Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

660 Excellent

About baktra

  • Rank

Contact / Social Media

Profile Information

  • Gender
  • Location
    Prague, Czech republic

Recent Profile Visitors

13,937 profile views
  1. In early 1990s, that would be an explosive question. Now we are smaller community, so it will just smolder :-). My favorite choice would be Omicron Turbo, but I do not have enough evidence that it actually fully works as intended. It also provides safer (==slower) transfer speeds. It targets the most common turbo hardware modifications, but not Rambit or Turbo 6000 (these two are simply too odd).
  2. And when it comes to turbo loading systems, everything has been said. Perhaps new games created in the current era can have turbo versions on side B, if both authors and the publisher agree.
  3. @Wilheim, would you disclose more technical details? The nature of the bugs, and how you fixed them?
  4. It is always difficult to satisfy everybody. What is more, complex games are not so easy to adapt from disk to cartridge and vice versa. All media have advantages and disadvantages. Tapes: + Not a problem to get blank media + Inexpensive - Terrible loading times - Without involvement of tape authoring company, it takes time to record them in large quantities - Not too much reliable - Users do not have data recorders - Loading extra game data is difficult - Releasing bug fixes is near to impossible Disks: + Good loading times + Duplication process is reasonably fast, even without involvement of an authoring company (are there companies duplicating floppies??) + Reliable + Loading extra game data is ok + Releasing bug fixes is reasonably possible - Difficult to get blank media, can be expensive too - Fewer users have real disk drives, but there is more disk drive owners than data recorder owners Cartridges: + Fast loading times + Reliable + Every user has a cartridge slot + Very big games can run on 64KB machines + Hi-scores and states can be saved (requires special features, increases price) - The game has to be designed for cartridge. Especially when bank-switching or special features are involved - Can be difficult and expensive to design and manufacture in large quantities, depends on the special features - More expensive for end users
  5. Given the shape of the black box, I would guess that if the device is really related to cassettes at all, it might allow to connect an ordinary cassette recorder. There were several similar interfaces for doing so.
  6. EDIT13.COM from FLOP#48, side A - http://flop.atariportal.cz/archives/Flop_48.zip. Simple, efficient, by Raster. Control+ Q Quit L Load S Save I Insert/Overwrite toggle P Paper/Text Color toggle O Non-printable characters toggle Y Delete line A Home Z End W Next Word U Page Up D Page Down T Top of the document B Bottom of the document C Copy - Copy to clipboard. Position cursor the the beginning of a block. Press CTRL+C. Then position cursor to the end of a block. Press CTRL+C again. Max block size is 4 KB V - Paste from clipboard to the cursor position.
  7. Atari800 supports multiple ways of sending audio to the sound card. The preferred way on GNU/Linux and Windows is through the SDL library, but it can do it also through the outdated OSS (hence /dev/dsp). However, if the SDL library is not found in your system (the attached config.log proves it was the case at the time), atari800's configuration script tries falling back to OSS looking for /dev/dsp. The same for video output. The preferred way is through SDL, but if not found, there is still possibility to output video directly through X11 API, so if no SDL, the config script tries to fall back to X11. But that requires to have X11-dev package to be installed. And you indeed need to have -dev packages of the SDL and png libraries installed if you compile from source code. The package without -dev is for running programs depending on a library. The package with -dev is for compiling programs depending on a library.
  8. A gentle reminder to visit the nearest C64 forum would be an efficient solution too.
  9. That was the first game that crossed my mind, however this is not a tape loading screen.
  10. This is a very good question. I believe block or segment, would do. It might be good idea to check scans of literature from Atari to see how they named those. For example Atari DOS 2 reference doesn't specify any name. I would recommend to avoid the word chunk, as it is associated with elements of tape images (.cas).
  11. This is a good tool. It seems that all of us who need to process the binary load files create such a tool sooner or later. I like the way you can select multiple chunks from the command line. I hope the tool will earn its rightful place at your website or a public repository, so it doesn't get lost in this forum.
  12. Thanks. I didn't know. In my program, I do not re-open the E: device (I just close it as I don't use it later).
  13. There is also one thing specific to the CC65 and its ATARI target and runtime library. It is, to my surprise, using MEMTOP to position its C runtime stack, though it is documented. So, for this specific situation, adjusting MEMTOP is also needed, even though it is a vector used by BASIC. I didn't do it in the TRAIN 2 game and its loading screen gets a little glitch (P letter appears briefly on screen). Apart from the glitch, there is no other damage, fortunately. A circumvention is to boot with the OPTION key pressed.
  14. It would wrong, of course. There would need to be certain logic checking the RAMTOP and adjusting it. On the other hand, software that really needs RAM below BASIC wouldn't work on a computer with less than 48 KB RAM anyway.
  15. I am afraid that this might not be possible in all cases. For the hybrid binary load files, it is possible as the compressed segments are distinguishable. For others, it might be guessing or might require manual intervention. It is a matter of recognizing compressed segments, compression types and decompressing them.
  • Create New...