IV254

[senior_falcon]

I am trying to understand the makeup of IV254 files. It is all pretty straightforward except for the first sector. Here is an example from one program.

0A ABCD D1E2 D1E5 0007 FFE7 FF In this example:

0A is the length

ABCD seems to be a header-it is the same in all the programs I have looked at.

D1E2 is the start of the line number table

D1E5 is the end of the line number table (This was a compiled program so there is only one line.)

0007 is ????

FFE7 is the end of the program

FF is a tag for the end of the data in the sector.

 

What are bytes 7 and 8? Possibly a checksum?

Thanks.

[RXB]

Check out my RXB TRANSFORM program:

 

 

Also a GPLHOW2 video:

 

[senior_falcon]

Good videos, but they don't address what I want to do. I'm looking for a simple way to force XB to save a program in IV254 format. The only reason I care is that it turns out there is a problem chaining programs in XB256. Imagine a program in two parts. The first part loads colors and character definitions, then runs the second program. If the second program is in program format it will overwrite the character definitions for screen2 that you just loaded, but it works fine as long as the second program is in IV254 format. I have a utility that does the equivalent of CALL FILES(28) (or thereabouts) and then saves are in IV254 format. But it is cumbersome and a bit flaky. I envisioned something like this: CALL LINK("SAV254","DSK3.PROGRAM2") which would save the program you are working on as IV254. Using RXB for this would be fine in emulation, but I want to be compatible with real iron, and there are hardly any actual RXB cartridges.

 

So back to my original question: what are bytes 7 and 8 for?

[kl99]

Do you mean the program stored in VDP Ram or the program stored on disk already? shouldn't that be covered by the FILE MANAGEMENT SPECIFICATION for the TI-99/4 Home Computer? Do you simply mean the File Format Internal/Variable with Record Length of 254?

Can you share the program lines that belong to the posted code?

[+Ksarul]

Klaus, what he is looking for is a simple way to force the file to be saved in I/V 254 format, even when it is small enough to be saved in PROGRAM format. The two bytes in question may help resolve that, or they may be a red herring--but you are correct, the information may be in the file spec. I'll have to give that one a read again.

[kl99]

is this also triggered when reaching a certain program length within TI-Basic or solely in TI XB? I will check my docs...

[+Ksarul]

Solely with TI Extended BASIC. TI BASIC can't see the expansion memory, and so never runs into a program too large to fit into the VDP memory (although you occasionally run into a program that used nearly every byte of it, so you need to run them from tape or with a CALL FILES(1)).

[RXB]

OMG the reason I posted what I did is it does EXACTLY WHAT YOU ASKED.

 

It takes XB Program Image files and turns them into Internal Variable 254 format.

 

I even showed how you can do this to NORMAL XB or any XB Cart version 110 or RXB or GK XB. (Of course can only be done with GRAM or Emulators)

 

You can no not do this with 2 sector or less XB Program Image Files as they do not have the minimum length to pull this off.

 

Also mentioned in the Video that you might have to add REM or ! to lengthen the lines to get to the minimum limit.

 

All of this is in the second Video. Odd no one watched them?

 

P.S. As I mentioned in Video using anything else but RXB you have to do all files one at time. RXB allows a batch process per even hard drives.

Edited December 7, 2014 by RXB

[senior_falcon]

Rich, I did watch them. The modification to XB is simple, but will not work on a real TI without a gramulator or similar device, which means it is not usable on real iron for most people. I am looking for a way to make this happen with standard TI XB without modification.

[senior_falcon]

The first sector is 10 bytes long and is as described in the first post. Evidently XB reads this to get info on where to start loading the program, where the line number table starts and ends and where the end of the program. After that first sector all of them are 254 bytes long and contain the bytes that make up the program starting at the beginning of the line number table. The last sector is shorter, containing just the right number of bytes to finish loading the program.

[kl99]

can't you directly call with the help of assembler whatever GPL/GROM method is called when the system finds out that it has too few vdp space available?

or you can try to play with CALL FILES(9) or directly play with the highest address VDP address by setting CPU RAM >8370.

[Tursi]

I am trying to understand the makeup of IV254 files. It is all pretty straightforward except for the first sector. Here is an example from one program.

When I did the XB export for Converty9918, these are the notes I took on the first record of the IV254 file. As far as I know they are correct:

 

I don't intend to go into great detail about how the relocation works, except that the header information took time to reverse so it is work documenting here. This only covers the DIS/VAR254 format - the PROGRAM image format is slightly different.

 

The first record is 10 bytes long, and contains these 5 words:

0 Always >ABCD (identification tag?)

1 Start address of line number table (value from >8330)

2 End address of line number table (value from >8332)

3 XOR of start and end addresses of line number table (used for sanity checking)

4 Top of RAM (from >8384?)

 

The rest of the sector is empty, since there wouldn't be room for a full record.

 

The first program record is 254 bytes long (assuming the program is at least), and starts with the line number table. The line number table is all that needs to be modified to relocation the program, and is a list of entries 4 bytes per line. The first entry is the line number as two bytes, the second is the address of the line as two bytes. The addresses in record 0 describe how far the table goes.

[senior_falcon]

Thank you sir!

[Willsy]

What happens if you simply save your second XB program in MERGE format? Does that not write it out as an IV254? I can't remember now!!

