Jump to content

Casey

Members
  • Posts

    534
  • Joined

  • Last visited

Everything posted by Casey

  1. Downloaded and played V1.3 also - I do think the average person would be surprised if they saw this game to know the VIC-20 doesn't have hardware sprites, because the animation is so smooth. One minor bug I've noticed. If the character dies because they blew up dynamite too close to them, or they hit a magma flow, and there is an enemy further away (a bat as an example) - the enemy goes away when the player is respawned. That's the only thing I've noticed while playing. Great work!
  2. It's an excellent port, and a great example of what the VIC 20 is capable of when programmed by someone willing to take the time to let the VIC shine. The animation is very smooth. This was one of my favorite games for the 64 back in the day - it's great to see it just as playable on the VIC 20.
  3. I actually wasn't sure - I don't have my TI handy at the moment so I could not try it. Which is all to say, I'm not sure what caused this:
  4. I don't think that's a limitation of the hardware. Alpiner and Parsec both use speech and sound from the sound chip together. It might be a limitation of BASIC, however, that it can't do a CALL SOUND and a CALL SAY at the same time.
  5. Having now had a chance to play this game (both versions) and only in TI BASIC, I have to say it is a very impressive and engaging game. Definitely a game to come back to again and again. What you've managed to achieve with TI BASIC is really quite something.
  6. Line 680 branches to line 75, which doesn't exist in the program listing. Thus, the error...
  7. I just put away my "the VIC 20" for a bit and got my TI 99/4A out, and this looks like the perfect way to spend some time with it. Thanks for all your hard work on what looks to be a great game! I'm excited to play it!
  8. While RELative files are in a sense random-access files, in that you can retrieve any record you want, they are different in Commodore's context. Validate won't wreck a RELative file. You create a relative file in a similar way as you do a sequential file (i.e, with an OPEN command, PRINT#, CLOSE, etc) A random-access file in Commodore's world is a file where you manage all of the track and sector use yourself, via the "B-A:", "U1:" commands and you write directly into the track and sector. Since these are not stored in the directory at all, Validate will free any tracks/sectors that you allocated with the BLOCK-ALLOCATE command. For this reason, I think Validate will also wreck an autoboot sector on a disk intended for use with the Commodore 128 (since that autoboot sector has to be written with direct access commands). (I think I have this all correct) GEOS had its own validate command that you could run inside GEOS that would not wreck its files as well.
  9. Really it took Commodore until BASIC 3.5 and 7.0 to really integrate the hardware and software in a useable way. Those versions of BASIC had full support for all of the graphical features, and BASIC 7.0 had very good support of the sound hardware as well. At the same time, most of the graphical commands added to BASIC 3.5/7.0 were included in the Super Expander cartridges that were released for the 64 and VIC 20, but like any add-on, no one had them in enough numbers to make them a standard. Going back to the TI computers and the ability to add hardware. Similar to an Apple II card, anything you could design could be made into a card for the expansion system, or as a device that can plug into the expansion port. The difference is that on the TI computers, those devices provided their device names in the ROM on the device and as long as it was coded to the general standard, anything could use them. An example is the TIPI device, that allows the TI to use a Raspberry Pi as a file system. With the TIPI interface plugged in, the TI recognizes a device named TIPI for the file system, and PI for added functions, and can just use it. This allows things like: 10 OPEN #1:"TIPI.FILES.FILE1", OUTPUT, DISPLAY 20 OPEN #2:"PI.http://some.address.com/file.txt", INPUT, DISPLAY 30 LINPUT #2:A$::PRINT #1:A$ 40 IF NOT EOF(2) THEN 30 50 CLOSE #2::CLOSE #1 Also almost any of the software released on cartridge provided options to save/load from tape, disk, or "other future device" - and with a TIPI attached, all of those programs can save their data onto the Raspberry Pi.
  10. The Apple DOS / BASIC interface was kludgy. Why do I have to PRINT my DOS commands inside a program, rather than just use them? Which makes more sense? TI BASIC: 10 OPEN #1:"DSK1.FILE",OUTPUT 20 PRINT #1:"DATA" 30 CLOSE #1 Applesoft: 10 D$=CHR$(4) 20 PRINT D$;"OPEN FILE" 30 PRINT D$;"WRITE FILE" 40 PRINT "DATA" 50 PRINT D$;"CLOSE FILE" Integer BASIC was worse because it didn't even have the CHR$ function. I'd argue that DOS 3.3/ProDOS's command interface was nothing more than the same thing as the Commodore DOS Wedge. If you load that into a C-64, all of the DOS commands are available in short keystrokes and you can display a directory without losing your program by pressing 2 keys. The 64's native support of disk devices was complicated - I won't disagree. Commodore did have a BASIC that had all those disk commands, but they expected people to buy tape units in larger numbers than disk. The TI 99/4A's file system could use any device attached to the system without really having to know anything about it. Replace "DSK1.FILE" with "CS1" in the above example and the exact same program will work with a cassette file instead of disk. The really poor thing with the TI's disk system is that you had to use a cartridge to do a lot of rudimentary things. Want to copy a file from BASIC? Have to lose your program, exit BASIC, and run the Disk Manager cartridge. It was also not possible to display a disk directory from BASIC unless you wrote a program (and not a small one). That was dumb. At the same time, cartridges could add devices that the system could use, which was a nice ability to easily extend the system. I'll admit to my biases also My first computer was a TI 99/4A. My second, a Commodore 128 (which had a BASIC that had all the proper disk commands).
  11. Also one thing to note - The TI doesn't recognize file names on cassette. When the Adventure cartridge asks you for a file name, for cassette, it should just be CS1. (That probably has very little to do with your issue, but unlike Commodore machines for example, file names are not used on tape).
  12. Not that this isn't already known but I believe one of the addendums that came with the 99/4A (at least the beige ones) mentioned this. The workaround was the one you found (IF K+1=1) http://ftp.whtech.com/datasheets and manuals/Official TI addenda and data sheets/994a Users Reference Guide Addendum.pdf The same issue applies to key unit 2 and the M key.
  13. As printed in the book, the line does not have an error.
  14. What good would a document be as a BASIC program?
  15. I think of all the TI cartridge manuals I've encountered, only the Mini Memory manual stated that the console should be powered off before inserting or removing the cartridge. All of the others tell you to turn on the console prior to inserting the cartridge
  16. It's been ages since I've played the the MAME emulation of the 99/8; does MAME emulate memory expansion for the 99/8? As an aside, I actually had a 99/8 for a while many years ago. Mine had the p-system intact, but there was no card edge connector for the expansion bus on the side (just bare board), so I could only use cassette with it. I sold it when I had to, but I hated to do that and I wish I still had it. It was definitely faster than the 99/4A, and TI Extended BASIC II was more full featured, but it definitely suffered from not having a better video and/or sound chip.
  17. The 99/8 kind of addressed it right? It had CPU RAM separate from VDP RAM. TI Extended BASIC II had access to machine language. I'm not sure sticking with the 9918 (9118) was the best choice when they could have gone with a better VDP by then.
  18. Wheel of Fortune on the C-64 is very interesting because it's written in BASIC! It does call some machine language routines, but the game engine is BASIC. I found this out when I loaded a directory and then loaded one of the programs and realized it was the game. That did allow me to fix a screen formatting error that had bugged me since I had this game originally BITD.
  19. Forgive an ignorant question from a non-Apple II guy (though I have used them of course). What was different in BASIC between ProDOS versions? I thought Applesoft ran from ROM, and I know that DOS intercepts the input/output to look for DOS commands with the CHR$(4) notation. Is it just that part of BASIC that changed?
  20. Robin at 8-bit Show and Tell on YouTube has a video describing something similar - it might be the case for you also. In his case, the head bumped too far and got stuck and he was able to "free" it. Perhaps this is what happened to yours as well.
  21. I had several Tandy 1000s back in the day. Thanks to Radio Shack putting the next more powerful model on sale within the 30 day return period, I went from a 1000 RL to 1000 RLX to 1000 RSX in about 3 months and actually got money back doing that. While I can't speak for all Tandy's, none of those were at all bad. I then had a Tandy 486 (Tandy 2100 Model 10 I believe) when I was in college and my friend who had a custom built 486 bought some RAM for his computer that he was sure was defective since it didn't work, yet worked just fine in my Tandy, so they weren't all bad. The worst computer I ever bought was a Philips Velo 1 Windows CE device. It was cool and I *really* wanted it when I bought it, but I couldn't use it for anything at all.
  22. 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.
×
×
  • Create New...