Hi again,
Still away from my Dragon stuff but I've looked at the patched module disassembly vs the original a bit.
The patched code seems to be for Bob's 128k design with the high / low bank bit. We should remove the logic which calculates which bank and sets the "VDG RAM is in" toggle with the two FF80 and FFE0 writes, it's irrelevant.
We also need to do a replacement of the F$SRqMem service call with a local implementation that grabs pages (well, a page) from the top of physical RAM as available, and maps it in to a sensible free spot in the system task. It's too risky to change F$SRqMem itself as it's the main allocator. We could add a new Dragon Beta style one to the kernel, but a local fix in the kbvdio patch is probably reasonable.
Thankfully that should be quite simple to do with one kernel F$AllRAM call (which is a top down Search on the coco3) and then a quick bottom up search through the system task map for the first free page and on finding it, using F$SetImg to map the page in. The SAM Address setting stuff can then remain the same.
So it's not a terribly difficult fix, it's just different to what we currently have. Apologies for not having identified the patch functionality was way off what the IMMUnity board would need earlier... It's been a bit of a non Dragon period sadly!
Cheers,
Mike
It should be possible to do that with
OS-9 Level 2 for (updated) Dragons
Re: OS-9 Level 2 for (updated) Dragons
Hi Mike,
thanks a lot for your last posts talking about the way the current version of boot procedure is working that conflicts with the iMMUnity specs
Unfortunately, my free time has been drastically reduced for family reasons. Hope eveything will be back again soon ...
I was planning to trace the F$SRqMem function modifying 'momentarily' the value of variable <$40 to 0x2e instead of $00 to force it to
use the page before $2f which is already in use by the system.
I know that at some point the calculations it does do conflict with the modified value of <$40, that's why I am sure I must trace it step by step
and 'probably' a simple change in the code could do the trick, but that has to be checked.
Hope to be able to do that tonight, then I will tell you all the results of the test.
cheers!
pere
thanks a lot for your last posts talking about the way the current version of boot procedure is working that conflicts with the iMMUnity specs
Unfortunately, my free time has been drastically reduced for family reasons. Hope eveything will be back again soon ...
I was planning to trace the F$SRqMem function modifying 'momentarily' the value of variable <$40 to 0x2e instead of $00 to force it to
use the page before $2f which is already in use by the system.
I know that at some point the calculations it does do conflict with the modified value of <$40, that's why I am sure I must trace it step by step
and 'probably' a simple change in the code could do the trick, but that has to be checked.
Hope to be able to do that tonight, then I will tell you all the results of the test.
cheers!
pere