Jump to content
9640News

TI Extended Basic Record sizes

Recommended Posts

Anyone know what the maximum number of records that can be written with TI Extended Basic?  Running some tests on a 16 MB HRD, and I hit a limit of 32768 with ABasic on the Geneve.  Trying to determine if it is a 32K limit, or a 64K limit.


Beery

  • Like 1

Share this post


Link to post
Share on other sites

Wondering if other basics peak out at 32768 without file swapping and resetting files.

I don't know, but I'm just watching what you come up with.

 

Share this post


Link to post
Share on other sites
31 minutes ago, 9640News said:

Anyone know what the maximum number of records that can be written with TI Extended Basic?  Running some tests on a 16 MB HRD, and I hit a limit of 32768 with ABasic on the Geneve.  Trying to determine if it is a 32K limit, or a 64K limit.


Beery

 

 

Page 295 E/A manual

 

image.thumb.png.998753ffe13acbd114ad817e2d1d9c0f.png

 

  • Like 4

Share this post


Link to post
Share on other sites
10 hours ago, TheBF said:

 

 

Page 295 E/A manual

 

image.thumb.png.998753ffe13acbd114ad817e2d1d9c0f.png

 

Thanks for the info.  @InsaneMultitasker

 

Will need to add writing/reading a second file into my testing loop.

 

Beery

Share this post


Link to post
Share on other sites
34 minutes ago, 9640News said:

Thanks for the info.  @InsaneMultitasker

 

Will need to add writing/reading a second file into my testing loop.

 

Beery

Most interesting, since record numbers are positive numbers, I guess this was implemented with signed numbers being taken into account?

Share this post


Link to post
Share on other sites

Here is the test I am running right now against a 16 MB HRD image in MAME.  I confirmed the original file, TESTREC when deleted, I had the correct number of free sectors  as I did when the drive was originally formatted.  Between the 32766 sector file, and the 32000 sector file that will be written, I should have about 20 sectors free.  The test is running now and will likely take 90+ minutes unless I get an error beforehand.

 

image.thumb.png.59264b15851836aae0de7513ba9b9f10.png

  • Like 5

Share this post


Link to post
Share on other sites
On 3/19/2021 at 9:59 AM, InsaneMultitasker said:

Most interesting, since record numbers are positive numbers, I guess this was implemented with signed numbers being taken into account?

Which is weird since nobody wants to access a negative record number. :) 

16 bits turned on is the same number whether you want to see it as -32768 or 65535.  It's just how you choose to interpret them.

 

I wonder if they just never imagined anybody ever needing more than 2^15 records on a little computer that they purposely hobbled.

 

They had no idea the kind of people that would be stretching it 40 years later. :) 

  • Like 2

Share this post


Link to post
Share on other sites

They probably were More hopeful that this 40th anniversary would be seeing it's upteenth update to a user friendly machine running the"TIKNOWS" search engine, on a 128 bit bus using a southwest bridge optical motherboard, with 16 CPUs with dual mufflers on a 16K true depth GPA running virtual parsec in a hologram room.

  • Haha 1

Share this post


Link to post
Share on other sites
11 hours ago, TheBF said:

16 bits turned on is the same number whether you want to see it as -32768 or 65535.  It's just how you choose to interpret them.

Ehh, no. You're right in principle (it's about interpretation), but unsigned 2's complement 65535 is signed -1. Signed -32768 is unsigned 32768.

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, apersson850 said:

Ehh, no. You're right in principle (it's about interpretation), but unsigned 2's complement 65535 is signed -1. Signed -32768 is unsigned 32768.

It still looks like 16 ones to the hardware no?

And for a file system record number field, the system designer simply states how it is to be understood. (un-signed)

 

I suppose for languages that mandate 2's complement signed interpretation of all 16 bit fields and no way to specify unsigned 16 bit int, this would be awkward.

Perhaps this is why the system limits to 15 bits because of TI BASIC. (?)

  • Like 2

Share this post


Link to post
Share on other sites
On 3/19/2021 at 6:59 AM, InsaneMultitasker said:

Most interesting, since record numbers are positive numbers, I guess this was implemented with signed numbers being taken into account?

The DSR does not care about Signed Numbers it uses Hex not Dec so there is no sign here. 

>FFFF is the maximum record so that in Decimal is 65535 I think it incorrect to say 32767.

>7FFF is last positive number in Decimal, but like I said the DSR is not written in Decimal.

Share this post


Link to post
Share on other sites

