Jump to content
IGNORED

Question about PABs in assembly.


Kchula-Rrit

Recommended Posts

While playing with the source code for Tom Bentley's TCIO library, I sent it a PAB opened for the RS232 board ("SIO.BA=9600") with OUTPUT+SEQUENTIAL+DISPLAY+VARIABLE-80 mode.  Then I accidentally sent it a WRITE PAB with zero as the byte-count.  By the documentation, a zero byte-count means "write until the next NULL byte."  When the "light show" hit, I knew something was wrong, so I threw the power switch.  I really need to put a reset button on my system.

 

That prompted a couple of questions.  The record-length in a PAB is specified in one byte.  This makes sense, since a TI sector is 256 bytes.  How would you get a 256-byte record?  Could you specify a record-length of zero to get 256 bytes, or does that tell the system to assume a default.  The manuals I have (the blue ones that came with the RS232 and disk controller boards) are rather vague about it.  They talk about BASIC, and its default values, but nothing about doing it with assembly.

 

Does anyone still use C99?  I managed to cut the object code down from 4357 bytes to 1852, a savings of 2495 bytes.  Would it be ethical to post it here?  No attempt at plagiarism intended, just thought it might be useful.

 

K-R.

 

Link to comment
Share on other sites

1 hour ago, Kchula-Rrit said:

That prompted a couple of questions.  The record-length in a PAB is specified in one byte.  This makes sense, since a TI sector is 256 bytes.  How would you get a 256-byte record?  Could you specify a record-length of zero to get 256 bytes, or does that tell the system to assume a default.  The manuals I have (the blue ones that came with the RS232 and disk controller boards) are rather vague about it.  They talk about BASIC, and its default values, but nothing about doing it with assembly.

 

The maximum record size for VARIABLE record type is 254 bytes due to a 1-byte overhead per record and 1-byte overhead per sector. The max for FIXED type is 255 due to the one-byte slot in the PAB for record size, which, of course, wastes one byte per sector. There is nothing special about a zero value (probably an error). The only way to pack all 256 bytes/sector with data is to create a file with a FIXED record type and a record size that evenly divides 256. 128 bytes/record, i.e., 2 records/sector, is the largest record size that uses all of the available space per sector.

 

If you really must have a 256-byte record, you would need to effect that with software.

 

...lee

  • Like 1
Link to comment
Share on other sites

10 hours ago, Kchula-Rrit said:

While playing with the source code for Tom Bentley's TCIO library, I sent it a PAB opened for the RS232 board ("SIO.BA=9600") with OUTPUT+SEQUENTIAL+DISPLAY+VARIABLE-80 mode.  Then I accidentally sent it a WRITE PAB with zero as the byte-count.  By the documentation, a zero byte-count means "write until the next NULL byte."  When the "light show" hit, I knew something was wrong, so I threw the power switch.  I really need to put a reset button on my system.

 

That prompted a couple of questions.  The record-length in a PAB is specified in one byte.  This makes sense, since a TI sector is 256 bytes.  How would you get a 256-byte record?  Could you specify a record-length of zero to get 256 bytes, or does that tell the system to assume a default.  The manuals I have (the blue ones that came with the RS232 and disk controller boards) are rather vague about it.  They talk about BASIC, and its default values, but nothing about doing it with assembly.

 

Does anyone still use C99?  I managed to cut the object code down from 4357 bytes to 1852, a savings of 2495 bytes.  Would it be ethical to post it here?  No attempt at plagiarism intended, just thought it might be useful.

 

K-R.

 

How I got around this is in RXB I use Program Image files, 4K in size ones so that fits perfectly into 4K pages of SAMS RAM. (Also 32K pages)

Now what is preventing you from making 256 byte Program Image files?

 

It occurred to me I had tested 12K Program Image files for speed loading the SAMS that is 4K*3=12K

so to bad we need VDP as where is PAB for 16K ? 

Guys how come a DSR card for Disk or SCSI or IDE or RAMDISK does not have a 256K buffer on it for files?

You still need a pab but the location is in the DSR Buffer and fakes the VDP buffer.

Edited by RXB
comment added
  • Thanks 1
Link to comment
Share on other sites

You're absolutely right Rich. So much potential for a DSR is lost because it needs a VDP PAB and buffer space.

 

The Corcomp disk controller had subroutines that would let you read and write directly to CPU addresses. I think it still had the hard requirement of a PAB in VDP though. And since it wasn't nearly common enough it didn't get used.

 

What would be nice is if TIPI had a built in routine to read and page directly to AMS. Give it a page start, disk file, and let it just read right into it until complete and then branch to page and address of your choosing. The load times and speed is going to be the biggest bottleneck with the system.

  • Like 1
Link to comment
Share on other sites

10 hours ago, adamantyr said:

I believe a 0 value for length is interpreted as a default record length of 80 bytes.

 

