OS-9 Level 2 for (updated) Dragons

[pser1]

Wow Pere,
You are making great progress here. Apologies for not having been following along - I hope I can clear some life stuff and watch a bit more closely going forwards.
Keep up the good work.
Mike

Hi Mike,
no worries. Thanks for your kind words.
You know your comments/ideas are very much appreciated, specially on this OS9 world!
Having almost no idea about OS9, this project is more like a 110m hurdles race to me;-)
Well, at least once solved the problems I myself added and having changed the final OS9L2 disk to a single density as probably did Bob Hall
back in the 80's has allowed the successful loading of the big OS9Boot file into memory.
I have seen the entries in the module directory and they seem correct.
Now I need to compare the unassembled OS9p2 from Tandy OS9L2 against the well documented file I downloaded (from rough.org)
something like "OS9L2-Kernel Part2.asm"
I must say that now if I leave that part2 run without tracing, it gets to a point where, probably, it switches to PM4 and then garbage
is shown on the screen.
No need to hurry! I will trace the whole OS9p2 just to keep widening my knowledge about that 'long' boot procedure.
I think that nobody has ever seen the OS9L2 welcome screen using Bob Hall's procedure.
I don't know if it should go PM4 or should stay in text mode instead. Time will tell!
cheers!
pere

[pser1]

Hello,
Time for an update!
I have been tracing the boot from the point where OS9p2 is called.
This module has a lot of calls to SWI2
Each time one was to be called, I set a temporary breakpoint to stop execution when the RTI returns
I have gone through these
- Install service routines
- change directories
- open path
- count open image (twice)
- link to OS9p3 (it doesn't exist in our case)
- startup initial process
That last one doesn't return, so a full trace is needed from that point on.
In the way I have found these subroutines
- start next proc
- allocate process task number
- get free DAT
- set process task
- update process task
And suddenly I was debugging code at $C0B4 but I have no source file for that memory location!!
After looking at the memory contents of this area I have found two know modules
- Init at $BFA1
- CC3Go at BFCF
A lot of modules were loaded into memory when the big file 'OS9Boot' was loaded and these modules are part of it.
To help debugging, I have unassembled the modules from Tandy OS9L2 that we are using without modifications as Bob suggested.
The problem will be, again, finding commented code for them. Will have a look at both rough.org and NitrOS-9

As I was debugging with the source file on the right of the screen and the GDB debugger on the left, so
I have not seen any 'effect' of the executed code on the screen of the Dragon64
But when I have arrived to CC3Go and have stopped, I have seen that the Dragon screen was white (PMode 4)
and there was some garbage in the lower part. See image
The program has not crashed nor looped at any point, that should be good news!
I am attaching a zip file containing all of the files used/to be used along that project including the virtual files to test/debug
cheers!
pere

OS9L2-Project.ZIP

(222.78 KiB) Downloaded 3 times

Garbage while Booting OS9L2.jpg (13.36 KiB) Viewed 88 times

[pser1]

Hello,
a few comments ...
1) the garbage on screen seems to have been drawn before calling the module 'CC3Go' being that one the module that prints the intro text on screen
That means that a previous call has written on screen. Must debug again looking at the emulator screen too to find out the culprit!
2) Unassembling the CC3Go with F9DASM has produced a very harsh file with lots of unaligned codes that got bad unassembled
I have needed to unassemble manually the code where the execution begins ... with OS9 calls it is just painfull
3) I am again alone with myself, I mean with no comments on the code. Unfortunately "rough.org" has no sources for CC3Go, Shell ...
When I have entered NitrOS9 std and 'easy of use' GitHubs, I have not been able to find any source file. I am sure it is my fault,
but anyway it surprises me that coding assembly language could be much easier to me than searching for a simple file in GitHub
I am sure that with some help/pointers this old school programmer could be happier finding those dreaded source files
Don't loose your chance to help me!
This is a true Cry for Help!
thanks a lot
pere

[pser1]

Hello,
I have been debugging again from the point where OS9p2 seems to want to 'open' module Term
The code has jumped into IOMan, yet another module with no info/comments. By now I am using the unassembled file
generated with F9DASM, so a complete blank file
There are lots of calls to SBRs / OS9 functions so it is very, very slow to advance through that many sub-functions

I am using GDB with XRoar and I only know a way to debug forwards.
It would be very interesting to leave the program work for a lot of code lines, say $400 and wait till the moment
the screen goes PM4 and shows garbage.
Having the debugger stopped, if I only could step backwards to 'see' the last sentences executed, probably I could
detect the wrong code that is failing to write to the screen ...
If anyone knows of a way to do that, please, let me know!
Thanks a lot

Just a doubt. I have seen that inside 'Term' module there is a string written "KBVDIO" but the file I copied to the OS9L2 disk
say disk 'F1' in file OS9Boot is named 'Kbvdio'
I know that uppercase vs lowercase are considered different letters by OS9, so I am afraid that this could cause problems
in the moment we want to load/link it
But, probably, this is not the problem we are suffering now getting garbage on screen ...
The module that prints the intro message is CC3Go but the garbage seems to appear before trying to write to the screen!
pere

[atsampson]

If you run xroar with the -trace option, it'll print every instruction it executes to stdout. You can redirect that to a file and then search through it afterwards. (You can turn tracing on and off at runtime too, but disk space is plentiful these days...)

If it's not obvious from the trace, you might also be able to use xroar's GDB watchpoint support to catch it writing to screen memory...

[pser1]

If you run xroar with the -trace option, it'll print every instruction it executes to stdout. You can redirect that to a file and then search through it afterwards. (You can turn tracing on and off at runtime too, but disk space is plentiful these days...)
If it's not obvious from the trace, you might also be able to use xroar's GDB watchpoint support to catch it writing to screen memory...

Thanks a lot for that idea!!
Right now I don't know what RAM addresses are used to show text in PMode4, mainly due to the mapping possibilities ... FFA0...FFA7
In fact I am not sure if it must be printed from task #0 (system). I hope it is but ... need to be verified!
I think that issuing commands like
'si 256' (to step through 256 code lines) would help once tracing is enabled.
cheers!
pere

[pser1]

If you run xroar with the -trace option, it'll print every instruction it executes to stdout. You can redirect that to a file and then search through it afterwards. (You can turn tracing on and off at runtime too, but disk space is plentiful these days...)
If it's not obvious from the trace, you might also be able to use xroar's GDB watchpoint support to catch it writing to screen memory...

Hello,
I have tried to read a bit about the trace options and have not been able to get a file created on the PC hard disk with asm sentences executed by the GDB ... I must admit that I have never used that GDB command, so, if it were possible, I would appreciate an example of use to apply to this OS9L2 boot procedure
Thanks a bunch!!
pere