Jump to content

Recommended Posts

When running some xdt99 cross-checks in Classic99 I noticed that the end-of-file byte marker for DIS/VAR files generated as FIAD files seems to be off by one.

 

BASIC program:

10 OPEN #1:"DSK2.ONELINE",DISPLAY ,OUTPUT,VARIABLE 32
20 PRINT #1:"123456789"
30 CLOSE #1
Resulting FIAD file:
00000000  4f 4e 45 4c 49 4e 45 20  20 20 00 00 80 07 00 01  |ONELINE   ......|
00000010  0b 20 01 00 00 00 00 00  00 00 00 00 00 00 00 00  |. ..............|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
FDR on MESS disk image:
00:  4F 4E 45 4C  49 4E 45 20  20 20 00 00  80 07 00 01   ONEL INE    .. .... 
10:  0A 20 01 00  A9 79 1E C2  A9 79 1E C2  22 00 00 00   . .. .y.. .y.. "... 
20:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   .... .... .... .... 
The EOF byte is "0B" in the FIAD file but "0A" in the disk image. Is this a "feature" of FIAD files that the EOF marker is off by one? I currently cannot double-check what v9t9 does (but Win994a agrees with MESS).
I also noticed that Classic99 has issues with EOF in Extended Basic. More specifically, it reads past EOF when using MESS disk images.
...
1000 IF EOF(1)THEN RETURN
1010 INPUT #1:L$
...
-> I/O ERROR 25 IN 1010
Could this be related?
  • Like 1

... Do TIFILES files have the same issue?

 

My comparison was using FIAD with a TIFILES header, which showed an EOF byte of 11 compared to DSK images in MESS and PC99, which each had a value of 10.

 

...lee

I'll compare against the TI DSR. Thanks! That said, VT9T9 is a deprecated format, and V9T9 is not a direct copy of the FDR from a disk image.

 

I see, so TIFILES would be the preferred file format for Classic99? And I'm curious, Tursi -- did you create your own disk controller for Classic99, or do you create a sector map etc. in the emulator on the fly? Would a module like the original Disk Manager even work in Classic99?

 

v9t9 file headers seem to be very similar to the FDR on disk, except for file timestamps. Do emulators use the local file timestamps instead? And how popular are v9t9-style files in general, i.e., in terms of emulators and/or working with real hardware?

 

Oh, and FIAD == Files ON a disk? What's that about? :)

 

BTW, here's another quick check to see that there's something off in Classic99:

OPEN #1:"DSK1.FOO",DISPLAY,OUTPUT,VARIABLE 255

throws I/O Error 02, for both TIFILES and v9t9.

I think it's Files IN a DISK. ;)

 

Tursi also has implemented the ability to insert a DOAD disk and run it from a drive. As far as sector access, he has done quite a bit there, but he will have to give all the details.

 

The TI FDC is implemented, but not default. You can switch to it.

 

For my purposes, FIAD format with the Classic99 default custom FDC is just fine. I can use mizapf's Image tool or TI99Dir to convert to DOAD if need be.

 

:)

 

Don't know if any of that helped.

  • Like 1

...

Oh, and FIAD == Files ON a disk? What's that about? :) ...

 

“FIAD” means “Files In A Directory”—each TI file is in a directory on the PC.

 

...

BTW, here's another quick check to see that there's something off in Classic99:

 

OPEN #1:"DSK1.FOO",DISPLAY,OUTPUT,VARIABLE 255

 

throws I/O Error 02, for both TIFILES and v9t9.

 

This is not “something off in Classic99”! There is no such animal as DV255. DV254 is the maximum. Variable records have a preceding length byte and 0xFF as the sector-termination byte.

 

...lee

I think it's Files IN a DISK. ;)

 

Tursi also has implemented the ability to insert a DOAD disk and run it from a drive. As far as sector access, he has done quite a bit there, but he will have to give all the details.

...

 

See my last post for meaning of “FIAD”.

 

“DOAD” means “Dump Of Disk On A Disk”, which is a dump of a TI disk to a disk image file. DOAD’s usually have a DSK extension.

 

...lee

Edited by Lee Stewart

This is not “something off in Classic99”! There is no such animal as DV255. DV254 is the maximum. Variable records have a preceding length byte and 0xFF as the sector-termination byte.

 

IIRC the >FF is dropped if the the sector is filled completely, with the EOF marker being 0, so DV255 works just fine. At least that's the behavior I observe in MESS, where the statement works just fine.

 

IIRC the >FF is dropped if the the sector is filled completely, with the EOF marker being 0, so DV255 works just fine. At least that's the behavior I observe in MESS, where the statement works just fine.

 

