Jump to content
IGNORED

What could they have done better with the 99/4a?


Tornadoboy

Recommended Posts

On 5/20/2020 at 7:47 AM, mizapf said:

Agree (with your disagreement), they should even have put TI BASIC in a cartridge. Maybe bundle it with the console.

 

This is also one of those bad ideas, as can be seen in the TI-99/8: built-in programming language. No fix, no upgrade, waste of memory.

RXB runs BASIC with no modifications, but not with EA Assembly Support.

But then TI Basic with Assembly Support is slow and very very limited compared to XB with Assembly support.

Link to comment
Share on other sites

On 5/20/2020 at 8:10 AM, apersson850 said:

At least the built-in operating system on the p-code card's "GROM disk" can be upgraded. You can place an upgrade of a segment of the operating system on the root disk. If you do (this never happened), then the system will use that part instead of the fixed one in GROM on the card.

 

But if TI BASIC didn't occupy two GROMs in the console, you could have had higher capacity modules. Perhaps they designed a nice size for the modules, found they could put five GROMs in there and then put the other three in the console? Since they can address up to eight of them, in an easy way.

 

QI most certainly is an abbreviation for Cost Reduced, nothing else. But that doesn't sound so cool to marketing.

A much better idea is just dump TI Basic and keep XB and those two GROMs should have been used for more OS features like XB Assembly support and Editor Assembly in Console.

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

On 5/22/2020 at 4:52 PM, RXB said:

But then TI Basic with Assembly Support is slow and very very limited compared to XB with Assembly support.

I agree. When I was using BASIC on the TI, it was Extended BASIC supported with assembly to do things not available, or too slow, in BASIC.

  • Like 2
Link to comment
Share on other sites

 
True, if we are talking tech of the past. With the FinalGROM 99 for instance, one could have a new DOS downloaded and installed in mere seconds. The FG99 cartridge is going to make so many things 'possible'... it remains to be seen if the tech will be fully exploited.
Since building my own.. it's been relevatory ( is that a word?)

Sent from my Pixel 4 XL using Tapatalk

Link to comment
Share on other sites

I'm going to be a pessimist and say "lack of foresight".  The "home computer" was probably not intended to have that much memory, otherwise it might complete with the minicomputer (oh no, computers are advancing!?!?)  Laying-out a memory-map in chunks of 8K seemed to be very popular at the time, based on other systems I have looked at of the same era.  The memory-map for the first 32K goes: ROM, Cartridge, Devices (DSR ROMs), memory-mapped devices.  Maybe having the top 32K as RAM expansion *was* always in the design though, but only the 99/4A designers could say for sure.  But not having RAM in the console, other than the 256-bytes of 16-bit scratchpad...  That's the worse design decision IMO.

 

It would have been nice if they had put the 8K of Cartridge space up at >8000, which would have made it contiguous with the 32K RAM expansion.  And it would also have been nice if they had made the >8000 range less wasted and provided a way to expand the 256-bytes of 16-bit RAM.  Or, at least further decoded the >8000 block into 1K blocks; but that would have taken another 74LS138 3-to-8 decoder IC and cost $1.50 more... GASP!  Also, having RAM in the ISR vector memory space would have been a *very* useful design decision.

 

But, knowing why does not change how it is, and sadly making a new system in the spirit of the 99/4A is still not going to be a 99/4A in the end.

Edited by matthew180
Mistakes
  • Like 1
Link to comment
Share on other sites

One thing that would have been very useful, both now and BITD?

 

If TI had produced a better data-recorder, that had a PWM drive control lead, in addition to the REM connector.  Then it would have been possible to have a datasette recorder that could fastforward, rewind, play at half speed, etc--- by sending the cassette mechanism more sophisticated signals.

 

It could (and likely would) have been used for user-port like actions as well (since it would essentially be a 2 wire serial interface without flow control) 

 

 

Link to comment
Share on other sites

Someone please correct me if I’m wrong because I’m not near my TI to try it, but several things I think they could have done better/different involved the cassette I/O.

 

1. Allow for named files/programs on cassette.  Commodore and Radio Shack supported this.

2. Why does each record printed to cassette have the leader tone?  The cartridges that allow for saving data to cassette don’t work this way (I suspect they save in program image format) but TI BASIC programs all produce lots of leader tones, making file processing even slower.

3. Cassette I/O has no EOF detection.  Again, Commodore BASiC could do this.

