Jump to content
9640News

TI Extended Basic Record sizes

Recommended Posts

7 minutes ago, GDMike said:

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

Still a bug with badly thought out logic.

 

They could have just done a much shorter check with one command.

 

 

CB   >00,@>FBFE(15)
  • Thanks 1

Share this post


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

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

 

This was obviously a decision to generally treat hex numbers as signed two's complement numbers. And those hex numbers go from -32768 to +32767.

  • Like 2

Share this post


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

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

This is related to what I was saying earlier. There is no decimal or hex with bits. That's a display function.

You can understand 16 bits of ones as  -1 two's complement, or 65535 (>FFFF) un-signed.

If your system only has one way of understanding a 16 bit data cell, you are kind of hooped.

 

Since TI-BASIC is natively in floating point converting to/from an integer made sense one way... signed.

 

I supposed they could have made another UINT() function to deal with that but I don't think BASIC implementations had that in general. 

 

  • Like 1

Share this post


Link to post
Share on other sites

I guess if TI had decided to give us unsigned integers in BASIC, we would probably have such numbers as addresses for CALL LOAD.

  • Like 3

Share this post


Link to post
Share on other sites
3 hours ago, GDMike said:

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

No, 0-32767 is 32,768 records. They just decided to treat it as a signed value. A byte wouldn't make any difference here, you need 15 bits to hold 32767.

 

We may never know why but it was probably "that's more than you'll ever need". ;)

 

  • Like 5

Share this post


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

We may never know why but it was probably "that's more than you'll ever need". ;)

And they were right. Who wants to wait for 90 minutes anyway? 🙂

  • Like 1

Share this post


Link to post
Share on other sites

Yes, for all practical purposes in this context, it's really enough. And if not, you can make the record larger and store more in each record.

Share this post


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

Yes, for all practical purposes in this context, it's really enough. And if not, you can make the record larger and store more in each record.

Also, can't get that much larger on a 180k disk! ;) Looks like 5 byte records would be the limit, 6 bytes takes you to 192k.

 

Not unreasonable for the TI Disk Controller, and they likely didn't expect every future disk device to be based on that DSR code. ;)

 

  • Thanks 1

Share this post


Link to post
Share on other sites
18 hours ago, mizapf said:

 

This was obviously a decision to generally treat hex numbers as signed two's complement numbers. And those hex numbers go from -32768 to +32767.

Based on what reason?

Again the computer is based on HEX not Decimal so internally this makes no sense!

This is like using Kelvin Temperature for your home.

Share this post


Link to post
Share on other sites
17 hours ago, mizapf said:

I guess if TI had decided to give us unsigned integers in BASIC, we would probably have such numbers as addresses for CALL LOAD.

Again I think this was based on not knowing anything about computers and HEX like a Management decided it.

There is no reason they could not do decimal REC(65530) for example except for someone decided mistakenly that is a negative number.

Share this post


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

No, 0-32767 is 32,768 records. They just decided to treat it as a signed value. A byte wouldn't make any difference here, you need 15 bits to hold 32767.

 

We may never know why but it was probably "that's more than you'll ever need". ;)

 

Yea like the IBM CEO that said no one well ever need a personal computer to Steve Jobs and the Woz.

  • Haha 1

Share this post


Link to post
Share on other sites

Actually, it's only bits inside. HEX is a visualization for humans only.

They (TI) did of course need the concept of signed 16-bit integers in this computer. I'd say the most likely reason for this particular limitaiton was that they could save some rare memory by doing the same, and thought that 32767 records would be a limitaiton nobody would suffer from. Especially since you can pretty easily circumvent the problem by consolidating more than one item into a larger record.

  • Like 2

Share this post


Link to post
Share on other sites

Are we sure a negative record number is not reserved for something like EOF or an error condition?

  • Thanks 1

Share this post


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

Are we sure a negative record number is not reserved for something like EOF or an error condition?

No they use HEX >FFFF (DEC -1) as the file marker of end of file so they could have used >FFFF 

