OS-9 Level 2 for (updated) Dragons

[bluearcus]

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

[pser1]

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

[bluearcus]

Hi Pere,

So some more thoughts on the driver. I'm still struggling with getting things working nicely. But I think I know what the driver should do now...

F$AlHRam definitely gets a high block. It'll be 62 normally, as the CoCo boot track modules get loaded in to 63 and mapped in the high slot, but after that everything is bottom up.

We then need to select a good slot in the System task, record the high block wherever in the System task DAT, mark the involved pages in use in the System page map (this is what I was missing... stops OS9 reallocating it!) and then just map it in.

Will keep struggling with my environment and hopefully start to make some progress.

Cheers,

Mike

[pser1]

After some days trying different ideas in order to force the system to use page $3d (mandatory being $3x) for iMMUnity module, I have not
succeeded to show correctly the text on screen.
Tracing the code manually and correcting on the fly the values to force page $3d being used has been the way I have tried most of the time, but always have ended with system hanging as soon as I have set a breakpoint before printing code ...
Finally have tried the most 'hard way' I have imagined, letting the system reserve the video memory and then modifying manually all of the associated tables so that they correspond to using page $3d. I have changed tables $200,$900,$640 and $ffa4 besides byte at $a31d that contains starting address
In this last case, as soon as the system has to print a string, it creates garbage at the very last line of the screen and immediately hangs
So it is not using the table of compressed chars that has been using when no mods where applied to the std code ...
This seems to point to one or more variables (system or not) that I have not updated and so they could be the reason for the crash ...
See image of the crash
Any idea would be very appreciated!
cheers!
pere
PS. I don't think this will cure the problem, but I see that I forgot to update the video offset on the SAM registers. Will do another run!