OS-9 Level 2 for (updated) Dragons

[pser1]

Hi Ciaran,
thanks a lot for these ideas. Will be very helpful!
Right now my debug/trace procedure gets to the point where mode is changed and screen memory is written.
The result is 'special' but tracing OS9Level1 from Eurohard does exactly the same.
Along next steps the whole screen memory is filled with $FF (white) and then an intro message should be written
Unfortunately the messages are different so I cannot relay on data from an Eurohard trace.
I suspect that the subroutine that writes text from a string to the graphics screen is not using the correct data table
that defines each character. If the selected mode were 40 chars per column, then having only 32 bytes per row
forces the writting SBR to work with six bits/pixels per char, so 40charx6bits=240 pixels. A bit less than the 256 pixels per screen row
I would like to find out where this subroutine 'lives', I mean inside what file:
IOMan, Kbvdio, SCF ... these three modules are calling each other along the mode change ... and even OS9p1 gets called!
cheers!

Ps In case anyone would want to give it a try, I am attaching here a zip containing the modules I have unassembled using the
ORG value needed to have them with the addresses they get when the big OS9Boot file is loaded into memory ...

OS9Level II source files (some).zip

(122.53 KiB) Not downloaded yet

[pser1]

Hello,
I found some strings in module CC3Go with these text
" OS-9 LEVEL TWO VR.02.00.01"
" COPYRIGHT 1986 BY"
" MICROWARE SYSTEMS CORP."
" LICENSED TO TANDY CORP."
" ALL RIGHTS RESERVED."
The first string is associated to Label ZBFE2 in the CC3Go.asm file

Looking for code that uses this label I found this

Code: Select all

        LEAX    >ZBFE2,PCR                *C0C3: 30 8D FF 1B
        LDY     #$0089                    *C0C7: 10 8E 00 89
        LDA     #$01                      *C0CB: 86 01      
        OS9 	I$Write                   *C0CD: 10 3F 8A

That last call to the OS9 function I$Write is processed calling the SWI2 that executes this code

Code: Select all

*FEF1     LBRA $FEAA
*FEAA     ORCC #$50
	  LDB  #$04
	  BRA  $FEB8
*FEB8     LDA  #$00
	  STA  $FF91
	  CLRA
	  TFR  A,DP
	  LDA  <$91
	  ANDA #$FE
	  STA  <$91
	  STA  $FF91
	  CLRA
	  TFR  D,X		; at this point we LOSE the pointer to the STRING :-(

Could anyone help understanding why should this code lose the string pointer?

And yet another point I cannot understand ...
Bob Hall suggested a patch for the module KBVDIO
He added some bytes at the end of the module that once unassembled do look like this

Code: Select all

ZE86B   TFR     A,B 
        ANDB    #$1F 
        PSHS    B       
        ANDA    #$E0 
        LSRA             
        LSRA             
        LSRA             
        LSRA             
        NOP              
        LDX     <$4C  
        LEAX    A,X    
        LDA     $01,X 
        STA     $FFE0  ; what does this?
        BITA    #$08                 
        BEQ     ZE888       
        STA     $FF80  ; what does this?

This code saves a value into memory at $FFE0 and $FF80
I cannot 'find' these addresses at any place and besides I can say
that I have not found them used later anywhere
$FF80 does not seem a GIME register and $FFE0 is out of SAM addresses

Again any pointer to clarify the use of these two addresses would be great!
cheers!
pere

[pser1]

Hello,
to my first question, the register X is saved onto the stack when SWI2 is called, so the OS9 function that should be printing
the string on the screen, could grab this value from offset 10 inside the stack ... upon other pushed values, of course.
But when I trace this OS9 call (I$Write) the sequence that I use to see with all previous OS9 calls is not the same and it seems
that some indirect addresses saved at $E0-$EF that are called from the ones at $F0-FF have been changed.
Probably the best will be to set a Watchpoint for writting to $E4-$E5 that contain the address to be called in this case.

Concerning the second question, no idea about these two strange addresses used by Bob.
cheers!
pere