baktra

That would be much appreciated. If I have a loader and file format, writing a plugin is easy. It was always this way with TURGEN: 75 % reverse engineering, 25 % programming TURGEN.

I am aware of NHP, SITRE and STAC. I always had certain objections, because some reside in the RAM under ROM, some do not support binary load files with INIT segments and some have fancy loading screen. That's why I decided to create the LBE system. I am not saying no to the gang of three, but they are not on the top of my TODO list. They can go higher if one of the following happens: 1. I go berserk and disassemble their loaders and understand the file format, all resulting in a new plugin or plugins 2. A documentation of the file formats and disassembly of the loaders mysteriously appears or I find them. Number 1 seems more likely and happened in the past with other file formats or loaders.

The adventures continue for the GENCAS command line interface. With the latest commits, you got the following: 1. The gencas.sh script has been fixed, so it accepts parameters with spaces. 2. All GENCAS functions work in a headless environment. A headless environment is an environment without a GUI (e.g., GNU/Linux without X11/Wayland, WSL) Theoretically, this would allow creating a web version of TURGEN.

These are commit SHAs. With GIT, each commit (a piece of code contributed to the project, if I simplify it) is calculated an SHA (it is a sophisticated checksum). The first few digits of the SHA are then used to identify the commit. The file names in question indicate that the binaries were compiled from a commit that has the id of gb05282e. This is normal for the development versions, because each development version can be easily tracked to a given commit.

I believe there is a minor problem with cassette emulation. The 'Load data as audio option' doesn't seem to work for tape images with pwm blocks. When the option is selected, the turbo data track cannot be heard. The standard records (baud, data) can be heard, though. Version 4.10, sample tape image attached (a cassette boot file followed by a turbo file). Set the emulated turbo system to Turbo 2000 (COMMAND active) and boot from the tape with START+OPTION. Atari XL/XE OS ROM is needed. mix_baud_pwm.cas

One of the tools for extracting files from .atr images is atrcompiler. You will find it at github. Compiles under Win/Lin and probably under macOS too. It is command line driven, that is good for automation. One of its functions is extraction of all files from the disk image. The tool is used by the FLOP magazine's editorial staff to build the magazine.

Number one is challenging enough, but feasible. Information on DOS 2, MyDOS, SpartaDOS and DOS II+ file management systems is available and command-line driven file extractors for PC already exist. SpartaDOS is always a challenge because of the complexity. Number two is an extreme challenge, because menu disks can be prepared by hundreds of programs and there are probably hundreds of “proprietary” file systems. Probably some system with plugins that would be able to detect and extract files would work. Exactly the same would apply to cassettes, but I would put those beasts aside.

Yes, the first encounter with ld65 is usually a harsh one. But it is nothing compared to LD. On the other hand, when a common Win/Lin/Mac programmer needs to place data to a specific virtual/physical address?

I don't believe so. I would go cross-platform. Native C development environments for 8-bits are usually clumsy, because the computers were not powerful enough. At Atari, they were developing cross-platform in the 80s too, using assemblers executed on stronger computers. A 40-column screen doesn't help either. When it comes to development using CC65, it is not a bed of roses, too. I would always consider the following: There is no rich library of functions for sound and graphics for Atari. Therefore, knowledge of how the Atari hardware works and how it is programmed is still essential. C65 is not at fault here, it is the way it is. One has to know assembler and how to interact with C. One must know how the LD65 linker works. This is especially important when including data (like fonts, bitmaps, display lists) in the project. Unsurprisingly, the generated code is not as good as handwritten assembler. This makes the CC65 somehow sandwiched: The assembler developers would complain about inefficient code and boilerplate syntax, fighting with the compiler. A better choice can be to stick with ASM. The higher-level language programmers who would find the library insufficient and do not want to deal with the intricacies of the linker. A better choice can be the Mad Pascal with richer library.

I am wondering in any of those dup tools can perform a fuzzy compare, i.e. showing how much likely in % two files are duplicates. I would only suggest answering a simple question. How does my archive differ from other archives? Isn't it better to contribute to the existing ones? Once I was considering an archive of monolothic .xex files (for whatever dubious reasons). Then I realized I'd better create a tool that harvests these files from existing archives.

Turgen 9.1.3 has been released. This is mostly a bugfix release. In a nutshell: I've fixed (or at least I believe so) all the blunders in the Worklist described in the above post. The bugs were distressing. Around 66 % of the documentation was verified and fixed using Grammarly and LanguageTool. This effort will continue until the whole documentation is done. Turgen ships with two example programs. These programs work with all 8-bit computers, including Atari 400. Their purpose is to give you something foolproof for your first steps and tests with TURGEN.

There is one called ATADIM. http://raster.atariportal.cz/forpc/atadim.htm To warn you in advance, this program has one peculiarity. It expects you to drag and drop a disk image to it or have the .atr extension associated with it. If you try to run ATADIM just by double-clicking the atadim.exe, it will not allow you to do anything meaningful. There is no File>Open menu.

Your solution by putting the #pragma data-name directive to the font.c is correct. And that is exactly where it should have been in the first place. Why is that? The extern unsigned char GAME_FONT[]; statement doesn't generate any machine code or data. It is just a symbol for the compiler that will be resolved later by the linker. Therefore, there is no code or data that could go to the FONT segment. That is also clear from the .map file. The .map file has no mention of the FONT segment. So, if you want to use the #pragma data-name directive, use it where the data is defined, not where it is declared.

