Casey

Actually all of the "answers" to the error message work at any prompt. If you type in OLD CS1, and press R when it says "Rewind Cassette Tape" - it will say it again. You can press C and it will "check" instead of "read" even when that doesn't make sense to do. I'm not sure if it actually loads anything if you tell it to check though.

Very interesting. The beige model in the last image is like the one I got when TI was getting rid of them here in the USA. The box, however, is very different, and reminds me of the TI 99/4 box

While I did not do it for 8 hours a day, my first job which I was still in high school was at the public library in my town. At that time, the library had an Apple IIe for patrons to use, but the library's circulation database was managed by an IBM PC XT with the green phosphor monochrome monitor. Transaction backups were written to floppy disk every 30 or so transactions. At some point we got a new version of the database application and it just could not run well on the XT. The interactive part was ok, but when it would do the transaction backup to floppy disk, that would take up to 20 minutes instead of the 30 seconds from the previous version. The XT was then replaced with an IBM PS/2 386 (with monochrome VGA monitor) and the XT was relegated to the back office where it was used to create card catalog cards, book spine labels, and it would write those records onto a floppy disk that we could take over to the PS/2 to import into the database. Since the machines were not networked (no network at all in the library), this was how we interchanged information between them. Years later, I was given that PC XT... I wish I still had it.