Link to comment
Share on other sites

I would think that the leader tones are there to give the user some "fudge room" on queuing up a cassette to load. When you press stop (or pause), the tape jerks a little.  A second or two of lead-in gives some time for the user to react to the stimulus and press the button, and some slack for the cassette mechanism itself, so that when playback is resumed, the full front of the program portion is still played back reliably.

 

Lack of named files makes sense when you have a dumb cassette recorder.  Named files (and a file system in general) make sense on a tape that is random access, and not queued linear access.  See my prior suggestion: A smarter cassette system, that can seek forward and backward on the cassette, using a 2 wire PWM communication channel with the cassette deck.

 

Dunno about why they did not add EOF to the cassette data structure.  Likely just the struggle to get to market quickly in time for Christmas, if you want a cynical answer. ?  

  • Like 1
Link to comment
Share on other sites

8 hours ago, wierd_w said:

One thing that would have been very useful, both now and BITD?

 

If TI had produced a better data-recorder, that had a PWM drive control lead, in addition to the REM connector.  Then it would have been possible to have a datasette recorder that could fastforward, rewind, play at half speed, etc--- by sending the cassette mechanism more sophisticated signals.

 

It could (and likely would) have been used for user-port like actions as well (since it would essentially be a 2 wire serial interface without flow control) 

 

 

My assumption is they wanted users to use any old cassette recorder instead of requiring a custom device with additional expense. That was usually the goal with audio cassette storage.

 

  • Like 1
Link to comment
Share on other sites

12 hours ago, wierd_w said:

I would think that the leader tones are there to give the user some "fudge room" on queuing up a cassette to load. When you press stop (or pause), the tape jerks a little.  A second or two of lead-in gives some time for the user to react to the stimulus and press the button, and some slack for the cassette mechanism itself, so that when playback is resumed, the full front of the program portion is still played back reliably.

 

 

The only problem with this is something like this:

 

100 OPEN #1:”CS1”,OUTPUT,INTERNAL,VARIABLE

110 FOR I=1 TO 10

120 PRINT #1:I

130 NEXT I

140 CLOSE #1

 

This produces 10 leader tones while the tape is in the record mode the entire time it is writing.  I mean I get why you’d write one out at the beginning of the file, but not at the beginning of each record.

 

Link to comment
Share on other sites

18 hours ago, wierd_w said:

If TI had produced a better data-recorder, that had a PWM drive control lead, in addition to the REM connector.  Then it would have been possible to have a datasette recorder that could fastforward, rewind, play at half speed, etc--- by sending the cassette mechanism more sophisticated signals.

That would have been pretty fun to watch, but Sears didn't sell one of those! ;) 

 

