OS-9 Level 2 for (updated) Dragons

[sixxie]

Ok, new snapshot pushed. It'll default to the "flags" definition, but if you specify -gdb-flags-as-struct it'll redefine them as structs. I think it's worth keeping as an option, because I can see being able to manipulate those being useful for scripting.

[pser1]

that's perfect, Ciaran!
thanks a lot, you are really very kind!!
cheers
pere

[pser1]

Hello,
back from holidays I have reentered the debug sessions on the OS9Level II project.
Having left aside the annoying problem of text being not shown on screen, I have been tracing more and more OS9L2 code untill I have arrived
to the Shell mainloop where it waits for user commands.
These are the facts I am sure of:
- CC3Go calls function F$Wait. It seemed that it was hanging there (waiting for enter or Escape).
Now I know that it has already printed some text and it is waiting for the date-time to be entered by the user.
- Later, in the Shell module there is a loop containing an I$ReadLn where everything seamed to freeze as well.
Clearly this part has printed the OS9 prompt and is waiting for the user to enter any OS9 command.
Once received, it is processed and the result is poked into the mapped RAM despite nothing is shown on screen

Just to let you see that the Operating System is working correctly, I have saved some snapshots on XRoar, then I have extracted
the RAM area assigned to graphics PMode4 and saved them with a Dragon header so that I can load them into a std Dragon.
I am including here a screenshot of every snapshot I have taken, so you will see that the sequence is absolutely correct.
See images at the end of this message.

This means that we need to find out and solve the misconfiguration problem(s) we are suffering.
I have verified that the screen is using the Pmode4 with fonts for 51 chars per line!

I think that this is very good news for the project, but we need someone with a better OS9 knowledge to discover what is wrong
when the Kbvdio module initiates the device.

cheers!
pere

01-CC3Go-Beginning.jpg (7.06 KiB) Viewed 1406 times

02-BeforeFWait.jpg (13.67 KiB) Viewed 1406 times

03-AfterFWait.jpg (19.34 KiB) Viewed 1406 times

04-BeforeReadLn.jpg (19.83 KiB) Viewed 1406 times

05-AfterReadLn-Dir.jpg (19.98 KiB) Viewed 1406 times

06-AnswerToDir.jpg (22.55 KiB) Viewed 1406 times

07-AfterHonouringDirX.jpg (20.67 KiB) Viewed 1406 times

91-AfterMDir-E.jpg (32.97 KiB) Viewed 1406 times

92-AfterMFree.jpg (29.18 KiB) Viewed 1406 times

[lcurtisboyle]

F$Wait causes the program that calls it to pause and wait for a signal (usually sent by a driver, like joystick button press, key press, timer event) but can also be from another program. I think this was unique to Level II; Level 1 could do an F$Sleep call

[pser1]

F$Wait causes the program that calls it to pause and wait for a signal (usually sent by a driver, like joystick button press, key press, timer event) but can also be from another program. I think this was unique to Level II; Level 1 could do an F$Sleep call

Hi L.Curtis,
that's right, as can be seen in the images I have attached at the end of my previous message.
When F$Wait is called, we may enter a date-time or simply press enter accepting the default value that OS9 will use ...
Right now, I am sure that the files used in this project are working correctly because the screens 'extracted' from the Xroar snapshots do show
the expected results in all of the cases.
But *nothing* appears on the screen, so we are doing something wrong when configuring the terminal. KBvdio module is responsible for Initializing the output device so we have to find out what is wrong there ...
I am attaching a zip with the source files used in the project for maybe someone could have a read at them and find out the errors we have overlooked
Of course I am not sure if the PIA values used in that module are the correct ones for the Dragon
I am attaching here some snapshots of a tracing session trying to capture the values of the PIAs at different points ...
We are almost reaching our goal, we just need a little help from someone with better OS9 inside knowledge
I hope someone will find the correct answer to solve that problem!
Thanks beforehand!!
pere

Source Files.zip

(179.4 KiB) Downloaded 18 times

W1-FirstLineInsideKbvdio-InitializationFunction.jpg (179.84 KiB) Viewed 1392 times

W2-AfterAll24Lines.jpg (185.04 KiB) Viewed 1392 times

W3-BeforeWrittingMessage.jpg (152.94 KiB) Viewed 1392 times

W4-AfterWritting twoStrings.jpg (142.8 KiB) Viewed 1392 times

W5-WrittingStringForDateTime.jpg (145.23 KiB) Viewed 1392 times

WW-noOS9L2-WelcomeMessage.jpg (100.59 KiB) Viewed 1392 times

[pser1]

just to add some info about the initialization in Kbvdio, let me add a few comments ...
- IOMan, at $B80D calls JSR D,X resulting in a call to Kbvdio module at $DF83
where it does LBRA DF95 (Kbvdio Initialization function)
regU comes here with value $A300
It clears 128 bytes from $A31F till $A39E
then disables interrupts (despite they were already disabled!)
The does some POKEing
POKE&HFF01,&H30:POKE&HFF00,&H00:POKE&HFF03,&H3B:POKE&HFF02,&HFF
POKE&HFF01,&H34:POKE&HFF03,&H3F
now restores flags (no change as they were previously disabled!)
OS9 F$RqMem (asks for $1900 bytes) - retunrs regU=$8A00
OS9 F$SRtMem (returns 256 bytes back)
disables interrupts
POKE&HFF03,PEEK(&HFF03) OR 1
Restore interrupts (value $F0 still disabled)
POKE&HFF22,PEEK(&HFF22) OR &HF8 (setting PM4)
Inside Subroutine E24C:
regY=$8A00 (RAM beginning address to be cleaned)
Now processes 24 'char' lines as 8 rows of 16 words clearing every byte there
POKE&HFF22,PEEK(&HFF22) OR &HF0 (setting again PM4)
Now it sets some SAM registers (V0-1-2): &HFFC0-C3-C5 Seting V=06 for PMode 4
Now it sets SAM registers to define graphic RAM offset: FFC7-C8-CB-CC-CE-D0-D3 setting value $45 -> x$200= $8A00
But despite all this work, the screen doesn't show any change
Could anyone spot the errors in this procedure?
thx in advance
pere

