Turgen System 8.8.x Adventures

[Chri O.]

Reason I ask is because I partially build my own microcontroller based wav player that can actually be used as audio input and it does listen to the ATARI SIO motor ON signal. Which basically means I can send through the USB a key press for Pause and Play.

[baktra]

10 hours ago, Chri O. said:

Reason I ask is because I partially build my own microcontroller based wav player that can actually be used as audio input and it does listen to the ATARI SIO motor ON signal. Which basically means I can send through the USB a key press for Pause and Play.

I am not sure if I understand correctly. I assume that the USB device would behave as a HID device, sending key presses to the comuputer whenever the MOTOR CTRL signal changes. Perhaps TURGEN can be programmed to respond to two distinct key presses (PAUSE, RESUME) when sending audio directly to the sound card. The challenge would be the RESUME function - identify the right place where to resume after the pause signal comes in. There is certain delay because of the audio buffering.

 

A standalone application that would communicate directly with the USB contraption would probably be a better choice.

[Chri O.]

4 hours ago, baktra said:

I am not sure if I understand correctly. I assume that the USB device would behave as a HID device

Since my device is based on Teensy 4.1 MCU it's really easy to do this simply by selecting the right USB Type. 

Example: Using USB Keyboard

4 hours ago, baktra said:

The challenge would be the RESUME function - identify the right place where to resume after the pause signal comes in. There is certain delay because of the audio buffering.

Got it.

I am assuming you are actually decoding the Atari FSK Stream. I wonder if this will even work with Atari Educational System tapes "Dorsett Talk and Teach System" this is because it's using some type of Modem FSK tape coding.

See this: EduEncode - a library for encoding Atari Educational System tapes!

[baktra]

Some news from the labs and latest pushes.

 

The "bad" stuff:

• Turbo Rapider 7500 is still resisting my reverse engineering attempts
• Do not know what to do with the L3 loader for KSO Turbo 2000. Doesn't work with Altirra, does work with atari800 and sometimes works with the real hardware. Altirra shows random off-by-one-bit errors in the loaded data.

The "users do not care" stuff:

• I've fixed many findings by the SonarLint. There are some things that I cannot fix, because the code is generated by the Netbeans GUI designer. Some fixes would (IMHO) impede readability too. Using the SonarLint was a good experience, however.

The "good" stuff:

• I've refined the pulse durations for the KSO Turbo 2000 to be closer to the reality
• The FlatLaf Look and Feel is updated to 3.2.5. You can select two extra macOS-like themes. The clothes make the man.
• The GENCAS command line interface accepts a Tape Image convertor in the full mode. As a consequence, GENCAS can serve both as XEX2CAS and CAS2WAV on (a lot of) steroids. POWER !!!!.
  Using the syntax below, you will achieve the CAS2WAV functionality.

  gencas -mode:full -o:wav "-conv:Tape Image" examples\test16k.cas examples\test16k.wav

[baktra]

On 11/16/2023 at 9:58 PM, Poison said:

It would be great to create USB3(or C)2SIO, connect XC12 directly to PC and create tape backups via Turgen  And create new MCs from Turgen directly to XC12

I am considering one way of making cassettes using purely XC12. Something like a self-extracting archive.

It would work as follows:

 

1. Pick your game that you have as a .xex file, give it to TURGEN

2. TURGEN takes that .xex file and prepares a special turbo 2000-self-extracting .xex file

3. Take your favorite universal cartridge or SIO2Whatever device, load the special .xex file

4. Insert a blank cassette 

5. Press PLAY+RECORD, press any key to start recording.

6. Your cassette is ready.

This way, a game could be distributed on a floppy disk or a cartridge, allowing you to create your own cassette version as an option. All you would need is your mighty XC12 and a blank cassette.

[baktra]

I am attaching the very first "Turbo 2000 self-extractor".

turbo2000sfx_test_cubico.xex

 

How to use it?

