baktra

Well, you will not expect Phaeron to go through the documentation in Slovak language (and mostly scans that are not so easy to translate) and come up with support for a rare system out of the blue, won't you? That would be naive. I believe such request must come on a silver plate with the following information: What is the modulation style (how the 0 and 1 are translated to the electric signal and back) How the data recorder is switched to turbo mode (if it is applicable) How the signal goes to the computer (SIO, Joystick Port, etc.) Sample recording Sample loader and instructions on how to use it. This is the bare minimum. It still doesn't guarantee that a request would be granted. It also very much depends on how much work it would require, how it would fit in the current code that supports turbo systems. And last, but not least, the business value of the enhancement must be taken into account. Let me do some digging first. If I collect sufficient information, we can get back to this matter.

I've released TURGEN 9.2.10. In a nutshell, it fixes all the mess that was in the SFXs. I have also completely removed the buggy 9.2.9 and 9.2.8. If you are nosy, you can dig into the SFX skeletons here: https://github.com/baktragh/a8_tape_loaders_and_utils/tree/master/tape_sfx_skeletons

I have good news. After fixing the trailing pulse, the SFXs work really well. So the main SFXs problem seems to be solved. I also updated the SFX skeleton for Super Turbo and derived systems, everything is fine. I updated the documentation, added some recommendations. A 5-second gap is always written between files, for easier orientation on the cassette. I made some changes that are not visible. SFX skeletons have data that TURGEN ZAPs near its starting address. This made ZAPs easier and more stable, I don't have to change the code in TURGEN every time I change the SFX skeleton. So, in the near future I will release TURGEN 9.2.10 with all fixes. What was not included in version 9.2.10. Automatic splitting of composite SFX by maximum side length - it's more complicated. Support for baud rates higher than 3633 bd. Creating pulse length tables is a pain in the ass, so I'll leave that for next time. And two more tips at the end, just to be sure, they are also in the documentation for the program. Two steps before you start recording to tape. It will save you a lot of time. Take advantage of Altirra being able to read Turbo. First, make your project items into .WAV or .CAS files and test with the emulator. Time can be accelerated in the emulator. If something doesn't work in the emulator, it won't work with the actual cartridge either. Take advantage of the fact that the modified atari800 emulator from the project http://www.arus.net.pl/FUJI/a8cas-util/ can completely emulate a turbo tape recorder, including writing to a cassette. The emulator may not be as comfortable, but it will allow you to test the SFX well. In the tape recorder emulation settings, choose the Czech system. Turbo 2000 B. The emulator can speed up the time by pressing F12. This will of course check if SFX works and if what it writes can also be read back.

Almost too good to be true. Thanks a lot for testing.

So, this is what one would call a proper termination pulse: I am attaching a new package of SFXes that have the termination pulse fixed. All Czechoslovak Turbo 2000. Start with the monolithic one, then go to the blockloading and then kilobyte blocks. Try the Expressloading as the last one. sfx4.zip

I might have discovered something wrong about the SFXs. The termination signal of each block generated by SFX is different from the termination signal created by e.g. VisiCopy III or Universal Turbo Copy. The last byte of the header block is $B1 = 1011 0001. The last pulse holding data is a wide pulse, highlighted by green dots. The subsequent pulse highlighted by the red brackets in the signal visualization is not part of the data. It is there to be merely a terminator of the previous pulse. The presence of the terminator is crucial. If the terminator is not present, then the loader will detect a timeout when looking for a zero-crossing, report an error or skip the header block. As you can see, the terminator pulse generated by SFX is extremely narrow, compared to the terminator pulse generated by VisiCopy III. Theoretically, the duration of the terminator pulse shouldn't matter (because there is a zero crossing). Practically, given the frequency range of a typical data recorder, the pulse is likely to be not registered at all, especially with old equipment. This is how it looks after applying a low-pass filter with a threshold of 8 kHz (simulating capabilities of a low-cost cassette recorder). There is no zero crossing at all. This is obviously wrong and can explain the somehow random nature of the SFX failures. I will, of course, solve this obvious problem. I, however, cannot claim this will fix all problems with SFXes.

What exactly happened with Swapz? Did you get a screen with pink border?

It is time I admit the SFX do not work as expected. Though none failed with my setup (I tested rather thoroughly before going public as I know emulation cannot be 100% trusted when it comes to tapes), I have reports that they do not work from everywhere else. It is unfortunate, but I have to face the reality. Either figure out what's wrong or abort the mission. Failures to read even the turbo header are damning.

