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 ...
OS-9 Level 2 for (updated) Dragons
Re: OS-9 Level 2 for (updated) Dragons
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
That last call to the OS9 function I$Write is processed calling the SWI2 that executes this code
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
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
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 8AThat 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 :-(
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?
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
Re: OS-9 Level 2 for (updated) Dragons
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
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
Re: OS-9 Level 2 for (updated) Dragons
Hi,
I have done more than 25 debug sessions writting down every executed opcode (on more than 20 A5 sheets) so that I can repeat the same procedure
as many times as I'd need. But the result (on XRoar emulating the iMMUnity module on a D64) is simply frustrating.
I know that somewhere along the boot code the system sets PM4, clears the screen RAM and prints something, but the result is garbage at the
bottom of the screen.
Trying to discover the code that does this, I am repeating the debug procedure skipping blocks untill the garbage appears on screen.
Then again but tracing step by step before it goes wild ...
But, I have found out that XRoar doesn't upadte the screen on every executed opcode, instead it does when some conditions are met.
I don't know what does control this updates, but the result is that the garbage on the screen does appear at different moments along the
procedure I am repeating, so I get fooled
Just to begin with something, there is a part of code that gets value $35 to set the SAM registers that define the graphic screen offset.
$35 = 53 decimal means 53x512= 2713 6 or $6A00
Looking at the values in the range $ffa0-ffaf I can see:
$FFA0: 003E 3E3E 0301 023F 3839 3A3B 3C3D 3E3F
I don't know where to look to check the values for the graphic screen 'actual' data.
$6A00 should be tied to slot 3 (mapped to $3E) but this will only 'see' from $6A00 to $7FFF
PMode4 uses 6,144 bytes ($1800) that should use from $6A00 till $6A00+17FF = $81FF and this will need also slot 4 (mapped to $03)
But from $8000 on there is data different than $FF (white colour). I don't know if this is just bad calculated data or simply a problem
due to the fact that we are using data for graphics that goes beyond $7FFF ...
I would really apreciate ideas/hints to clarify this obscure situation!
thanks a lot beforehand
pere
I have done more than 25 debug sessions writting down every executed opcode (on more than 20 A5 sheets) so that I can repeat the same procedure
as many times as I'd need. But the result (on XRoar emulating the iMMUnity module on a D64) is simply frustrating.
I know that somewhere along the boot code the system sets PM4, clears the screen RAM and prints something, but the result is garbage at the
bottom of the screen.
Trying to discover the code that does this, I am repeating the debug procedure skipping blocks untill the garbage appears on screen.
Then again but tracing step by step before it goes wild ...
But, I have found out that XRoar doesn't upadte the screen on every executed opcode, instead it does when some conditions are met.
I don't know what does control this updates, but the result is that the garbage on the screen does appear at different moments along the
procedure I am repeating, so I get fooled
Just to begin with something, there is a part of code that gets value $35 to set the SAM registers that define the graphic screen offset.
$35 = 53 decimal means 53x512= 2713 6 or $6A00
Looking at the values in the range $ffa0-ffaf I can see:
$FFA0: 003E 3E3E 0301 023F 3839 3A3B 3C3D 3E3F
I don't know where to look to check the values for the graphic screen 'actual' data.
$6A00 should be tied to slot 3 (mapped to $3E) but this will only 'see' from $6A00 to $7FFF
PMode4 uses 6,144 bytes ($1800) that should use from $6A00 till $6A00+17FF = $81FF and this will need also slot 4 (mapped to $03)
But from $8000 on there is data different than $FF (white colour). I don't know if this is just bad calculated data or simply a problem
due to the fact that we are using data for graphics that goes beyond $7FFF ...
I would really apreciate ideas/hints to clarify this obscure situation!
thanks a lot beforehand
pere
Re: OS-9 Level 2 for (updated) Dragons
Hello,
forgetting about the garbage on the screen, I have been debugging past that point waiting to arrive at some part that
wants to print text on screen.
After quite a lot of sessions I have arrived at a point where the code loops froever.
This hapens inside module 'SCF' between code at $DE77 and $DEDD
I think I saw the code reading the very first char of the welcome string, that is a space and then after some calculations it gets data from
a table that should contain the chars definition. Not sure about that point because I don't know the procedure used to fit 40 chars
on a sequence of just 32 bytes. It should be 6 pixels per char, but the table seems to have four bytes per each character ...
It would help a bit if we could have the commented source code for modules like:
- 'CC3Go', 'Term', 'IOMan', 'Kbvdio' and 'SCF' because they all are involved in the present case.
I am attaching here the very last version of the unassembled modules that I am using along the debug procedure ...
cheers!
pere
forgetting about the garbage on the screen, I have been debugging past that point waiting to arrive at some part that
wants to print text on screen.
After quite a lot of sessions I have arrived at a point where the code loops froever.
This hapens inside module 'SCF' between code at $DE77 and $DEDD
I think I saw the code reading the very first char of the welcome string, that is a space and then after some calculations it gets data from
a table that should contain the chars definition. Not sure about that point because I don't know the procedure used to fit 40 chars
on a sequence of just 32 bytes. It should be 6 pixels per char, but the table seems to have four bytes per each character ...
It would help a bit if we could have the commented source code for modules like:
- 'CC3Go', 'Term', 'IOMan', 'Kbvdio' and 'SCF' because they all are involved in the present case.
I am attaching here the very last version of the unassembled modules that I am using along the debug procedure ...
cheers!
pere
- Attachments
-
- Source Files.zip
- (175.41 KiB) Downloaded 4 times
Re: OS-9 Level 2 for (updated) Dragons
Hello,
I am stuck. The program enters an andless loop and I am still trying to find out the range of RAM memory used for the graphics (PMode 4)
;-----------------------------------------------------------------------
Tracing the execution, on the module 'Kbvdio' we can see this code that asks the system for ram to be used for video (6,144 bytes)
;-----------------------------------------------------------------------
Apparently the system function F$SRqMem has returned $8A00 as the beginning of the requested amount of RAM
Later this module sets PMode4 in the SAM registers and then calls a subroutine added by Bob Hall that does some calculations to obtain the parameters needed by the subroutine that sets the SAM registers that control the offset of the beginning of the graphic RAM (ZE28E)
This is the code
;-----------------------------------------------------------------------
; arrives here with regD=8A00 regX=FFC6 regY=A280 regU=A300 regS=7A1
;-----------------------------------------------------------------------
Looking at the data in the table at $0640, we found:
$0640: 0000 333e 333e 333e 0003 0001 0002 003f
and in the MMU registers:
$FFA0: 003e 3e3e 0301 023f 3839 3a3b 3c3d 3e3f
The calculated value ($35) will set the video RAM beginning in slot3 that uses addresses $6000-$7FFF
But the system had returned a pointer to $8A00 and this value will be pointing to slot 4 that uses $8000-$9FFF
Could anyone tell me what is correct here?
Out of curiosity, I have debugged it again and have changed the calculated value $35 to $45 befaore calling Bob's subroutine ...
The system keeps hanging in that case too
cheers!
pere
I am stuck. The program enters an andless loop and I am still trying to find out the range of RAM memory used for the graphics (PMode 4)
;-----------------------------------------------------------------------
Tracing the execution, on the module 'Kbvdio' we can see this code that asks the system for ram to be used for video (6,144 bytes)
Code: Select all
LDD #$1900 ; asks for $1900 bytes
OS9 F$SRqMem ;
; returns regD=allocated amount
; and regU=allocated RAM beginning
TFR U,D ; passes $8a00 to regD
BCS ZE02A ; no
TFR A,B ; regD=8a8a
BITA #$01 ; not set
BEQ ZDFDB ; jump
ADDA #$01 ;
BRA ZDFDE ;
ZDFDB ADDD #$0018 ; D=8aa2
ZDFDE PSHS A ; save regA
TFR B,A ; regA=a2
CLRB ; zero low byte
TFR D,U ; copy D to pointer U
; $a200 is final of allocated RAM
LDD #$0100 ; bytes to return ...
OS9 F$SRtMem ;
PULS A ; = $8A
BCS ZE02A ; no
CLRB ; regD = $8A00
LDU ,S ; = $A300
STD $1D,U ; save address into tableApparently the system function F$SRqMem has returned $8A00 as the beginning of the requested amount of RAM
Later this module sets PMode4 in the SAM registers and then calls a subroutine added by Bob Hall that does some calculations to obtain the parameters needed by the subroutine that sets the SAM registers that control the offset of the beginning of the graphic RAM (ZE28E)
This is the code
;-----------------------------------------------------------------------
; arrives here with regD=8A00 regX=FFC6 regY=A280 regU=A300 regS=7A1
Code: Select all
ZE86B TFR A,B ; copy high byte to regB
ANDB #$1F ; mask lower 5 bits = $0A
PSHS B ; save onto stack
ANDA #$E0 ; mask 3 high bits = $80
LSRA ; pass
LSRA ; to
LSRA ; low nibble
LSRA ; (divide by 16) = $08
NOP ; do nothing
; get system DAT image pointer
LDX <$4C ; get pointer = $0640
LEAX A,X ; add offset = $0648
LDA $01,X ; get byte = $03
STA $FFE0 ; save here (for what purpose?)
BITA #$08 ; check bit 3
BEQ ZE888 ; if zero, skip next (jump)
STA $FF80 ; save here (why?)
ZE888 ASLA ; move
ASLA ; three
ASLA ; lower bits
ASLA ; five
ASLA ; bits up (left) = $60
NOP ; do nothing
ORA ,S+ ; add byte from stack = $6A
LSRA ; divide by two = $35
; shouldn't this be $45 to point to received address $8A00?
LDX #$FFC6 ; point to SAM registers
LDB #$07 ; number of regsters to set/reset
RTS ; returnLooking at the data in the table at $0640, we found:
$0640: 0000 333e 333e 333e 0003 0001 0002 003f
and in the MMU registers:
$FFA0: 003e 3e3e 0301 023f 3839 3a3b 3c3d 3e3f
The calculated value ($35) will set the video RAM beginning in slot3 that uses addresses $6000-$7FFF
But the system had returned a pointer to $8A00 and this value will be pointing to slot 4 that uses $8000-$9FFF
Could anyone tell me what is correct here?
Out of curiosity, I have debugged it again and have changed the calculated value $35 to $45 befaore calling Bob's subroutine ...
The system keeps hanging in that case too
cheers!
pere
Re: OS-9 Level 2 for (updated) Dragons
Hello,
let me talk one more time about the graphics memory (for PMode4)
In the module Kbvdio there is a call to the OS9 function F$SRqMem that asks for $1900 bytes
Next image shows the values of the MMU registers before and after that call.
Clearly slot 4 that had value $3e (unsed) before the call, has now value 03
so this slot has been used to map the requested memory.
Tracing the code we know it begins at $8A00 and ends at $A1FF (6,144 bytes)
Later the program calls a subroutine added by Bob Hall that calculates the
value to be used to set/reset the SAM registers that control the beginning
of the graphics RAM. That SBR calculates value $35 but this would be pointing
to $35 x $200 = $6A00 but this would be wrong ...
I change that byte to $45 so that $45 x $200 = $8A00 as desired
Tracing the code after that, once the screen shows totally white colour
we can see that the RAM has value $FF (white) from $8A00 till $A1FF as shown in next images
Then I have entered a small piece of code that puts zero into all
of the bytes of the reserved graphics RAM (colour black). See image below
Executing that code with a breakpoint at the RTS opcode, there is no change
in the screen, it keeps being colour white
Examining the RAM from $8A00 to $A1FF shows us that all of the bytes have been
changed from $FF to $00 despite the effect is not shown on screen
I have executed that code one more time, but no change at all on screen!
So, right now I don't know what's wrong with that.
Any idea to justify that behaviour?
cheers!
pere
let me talk one more time about the graphics memory (for PMode4)
In the module Kbvdio there is a call to the OS9 function F$SRqMem that asks for $1900 bytes
Next image shows the values of the MMU registers before and after that call.
Clearly slot 4 that had value $3e (unsed) before the call, has now value 03
so this slot has been used to map the requested memory.
Tracing the code we know it begins at $8A00 and ends at $A1FF (6,144 bytes)
- 00-Before and after requesting memory for graphics.jpg (17.32 KiB) Viewed 208 times
value to be used to set/reset the SAM registers that control the beginning
of the graphics RAM. That SBR calculates value $35 but this would be pointing
to $35 x $200 = $6A00 but this would be wrong ...
I change that byte to $45 so that $45 x $200 = $8A00 as desired
Tracing the code after that, once the screen shows totally white colour
we can see that the RAM has value $FF (white) from $8A00 till $A1FF as shown in next images
- 01-After changing SAM registers value from 35h to 45h. Memory white colour from 8A00 on.jpg (34.55 KiB) Viewed 208 times
- 02-End of graphics clearly white colour till A200.jpg (34.72 KiB) Viewed 208 times
of the bytes of the reserved graphics RAM (colour black). See image below
- 03-Code entered in an unused area of Kbvdio. Pokeing zeros at the whole graphic area.jpg (51.85 KiB) Viewed 208 times
in the screen, it keeps being colour white
- 04-After executing the code, nothing has changed on screen.jpg (36.45 KiB) Viewed 208 times
changed from $FF to $00 despite the effect is not shown on screen
- 05-But examinig ram from 8A00 it has changed from FF to 00 but changes NOT reflected on screen.jpg (30.39 KiB) Viewed 208 times
So, right now I don't know what's wrong with that.
Any idea to justify that behaviour?
cheers!
pere
Re: OS-9 Level 2 for (updated) Dragons
Hello,
I have traced the OS9 function F$SRqMem to verify every step it does. It is using three system tables:
- from $200 to $240 each byte represents a chunk of 8Kb of physical RAM. By now it just controls up to 512Kb (64 bytes x 8Kb = 512Kb)
- from $640 t0 $64F (and $650-$65F) each word identifies the use of each MMU slot (value $333e indicates NOT in use)
- from $900 to $9FF each byte corresponds to a block of 256 bytes of logical RAM, every slot has 32 bytes (32 x 256bytes = 8,192 btes)
Value zero indicates unused
The boot procedure asks the system to allocate $1900 bytes for PMode4
I cannot get the idea behind that number. We really need 6,144 bytes = $1800
The search procedure is really a bit convoluted. The tables contents before the call are like that:
The OS9 function 'decides' to allocate $1900 bytes in a single block that begins at $8A00 and ends at $A2FF.
This seems strange to me because for an amount lower than 8K, it will need two MMU slots enabled.
Slot 4 uses $8000-$9FFF and slot 5 is needed to access from $A000-$A2FF
You can see the tables after the memory allocation
Once received the pointer to the beginning of the allocated area, it returns $100 (not needed) to the system.
And now, I asume that, just to avoid changing the pointer to the beginning, the OS9 function F$SRtMem decides to deallocate
the last allocated block of 256 bytes. That one will stay 'orphan' between the other that have been allocated
And finally, the MMU registers are updated
Once verified that behaviour, we need to change Bob's subroutine that calculates the values needed to set/reset the SAM registers
that control the beginning of the graphics RAM. The code there calculates value $35 but we need $45 because graphics beginning
is coded in steps of 512 bytes
$8a00 / $200 = $45
I will try to modify that SBR, compile the module again and then use the OS9 command VERIFY to correct the final CRC in Kbvdio.asm
This change has to be 'added' to OS9Boot, so I will have to execute one more time the OS9Gen command with the 'modified' module
cheers!
pere
I have traced the OS9 function F$SRqMem to verify every step it does. It is using three system tables:
- from $200 to $240 each byte represents a chunk of 8Kb of physical RAM. By now it just controls up to 512Kb (64 bytes x 8Kb = 512Kb)
- from $640 t0 $64F (and $650-$65F) each word identifies the use of each MMU slot (value $333e indicates NOT in use)
- from $900 to $9FF each byte corresponds to a block of 256 bytes of logical RAM, every slot has 32 bytes (32 x 256bytes = 8,192 btes)
Value zero indicates unused
The boot procedure asks the system to allocate $1900 bytes for PMode4
I cannot get the idea behind that number. We really need 6,144 bytes = $1800
The search procedure is really a bit convoluted. The tables contents before the call are like that:
- 01-200-Table of physical 8k pages (by now 512k (200-240 only).jpg (13.94 KiB) Viewed 164 times
- 02-640-Table MMU mapped slots (1 byte each entry) Before asking for $1900.jpg (8.31 KiB) Viewed 164 times
- 03-900-Table 32 sectors x MMU slot. Used slots 0-5-6-7 Before asking for $1900.jpg (54.54 KiB) Viewed 164 times
This seems strange to me because for an amount lower than 8K, it will need two MMU slots enabled.
Slot 4 uses $8000-$9FFF and slot 5 is needed to access from $A000-$A2FF
You can see the tables after the memory allocation
- 04-200-Table of physical pages after the call.jpg (14.19 KiB) Viewed 164 times
- 05-640-Table MMU after the call.jpg (8.25 KiB) Viewed 164 times
- 06-900-Table 32 sectors x MMU slot after the call.jpg (50.99 KiB) Viewed 164 times
And now, I asume that, just to avoid changing the pointer to the beginning, the OS9 function F$SRtMem decides to deallocate
the last allocated block of 256 bytes. That one will stay 'orphan' between the other that have been allocated
- 07-900-Table after returning 1 sector (256 bytes).jpg (53.63 KiB) Viewed 164 times
- 08-Later MMU registers get updated.jpg (4.82 KiB) Viewed 164 times
that control the beginning of the graphics RAM. The code there calculates value $35 but we need $45 because graphics beginning
is coded in steps of 512 bytes
$8a00 / $200 = $45
I will try to modify that SBR, compile the module again and then use the OS9 command VERIFY to correct the final CRC in Kbvdio.asm
This change has to be 'added' to OS9Boot, so I will have to execute one more time the OS9Gen command with the 'modified' module
cheers!
pere
Re: OS-9 Level 2 for (updated) Dragons
Hi,
the code tests for the address returned by the OS9 function and in case it were odd, then it adds 1 to the high byte so that it will
begin in an address multiple of 512. In this case, the 256 bytes returned to the system are the 'skipped' by this increment
If the address were even, then adds $1800 to point to the very last group of 256 bytes that has been allocated and passes
that address when returning those 256 bytes
So all of that code works correctly.
I have already modified Bob's subroutine so that it calculates the correct value ($45) when it receives $8a
In fact a simple divide by two (shift right) does the trick
After compiling and verifying the new code I have substituted it in the OS9L2 disk used to apply OS9Gen
Now I have another version of our OS9L2 disk (184Kb) and using it instead the old one works as did the old one.
Anyway, the code that should write to screen keeps entering an endless loop
This needs yet another debug session ...
pere
the code tests for the address returned by the OS9 function and in case it were odd, then it adds 1 to the high byte so that it will
begin in an address multiple of 512. In this case, the 256 bytes returned to the system are the 'skipped' by this increment
If the address were even, then adds $1800 to point to the very last group of 256 bytes that has been allocated and passes
that address when returning those 256 bytes
So all of that code works correctly.
I have already modified Bob's subroutine so that it calculates the correct value ($45) when it receives $8a
In fact a simple divide by two (shift right) does the trick
After compiling and verifying the new code I have substituted it in the OS9L2 disk used to apply OS9Gen
Now I have another version of our OS9L2 disk (184Kb) and using it instead the old one works as did the old one.
Anyway, the code that should write to screen keeps entering an endless loop
This needs yet another debug session ...
pere
-
lcurtisboyle
- Posts: 33
- Joined: Thu Nov 05, 2020 9:47 pm
Re: OS-9 Level 2 for (updated) Dragons
Sorry I have been away for a couple of weeks and couldn't respond during that time. The SAM/VDG can only allocate graphics on 512 byte ($200) boundaries, but OS9 by default allocates 256 byte pages. So doing a F$SRqMem for $1800 bytes can start on a non-512 byte boundary. Allocating an extra 256 bytes means we can choose the first or last $1800 bytes returned, thus ensuring we can start on a SAM/VDG allowable boundary.
OS9P1 will be called from all interrupts (software system calls or hardware); it routes through to the dispatch tables for system calls (and allows user overrides to replace stock system ones as well). If the high bit is set on the system call number (>=$80), it knows that it is an I/O call and thus calls IOMan (I/O Manager). IOMan will take a look at the device descriptor to determine which type of I/O call hardware is being called (SCF or RBF at the very least) and then call the appropriate file manager to perform the system call. In this case, it will be SCF since it handle screens amongst other things. SCF will then do some processing itself (looking for special control characters and the like), and then calls the appropriate driver (whose name is in the device descriptor - /term in this case) which does the low level drawing, etc. In some cases this will be the special Coco / Dragon drivers (like CC3IO) which can call further submodules (WindInt/Grfdrv is a good example on the Coco 3), depending on the type of read/write call. In the case of I$Write or I$WritLn on a screen, and using the original SCF, it does by going through the string being written one character at a time: it does all the pre-processing for special characters (CTRL-W to pause screen output, as one example), and then passes the single character to write to CC3IO, which does the actual write, updates the cursor position, scrolls the screen if necessary, etc.). It then returns to SCF to handle the next character until the string is done (not going to mention task switching here where it can bounce between different screens/output devices as clock interrupts come in).
In NitrOS9, SCF pre-scans up to 32 or 64 characters in the string being written until it hits the end of the string or a control character (character codes $00-$1f). If it has multiple non-control characters, it then passes the pointer to them (and the length of the non-control characters found) to the screen driver and writes it in one fell swoop, which is much faster then going through SCF -> CC3IO -> WindInt -> Grfdrv for every single character.
Eventually I would like to make the buffered writes more generic (and add buffered reads as well) via bit settings in the SCF descriptors so that they work with more than just Windint related devices; they could work in Coco 1/2 modes as well, and even other SCF devices like modems, etc.
OS9P1 will be called from all interrupts (software system calls or hardware); it routes through to the dispatch tables for system calls (and allows user overrides to replace stock system ones as well). If the high bit is set on the system call number (>=$80), it knows that it is an I/O call and thus calls IOMan (I/O Manager). IOMan will take a look at the device descriptor to determine which type of I/O call hardware is being called (SCF or RBF at the very least) and then call the appropriate file manager to perform the system call. In this case, it will be SCF since it handle screens amongst other things. SCF will then do some processing itself (looking for special control characters and the like), and then calls the appropriate driver (whose name is in the device descriptor - /term in this case) which does the low level drawing, etc. In some cases this will be the special Coco / Dragon drivers (like CC3IO) which can call further submodules (WindInt/Grfdrv is a good example on the Coco 3), depending on the type of read/write call. In the case of I$Write or I$WritLn on a screen, and using the original SCF, it does by going through the string being written one character at a time: it does all the pre-processing for special characters (CTRL-W to pause screen output, as one example), and then passes the single character to write to CC3IO, which does the actual write, updates the cursor position, scrolls the screen if necessary, etc.). It then returns to SCF to handle the next character until the string is done (not going to mention task switching here where it can bounce between different screens/output devices as clock interrupts come in).
In NitrOS9, SCF pre-scans up to 32 or 64 characters in the string being written until it hits the end of the string or a control character (character codes $00-$1f). If it has multiple non-control characters, it then passes the pointer to them (and the length of the non-control characters found) to the screen driver and writes it in one fell swoop, which is much faster then going through SCF -> CC3IO -> WindInt -> Grfdrv for every single character.
Eventually I would like to make the buffered writes more generic (and add buffered reads as well) via bit settings in the SCF descriptors so that they work with more than just Windint related devices; they could work in Coco 1/2 modes as well, and even other SCF devices like modems, etc.