Specialized file access from XB

[+Vorticon]

Hi.

I'm trying to read records from a TI Artist pattern file, which is essentially the pattern descriptor table for the VDP, from XB. (image file attached).

It's trivial to do from assembly, but I've been stumped trying to figure it out in XB. My goal is to read each individual byte to send to a device. I've tried something like this and I get an IO error 02 on line 20, meaning that the file attributes are incorrect. Does anyone know what the correct attributes are? I've tried several combinations to no avail...

I checked the file in TI99 DIR and it's fine.

10 CALL CLEAR
20 OPEN #1:"DSK1.AEN_P",INPUT,INTERNAL, FIXED 80
30 IF EOF(1) THEN 60
40 INPUT #1:A
50 PRINT A
60 END

AEN_P.zip

[+arcadeshopper]

 

Hi.

I'm trying to read records from a TI Artist pattern file, which is essentially the pattern descriptor table for the VDP, from XB. (image file attached).

It's trivial to do from assembly, but I've been stumped trying to figure it out in XB. My goal is to read each individual byte to send to a device. I've tried something like this and I get an IO error 02 on line 20, meaning that the file attributes are incorrect. Does anyone know what the correct attributes are? I've tried several combinations to no avail...

I checked the file in TI99 DIR and it's fine.

10 CALL CLEAR
20 OPEN #1:"DSK1.AEN_P",INPUT,INTERNAL, FIXED 80
30 IF EOF(1) THEN 60
40 INPUT #1:A
50 PRINT A
60 END

 

This is a "program" image file.. not a internal fixed file.. I don't think basic can open a program image file natively. there's no option for that..

 

Greg

[Tursi]

I don't know of any way either.. you'll need assembly support to read a PROGRAM image file. You could, alternately, convert the type to DF/128 on the PC (no change to the data, only the header), and then XB could read it 128 bytes at a time.

[+Vorticon]

 

This is a "program" image file.. not a internal fixed file.. I don't think basic can open a program image file natively. there's no option for that..

 

Greg

 

I was afraid of that... Oh well, I'll just have to write a small assembly support routine to be called from XB to read the file and return the data to XB.

[+Vorticon]

I don't know of any way either.. you'll need assembly support to read a PROGRAM image file. You could, alternately, convert the type to DF/128 on the PC (no change to the data, only the header), and then XB could read it 128 bytes at a time.

 

Good to know, although it would be cumbersome from a work flow perspective if I have to convert every file manually.

[+9640News]

Did Barry Traver's original program that created an "archive" of multiple images have a sector i/o reader for a file from XB? If so, he could possibly read it in that way with the program. In this case, I think to handle strings, you need to use A$ instead of A as a variable, and the string would be 256 bytes long for each sector, or bytes 0 to 255 depending upon how you count. You could then process each character of the string.

 

Beery

[Tursi]

XB only allows 255 byte strings, unfortunately, so reading entire sectors isn't that easy. XXB worked around it by giving you two 128 byte strings to work with (wasn't perfectly ideal for this scenario, though, since it's a raw sector read rather than a file sector read).

[+InsaneMultitasker]

One option within XB is to reserve 6K of VDP by changing the appropriate pointers and using a short assembly routine to load the _P file into the reserved VDP space. A second routine could pass the data via string or array. Might be possible to use the array index number as a pseudo "record" number to calculate the desired byte offset you are trying to read from memory.

[+Vorticon]

I just need to read the data sequentially, which should be straightforward, especially since the file size is fixed.

In the simplest scenario, I'll have XB pass on the file name to the assembly routine which will open and read the data and pass it on byte by byte back to XB. I'll do some tests tomorrow. It's terribly inefficient but it should be workable...

[Tursi]

I'd recommend the XXB approach, just specify a file sector offset rather than a disk sector number, and return two 128 byte strings representing the entire sector. That way you'll have the whole block in one read, and that will keep performance reasonable. It also means you won't need a buffer for the entire PROGRAM image in VRAM, like you would with LOAD.

 

Of course, if that's not a worry and simple is more important, then just loading it all up and feeding back bytes meets that criteria too!

[+InsaneMultitasker]

I'd recommend the XXB approach, just specify a file sector offset rather than a disk sector number, and return two 128 byte strings representing the entire sector. That way you'll have the whole block in one read, and that will keep performance reasonable. It also means you won't need a buffer for the entire PROGRAM image in VRAM, like you would with LOAD.

What is XXB? I've used XB disk sector IO routines like the one you describe but don't recall coming across an XB variant/utility for file sector IO. Sounds like a good one for the toolbox!

[RXB]

 

Hi.

I'm trying to read records from a TI Artist pattern file, which is essentially the pattern descriptor table for the VDP, from XB. (image file attached).

