USER MTX is basically the original Memotech code for USER LOAD tweaked to account for the differences between disc basic and tape basic. It only works for single file MTX files, as any 2 stage loaders are going to be calling the rom's tape loader directly, and patching the rom isn't an option.
That means USER MTX has 2 things to deal with:
- Tape basic stores the file name at the start of the file, disc basic doesn't as the file name is already in the catalogue.
- Disc basic stores an extra 2 bytes for the length of the system variables that tape basic doesn't.
This is the output from the assembler for the start of USER LOAD, as written by Memotech
Code: Select all
(2804) .DLOAD
C804 (2804) 13 INC DE
C805 (2805) DD 21 E8 D8 LD IX,CHNL5
C809 (2809) CD 02 2E CALL GETUFN
C80C (280C) 1B DEC DE
(280D) .AUTORUN
C80D (280D) DD 21 E8 D8 LD IX,CHNL5
C811 (2811) D9 EXX
C812 (2812) 21 85 FA LD HL,USER+-4
C815 (2815) 11 12 D9 LD DE,USERSAV
C818 (2818) 01 07 00 LD BC,7
C81B (281B) C5 PUSH BC
C81C (281C) D5 PUSH DE
C81D (281D) E5 PUSH HL
C81E (281E) ED B0 LDIR
C820 (2820) D9 EXX
C821 (2821) DD 36 27 05 LD (IX+&27),5
C825 (2825) CD 66 29 CALL SIOPEN
C828 (2828) CD 1D 2D CALL STARW
C82B (282B) 21 7A FA LD HL,LSTPG
C82E (282E) 7E LD A,(HL)
C82F (282F) F5 PUSH AF
C830 (2830) E5 PUSH HL
C831 (2831) CD 95 28 CALL GETBC
C834 (2834) 60 LD H,B
C835 (2835) 69 LD L,C
C836 (2836) CD 95 28 CALL GETBC
(2839) .load_common
(2839) ;USER MTX rejoins here
C839 (2839) CD 7E 28 CALL READIN
And this is the modified code used by USER MTX
Code: Select all
(318A) .MTX
D18A (318A) 13 INC DE
D18B (318B) DD 21 E8 D8 LD IX,CHNL5
D18F (318F) CD 02 2E CALL GETUFN
D192 (3192) 1B DEC DE
(3193) ;AUTORUN
D193 (3193) DD 21 E8 D8 LD IX,CHNL5
D197 (3197) D9 EXX
D198 (3198) 21 85 FA LD HL,USER+-4
D19B (319B) 11 12 D9 LD DE,USERSAV
D19E (319E) 01 07 00 LD BC,7
D1A1 (31A1) C5 PUSH BC
D1A2 (31A2) D5 PUSH DE
D1A3 (31A3) E5 PUSH HL
D1A4 (31A4) ED B0 LDIR
D1A6 (31A6) D9 EXX
D1A7 (31A7) DD 36 27 05 LD (IX+&27),5
D1AB (31AB) CD 66 29 CALL SIOPEN ;sequential file open
D1AE (31AE) CD 1D 2D CALL STARW ;pre-I/O setup routine
(31B1)
(31B1) ; now need to throw away 16 bytes of the "tape" header
D1B1 (31B1) 06 10 ld b,16
(31B3) .throwaway
D1B3 (31B3) CD 72 2C call bget
D1B6 (31B6) 10 FB djnz throwaway
(31B8)
D1B8 (31B8) 21 7A FA LD HL,LSTPG
D1BB (31BB) 7E LD A,(HL)
D1BC (31BC) F5 PUSH AF
D1BD (31BD) E5 PUSH HL
D1BE (31BE) CD 95 28 CALL GETBC ;get the variables start address
(31C1) ;LD H,B
(31C1) ;LD L,C
(31C1) ;CALL GETBC
(31C1) ; SDX basic stores the block length next, MTX files don't have that word, it has to be calculated
D1C1 (31C1) C5 push bc ;save the variables start address
D1C2 (31C2) 21 4B FB ld hl,start ;system variables are saved to this point
D1C5 (31C5) B7 or a ;clear carry flag
D1C6 (31C6) ED 42 sbc hl,bc ;block length calculated
D1C8 (31C8) 44 ld b,h
D1C9 (31C9) 4D ld c,l ;length to BC
D1CA (31CA) E1 pop HL ;start to HL ready for the next call.
D1CB (31CB) C3 39 28 jp load_common ;now go back to the load routine as there are no further differences.
I would assume any issues with autorun stem from the file, rather than the code. As autorun for disc basic files is working, and that's not altered by the changes I made.
However:
2 things to thing about.
- A lot of the Continental games deliberately corrupt the system variables.
- Different memory sizes might have an effect on auto run.
The first one is actually easy to get around. While he MTX OS CHECKS the break key under interrupts, but doesn't ACT on that while disc I/O is happening (and this applied to the real FDX and probably SDX too). So if you type in USER MTX "file" or USER LOAD "file" and then hold down break after hitting enter. as soon as the loading finishes you should get "Ready" appear, even if the program normally auto runs. Saving a program at that point should have more chance of success though it might still need a dive into panel to check/alter some of the pointers.
The second has come to light when trying some autorun programs on the MTXplus where the memory available to basic can be tweaked to be between 32k and 448k. That seems to occur with large arrays saved. Since the code used is exactly the same (as the MTXplus and CFX us the same CF hardware) it's likely there's an issue in the original Memotech code when dealing with programs that extend over multiple ram "pages". However none of the game files I've tested on the MTXplus are affected - presumably because they all fit into a single "page" of the ram.