baktra

It seems there is a fix

Thank you so much for trying. I will commit, push, and release updated binaries. The fixed games are downloadable from the github repository or from its home page. If you are downloading from the home page, ensure you are not getting the old, cached copy. The date of the .bin files inside the .zip archive must indicate year 2023.

@olix, With the following document, you can assess if you would be willing to do so. https://web.archive.org/web/20120830055323/http://www.atarimuseum.com/videogames/consoles/5200/conv_to_5200.html With a cross-assembler and emulator, it might be doable.

How big is the actual motherboard of 5200? Could it just be taken and then fitted in a smaller, 3d-printed case?

The disk format is the same as SpartaDOS. So, if there is no difference in the settings (e.g., the VERIFY command), then it is probably the algorithm that looks for free space, manages it and overwrites the sectors. We would need someone who understands the very internals of that DOS. Cannot think of anyone else than Jiri Bernasek, or possibly @janzh. But as far as I know, Jiri Bernasek is out of the Atari game for a long time.

The a8cas-convert creates the fsk blocks whenever it detects a signal that doesn't constitute a regular data block. It can just be a noise, or it can be part of some copy protection scheme. To remove the fsk blocks, you can use for example TURGEN and its Tape Image Extractor function. That function allows you to display the contents of the tape image, select a subset of tape image chunks, and save them as a new, clean tape image. Another possibility is to use a8cas-convert to convert the .cas file to a .hex file. You can then edit the .hex file with a text editor, remove the fsk chunks and re-convert to a .cas file.

The .COM file is a monolithic one (one DATA segment, one RUN segment), so conversion to a boot tape shouldn't be a problem. DATA 08192-15270 [2000-3BA6] RUN 00736-00737 [02E0-02E1] R:08192 [2000] GH16K.cas

I have asked for help. It seems the problem can be fixed.

It would appear that my whole approach to reading the potentiometers was wrong. I have switched to using the the shadow registers, and at least under the atari800 and Altirra emulators, all seems OK. I would be grateful, if there is someone who would try the attached cartridge image with a real machine to confirm that the problem was fixed. The game should be controllable with both keypad and the analog stick. If this is confirmed to be working, I will release the updated source code, of course. train1_5200_testfix.bin

Thank you, I will remove the POTGO write and see what happens.

This is switching on power to the potentiometers of the analog stick. Without that, there would be no reading of the potentiometers at all.

The kpdLastkey is declared used in the assembler routines https://github.com/baktragh/train_5200_ose/blob/master/train_routines.asm

I am looking for help with the Atari 5200 version of the TRAIN game. I have never tested the game with real hardware, only with the Altirra emulator, where the game works. However, real hardware users report that the game doesn't respond to any controls. Can a subject matter expert review the code and identify what is wrong? I suspect something can be wrong with cartridge initialization code (beginning of the main() function), or with the joystick initialization jsInit(), or reading of the joystick - jsGet(). I've tried an alternate emulator (kat5200), but the cartridge wouldn't even start (just black screen). https://github.com/baktragh/train_5200_ose/blob/master/train.c Thank you.

You were not mistaken that much. Many .XEX files were indeed created from cartridge ROM images. Many older programs were distributed on cartridges with less than 16 KB of ROM. Getting a .XEX from them was not difficult. When it comes to .xex files, there are several ways they were conceived 1. The original program was distributed as a .xex file. That's the easiest and most obvious case. 2. The .xex was created from a bootable disk. Some software was designed to be booted from disk. Someone collected the sectors of the disk, added an initialization routine if needed, and a .xex was born. 3. The .xex was created from a bootable cassette. Similar to #2 4. The .xex was created from a cartridge ROM image. If the ROM was small and not bank-switching, the conversion was relatively straightforward. For large, bank-switching cartridges, the task requires extended memory and significant efforts.

It would be difficult. You would have to dump the ROM, use a disassembler to get the source code, understand the source code, and then modify the source code so that it would use extended memory banks instead of the cartridge address space. And then write a loader that would feed the extended memory banks with all the data. Unless you already are an experienced developer and a bright side cracker, it is a difficult task. @Fandal (who is a great developer and a bright side cracker) has already done that: http://atarionline.pl/v01/index.php?ct=search&query=crossbow&t=katalog The .xex version requires 256 KB of RAM, because the Crossbow cartridge is a bank-switching cartridge with huge ROM and you have to fit all the data from the ROM in the extended RAM.

If we look at this from another perspective, is any consumer grade power supply, older than 30 years safe?