• Load the .xex file from SDrive, Universal Cartridge, or anything that is capable of loading .xex files that begin at address $0C00 or higher. 
• Connect your data recorder with Czechoslovak Turbo 2000 or compatible upgrade to the Atari computer
• Insert a blank tape in the XC12, reset the counter to 000
• Press PLAY+RECORD
• Press START
• The CUBICO game will be recorded to the tape. Just wait until the title screen re-appears.

Then rewind the tape to 000, launch your favorite Turbo 2000/Universal Turbo loader and try to load the game from the tape.

Does it work or not? Try and let me know!

 

If this works, I will add a function to TURGEN which will allow you creating Turbo 2000 self-extractors for many programs of your choice. And you will not be restricted to just monolithic binaries. Chainloading, Blockloading, ExpressLoading, Turbo 2000 - kilobyte blocks will all work.

[baktra]

A more advanced self extractor for testing.

sfx_test_train2.xex

Improvements:

- Maximum number of turbo blocks increased to 255

- A small INIT segment at the beginning disables the screen DMA. This prevents glitching when the data goes to the screen RAM used by the screen editor.

- Better structure of the turbo block table

- Improved look and feel.

- Verified loadability using the MyPicoDOS binary loader.

 

This one records the TRAIN 2 game on tape using the Turbo 2000 - BlockLoading format. No worries, a plain Turbo 2000 loader is still enough to load the game after recording it to tape.

 

[baktra]

A few words on how I would outline the support for the Turbo 2000 self-extractors in TURGEN.

1. You will prepare project items as usual
2. You will select project items that you want to make self-extractors from
3. You will select Tools->Special ->Create Turbo 2000 self-extractors
4. You will specify the output directory
5. You will click the Create Self-Extractors button

On output, you will get

1. Report on what items were successfully or unsuccessfully processed (of course only items for the Turbo 2000 and Turbo 2000 - Kilobyte blocks will be processed).
2. In the output directory, you will find .xex files with self-extractors
3. For big inputs, you will get multi-part self-extractors (game_p01.xex,game_p02.xex).

In further iterations, an alternate output to a disk image with MyPicoDos can be considered.

Edited December 23, 2023 by baktra

[Poison]

will be possible to create more than one in one time ? I mean, that i will choose more than one file and it will create all self extract xex in one step.

[baktra]

10 minutes ago, Poison said:

will be possible to create more than one in one time ? I mean, that i will choose more than one file and it will create all self extract xex in one step.

Yes, of course. If you create and select more project items before invoking the Create Turbo 2000 self-extractors function, the function will create self-extractors for all of the selected items in one pass. So it will be convenient.

Edited December 23, 2023 by baktra

[baktra]

If anyone is curios how all this self-extracting works, there are a few details.

 

 

On the Atari side...

The foundation is a self-extractor skeleton. It is program written in 6502 assembly. This program displays the screen shown a few posts above and holds a general routine for writing turbo 2000 blocks to tape. The routine was "appropriated" from one of the Universal Turbo copiers by JRC.

 

After that, the skeleton holds a table. Each entry in the table describes one turbo 2000 block (output buffer ranges). After the table, the data of the blocks follows.

Of course, the table is appended to the skeleton by TURGEN. TURGEN also zaps the area dedicated for file name.

 

Once the user presses the START key, the skeleton gets to the beginning of the table and keeps recording turbo blocks, until the end of the table is reached. The process can be repeated, so one can write multiple copies, if needed.

 

I intend to publish the source code of the skeleton together with instructions on how to use it (I guess nobody except me will). I am sure that a few developers would find a way to save a few bytes here and there. I don't like bloatware either, but keep in mind, I am institutionalized by corporate development.

 

On the TURGEN side.

It is not that difficult. The self-extractor creator will get a collection of project items on input.

 

For each project item, the following will happen:

1. Validate the item - is it created by a plugin that generates Turbo 2000 blocks? If not, report it and continue with next item.