Just to add to what others have said: TI BASIC (And Extended BASIC) have commands built in for loading and saving programs and manipulating files (OPEN, DELETE, PRINT#, INPUT#, etc). None of these commands are device specific, but the file name portion of the command indicates which device it is to be sent to (similar to a device number for the Commodore). Where Commodore machines send commands to the disk drive to do things like format, copy, etc - TI uses a cartridge to do those things. Disk Manager (and Disk Manager 2) were the official TI cartridges, but as mentioned, other vendors produced their own that worked with their hardware. When you bought a disk drive for a TI, you needed to purchases a disk controller if you didn't have one (either a standalone peripheral device or a card for the PEB). The disk controller included the Disk Manager (or Disk Manager 2) cartridge as part of the package. I assume that would be the same with the non-TI controllers.

Others I can think of: TP SPEECH ALPHON MINIMEM EXPMEM2

From Thierry's page - this may answer some of your questions: https://www.unige.ch/medecine/nouspikel/ti99/cassette.htm

I actually would have loved to have had an Amiga, but by the time I bought my first PC (1992), everyone I knew had a PC and every computer I used at school was also a PC, so that's why I went that direction.

I used it. My first PC compatible computer was a Tandy 1000 RL - replacing a Commodore 128. But when I bought it, I didn't have any software - certainly not word processing software. So the built in Text application was very useful to me. That the spelling checker was built into ROM made it much faster than what I had used in the past with the Commodore. I also had an ACT preparation program that used a runtime version of DeskMate.

About 20 years ago, I was working a part time job at a grocery store's meat department. We used electronic scales that would print barcoded labels for people's purchases. Strangely, this scale system we had used a TPDD to back up its database to floppy disk. No need for a TRS-80 Model 100/102 either.

The only other difference I can think of is that 99/4A TI BASIC issues: * WARNING: CHECK PROGRAM IN MEMORY in the case where OLD fails, but 99/4 BASIC does not. A brain cell way in the back part of my brain seems to think I read that somewhere that OLD on the 99/4 clears memory first, and on the 99/4A does not, but I don't remember where I read that. Aren't there some bug fixes in the 99/4A TI BASIC also? Some things with INPUT causing lock ups? And I think 99/4A TI BASIC does not return a true zero for CALL KEY in some cases where the 99/4 does in certain situations. I remember an addendum stating that after using CALL KEY(1,K,S) to check for IF S+1=1 instead of IF S = 0 or something like that.

Ditto - My first computer was a TI 99/4A and we could only afford tape (and truthfully, we bought this computer when it was closed out for $50 - I'm not sure we could have even found all the gear needed for disk). My next computer was a Commodore 128 with a 1571 disk drive. I would have never considered using tape with it unless there was no choice.

When I was in high school, our writing classroom had 2 daisy wheel printers. 1 was a Diablo 630, it was shared by 8 PCs. The other was not branded as Diablo but looked exactly like it (can't remember its brand) - it was shared by 8 Xerox CP/M machines. These used carbon based ribbons. They produced fantastic looking output, but they were quite loud. My recollection is that the Diablo 630 was faster than the other one, but not by much.

I think except in the case of arrays like B%(X) - CBM BASIC has to convert the integer back to floating point before it uses it. You can save memory space and execution time if you are processing an integer array, but otherwise I don't think it buys you much.

^^ This is what I was essentially typing when Rich's post showed up. TI BASIC commands are tokenized and interpreted by the TI BASIC interpreter program, which is written in GPL. The TI BASIC interpreter program has GPL instructions (compiled) to do the statements of a TI BASIC program, which the GPL interpreter executes as needed by the TI BASIC program. Is this accurate? (feels like it, but want to make sure).

Ask yourself a couple of questions. What code does the CPU run? How does a TI BASIC command end up being something the CPU can execute? Now, ask yourself the same questions for a Commodore PET. What code does the CPU run? How does a Commodore BASIC command end up being something the CPU can execute? The answers to these questions will explain how people get to the conclusion they do about TI BASIC.

For the record, js99er works great on an iPad Pro. I was surprised it worked at all when I tried it out. Oddly I was able to save a file to tape but not mount the .wav file again after I saved it, but I'm sure it's the iPad's fault. Still, I was very pleasantly surprised it worked at all since no other emulators seem to work on iPads.

I think this works the way you wanted your example program to work? 1 ON ERROR 100 2 CALL INIT 3 PRINT "SUCCESS" 4 STOP 100 CALL ERR(A,B,C,D)::PRINT A;B;C;D::RETURN NEXT On real hardware, without 32K, this prints the 4 error numbers, then prints "SUCCESS" and stops. With 32K, it only prints SUCCESS.

I think the CALL CHAR method works in standard TI Extended BASIC also? (Just during program run - it resets to a block when the program ends, right?)

Sort of related to this question, and I am certain I may have asked a variation of it before, but since the TI BASIC interpreter can run BASIC programs that are stored in GROM (some of the TI cartridges are that) - what is required to make a TI BASIC program run from GROM? If it was possible to make one, then it seems like it would be possible to save a program in a format that would run from the FG99 via the TI menu screen. Certainly not the easiest thing to do I would imagine, but possible? It also wouldn't work for Extended BASIC naturally.

I'd offer up the Commodore 1541 disk drive as a whole. The only reason it exists in the first place is that the 1540 was not compatible with the 64 because it was too fast. By that time, Commodore already had the hardware bug fixed and could have made a fast disk drive for the 64 (like the 1571 was later to the 128). But they chose to just make the 1540 even a bit slower so that it was compatible with the 64. That was a dumb decision.

It might have been a bit more successful as a hybrid business/home computer if it had an 8088 instead of a Z80, though that would have driven the cost up. MS-DOS would have been a lot more useful in 1985 than CP/M. If it had been possible to use the REUs with the 8088, you could have had a fairly decent MS-DOS machine and yet still had all of the C-64 software available as well.

I think the only thing the TI version lacks is multi-voice sound in some of the sound effects, and the "how high can you go?" screens. Strangely the blue barrels in the girder screen don't cause fireballs to spawn from the oil drum at the bottom of the screen. Graphically, it's an excellent version. I had this game back when I first got the TI in 1983, but I had a cartridge that would crash on the elevator screen almost every time you'd get to it, so it was exchanged for Pac Man.

Some games (most) use port 2. Some games used port 1. BITD, if the joystick didn't respond to one port, you had to plug it into the other. On The C64, the default for the joystick is port 2. You can force a game to use port 1 by adding a _J1 to the file name. Example: my_game.d64 becomes my_game_J1.d64 You can't make it universal, because Commodore 64 software did not work that way. Port 1 is less frequently used because it interferes with several keys on the left side of the keyboard.

There were 2 issues that Bill Herd stated was the reason for the Z80 in the 128. 1 was the CP/M cartridge. The 64's CP/M cartridge wouldn't run on the 128 when it was in development as was stated before. And the Magic Voice (speech synthesizer) cartridge would crash the 128 when it was plugged in. They utilized the Z80 to look for the Magic Voice cartridge and properly initialize 64 mode before booting. One thing I've always read but never fully believed. The 128's boot process was stated as using the Z80 to check for the presence of a CP/M boot disk before launching 128 mode. That seems backwards to how it appears to work. If you stick a CP/M disk in a 1571 and turn on a 128 - the first thing that happens is Commodore BASIC starts and it checks track 1 sector 0 for the boot sector. Finding none, it returns to the command level with READY. If it finds a boot sector, it initiates whatever the boot sector tells it to. In the case of a CP/M disk, that would switch the Z80 back on and load CP/M - but something in that boot sector has to initiate that. I feel like that's done via the 8502 and not the Z80. Does anyone know for sure? I've always been curious.

Because BASIC 2.0 fit in 8K of ROM. Thus, it was cheaper to manufacturer. Remember also that when the VIC 20 was introduced, it only had 5K of RAM and no disk drive. So there was no perceived need for the disk commands in BASIC 4.0, which is really the main thing lacking in BASIC 2.0.