167 lines
14 KiB
ArmAsm
167 lines
14 KiB
ArmAsm
; ============================================================================
|
|
; 1541 bootstrap sector (track 1 sector 17) - executed in the drive by DOS command "B-E 2 0 1 17"
|
|
; ============================================================================
|
|
; DOS loads this sector into the buffer of channel 2 and jumps to its first byte. The code finds its own
|
|
; page with a JSR/TSX trick, copies itself to buffer 3 ($0600) and continues there at $0624, so it is shown
|
|
; here at its final address. It queues three job-code reads (track 1 sectors 18,19,20 -> $0300-$05FF),
|
|
; re-initialises the drive and jumps to $0300 (the fast loader). The tail of the sector holds a 1988
|
|
; Electronic Arts message that is never displayed.
|
|
|
|
.setcpu "6502"
|
|
.include "drive1541.inc"
|
|
.include "drive_zp.inc"
|
|
|
|
; ---- references to code/data outside this file ----
|
|
D_0100 := $0100
|
|
sub_0300 := $0300
|
|
|
|
; Contents
|
|
; --------
|
|
; $0600 driveBootstrapEntry the 1541-side bootstrap, i.e.
|
|
; $0624 queueFastLoaderReads pulls the fast loader into the drive.
|
|
|
|
.org $0600
|
|
|
|
|
|
; ----------------------------------------------------------------------
|
|
; driveBootstrapEntry - the 1541-side bootstrap, i.e. the whole of track 1 sector 17, executed inside
|
|
; the drive by the DOS command 'B-E 2 0 1 17'. It first pulls the serial CLK line low as a 'drive
|
|
; busy' flag (that is what makes the C64 wait until the fast loader is up), then works out which
|
|
; buffer page DOS actually gave it - JSR to an RTS planted at $0300, then TSX / LDA $0100,X picks the
|
|
; return-address high byte off the stack - and copies its own 256-byte page to buffer 3 ($0600),
|
|
; continuing there. The move is necessary because the three sector reads it is about to queue land in
|
|
; buffers 0-2 ($0300-$05FF) and would overwrite the running code.
|
|
; In: nothing; DOS has read the sector into the buffer of channel 2 (the '#' channel the C64 opened)
|
|
; and jumped to its first byte. The page it runs from is recovered from the stack, so the code is
|
|
; fully position independent.
|
|
; Out: I flag set; VIA1 port B = $08 (CLK asserted, DATA released, ATN acknowledge off); $0300 = $60
|
|
; (RTS); $14/$15 = pointer to the page it was loaded into; $0600-$06FF = a copy of this sector.
|
|
; Execution continues at queueFastLoaderReads inside that copy.
|
|
; Called from: the 1541 DOS block-execute command only. The C64 sends the string 'B-E 2 0 1 17' from
|
|
; bootBlockExecute ($C32C in boot/fastLoaderC000) right after opening buffer channel 2 with the
|
|
; filename '#'.
|
|
; ----------------------------------------------------------------------
|
|
driveBootstrapEntry:
|
|
sei ; 0600 mask the DOS interrupt: neither the disk-controller job loop nor the serial-bus ATN handler may run while this sector relocates itself
|
|
cld ; 0601 clear decimal mode before touching job codes and pointers (defensive - DOS leaves it clear)
|
|
|
|
; ----------------------------------------------------------------------
|
|
; Take the serial bus away from DOS and hold the host off. VIA1 port B at $1800 is the serial port:
|
|
; bit 0 = DATA IN, bit 1 = DATA OUT, bit 2 = CLK IN, bit 3 = CLK OUT, bit 4 = ATNA (hardware
|
|
; acknowledge of ATN), bits 5-6 = device address jumpers, bit 7 = ATN IN. The data direction register
|
|
; is left as DOS set it ($1A = bits 1,3,4 outputs).
|
|
; ----------------------------------------------------------------------
|
|
lda #$08 ; 0602 bit 3 alone = CLK OUT on, DATA OUT off, ATN acknowledge off
|
|
sta VIA1_PRB_SERIAL ; 0604 pull the serial CLK line low (the drive's outputs are inverted, so writing 1 makes the line true) and release DATA: the C64 sits in bootExchangeByte ($C040: BIT $DD00 / BVC) waiting for CLK IN to go high again, which only happens when the fast loader starts at $0300 and writes $00 here
|
|
|
|
; ----------------------------------------------------------------------
|
|
; Find out which page this code is executing in. DOS block-execute runs the sector from whatever
|
|
; buffer channel 2 was allocated, so the address is not known at assembly time: JSR to a planted RTS
|
|
; and read back the return address the JSR left on the stack.
|
|
; ----------------------------------------------------------------------
|
|
lda #$60 ; 0607 $60 = the RTS opcode
|
|
sta sub_0300 ; 0609 plant that RTS at the first byte of buffer 0; clobbering $0300 is harmless because the track 1 sector 18 read overwrites the whole buffer moments later
|
|
jsr sub_0300 ; 060C call the planted RTS purely for the side effect: JSR pushes return address $060E, whose high byte is the page this code really lives in
|
|
tsx ; 060F X = stack pointer, which the RTS has put back to its pre-JSR value
|
|
lda D_0100,x ; 0610 $0100+X still holds the return-address high byte the RTS read but did not erase = this page number ($03, $04, $05 or $06, whichever buffer DOS handed out)
|
|
sta zp_15 ; 0613 high byte of the copy source pointer; drive zero page $14/$15 is the disk id of the non-existent drive 1 in stock DOS, so it is free scratch
|
|
ldy #$00 ; 0615 Y = 0: index over the whole 256-byte page, and also the low byte of the source pointer
|
|
sty zp_14 ; 0617 source low byte = 0 - every DOS buffer starts on a page boundary
|
|
|
|
; ----------------------------------------------------------------------
|
|
; Copy all 256 bytes of this sector (code, job table and the EA message) from the buffer DOS chose
|
|
; into buffer 3 at $0600. Y counts 0..255 and wraps to end the loop.
|
|
; ----------------------------------------------------------------------
|
|
copySelfToBuffer3Loop:
|
|
lda (zp_14),y ; 0619 read byte Y of the page we are currently executing in
|
|
sta driveBootstrapEntry,y ; 061B write it to buffer 3 ($0600); if DOS happened to allocate that very buffer the loop just copies the page onto itself, which is harmless
|
|
iny ; 061E advance to the next byte of the page
|
|
bne copySelfToBuffer3Loop ; 061F loop until Y wraps back to 0, i.e. all 256 bytes have been copied
|
|
jmp queueFastLoaderReads ; 0621 jump into the identical copy at $0624 by absolute address - from here on the code runs in buffer 3 and buffers 0-2 are free to be overwritten by the reads
|
|
|
|
|
|
; ----------------------------------------------------------------------
|
|
; queueFastLoaderReads - pulls the fast loader into the drive. It writes jobQueueInitTable over the
|
|
; DOS job queue so that buffers 0, 1 and 2 each get a 'read sector' job for track 1 sectors 18, 19 and
|
|
; 20 ($0300, $0400, $0500), enables interrupts so the disk controller executes them, waits for all
|
|
; three to finish and insists that every one reported OK. Then it re-initialises the disk (BAM and
|
|
; disk id) and jumps into the code it has just loaded.
|
|
; In: jobQueueInitTable ($0641). Must already be executing from $0600, because the three reads
|
|
; overwrite $0300-$05FF.
|
|
; Out: $0300-$05FF = the 1541 fast loader (track 1 sectors 18-20, the only game code on the disk
|
|
; stored in plaintext); drive zero page $00-$0B = job queue state ($01 in each of the three job
|
|
; bytes); $12/$13 = disk id; I flag clear. Never returns - it ends with JMP $0300.
|
|
; Called from: the JMP at $0621 (entry after the self-copy) and from its own retry branch at $0639. A
|
|
; read error re-queues the whole set forever: there is no error exit.
|
|
; Load the three pages of the fast loader. This is also the retry entry point: any failed read comes
|
|
; back here and re-issues all three jobs from scratch.
|
|
; ----------------------------------------------------------------------
|
|
queueFastLoaderReads:
|
|
ldx #$0B ; 0624 12 table bytes to copy, highest index first
|
|
|
|
; ----------------------------------------------------------------------
|
|
; Copy the job-queue image into drive zero page $00-$0B, backwards from index 11 to 0.
|
|
; ----------------------------------------------------------------------
|
|
copyJobQueueLoop:
|
|
lda jobQueueInitTable,x ; 0626 next byte of the image (indices 0-5 are job codes, 6-11 are track/sector pairs)
|
|
sta zp_00,x ; 0629 store into the DOS job queue: $00-$05 = job code for buffers 0-5, $06-$11 = the track/sector pair belonging to each buffer (only buffers 0-2 are given work here)
|
|
dex ; 062B step down one entry
|
|
bpl copyJobQueueLoop ; 062C keep copying until index 0 has been written (BPL, so all 12 bytes $0B..$00)
|
|
cli ; 062E let interrupts back in: the DOS disk controller runs from the VIA2 interrupt and only now notices the three $80 jobs, seeks to track 1 and reads the sectors
|
|
|
|
; ----------------------------------------------------------------------
|
|
; Wait for the three reads. While a job is outstanding its queue byte still holds the job code with
|
|
; bit 7 set; when the controller finishes it replaces the byte with the result code (bit 7 clear,
|
|
; $01 = OK, $02 = header not found, $05 = data checksum error, ...). ORing the three bytes therefore
|
|
; gives a negative value while anything is still pending and exactly $01 when all three succeeded.
|
|
; ----------------------------------------------------------------------
|
|
waitForReadJobsLoop:
|
|
lda zp_00 ; 062F job byte of buffer 0 (track 1 sector 18 -> $0300)
|
|
ora zp_01 ; 0631 merge the job byte of buffer 1 (track 1 sector 19 -> $0400)
|
|
ora zp_02 ; 0633 merge the job byte of buffer 2 (track 1 sector 20 -> $0500)
|
|
bmi waitForReadJobsLoop ; 0635 bit 7 still set somewhere, so at least one read is still queued or running: keep spinning
|
|
cmp #$01 ; 0637 all three have finished - the OR of three 'OK' result codes ($01) is $01, and no other combination of DOS codes can produce it
|
|
bne queueFastLoaderReads ; 0639 any error code sets extra bits, so re-queue all three reads and try again - forever. There is no error exit and no LED blink: a damaged track 1 hangs the drive here, and the C64 hangs with it because CLK is still held low
|
|
|
|
; ----------------------------------------------------------------------
|
|
; The fast loader is in place; hand the drive over to it.
|
|
; ----------------------------------------------------------------------
|
|
jsr ROM_INIT_DRIVE ; 063B DOS 'initialise drive' ($D042): re-reads the BAM of track 18 and reloads the disk id into $12/$13, which the fast loader needs both to build the expected sector header ($039D) and for its id check at $0525 - zp_12 EOR zp_13 must equal $15, which is 'O' EOR 'Z', the id of the Modem Wars disk
|
|
jmp sub_0300 ; 063E enter fastloaderMain in the code just read into buffers 0-2; its first two instructions (LDA #$00 / STA $1800) release the CLK line and so unblock the C64, which then starts requesting sectors
|
|
|
|
|
|
; jobQueueInitTable - 12-byte image of drive zero page $00-$0B, copied into the DOS job queue by
|
|
; queueFastLoaderReads. Element size 1 byte; the index is the zero-page address:
|
|
; $00-$02 = $80, the DOS 'read sector' job code, for buffers 0, 1, 2 ($0300, $0400, $0500)
|
|
; $03-$05 = $00, no job, for buffers 3, 4, 5: buffer 3 ($0600) is where this code now runs,
|
|
; buffer 4 ($0700) is the BAM buffer, and a 1541 has no buffer 5 at all
|
|
; $06-$0B = the track/sector pair of each job, two bytes per buffer: 1/18 ($01,$12) for buffer 0,
|
|
; 1/19 ($01,$13) for buffer 1, 1/20 ($01,$14) for buffer 2 - the three pages of the
|
|
; fast loader, in order.
|
|
; Because these are ordinary DOS job-code reads, track 1 sectors 18-20 are the only game code on the
|
|
; disk that cannot be XOR-encrypted; the sector cipher at $0531 is applied by the fast loader itself.
|
|
jobQueueInitTable:
|
|
.byte $80,$80,$80,$00,$00,$00 ; 0641 ...... row 0 = job codes for buffers 0-5, row 1 = the three track/sector pairs
|
|
.byte $01,$12,$01,$13,$01,$14 ; 0647 ......
|
|
|
|
; eaCopyrightMessage - 179 bytes of plain ASCII filling the rest of the sector, from $064D to the last
|
|
; byte $06FF. Ordinary ASCII with no bit-7 terminator, unlike the game's own strings, and nothing
|
|
; ever reads or prints it: like the 'DaN'/'SaRa' signature at the end of the fast loader ($05F4) it is
|
|
; a message for whoever dumps track 1. It reads:
|
|
; '(C)1988 ELECTRONIC ARTS, 1820 GATEWAY DR, SAN MATEO,CA 94404. THE AGE OF MODEM WARFARE HAS
|
|
; BEGUN. MORE TELEGAMES COMING SOON FROM EA. WRITE TO US & TELL US YOU LIKE MODEM GAMES.'
|
|
; The listing breaks the run into pieces only as an artefact of the build: the C64 side of the game
|
|
; has its own labels and strings at these same addresses (this page is a drive buffer here and part of
|
|
; the game's $0400-$07FF scratch page there).
|
|
eaCopyrightMessage:
|
|
.byte "(C)1988 ELECTRONI" ; 064D start of the 179-byte message; it runs unbroken to $06FF
|
|
.byte "C ARTS, 18" ; 065E
|
|
.byte "20 GATE" ; 0668
|
|
.byte "WAY DR, " ; 066F
|
|
.byte "SAN MATEO,CA 94404. THE AGE OF MODEM WAR"; 0677
|
|
.byte "FARE HAS BEGUN. MORE TELEG"; 069F
|
|
|
|
; eaCopyrightMessageTail - the last 70 bytes of eaCopyrightMessage. It only carries its own label
|
|
; because the C64-side unit has code at this address and splits the text run.
|
|
eaCopyrightMessageTail:
|
|
.byte "AMES COMING SOON FROM EA. WRITE TO US & TELL US YOU LIKE MODEM GAMES."; 06BA '...AMES COMING SOON FROM EA. WRITE TO US & TELL US YOU LIKE MODEM GAMES.'
|