2. Let the respective plugin convert the playlist item to the internal signal generator instructions.

3. Read back the internal signal generator instructions and extract only instructions generating turbo 2000 data blocks. Store them in a collection.

4. Template a new self-extractor skeleton in memory.

5. Get next turbo 2000 data block. If it fits in the current skeleton, add it to the current skeleton.

6. If it doesn't fit, flush the current skeleton to disk and template a new one with _p01,p_02 suffix. Add the block to the new skeleton.

7. Keep doing that until all blocks are processed, flush the remaining skeleton to disk.

 

Good new is that I can test all of it using FUJI's modified emulator.

 

Limitations.

1. The longest possible turbo 2000 block is around 44 KB. That shouldn't be a big deal, because .xex files with segments longer than 44 KB are rare. Remember, this is limitation for a block size, not for the total file size. Let us take the Ridiculous Reality game. The total size of the game is >60 KB, but none of the segments is longer than 44 KB. Therefore you can create a SFX for it (it will be split in two parts, but it will work).

 

What about Turbo 2000/Univeral Turbo Loader?

The SFX is for those who have either some universal cartridge or a floppy drive emulator. The loader can be started from these devices.

 

What about Omicron Turbo?

The stage 0 loader is available as a .xex file, so you can load it from your unicart or floppy drive emulator too.

 

 

 

Edited December 24, 2023 by baktra

[baktra]

I've tested the 2nd self-extractor with real hardware, and it works. So the Turbo 2000 SFX creation will come with next TURGEN release.

 

On the Atari side, I will need to adjust the SFX skeleton a bit.

 

Currently, the recording sequence is the following:

1. Wait for START

2. Delay for a while

3. Motor ON, ready for turbo recording

4. Record block

5. Motor off, goto 2 if not EOF

 

The sequence can be improved, because pieces of original recording are left on tape.

It will also help to stabilize the mechanical and electrical parts of the data recorder at the beginning of the recording.

 

I better do it as follows:

1. Wait for START

2. MOTOR ON, ready for turbo recording

3. Delay for a while

4. Record block

5. Delay for a short while

6. Motor OFF , goto 2 if not EOF.

 

[baktra]

There will be one small enhancement to the ExpressLoading conversion for Turbo 2000 and Omicron Turbo.

Improved compatibility with more binary load files. While testing, I've realized that binary files that call CIO during the loading process mostly do not load.

 

Well, in the ExpressLoader, there was the following "sequence of doom":

 

       LDA ICAX4Z  ; Get the ID byte of the turbo block
       AND #$40    ; Is there INIT vector indication?
       BEQ NOINIT  ; There is not, skip INIT
       JSR DOINIT  ; Call the INIT segment
NOINIT LDA ICAX4Z  ; Get the ID byte of the turbo block
       AND #$80    ; Is there EOF indication?
       BEQ NEXTB   ; It is not, get to the next block
       JSR DORUN   ; EOF, run the loaded program

 

What was I thinking? That the CIO calls in the INIT segment will not obliterate ICAX4Z? Very naive indeed 🙂

It is fixed in the latest commits, I save the ICAX4Z value in the stack. It seems safe, because it is in the best interest of an INIT code not to corrupt the stack, isn't it?

 

 

 

[Chri O.]

Hey I got a question about the German (CHAOS SYSTEM) Turbo 6000.

I am on TURGEN 9.2.6 currently and the maximum transfer speed setting appears to be 3200 baud.

I was under impression it's supposed to be 6,000 ?

[baktra]

33 minutes ago, Chri O. said:

Hey I got a question about the German (CHAOS SYSTEM) Turbo 6000.

I am on TURGEN 9.2.6 currently and the maximum transfer speed setting appears to be 3200 baud.

I was under impression it's supposed to be 6,000 ?

Well, that is the magic of the marketing.

 

If your file was just all zeros, you would reach 5512 bps (pulse duration for 0 is 8/44100 s)

