Cassette load quirk

[InfernalKeith]

I was loading a BASIC program from cassette tonight, but had my PEB with 32K plugged in and turned on as well.  As soon as the initial tone on the cassette ended and the first data was encountered, it kicked back ERROR DETECTED IN DATA and stopped.  I tried it on two different tape decks.

 

Once I shut off the PEB and unplugged it from my console, restarted in TI BASIC, and typed OLD CS1, that program loaded with no issues at all.

 

I expected the program not to run, given the small amount of memory the disk system uses up, but for it to not even load the program in?

 

Is that just a weird quirk, or some normal procedure I've just never seen happen before?

[+mizapf]

Not sure, could be the length word that it encountered, and when your PEB is connected, supposedly with floppy drive, the free space is smaller than without.

[blackbox]

Memory limitations can hit in two places when loading from tape- the tape file may be bigger than the VDP memory you have  when the disk controller is attached - your problem here I think.  With a disk system attached you lose some VDP memory for disk buffers. You may not have enough vdp to hold the cassette file.
Then when you RUN a program, and prescan takes place, arrays dimensioned, and so on, more memory is required which can result in a run time error.
Although you may have 32k ram attached, the tape is always first loaded into VDP memory but may then run from 32k ram.
With the PEB attached  you can free up memory with CALL FILES(1) then NEW. This reduces the VDP memory used by disk buffers and also limits you to one disk file open at a time.  Some XB versions permit CALL FILES(0) or there is a CALL LOAD available.
s

 

Edited February 12, 2020 by blackbox

[ti99iuc]

23 minutes ago, blackbox said:

[...]  Some XB versions permit CALL FILES(0) or there is a CALL LOAD available. 
s

i know only Classic99 can use CALL FILES (0), it is an interesting news instead!
who knows which one of the XB permit also to use CALL FILES (0) on real hardware please?
 

[Mehridian Sanders]

Please forgive my ignorance in this matter. Is there a way to Increase VDP size?

Sent from my SM-G955U using Tapatalk

[+mizapf]

You can increase the VRAM space only by reducing the reserved buffers using CALL FILES. The RAM itself cannot be expanded, as the VDP cannot address more than 16 KiB.

[atrax27407]

Or, you can get one of the 80-column cards that has increased VRAM.

[InfernalKeith]

>Memory limitations can hit in two places when loading from tape- the tape file may be bigger than the VDP memory you have  when the disk controller is attached - your problem here I think.  With a disk system attached you lose some VDP memory for disk buffers. You may not have enough vdp to hold the cassette file.

 

 

This makes sense.  I'd just never encountered it before.  When I used tapes all the time, I would sometimes get a program that loaded but kicked back a MEMORY FULL when you tried to run it.  

 

Interesting!  

[blackbox]

3 hours ago, ti99iuc said:

i know only Classic99 can use CALL FILES (0), it is an interesting news instead!
who knows which one of the XB permit also to use CALL FILES (0) on real hardware please?

 

I have had so much strange hardware on trial and so many XBs - many of which have disappeared- I honestly can't recall, and could have misremembered. Right now I don't have a working disk controller.

 

However to keep everything relevant in the thread:

In XB with 32k and Disk Controller-

CALL LOAD(-31888,63,255) then NEW  will advise your console it really doesn't have a disk controller attached and will free up the vdp memory for you.  Don't try to use a disk until you reset eg with

CALL LOAD(-31888,55,255) then NEW

which puts it back to 3 for you.

After using the CALL LOAD, if you have just told the system you don't have a disk controller, don't try CALL FILES(3), use the latter CALL FILES.

 

Effect:  Each FILE buffer uses up 518 bytes.  However between (0) and (1) you will save 1052 bytes.

 

 

Or to put it another way, when you plug the disk controller in the VDP has 2088 bytes less to transfer the cassette file into.

 

 

 

 

[+Lee Stewart]

5 hours ago, ti99iuc said:

i know only Classic99 can use CALL FILES (0), it is an interesting news instead!
who knows which one of the XB permit also to use CALL FILES (0) on real hardware please?

 

TI Basic and XB CALL FILES() both call subprogram >16 in the DSR of the disk controller. That subprogram, in the TI Disk Controller at least, will not allow CALL FILES(0).

 