There is indeed never enough testing. There is the newest SFX package for testing. All SFXs created using the most recent builds of TURGEN and SFX skeletons. Explanation of the suffixes: t2k - Czechoslovak Turbo 2000 t2kb - Czechoslovak Turbo 2000 - Kilobyte blocks. Normal Turbo 2000 or Universal Turbo loader is enough to load the recorded data lst2000 - Lower Silesian Turbo 2000 (Poland). Use the Auto Turbo loader to load the recorded data. ht - Hard Turbo (Poland). Use the Hard Turbo loader to load the recorded data. Consider the following: The loading address of the SFXs is $0B80. Use AVGCART, UNOCART, SIDE, MyPicoDOS, or any loader that supports such MEMLO to load the SFXs The data recorder and cassettes should be in a good shape. The data recorder must have a compatible turbo upgrade. If in doubt, check the compatibility matrix. The composite SFXs require a setup where the device you load the SFX from and the data recorder are connected simultaneously The data recorder should not have a modification that makes it disrespect the MOTOR CTRL signal The testing status is as follows: For w1k, almost nothing works For me, everything is recorded and read back from tape just fine. sfx3.zip For daring souls, latest TURGEN builds: Windows Installer: https://drive.google.com/file/d/1M6XW_VhSJRlvnJ4BQQQFgXb5evymkr2e/view?usp=drive_link Compressed tarball: macOS/Linux/Windows: https://drive.google.com/file/d/12zbrv0Kr-D5HgOeUm-tRkZLy3ip6tV2e/view?usp=drive_link

There is a sample composite SFX. It records 4 games to the basic Czechoslovak Turbo 2000 format. I've successfully tested it, loading the SFX from my mighty AVGCART. composite.zip

The Self-Extractor capability is getting somehow monstrous. If you are wondering what the Composite SFXs will be... In a nutshell, one huge Composite SFX can record a full tape side without user interaction. Provided you have the right equipment - data recorder connected to the computer simultaneously with the device the SFX is loaded from.

If you want some support for emulating a data recorder with one of the turbo upgrades, consider also connecting the COMMAND wire.

Let us get some more power. The attached package holds two self-extracting archives that will record games in the Czechoslovak Super Turbo format, with transfer speed of 2725 bps. Try only when you know that Turbo 2000 SFXes already work for you. super_turbo_sfx.zip

I would recommend sticking to version 1.5. Whatever versions above 1.5 are typically unofficial mods of the original product. If version 2.11 is what I think - the splash screen says "Turbo 2000 system", then the DOS command executes a small menu with tape-oriented functions, and some memory is wasted for the T: CIO device. Recommended reading: https://github.com/dmsc/turbo-dis

There is more good news. w1k reports that a third party tester confirms the SFXes work. The only complaint is a rather short pilot tone for the first header block for Turbo 2000 files. This will be fixed in the final version of the SFX skeleton.

Some update on the affair with SFXes. w1k reports that his data recorder might not be in the best shape, which can affect the testing results. In any case, a 3rd party tester is welcome. No need for a video, a statement signed with your own blood is enough 🙂

Some standard library functions can be surprisingly "bulky" too, e.g. printf().

I have some update on the self-extractors. Firstly, I need to thank @w1k for quick testing. Now, we have a precarious situation. w1k's tests indicate that the files recorded using the self-extractors attached above are not working and cannot be loaded. I've performed my own tests (see the attached videos) and the files are loading, so I have exactly the opposite results. However, I am not exactly a disinterested party. My setup is simple - Stock Atari XL, PAL, 64 KB RAM, XC12 with a turbo upgrade compatible with Czechoslovak Turbo 2000. I am using JRC's VisiLoader and JRC's Turbo 2000 loader launched from UnoCart. I am launching the SFXes from UnoCart too. The cassette is FOX C60. In this situation, I am looking for disinterested third party testers, who would take the most recent self-extractors and try recording/loading, so we can see where the self-extractors stand. I am attaching two more extractors for more diverse testing. 20240129_214708.mp4 20240129_215121.mp4 20240129_214543.mp4 sfx_ng_test16k.xex sfx_ng_ataritenis.xex

While dealing with the bug above, I've decided for more radical changes in the Turbo SFXs. The block table now has 5-byte items. The last byte is dedicated to block flags. Two flags are currently in place - "no gap after block" and "elongate pilot tone". More flags might be available in the future. The recording environment (no INTRs, no DMA, Motor ON) is set at the beginning of the recording process and reset at the very end of the recording process. This has two advantages: 1. The recording is not spoiled by motor starts/stops, 2. The screen doesn't flicker after each written block. The screen stays blank until the recording is complete. The SFX creator fixes the bug above. The load address is now $0B80. Attached are 2 new test files. sfx_ng_diamondz_blockloading.xex sfx_ng_diamondz_expressloading.xex

Bad news. @w1k discovered a bug in the Turbo 2000 Self-extractors. The silence between the first turbo header block and the first turbo data block is too long. This can prevent loading the recorded file using a Universal Turbo loader. Ordinary Turbo 2000 loader works. I will work on a fix for the self-extractor code. Instead of silence between the header and data blocks, there will be a longer pilot tone. The Lower Silesian Turbo and Hard Turbo are not affected.

To explain the ALT-SPACE on my system, I have the PowerToys installed, and this shortcut opens a search bar. When disabled in the PowerToys control panels, the combination opens the window menu as expected.

Do not be afraid of exploring the menus and dialogs, they do not bite and they do not break things. Main Menu > Tools > Keyboard ShortCuts >> Tools > Scan for Blocked keys

Perhaps we can contribute by reporting the global keys problem to the vendors of the offending applications (if not reported already)

To deactivate the joystick emulation, go to the "Input" menu, select the "Port 1" submenu. In the submenu, select the "None" item. You might need to check also the "Port 2" submenu.

A dumb question, is the joystick emulation set not to be in conflict with the keyboard layout?