and still have HEX >0001 to >FFFE (DEC 65534 as max record)

 ***********************************************************
[2693]               *                         EOF ROUTINE
[2694]               * EOF(X) returns status codes on file X. The meaning of the
[2695]               * result codes is:
[2696]               *           -1  Physical End Of File
[2697]               *            0  Not at End Of File yet
[2698]               *            1  Logical End Of File
[2699]               ***********************************************************
[2700] 91DE BD,5C,04 EOF    DST  @PABPTR,@ARG      Save the current PAB and set
[2701]               *                              the new one in SUBEOF
[2702] 91E1 06,92,1E        CALL SUBEOF            Try to find the PAB somewhere
[2703] 91E4 57,D7           BR   ERRFE             Can't file
[2704] 91E6 BE,5E,09        ST   CZSTAT,@ARG2      Select status code without
[2705] 91E9 C0,E0,04        EX   @ARG2,[email protected](@PABPTR) destorying original code
       91EC 04,5E
[2706] 91EE 06,97,65        CALL IOCLZ1            Get the info from DSR
[2707] 91F1 C1,04,5C        DEX  @ARG,@PABPTR      Restore original PAB and orig
[2708] 91F4 BC,E0,04        ST   @ARG2,[email protected](@ARG)  I/O code
       91F7 5C,5E
[2709] 91F9 BC,5E,E0        ST   [email protected](@ARG),@ARG2 And pick up STATUS
       91FC 0C,5C
[2710] 91FE 31,00,08        MOVE 8,[email protected],@FAC   Get floating 1
       9201 4A,92,16
[2711] 9204 DA,5E,03        CLOG 3,@ARG2           Test EOF bits
[2712] 9207 72,12           BS   EOFZ2             No EOF indication
[2713] 9209 DA,5E,02        CLOG 2,@ARG2           Physical EOF
[2714] 920C 72,10           BS   G9210
[2715] 920E 83,4A           DNEG @FAC              Make result -1
[2716] 9210 0F,75    G9210  XML  CONT
[2717] 9212 87,4A    EOFZ2  DCLR @FAC              Create result 0
[2718] 9214 0F,75           XML  CONT
[2719] 9216 40,01,00 FLOAT1 BYTE >40,1,0,0,0,0,0,0   * Floating point -1
       9219 00,00,00
       921C 00,00
[2720] 921E D6,42,B7 SUBEOF CEQ  LPARZ,@CHAT       * SYNTAX ERROR
[2721] 9221 41,09           BR   ERRSYN
[2722] 9223 0F,74           XML  PARSE             Parse up to the matching ")"
[2723] 9225 FF              BYTE >FF
[2724] 9226 06,93,5C        CALL CHKCNV            Convert and search for PAB
[2725] 9229 77,CB           BS   ERRBV             Avoid 0's and negatives bad v
[2726] 922B BC,62,17        ST   @DSRFLG,@ARG6     @DSRFLG got changed in CHKCON
[2727] 922E 06,93,71        CALL CHKCON            Check and search tiven filenu
[2728] 9231 BC,17,62        ST   @ARG6,@DSRFLG     @DSRFLG to changed CHKCON
[2729] 9234 01              RTNC                   Condition set : file # exists
[2730]               ***********************************************************
[2731]               *      LOAD / SAVE / MERGE UTILITY ROUTINE
[2732]               * GPNAME gets program name from OLD and SAVE
[2733]               * Can also be used for future implementation of REPLACE
[2734]               * statement. Also gives valuable contribution to updating
[2735]               * of program pointers (VSPTR, STVSPT, FLAG, etc...) and
[2736]               * creation of LOAD/SAVE PAB

 

  • Like 2

Share this post


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

No they use HEX >FFFF (DEC -1) as the file marker of end of file so they could have used >FFFF 

and still have HEX >0001 to >FFFE (DEC 65534 as max record)

Absolutely. But people often prefer to check bits instead of ranges of values because it's easier and faster. I do the same all the time.

  • Like 2

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