A quick look tells me that it makes assumptions on where $0330 and $0332 was pointing (which is different in the dtv kernal). The code is at $9c40-$9fc5 after loading. I'll have a go at fixing it tomorrow.
I wonder why the coder didn't chose to have the code at $CC7a-$cfff. I haven't seen many programs using that area. And the more you load into RAM, the less free you have left to run programs from... DUH! So high memory only would be really great. And then those pokes in the beginning wouldn't be needed either.
I guess making a RAMdisk that works instead of a floppy, which you can run games and demos from, would require a quite different solution?
Last Edit: Sept 2, 2006 18:10:35 GMT -5 by MadModder
Ok... so the original program has these problems: 10 POKE 52,0:POKE 53,156:POKE 55,0 20 POKE 56,156:PRINT"<CLR>WAIT..." ...should probably be... 10 POKE 51,0:POKE 52,156:POKE 55,0 20 POKE 56,156:PRINT"<CLR>WAIT..." It does not matter so much because 51/52, i.e $33/$34 (FRETOP) are updated from 55/56, i.e $37/$38 (MEMSIZ) upon the terminating NEW in line 130.
The "bug" preventing it working with the DTV is that it assumes that the kernal vector is $f4a5 upon load (called through $0330): 9D35 85 93 STA $93 9D37 A5 BA LDA $BA 9D39 C9 02 CMP #$02 9D3B F0 05 BEQ $9D42 9D3D A5 93 LDA $93 9D3F 4C A5 F4 JMP $F4A5 9D42 ...Analogously done for save at $9c6c, calling $f5ed.
These vectors are different in the DTV kernal.
There are two ways of fixing this:
One is calling the routines indirectly through the vector-table at $FD30. (load entry $FD4C, save entry $FD4E) This will as a side effect kill any previous patch to the load/save vectors, for example a turbo loader. Still this might be desirable, because the ram disk probably overwrites the turbo anyway.
Another way is to, at startup, check $0330-$0333 to see if they are already set up by us, otherwise record the old values, and call those instead.