Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

39 Excellent

About lp060

  • Rank

Profile Information

  • Custom Status
    GFA Coder
  • Gender
  • Location
    GFA Headquarters
  • Interests
    GFA-Basic (Atari ST)

Recent Profile Visitors

10,839 profile views
  1. No problem here. There's no other way to interpreter "Line numbers in early BASIC were not overhead." If you wanted to say "it was simpler than using labels" you should of said it. Still it changes nothing, my facts remain the same. So now I'm attaching old solutions. That's funny. I lived through that era, used them machines and many of those languages. BASIC by design had line numbers to facilitate jumps, not to ease your type in experience. Just so happens the line numbers where handy for printed listings. Those so called "very limited (slow, little RAM size) computers" also had 6502 assembler, 'C', Forth, Pascal, and the Action programming language. None of which have line numbers. I should know, it was Action that freed me. I guess you are unable to agree that line numbers are technically overhead, but would rather squabble over the semantics of some phrase. So it's now my fault you didn't write all that you should of wrote in a previous post. Typical.
  2. Regardless if you "feel" they were necessary, line numbers are in fact overhead and less intuitive, it does not change the facts. I know how interpreters work internally, made a study of that on both platforms. The interpreter has to search for the line number and you are trying to tell me that is not overhead? Seriously? A couple of 8-bit basic interpreters use tricks to overcome this overhead by converting line numbers into pointers at run time.
  3. From my own experience, by the end of the 8-bit era, moving away from a line number based language was a goal. Line numbers are messy and unwanted overhead. That's why I never used ST BASIC to do anything. There was a compiler, granted not free, but even that could not save ST BASIC. https://www.atarimagazines.com/v5n7/LDWCompiledBASIC.html
  4. I could never get it to boot into TT emulation. Turned out to be a bad rom image some sites are offering for download.
  5. From my notes: The TT030 has a "T" style SCSI chain. This means the internal HD is one chain and the SCSI port on the back is the other. Both chains must be terminated. To clarify, the internal drive must be terminated. If you use the external SCSI port, remove the terminating resistor packs from the motherboard. If you do not use the external SCSI port, the terminating resistor packs should be left on the motherboard.
  6. Perhaps someone here can help? https://www.facebook.com/groups/1619945831452530/
  7. Rescued a broken HP all-in-one that doesn't print anymore, but the scanner part works fine. Spent the time to re-scan the material. The manual says v3.0 on the cover but there's a chapter about v3.5. Scanned the v3.5 compiler manual as well. Then made them searchable. Can find them at https://docs.dev-docs.org/ Regarding v3.6, it added support for TT030 video modes, meaning the editor itself would function in those modes and limited FPU support. Also a couple of new commands. There's a read me file on the v3.6 disk, but it seems to be incomplete. Does anyone have some v3.6 addendum pages laying around? Merry Christmas. 🎅🎄😉
  8. Switch 8 -> on = Disables the DMA sound hardware My TT arrived with this switch set wrong by the dealer. Not sure where his switch 5 info came from, but Cattamaran manual states: Set DIP switch # 1 to ON (as shown). This informs the system that you have installed a CyReL CaTTamaran 48 MHz accelerator module in your Atari TT030.
  9. Had the entire English v3.5 manual scanned at one point and then lost it when the SSD hard drive bricked.
  10. Sounds like a general assumption not based on experience. I did write a disclaimer "Won't work on all old programs." Sure some trial and error is required. I've had the TT030 since 1991 and great success with tweaking the header bits. Obviously I'm not trying to make games and demos run in fastram, but for productivity software and most gem applications, it works quite well.
  11. My system is 10mb STram/64mb TTram. Can't say I ever ran out memory. There are users out there with way more fastram than me. It probably depends on what you plan to do with the system and what types of programs you plan to run. My system runs MiNT and with multitasking the extra ram helps. If you are going to stick to single tasking TOS, then a setup like mine is overkill.
  12. Some bits in the program header can be adjusted to allow old software to allocate fastram or place the program itself in fastram. A small utility can be used to manipulate these bits or some of the more advanced desktops like Thing Desktop have this feature built in. Won't work on all old programs. https://freemint.github.io/tos.hyp/en/gemdos_programs.html
  13. The latest version of GFA is 3.6 and if you don't mind reading PDFs checkout: https://docs.dev-docs.org/ See 'out of print books' link.
  14. Cheers for the effort, but sadly it appears unreadable. Quite a few sectors including the directory sectors contain "SORRY, THIS SECTOR CANNOT BE READ FROM FLOPPY DISK BY ST RECOVER."
  • Create New...