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 81 times

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

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

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

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

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

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

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

92-AfterMFree.jpg (29.18 KiB) Viewed 81 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 2 times

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

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

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

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

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

WW-noOS9L2-WelcomeMessage.jpg (100.59 KiB) Viewed 67 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