OS-9 Level 2 for (updated) Dragons

[pser1]

Hello,
I attach here the basic program that loads the fles, patches them and finally starts REL (exec&H2602)
I include a DOS disk ("F1 - step4 with BOOT6 and L2BOOT and CCSWITCH.VDK")that can be loaded in XRoar in drive 2
and another disk ("F2 - step6 with OS9BOOT and folders.DSK") for drive1 that will be called when boot process succeeds.
Then RUN"2:CCSW52" will require a keypress and then it will STOP to give you time to set a breakpoint in GDB or any other debugger.

Debug.ZIP

(236.2 KiB) Downloaded 1 time

Points of interest for debugging ...
- F013 the beginning of OS9P1
- F109 the code block that calculates present RAM
- F132 the exit after that calculations
- F5D8 the point where it loops while counter in stack is not zero
- F5CE point when low byte of counter is zero
- F5D3 the call to OS9 function Sleep
See a screen of the debugging session just before calling OS9 Function
In the lower GDB window you can see the contents of these addresses (groups of 16 bytes)
- $FF90, - $FFA0, - $FFF0 - $FEEE and - $0100
You see that $FFF0-FFFF have the values poked by the basic program, but the $FEEE range is not initialized and same for range $0100-$010F
No chance for the SWI2 to find the correct code

Debug1536.jpg (80.29 KiB) Viewed 103 times

cheers!
pere

[pser1]

Hi,
I have debugged the boot sequence of CoCo3 with Tandy OS9Level2 and using almost the same code we use for the Dragon (REL and OS9P1 have a few patches only) arriving at the point previous to the call of the OS9 function, I have found these values in the secondary vectors:
- FEEE lbra $FEA4
- FEF1 lbra $FEAA
- FEF4 lbra $FEB0
- FEF7 lbra $FEB4
- FEFA lbra $FECE
- FEFD lbra $FED2
and of course, the area from FEA4 on contains perfect code that I cannot see when debugging our Dragon version
So, I need to debug again CoCo3 and try to find the point in wich the area $FEA4- is filled with the ISR code
cheers!
pere

[pser1]