I ran into this issue myself in my CRPG. I ended up going to sector read/write and just dropping the use of record abstractions for a lot of my data access.

This will sound like a dumb "question," but I assume this means you don't use the "filesystem" approach and just read and write pure data blocks?  I used to work on computers long before I heard people talked about "abstract" stuff in relation to them...

 

K-R.

Edited by Kchula-Rrit
  • Like 1
Link to comment
Share on other sites

1 hour ago, RXB said:

How I got around this is in RXB I use Program Image files, 4K in size ones so that fits perfectly into 4K pages of SAMS RAM. (Also 32K pages)

Now what is preventing you from making 256 byte Program Image files?

 

It occurred to me I had tested 12K Program Image files for speed loading the SAMS that is 4K*3=12K

so to bad we need VDP as where is PAB for 16K ? 

Guys how come a DSR card for Disk or SCSI or IDE or RAMDISK does not have a 256K buffer on it for files?

You still need a pab but the location is in the DSR Buffer and fakes the VDP buffer.

I had often wondered that, since file I/O is through the DSR, is it an absolute requirement that file-transfers go through the VDP?  It seems to me that transferring DEVICE<=>RAM BUFFER<=>VDP<=>CPU RAM makes for a pretty slow system.

 

I tried disassembling the disk DSR for the NanoPEB (I like doing that kind of thing to see how it works) and it left me wondering if the builder is in a padded cell somewhere. 8-)  It would probably be easier with a schematic to get an idea of where everything is, address-wise, and how it works.

 

But then, all the information I've read indicates that every transfer (disk/RS232/whatever) wants its data stored in the (slow) VDP RAM.  The TI99 really could have been something if the builders hadn't hobbled so badly.

 

I suppose one could make a peripheral that bypasses the VDP, but it would probably be incompatible with pretty much all existing programs.  Sort of like when WinVista and Win7 came out and none of my telescope-control software worked anymore. 8-(

 

K-R.

 

K-R.

  • Like 2
Link to comment
Share on other sites

10 hours ago, Lee Stewart said:

 

The maximum record size for VARIABLE record type is 254 bytes due to a 1-byte overhead per record and 1-byte overhead per sector. The max for FIXED type is 255 due to the one-byte slot in the PAB for record size, which, of course, wastes one byte per sector. There is nothing special about a zero value (probably an error). The only way to pack all 256 bytes/sector with data is to create a file with a FIXED record type and a record size that evenly divides 256. 128 bytes/record, i.e., 2 records/sector, is the largest record size that uses all of the available space per sector.

 

If you really must have a 256-byte record, you would need to effect that with software.

 

...lee

Thanks for the answer.  I don't really need 256-bytes, just curious if it could be done.  I've seen setups where the data-length is stored in a byte, and a zero value meant 256 bytes.  The "light show" I got would seem to confirm your idea that, for TCIO, a zero-length record is an error.  I assumed it was a runaway VDP-write transfer that trashed the VDP setup tables.

 

K-R.

 

  • Like 1
Link to comment
Share on other sites

22 minutes ago, Kchula-Rrit said:

But then, all the information I've read indicates that every transfer (disk/RS232/whatever) wants its data stored in the (slow) VDP RAM.  The TI99 really could have been something if the builders hadn't hobbled so badly.

Well, yes, what else should you do if you spared all CPU memory except for those 256 bytes? The decision was there at an early stage, and the engineers had to live with it. Of course, there is a way to use the memory expansion directly, since we don't have a DMA to VDP RAM, but you have to write your own device drivers (for all different kinds of controller, not a lot of fun).

  • Like 1
Link to comment
Share on other sites

2 hours ago, Kchula-Rrit said:

This will sound like a dumb "question," but I assume this means you don't use the "filesystem" approach and just read and write pure data blocks?  I used to work on computers long before I heard people talked about "abstract" stuff in relation to them...

 

K-R.

I still use the file system, I just access the files via their sectors, rather than use a record system. There are DSR subroutines to do this; access files via sector and you get the whole 256 bytes of a sector at a time.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

5 hours ago, Kchula-Rrit said:

I had often wondered that, since file I/O is through the DSR, is it an absolute requirement that file-transfers go through the VDP?  It seems to me that transferring DEVICE<=>RAM BUFFER<=>VDP<=>CPU RAM makes for a pretty slow system.

 

I tried disassembling the disk DSR for the NanoPEB (I like doing that kind of thing to see how it works) and it left me wondering if the builder is in a padded cell somewhere. 8-)  It would probably be easier with a schematic to get an idea of where everything is, address-wise, and how it works.

 

The Nano 'floppy' DSR is based off the TI disk controller DSR , which uses VDP RAM quite extensively (and is therefore also slower than most other controllers) for operations.  Reviewing Thierry's site is a good way to get familiar with how the nano works and how (and sometimes why) TI wrote the DSR the way they did. 

 