If any one of DSK1, DSK2, DSK3 is set up in Classic99 to use the TI Disk Controller, Classic99 will also not allow CALL FILES(0).

 

...lee

[ti99iuc]

yes, well... talking for the real hardware, would really useful to have something of the CALL FILES (0) to convert some tapes to disk.

There are some programs that will load on classic99 using CALL FILES (0) otherwise, without use it, after RUN we can have a MEMORY FULL error.

in Classic99 i think it simulate like if no controller or floppy disks are connected but instead we can use to save a program.
On real hardware instead i done some trials using CALL LOAD() codes some months ago without success, i will try again but i doubt it will work as i need... because i need to use the controller to save the program once it is loaded in memory.

BTW i am curious to discover if i have some XB version here with the CALL FILES (0) possibility as blackbox described.
 

[blackbox]

If you have a TI Basic program that your emulator allows you to load but not run,  one possibility is to try loading the Basic program into Extended Basic, then merge in the short VDP utility which allows Basic programs to run in ExBas - then save to disk.  The system may save the file as IV254 but that just means long program (too big for VDP...) and it loads in the usual OLD way.  Your Basic program will now need Extended Basic and 32k ram,  but will at least be runnable from  (emulated) disk.

 

REAL IRON....

If you use the CALL LOAD to load a TI Basic cassette program into TI Basic, you may be able to reduce the size of the program by editing and then SAVE back to tape, then see if it will load with CALL FILES(1) to enable you to save it to disk.       OR the really tough way...

 

If you can get the program into memory with the CALL LOAD, it may be possible to edit it into two parts (yes it is hard work) and save each part to tape, then  with CALL FILES(1) set, move both parts to DISK.  You can then use Extended Basic's MERGE facility to get the two parts back together and add the VDP utility.  

- set disk drive off with the call load

- OLD program from tape

- edit out a hundred or so lines at the end

- save to another tape

- reload original program and edit out a hundred or so lines from the start

- save to another tape

Reset the disk drives back, use CALL FILES(1) if needed-

Switch to Extended Basic and load one of the tapes and save to disk in MERGE format.

Load the other part of the program and MERGE in the first part and the VDP utility.

 

 Yep, hard work, but it should work. May take ages.  

And you only need to do it once.   The Basic program will now be on disk but needs XB and 32k ram.

 

s

 

 

 

[ti99iuc]

1 hour ago, blackbox said:

[...] REAL IRON....

If you use the CALL LOAD to load a TI Basic cassette program into TI Basic, you may be able to reduce the size of the program by editing and then SAVE back to tape, then see if it will load with CALL FILES(1) to enable you to save it to disk.       OR the really tough way...

If you can get the program into memory with the CALL LOAD, it may be possible to edit it into two parts (yes it is hard work) and save each part to tape, then  with CALL FILES(1) set, move both parts to DISK.  You can then use Extended Basic's MERGE facility to get the two parts back together and add the VDP utility.  

- set disk drive off with the call load

- OLD program from tape

- edit out a hundred or so lines at the end

- save to another tape

- reload original program and edit out a hundred or so lines from the start

- save to another tape

Reset the disk drives back, use CALL FILES(1) if needed-

Switch to Extended Basic and load one of the tapes and save to disk in MERGE format.

Load the other part of the program and MERGE in the first part and the VDP utility.

 Yep, hard work, but it should work. May take ages.  

And you only need to do it once.   The Basic program will now be on disk but needs XB and 32k ram.

yes indeed, this is the method i used until now because never found an alternative.
for example i used in Robopod i dumped from the tape the original TI BASIC list, but also in other bunch of others.
yes, do this steps is a #painintheass every time ? 
for this i always hope to find another easier way to do this, still about 400+ tapes to dump.

Edited February 12, 2020 by ti99iuc

[+mizapf]

11 hours ago, mizapf said:

Not sure, could be the length word that it encountered, and when your PEB is connected, supposedly with floppy drive, the free space is smaller than without.

 

I just had a look at the cassette data format.

 

00 00 ... (00*764) ...00 00 FF Len1 Len2 [  [ 00*8 FF Data*64 Checksum ]*2 ] *n

 

