Products > Vintage Computing

Need some advice on threading on a Z80

<< < (20/21) > >>

SiliconWizard:

--- Quote from: JamesIsAwkward on September 13, 2024, 03:40:09 am ---For the record this is all a "just for fun" build. Years ago when I started toying with the idea of a custom retro computer I chose the Z80 arbitrarily. Mostly because it seemed nicer to mess with due to its large register set when compared to a 6502.
--- End quote ---

Yes the "for fun" part is understandable, and impossible to question. It's personal.
As to the Z80 being nicer than the 6502, it's all a matter of perspective. I did, overall, prefer the instruction set of the Z80 for hand-writing assembly, but the 6502 was much more efficient per clock cycle. If I had to write a multitasking OS on a 8-bit MCU, I would probably pick the Z80 over the 6502 without a question. Actually, I would probably go for the 6809: it was more powerful, had a better instruction set, and I've never directly programmed one in the past (contrary to the others), so that would be a "learning" experience too!


--- Quote from: JamesIsAwkward on September 13, 2024, 03:40:09 am ---For instance, there aren't any real turn-key ICs that can help do SPI. Instead of bitbanging SPI (which would be very slow for wiznet ethernet or sd card use), I'm trying to design a circuit that allows my Z80 to interface with an SPI device via its full 8-bit data bus in parallel.

--- End quote ---

I don't think there is either, but you can design that around a discrete shift register and some glue logic (if you want to use a "vintage" approach), or you could of course implement this in a small FPGA/CPLD.

Jonathon_Doran:
There were plenty of design issues with the 99/4A.  Most people didn't realize that while their BASIC programs were interpreted, the BASIC interpreter itself was written in an interpreted language.
Much of the I/O had to go through the 9918A which meant that you had to setup memory and then interrupt the 9918A.  There was no direct access.

I remember buying the Editor/Assembler (needed for assembly language programming) and then reading on page 1 "We assume that you know assembly language."   This was before the internet...

I would have a lot more fun with that machine now.  40 years of experience is a good equalizer.

I've had similar thoughts as the OP about vintage computing.  I was thinking of a 6502 with an external MMU and VGA graphics.  But I would have cheated and done the graphics on an FPGA because I couldn't have breadboarded a decent resolution.

brucehoult:

--- Quote from: Jonathon_Doran on September 14, 2024, 03:11:29 am ---There were plenty of design issues with the 99/4A.  Most people didn't realize that while their BASIC programs were interpreted, the BASIC interpreter itself was written in an interpreted language.
Much of the I/O had to go through the 9918A which meant that you had to setup memory and then interrupt the 9918A.  There was no direct access.

--- End quote ---

Ah, so nothing to do with the CPU itself.

From 1976 until the 8086 and 68000 became available to normal people in the early 80s, the TMS9900 looks like it should have been more than a match for the 6502 and Z80, and far far easier to program.

bson:

--- Quote from: brucehoult on September 11, 2024, 01:46:35 am ---Most OSes from the 1970s to this day switch CPU-bound tasks (that finish their time slice) 100 times a second. So on the Z80 you'll use 1% of the CPU time to do that task switching.

--- End quote ---
They used to interrupt on the line frequency, so 60 or 50Hz.  Because things like programmable timers were too expensive and frivolous, a heartbeat interrupt was used and all timing done in software.  This doesn't mean every tick resulted in a thread switch (used loosely here, meaning execution context since we've seen confusion over this term before).  With the advent of programmable timers, nobody designs systems like this anymore.

In a modern RT system, if only one thread (execution context) is active, there is no need for context switching and the timer doesn't need to run at all - at least not for this.
If a higher priority thread is activated by an interrupt, a switch to it is made, and no timer is needed.
If a lower priority thread is activated by an interrupt, no switch is made, and no timer is needed.
If a thread of the same priority is activated and the scheduler implements round-robin, it can implement a round-robin policy for these threads, and give it a quantum for which a timer is used to signal its end and that a RR context switch is needed.

The timer might still be running, to keep time - it can interrupt close to rollover, with some margin, to update a value in memory and restart.  At any point, the current time, in ticks, is that of the value in memory plus that of the timer.

Or a separate 32-bit timer, such as the core ARM SYSTICK, can be used exclusively to keep time, with a huge rollover margin.

NOBODY designing modern systems has a fixed heartbeat.  It's simply not necessary with the existence of programmable timers.

peter-h:
Gosh this takes me back.

I've been doing asm programming on Z80 Z180 Z280 etc since c. 1978.

Wrote a simple RTOS for it too - posted the source here a few years ago. It was a simple but totally effective solution for building a complex product without ending up with a ridiculously convoluted state machine. It does rely on tasks behaving not too badly otherwise, while a hanging task will still get chopped, it merely wastes the CPU until the next tick. So I have an API call to "suspend me" which you call then you are done for now.

FreeRTOS is great and I am using it now on arm32.

Implemented CP/M 2.2 on various boards I designed. It is a very good OS and you will create a life's wasted work if you write your own. And there are lots of apps for CP/M - stored at various archives. You don't need an RTOS for CP/M though; it is just handy if you are building a product which happens to use CP/M for a file system - a bit like one would today use FatFS for a file system which is wondows compatible if done via USB MSC, but you don't want to be coding USB on a Z80 unless you are a total masochist. I did a product in 1991 which contains a file system but it wasn't done with CP/M and as a result was primitive and inefficient, but it worked.

Implemented graphics too, with various chips e.g. NEC UPD7220, SGS EF9367. You can spend your life working out a suitable API for what you want to do. You will get into graphics code for circles, fills, fonts... a life's work just doing that.

So that's the Z80. I would recommend the Z180 actually, for various reasons, but if you want total authenticity then the Z80 will do.

If you want to learn about computing and build useful stuff then get into ARM32. I've just finished a 32F417 based product and it does everything about 100x faster than the Z80 used to :)

I normally used a 10ms timer tick in the Z80 RTOS.

Navigation

[0] Message Index

[#] Next page

[*] Previous page