[pser1]

Hello,
I have tried a few tricks but none of them have made the text appear on the screen
I am afraid that with my almost null OS9 technical knowledge I cannot imagine/find a reason for this 'strange' effect I am suffering
on the screen writting process.

I know that the text is drawn into the correct RAM addresses ($8a00-$a1ff) because extracting this area from any XRoar snapshot results
in a binary file that once loaded at $0C00 into a std Dragon in PMode 4, it shows the correct string text that had been printed by OS9L2.

So, what could be the reason for this text to be not 'reflected' to the screen?

- The colour for foreground could be the same we have for the background
For this case, I have seen that the module REL that we are using (from Tandy L2) contains code that copies a 16 bytes table to addresses: $FFB0-$FFBF
This might be OK for a CoCo3, but I don't know if this makes any sense for a Dragon!

- On a Dragon, for every frame the screen is drawn/updated reflecting the changes we have done to the graphic RAM between two
consecutive frames (/FS). This means that an interrupt is somehow produced and detected ...
How does OS-9 update the screen?

- What modules are involved in the screen update process on OS9?

I hope someone is going to shine some light to solve that awful problem!

Thanks a lot beforehand!
Do not fear to chime. Any idea could be the clue to that problem!!
cheers!
pere

[sixxie]

The only thing that comes to mind is that the iMMUnity needs you to use the on-board RAM for video - are you doing whatever it is you need to do to make video data go to the right place?

[pser1]

The only thing that comes to mind is that the iMMUnity needs you to use the on-board RAM for video - are you doing whatever it is you need to do to make video data go to the right place?

Hi,
that's a very good point, Ciaran!
As OS9L2 is calling the function F$SRqMem, the 'assigned' RAM chunks are taken from the very beginning of the RAM but according to the constraint
you have mentioned, the RAM to be used lies from $70000-$7FFFF corresponding to 8K blocks number $38-$3F (64Kb). Currently that OS9 function
uses block #03 instead ...
I will have a peek at that function in order to find a way to 'force' the search to begin on block #38 for instance
thanks a lot!!
cheers!
pere

[bluearcus]

Hi Pere,

This is not entirely unusual in level 2 machines. There are often only certain parts of the RAM areas which can be used for graphics. As a result, customisation of the kernel memory allocation routines is sometimes done to ensure the right blocks are grabbed and that they aren't typically accidentally already allocated by the time the graphics memory request is made.

If you are running code that's primarily from Bob Halls expanded Dragon designs, the memory mapping for the vdg depends upon which particular design the code has been patched for.

In the 128k version of his design, Bob implemented a single bit control register which held the 64k bank number to be used for the source of graphics memory in the VDU half of the cycle. In the 256k or larger designs, with the MMU off the top 64k bank of available memory is used and once the MMU has been switched on the bottom 64k of memory is instead accessed.

On a Coco 3, the whole bottom 512k is usable, and I suspect there's no special handling. The Dragon Beta expects to be changing gfx modes frequently and after lots of other stuff had been loaded, but again there's a restriction... the bottom 128k is connected to the 6845 based graphics subsystem using a special 16 bit wide bus, so only that area can be used. As the beta disallows mmu map update access to anything apart from the system task, direct manipulation of the gfx mapped pages isn't assumed to be always possible, so Viviway did some kernel customisations, adding explicit gfx memory allocation calls. They are detailed in here:

https://archive.worldofdragon.org/brows ... le0001.jpg

Os9-68k has a whole subsystem on this 'coloring' different parts of the memory map and making requests that are specific.

Tormod must also have done something in his Mooh port, though it may be more confusing than helpful to look at, because the gfx allocated memory that needs to be allocated in a Mooh system has must have it's mapped location also be reserved in every 64k process map!

In Coco 3 world of course, things are thankfully simpler and everybody can read and write to the mmu maps, so it's possible for the coco3 console driver or our amended kbvdio device driver to manually setup the required map elements.

My assembled doc included Bob's set of patches for kbvdio which, according to his commentary, set up which bank was mapped in.

Soren's disassemblies don't include the original Eurohard v2.0 version and I haven't tried to generate a nice commented disassembly. It's not clear to me if the patches are for his 128k or 256/512k design - or if they are sensible on the form you have and I'm unfortunately not able to do any checking by disasming of that revised code vs the standard at the moment, but the difficulty almost certainly lies there as the IMMUnity is expecting the vdg to be accessing the highest bank and the patched kbvdio from Bob is either wrong, using a non existent control register, or just forcing the lowest 64k bank.

Hope these ramblings help a little.

Keep up the amazing work.

Mike