Not according to the TI docs. And it does not work in MESS for me. It gives the I/O error 02 .

 

...lee

Ah, interesting, it definitely works for me ... but as it turns out I'm using the Myarc HFDC controller in MESS. When I switch to the TI disk controller then the statement also fails for me!

 

So never mind my suggestion that this could somehow be related to the EOF marker. :ponder:

  • Like 1

I just wanted to add ... but now it seems this has already been proved ... on this level it's very likely the DSR author who is to blame. MESS itself does not have any code inside that can control how the contents of a disk or file look like.

Ah, interesting, it definitely works for me ... but as it turns out I'm using the Myarc HFDC controller in MESS. When I switch to the TI disk controller then the statement also fails for me!

 

So never mind my suggestion that this could somehow be related to the EOF marker. :ponder:

Which statement fails?

I'll compare against the TI DSR. Thanks! That said, VT9T9 is a deprecated format, and V9T9 is not a direct copy of the FDR from a disk image. Do TIFILES files have the same issue?

 

note: when using hdx server and sharing a directory with real ti's and classic99 v9t9 format is required

OPEN #1:"DSK1.FOO",DISPLAY,OUTPUT,VARIABLE 255

 

Lee is correct - this should fail. However, I did confirm that with the Geneve such a file can be opened. I did not test with the HFDC directly.

 

I suspect this is a bug related to the effort to expand the record size beyond 255 bytes. The HFDC and Geneve DSR sources both reference "extended record length" and the HFDC manual defines the use of a corresponding 2-byte value. I suspect it never came to fruition due to multiple programs not knowing how to deal with a 2-byte record length, especially disk managers and file transfer routines relying upon level 2 IO.

See my last post for meaning of “FIAD”.

 

“DOAD” means “Dump Of A Disk”. DOAD’s usually have a DSK extension.

 

...lee

From the original V9T9 documentation, where the terms were defined:

 

If you use the emulated disk ROM provided with

V9t9, you can use "files-in-a-directory" or FIAD emulation. If you use

the disk ROM from the actual 99/4A disk controller, you can use "disk-

on-a-disk" or DOAD emulation. If you use both ROMs, you can use both

FIAD and DOAD at the same time.

I see, so TIFILES would be the preferred file format for Classic99?

Yes, because it is a classic format allowing direct interchange with a real TI-99. In the 80's, this was the format used to store TI files on a foreign disk system.

 

And I'm curious, Tursi -- did you create your own disk controller for Classic99, or do you create a sector map etc. in the emulator on the fly?

Yes, it's all from scratch (except the beta-only TI disk controller emulation which you have to manually switch on).

 

Would a module like the original Disk Manager even work in Classic99?

Within limits. Directories will work on any system. Sector access beyond the catalog sectors will only work on disk images. The DSR does not support renaming or deleting files, or formatting disks, on purpose. New blank disks can be created in the Classic99 menu, or with any number of external utilities. Renaming and deleting files can be done in the Windows UI much more simply (except for V9T9 files, who embed the filename, which is the main reason I don't like them). Again, the TI Disk Controller doesn't work with files, but sectors (from the emulator's point of view), so doesn't enforce those limits, although I haven't implemented the format command there.

 

v9t9 file headers seem to be very similar to the FDR on disk, except for file timestamps. Do emulators use the local file timestamps instead? And how popular are v9t9-style files in general, i.e., in terms of emulators and/or working with real hardware?

They are intended to be very similar. Real TI disk controllers (with specific system exceptions) don't have timestamps - that's an extension to the format in all cases.

 

I'm not going to talk to popularity.

 

Oh, and FIAD == Files ON a disk? What's that about? :)

Just me forgetting the acronym, see previous message.

From the original V9T9 documentation, where the terms were defined:

 

If you use the emulated disk ROM provided with
V9t9, you can use "files-in-a-directory" or FIAD emulation. If you use
the disk ROM from the actual 99/4A disk controller, you can use "disk-
on-a-disk" or DOAD emulation. If you use both ROMs, you can use both
FIAD and DOAD at the same time.

 

I stand corrected. :) I couldn't find the reference, so synthesized it from Thierry's definition, which said a DOAD was a sector dump of a TI disk, which is true, but not the source of the acronym.

 

...lee

  • Like 1
  • 2 weeks later...

Tracked down and fixed the off-by-one in the FIAD headers (was a case of knowing the right answer and even having it in the comments, but then coding it backwards ;) ). Also found and fixed the EOF issue (was checking the wrong variable, probably been in there for a long time). Will be in the next release.

  • Like 9

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...