Large file support via assembly?

[matthew180]

One thing I have *never* done in assembly is read or write files to the disk subsystem, so I am totally ignorant about the capability in the 99/4A.

 

Can someone explain any issues I would have trying to read a 200K to 800K file from a single file? Is it even possible to work with a file that big? Of course I'm assuming the file is stored on a CF7+ cf-card, or someone has copied the file to a 99/4A hard disk (as long as the HD interface is the same as the CF7+ or floppy disk).

 

The code would be 100% assembly, and preferably interrupts would be disabled.

[+Lee Stewart]

You should be able to set up a file with a maximum of 32768 records (0 -- 32767). The most efficient record size IIRC is 128 bytes (2 per sector). This would be 4MB. However, CF7+ is limited to 400KB/disk image and floppies to 360KB/ disk with the TI controller, I believe. This is incomplete information, but all I can think of right now.

 

...lee

[Gazoo]

One thing I have *never* done in assembly is read or write files to the disk subsystem, so I am totally ignorant about the capability in the 99/4A.

 

Can someone explain any issues I would have trying to read a 200K to 800K file from a single file? Is it even possible to work with a file that big? Of course I'm assuming the file is stored on a CF7+ cf-card, or someone has copied the file to a 99/4A hard disk (as long as the HD interface is the same as the CF7+ or floppy disk).

 

The code would be 100% assembly, and preferably interrupts would be disabled.

 

File access in assembly is very simple for me, what is difficult is graphics and being able to write some sort of game in assembly. That's probably the reverse of most people in this forum and something I don't quite understand.

 

Nevertheless, I've attached the code that I use to save and restore the sectors of my two 3.2meg ramdisks to/from single files on my hard drive. Each ramdisk is saved as a 12800 sector D/F 128 file by splitting each sector into 2 records. Part of the screen is used as the data buffer so you can actually see the sector data as it's being accessed.

 

The E/A manual is actually quite good at explaining file access, one of it's few good qualities.

 

Gazoo

 

 

save.txt

 

restore.txt

Edited August 14, 2012 by Gazoo

[moulinaie]

One thing I have *never* done in assembly is read or write files to the disk subsystem, so I am totally ignorant about the capability in the 99/4A.

 

Let's say that you want to read a binary file in sequential mode, the file is named "DSK1.F18A" (why not?).

Everything is done in VDP RAM (you have no access directly from a file to CPU RAM)..

Let's say that we will use VDP >1000 as a 128 bytes buffer and >1080 as the PAB address.

 

What is the PAB? a structure you must create that gives informations to the system:

PAB structure:
BYTE 0	 OPCODE for Fopen
BYTE 12 FLAGS (here sequential, input, fixed length, internal)
WORD >1000 data address
BYTE 128 record length
BYTE 128 count
WORD 0 record number, unused for sequential
BYTE 0 screen offset, useful for cassette operations
BYTE 9 name length
TEXT "DSK1.F18A"

 

then for each file call, you must provide this:

 

** FILE ACCESS **
LI R0,>1089	 address of name length
mov R0,@>8356
BLWP @DSRLNK
data 8

 

That should open the file ! An error code is returned in the three high bits of FLAGS, so at address >1081.

If 000x xxxx, then no error.

 

Then you want to read the file...

Change OPCODE to 2 (for fread)

Use the same routine and your buffer at address >1000 should be filled with the first 128 bytes of the file!

The entry COUNT is filled with the actual bytes read count, normally 128...

 

When the error code is 101x xxxx (5), this is that the end of file is reached.

 

Change the OPCODE to 1 (for fclose)

Use the same routine to close the file.

 

That's all.

 

Guillaume.

Edited August 15, 2012 by moulinaie

[+Lee Stewart]

If you want the widest use for your program using the large file access, I would think you would use 256-byte sectors as is used for floppies and CF7+. With 256 bytes/sector, the volume information block (VIB) only has 200 bytes (56--255) available for the file allocation bitmap, which is enough for 1600 sectors. If you want to fill the disk with a single file, you can use all but 3 sectors (sector 0 = VIB; sector 1 = FDIR; sector 2 = FDR for first file). For a CF7+ formatted with 1600-sector "disks", this would be 1600 - 3 = 1597 sectors for a 399.25KB file. The same situation for a DSDD floppy would be 1440 - 3 = 1437 sectors for a 359.25KB file.

 

