Problem converting Extended BASIC Tape to FIAD

[J-Data]

Hi All,

 

Sorry if this has been asked and answered before, but I've looked and can't find any similar problems discussed.  

 

I need help converting a very large Extended Basic (XB Version 110) program from tape to FIAD file, but have hit a big roadblock.  I think its related to how big the XB program is (190 records in FIAD file).

 

So my goal was to take all my old Extended Basic programs and get them converted into a format to archive permanently, and to run them on TI99 emulators like Classic99 or TI99SIM or with my old real-iron units through TIPI or MicroPEB.  So I dug out all the old tapes and started making .WAV files using Audacity and then converting using either CS1er or TAPE994a.  This worked great on 90% of my old files.  Unfortunately, when I went to convert my 1983 masterpiece "Cosmic Crater", it failed to load from disk every time (using Classic99), and I get an "I/O error 02". 

 

Keep in mind:

• The tape I have will load on a real TI99 from tape drive every time, and runs fine.
• I can successfully convert the .WAV file to FIAD using both CS1er and Tape994a without error.
• When I go to load the FIAD using an emulator (Classic99) "OLD DSK3.FIAD" I get an "I/O error 02"  every time.
• I've been successful in converting and running many other XB programs using this method without issue.
• The XB program I'm trying to convert is very large on uses almost all of the available ~14KB RAM, (SIZE shows only 1803 bytes free after "OLD CS1")
• I did a test to convert another extremely large XB .WAV file (downloaded off this forum) using the same method and got the exact same "I/O error 02" on Classic99.
• I even tried re-recording the .WAV file direly TI99's CS1 Mic output plug to the Mic input to the PC running Audacity, with no change.  (File audio quality was exceptionally good though)
• I don't have a TIPI or MicroPED (yet) so can't test this FIAD file on a real unit.

 

So I have 5 possible theories on what might be going wrong:

1. Classic99 has a unique issue of running XB program that large (~12K)
2. The FIAD format has a limitation with XB programs that large (190 records)
3. The TI99 with a 32K expansion has an issue running XB programs that large (Classic99 can only be run with 32K expansion emulated)
4. The TI99 with a disk controller has an issue running XB programs that large
5. None of the above, I'm just doing the .WAV to FIAD conversion wrong. 

 

I've attached the FIAD file for anyone willing to take a look and see what is wrong.  I can also attache my best .WAV file if it help. 

 

So, Any suggestions?

 

Thanks!

 

-JP 

CC3

[jrhodes]

In classic99, select XB as the cart.

Do: CALL FILES(0)

then, OLD DSK1.CC3

 

Then, CALL FILES(3)

SAVE DSK1.CC3-IV [or use whatever filename you want]

 

This will save the program in XB Int/Var format, which can be loaded from DSK or TiPi from XB.

 

Here is the converted Int/Var file of your program

Please keep in mind that CALL FILES(0) will not work on a real TI!

CC3-IV

 

Edited January 6, 2020 by jrhodes

[J-Data]

Hi Jrhodes,

 

Thanks! that worked great!  Although it does look like that "CC3" file I included does have some text errors introduced (probably in my conversion).  I'll do some digging in the classic99 documentation to understand what the "CALL FILES(0)"  and "CALL FILES(3)"commands do, but can you give a short explanation on why the original FIAD file would not work without these?

 

Thanks again!

 

-JP

[jrhodes]

Someone can probably explain it better, but the disk system uses some memory.

Classic99 is able to do a illegal value of 0 for CALL FILES().

CALL FILES() allocates memory for the disk system.

Normally, setting it to 1 reserves the least amount of memory.

I forget what CALL FILES(2) does, but i know CALL FILES(3) causes XB to write programs in Int/Var format.

 

Someone else, please feel free to explain this better?

[+jedimatt42]

the number passed to CALL FILES is the number of files you can have simultaniously open. Each open file requires a sector buffer and additional overhead.

 

Programs that are small enough will live in the VDP memory.  The open file overhead must reside in VDP memory. So if you grow this and your program wouldn't fit anymore, XB moves some of your program into memory expansion. CALL FILES(2) might do that if it crosses the threshold. 

 

Programs that live in memory expansion get saved in a record based format instead of a memory image based format, cause with TI disk controllers, all PROGRAM image LOAD operations (at the low level, not lowest) get loaded directly into VDP memory.  The TI Disk Controller was designed to be operational without the memory expansion. Using a record based format then allows XB to load smaller subsets and determine where they belong.   ( See the next post by senior_falcon for correction on what I said. He is our BASIC runtime expert )

Future expansions change or expanded the rules.. emulations like classic99 don't actually need a sector buffer in VDP for the file system... so it allows setting CALL FILES(0) - no VDP buffers for disk.  

 

Sector buffers exist because the unit of read/write from spinny disk thing is a sector. But the unit of interaction is just a record, of which many may be in one sector. 

 

We have to manage it because it was the 80s.

 

-M@

Edited January 6, 2020 by jedimatt42

[J-Data]

So it sounds like my XB program would have never run a a real system with a disk controller due to the memory used by the disk system.  Common sense would say that the 32K memory expansion would counter this, but I guess the memory allocation is not that straight forward. 

 

Thanks again for all the help guys!  This is huge for me. 

 

Thanks!

 

-JP

[J-Data]

It looks like that CC3 file I originally attached was corrupted, so I tried an older conversion with your "CALL FILES(0); OLD DSK3.CC1; CALL FILES(3); SAVE DSK3.CC1-IV" sequence and it works great.  The new version can now be loaded and run without any "CALL FILES(X)" statements.  See attached.

 

Wow, the game play is much more exciting in CPU overdrive. 

 