RXB 2001 to RXB 2020 has CASSETTE control CALL IO( 4,80,4096) this would 4 = Write, Length of records 80, and VDP address >1000

Someone with a Cassette just do not put in a tape and try to write ENDLESS number of Records.

Spoiler

IO (CASSETTE ACESS) PAGE I12
-------------------------------------------------------------
CASSETTE INPUT/OUTPUT/VERIFY INSTUCTION
Format CALL IO(type,length,vdp-address[,...])
The three different cassette I/O instructions use the same
format. The write and read instructions physically perform
Input/Output to the cassette. The verify instruction will
read a tape and compare it, byte by byte, against what is in
the specified VDP area. All will report an I/O error if one
is detected. No prompts are present with these three formats.
These three types control the cassette directly so no prompt
will tell the user to turn on or off the cassette record/play
buttons. The programmer must inform the user with own prompt.
Programs
(Presently I have no cassette to write programs with.)
AUDIO GATE
----------
CRU bit 24 is the audio gate which allows data being read to
be heard. If the bit is set to 1, the data being read is
heard, and if the bit is set to 0, the data is not heard.
Setting the bit to a 0 or 1 is done with an IO instruction, or
a Assembly instruction.
MOTOR CONTROL
-------------
There are two CRU bits (22 and 23) used to control cassettes
1 and 2, respectively. When there is no Cassette IO being
done, both motors remain on. When Cassette IO is specified,
the DSR (Device Service Routine) will control the data being
read. If there are two motor units connected, the data will be
read simultaneously, or you may have the option of reading
data from one motor unit and playing the recorded voice from
another motor unit through the TV (Monitor) speaker.
*NOTE:
Compatibility with or without 32K or other devices is not a
concern as IO needs no RAM to work with. Therefore from just
a console all IO commands will work fine. If you only have a
Cassette and RXB you can quickly load/save/verify without
menus, or just make up your own.

 

Share this post


Link to post
Share on other sites
Posted (edited)

It's not about how you write the numbers but how you compare them.

 

li r0,32768

ci r0,32767

jh xxx            ; true (unsigned)

 

li r0,32768

ci r0,32767

jgt xxx           ; false (signed)

 

You could also write 32768 as >8000 or -32768 and you would still get the same result.

Edited by Asmusr
Swapped unsigned and signed in the comments
  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, Asmusr said:

It's not about how you write the numbers but how you compare them.

 

li r0,32768

ci r0,32767

jh xxx            ; true (signed)

 

li r0,32768

ci r0,32767

jgt xxx           ; false (unsigned)

 

You could also write 32768 as >8000 or -32768 and you would still get the same result.

 

What is the purpose to limit it to have the possible limit to a 16 bit computer?

Purpose? Reason for this? Page 294 EA Manual:

 

697 All Record Number (Only required for a relative record type file.) The record number on which the current 110
                                                                                                     operation is performed. The most-significant bit
                                                                                                      is ignored, so this number can be from 0 through
                                                                                                      32767

 

This seems to be a stupid concept for a 16 bit computer address limited to 15 bits for what reason?

 

Ok found the problem in XB source:

[3023]               ***********************************************************
[3024]               * PARREC parses a possible REC clause in INPUT, PRINT or
[3025]               * RESTORE. In case a comma is detected without a REC clause
[3026]               * following it, the COND is set upon return. In case a REC
[3027]               * clause is specified for a file opened for SEQUENTIAL
[3028]               * access, a * FILE ERROR is given.
[3029]               ***********************************************************
[3030] 94C2 D6,42,B3 PARREC CEQ  COMMAZ,@CHAT      Only check if we have a ","
[3031] 94C5 54,EE           BR   G94EE
[3032] 94C7 0F,79           XML  PGMCHR            Check next token for REC
[3033] 94C9 D6,42,DE        CEQ  RECZ,@CHAT        May be USING clause
[3034] 94CC 53,8C           BR   RTC
[3035] 94CE DA,E0,05        CLOG 1,[email protected](@PABPTR)
       94D1 04,01
[3036] 94D3 77,D7           BS   ERRFE
[3037] 94D5 0F,79           XML  PGMCHR            Get first character of expres
[3038] 94D7 06,93,90        CALL OUTEOF            Output possible pending outpu
[3039] 94DA 86,E0,03        CLR  [email protected](@PABPTR)    Clear record offset
       94DD 04