"Newer" peripherals often provided PAB and Buffer options for CPU ram, however, many (most?) programmers avoided them for compatibility reasons. Instead, new programs that could have made use of faster, direct transfers are relegated to the VDP->CPU memory moves, unless of course the target is VDP ram :)

 

  • Like 1
Link to comment
Share on other sites

4 hours ago, Kchula-Rrit said:

I had often wondered that, since file I/O is through the DSR, is it an absolute requirement that file-transfers go through the VDP?  It seems to me that transferring DEVICE<=>RAM BUFFER<=>VDP<=>CPU RAM makes for a pretty slow system.

 

That's the way it was on the 4A, which would not have any significant CPU RAM.

 

A revision to the file spec for later (never shipped) home computers remedied that. The PAB is extended and it has a flag for whether the destination address is in CPU or VDP RAM. But that's not our world.

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Worth noting that the standard is if you open with a record length of 0, the DSR is supposed to fill in its default record size. That's 80 bytes on the disk controller, but for instance the thermal printer that we recently hacked throws 32 in there.

 

For reading/writing full sectors on a diskette without any wasted bytes, use Fixed/128 record size. That fits exactly two records per sector and this is the reason that "foreign" files are stored by XModem software as IF128.

 

  • Like 2
Link to comment
Share on other sites

1 hour ago, InsaneMultitasker said:

"Newer" peripherals often provided PAB and Buffer options for CPU ram, however, many (most?) programmers avoided them for compatibility reasons.

This is the reason why Extended Basic II from the 99/8 does not run with a 99/4A disk controller in the PEB. It sets up a PAB in CPU RAM (because it can), and the legacy controllers assume the address is in VRAM.

Link to comment
Share on other sites

13 hours ago, adamantyr said:

I still use the file system, I just access the files via their sectors, rather than use a record system. There are DSR subroutines to do this; access files via sector and you get the whole 256 bytes of a sector at a time.

 

This is a most interesting discussion. Can you share some details on how you exactly do this?

 

For my TiVi editor I'm currently using normal file I/O to load DV80 files. But ofcourse it takes time when loading >100KB even from ramdisk/HDR or TIPI. So I'm considering alternatives to speed things up (at least for HRD). 

 

Link to comment
Share on other sites

2 hours ago, apersson850 said:

There is a disc sector read/write subprogram in the disk controller card. That's in all of them. That's what the file system uses on its lowest level, since it reads a sector at a time, then converts these sectors to records.

 

This is how TI Forth does screen/block I/O. This method uses DSR Level 1 Read/Write Sector subprogram >010 via what is termed a transfer block at FAC (>834A in 16-bit scratchpad memory) instead of a PAB in VRAM as required by DSR Level 3 file I/O. Only one sector at a time is transferred to a program-designated 256-byte buffer in VRAM. TI Forth moves 4 contiguous sectors (1 at a time) into a 1 KiB VRAM buffer before copying said buffer to a CPU RAM block buffer for Forth’s use. This kind of sector access is obviously dangerous as it totally disregards the file system and can easily trash a disk that contains files such as does the TI Forth system disk. That is the main reason I developed fbForth (from TI Forth), which uses DSR Level 3 file-record I/O (eight 128-byte records/block) via VRAM PABs to manage Forth blocks located in separate blocks files.

 

...lee

  • Like 1
Link to comment
Share on other sites

45 minutes ago, Lee Stewart said:

 

This is how TI Forth does screen/block I/O. This method uses DSR Level 1 Read/Write Sector subprogram >010 via what is termed a transfer block at FAC (>834A in 16-bit scratchpad memory) instead of a PAB in VRAM as required by DSR Level 3 file I/O. Only one sector at a time is transferred to a program-designated 256-byte buffer in VRAM. TI Forth moves 4 contiguous sectors (1 at a time) into a 1 KiB VRAM buffer before copying said buffer to a CPU RAM block buffer for Forth’s use. This kind of sector access is obviously dangerous as it totally disregards the file system and can easily trash a disk that contains files such as does the TI Forth system disk. That is the main reason I developed fbForth (from TI Forth), which uses DSR Level 3 file-record I/O (eight 128-byte records/block) via VRAM PABs to manage Forth blocks located in separate blocks files.

 

...lee

Has anyone every written an alternate DOS that uses raw sectors? 

As I write this I remember that USCD Pascal seems to have a different disk system but I am thinking more along the lines of putting an MS DOS format on TI disks for example.

Link to comment
Share on other sites

21 hours ago, Kchula-Rrit said:

I had often wondered that, since file I/O is through the DSR, is it an absolute requirement that file-transfers go through the VDP?  It seems to me that transferring DEVICE<=>RAM BUFFER<=>VDP<=>CPU RAM makes for a pretty slow system.

 

