It's the boot tracker code. If I don't call it, it works. It's not because the code doesn't work - it finds the right device name - but for some reason the HFDC doesn't like that this code has been called. Probably to do with enabling the ROM?
[font=courier new,courier,monospace]BOOTTR MOV @>83D0,R12 * GET THE CRU BASE IN R12
MOV @>83D2,R9 * GET THE ROM ADDRESS FOR DEVICE
LDCR @ONES,0 * ENABLE THE ROM
AI R9,4 * ADDING FOUR PUTS US AT THE LENGTH BYTE
MOVB *R9+,R4 * PLACE THAT IN R4 AND INCREMENT R9
SRL R4,8 * RIGHT JUSTIFY LENGTH IN R4
LI R10,FILEDV * POINT TO TEXT BUFFER
MOVIT MOVB *R9+,*R10+ * MOV ONE BYTE FROM ROM TO TEXT BUFFER
DEC R4 * FINISHED?
JNE MOVIT * NO, DO ANOTHER BYTE
LDCR R4,0 * DISABLE THE ROM (R4 IS ZERO AT THIS POINT)
B *R11 * BRANCH TO NEXT SECTION OF CODE
ONES DATA >0101 * WORD TO TURN ON ROM IN CRU[/font]
As I wrote earlier I copied it from "The Art Of Assembly — Part 7. Why A Duck? By Bruce Harrison 1991", and I don't fully understand how it's working. I would like to keep it, because I like to be able to run the game from any floppy drive.
Looks like Michael identified the culprit. And it was simple <big grin>
Strange that Bruce used LDCR and loaded 16 bits when 1 bit would suffice. Then again, CRU operations are often cloaked in mystery. If you read future articles from Bruce, he complains about hardware incompatibilities and such. I wonder if his early loader was the source of some of that woe over the years.
As for the code, let me add a few things to my earlier comment. Essentially what Bruce is doing is picking up the last used CRU address (assumed to be the peripheral card that loaded your program) and the address of the last used device name. These pointers are set by most DSRLNK routines, including the one you are using to load your map and other data.
[color="#008800"]DJUMP2 AI R12,>0100
MOV R12,@>83D0 [b]SAVE THE CRU ADDRESS![/b]
DLOOP3 MOV @>83D2,R2
DJUMP3 MOV *R2,R2
MOV R2,@>83D2 [b]SAVE POINTER TO THE DEVICE! [/b][/color]
Each peripheral has a linked list of the device names located in its DSR (could be ROM or RAM). Bruce makes use of these values to turn the card back on by setting R12 equal to the peripheral's CRU address (83d0) and then turning the card on with a CRU instruction. He then uses 83d2 to point to the last device via R9, skips four bytes that are part of the linked list, grabs the device name length (also in the list) and extracts the name. The final step is turning the card off, again using a CRU instruction.
A good representation of the DSR ROM header and linkage can be found in the "Device Service Routine Specification for the TI" Section 4.2 and 4.2.1.
Device Service Routine Specification for TI 99_4(A) Personal Computer V2.0 03-28-1983.pdf 528.71KB
Edited by InsaneMultitasker, Sun Aug 11, 2013 3:23 PM.