Jump to content

baktra

Members
  • Posts

    1,473
  • Joined

  • Last visited

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Prague, Czech republic

Recent Profile Visitors

16,991 profile views

baktra's Achievements

Stargunner

Stargunner (7/9)

1.5k

Reputation

  1. Release 9.2.16 is available. Main points: TSFX now supported for the polish KSO Turbo 2000 plugin. Since there are two variants of the hardware, you must indicate the one you have using a new configuration entry named Hardware type. In the main menu, navigate to Tools>Preferences. Then navigate to the KSO Turbo 2000 section. Some transfer speed refinements for Turbo D Thanks to @w1k and @lexx for testing.
  2. Release 9.2.14 introduced a regression: The tape self-extractors generated oversaturated output, resulting in unusable recordings. Release 9.2.15 is fixing the regression. All users of 9.2.14 are advised to update to 9.2.15. Thanks to @w1k for discovering it.
  3. Just briefly, TURGEN 9.2.14 Can create TSFX for Turbo Blizzard Some Turbo D timing refinements The beeps are now all POKEY
  4. I have some good news from Poland. One atarionline.pl user reports the TSFX for Turbo Blizzard works. Of course, such success is rewarded by requests for supporting other Polish systems. What a surprise... The only issue is that to support all major Czechoslovak turbo systems, you just need one block-writing routine (Turbo D, which is a unicorn, doesn't count). For Polish systems, you need many block-writing routines.
  5. Would you happen to have a comprehensive list of utilities you already have?
  6. My experience shows that these adapters are less predictable than anticipated, branded or not branded. Branded have better mechanical parts. Setting the correct volume is of a finicky nature. The ideal volume can differ for different speeds and also waveforms. Also note that for nominal transfer speeds above 4000 bps, with waveform set to auto, turgen changes the waveform from harminic to square. You can change that setting, of course.
  7. I believe that not that much love for the system then and now doesn't need to be emotional at all. From a pragmatist's and developer's perspective, living in EU, today. 1. The consoles are rare, their cost is high, getting a real machine is tough. 2. No PAL. Not so much of a problem these days with modern display devices that can handle both PAL/NTSC 3. Small user base in general. Developing a paid or free homebrew software will not reach a broad audience. Digital releases require the customer to have a universal cartridge. Physical releases are surprisingly doable, these day easier than in the past. This creates the traditional chicken and the egg problem. 4. Competition from the 8-bit computer line is fierce. Bigger user base, upgrades and mods, disk/tape/cart choice, keyboard for advanced games. Not so much distinguishes the console from the computer (analog controllers, two fire buttons, keypad do not seem enough). Bank switching cartridges are fortunately possible for huge programs 5. Cross-platform development tools are equal and convenient for both product lines. that is a plus. If given some thought in advance, software for both platforms can be compiled from one source.
  8. The work on the Turbo Blizzard TSFXes had advanced enough, so we have a 2nd prototype TSFX. This one records the Flying ACE game from Avalon Hill. Other minor enhancements are on the way, related to... beeping. 1. All beeps will be done by POKEY, because some imperfect STEREO upgrades do not mix in the GTIA beeps. 2. Alarm will be possible also for standalone TSFXes P.S. We've got lucky this time, the Turbo Blizzard CIO device handler's source code is available. Not that I fully understand the block write routine, but I understand it enough to adjust it for TSFX. I wish the source code was available for Turbo D, and for KSO Turbo 2000. 000_flyingace_bliz.xex
  9. To take some time off from the Turbo D, I started work on the Turbo Blizzard TSFXes. The block writing routine is already succussfully stolen, just needs some adjustments, e.g. refrain from calculating and storing the checksum (that is already done by turgen).
  10. Not unless the Fujinet device traveled in time to the 1980s. The utility software installed two CIO devices, N and D. The N device used non-duplicated blocks (provided speed, but no redundancy), while the D device used duplicate blocks (not so much speed, but redundancy). So why not use the device names to identify the tape modes? Or is it just Daleks and Nausicaans?
  11. Version 9.2.13 is out: https://sourceforge.net/p/turgen/blog/2024/03/turgen-9213---double-d/ Changes Turbo D : You can choose tape mode (N:) or (D:) Turbo D : The transfer speed setting uses average speed (assuming 50% zeros), instead of maximum speed (assuming 100 % zeros) Standard: Refined GUI, streamlined color choosers Rambit Turbo Tape: Refined GUI, streamlined color choosers Documentation: Ability to specify special file names using $HEX$ notation documented for plugins that support it (Turbo 2000, Super Turbo, Standard, Lower Silesian Turbo 2000).
  12. Some plugins can do that, namely Turbo 2000, Super Turbo, Lower Silesian Turbo 2000, and Standard. You need to put hexadecimal notation, instead of program title. Use ATASCII table. E.g. $HEX$ 32 FC 24 45 75 Such function must be used with extreme caution, as inverse characters can confuse some loaders/copiers.
  13. For Turbo D, you will be able to select a tape mode using radio buttons. The Standard and Rambit Turbo Tape plugins will get more streamlined color selectors.
  14. Plans for the next update release: Tape mode selection for Turbo D Refined UI for color selections (Standard and Rambit plugins)
  15. It was established that the Load function didn't work, because the loaded file exceeded the size of the "RAM under ROM" small ramdisk.
×
×
  • Create New...