Casey
-
Content Count
445 -
Joined
-
Last visited
Posts posted by Casey
-
-
If I remember right, if you mount volume 1 into dsk1 and then start Extended BASIC, the config program runs automatically. If you are trying to run it from TI BASIC, I'm not sure that's possible. There's also a CATALOG program on volume 1 that you can load from either BASIC and display the disk catalog without needing Disk Manager. I usually leave volume 1 mounted in dsk3 so that it doesn't take over Extended BASIC but the catalog program is always available.
-
Huh,, that's strange. I've never had it not show up on mine.
-
Silly question, but does the finalgrom99 works on a beige TI?
I have both a beige and a silver Ti, but it doesn't seem to work on the beige. I do have to fix my power button on my silver so I intended to use it on my beige in the meantime. Not a big problem really...
It works just fine in my beige TI, but I have a non-QI, 1981 OS version. Do you have a V2.2 beige console? I would think it should still work, but I'd be curious if yours is somehow different than mine.
Like many others, I bought it so I could have all of the cartridges that are available accessible at once. Lots of cartridges that we have images for are nearly impossible to find in the wild, or if you do find them, they are $$$$.
-
Neat! Was that also a Microsoft BASIC? Also, what up with your avatar... 3.0??
No, Atari BASIC was very different from Microsoft BASIC. To make it more confusing, there was an Atari Microsoft BASIC, but it worked just like most other Microsoft BASICs. But the BASIC that came with the machine used a token table for variables. This had its own set of issues. The benefit was that the length of the variable name didn't impact the runtime, but you could only have 128 unique variables and sometimes their place in the variable table mattered. I recall seeing some magazine listings instructing people to LIST their programs to tape or disk, NEW, and then ENTER the program back in so that the variables were in the right place in the table.
And yes, mizapf is correct. At one time many years ago I was fortunate enough to have a 99/8 for a while and I took a screen shot from it back then of its title screen, and that's where my avatar came from.
-
I always wondered why BASIC languages do a string search for variable names. I would think a good way to store variables would be a hash-table of names with a collision flag.
Atari BASIC actually did tokenize variables, with the limitation being you could only have 128 unique variables in a program. Another approach to the same problem...
-
1
-
-
This worked great on my real TI. Very impressive stuff!!
-
1
-
-
If you are testing for a file's existence with something like OPEN #1:"DSK1.DUMMY",INPUT,INTERNAL,FIXED and it doesn't exist, you don't need a CLOSE #1 because the OPEN #1 didn't succeed. (I think you'll get a FILE ERROR if you try to CLOSE #1 actually).
If you are just using the file temporarily in a program run and you don't need it at the end, (that's what I took your explanation to me, but please correct me if I misunderstood) you can make it easier on yourself with something like the following:
100 OPEN #1:"DSK1.FILE",UPDATE,INTERNAL,VARIABLE
110 REM program lines
200 PRINT #1:"SOME DATA GOES IN THE FILE"
210 REM program lines
300 RESTORE #1
310 INPUT #1:A$::PRINT A$
320 REM rest of the program
500 CLOSE #1:DELETE
510 END
This allows the program to open the file, read it, write to it, do whatever it needs to do with what it did with the data in the file, and then clean it up at the end. Then you don't have to worry about the file existing when you run it again, because the file will only live as long as the program is running.
INTERNAL/DISPLAY - Think of it like this and I think it will help. INTERNAL is great if the only thing that's going to read the contents of the file is the computer itself. DISPLAY is perfect if a human is going to read it. Disk and cassette files are good candidates for INTERNAL, whereas the printer would be something you'd open with DISPLAY. At the same time though, if you have to transfer the file to another computer (say, Windows) you'll want to use DISPLAY. INTERNAL files are stored in TI's own proprietary format that another computer might not understand, but DISPLAY is standard ASCII.
INPUT/OUTPUT/UPDATE - I tend to use INPUT and OUTPUT more often than UPDATE. It's much clearer what you intend to do with the file with INPUT and OUTPUT for one thing, and if you were going to read one file and write to another, this gives you some insurance that you won't wreck your input file by accident. UPDATE is perfect for a RELATIVE file where all the records are the same size and you want to change individual records in the file. But it works fine with sequential files too if you need to read some data in the file to affect other data later in the file.
Be sure to use the EOF function when you are reading to check that you haven't hit the end of the file.
In the case above, you can set up a read loop that tests for end of file and then gets you out before you get an I/O ERROR with something like this:
100 OPEN #1:"DSK1.DUMMY",INPUT,INTERNAL,VARIABLE
110 IF EOF(1) THEN 150
120 INPUT #1:A$
130 PRINT A$
140 GOTO 110
150 CLOSE #1
-
I have questions about your question.
You won't get an error if you try to DELETE a file that doesn't exist. With that said, I'm not sure you need to even check if it exists first if the only action you are going to take if it is found is to delete it.
However, you can test if a file does not exist and then handle that in a program. Opening a file for input that doesn't exist produces an I/O ERROR that you can trap with ON ERROR. Once you handle that (set a flag, do something else), you can put ON ERROR STOP to set error handling back to the normal method and continue on with your program. You have to be careful though, since a file with different data type than you are checking for will also produce an I/O ERROR and get trapped by the error handling. There may be a CALL PEEK that you can use to find the digits for the I/O ERROR and look specifically for the file not found condition. I thought CALL ERR might give you that information, but all it tells you is the file number that caused the error. Unfortunately, the CALL ERR built into the CC-40 would give us that information, but not 99/4A Extended BASIC.
If we can assume that the file type will always be the same, or is known, this seems to work:
100 ON ERROR 150 110 OPEN #1:"DSK1.DUMMY",INPUT,INTERNAL,FIXED 120 ON ERROR STOP 130 DELETE "DSK1.DUMMY" 140 END 150 PRINT "FILES DOES NOT EXIST"
-
I can certainly try RUN “CS1” in a program for you when I get home today. There’s no way to supress the cassette operating instructions though, so if you have a neat screen display, it’ll be gone by the scrolling instructions.
-
I’d be interested to see how this works with RXB and real casssette. I have both available with my real iron 99/4A if you wanted to see if the 17K program can save from RXB in IV254 format and then load back into regular Extended BASIC.
-
The user's reference guide that comes with the 99/4A (there is a PDF of it on whtech) has very thorough documentation for all the parameters for the OPEN statement, in much more detail than the Extended BASIC manual. You many want to have a look through there as well. There are many examples and they are all very well documented. The manual tells you about all the defaults if you leave them off a well. Good luck with your project! Happy to help as always. I learn so much from everyone else on here with the assembly language and the hardware stuff - I'm happy to help with TI BASIC whenever I can.
-
2
-
-
I think I am misunderstanding how to use FIXED. second from last paragraph of page 139 extended basic manual talks about using FIXED. it says
"If you like, you may specify a maximum length of a record by following VARIABLE or FIXED with a numeric expression.
So I took that to mean FIXED2 would limit the fixed size to a max length of 2 (for 2 digit numbers)
But now that i look at all these answers, is that what the ,80 is for at the end?
So I would use
OPEN #1:"DSK3.SHAREDFILE",UPDATE,OUTPUT,FIXED 2
instead?And by length are they describing integers? The longest length record I would need to save is two digits long. (From 0 - 99)
UPDATE and OUTPUT are 2 options for the same operation in OPEN. You cannot specify both.
This may help I hope - the generic format of an OPEN statement:
OPEN #x - where x is any number between 1 and 255
:device-file name - a variable or string constant that specifies the device and file name
,file access mode (RELATIVE or SEQUENTIAL) - defaults to SEQUENTIAL if you leave it off
,file mode (INPUT, OUTPUT, UPDATE or APPEND) - UPDATE is the default option if you leave it off.
,file type (INTERNAL or DISPLAY) - defaults to DISPLAY if you leave it off
,record type + optional record length (FIXED or VARIABLE) (I think VARIABLE is the default)
So, in your case, you would want: OPEN #3:”DSK3.SHAREDFILE”,UPDATE,DISPLAY,FIXED 80 as in the example code from above.
It can be more generic of course.
100 X=37
110 FILE$=“DSK3.SHAREDFILE”
120 OPEN #X:FILE$,UPDATE,DISPLAY,FIXED 80
xxx
200 CLOSE #X
Specifying UPDATE allows the TI to both read and write to the file at the same time.
Some devices can only used certain record lengths. Cassette for instance will only support 64, 128 and 192. If you specify VARIABLE 80, I think you get a maximum length of 80, but the cassette system will pad it to 128.
-
1
-
-
I did some additional testing on my real iron 99/4A just now.
You can use OPEN #1:"DSK3.SHAREDFILE",UPDATE,DISPLAY,VARIABLE 80 and read and write to the file.
You can use RESTORE #1 to go back to the beginning of the file if you want, but if you are going to overwrite a record in the file, you have to be careful to overwrite it with the exact same number of characters or you may wreck something because of the VARIABLE 80.
But I had no trouble getting this to work:
100 OPEN #1:"DSK2.TEST",UPDATE,DISPLAY,VARIABLE 80 110 C=87 120 TRAP=1 130 PRINT #1:C 140 PRINT #1:TRAP 150 RESTORE #1 160 INPUT #1:LINE$ 170 D=VAL(LINE$) 180 INPUT #1:LINE$ 190 TRAP2=VAL(LINE$) 200 PRINT D,TRAP2 210 CLOSE #1
-
1
-
-
I did some testing just now on my 99/4A. This worked fine:
100 OPEN #1:"DSK2.TEST",OUTPUT,DISPLAY,VARIABLE 80 110 C=87 120 TRAP=1 130 PRINT #1:C 140 PRINT #1:TRAP 150 CLOSE #1 100 OPEN #1:"DSK2.TEST",INPUT,DISPLAY,VARIABLE 80 110 INPUT #1:LINE$ 120 C=VAL(LINE$) 130 INPUT #1:LINE$ 140 TRAP=VAL(LINE$) 150 PRINT C,TRAP 160 CLOSE #1
One thing I meant to comment on above. APPEND in the open statement will only add to the end of a file. You can't read from it in APPEND mode. You can either use INPUT or OUTPUT to be specific, or you can use UPDATE mode to both read and write from the file. It may need to be RELATIVE for UPDATE mode though - that I'm not sure of without playing around.
-
1
-
-
Close - I think you would need VAL. C=VAL(LINE$) - this only works of course if LINES$ contains valid numeric characters. I'm not sure also if this works because of there may be a carriage return in LINES$ also. I haven't done any testing.
-
1
-
-
Cool! After I panic-posted and then read the doc for ti99dir again, I figured out how to get individual files into a volume on the CF card, so I’m good to go. But it’s good to know I can use Classic99 to write to disk images now as well. Much easier to send files the the 99/4A that way than trying to type them in by hand.
-
1
-
-
In Extended BASIC, CALL PEEK(-31888,A,B)::PRINT A;B
If A and B are not 55,215 then change the 55,215 in line 110 to match your values. And of course, report your results!
That did the trick. On my real 99/4A, it was 55,207. Changing line 110 to match worked. Thanks!
-
1
-
-
My real 99/4A doesn't like something about these programs but I'm not sure what it doesn't like. I pasted these into Classic99 and then transferred them to my nanoPEB and 99/4A locks up after running the setup program. TI BASIC restarts, but attempting to load the demo program locks up the TI. I can't imagine it makes a difference, but the programs from above that I used to make the video with, I typed in by hand. (Those only work from cassette, oddly).
-
This may (and probably certainly has been) have been asked before, but I have hunted around and haven't found what I am seeking.
Suppose I'm using Classic99 and I've got some TI BASIC program files I've saved to my PC's hard disk. I want to use these on my real 99/4A. I have a nanoPEB and a CF adapter thingy hooked up to my PC to exchange files. I have no problem using dsk2cf to move disk images from the PC to the TI. But Classic99 won't write to a disk image according to the documentation, and I don't know how to get these 2 files into a disk image so that I can put it in my CF reader for the real TI to use.
How do I make this work?
Thanks!
EDIT - After I posted this, I figured out how to do it.... This can be deleted by someone who can delete threads.
-
I would just echo what has been said above. RXB works great on real hardware from a FinalGROM. There's lots to it that I haven't explored, but it definitely works great.
-
I'm not senior_falcon
but is it 2's complement notation? Instead of going from 0-255, the values would go from -128 to +127, which allows us to have negative and positive numbers all in 1 byte. In 2's complement, you take the binary digits that make up the number, flip them, and then add 1, and that gives you the negative decimal equivalent. FC in binary is: 11111100
2's complement: 00000011 + 1
-4
It really is an artifact of how integers are expressed (or can be) expressed in computers. Either from 0-255 in 8 bits, or using the first bit to indicate the sign, from -128 to +127. It's also why we have to use negative numbers in CALL LOAD statements.
I hope I explained that correctly - Computer Science classes were a long time ago!
-
1
-
-
This is interesting to me as well. My first computer as a child was a TI 99/4A (in beige, so that's why I have a beige one now). Since I was a kid when the 99/4A was out, I never had the means to get any of the peripherals, and the moved to the Commodore 128 and then later PCs. The TI has always held a spot in my heart, however, so at times I collected TI equipment and then sold it. At one point I had a 99/4, a black/silver 99/4A, a beige 99/4A and a 99/8, along with a PEB and all that good stuff. I then sold all of that equipment and within the last year decided to get back into it again. I'm back to a single beige 99/4A (a new one), along with a nano-PEB and a FG99 and that is able to hold my interest. I am very much looking forward to the TiPi and I'm on the wait list for the F18A. Can't wait to get those! It's a great time to be in the hobby.
-
2
-
-
So to Casey, put that video back up please! I take exactly zero offense if you omitted my name.
(Now if there are sales involved, that is another story!)
I will re-upload the video. The URL may change, so if it does, I will make sure the proper link is included. (And no, I'm not planning on selling anything!
)I'm actually fascinated by the technique, though I don't understand it a bit (I just don't have the knowledge to know what it is doing). But it makes me wonder if something like this has been known in the days when TI BASIC programs were included in magazines like COMPUTE!, would we have seen it exploited to produce more interesting games? COMPUTE!'s TI Collection Vol 2 has a series of programs where they were able to figure out the object code format so you didn't need Editor/Assembler to use them. Seems like maybe this technique could have been used as well for some interesting programs with not much hardware required.
Edit: The video has been re-uploaded:
-
3
-
-
It wasn't offensive. I just didn't feel like going to the effort to put in credits, and descriptions, and everything else, since 1) I don't understand the technique other than what is stated already in this thread (I certainly have no idea how or why it works), and 2) to have come across the video, you'd have had to have been in this thread and read the conversation which already contains all that information. At the same time, I didn't want to be accused of stealing someone's work and having to mess with all that drama, so the easiest thing to do was just remove the video.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Best TI99 game graphics?
in TI-99/4A Computers
Posted
As far as cartridge games go, I'd have to also vote for Popeye - an almost exact duplicate of the arcade game. Donkey Kong is a close runner up. (I just wish the sounds were better)