Shop OBEX P1 Docs P2 Docs Learn Events
Towards OS9 operating system on P2? - Page 2 — Parallax Forums

Towards OS9 operating system on P2?

2»

Comments

  • evanhevanh Posts: 15,126

    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

  • evanhevanh Posts: 15,126
    edited 2022-09-24 07:12

    @"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.

  • @evanh said:

    @"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

  • 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.

  • evanhevanh Posts: 15,126

    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.

    Disk Basic Unraveled explains it on page 14.

    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.

  • evanhevanh Posts: 15,126

    Specific for sure! Used as an abort mechanism to turn the 6809 into a temporary DMA controller. Kudos to the inventiveness though.

  • @"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.

Sign In or Register to comment.