How to move DIS/FIX 80 through HDX as files?

[+FarmerPotato]

I'm stuck. I just got HDX working for the first time. Yeah coming out of the stone age. Using some seriously amazing software from Fred Kaal.

 

I'm trying to move a DIS/FIX 80 file. On my PC it is written by xdt99 (oh yeah, the modern world is amazing)

 

The PC has a text file with CRLF line endings.

 

I converted it with TI99Dir to TIFILES format. I tell it it is a DIS/FIX 80 file. I told it to remove CRLF at the same time. TI99Dir produces this format:

128 bytes of TIFILES header

256 bytes organized as: 80 bytes, space filled, 3 times. 16 bytes of zeros.

repeat

 

I drop the file in the HDX files directory and transfer it to the 4A using CFHDXS1 (nanoPeb version).

 

E/A3 says "Illegal Tag". When I look at the file it has a 4th line between every 3.

 

10 OPEN #1:"DSK1.G2",INPUT,DISPLAY,FIXED 80

20 INPUT #1:A$

30 PRINT A$

40 GOTO 20

 

Every 4th line looks like an object record truncated to 16 bytes.

 

Something similarly bad happens when I transfer my EA5 version. However, I was able to transfer 'CANFIELD' from the 4k game contest alright and run it.

 

I'm just stuck at this point. Probably try the same dumb things over and over looking for options I missed, while surrounded by screaming kids. Can anyone help me with the HDX part of my problem?

Edited February 18, 2019 by FarmerPotato

[Opry99er]

I thought HDX required V9T9 format, and not TIFILES?

[+arcadeshopper]

it should do both V9T9 and TIFILES in the latest version..

[+FarmerPotato]

I thought HDX required V9T9 format, and not TIFILES?

 

When TI99Dir (v6.3a 20171101) converts the file it has these bytes for a header: (little endian)

 

>0000

3247 2020 2020 2020 2020 0000 0300 1a00 'G2 '

5050 004c 0000 ...

 

Not TIFILES.. I guess it's V9t9? TI99Dir identifies it as v9. DIS/FIX 80

 

>0080 (sector 1)

80 bytes of tagged object code ending in '0001'

80 bytes of tagged object code ending in '0002'

80 bytes of tagged object code ending in '0003'

16 bytes of 0

so far so good. The last 4 characters of each record should be a consecutive line number.

>180 (sector 2)

'A003EB06A0C0010' nul nul nul ...

offset 80 (decimal. Start of where 2nd record would be.)

64 bytes 'B04C0B0201BD000B ...' line ending in ' 000'

Considering what I read from TI BASIC, every 4th line is mangled with just 16 bytes of data, followed by an unnaturally short 64 character line.

[+FarmerPotato]

 

When TI99Dir (v6.3a 20171101) converts the file it has these bytes for a header: (little endian)

 

>0000

3247 2020 2020 2020 2020 0000 0300 1a00 'G2 '

5050 004c 0000 ...

 

Not TIFILES.. I guess it's V9t9? TI99Dir identifies it as v9. DIS/FIX 80

 

>0080 (sector 1)

80 bytes of tagged object code ending in '0001'

80 bytes of tagged object code ending in '0002'

80 bytes of tagged object code ending in '0003'

16 bytes of 0

so far so good. The last 4 characters of each record should be a consecutive line number.

>180 (sector 2)

'A003EB06A0C0010' nul nul nul ...

offset 80 (decimal. Start of where 2nd record would be.)

64 bytes 'B04C0B0201BD000B ...' line ending in ' 000'

Considering what I read from TI BASIC, every 4th line is mangled with just 16 bytes of data, followed by an unnaturally short 64 character line.

 

 

Alright, sorting out my own problem.

 

xas99 produces one very long line of 80 character records. I only thought it had line breaks because "more" shows it properly on my 80 column window.

g2.obj

 

So ti99dir is confused by this. I think it reads up to 256 bytes with no newline, then breaks that into 4 DF80 records, then reads another 256 bytes, makes 4 records...

 

Classic99 guesses the file format in TIAD mode when providing it to EA3 Load and Run, so I never noticed an issue there.

 

However, from BASIC, Classic99 behaves badly, resulting in this undefined error:

 

So I use xdm99:

../xdt99/xdm99.py work.dsk --initialize 720 -n G2
../xdt99/xdm99.py work.dsk -a g2.obj -f DF80

hdxcfs can't send a whole dsk, so I extract the file in v9t9 format again:

../xdt99/xdm99.py work.dsk -9 -e G2 -o  ../mount/G2

where 'mount' is the Ti99HDX files directory.

 

After this, I am able to transfer the file with CFHDXS1 and run it! Hooray!

Edited February 19, 2019 by FarmerPotato

[Tursi]

I had to put special support in Classic99 for the files that xas99 outputs, as they are formatted oddly, as you are finding.

 

No idea why BASIC doesn't work but it's not going to be high on my list of concerns - it's not a properly formatted TI file and it's not a properly formatted Windows text file, it's somewhere in the middle.

[FDOS]

 

Alright, sorting out my own problem.

 

xas99 produces one very long line of 80 character records. I only thought it had line breaks because "more" shows it properly on my 80 column window.

g2.obj

 

So ti99dir is confused by this. I think it reads up to 256 bytes with no newline, then breaks that into 4 DF80 records, then reads another 256 bytes, makes 4 records...

 

Classic99 guesses the file format in TIAD mode when providing it to EA3 Load and Run, so I never noticed an issue there.

 

However, from BASIC, Classic99 behaves badly, resulting in this undefined error:

 

So I use xdm99:

../xdt99/xdm99.py work.dsk --initialize 720 -n G2
../xdt99/xdm99.py work.dsk -a g2.obj -f DF80

hdxcfs can't send a whole dsk, so I extract the file in v9t9 format again:

../xdt99/xdm99.py work.dsk -9 -e G2 -o  ../mount/G2

where 'mount' is the Ti99HDX files directory.

 

After this, I am able to transfer the file with CFHDXS1 and run it! Hooray!

 

Get a later version of TI99Dir.. I'm behind with V6.4a, but it works well.

[+FarmerPotato]

 

Get a later version of TI99Dir.. I'm behind with V6.4a, but it works well.

Yup. I checked the latest version, same behavior. I need to message Fred.