What the PAB?!

[ralphb]

Consider these PABs for reading a DIS/VAR 40 file with the TI floppy controller:

 

pab_open_read:
       data >0014, pab_buf, >2800, >0000, >000d
       text 'DSK1.OVERRIDE'

pab_read1:
       data >0214, pab_buf, >2828, >0000, >000d
       text 'DSK1.OVERRIDE'

pab_read2:
       data >0214, pab_buf, >2828, >0001, >000d
       text 'DSK1.OVERRIDE'

pab_read3:
       data >0214, pab_buf, >2801, >0002, >000d
       text 'DSK1.OVERRIDE'

pab_close_read:
       data >0115, pab_buf, >2800, >0000, >000d
       text 'DSK1.OVERRIDE'

 

Executed one by one with some additional glue code, the read operations return (without error):

• record 0
• record 0
• the first char of record 0

 

Why does the program read record 0 three times in a row, instead of advancing to record 1?  

 

(It should be noted that I do not update single bytes in the PAB from one operation to the next, but overwrite the entire PAB according to the list above.  But I don't know which secret information should be lost this way.)

 

[+TheBF]

This is a dump of my PAB while the machine is reading the contents of a file.  It is a DV80 file.  Yours appears to be >28 byte records.

I notice that the record number does not change because it is a sequential file.

In a relative file you can get at any record by changing the record no. field, but SEQUENTIAL files do it automatically.

 

Try reading repeatedly without changing the record number and see if the text in the pab buffer changes.  You should also see different values in the 5th field that reflects the number of bytes actually read.  In the example above the record length is >50 but the line that was read only had >1 bytes in it. (empty line)

 

 ok                                                                             
36A9 80 VDUMP                                                                   
36A9: 0114 36D2 5001 0000 050A 4453 4B31 2E38 ..6.P.....DSK1.8                  
36B9: 3043 4F4C 0000 0000 0000 0000 0000 0000 0COL............                  
36C9: 0000 0000 0000 0000 0020 4147 454C 5341 ......... AGELSA                  
36D9: 5048 4943 5320 2820 2D2D 2029 2054 4558 PHICS ( -- ) TEX                  
36E9: 5420 4752 4150 4849 4353 203B 7420 6966 T GRAPHICS ;t if                  
36F9: 2079 6F75 2061 7265 2075 7369 6E67 2038  you are using 8                  
3709: 3043 4F4C 5320 616E 6420 4752 4150 4849 0COLS and GRAPHI                  
3719: 4353 6500 0000 0000 0000 0000 0000 0000 CSe.............                  
 ok                                                                             
CAPTURE DSK3.PABDUMP                                                            
                         

Edit:  I also see you show D in the error field while I show 5. That might be a problem.

      

Edited August 20, 2019 by TheBF

[ralphb]

Thanks, but changing all record numbers to 0 didn't change the result.

 

This is so strange, because I remember I succeeded in the past.  I must be doing something simple wrong.

[+TheBF]

The error code D is probably the clue.

[+TheBF]

>D0 means error code 6.  Device error. 

[+InsaneMultitasker]

Are you sure the file is open/still open? It almost looks like you are seeing the same information in the buffer because the DSR is not really reading anything beyond the initial read.  Recommend you not set byte 5 before calling the DSRLNK to perform your read; same may go for byte 1. 

[ralphb]

1 hour ago, InsaneMultitasker said:

Are you sure the file is open/still open? It almost looks like you are seeing the same information in the buffer because the DSR is not really reading anything beyond the initial read.  Recommend you not set byte 5 before calling the DSRLNK to perform your read; same may go for byte 1. 

 

Argh, this is actually quite funny.  First of all, to detect the "not reading anything" case, I invalided the buffer before each read -- but I invalided the RAM buffer, not the VDP buffer.  Fixing that, I saw exactly what you suggested.

 

Then I was checking for errors, but for simplicity I only checked for error code 1-7.  And you guessed it, it was error 0 for the second read.

 

Also, about byte 5 containing the number of bytes to read.  Originally, I put zero there.  Theirry describes it this way, whereas the E/A manual is ambiguous.  But when I ran that, I noticed that the length of the results for read 2 and 3 actually depend on the number I put there, so I thought you're supposed to supply that number.  In hindsight, it was just I myself that provided the result length, since the DSR didn't really run at all.

 

The PABs now look like this:

 

pab_open_read:
       data >0014, pab_buf, >2800, >0000, >000d
       text 'DSK1.OVERRIDE'

pab_read1:
       data >0214, pab_buf, >2800, >0000, >000d
       text 'DSK1.OVERRIDE'

pab_read2:
       data >0214, pab_buf, >2800, >0000, >000d
       text 'DSK1.OVERRIDE'

 

Why would read 2 throw an error?

 

EDIT: Oops, forgot about byte 1, but setting it to zero didn't change anything.

Edited August 20, 2019 by ralphb

[ralphb]

I changed the code so that it would just update byte 0 and byte 5 in the PAB, instead of overwriting the entire PAB, and made it use the E/A DSRLNK -- but no change.

 

Looking at the data sector of file OVERRIDE, everything looks fine.

 

But the FDR shows only one level 3 record at bytes >12->13, instead of two!

 

arcturus ~/ti99 > xdm w.dsk -S ">3"
00:  4F 56 45 52  52 49 44 45  20 20 00 00  80 06 00 01   OVER RIDE   .. .... 
10:  41 28 01 00  00 00 00 00  00 00 00 00  33 00 00 00   A(.. .... .... 3... 
20:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   .... .... .... .... 
     ...
F0:  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   .... .... .... .... 

 

[+TheBF]

It's sounds like you need to publish the entire program for the group to see it more clearly.

Something fundamental is different than when you used this code and it worked. 

(Happens to me all the time. One tiny innocent change and oops!)

 

 

[ralphb]

17 hours ago, TheBF said:

It's sounds like you need to publish the entire program for the group to see it more clearly.

Something fundamental is different than when you used this code and it worked. 

 

Fair enough.   Attached is the source code, and the disk image with the file OVERRIDE to read, and the E/A#3 file PUB to read it.  In the top left-hand corner you see the status, in the right-hand corner you may see E for error and L for zero-length result.  Right now you see L for reading the second record.  The file OVERRIDE was created in BASIC.

 

It's probably something really simple, but I'm currently stumped.

 

w.dsk pub.asm

[+Lee Stewart]

You probably already know this, but you can test for EOF with opcode = 9, which puts the status information in byte 8 of the PAB. Byte 8’s LSb will be set if at EOF.

 

...lee