TI Extended Basic Record sizes

[RXB]

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)

[+mizapf]

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.

[+TheBF]

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. 

 

[+mizapf]

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

[Tursi]

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

 

[Asmusr]

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

[apersson850]

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.

[Tursi]

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.

 

[RXB]

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.

[RXB]

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.

[RXB]

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.

[apersson850]

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.

[Asmusr]

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

[GDMike]

I think I've seen that as common place to do.

[RXB]

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,V@COD(@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,V@COD(@ARG)  I/O code
       91F7 5C,5E
[2709] 91F9 BC,5E,E0        ST   V@SCR(@ARG),@ARG2 And pick up STATUS
       91FC 0C,5C
[2710] 91FE 31,00,08        MOVE 8,G@FLOAT1,@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

 

[Asmusr]

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.