I have also repackaged the 9.2.0 release. Together with the updated Download page, the repackage simply brings Java much closer to your fingertips. If you are not completely oblivious, of course. Plans for the next update release: Steal and add the loader, which allows you playing Pong in the process. Make the experimental, full package installers, the first citizens of the TURGEN project. Plans for the upcoming update releases: Turbo Rapider (PWM-based, Poland) Turbo 2600 (FSK-based, Poland, a candidate for the Standard Plus plugin). This will require an infrastructure change to support more flags for one plugin. Imagine that, Polish and Chilean flags next to each other. Is there any quarrel between these two countries? If you are wondering what an "update release" is, then let me tell you that the current versioning rules for TURGEN are the following: <major_release>.<minor_release>.<update_release>

I have updated the Downloads page. I will also update the product documentation and the Java launchers to point to this page.

I believe I have found a decent solution. Instead of linking to the Adoptium home page, I will provide a link to the TURGEN's Download page. At that page, I will provide various links for downloading Java. Fortunately, the Adoptium project indeed provides convenience URLs that allow downloading a specific or the most recent version of either JRE or JDK. I will provide one general link and a set of specific links for the most common cases, such as latest JRE for Windows or macOS. Thank you for making me think about this.

Behold the XEX2CAS 2.6.3 Remember, the product is in the "keep the lights on" mode. No enhancements, just minimum maintenance and bug fixes.

Yeah. Not so convenient as the Oracle's page. I will see what I can do to provide more convenience. I do not want the downloading and installing of JRE to be a "ritual of passage". It is already complicated as it is. TURGEN has a steep learning curve. Creating tapes requires at least some expertise. All things considered, a website where you would just choose games and click 'Get them in SITRE' format would work better. It is not impossible, though. TURGEN has a CLI and there is only one small step from CLI to "Spring" the program to the REST API. I would also love to provide a .dmg package for macOS. Unfortunately I didn't find a tool that would do it from Windows. Now I will take a detour to XEX2CAS. It deserves binaries for 2.6.3, updated TSCBL, and I intend to CMAKEize the project.

Enjoy 9.2.0 https://sourceforge.net/p/turgen/blog/2023/05/turgen-920---coffee-at-9-oclock/

This are just random thoughts I am preparing some collateral items for the 9.2.0. For example, keeping the Beginner's guide up-to-date with the most recent changes in the GUI. Since the JDK 9 is now a requirement, I have to change the documented System requirements, and also all links to the Java downloads. All links to the traditional Java for your computer page from Oracle does not help much as it is version 8. Besides, the warning about the licensing is somewhat scary too. It is tough to be smart in this case. After some contemplation, I decided to link to the Eclipse Adoptium project. Their download page is almost a friendly one. The TURGEN's website will need some subtle updates too. To be honest, running WordPress on SourceForge's web servers is not the best experience. The restrictions are tough and many things like automatic WordPress updates simply do not work. I still believe using a CMS is better than coding the pages directly. Saved me a lot of headaches. Since there is a lot of 'administrative overhead', I will not include any new tape loading systems in 9.2.0 and focus on the infrastructure work. The most valuable enhancement, a convenient plugin management, is already there. I also realized that TURGEN is missing a good automated regression test suite. Some portions of the product can be tested from the batch interface. That could be automated easily. However, some functionality is a typical GUI work and in that case, I would be programming a robotized user, clicking and using keyboard using a framework like Jemmy. Almost Impossible for a project that is a typical one-man show. No, no, no. The XEX2CAS project deserves one more release. There are important changes in the GIT repository (using the TSCBL binary loader instead of the older STDBLOAD 2a), but no binaries. I will need to do something about it. Speaking of XEX2CAS, you can see that in its successor named GENCAS, I show no mercy for the ! (Exclamation Mark) binary loader. I understand the loader is very traditional, but it is a terrible piece of software too. I believe the TSCBL is a great and open source replacement, and we will make do without the Exclamation mark loader. One is wondering what was the fate of the authors (Nudmehi Software).

I have found a nasty bug in 9.1.5. Whenever you save a Turbo 2000 or Super Turbo project item to a project file and then load the project, the transfer speed of the project item will be set to 600 baud (which is nonsensical). Therefore, there is a hotfix release 9.1.6. I have also realized that the number of downloads of the fullpack installation packages is not negligible. Since 9.2.0, the fullpacks will always be released. On one hand, some disk space is wasted, on the other hand, there are no headaches caused by multiple public JREs and JDKs in one system.

The development is going well. I have heavily simplified the 'Manage Plugins' function and fixed several related bugs. I will wait for some time until the 'dust settles' after 9.1.5 and go on with release 9.2.0 later. Those of you who are impatient, you can always get what you need from the GIT repository.