RXB Posted March 24, 2021 Share Posted March 24, 2021 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) 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 24, 2021 Share Posted March 24, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted March 24, 2021 Share Posted March 24, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 24, 2021 Share Posted March 24, 2021 I guess if TI had decided to give us unsigned integers in BASIC, we would probably have such numbers as addresses for CALL LOAD. 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 25, 2021 Share Posted March 25, 2021 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". 5 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 25, 2021 Share Posted March 25, 2021 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? ? 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted March 25, 2021 Share Posted March 25, 2021 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 25, 2021 Share Posted March 25, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 25, 2021 Share Posted March 25, 2021 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 25, 2021 Share Posted March 25, 2021 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 25, 2021 Share Posted March 25, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted March 26, 2021 Share Posted March 26, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 26, 2021 Share Posted March 26, 2021 Are we sure a negative record number is not reserved for something like EOF or an error condition? 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 26, 2021 Share Posted March 26, 2021 I think I've seen that as common place to do. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 26, 2021 Share Posted March 26, 2021 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 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 26, 2021 Share Posted March 26, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.