|
Ramdisk
Sept 2, 2006 14:51:02 GMT -5
Post by MadModder on Sept 2, 2006 14:51:02 GMT -5
I have this ramdisk program from a computer magazine. It works on the DTV, but when I have it running I can't load"$",1. That makes it crash. Maybe someone could look at it, and even make it use the high DTV memory madmodders.se/temp/RAMDISK.PRG
|
|
|
Ramdisk
Sept 2, 2006 16:17:44 GMT -5
Post by tlr on Sept 2, 2006 16:17:44 GMT -5
I have this ramdisk program from a computer magazine. It works on the DTV, but when I have it running I can't load"$",1. That makes it crash. Maybe someone could look at it, and even make it use the high DTV memory madmodders.se/temp/RAMDISK.PRGA 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.
|
|
|
Ramdisk
Sept 2, 2006 18:09:49 GMT -5
Post by MadModder on Sept 2, 2006 18:09:49 GMT -5
So, quick and dirty, huh? 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?
|
|
|
Ramdisk
Sept 3, 2006 5:41:05 GMT -5
Post by tlr on Sept 3, 2006 5:41:05 GMT -5
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.
I'll post a fully fixed binary later today.
|
|
|
Ramdisk
Sept 3, 2006 6:44:09 GMT -5
Post by tlr on Sept 3, 2006 6:44:09 GMT -5
Here: ramdisk-fixed.prgI took the liberty of shortening the loader, i.e converted it to ML and rle-packed the strings. $0801-$0C8C (5 blocks) instead of $0801-$18a0 (17 blocks). I think that if you want a ramdisk that uses high mem you should look for a REU enabled ram disk for the c64 and modify that. This implementation is very simplistic.
|
|
|
Ramdisk
Sept 3, 2006 12:11:59 GMT -5
Post by MadModder on Sept 3, 2006 12:11:59 GMT -5
Very nice done! If my memory serves me right, you have a true DTV-ramdisk in the workings? So I just have to wait then... ;D
|
|
|
Ramdisk
Sept 3, 2006 13:05:54 GMT -5
Post by tlr on Sept 3, 2006 13:05:54 GMT -5
Very nice done! If my memory serves me right, you have a true DTV-ramdisk in the workings? So I just have to wait then... ;D Thanks! Not me. I think it was David or gmoon that spoke about it. Post a thread there and we'll all discuss it.
|
|