It's called shared interrupts. It uses level triggered IRQs instead of edge triggered. Level triggering allows for IRQ pin sharing because the source devices have to be acknowledged to release their respective open drain wiring.
@evanh said:
Expect NMI never to be used. Any system that uses it is a broken design. It's a wasted pin.
Well, I would not call a zx81 a broken design. They had a latch to switch it on. Those were the days, when there was no flashing and in rom the vectors were there before startup. Days, when timers have been rare.
In coco-3 there are registers to enable the different sources for interupts. You can even select, if irq or firq would be fired from the same source. And nmi is wired to the bus, so hardware designers left open much. The os9 reference manual says, that nmi is used and it's vector points to the disc driver service routine.
@ke4pjw said:
As I recall, the default clock module in OS-9 uses the h-sync to generate the ticks. The h-sync and v-sync timers are exposed in the GIME. I remember having to coble a new boot disk when I got my DISTO supercontroller with RTC, because the clock module needed to be updated to use the RTC. As I recall that module is the heart of the multitasking and each 60hz "tic" it would scan for virtual IRQs in a table to service the various tasks. It has been 30 years since I last thought about any of that. If you emulate the h-sync and v-sync counters, I don't think it would be a problem.
Yeah, I don't think the P2 could emulate things fast enough using spin. You can't use the streamer FIFO with interpreted Spin/Prop Tool, and that latency is gonna kill your performance.
If I ever get time, I need to learn the overall architecture of these emulators. Seems like a lot of fun.
Thanks for your efforts Christof!
Hi Terry,
this is using compiled C Source. Interpreted Spin would he way slower.
Christof
@"Christof Eb." said:
Well, I would not call a zx81 a broken design. ...
That's arguable! I had a second hand one of those. The memory expansion was diabolically unreliable.
In coco-3 ...
They exposed the NMI only because it was there. It doesn't work if you try to use it for real. IRQs have to be maskable. Otherwise data gets corrupted. There's always multi-instruction atomic ops needed.
@"Christof Eb." said:
Well, I would not call a zx81 a broken design. ...
That's arguable! I had a second hand one of those. The memory expansion was diabolically unreliable.
In coco-3 ...
They exposed the NMI only because it was there. It doesn't work if you try to use it for real. IRQs have to be maskable. Otherwise data gets corrupted. There's always multi-instruction atomic ops needed.
Well, your general idea might be reasonable, but this rule of thumb does not help here, because you need solid informations. As written, the os9 reference manual says, that nmi is used!
I had a zx80 and yes, the ram extensions was very unreliable, but this was because of the connection. These computers have been too cheap but I learned a lot nevertheless.
Christof
Problem is, even such a limited use will upset other sensitive code if there is any concurrency. I guess that means there wasn't any such concurrency. Kind of defeats the purpose of an interrupt in the first place.
@evanh said:
Problem is, even such a limited use will upset other sensitive code if there is any concurrency. I guess that means there wasn't any such concurrency. Kind of defeats the purpose of an interrupt in the first place.
There is no concurrency when the CoCo is using the default disk controller. It halts the CPU. There were aftermarket controllers that did not do this, such as the Disto Supercontroller II. I know the default drive controller did this in OS9, as it would halt all windows and processes when the disk was accessed. I suspect the RBF or IOMAN modules would set the return vector for NMI.
Data transfer between the computer and the disk drives through the FDC is
accomplished through a series of hardware and software ‘tricks’. The slow clock
speed of the Color Computer will not allow data to be transferred in the ‘normal’
method of getting a byte from the computer, giving it to the FDC and then
performing status checks until the FDC is not busy. There is just not enough time
for this when operating at double density. Part of the Color Computer’s solution is
a hardware trick whereby the disk controller board will allow the FDC to halt the
6809 while the FDC is storing or retrieving data. The halt flag will allow the DRQ
signal from the FDC to halt the 6809 so that the 6809 will wait while the FDC is
processing a data request. This trick will allow the 6809 to pass data to the FDC
as fast as the FDC can take it by executing a fast loop of: grab a byte from RAM,
give it to the FDC and loop back to get another byte. The analogous loop for
getting data will also work. The only problem is how to get out of this loop. This
problem is solved with software - when an FDC command such as WRITE SECTOR or READ
SECTOR is completed an interrupt (INTRQ) is generated by the FDC. The Color
Computer connects this INTFQ signal to the Non Maskable Interrupt (NMI) pin of the
6809. This means that whenever an FDC command (except the $D0 FORCE INTERRUPT) is
completed, an NMI will be generated. The computer will now be able to tell that an
FDC command is over; all that is left is for the computer to know where to go when
the command is finished. This is accomplished by storing a jump vector (DNMIVC) in
the disk RAM prior to entering the FDC data transfer loop. Another byte in disk RAM
is used as a flag (NMIFLG) to indicate that the NMI jump vector should be used. If
the NMIFLG is not equal to zero and an NMI is received by the 6809, Disk Basic will
cause the NMIFLG to be reset and control will be transferred to the address in
DNMIVC. It is exactly this method, which is used to exit from the FDC data transfer
routines.
Needless to say, the NMI in the coco has one very specific use case.
@"Christof Eb." said:
Hi forum members,
P2 has 512k memory and can do multitasking with it's 8 cogs, so I am thinking about times, when this was plenty of memory.
A realtime operating system, that works with 512k, has plenty of software available, can do multitasking, would be OS9, written for 6809 CPU and used for Tandy Coco3 computers, which led to a rather large amount of software. (I had been thinking of CPM/68k, but there is not much software for this platform and it cannot do multitasking. Os9/68k is not available.)
Access for 512k is done via a MMU tcc1041 in the Coco3.
Any thoughts or comments?
Christof
As a "coco nut" nitros was ignored for all long time by it's owner (microware) and for the coco nitros was ignored for a number of reasons like the coco was discontinued, etc. A few years ago a former employee contacted microware and got "formal" permission to use nitros on an an 6809 cpu or emulator but not on any "modern" cpu.
Comments
It's called shared interrupts. It uses level triggered IRQs instead of edge triggered. Level triggering allows for IRQ pin sharing because the source devices have to be acknowledged to release their respective open drain wiring.
Well, I would not call a zx81 a broken design. They had a latch to switch it on. Those were the days, when there was no flashing and in rom the vectors were there before startup. Days, when timers have been rare.
In coco-3 there are registers to enable the different sources for interupts. You can even select, if irq or firq would be fired from the same source. And nmi is wired to the bus, so hardware designers left open much. The os9 reference manual says, that nmi is used and it's vector points to the disc driver service routine.
Hi Terry,
this is using compiled C Source. Interpreted Spin would he way slower.
Christof
That's arguable! I had a second hand one of those. The memory expansion was diabolically unreliable.
They exposed the NMI only because it was there. It doesn't work if you try to use it for real. IRQs have to be maskable. Otherwise data gets corrupted. There's always multi-instruction atomic ops needed.
Well, your general idea might be reasonable, but this rule of thumb does not help here, because you need solid informations. As written, the os9 reference manual says, that nmi is used!
I had a zx80 and yes, the ram extensions was very unreliable, but this was because of the connection. These computers have been too cheap but I learned a lot nevertheless.
Christof
The NMI is only used by the drive controller to vector out of data transfers.
https://nowhereman999.wordpress.com/2017/11/17/how-to-setup-and-use-irqs-on-the-trs-80-color-computer-part-1-what-is-an-irq-and-when-would-i-use-it/
OS-9 Level I documentation also states that it is used exclusively for the drive controller.
Problem is, even such a limited use will upset other sensitive code if there is any concurrency. I guess that means there wasn't any such concurrency. Kind of defeats the purpose of an interrupt in the first place.
There is no concurrency when the CoCo is using the default disk controller. It halts the CPU. There were aftermarket controllers that did not do this, such as the Disto Supercontroller II. I know the default drive controller did this in OS9, as it would halt all windows and processes when the disk was accessed. I suspect the RBF or IOMAN modules would set the return vector for NMI.
Disk Basic Unraveled explains it on page 14.
Needless to say, the NMI in the coco has one very specific use case.
Specific for sure! Used as an abort mechanism to turn the 6809 into a temporary DMA controller. Kudos to the inventiveness though.
As a "coco nut" nitros was ignored for all long time by it's owner (microware) and for the coco nitros was ignored for a number of reasons like the coco was discontinued, etc. A few years ago a former employee contacted microware and got "formal" permission to use nitros on an an 6809 cpu or emulator but not on any "modern" cpu.