It's trivial to do from assembly, but I've been stumped trying to figure it out in XB. My goal is to read each individual byte to send to a device. I've tried something like this and I get an IO error 02 on line 20, meaning that the file attributes are incorrect. Does anyone know what the correct attributes are? I've tried several combinations to no avail...

I checked the file in TI99 DIR and it's fine.

10 CALL CLEAR
20 OPEN #1:"DSK1.AEN_P",INPUT,INTERNAL, FIXED 80
30 IF EOF(1) THEN 60
40 INPUT #1:A
50 PRINT A
60 END

Hmm RXB 2015 has CALL SECTOR so you could read the sectors into XB and look at the values in Decimal or Hex using CALL HEX that converts them.

 

SECTOR subprogram PAGE S3

-------------------------------------------------------------

Format CALL SECTOR(pathname,read/write-flag,#sectors,sector-string,[,...])

CALL SECTOR(number,number,number,string[,...])

CALL SECTOR(string-variable,numeric-variable,numeric-variable,string-variable[,....])

Description

The SECTOR subprogram reads or writes sectors on disk or

hard drives. The pathname determines the device used and the

pathname can be up to 255 characters in length. The Myarc

HFDC can only support 29 characters pathnames plus the

filename of 10, so that would add up to 39 characters total.

The pathname must end with a period and the directory may

only be 10 characters in length. The read/write-flag may be

any number to read sectors and 0 will write sectors. The

#sectors ranges from 1 to 32 sectors being read/written

at one time. The sector-string is a Hexadecimal string of

the sector to read or write. Sector-string may be a "0" or

up to "FFFFFFFF" or in other words in decimal form ranges

from 0 to 4294967295 sectors. (2 Terabyte Hard Drive)

NOTE: The lower 8K for assembly support is used as a buffer

for SECTOR so anything in the lower 8K will be corrupted.

That means two things.

1. AMS support can store the sectors for duplication.

2. SECTOR is totally compatible with CORCOMP, MYARC...

This means you can read up to 32 Sectors at a time and if you use the SAMS an entire 720 Sector disk.

Edited October 13, 2018 by RXB

[Tursi]

XXB was a package that Barry Traver released back in the day that added a set of CALL LINKs. The docs categorize the extensions as Disk, Character sets, text mode (40 col), graphics mode, peeks and pokes, noises, and misc. I used the sector functions a lot back then.

 

RXB might actually be faster if you have a cart for it... otherwise, here's the disk.

 

XXB.DSK

[senior_falcon]

 

Hi.

I'm trying to read records from a TI Artist pattern file, which is essentially the pattern descriptor table for the VDP, from XB. (image file attached).

It's trivial to do from assembly, but I've been stumped trying to figure it out in XB. My goal is to read each individual byte to send to a device. I've tried something like this and I get an IO error 02 on line 20, meaning that the file attributes are incorrect. Does anyone know what the correct attributes are? I've tried several combinations to no avail...

I checked the file in TI99 DIR and it's fine.

You might be able to do this with TML. You can load a picture, then there are two additional routines described on pages 28-29 of the manual. One returns the pixel at any given coordinates and the other returns a hexadecimal character definition (8x8 block) at any given coordinates. A deal breaker for you might be that the TML screen can only be 240 pixels wide.

[+Vorticon]

You might be able to do this with TML. You can load a picture, then there are two additional routines described on pages 28-29 of the manual. One returns the pixel at any given coordinates and the other returns a hexadecimal character definition (8x8 block) at any given coordinates. A deal breaker for you might be that the TML screen can only be 240 pixels wide.

 

Oh that actually might work perfectly for me! The width limitation is only 16 pixels off so really not a huge problem for my application. Are there any limitations with TML regarding calling external custom assembly routines? I have to access a hardware driver I wrote from the XB environment...

 

To clarify my project, I built a custom X-Y plotter table for the TI along with a controller which is driven by the TI. I want to be able to take a pattern table image and draw it using the plotter, all from within the XB environment (with assembly support of course). So in the TML scenario, XB will load and display the image then it would be a trivial matter to sequentially pick up the status of each pixel and send it to the plotter. Details on the project here: http://atariage.com/forums/blog/659/entry-14733-x-y-plotter-table-for-the-ti-994a-computer-updated-10618/

[+Vorticon]

 

 

Hi.

I'm trying to read records from a TI Artist pattern file, which is essentially the pattern descriptor table for the VDP, from XB. (image file attached).

It's trivial to do from assembly, but I've been stumped trying to figure it out in XB. My goal is to read each individual byte to send to a device. I've tried something like this and I get an IO error 02 on line 20, meaning that the file attributes are incorrect. Does anyone know what the correct attributes are? I've tried several combinations to no avail...

I checked the file in TI99 DIR and it's fine.

10 CALL CLEAR
20 OPEN #1:"DSK1.AEN_P",INPUT,INTERNAL, FIXED 80
30 IF EOF(1) THEN 60
40 INPUT #1:A
50 PRINT A
60 END

Hmm RXB 2015 has CALL SECTOR so you could read the sectors into XB and look at the values in Decimal or Hex using CALL HEX that converts them.

 

SECTOR subprogram PAGE S3

-------------------------------------------------------------

Format CALL SECTOR(pathname,read/write-flag,#sectors,sector-string,[,...])

CALL SECTOR(number,number,number,string[,...])

CALL SECTOR(string-variable,numeric-variable,numeric-variable,string-variable[,....])

Description

The SECTOR subprogram reads or writes sectors on disk or

hard drives. The pathname determines the device used and the

pathname can be up to 255 characters in length. The Myarc

HFDC can only support 29 characters pathnames plus the

filename of 10, so that would add up to 39 characters total.

The pathname must end with a period and the directory may

only be 10 characters in length. The read/write-flag may be

any number to read sectors and 0 will write sectors. The

#sectors ranges from 1 to 32 sectors being read/written

at one time. The sector-string is a Hexadecimal string of

the sector to read or write. Sector-string may be a "0" or

up to "FFFFFFFF" or in other words in decimal form ranges

from 0 to 4294967295 sectors. (2 Terabyte Hard Drive)

NOTE: The lower 8K for assembly support is used as a buffer

for SECTOR so anything in the lower 8K will be corrupted.

That means two things.

1. AMS support can store the sectors for duplication.

2. SECTOR is totally compatible with CORCOMP, MYARC...

This means you can read up to 32 Sectors at a time and if you use the SAMS an entire 720 Sector disk.

 

 

Honestly Rich I think it's time for me to dump XB altogether and stick with RXB! This will simplify things tremendously.

Now here's a newbie question: how may bytes are in a sector using a standard TI controller?

 

Addendum: I just noted from the description of the SECTOR command that it corrupts the lower 8K of memory, so unfortunately I won't be able to use it since I need that area for my assembly routines... Bummer...

[Omega-TI]

I'm starting to wonder, WHAT Vorticon is working on...

[+Lee Stewart]

 

Honestly Rich I think it's time for me to dump XB altogether and stick with RXB! This will simplify things tremendously.

 

Now here's a newbie question: how may bytes are in a sector using a standard TI controller?

 

Addendum: I just noted from the description of the SECTOR command that it corrupts the lower 8K of memory, so unfortunately I won't be able to use it since I need that area for my assembly routines... Bummer...

 

There are 256 bytes/sector for all floppy controllers for the TI-99/4A.

 

...lee

[+Vorticon]

Thanks Lee.

[+chue]

I'm starting to wonder, WHAT Vorticon is working on...

 

[senior_falcon]

Oh that actually might work perfectly for me! The width limitation is only 16 pixels off so really not a huge problem for my application. Are there any limitations with TML regarding calling external custom assembly routines? I have to access a hardware driver I wrote from the XB environment...

 

Yes you can do that. Read the section of the docs called High Memory Assembly Code. Around page 25 or so.

[HOME AUTOMATION]

I'm starting to wonder, WHAT Vorticon is working on...

 

A competing HOME AUTOMATION CONTROL SYSTEM perhaps!!! :-o

[+Vorticon]

Oh that actually might work perfectly for me! The width limitation is only 16 pixels off so really not a huge problem for my application. Are there any limitations with TML regarding calling external custom assembly routines? I have to access a hardware driver I wrote from the XB environment...

 

Yes you can do that. Read the section of the docs called High Memory Assembly Code. Around page 25 or so.

 

Great! I'll take a look this evening.

[+Vorticon]

Well after a couple of hours of hair pulling wondering why my test code was locking up the console, it turned out that DSRLNK is not supported by the XB environment! Please tell me that somebody here has written a homebrew DSRLNK routine because I have no clue how to go about doing this myself...

The other issue is that the image file loading can only be done with the load opcode in the PAB, which means it loads in one shot the entire file contents and dumps it in the VDP. That's not going to work given that it will trash the XB environment...

Obviously senior falcon has solved both problems with TML, so instead of re-inventing the wheel I might just use it!

[Asmusr]

I'm starting to wonder, WHAT Vorticon is working on...

 

A competing HOME AUTOMATION CONTROL SYSTEM perhaps!!! :-o

 

Or perhaps "a custom X-Y plotter table for the TI along with a controller which is driven by the TI."?

Edited October 13, 2018 by Asmusr