Fandal's collection at: a8.fandal.cz Top quality digital images (.atr, .xex) of 8-bit Atari software.

I have subjected TURGEN to certain stress tests. I've tried to process around 2400 monolithic binary load files from the recently updated game archive at atarionline.pl In terms of performance, TURGEN performed admirably. The Wizard for Files can take 2400 binary load files and make project items from them in 20 seconds. A profiler revealed 2500 unnecessary calls of the File.getCanonicalPath() method that have proven to be very costly. When eliminated, the time was reduced to 12 seconds. This is a favorable result. A rather unfavorable results were yielded by the WorkList code under stress. When processing 2400 project items, the following can happen: Clicking the Remove complete and STOP buttons can result in deadlocks or ArrayIndexOutOfBounds exceptions It is very difficult to stop output to the sound card in the Preview mode Cancelling generation of WAVE files results in displaying nonsensical elapsed times In a nutshell, we had one extremely poor multi-threading piece of code and one programmer's ego badly bruised. Why the past tense? Because now, we have fixes pushed to the GIT repository and a programmer who learned his lesson on the intricacies of the AWT Event Dispatching thread. P.S. The ego is still bruised 🙂

Since I've mentioned testing of the LBE loader, here you can see the LBE PMG loader in action. For those who forgot what LBE is, it is my attempt to create a loading system at least partially comparable to NHP, STAC or SITRE. lbe.mp4

Today, after long time, I took my real hardware out of the cold storage for a while and performed what I call a "reality check". I have tested the LBE loader for the Standard plugin and the ExpressLoader for the Turbo 2000 plugin with a real hardware. The recording chains were the following: 1. Turgen ->WAVE file (harmonic pulses) -> MP3 file (320 kbps CBR) -> Pocket MP3 player -> Tape Deck -> FOX C60 tape -> Atari XC12 -> Atari 800XL. 2. Turgen ->WAVE file (harmonic pulses) -> MP3 file (320 kbps CBR) -> Pocket MP3 player -> Cassette Adapter -> Atari XC12 -> Atari 800XL. For both chains, all test files loaded successfully. A "bonus" chain: 3. CAS File -> CAS2Audio Android App -> Cassette Adapter -> Atari XC12 -> Atari 800XL works too.

One possibility is to use atrcompiler's unpack function to extract files from a disk image.

Perhaps using OSD to indicate the decoding process would be worth considering.

The beta stage is over. I give you mmSAP 3.0.0. What are the differences compared to the latest beta? Release title 🙂 The file choosers display recently selected .SAP files, but only privately to mmSAP

With the following command lines: altirra c:\users\baktra\a8\pokus_changed.cas /f altirra "C:\Users\baktra\a8\filtered\turborom_zestaw4_strona_A.wav" /f I can confirm the behavior with Altirra 4.00; the emulator doesn't go to fullscreen With Altirra 4.10-test26, the emulator goes to the fullscreen as expected. So perhaps, you can switch to the development version, if you can.

Thank you for this small convenience enhancement. I've tested this enhancement with a tape image that begins with a Turbo Blizzard loader stored as a cassette boot file followed by a Turbo Blizzard file. Booted and loaded just fine. When it comes to the decoder choice, these are my observations. These observations can help those who want to use the Altirra emulator with machine-generated turbo recordings. I believe my observations are in line with the nature of the decoders. For square waveform: The PEAK+HPF works with average bps < 3500. For higher average transfer speeds, plain SLOPE works. For sine waveform: The PEAK+HPF works with average bps < 3500. The SLOPE works with bps <2700, but nothing above.

Yes, Turbo Blizzard is somehow finicky. No surprise, the default transfer speed is very high. So "Slope" it is. That would be nice. The point probably was to save the extra wire seen with other turbo systems. Believe it or not, I didn't realize that. That explains some of my problems. Thank you very much for looking into this.

I might have discovered a turbo tape related problem. Version -test25, could be also others. Attached is a package with a WAV file (a tape image with Polish Turbo Blizzard records) and a .xex file with loader. When I use the old Altirra 3.90, then the following works: 0. Setup the emulated system as follows: - Plain XL/XE with 64 KB RAM, no extensions etc. - Original OS ROMs - TV System: PAL - Cassette: Turbo support == Enabled (always on). Turbo Decoder: Default option. 1. Boot the .xex file 2. Select option 4 (Blizzard Turbo 2.8) 3. Press SELECT (to run MICROLOADER) 4. Load the .WAV file as a tape image 5. Press a key to begin loading After a while, the MICROLOADER will display the file name and ask to press the 'Y' key to continue loading. The Archon game loads and runs. When I try the same with the -test25 version (after clearing all settings and re-configuration), in step 5, the MICROLOADER will not display the file name. Also the screeching sounds differently. Good to know: 1. The Turbo Blizzard works like the Turbo 2000, but switching on the turbo mode is different. Instead forcing log.0 at COMMAND, Turbo Blizzard forces log. 0 at DATA OUT. That's why I use the Enabled (always on) turbo support. A final question. When I select a different Turbo decoder in the system settings, do I need to reload the tape image? blizpak.zip

I've released TURGEN 9.1.2 This release doesn't bring too much new, but fixes a nasty bug in the Atari Super Turbo plugin. The conversion of binary files to the Polish Unerring Master system was broken. If you tried to convert a binary file that ends with an INIT segment, you've always got a loading error.