[3040] 94DE 0F,74           XML  PARSE             Translate the expression in R
[3041] 94E0 B5              BYTE COLONZ
[3042] 94E1 06,93,5C        CALL CHKCNV            Check numeric and convert to
[3043] 94E4 D2,4A,00        CGE  0,@FAC             2 byte integer, Bad Value
[3044] 94E7 57,CB           BR   ERRBV
[3045] 94E9 BD,E0,0A        DST  @FAC,[email protected](@PABPTR) Store actual record number
       94EC 04,4A
[3046] 94EE 00       G94EE  RTN

Line 3042 converts from DECIMAL TO HEX problem it USES the SIGN so this limits the REC(32767) as CHKCNV uses signs.

I could fix this in RXB to be a limit of 65535 instead.

Just use a routine I use for SAMS that uses 65535 as the upper limit of a number for input.

 

Guess I found something else in XB to fix!
 

  • Like 1

Share this post


Link to post
Share on other sites
17 minutes ago, RXB said:

 

What is the purpose to limit it to have the possible limit to a 16 bit computer?

Purpose? Reason for this? Page 294 EA Manual:

 

697 All Record Number (Only required for a relative record type file.) The record number on which the current 110
                                                                                                     operation is performed. The most-significant bit
                                                                                                      is ignored, so this number can be from 0 through
                                                                                                      32767

 

This seems to be a stupid concept for a 16 bit computer address limited to 15 bits for what reason?

 

Ok found the problem in XB source:

[3023]               ***********************************************************
[3024]               * PARREC parses a possible REC clause in INPUT, PRINT or
[3025]               * RESTORE. In case a comma is detected without a REC clause
[3026]               * following it, the COND is set upon return. In case a REC
[3027]               * clause is specified for a file opened for SEQUENTIAL
[3028]               * access, a * FILE ERROR is given.
[3029]               ***********************************************************
[3030] 94C2 D6,42,B3 PARREC CEQ  COMMAZ,@CHAT      Only check if we have a ","
[3031] 94C5 54,EE           BR   G94EE
[3032] 94C7 0F,79           XML  PGMCHR            Check next token for REC
[3033] 94C9 D6,42,DE        CEQ  RECZ,@CHAT        May be USING clause
[3034] 94CC 53,8C           BR   RTC
[3035] 94CE DA,E0,05        CLOG 1,[email protected](@PABPTR)
       94D1 04,01
[3036] 94D3 77,D7           BS   ERRFE
[3037] 94D5 0F,79           XML  PGMCHR            Get first character of expres
[3038] 94D7 06,93,90        CALL OUTEOF            Output possible pending outpu
[3039] 94DA 86,E0,03        CLR  [email protected](@PABPTR)    Clear record offset
       94DD 04
[3040] 94DE 0F,74           XML  PARSE             Translate the expression in R
[3041] 94E0 B5              BYTE COLONZ
[3042] 94E1 06,93,5C        CALL CHKCNV            Check numeric and convert to
[3043] 94E4 D2,4A,00        CGE  0,@FAC             2 byte integer, Bad Value
[3044] 94E7 57,CB           BR   ERRBV
[3045] 94E9 BD,E0,0A        DST  @FAC,[email protected](@PABPTR) Store actual record number
       94EC 04,4A
[3046] 94EE 00       G94EE  RTN

Line 3042 converts from DECIMAL TO HEX problem it USES the SIGN so this limits the REC(32767) as CHKCNV uses signs.

I could fix this in RXB to be a limit of 65535 instead.

 

Guess I found something else in XB to fix!
 

But the disk DSR will not care about it so probably should not be very high on your work list.  

And... CHKCNV might turn it into a negative number which would probably burp in the DSR code. (?) 

 

 

  • Confused 1

Share this post


Link to post
Share on other sites
8 minutes ago, TheBF said:

But the disk DSR will not care about it so probably should not be very high on your work list.  

And... CHKCNV might turn it into a negative number which would probably burp in the DSR code. (?) 

 

 

Hmmm I would not use CHKCNV I would use a RXB routine that I use for SAMS that has page limit up to 65535 UNSIGNED instead thus fix issue.

And RXB always gets updates so will be fixed in next version I release.

New FEATURE RXB has upper limit change to REC clause from old limit of 32767 upgraded to 65535.

 

I will test it in my new RXB 2021 on REAL IRON before release.

Share this post


Link to post
Share on other sites
1 minute ago, RXB said:

Hmmm I would not use CHKCNV I would use a RXB routine that I use for SAMS that has page limit up to 65535 UNSIGNED instead thus fix issue.

