Turgen System 8.8.x Adventures

[baktra]

Counting the cycles in various loader states was fun:

• STATE_ID consumes 38 cycles to process the byte
• STATE_BUFLO,STATE_BUFHI, STATE_BFENLO consume 43 cycles to setup the buffer range bytes
• STATE_BFENHI consumes 45 cycles to setup the last byte of the buffer range
• STATE_DATA consumes 58 cycles to process a byte or 54 cycles to process the final checksum.

This is a significant imbalance. Investigation continues.

[baktra]

After a lot of counting and balancing the 6502 cycles, I believe I've got it right in the ExpressLoader.

The number of cycles now varies only between 57-59, which I believe is acceptable. I will try to test again with real hardware to see if the changes in the loader made a difference.

Counting cycles is fun, you can see in the current source code.

 

 

 

 

[baktra]

Finally I have some good news.

 

The problem with the ExpressLoader is not that hot as it seemed to be. After some experimentation, I've realized that the loading error was caused by a significant dropout on the tape. After re-recording the very same signal, the affected file loaded correctly without problems.

 

In any case, the imbalance in the number of cycles needed to process the most recent byte for various loader states is still significant, so anyone seriously (e.g. releasing software commercially) interested in using the ExpressLoading conversion should wait for TURGEN 9.1.1 (or go to GIT) which will be released soon and with updated ExpressLoader.

[baktra]

The 9.1.1 is out.

I've finished removal of the status bar, fixed the ExpressLoading conversions with updated loader and fixed the dual track generation for Linux and macOS. Enjoy!

 

 

[Mr.Bacardi]

 Inspired by Blowjobb's great tape version of "back to 80's" demo, I had some fun lately in creating "new" cassette tapes with loading sound. Here's the result...

Imagine this lineup being available back in the days!

 

 

 

[baktra]

On 11/5/2022 at 9:46 AM, Mr.Bacardi said:

 Inspired by Blowjobb's great tape version of "back to 80's" demo, I had some fun lately in creating "new" cassette tapes with loading sound. Here's the result...

Imagine this lineup being available back in the days!

Very nice to see these. Did  you try to spare the users' nerves by using a good compression to reduce the loading times? Of couse some of the games, such as Yoomp are compressed already.

[Mr.Bacardi]

I didn't bother too much about the loading time but I must admit that 10 minutes or more is getting critical for most users' nerves!

I did this mostly for my personal fun and to play around with Audacity and text to speech tools...

Please see some short examples, to get some feeling how much fun it can be to play around with 2nd recording channel...

1.)  The Empire strikes back

2.) Jump!

3.) Blowsub

4.) Sinistar (wait for evil Sinistar voice!)

 

 

[baktra]

Something from my past production.

Train 3 dual track with a special version of the TSCBL loader

 

 

[baktra]

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.

[baktra]

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.

 

 

 

Edited December 7, 2022 by baktra

[baktra]

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.

Edited December 8, 2022 by baktra

[baktra]

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:

1. Clicking the Remove complete and STOP buttons can result in deadlocks or ArrayIndexOutOfBounds exceptions
2. It is very difficult to stop output to the sound card in the Preview mode
3. 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 🙂

 

 

 

[baktra]

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.

 

 

 

[baktra]

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. 

 

 

 

[ascrnet]

I have always wondered why there are no TURGEN loading systems in Chile, since several of them have error recognition, which is to turn the counter back three numbers and reload the failed block again. 😅

[baktra]

1 hour ago, ascrnet said:

I have always wondered why there are no TURGEN loading systems in Chile, since several of them have error recognition, which is to turn the counter back three numbers and reload the failed block again. 😅

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.

[ascrnet]

26 minutes ago, baktra said:

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.

I see you know some, I can pass you the source code of some to see if it can be implemented. the idea is to be able to help in some way so that it is not so much work to disassemble. 😉

[baktra]

8 hours ago, ascrnet said:

I see you know some, I can pass you the source code of some to see if it can be implemented. the idea is to be able to help in some way so that it is not so much work to disassemble. 😉

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.

 

[ascrnet]

On 1/29/2023 at 3:54 AM, baktra said:

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.

 

Perfect, then we start with the first of them which is NHP36. Here you have the source codes in MADS and examples in the folder.

 

The loader consists of 3 files which are loader.asm, pag4.asm and pag7.asm. the generator program is the nhp.asm which asks you two mandatory things the name of the game title and the file to read. as an option you can generate it in turbo off is equal to 600 baud and turbo on 990 baud.

 

If you need anything, let me know.😉

[baktra]

A preliminary analysis of the loader shows the following:

 

The file format

1. Cassette boot file using the "data in EOF block" Trick. In essence a stage 0 loader. The loader is zapped with file name and number of blocks.
2. Non-standard, long  block that holds the binary loader code and data. This is loaded by the stage 0 loader.
3. Non-standard, short block that holds file name and the number of blocks expressed as 3-digits in internal code and as one byte in binary code. 
4. Series of 257-byte blocks that are as follows:
   0x55,      (calibration sequence)
   0x55,      (calibration sequence)
   blkno      (block number)
   userdata[] (data of the very block)
   ..
   numbytes  (number of valid bytes of the user data), full blocks have 252 ($FC) bytes
   chksum    (SIO-checksum)

