ytmytm / tib-001-cart Goto Github PK

Tomas Vondracek reported:

I tried copy files from 1541 to DD-001 via "slash" and "left arrow" in
Basic. The files are ok, but the saved file at DD-001 doesn't include
any extension and can't be loaded via "arrow up" right from the
directory. You have to type the filename manually.

Need to check:

• how files without extension are stored (probably spaces)
• how the filename matching in FindFile deals with missing extension
• is there a difference if you load "NAME" vs "NAME." vs "NAME.<space><space><space>" vs "NAME.*" vs "NAME*"

Expected behavior probably should be that "NAME" (without dot) means "NAME.*".

I don't think we can drop name.ext DOS convention becuase exchanging files with PC would become much more difficult and/or impossible if illegal (for MSDOS) names are created.

/* loads empty file, this is incorrect.

It seems that pattern matching (FindFile?) doesn't skip over volume id and it won't skip properly over long filename entries either.

Tomas reported:

• There is an issue with directory. I copied your files on the diskette,
  it was ok. Then I copied a few onefile games and the directory looks
  disrupted. I'm sending screenshot + directory in txt. E.g. in the
  disrupted directory I can't see the game "tigerclaw", but the game can
  be loaded right via filename.

 Volume in drive A is DD-001
 Volume Serial Number is 20A0-69F9

 Directory of A:\

20.08.2013  08:53             2˙174 fb64.bin
15.10.2023  20:50               770 diskcopy.prg
15.10.2023  20:50             1˙177 diskmon.prg
15.10.2023  20:50               525 dispasc.prg
15.10.2023  20:50               639 disphex.prg
15.10.2023  20:50               300 format.prg
16.08.2016  03:09            30˙114 pentagram.prg
17.02.2017  18:27            37˙282 kongarcade.prg
09.10.2016  12:28            17˙308 redbaron3000.prg
28.02.2015  18:18            16˙328 tigerclaw.prg
17.03.2016  22:26            31˙029 awakening.prg
              11 File(s)        137˙646 bytes
               0 Dir(s)         586˙752 bytes free

@N:NEWDISK exits without moving out of track 1 with "DISK UNRELIABLE" message (twice).

Original ROM is able to format the same disk.

Probably that's a good case to try out git bisect to see where/when it happened.