(I know Sears also re-branded other company's work, but back in the day we had the TI Data Recorder and a Sears branded unit that was identical save the branding).

 

Quote

I would think that the leader tones are there to give the user some "fudge room" on queuing up a cassette to load. 

There is probably some of that, but the tone is also used to calibrate the timing loop in the cassette read code. It's asynchronous data, so the timing needs to match the speed of the tape to be read successfully. Since there was no knowing the exact speed of the tape drive, they needed something known to time against.

 

Arguably multiple records in a single set of data shouldn't really need to do that, but the cassette interface doesn't maintain any state between records.

 

  • Like 1
Link to comment
Share on other sites

You know, a thought occurs to me...

 

It might be possible to send such messages to the cassette deck ALREADY, with what is already available...  It would need a new cassette DSR (and of course, a suitably microcontroller gussied up tape deck), but consider:

 

 

When REM port is active, then any data blasted at the cassette recorder's mic jack should be treated like a PWM control code tone. (the cassette cannot actually read or write data while REM is active anyway.) Upon first use, the TI sends such a message to the recorder, that instructs it to respond immediately with an ACK tone, but if no such tone is received, it falls back to dumb recorder mode. If such an ACK is received, then it knows a smart cassette deck is attached, and it sends messages to the tapedeck while REM is high. The microcontroller embedded into the cassette deck queues up the messages blasted at it, then waits for REM to go low again. It then performs the assigned sequence, and responds with one of 2 ACK tones over its headphone jack, which the TI waits for, before proceeding.

 

I could see one of the stronger arduinos being able to pull this off pretty neatly.

Link to comment
Share on other sites

The lead tone is also there to allow the automatic gain control in the cassette unit (not all of them could set that manually) to "home in" on the signal level to expect. When storing in program image format, only one tone is needed, since then all data is one large block. But for individual records, you need to set it each time.

  • Like 1
Link to comment
Share on other sites

- better power switch

 

   * I remember mine eventually taking a long time to actually stay
     in the correct spot. I should have just unplugged it after it
     was "on" so that I didn't have to fuss with it!

 

- real lowercase letters (insted of smaller capitals)

- separate arrow keys

 

- when resequencing, and there's a missing line number,
  help the programmer instead of giving "32767"

  (there's a program that can resequence better)

 

- down-inserting cartridges

Link to comment
Share on other sites

16 hours ago, GratedTopping said:

- better power switch

 

   * I remember mine eventually taking a long time to actually stay
     in the correct spot. I should have just unplugged it after it
     was "on" so that I didn't have to fuss with it!

 

- real lowercase letters (insted of smaller capitals)

- separate arrow keys

 

- when resequencing, and there's a missing line number,
  help the programmer instead of giving "32767"

  (there's a program that can resequence better)

 

- down-inserting cartridges

Having written GPL for TI Basic and XB for 20 years now, exactly where would you store all these missing number lines to fix them?

Especially in TI Basic that only has 16K of VDP in the first place and less then 12K is available.

Link to comment
Share on other sites

He means, that if you have a situation like this

 

10 PRINT "This is a line. Yay."
PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

 

 

The interpreter should do this:

 

10 PRINT "This is a line. Yay."
11 PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

 

and not this

 

10 PRINT "This is a line. Yay."
32767 PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

Link to comment
Share on other sites

11 minutes ago, wierd_w said:

He means, that if you have a situation like this

 

10 PRINT "This is a line. Yay."
PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

 

 

The interpreter should do this:

 

10 PRINT "This is a line. Yay."
11 PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

 

and not this

 

10 PRINT "This is a line. Yay."
32767 PRINT "This line intentionally has no line ID!"

20 PRINT "This is the next actually numbered line!"

How exactly does the Interpreter know when to magically insert lines?

10 X=2 

20 IF X then 40

PRINT X

30 X=8

40 Y=10

 

See how you are asking for the PRE SCAN to find stuff like this and fix it.

Should I show you all the code for the PRE SCAN currently, and where do you think this should be stored?

The reason TI Basic does not do this is the insane amount of code needed, and XB has same issue.

 

It sounds simple but if you want to fix it go for it RXB code of the XB module is out there and I can give you the original GROM/ROM code if you want.

After all you would have to fix both ROM and GROM to do this.

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

Hmm... Firstly, your line 20 is kinda malformed? "If X" without an operator logically means "if a variable named X exists"...  But that aside--

 

 

The idea I would implement is pretty dumb, and would introduce problems. I will be forthright about that, and it was not my suggestion anyway. :P

 

I would count the number of un-numbered lines between the properly ID'd lines, and check to see if they can logically exist there.

 

EG

 

10 PRINT "This is the first indexed line"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

20 PRINT "This is the second indexed line"

 

would get flagged, because 11 lines are needed, but only room for 10.

 

Otherwise, sequentially number the un-numbered lines with appropriate numbers between the indexes.

 

 

This would introduce problems.  I am well aware of this. Notably, this would be a serious problem for the renumberer.

 

 

10 PRINT "This is some line with a low index!"

500 PRINT "This is a perfectly valid line number, it is just WAAAAAAAY out of sequence."

PRINT "THIS LINE WILL BORK SIMPLISTIC RENUMBERING BAD!"

20 PRINT "We now return to our regularly written program..."

 

 

When you have to deal with "Spaghetti code" syntax, with gotos all over the place, line numbers not in numerical order (but still valid, because not with overlapping IDs.), etc I totally get your point.  Nobody should really be programming like that anyway. Nobody sane that is.

Link to comment
Share on other sites

1 hour ago, wierd_w said:

Hmm... Firstly, your line 20 is kinda malformed? "If X" without an operator logically means "if a variable named X exists"...  But that aside--

 

 

The idea I would implement is pretty dumb, and would introduce problems. I will be forthright about that, and it was not my suggestion anyway. :P

 

I would count the number of un-numbered lines between the properly ID'd lines, and check to see if they can logically exist there.

 

EG

 

10 PRINT "This is the first indexed line"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

PRINT "Oh noez! 11 lines between!"

20 PRINT "This is the second indexed line"

 

would get flagged, because 11 lines are needed, but only room for 10.

 

Otherwise, sequentially number the un-numbered lines with appropriate numbers between the indexes.

 

 

This would introduce problems.  I am well aware of this. Notably, this would be a serious problem for the renumberer.

 

 

10 PRINT "This is some line with a low index!"

500 PRINT "This is a perfectly valid line number, it is just WAAAAAAAY out of sequence."

PRINT "THIS LINE WILL BORK SIMPLISTIC RENUMBERING BAD!"

20 PRINT "We now return to our regularly written program..."

 

 

When you have to deal with "Spaghetti code" syntax, with gotos all over the place, line numbers not in numerical order (but still valid, because not with overlapping IDs.), etc I totally get your point.  Nobody should really be programming like that anyway. Nobody sane that is.

XB has Subprograms and Subroutines to deal with this and you can call them with just a name for example: CALL MYSUBPGM 
So complaints about "Spaghetti code" does not really bother me as even Dennis Ritche said "You can write code in C that even I can not tell you what is going on."

That makes "Spaghetti code" sound like easy to use in comparison. 

 

Also you can write this in XB edit mode:

 

10 PRINT "This is some line with a low index!"

500 PRINT "This is a perfectly valid line number, it is just WAAAAAAAY out of sequence."

PRINT "THIS LINE WILL BORK SIMPLISTIC RENUMBERING BAD!"

20 PRINT "We now return to our regularly written program..."

 

And nothing will be "BORKED", try it and prove me wrong.

Maybe you just did not create a good example here.

 

Do you even know how to program in Basic? 

We see this all the time in Basic or XB:

 

230 X=8 

Edited by RXB
Link to comment
Share on other sites

I do actually, I think you just did not catch the condition I was trying to present.

 

The dumb renumberer would look at the preceeding listed line number to set the LOWBOUND, and then skip forward to find the next listed line number to get the UPPERBOUND.

 

Since 500 is much larger than 20, the lowbound would be higher than the upperbound, which would break the simple renumberer.

 

 

The statement I made about malformed line 20, is that you need an operator.

 

IF X [some operator] THEN 40

 

EG, if you intend for it to be a boolean, you need

 

IF X=TRUE THEN 40

 

= is the operator specifying what kind of evaluation you are checking for. Without such an operator, the only conceivable check to do is if the variable exists or not.

 

Since your sample code is basically just checking for the existence of X as a variable, and it was explicitly defined in line 10, It should exist at this point in execution, the IF statement should return true, and code should jump to line 40.  Code between 20 and 40 will be skipped by program flow (including explicitly labeled line 30). Adding line numbers to the undefined line(s) between, (eg, giving it line number 21), will not impact program execution.  The only time this would not be true, is if you GOTO line 20 after line 40, and somehow delete the variable. Then it will return false, and the next line will (attempt) to execute. No variable named X will exist, and the interpreter should error accordingly.

 

 

Edited by wierd_w
Link to comment
Share on other sites

52 minutes ago, wierd_w said:

Without such an operator, the only conceivable check to do is if the variable exists or not.

That's not true.

IF X THEN 40

is a perfectly legal statement. It evaluates to a jump to line 40 if X is true, which normally means X is -1, but will work for anything that's not zero.

  • Thanks 1
Link to comment
Share on other sites

That is nonstandard behavior--  None of the basics I have used prior would have allowed that.

 

 

(Consider in a vacuum--  You ask the computer "X?"  The logical "no" condition is "No X". Not "X=false". Defining this behavior in this manner is not consistent with proper logic. Most people defining a programming language are sticklers about formal logic and its paradigms. Clearly not TI. (and apparently MS at the time, since we have paperwork now.) )

Edited by wierd_w
Link to comment
Share on other sites

That's normal behavior in every language I use. Including variants of BASIC. So no, it's rather the standard.

The IF statement evaluates an expression. If it comes out to -1 (in many cases, as it's the two-complement of zero), it's true. Some systems use 1 and 0, not -1 and 0.

You can do IF A+7 THEN  and it will be true in all cases except when A is -7. You can do it more complex, like IF (A=3)+(B=12) THEN, which would be equivalent to IF A=3 OR B=12 THEN.

 

The same goes for Pascal, for example, where if done=true then is the same thing as if done then.

Edited by apersson850
  • Like 1
  • Thanks 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...