4.1 DragonDOS Startup Program
The startup program (COCOSWITCH) amongst other tasks:
• Sets up the MMU registers.
• Loads in the 3 Tandy modules REL, OS9P1 and BOOT from a .BIN file ("L2BOOT").
• Overlays the Tandy BOOT file (designed for the Tandy disk controller) with one ("BOOT6") designed for the Dragon DD controller.
• Patches REL.
• Disables interrupts, enables the MMU.
• Sets up the new interrupt vectors, pointing into the 'reserved common RAM', and then executes REL.
The contents of L2BOOT are taken from the bootstrap track on the Tandy Level Two disk.
A BASIC routine (L2STEAL) reads the 18 sectors of track 34 into memory. To do this work, I have used a clean DOS disk (W1) that ended containing
- L2STEAL.BAS and L2BOOT.BIN
Code: Select all
0 'L2STEAL
10 CLS:PCLEAR1:CLEAR1000:DIMB$(128):DIMA$(128):D=&H264:E=9728
20 I=INT(D/18):J=D-18*I+1:SREAD 2,I,J,A$,B$
30 FA=VARPTR(A$)+2:AD=256*PEEK(FA)+PEEK(FA+1):FOR CT=1TO128:POKEE,PEEK(AD):E=E+1:AD=AD+1:NEXT CT
40 FB=VARPTR(B$)+2:BD=256*PEEK(FB)+PEEK(FB+1):FOR CT=1TO128:POKEE,PEEK(BD):E=E+1:BD=BD+1:NEXT CT
50 D=D+1:ZZ=FRE$:PRINTI;J;ZZ::'INPUT TE$
55 IF J<17 GOTO20
70 SAVE"L2BOOT",&H2600,&H3800,&H2602But &H3900-&H2600 = $1300 and this exceeds the track length ($1200). So, I have reduced one sector so that it fits inside 4,608 bytes
The binary file I have saved into W1 has been copied into disk F1 too.
Now we have the Level 2 boot modules in disk F2 and the Tandy boot and the Dragonized one in disk F1 ; -----------------------------------------------------------------------------------------------------------
It is time to put thinks together and create a basic program that will be the starting piece
COCOSWITCH — DragonDOS Startup Program
Written by Bob:
Optional lines 10–40 (load BASIC ROM into RAM) are only needed if using a design without a 6116.
Running 256k with OS9LII also needs a patch to the startup routine in OS9P1 which as supplied by Tandy only expects 128k or 512k machines
Lines 110–120 are the 256k OS9P1 patch — omit for 128k or 512k versions.
I have saved this program into disk F1 as "CCSWITCH.BAS" because DOS only supports 8 char names
When the program has loaded both files, it will be waiting for the user to press a key (line 70)
Remember to do that only after changing the F1 disk in drive #1 for the OS9L2 we have prepared (F2)
Code: Select all
0 ' COCOSWITCH
10 REM DATA 34,7F,1A,50,8E,80,00
20 REM DATA B7,FF,DE,A6,84,B7,FF,DF,A7,80
30 REM DATA 8C,F0,00,2F,F1,B7,FF,DF,35,FF
40 REM BA=&H200:FOR I=BA TO BA+26:READ V$: V=VAL("&H"+V$):POKE I,V:NEXT I: EXEC BA
50 PCLEAR 1
60 FOR I=0 TO 7: POKE&HFFA0+I,(&HF8+I):POKE&HFFA8+I,(&HF8+I): NEXT
70 LOAD"L2BOOT.BIN":LOAD"BOOT6.BIN":PRINT"READY TO RUN":INPUT J
80 POKE&HFF03,&H34:POKE&HFF90,0
85 REM THIS PATCHES REL MODULE
90 POKE&H2682,&HDF:POKE&H2631,0:POKE&H26E0,&H48
100 POKE&H272D,&H94:POKE&H272E,&HA9:POKE&H272F,&H55:REM THESE ARE CRC
105 REM PATCH FOR 256K OF RAM - NOT FOR 1-2M
110 REM POKE&H2A20,&H0F:POKE&H2A3B,&H1F
120 REM POKE&H37D6,&H9D:POKE&H37D7,&H5D:POKE&H37D8,&H96:REM THESE ARE CRC
130 POKE&HFFA2,&HFF:FOR I=0 TO 7:POKE(&H5FF0+I+I),&HFE:NEXT
140 POKE&H5FF3,&HEE:POKE&H5FF5,&HF1:POKE&H5FF7,&HF4
150 POKE&H5FF9,&HF7:POKE&H5FFB,&HFA:POKE&H5FFD,&HFD
160 POKE&H5FFE,&H26:POKE&H5FFF,02
170 POKE&HFFA2,&HFA:POKE&HFF48,0:EXEC&H2602Some points before attempting to make the very first test running CCSWITCH ...
The OS9L2 disk (F2) that contains the OS9 modules, needs some changes for sure
I have not yet added 'acia51.new' from Eurohard OS9L1 and probably I should update
after applying more patches the already present modules OS9P1 and clock.50hz
1) Bob Hall patches the module OS9P1 from CCSSWITCH.BAS but only for the case of 256K RAM
Well, we will be using modules that have 1Mb-2Mb so we should have a peek at that module in order to find a way to ensure that all RAM
will be detected/used by OS9P1. We need to modify the patch to that module that is loaded into RAM @ $28FA(10,490)
so lines 110-120 should be modified.
I have been working on that module (from Tandy OS9Level2) adding some comments, most of
them coming from NitrOS-9 Level 2 documentation and variable names coming from os9defs-l2v3 I have seen too many differences between the two systems, so I have extracted the code
used in NitrOS-9L2 to calculate the present RAM. I attach it here I don't get how Tandy L2 OS9P1 module does the calculations, so maybe someone could give
us some ideas to understand the way it does. help! help! help!
One possible alternative could be deleting all that code and substituting it with the
code from NitrOS-9L2 kernel module shown in file 'CalculateRAM.asm'
2) I have extracted the REL module too, I have unassembled it and then applied the patches that we see in CCSWITCH Basic program in lines 90-100 just to see what these changes do.
REL sends the initial values to the GIMME registers and I found that $FF98 is set to zero, that means that clock rate will be 60Hz.
According to CC3 docs it should be $08 to force the clock to work at 50hz as we really want! Then I have open the clock.50hz to see if that is corrected there, but I have found something
very suspicious to me about code line 246 of the asm file
Code: Select all
lda <$98 ; get copy from direct page of register $FF98
ora #$08 ; set bit3 to work @50hz
sta <$98 ; update copy
*sta $FF98 ; WHY NOT UPDATE THE GIMME REGISTER TOO?
nop ; these three bytes overwrite previous old code
nop
nopI will really appreciate any hint/idea you'd want to share with us to clarify this situation!
Fear not to chime!!
thanks a bunch
cheers!
pere
