.T64 file support bugs.

[zaphod]

1) after loading any file from .t64 whether a filename is specified or not, the file pointer should move to the file after the one loaded, and it does not. instead, it stays on the same file, breaking all multistage tape loaders that call the kernel routine without a filename.

2) Filenames are not being properly interpreted. The .t64 file demands that filenames be padded at the end with spaces. This means that unless you have a 16 character filename, you CANNOT load it directly in ccs64 without tacking on the extra spaces. This breaks multi-stage tape loaders that DO use filenames except in the rare case that the filename is exactly 16 characters. The proper way for CCS64 to interpret a .t64 file directory is to seek to the end of the filename entry, and replace all consecutive $20 with $A0 internally startign at the end of each entry and ending at the first non space character for that file. This algorithm will not fail.

This is a major interference with my process of transfering multi-load games that do not save highscores from .d64 to .t64 to save disk space.

[zaphod]

Both are fixed as of beta 1.3. Congrats on the good work.

[zaphod]

WEll, not quite... I've got a loader that still fails. It works on c64s just fine..

[zaphod]

Well after looking at it, it wouldnm't work on a real c64 either. some stuff works that shouldn't on c64s.I think thw support is good enough now, though perhaps a configurable option of "tape load ALWAYS loads next file" can be added that will fix such broken tape loaders.

[Stuart Toomer]

I think we'll classify this one as fixed.

[zaphod]

When loading a tape file as disk, it uses the space padded names instead of the real names.

INcidentally, loading a disk file as tape works perfectly. I even managed to boot my "shogun cracks" perfectly off their disk images using tape, because they use basic loaders that check for active device.