The 00 at the beginning cause the constant 714 Hz tone. The two length bytes (length = Len1 * 256 + Len2) can indeed be used to check whether the file fits into memory before reading it.

[sparkdrummer]

Ciro 

I recommend Tape To Disk. 
it works great. 

[ti99iuc]

12 minutes ago, sparkdrummer said:

Ciro 

I recommend Tape To Disk. 
it works great. 

ok, try to find it.

thanks

[Tursi]

9 hours ago, Lee Stewart said:

If any one of DSK1, DSK2, DSK3 is set up in Classic99 to use the TI Disk Controller, Classic99 will also not allow CALL FILES(0).

.. an unsupported configuration, I'll add, as there are many limitations when you do that. It's intended for testing purposes only, not general use. I haven't patched the TI ROM to support the larger disk images yet.

 

The Classic99 DSR should be able to do anything the TI Controller can, and if it can't, with the exception of relying on bread crumbs in RAM for disk tracking, please let me know so I can fix it.

 

[Tursi]

The other thing I did back when I did my own conversions from tape to disk was just modifying the program to take up less space. We've done that for a one of two here on the forum over the years... sometimes we can do it without changing functionality at all.

 

 

[snume]

On 2/12/2020 at 2:03 AM, InfernalKeith said:

I was loading a BASIC program from cassette tonight, but had my PEB with 32K plugged in and turned on as well.  As soon as the initial tone on the cassette ended and the first data was encountered, it kicked back ERROR DETECTED IN DATA and stopped.  I tried it on two different tape decks.

 

Once I shut off the PEB and unplugged it from my console, restarted in TI BASIC, and typed OLD CS1, that program loaded with no issues at all.

 

I expected the program not to run, given the small amount of memory the disk system uses up, but for it to not even load the program in?

 

Is that just a weird quirk, or some normal procedure I've just never seen happen before?

 

On 2/12/2020 at 3:56 AM, blackbox said:

Memory limitations can hit in two places when loading from tape- the tape file may be bigger than the VDP memory you have  when the disk controller is attached - your problem here I think.  With a disk system attached you lose some VDP memory for disk buffers. You may not have enough vdp to hold the cassette file.
Then when you RUN a program, and prescan takes place, arrays dimensioned, and so on, more memory is required which can result in a run time error.
Although you may have 32k ram attached, the tape is always first loaded into VDP memory but may then run from 32k ram.
With the PEB attached  you can free up memory with CALL FILES(1) then NEW. This reduces the VDP memory used by disk buffers and also limits you to one disk file open at a time.  Some XB versions permit CALL FILES(0) or there is a CALL LOAD available.
s

 

Well after another hiatus, a new wave of nostalgia has hit and I fired up the 99/4A, the CF7+ and the cassette drive to transfer some of the tapes I got in a batch of stuff a few years ago and Iran into the same issue as Keith. And the CALL FILES(1) and NEW - in TI Basic did the trick. Anything over 23 or so blocks wouldn't fit. The work around wouldn't work in Extended Basic either, just TI Basic.

 

Well it only took me a couple of hours plugging and unplugging, running around until I found this thread and I want to say a huge thanks to you Black Box.

[RXB]

On 2/12/2020 at 1:56 AM, blackbox said:

Memory limitations can hit in two places when loading from tape- the tape file may be bigger than the VDP memory you have  when the disk controller is attached - your problem here I think.  With a disk system attached you lose some VDP memory for disk buffers. You may not have enough vdp to hold the cassette file.
Then when you RUN a program, and prescan takes place, arrays dimensioned, and so on, more memory is required which can result in a run time error.
Although you may have 32k ram attached, the tape is always first loaded into VDP memory but may then run from 32k ram.
With the PEB attached  you can free up memory with CALL FILES(1) then NEW. This reduces the VDP memory used by disk buffers and also limits you to one disk file open at a time.  Some XB versions permit CALL FILES(0) or there is a CALL LOAD available.
s

 

No actually you can type in CALL FILES(0) but that does exactly the same as CALL FILES(1).

I know this as I just created in RXB the first CALL FILES(0) that does exactly what it should do.