...lee

[+retroclouds]

Must interrupts be enabled for doing file access or can they stay disabled ?

[moulinaie]

Must interrupts be enabled for doing file access or can they stay disabled ?

 

No need for interrupts if using the DSRLNK routines.

I don't use them in MLC and file access works well!

 

Guillaume.

[Tursi]

Leave interrupts off, not sure if the DSR turns them off for you but it accesses VDP memory and interrupts would interfere with that.

 

Remember (if it matters) that on a TI disk controller the maximum disk size is only 180k (double sided single density). You need a double-density controller to get 360k. But as for maximum file size in terms of the DSR interface, yeah, you're just limited by the record indexes.

 

The maximum density is obtained with Fixed/128 files, as was previously mentioned. You can't do Fixed/256 because the byte length count reserves 0 for 'DSR selects', so the maximum fixed record size is 255 bytes, which wastes a byte. (And the maximum variable record size is also 255 because one byte is reserved for the record length). With fixed/128 you get two records per 256 byte sector.

[+InsaneMultitasker]

One thing I have *never* done in assembly is read or write files to the disk subsystem, so I am totally ignorant about the capability in the 99/4A.

 

Can someone explain any issues I would have trying to read a 200K to 800K file from a single file? Is it even possible to work with a file that big? Of course I'm assuming the file is stored on a CF7+ cf-card, or someone has copied the file to a 99/4A hard disk (as long as the HD interface is the same as the CF7+ or floppy disk).

 

The code would be 100% assembly, and preferably interrupts would be disabled.

 

File access in assembly is very simple for me, what is difficult is graphics and being able to write some sort of game in assembly. That's probably the reverse of most people in this forum and something I don't quite understand.

 

Nevertheless, I've attached the code that I use to save and restore the sectors of my two 3.2meg ramdisks to/from single files on my hard drive. Each ramdisk is saved as a 12800 sector D/F 128 file by splitting each sector into 2 records. Part of the screen is used as the data buffer so you can actually see the sector data as it's being accessed.

 

The E/A manual is actually quite good at explaining file access, one of it's few good qualities.

 

Gazoo

 

 

 

Have you considered writing to the last record first to pre-allocate the file? It is quite likely that for every allocation unit you consume, the bitmap is read and written. This can cause some thrashing with physical devices and may decrease the lifespan of flash media (if no wear leveling within the device) due to the constant writing of sectors 1-31.

 

Of course, if you're file is already there it's just once & done. Probably.

[+Lee Stewart]

Have you considered writing to the last record first to pre-allocate the file? It is quite likely that for every allocation unit you consume, the bitmap is read and written. This can cause some thrashing with physical devices and may decrease the lifespan of flash media (if no wear leveling within the device) due to the constant writing of sectors 1-31.

 

Of course, if you're file is already there it's just once & done. Probably.

 

If you want to fill up the disk with one file, you just subtract 3 from the total number of sectors on the disk, multiply by 2 for 128-byte records, open the file and, as you say, write to the last zero-based record of the file. That will allocate all of the available space, including sectors 3-33. That's what I did in TI Forth to allow accessing a Forth screens disk by normal file I/O.

 

...lee

Edited August 17, 2012 by Lee Stewart

[+InsaneMultitasker]

Have you considered writing to the last record first to pre-allocate the file? It is quite likely that for every allocation unit you consume, the bitmap is read and written. This can cause some thrashing with physical devices and may decrease the lifespan of flash media (if no wear leveling within the device) due to the constant writing of sectors 1-31.

I should note the implication in Gazoo's case is that on a hard disk device controlled by the IDE, HFDC, or SCSI card, sectors 1-31 contain the bitmap. Because the bitmap is allocated to the file as the file grows, failure to allocate space up front results in a lot of extra drive activity where the bitmap is concerned. The FDR (file descriptor record) is also updated as the file grows, accounting for each cluster allocated and resulting in excessive writes to the FDR sector.

[+Lee Stewart]

Yeah, what I wrote above only applies to floppy or floppy-like DSRs that have a sector allocation bitmap that occupies only 200 bytes of sector 0.

 

...lee