The loader

 

It is one of the better ones. Binary load files with INIT segments are supported, though the fancy screen of the loader can still spoil loading for some files.

Ability to re-read a block is good. The loader is located in the RAM under ROM, so its XL/XE only and binary load files using the area cannot be loaded. The maximum number of blocks is 255, which gives a maximum file size of approximately 62 KB.  Loading such a file would take around 9 minutes when 900 bps is selected, which is at the borders of practicality. The loader could have been smaller, if the fancy screens were removed. That would of course reduce the 'cool' factor.

 

While analyzing the loader, I've enhanced TURGEN's Tape Image extractor so that it can display chunk data also in the internal code.

 

So what is next?

 

I will introduce a new plugin named "Standard Plus", which will become a "collection" of non-standard loading systems for non-modified data recorders. 

The first conversion type available will be "NHP" with a Chilean flag in the combo box. This looks like a plan for TURGEN 9.1.4 "Puerto Montt"

 

 

 

 

[manterola]

51 minutes ago, baktra said:

So what is next?

 

I will introduce a new plugin named "Standard Plus", which will become a "collection" of non-standard loading systems for non-modified data recorders. 

The first conversion type available will be "NHP" with a Chilean flag in the combo box. This looks like a plan for TURGEN 9.1.4 "Puerto Montt"

 

This sounds fantastic! By the way, your LBE loader should include the feature of reloading failed data blocks, and then it would be the ultimate "K7" loader (for players without modifications). Having survived years only with a cassette player, this feature alone saved me (and us, Chileans) lot of frustration. 

I remember that some old cassettes, or cassette with games we played too much, developed difficult data blocks, and using this feature I was able to still load the game by sometimes pushing down the door of the cassette player so that tape section was recognized as a valid data block. This required several tries with the most used cassettes, but it worked!

Thanks, baktra for bringing TURGEN to this world.

 

 

 

[ascrnet]

5 hours ago, baktra said:

A preliminary analysis of the loader shows the following:

 

The file format

1. Cassette boot file using the "data in EOF block" Trick. In essence a stage 0 loader. The loader is zapped with file name and number of blocks.
2. Non-standard, long  block that holds the binary loader code and data. This is loaded by the stage 0 loader.
3. Non-standard, short block that holds file name and the number of blocks expressed as 3-digits in internal code and as one byte in binary code. 
4. Series of 257-byte blocks that are as follows:
   0x55,      (calibration sequence)
   0x55,      (calibration sequence)
   blkno      (block number)
   userdata[] (data of the very block)
   ..
   numbytes  (number of valid bytes of the user data), full blocks have 252 ($FC) bytes
   chksum    (SIO-checksum)

The loader

 

It is one of the better ones. Binary load files with INIT segments are supported, though the fancy screen of the loader can still spoil loading for some files.

Ability to re-read a block is good. The loader is located in the RAM under ROM, so its XL/XE only and binary load files using the area cannot be loaded. The maximum number of blocks is 255, which gives a maximum file size of approximately 62 KB.  Loading such a file would take around 9 minutes when 900 bps is selected, which is at the borders of practicality. The loader could have been smaller, if the fancy screens were removed. That would of course reduce the 'cool' factor.

great job, of course it has all the limitations you mention, but if we think back to 1991 it was common to highlight the distributor's brand of the game.
Today you can make many improvements, but you choose to leave it as it was done at the time. 😄

 

5 hours ago, baktra said:

The first conversion type available will be "NHP" with a Chilean flag in the combo box. This looks like a plan for TURGEN 9.1.4 "Puerto Montt"

Nice, but you can call it NHP 3.6 "NHP rainbow", as this copier has many versions since NHP 1.0. Will it be possible to put the title of the game and the normal or turbo recording mode? 😅

 

4 hours ago, manterola said:

This sounds fantastic! By the way, your LBE loader should include the feature of reloading failed data blocks, and then it would be the ultimate "K7" loader (for players without modifications). Having survived years only with a cassette player, this feature alone saved me (and us, Chileans) lot of frustration. 

I remember that some old cassettes, or cassette with games we played too much, developed difficult data blocks, and using this feature I was able to still load the game by sometimes pushing down the door of the cassette player so that tape section was recognized as a valid data block. This required several tries with the most used cassettes, but it worked!

Thanks, baktra for bringing TURGEN to this world.

I also spent years as the only device the cassette deck and totally share your experience. another trick I used was to adjust the azimuth screw of the cassette deck when there was no case of block loading. 😆

[baktra]

3 hours ago, ascrnet said:

Nice, but you can call it NHP 3.6 "NHP rainbow", as this copier has many versions since NHP 1.0. Will it be possible to put the title of the game and the normal or turbo recording mode? 😅

 

I will name it "NHP 3.6 Rainbow" and I will keep the loader as it is. Of course, transfer speed and program title will be fully configurable, including centering of the text and possibility to enter internal hex codes to use the whole character set and colors.

[baktra]

Cooking...

 

 

[baktra]

Still cooking the NHP support. I have a successful conversion of the stage 0 and stage 1 loaders. Moving on to the binary load file conversion to the NHP non-standard blocks.