Thanks again!

 

-JP

CC1-IV

[Ed in SoDak]

The first file loaded in Mac V9T9, other than the "For-Next Nesting" error.

 

The second file is in TIFILES format which I had to convert to V9T9. Then it ran fine.

-Ed

[senior_falcon]

3 hours ago, jedimatt42 said:

Programs that are small enough will live in the VDP memory.  The open file overhead must reside in VDP memory. So if you grow this and your program wouldn't fit anymore, XB moves some of your program into memory expansion. CALL FILES(2) might do that if it crosses the threshold. 

 

Programs that live in memory expansion get saved in a record based format instead of a memory image based format, cause with TI disk controllers, all PROGRAM image LOAD operations (at the low level) get loaded directly into VDP memory.  The TI Disk Controller was designed to be operational without the memory expansion. Using a record based format then allows XB to load smaller subsets and determine where they belong.

 

This is a common misconception. A program is only kept in VDP memory when there is no memory expansion.  If there is a 32K memory expansion then programs are always kept there, regardless of size.

You can check this easily:

NEW

SIZE  -   you get 11840 bytes of stack free; 24488 bytes or program space free.

1 !         shortest possible program

SIZE  -  and now you have 24481 bytes of program space free.

What you mean to say is that, when using the memory expansion, if there is enough room in VDP ram then the program will be saved in a memory image format.

If the program will not fit in the available space in VDP ram then it will be saved in a record based format (IV254)

And of course, the disk buffers take up room in the VDP which is why CALL FILES(1) or CALL FILES(0) gains you additional space.

Edited January 6, 2020 by senior_falcon

[+jedimatt42]

44 minutes ago, senior_falcon said:

This is a common misconception. A program is only kept in VDP memory when there is no memory expansion.  If there is a 32K memory expansion then programs are always kept there, regardless of size.

You can check this easily:

NEW

SIZE  -   you get 11840 bytes of stack free; 24488 bytes or program space free.

1 !         shortest possible program

SIZE  -  and now you have 24481 bytes of program space free.

What you mean to say is that, when using the memory expansion, if there is enough room in VDP ram then the program will be saved in a memory image format.

If the program will not fit in the available space in VDP ram then it will be saved in a record based format (IV254)

And of course, the disk buffers take up room in the VDP which is why CALL FILES(1) or CALL FILES(0) gains you additional space.

Thanks for that clarification! 

 

-M@

[Tursi]

Just for the record, if you load a program with CALL FILES(0), and then issue CALL FILES(3) without immediately issuing NEW, you run the risk of corrupting the loaded program. CALL FILES does not do any reallocation or moving of data, all it does is change the pointers for how much memory is reserved.

 

Traditionally, you would start issues like this by simply issuing CALL FILES(1) before you load it - and if that works, then you are done and can do the same thing on real hardware. CALL FILES(0) is supported on Classic99 only because Classic99 doesn't need to reserve any VRAM for disk and does it for compatibility only. Setting number of files buffers to 0 gives you the same memory layout (in theory) as cassette systems have.

 

The trick there for forcing it to save as IV254 is clever, though you can do the same thing without trickery by using RXB, which always saves in that format. Worth a try anyway!

 

Edit: Ah, based on Senior Falcon's description, it would appear the risk of corruption is not there after all. I guess that's why the trick works!

 

 

Edited January 6, 2020 by Tursi

[ti99iuc]

Very nice  and interesting post here, thanks for the game too  

I am curious @Tursi could it be possible to load in realtime in classic99 using a tape?
because i often doing lot of dumps from tapes and still have hundreds to do it could be very useful and faster connect my recorder to PC and load directly into Classic99 for example.
this possibility not only will make easier things for Basic or XB programs but also Dump MM software or other multiload maybe.

 

[Tursi]

17 hours ago, ti99iuc said:

Very nice  and interesting post here, thanks for the game too  

I am curious @Tursi could it be possible to load in realtime in classic99 using a tape?
because i often doing lot of dumps from tapes and still have hundreds to do it could be very useful and faster connect my recorder to PC and load directly into Classic99 for example.
this possibility not only will make easier things for Basic or XB programs but also Dump MM software or other multiload maybe.

 

I wouldn't expect it at this point. Conceptually, it'd probably work if I buffered a little bit, but Classic99 is not intended as a solution to reading from tape - I implemented it only as a curiosity. At any rate, I don't have live readback right now. I was always under the impression that tools like CS1er were more appropriate, since they attempt to correct and regenerate the signal.

 

[ti99iuc]

@TursiYes, i've also often used CS1er utility to convert a program, but not always with success and it is also a lot limited. (I dumped already about 200 tapes and missing more than 300 still)
The problems that i found, are overall when the program is full 16K (same of the case of the game in the first post) that you have to record and process a .wav but also when programs are not in standard B/XB, in this case CS1er will not work.
And then the idea for a Classic99 'realtime player' from an external input. 
Classic99 is a mature and useful tool, It can have a monitor debugger and also CALL FILES (0) possibility to make things easier also dumping tapes.

i can understand your point of view talking of classic99 that have tape function just because it was a curiosity and it is already enough for you.  thanks for your reply

Edited January 7, 2020 by ti99iuc

[Tursi]

Hmm, I see.

 

I'll think on it. If I do it, though, I'm not debugging it when it fails.  I was a cassette-only user for 7 or 8 years, and I was never happier to be done with it. Everyone who wants to go back to it is crazy.

 

 

[ti99iuc]

You are right indeed, cassette tape is unconfortable at all... i just use it for necessity to convert, once done it, then i use only the digital backup of course ?
anyway i really like to keep the originals once for my personal collection ?