Hello,
there is a bit of hope. I have found a big error!
While creating/extracting the boot track from the Tandy disk, I am afraid that my basic program simply stops one sector before the end
And this last (lost) sector contains both the secondary vectors and the ISR code (
Hopefully once corrected this very initial step we would be able to advance a bit more!
cheers!
pere

[pser1]

Hi,
debugging the CoCo3 load of OS9L2 and getting a bit further past the point where an OS9 function is called ($f5ce) I could see
that the boot sequence reads drive 1 from sectors 0 to 3, but when I do the same on the Dragonized version, the numbers are
absolutely mad. It shows drive 1 tracks up to 231 and later shows Track 199
I think that this behaviour might be the result of using a disk 368K instead of the single side 184Kb
It all should depend on the device descriptor and the device driver, I asume
In our case we are using D0 and Ddisk
D0 points to RBF and Ddisk so this seems consistent, but it contents a table of 15 parameters that are loaded somewhere
I don't know what each value means, but these bytes seem to be physical description of the disk (tracks, sectors maybe?)
These are the bytes including the first one that shows the table length

Code: Select all

        FCB     $0F       ; iniTable size*0011: 0F
        FCB     $01              	 *0012: 01
        FCB     $00              	 *0013: 00
        FCB     $00              	 *0014: 00
        FCB     $20,$01                  *0015: 20 01
        FCB     $00              	 *0017: 00
        FCB     $28,$01                  *0018: 28 01
        FCB     $00,$00                  *001A: 00 00
        FCB     $12              	 *001C: 12
        FCB     $00              	 *001D: 00
        FCB     $12              	 *001E: 12
        FCB     $02              	 *001F: 02
        FCB     $08              	 *0020: 08

The Ddisk file contains all of the functions that can be called ...
I attach here the asm files for D0 and Ddisk for someone could tell us if these files would work with a physical drive
double side (368 Kb)
cheers!
pere

D0P.zip

(797 Bytes) Downloaded 2 times

DdiskP.zip

(5.51 KiB) Downloaded 1 time

[pser1]

just a reflexion about what I have said in previous message.
OS9 boot track has been loaded by DOS file "L2BOOT.BIN", then it's module 'BOOT' has been overwritten by DOS file "BOOT6.BIN"
Then REL is called (EXEC&H2602) and after a lot of code, it seems to access tracks 0-1-2-3 in the CoCo3 case.
But if all of the device descriptors and other modules that we have copied or patched are inside a file named "OS9Boot"
that exists in drive 1 in disk named "F1 ..."
How could we read any disk if we have not yet in memory the OS9Boot files?
And how would we read the OS9Boot files without the descriptors, devices (D0,Ddisk)?
It seems that there must be a way to load that special file OS9Boot from drive 1 without using DOS nor OS9
but some previously loaded subroutine that might exist in the 'BOOT' module perhaps?
I would appreciate any enlightment on this situation!
thanks in advance
pere

[pser1]

Looking at the unassembled file for BOOT module (from DragonData OS9L1 v1.2) once patched, I can see a point that has been patched in Bob's articles
to call an OS9 function already in high memory (offset $70 from the beginning)
OS9 F$BtMem ; commented as I$Read by Claude.ia
This is a call to read chunks of data from disk so this is the next point to be debugged!
I attach here the patched file BOOT.ASM for anyone who wants to give it a peek
cheers!
pere

bootP.zip

(3.33 KiB) Downloaded 1 time

[pser1]

well, it seems that there are 8 calls to SWI2 (OS9 functions) in module OS9P1, so I will have to debug there untill the program
reaches any of those calls to discover the reason why it tries to read track numbers greater than 40
The Boot module will have to wait untill it is called
cheers!
pere

[pser1]

Hello,
I just found another stupid error ...
I was loading BOOT6.BIN @$3430 instead of the correct place $2730. Something went wrong when I added the dragon header to the OS9 binary file
Once corrected, the program works for a while and then writes the word FAILED below the OS9 BOOT message
This happens because the call to OS9 F$BOOT returns with carry set because it did not work

As there have been some changes, I am uploading the two disks: "F2 - OS9L2.dsk" to be put into drive 1 and "F1 - starter.VDK" to go into drive 2
To test it you just have to issue:
RUN"2:CSSW52"
When it waits for a user input just press enter, then the basic will stop
At this point you should add some breakpoint(s) to GDB or your debugger, I use to add hbreak *0xf5ce that stops just before calling
a OS9 system function and then ... happy debugging!
In the zip file you will find besides the two discs the source code for the modules REL, OS9P1
I have already included the descriptor file INIT that points to some modules that 'maybe' we have not added to the OS9Boot
file when it was generated by OS9Gen
cheers!

Testing OS9L2.ZIP

(187.29 KiB) Downloaded 2 times

OS9Boot failed.jpg (13.83 KiB) Viewed 59 times

[pser1]

Hi,
as the unassembled code for module OS9P1, created with F9DASM is absolutely impossible for me to understand,
I have searched for source code and found "OS-9 Level 2 V1.2".
I downloaded Kernel Part 1 and Kernel Part 2. Both, fortunately, very well documented and plenty of comments
I am slowly copying those comments to the same code part in our OS9P1.ASM
Unfortunately there are differences between what we have and the downloaded Kernel, but I expect to have most of the
subroutines documented in a couple of days.
Sincerely debugging the boot procedure without knowing what the code is doing is really frustrating

We know for sure that something goes wrong along the execution of the OS9 Boot function, but that code goes through hundreds of subroutines
and we need to know which one does set the carry flag to discover what is causing that error!
have a nice weekend!!
pere