Jump to content

Casey

Members
  • Content Count

    367
  • Joined

  • Last visited

Community Reputation

251 Excellent

About Casey

  • Rank
    Moonsweeper
  1. I realize this thread is about the Atari 400, but the TI 99/4A has cursor movement keys for editing typos. It doesn't use a full screen editor like the Atari or Commodore computers do, but it has a line editor and by using various key combinations you can move around in the line, insert characters, delete characters, etc.
  2. For years (at least into the mid 90s), Iowa State University’s College of Engineering’s career office used a TI 99/4A hooked up to a black and white TV as a display showing which companies were coming to interview for jobs and when.
  3. Didn't the 3K expander fit in the memory hole before the 5K that came with computer in the memory map? If the built in RAM was bad, would the computer not start at all with the 3K expander? Or could it possibly start BASIC and show less than 6656 bytes free if the memory test got up to the bad memory? (Just curious)
  4. Yep, I just tried it. Reading DS in BASIC 4.0 affects ST, so the updated version saving it off would work. Some of the dual drives (I think the 8250) also return the drive number where the error occurred. It may not be necessary to retrieve the drive number, but it is there if you need/want it, so I just included it in my example. And you are right. The disk I think only uses 0 and 64 for ST. Cassette has several other values for ST also (64 being end of file as well)
  5. Oh! One other thing I forgot. Any I/O command can cause ST to change, even if you don’t expect it would. That can cause you problems you don’t expect to occur. A common workaround for this is: 100 OPEN 8,8,8,”0:LEVEL1,S,R” 110 INPUT#1,A$:SS=ST 120 PRINT A$ 130 IF SS<>64 THEN 110 140 CLOSE 8 This assures that you know the value of ST right after you do your INPUT and don’t lose it somehow by something else. What I suspect, though I haven’t tried it yet, but the check of DS/DS$ or the INPUT#15 method to read the disk error channel may change the value of ST to 64 after you read the error status (it’s 1 record, and the last one the disk will give you - that might set ST to 64 at that point). I may play with that this afternoon, but that would explain why your program only reads 1 line from the file. The error check may set ST to 64 right after that.
  6. Great! I'm glad it is working for you!
  7. Strange. I just tried it in VICE and it worked as expected. If you just run the small version of the program that just reads the file and prints the contents to the screen, does it still just do one line? Can you show us the code in your program (at least the disk portions) and we can take a look? Some of the PETs had issues with sending line feeds to the disk drive when you use PRINT# but I tried it with a 4032 with BASIC 4.0, both with an 8250 and a 4040 drive and they behaved the same way.
  8. BASIC 4.0 makes working the disk easier. The same program snippet I provided above, in BASIC 4.0: 10 DOPEN#1,”LEVEL1”,D0,U8 20 INPUT#1,A$:GOSUB 100:PRINT A$ 30 IF ST<>64 THEN 20 40 DCLOSE#1 50 END 100 IF DS>1 THEN PRINT DS$:STOP 110 RETURN In BASIC 4.0, DS and DS$ are reserved variables that return error status from the disk drive, so it simplifies the error checking. DS returns the error number alone, DS$ returns the entire error string (00, OK,00,00)
  9. I may be wrong about this and others will chime in, but I believe PRG files store part of the load address in the first few bytes of the file and that may cause INPUT some sort of heartburn. The limitation with INPUT# is that what you read in has to fit within 80 characters, ad if it isn't quoted, you can't have commas or other punctuation errors of you'll get ?EXTRA IGNORED or ?REDO FROM START GET# causes a different set of issues. The default record separator in a file is CHR$(13) (carriage return). GET# won't care about that and it'll give you back a CHR$(13) into your string. You can test for this and skip it. So, what I would do is take your DATA statements, and write them to a SEQ file first (it won't have the load address issue) with something like: 10 OPEN 15,8,15:OPEN 2,8,2,"0:LEVEL1,S,W" 20 FOR I=1 TO (however many DATA statements you have):READ A$:PRINT#2,A$;CHR$(13);:GOSUB 100:NEXT 30 CLOSE 2:CLOSE 15 40 END 100 INPUT#15,EN,ER$,ET,ES,ED 110 IF EN>1 THEN PRINT ER$:STOP 120 RETURN Now, your program can read this file with: 10 OPEN15,8,15:OPEN 3,8,3,"0:LEVEL1,S,R" 20 INPUT#3,A$:GOSUB 100:PRINT A$ 30 IF ST<>64 THEN 20 40 CLOSE 3:CLOSE 15 50 END 100 INPUT#15,EN,ER$,ET,ES,ED 110 IF EN>1 THEN PRINT ER$:STOP 120 RETURN Lines 100-120 check for a disk error and stop if it gets one - it's good to check for disk errors since Commodore BASIC can't detect them. You don't say which version of PET BASIC you are using. If you are using BASIC 4.0, it has built in disk commands that are a little easier than the BASIC 2.0 commands we've been using. If you aren't familiar with those, let us know and we can help. They are pretty easy to master.
  10. Then I must have the special multitasking-enabled version of Windows 10 1903... They are all just running away. Obviously this is just a screen shot and not a video, but I assure you, they were all running, all at the same time, printing numbers.
  11. Just for grins, I ran this program twice on the TI 99/8 emulation in MESS using Extended BASIC II (which I believe is mostly written in Assembly with some GPL, and the processor is faster). As written, it completed in 18 seconds. Then I modified it as follows: 5 INTEGER I 10 FOR I=1 TO 3000 20 A=RND 30 NEXT I 40 PRINT A It completed in just under 15 seconds. Combining the program into 1 line using statement separators produced a runtime of 12.5 seconds.
  12. I have both of these devices so I can answer a few of your questions. The FinalGROM99 is a cartridge that has an SD card slot built into it, and a menu system. You can copy cartridge image files to the SD card in whatever organization scheme you want. When you start the TI up, the 2nd option on the menu screen will launch a menu that will allow you to browse the directory structure of the SD card for cartridge files. When you pick one, it is mounted into the TI just like you plugged in the cartridge for real. From that point on, item 2 in the menu screen is the cartridge you’ve mounted. The FG99 also has a reset button to reset the TI 99/4A, and a button to “eject” the mounted cartridge which then allows you back into the menu system to pick a different cartridge. The FTP site at whtech has a zip archive file that has I think almost every cartridge that was available in a nicely laid out scheme. The TIPI allows you to use a Raspberry Pi essentially as a hard disk system for the TI. It provides the normal DSK devices (these are directories on the Pi’s file system), but it also provides you with flexibility with how you want to organize your files. Most TI software allows for an “other” device that allows you to specify directories specifically on the TIPI and not mounted in a DSK. It also allows you some internet connectivity (you can open a static text file on a website from within TI BASIC, as an example). It won’t provide you a 32K memory expansion or serial/parallel ports. Jedimatt has a 32K expansion card that plugs into the expansion port that the TIPI’s interface card can plug into also. Greg (arcadeshopper) has all of these items I think available, including cases for them.
  13. I have an HP Spectre - mine comes up via Ctrl+Backspace. The config file thinks it is set to Scroll Lock also, so try that and see if it works.
  14. If you like the lower case characters that are in the 99/8’s character set, it would be trivial to provide the character definitions. Let me know if those work and I can get them from MAME and put it here.
×
×
  • Create New...