I tried disassembling the disk DSR for the NanoPEB (I like doing that kind of thing to see how it works) and it left me wondering if the builder is in a padded cell somewhere. 8-)  It would probably be easier with a schematic to get an idea of where everything is, address-wise, and how it works.

 

But then, all the information I've read indicates that every transfer (disk/RS232/whatever) wants its data stored in the (slow) VDP RAM.  The TI99 really could have been something if the builders hadn't hobbled so badly.

 

I suppose one could make a peripheral that bypasses the VDP, but it would probably be incompatible with pretty much all existing programs.  Sort of like when WinVista and Win7 came out and none of my telescope-control software worked anymore. 8-(

 

K-R.

 

K-R.

 

 

So the entire solution is just have a DSR that ignores the VDP use except for the PAB the DATA buffer in VDP is never really used.

Well nothing is preventing you from putting >C000 or >6000 in the PAB DATA BUFFER of the PAB.

It is after all the DSR that checks the location of the DATA BUFFER, and of course would crash TI Disk Controller, but not a new DSR.

Just take out TI DSR and pop in another that used RAM address instead.

Edited by RXB
comment added
Link to comment
Share on other sites

3 hours ago, RXB said:

 

 

So the entire solution is just have a DSR that ignores the VDP use except for the PAB the DATA buffer in VDP is never really used.

Well nothing is preventing you from putting >C000 or >6000 in the PAB DATA BUFFER of the PAB.

It is after all the DSR that checks the location of the DATA BUFFER, and of course would crash TI Disk Controller, but not a new DSR.

Just take out TI DSR and pop in another that used RAM address instead.

I thought the PAB data buffer was required to be in VDP RAM, then the calling program does a VMBR to get the data into "normal" RAM.  It just never occurred to me to try doing so.  I tend to assume that the people who make these things that I use (C99, TCIO, etc.) are smarter than me and know what they're doing.

 

Since I'm playing with the TCIO code already, I could try it.

 

I have frequently thought of playing with DSRs but I worry about breaking equipment that I consider irreplaceable.  Are TIs fairly bullet-proof in that respect?

 

K-R.

  • Like 1
Link to comment
Share on other sites

In reference to my question about sending a zero-length record to NanoPEB, it finally occurred to me to use TIDir to look at source files I had transferred using TELCO XMODEM protocol.

 

Lee Stewart said that a record is a length-byte followed by the data.  I found several zero-bytes which correspond to blank lines in the source file.  It seems that the E/A cartridge stores a blank line as a one-byte followed by a space.  That makes sense.

 

It would seem that my runaway program and the corresponding "light show" are either my program or the TCIO library.  Looks like some more experiments are in order.

 

It seems my little question has prompted a bit of a stir. 8-)

 

K-R.

Link to comment
Share on other sites

9 hours ago, retroclouds said:

 

This is a most interesting discussion. Can you share some details on how you exactly do this?

 

For my TiVi editor I'm currently using normal file I/O to load DV80 files. But ofcourse it takes time when loading >100KB even from ramdisk/HDR or TIPI. So I'm considering alternatives to speed things up (at least for HRD). 

 

They're described on the tech pages under Subprograms in the Disk controller section:

 

http://www.nouspikel.com/ti99/titechpages.htm

 

File Input and File Output, which will just read and write a sector count to a file, ignoring record structures if present.

  • Like 2
Link to comment
Share on other sites

1 hour ago, Asmusr said:

What is the best approach if you want to read from a named file sector by sector? I mean, how do you know which sectors to read?

If it recall correctly, I read on Thierry Nouspikel's site that Sectors 0 and 1 have the file-names.  I assume you would have to look up the list of sectors for the particular file-name and read them one-by-one.

 

K-R.

  • Like 1
Link to comment
Share on other sites

While investigating my runaway light show problem, I think I found a bug in TI's VMBW routine!  Here's a disassembly of the VMBW routine:


VMBW_START                                                                2200
       BL   @VDP_SET_WRITE_ADDR         >06A0,>223A        '..":'         2200

VMBW_LOOP                                                                 2204
* Get data from caller's buffer,
*  pointed-to by R1 MS byte,
*  and send to VDP.
       MOVB *R1+,@VDPWD                 >D831,>8C00        '.1..'         2204

* Done?
       DEC  R2                          >0602              '..'           2208

* If not, send another byte.
       JNE  BW                          >16FC              '..'           220A

* Return to caller.
       RTWP                             >0380              '..'           220C

If R2 is zero (writing zero bytes to VDP) it will decrement before the check, sending 65536 bytes to the VDP, causing the "lights show," and trashing any PABs and other stuff.  VMBR has the same "problem."

 

Maybe not necessarily a bug; TI probably did not expect someone to send "nothing" to the VDP.

 

K-R.

Edited by Kchula-Rrit
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...