And RXB always gets updates so will be fixed in next version I release.

New FEATURE RXB has upper limit change to REC clause from old limit of 32767 upgraded to 65535.

Is there a disk card that can handle 65K records?

  • Confused 1

Share this post


Link to post
Share on other sites
Posted (edited)

Dat'  be da' bottom scoop.

Yup tecno slang...I read it somewhere, oh yeah, I wrote it down and read it.

 

Edited by GDMike

Share this post


Link to post
Share on other sites
Posted (edited)
17 hours ago, TheBF said:

It still looks like 16 ones to the hardware no?

And for a file system record number field, the system designer simply states how it is to be understood. (un-signed)

 

I suppose for languages that mandate 2's complement signed interpretation of all 16 bit fields and no way to specify unsigned 16 bit int, this would be awkward.

Perhaps this is why the system limits to 15 bits because of TI BASIC. (?)

Yes, it's 16 ones, but as soon as you start interpreting them as anything else than fence poles, you have to do it with some kind of system.

Now Rich has already found that it's the conversion from integer to floating in BASIC that assumes signed integers. And they are 2's complement.

Edited by apersson850
  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
19 hours ago, TheBF said:

Is there a disk card that can handle 65K records?

DISK floppy or flippy NO!

SCSI or IDE or SD can handle it. Also MESS and Classic99 can too.

I have a TIPI so should be able to handle it also.

  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, RXB said:

DISK floppy or flippy NO!

SCSI or IDE or SD can handle it. Also MESS and Classic99 can too.

I have a TIPI so should be able to handle it also.

Not that I see any value in doing this but you could, for example, create a DF4 file at 64 records/sector*1440 sectors = 92,160 records, which would well exceed both record limits.

 

Do the aforementioned device DSRs accept a record number greater than 32767?   I'lve never tried nor had a need to test.  SCSI and IDE (and others) will only handle more records if the DSR is programmed to allow it. (Edit:  and it might be good to test before adjusting RXB, if you haven't already tested).

  • Like 3

Share this post


Link to post
Share on other sites

I ran a test in Classic99 using the TI disk controller on a 180k disk - using the 4 byte record idea as a test. I attempted to write 32,780 records. It failed out with an error 34 right at record 32769... Buffer Full.

 

Looks like the routine at >5510 in the TI DSR checks for negative record number, and rejects it if so. (Code from Theirry's disassembly).

 

       MOVB @>FBFE(15),1      get record # from PAB
       SWPB 1
       MOVB @>FBFE(15),1
       SWPB 1
       MOV  1,0               save it
       JLT  A553C             too big
       JMP  A5542             ok
A553C  BL   @A4C72            update data then return with error
       DATA >8000             "memory full"
A5542  INC  0                 next record

 

So, for TI at least, the record number limit is 32767. (TI BASIC numbers starting from 1, while the DSR starts at 0, so the 32769 is really 32768 under the hood ;) )

 

 

 

 

 

  • Like 4

Share this post


Link to post
Share on other sites
2 hours ago, Tursi said:

I ran a test in Classic99 using the TI disk controller on a 180k disk - using the 4 byte record idea as a test. I attempted to write 32,780 records. It failed out with an error 34 right at record 32769... Buffer Full.

 

Looks like the routine at >5510 in the TI DSR checks for negative record number, and rejects it if so. (Code from Theirry's disassembly).

 

 

       MOVB @>FBFE(15),1      get record # from PAB
       SWPB 1
       MOVB @>FBFE(15),1
       SWPB 1
       MOV  1,0               save it
       JLT  A553C             too big
       JMP  A5542             ok
A553C  BL   @A4C72            update data then return with error
       DATA >8000             "memory full"
A5542  INC  0                 next record

 

 

So, for TI at least, the record number limit is 32767. (TI BASIC numbers starting from 1, while the DSR starts at 0, so the 32769 is really 32768 under the hood ;) )

 

 

 

 

 

So why they did this is in the Disk Drive DSR beyond just weird? 

This looks like a misunderstanding of Decimal vs Hex and that in Decimal can go up to 65535 which would be >FFFF

Like most goofy thing in TI99/4A it is a bug they did not catch.

(It may be a goofy confusion of CALL PEEK or CALL LOAD that can only go positive to 32767 before it goes negative.)

Share this post


Link to post
Share on other sites
Posted (edited)

We're they just using one byte to save the value vs a word maybe? Else they'd be deliberately looking for 32768.

Edited by GDMike

Share this post


Link to post
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.

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...