[RXB]

Merge is Internal Variable 163 format.

 

I made a case years ago to make a new format for Merge as Display Variable 163 so people could edit the merge files from Text Editors.

 

Current Emulators have Readers for this but not a real editor. And besides a pure text file does not take much longer to load then Internal Variable.

[kl99]

can I actually save a file in PROGRAM format from within a XB program?

- SAVE is only allowed in command mode.

- OPEN/PRINT seem to only create DIS/VAR, DIS/FIX, INT/VAR, INT/FIX but not filetype: PROGRAM.

 

If not then I probably have to jump into assembler for that.

[RXB]

Yes afraid the only way is using Assembly.

 

You can try out Classic99 using RXB or MESS also has a RXB if you want to try out other ways to do this.

[kl99]

thx Rich.

[+acadiel]

I always wondered by programs that were extremely large (i.e. the "Yesterday" song in XB) were saved in IV/254 format vs. PROGRAM. I know it has to do with fitting segments into VDP and offloading them to 32K (as discussed), and ones that are too large need to be paged. Any idea why TI designed it that way? Versus something like the EA/5 PROGRAM image format where there were just multiple segments?

[RXB]

It seems a single large file of Display Variable 254 vs loading two files of Program Image would easily out run the Program Image Loader.

 

The Program Image loader has to close the file and open another file to find and load that second Program Image file.

 

You can see that the more times you do this the slower it would become for loading memory.

 

I actually considered a SAMS loader for RXB that used Display Variable 255 loader for the 1 Meg SAMS as it would load 1 Meg much faster than 31 files of 32 sector program image files.

 

If we ever develop a 10 Meg version of the SAMS for the TI99/4A I will do this.

 

The advantages are no one would confuse Dis/Var255 with any other application or programs and a single file would cut down confusion.

[senior_falcon]

Here's an assembly language subroutine that lets you save an XB program in IV254 format.

 

CALL INIT

CALL LOAD("DSKx.SAVEIV254O"

Load or write the XB program

CALL LINK("SAVEIV","DSKx.PROGNAME")

 

 

Note that this would normally be run in the command line mode. If the program is less than 254 bytes long then SAVEIV will insert line #1 into the program. This is a remark long enough to make the program come out to 254 bytes. You will be told if there is already a line #1. Rich, maybe you can incorporate this in your Program format to IV254 format converter. That way you won't have to manually add the remark to a short program to pad the length.

 

(edit) When loading a program, XB is rather particular about the format of the IV254 progam. First there must be a 10 byte long header as described above. The next entry must be 254 bytes long. Any other length (even if it is valid for IV254 format) will upset the XB interpreter which issues an error message. The final entry can be any length from 1 to 254. (further edit) I should add that this utility takes care of all that for you.

SAVEIV254O.zip

Edited December 14, 2014 by senior_falcon

[kl99]

can you outline the differences/advantages between IV254 and the PRG format?

[+InsaneMultitasker]

It seems a single large file of Display Variable 254 vs loading two files of Program Image would easily out run the Program Image Loader.

 

The Program Image loader has to close the file and open another file to find and load that second Program Image file.

 

You can see that the more times you do this the slower it would become for loading memory.

 

I actually considered a SAMS loader for RXB that used Display Variable 255 loader for the 1 Meg SAMS as it would load 1 Meg much faster than 31 files of 32 sector program image files.

 

If we ever develop a 10 Meg version of the SAMS for the TI99/4A I will do this.

 

The advantages are no one would confuse Dis/Var255 with any other application or programs and a single file would cut down confusion.

 

For reference, The program LOAD operation does not require a "close" operation. With fast devices (i.e. RAMdisk, HFDC, SCSI) the load time deltas should be negligible; however, record-based IO is in nearly all cases slower to process than a program image, simply due to the iterative record processing needed.

 

I agree that finding the next file in the chain can take some time and doing this for 20-30 files may slow things down. What I would suggest for a large file loader is using a hybrid approach of record IO and level 2 IO. Set up the file as DV255 (though 128 byte records would be most optimal for memory dumps) but when loading into memory, use level 2 IO. Level 2 IO is how terminal emulators and disk management programs access files during transfers and copy operations. You should then get the best of both worlds for speed and file handling, and could always drop to record IO if a device doesn't play nice with level 2.

 

Also for devices that handle CPU RAM transfers, you can completely bypass VDP and dump straight to RAM. This requires some additional effort on the programmer's part to ensure the device supports the method. The Myarc FDC, HFDC, SCSI, and IDE all support cpu ram transfer IO though most programmers avoid it to keep things simple.

 

Edit: added comment about 128 byte records

Edited December 14, 2014 by InsaneMultitasker

[senior_falcon]

can you outline the differences/advantages between IV254 and the PRG format?

Rich likes IV254 because when you catalog a disk you can easily tell the difference between XB programs and EA programs. To me that seems like it would be quite useful. I think IV254 is a tiny bit slower to load, maybe 2%, but that isn't enough to really matter. If you are chaining XB programs that use XB256, if the program being loaded is in program format it will overwrite all the sound lists, screen2, character definitions for screen2, etc. IV254 avoids this, which is why I have an interest in it.

One drawback to IV254 is that you need memory expansion; a program that would ordinarily run in XB sans 32K will not load if it is in IV254 format.