Re: Symmetric multiprocessing...
Posted: Sun Jun 09, 2019 9:13 am
Hi Dave,
Looking good, if you ever produce any these boards, I would be interested.
Looking good, if you ever produce any these boards, I would be interested.
RIP Sir Clive Sinclair 1940 - 2021
https://qlforum.co.uk/
Nasta wrote:Also, some form of interrupt is needed if any kind of kernel is to run, to provide a periodic tick. Similar to QDOS, at least the poll interrupt must be implemented.
The 68K series CPU's expect to have the restart vector at address 0 - in fact, it's the stack pointer in the first vector and the initial PC in the 2nd vector - it's the only one that's 2 vectors - and it's the only one in supervisor program space (where FC2=1, FC1=1 and FC1=0), the other vectors are all in Supervisor data space (FC2=1, FC1=0 and FC0=1).Also, the 68K vector area and etc. are so small, it might be unnecessary to remap the DPRAMs, IF they do not conflict with a ROM image. I haven't tackled that part of the design yet.If you'd like to expand on that I'd be interested to read it.Pr0f wrote:you can use the FC0-FC2 to signal a fetch of restart vector - as it's different to other vector fetches - and could remap the dual port ram when a reset is done on the off board processor, but otherwise leaving it alone.
Well, you still need to decode addresses and decoding down to the 4 byte granularity requires a lot of address lines.Pr0f wrote:The 68K series CPU's expect to have the restart vector at address 0 - in fact, it's the stack pointer in the first vector and the initial PC in the 2nd vector - it's the only one that's 2 vectors - and it's the only one in supervisor program space (where FC2=1, FC1=1 and FC1=0), the other vectors are all in Supervisor data space (FC2=1, FC1=0 and FC0=1).Also, the 68K vector area and etc. are so small, it might be unnecessary to remap the DPRAMs, IF they do not conflict with a ROM image. I haven't tackled that part of the design yet.If you'd like to expand on that I'd be interested to read it.Pr0f wrote:you can use the FC0-FC2 to signal a fetch of restart vector - as it's different to other vector fetches - and could remap the dual port ram when a reset is done on the off board processor, but otherwise leaving it alone.
If you had a ROM that was mapped into a high address normally, you could also map that ROM into the first 4 bytes of memory if Supervisor Program space was indicated by FC2-FC0, so that the vectors come out of the ROM. There is nothing stopping you doing much the same with the dual port RAM, having it mapped at $00000000 when you reset by using the FC2-FC0 as well as address lines, but there after mapping it elsewhere in memory. You just lose the first 4 bytes of storage.
The standard QL addressing only ever makes use of FC1 and FC0 and uses those to flag interrupt acknowledge using auto vectors, FC2 is never decoded. Since FC2 =0 when FC1 and FC0 was undefined in the earlier models of 68K, it was assumed that FC1=1 and FC0=1 must therefore be signalling an interrupt acknowledge.
Nasta wrote:...needs some refinement to the hardware it it's going to run useful code. Some of it can be implemented using extra features present on DPRAM chips, depending on the actual chip. Also, some form of interrupt is needed if any kind of kernel is to run, to provide a periodic tick. Similar to QDOS, at least the poll interrupt must be implemented.
This, to me, is the most encouraging thing in this thread. Two people who have high status saying "if you want to do X you'll need to implement Y..." Thank you.tofro wrote:the periodic tick (the polling interrupt) is the heartbeat of any QDOS-based system. If you ever want to be able to implement anything QDOS-like, you'll need a timer interrupt on all CPUs.
I understand what you're saying. I just don't know how to implement something in hardware to create anything useful for you. My current plan is to ALWAYS have SRAM from $0, and have a toggle state for the 2K DP RAM where it is mapped to $0 or $80000 and will alias every 2K. The only reason to provide the relocation feature is because it might be asking too much for people to edit QDOS or Minerva to create a hole in the bottom 2K for message passing.pr0f wrote:The 68K series CPU's expect to have the restart vector at address 0 - in fact, it's the stack pointer in the first vector and the initial PC in the 2nd vector - it's the only one that's 2 vectors - and it's the only one in supervisor program space (where FC2=1, FC1=1 and FC1=0), the other vectors are all in Supervisor data space (FC2=1, FC1=0 and FC0=1).
You have shared access to my schematic, so you will see that I used two QL-side GALs. One is labeled "decoder" and uses A19..A9. It has outputs identifying accesses in the 2K blocks of each CPU, plus a "carry" to a second GAL, labeled "Reset manager", which has A8..A0 so can resolve an individual byte with a 15ns decode time. That GAL will have four flip flop outputs going to the guest CPU-side GALs indicating the mapping state of the DPRAM as 1 ($0) or 0 ($80000). It's a bit brute force, but it keeps the decoding chain really short. I considered using a small EPROM and four flip flops instead, but I was less confident about its flexibility and adding features later.Nasta" wrote:Well, you still need to decode addresses and decoding down to the 4 byte granularity requires a lot of address lines.
Hi Derek!Derek_Stewart wrote:Hi Dave,
That I have thought of by myself, without the assistance of the far smarter people here....Derek_Stewart wrote:I like both proposals, but could you detail the possible advantages of each system.
You're free to use the processors for any purpose and in any way you wish. It's also Open Source hardware, so if you had a specific purpose that needed a particular tweak or extra feature, you have the complete framework to build it.Derek_Stewart wrote:Is each CPU able to be programmed for separate tasks?