If your file was just all ones, you would reach 3150 bps (pulse duration for 1 is 14/44100 s)

 

So, if one wants to be honest technician, the speed could be advertised as 4331 bps in average (assuming there is the same number of ones and zeros in the file).

From the marketing perspective, it is different. Let us take the speed for zeroes, round to the closest thousand, and here we have... Turbo 6000. Such name is much more appealing than Turbo 4331 or Turbo 4300.

 

If you study the block format of Turbo 6000 closer, you will find a rather disturbing similarity with C64 tape block format. The RAMBIT circuit can be modified to support this system. Instead of INTERRUPT, the output signal is applied to the PROCEED pin. The polarity of the pulses is the opposite, though.

 

As another example, the Czechoslovak Turbo 2000 was intentionally and openly inspired by the ZX Spectrum loading system.

 

 

 

 

Edited January 1 by baktra

[Chri O.]

57 minutes ago, baktra said:

The polarity of the pulses is the opposite, though.

WOW thanks for this tip.

I knew about the proceed SIO PIN but not the polarity issue thanks.

[Chri O.]

I hate to bother you but why do we need COMMAND SIO pin in Czechoslovak Turbo 2000 implementation❓

.... https://turgen.sourceforge.io/docs/Turbo2000_Upgrade.pdf

I am just curious if it's turned on the whole time or if it's actually used for any type of command ?

[baktra]

6 hours ago, Chri O. said:

I hate to bother you but why do we need COMMAND SIO pin in Czechoslovak Turbo 2000 implementation❓

.... https://turgen.sourceforge.io/docs/Turbo2000_Upgrade.pdf

I am just curious if it's turned on the whole time or if it's actually used for any type of command ?

The command signal is for switching between the turbo and standard (original) modes of operation. Command active = Turbo, not active = Standard. Since the XC12 doesn't have a wire for the command signal, the audio-in wire is given another purpose. That's why the capacitor in the SIO connector. This variant of the T2000 upgrade maximizes usage of the existing components in the recorder.

 

If looking for something more standalone, you can have a look at the cd-link interface. Turbo 2000 decoder that connects to CD Audio players and similar devices. Source: http://blog.3b2.sk/igi/post/Hardware-CD-LINK.aspx

[baktra]

I am placing one more prototype Turbo 2000 self-extractor in the wild.

This one records the TRAIN game using the ExpressLoading conversion.

sfx_test_train_expressloading.xex

[baktra]

This is how the dialog for creating Turbo 2000 SFXes will most likely look like.

[baktra]

Work on the Turbo 2000 SFX continues with latest commits.

 

So does some testing on real hardware. I made the Bum Box device busy, while testing many plugins and conversion types. I repeat this testing here and there to verify if everything still works. Everything seems to be in order.

 

 

Some notable results:

• The L3 loader for KSO Turbo 2000 works. I will therefore keep it.
• With Bum Box, the speed of 6315 bps works.
• Turbo 2600 works with base speed 
• Turbo Blizzard works, requires a lot of fiddling with the signal amplitude.
• The ExpressLoading conversion for T2K and Omicron Turbo works with both Bum Box and real cassette.

[Chri O.]

Fantastic progress 🙂

[w1k]

i will test on real hw with xc12 today or tommorow

[w1k]

hmm.. using standard turbo 2000 loader

Edited January 4 by w1k

[baktra]

9 minutes ago, w1k said:

hmm.. using standard turbo 2000 loader

 

Thanks.

 

I've tested the very same file yesterday (real tape, real XC12) and worked. I didn't use the plain Turbo 2000 loader, but a VisiLoader instead.

 

The BOOT ERROR message is displayed by the Turbo 2000 loader. This indicates that the Turbo 2000 loader loaded the header correctly, but not the following block, for whatever reason. I would try with a loader that doesn't wait for a key when displaying the header. If I can have a .xex file for the Turbo 2000 loader, I would make the same test myself.

 

Let us see what other testers will report.