That first one was incomplete, and also lacks some design changes I made later on. The one in this later post is close to what I've actually built, and that post describes the differences to the first design in some detail.

The further changes in what I actually built are fairly simple:

• Added pull-up resistor to the ACIA's IRQB
• Added pull-up resistor to /ENDSUPER
• Add pull-down resistor to ROMDIS
• Omit the upper 512K RAM bank
• Replace the lower 512K RAM bank with a 32K module

I'll upgrade the RAM back to the original spec at some point, but aside from that I'd consider that hardware design pretty stable. The only serious hardware bug I'm aware of is that the mechanism to allow code in ROM to write to the private RAM (U16) is not reliable enough to write actual code into that RAM while the ROM is selected, but it's been possible to work around that without too much trouble and I haven't stopped to investigate it more.

The code is all here as well, though without any documentation beyond the comments: https://github.com/gfoot/multitasking65 ... n/src/mtos

Thanks for the pointer!

I made some changes to allow IRQs during system calls, and it improved these figures. From that last post I was observing about 65us duration of IRQB, and it's now down to about 30us-40us when supervisor mode had been active. It's about 20us when user mode was active, which won't have changed since the previous post. Here's an updated trace showing, top to bottom, VPB, SUPER, IRQB, and the serial transmit line:
There are three pulses in VPB showing where interrupts or system calls occured. The first is an interrupt taken in user mode - probably the preempt timer expiring. This was serviced in about 20us, but the system then took about 35us to pick a new process (measuring from the rising edge of IRQB to the falling edge of SUPER). Most interrupts don't cause a process switch so avoid some of this cost in their exit code. Interrupts would be masked throughout this one.

Then the system went into user mode and executed a system call via BRK, putting it back in supervisor mode. Shortly after this started, IRQB went low, and - as I now allow interrupts during system calls - this was serviced as soon as interrupts were re-enabled, despite the system still being in supervisor mode - you can see the third pulse on VPB at this point. The IRQ itself cleared about 20us later, consistent with the first one, so overall IRQB was low for about 30us in this case.

I'm sure there's room for improvement in the IRQ response code in general but am glad to see enabling interrupts during syscall is both working and having a positive effect. I think there's potential to enable interrupts during task selection as well. The response times will also reduce if the clock speed goes up, of course - but at 4MHz it looks like the worst case is now about 40us.

These are the only changes needed to enable interrupts during syscalls - pleasantly few! I mark that an interrupt came from supervisor mode by decrementing a memory location to a negative number, which can be done without needing any registers; and it can then also be tested right at the start of the regular interrupt handler routine, without corrupting any registers either. It branches to a dedicaded routine to handle hardware interrupts from supervisor mode. The preempt interrupt is also disabled because we don't want that one to fire - we can't switch processes anyway while we're in a syscall, all we can do is lightweight processing of proper hardware interrupts.

I haven't had a lot of time recently, but I wanted to add a video output circuit as I was tired of the slow speed of the serial communication. I could increase the baud rate but it still wouldn't get me to where I want it to be, it ends up being too much of a burden on the system and all the user processes end up spending all their time waiting for the serial line.

I won't go into full detail about the video circuit here, I'll post that separately when I get time - but briefly, I wanted something capable of decent text output, without requiring a lot of video RAM, so went for a VGA-style text display, with 80x30 character cells, each 8x16 pixels. To keep it simple at first I also made it black-and-white only, with no character attributes. As I've said before, all my past video circuits were synchronised with the CPU clock - or rather, the CPU clock was generated from the video circuit. It's a pattern I copied from the BBC Micro. It works well but removes a lot of flexibility on the CPU side of things, and I've been meaning to do it differently "next time" - so here next time is. This runs the video circuit at 640x480 VGA frequency, and the main computer is still running at 4MHz. The video circuit captures all writes to paged memory, and especially writes to pages $F0-$F7, and buffers these (1-deep) and writes them into its own private video RAM at the next opportunity. The computer's main RAM is also accepting these writes, and the CPU can also read the data back from there like any other RAM.

Here's a photo of the circuit and test output:


Here the kernel is mapping one of its logical pages to physical page $F0, which the video circuit decodes as video memory, and writing data there as part of its initialisation sequence. I used the chequerboard pattern to check the screen bounds were good and make sure the monitor's calibration worked well, and overlaid a ruler so I could check the overall width was correct.

I will probably add a syscall to allow any user process to also map this page, and they can just fight over it - all I want is to use it for more real-time output from the processes, so I can design them to each draw only in one part of the screen. In future I could use more RAM pages to provide multiple framebuffers, with some form of switching capability like virtual consoles in Linux, but the point here for test purposes was to see them all running together so this is what I'll do first.

There is a bug at the moment which leads to some write operations not being performed, or perhaps not being performed correctly. I'm not sure what's causing it, it is hard to observe happening, and I tried various mitigations at various points in the write pipeline without improving matters. Making the code just execute every write operation twice in a row did seem to work around the problem at least - I will have to diagnose it in more depth another time.

I am also pretty sure my shift register is broken - it behaves very strangely, in ways that I have also found workarounds for but which shouldn't be necessary. I mean to also try swapping it for another one but it is trapped under wires at the moment!

Splendid! Any special care to move data from one clock domain to the other?

No not in this case, I cut as many corners as I could. The main system's RAM /WE line also goes into the '574 CP inputs, so that they capture the address and data bus states at the end of the write operation. Then a PLD clocked by the VGA pixel clock (25.175MHz) samples that plus the high bits of the physical page, watching out for cases where /WE is low and the physical page is $F0-$F7. When it spots the end of such a condition (i.e. it was satisfied on the previous VGA pixel but not the current one), it latches that a write is pending, then uses that latch to conditionally activate the write phase at an appropriate time (when the video system isn't reading from the RAM). It would fail in various ways if that condition was somehow noisy, or activated at an inappropriate time.

I guess the opportunities for metastability are where the page bits may be changing at the same time as the VGA clock rises, or where the VGA clock coincides with the an edge of /WE (which is gated by PHI2 as usual). The page bits are provided by a RAM lookup during phase 1.

A better design may be to use external D flipflops to track whether a write is pending, so that one can be triggered by the edge of /WE and the other can synchronise that to the VGA clock, then the PLD could read from there, one clock cycle later, to get some protection from metastability.

Thanks… so what you have at present is a kind of testbed which might illustrate how often any kind of metastability problem might turn up…

I'm at the stage of working out the character set for my half-svga display: would you care to share your character rom?

Thanks,

Neil