baktra

The initial work on the Turbo D support is almost finished. You can take files and convert them to Turbo D, create .WAV and .CAS files, output audio. You can use the Wizard, CLI, and batch processing to create Turbo D project items. What you cannot do so far, is creating TSFXes. I didn't "borrow" the block recording routine yet. When it comes to loaders/operating systems using Turbo D, I've added information on the significant ones (there are others available) to the product documentation. Download these loaders from w1k's archive. Turbo DNM MOS. A small tape operating system. Makes the Turbo D accessible through the D : (duplicated blocks) and N : (non-duplicated blocks) CIO devices. Provides a Run function that can load and run binary load files (like the BINARY LOAD function of Atari DOS 2). Segmented binary load files and INIT segments are fully supported. MEMLO is around $2000. Turbo DNM MOST. Same as Turbo DNM MOS, except that instead of using the original Turbo D hardware modification, this loader works with the Czechoslovak Turbo 2000 and compatible hardware upgrades. BLOAD (V0,V1, V2). Miniature utility/game loaders. The V0 includes the D : device handler, other versions do not. Notably, these loaders only load boot files, and not binary load files. As you can see, the situation with the loaders is not ideal. Imagine my disappointment when I realized the BLOAD loaders do not support binary load files (as I originally thought), only boot files. C'est la vie. The Turbo DNM MOS tape operating systems are solid performers when it comes to loading binary files, however the MEMLO is rather high for many games.

I have scored some points when dealing with the "terrible .CAS files". Now, instead of having thousands of pwml chunks, you can see a few pwmd chunks, followed by up to pwml chunks. How I accomplished that? The 8 to 9 bits encoding of the Turbo D requires being somehow creative. Instead of generating 9 standalone pulses for each byte, resulting in thousands of pwml chunks, I keep adding the bits to a bit vector in memory. When a block of data is finished, I flush the bits as follows: 1. Get number of full octets (bytes) in the bit vector [number_of_bits div 8] 2. Get the number of stray bits at the end of the vector [numbe_of_bits mod 8] 3. For the full bytes, generate a turbo block. This will result in a pwmd chunk in the tape image. 4. For the stray bits, generate wide and narrow pulses. This will result in up to 7 pwml chunks in the tape image.

The speed detection routine is flexible enough to support that speed. In theory, and in emulator. Practical limits are given by the tape and the recorder. SONY HF beats Emgeton LH. Turbo D, like many other systems, advertises "the speed of logical zero". That means 9600 bps is actually 7200 bps for a recording that has 50% zeros. In any case, it is "fast enough".

I am getting back to the matter of Turbo D. I have answers to the questions above. The modulation is the same as for the other "Turbo" systems. Wide and Narrow rectangular pulses are used to encode 1s and 0s There is no explicit switching to turbo mode, because a "non-standard" input path is used (like Turbo 6000 and Rambit) The signal goes to the computer through joystick port #2, pin 1 (joystick up). The loader is polling the joystick port as follows: LDA #$10 : BIT PORTA : BEQ/BNE <address>, when DMA and interrupts are off. It is the same as the existing (Joystick Port 2;KSO Turbo 2000) decoder, except a different pin of the joystick port is used. The loader expects certain polarity of pulses. Motor is controlled normally, using MOTOR CTRL. @phaeron, if you would be interested in adding support for Turbo D to Altirra, I can provide a sample recording, loader and instructions on how to use them (#4 and #5). Be advised, the user base of Turbo D is 2–3 users only. Some indication of the business value. On the other hand, I do not believe that the user base of the already supported turbo systems is much larger. Thank you

Another visualization of progress on Turbo D. I promise, next updates will be textual. I need to perform some testing and update the documentation. Not everything is nice and fluffy, though. Sadly, the .cas files with Turbo D are rather terrible. The .CAS format is not that great for the 8 to 9 bits coding used by the system. Tons of pwml chunks.

Visualizing progress on Turbo D

Yes, one of these moments when despair turns to enlightenment. And sometimes back to despair. There will be a new Turbo D plugin soon, together with the flag of the Slovak republic. That is historically inaccurate (Turbo D is from before 1993), but more illustrative, depicting the place of origin of the system.

And even more good news. I was able to generate a correct Turbo D WAVE file for the Ridiculous Reality and Swapz games. All loaded ok using the Turbo D system, in a modified emulator.

More good news: Now I have the following information on the structure of a data block: Offset (decimal) 0,1 - Length of the user data (length_u), encoded as HI(length_u)+1,LO(length_u)+1. This is the length of the user data. 2,3 - Length of the block data(length_b), encoded as HI(length_b)+1,LO(length_b)+1. This is the total length of the block (except the first 4 bytes) 4 - Sequential number of the block, beginning with $00, ascending. Then the bytes of the block data follow. The last byte of the block is a checksum. The checksum is a sum (clc, adc) of the previous bytes (including the first 4 bytes) modulo 256. The byte preceding the checksum is probably a random "synchro byte" as described in the documentation. The header block has a similar structure as the data block. Offset (decimal) 0,1 - Length of the user data (always $14 bytes), 2,3 - Length of the block data (always $17 bytes) 4-23 - A device:filename string, terminated by EOL ($9B), ATASCII 24,25 - Probably sequential number and synchro byte (will be verified by experimentation) 26 - Checksum This might be enough for me to try generating a WAVE file in TURGEN. At least something (WAVE, audio, tape image), but still a long way to go to the Tape Self-Extractor for this rather peculiar system.

One small step forward with Turbo D The meaning of the first 5 bytes of each data block is the following: Offset 0,1 - Length of the data, encoded as HI(length)+1,LO(length)+1. Strange way of encoding, perhaps to do with easy use of the carry? 2,3 - Length of the data+3, encoded as HI(length+3)+1,LO(length+3)+1. Even stranger. 4 - Sequential number of the block, beginning with $00. Then block data follows, this is clear. Then one or two bytes follow. Most likely checksum, still unknown algorithm.

For a simple case of a defective cassette (something everyone distributing software on cassettes must take into account), the letter is rather wordy. I like the overall polite style of the letter, though.

Yes. The original word is "Mazat", which can mean To Lubricate or To Erase/Delete. In this context, it means delete. Slashed red LED - Crossed out red LED. Wonders of a machine translation.

Some minor progress on Turbo D. Let us have the following BASIC program and run it under Turbo DNM system. 10 OPEN #1,8,0,"N:AAAB" 20 FOR I=1 TO 3 30 A=255 40 PUT #1,A 50 NEXT I 60 CLOSE #1 We get a partial block analysis as follows. Note that the bits are in reverse order (MSB to LSB). Still many question marks and blanks, but there will be fewer in the future. BOF BLOCK --------- 0000 0000 $00 1000 0000 $01 1010 1000 $15 1000 0000 $01 0001 1000 $18 0111 0010 $4D N 0101 1100 $3A : 1000 0010 $41 A 1000 0010 $41 A 1000 0010 $41 A 0100 0010 $42 B 1101 1001 $9B EOL 0010 1000 $14 0000 0000 $00 1110 1000 $17 1110 1000 $17 0001 0000 $08 0000 0001 $80 1011 0100 $2D 0111 0000 $0D 0000 0010 $40 1000 0000 $10 0000 0000 $00 0000 0000 $00 ... 1001 1000 $19 Could be SIO style checksum 0110 1101 $D6 DATA BLOCK ---------- 0000 0000 $00 From $0100 to $0104 (?) 1000 0000 $01 0010 0000 $04 1000 0000 $01 1110 0000 $07 ? 0000 0000 $00 ? 1111 1111 $FF Data 1111 1111 $FF Data 1111 1111 $FF Data 1001 0000 $05 Could be SIO-style checksum 1100 1000 $13 ?? A little bit of ranting on the old Czechoslovak UG documentation, I cannot help myself. Don't take it too seriously. I've been guilty of similar infractions too. If you document a file format, then: 1. If you say that a byte represents a checksum, specify how to calculate that checksum and what bytes are involved. 2. If you say that each block holds 7 control bytes and 1024 data bytes, ensure that not only you enumerate the purpose of the control bytes, but also specify at what offsets these bytes are. It is helpful. 3. If you say that the block size is 256–1024 bytes, why I have a block that is for sure shorter than 256 bytes. 4. If you say that one control byte holds a block sequence number, specify if these begin with 0 or 1 or any other number.

Confirmed. The command wire is not used. I will fix the documentation with next commit.

I do not believe the information about the command signal is correct.

Thank you. I know about the event, one would dare to say it is a classic one. I was going to some local ones (Atariada, ByteFest, Platariada), but not anymore. At least not for the foreseeable future, where my primary mission coming very soon is parenting. Good memories of the past, though. Now, the only Atari related project that I keep running is TURGEN.

I believe I am getting to it. It seems that there are three types of Turbo DNM loaders. 1. Loaders designed to be used with the Czechoslovak Turbo 2000 turbo upgrades - T variant. Polls SKSTAT for pulses. 2. Loaders that take the data from the joystick port. I have discovered the loader at w1k's page. It has code that actually polls PORTA for pulses, so it is the intended Turbo D, which uses the joystick port. 3. Loaders that take the data from god knows where, and which I was using for a while. At the beginning, it polls SKSTAT for an edge, but then the code indicates it is polling SERIN. I suspect this variant works with the Turbo EMO upgrade. When writing data, #1 alternates SKCTL between $0B and $03 to make pulses. When writing data, #2 alternates PORTA between $11 (pin 2 holds zero) and $EE (pin 2 holds 1) to make pulses. Except #3, it now makes sense.

To be honest, the description is not straightforward enough, and it is not because of my rusty Slovak. From the schematic and textual description, I understand that when reading, the amplified and shaped signal goes to the pin 1 of the 2nd joystick port. So, somewhere in the code, I would expect LDA PORTA, AND #$10 to determine if the pin reads 0 or 1 (Joystick UP). Either in mainline code, or in some interrupt handler. For writing, the textual description indicates that pin 2 of the 2nd joystick port is connected to the PCB. So I would expect LDA #$20 STA PORTA sequence to be present somewhere, and the direction control set to output for pin 2.

Some discoveries for the Turbo D sub-adventure. The general modulation is PWM, like many other turbos. Two pulses are distinguished - wide and narrow Data is organized in blocks of varying lengths. The length is stored in each block Pilot tone is a sequence of narrow pulses Bits are encoded using a custom 8 to 9 scheme, where the 9th bit is a filler, which is always 1 Bits in bytes are stored from LSB to MSB Polarity of the pulses matters. Wrong polarity, you load nothing. Pilot tone is used for speed calibration - transfer speed is detected automatically. There is a T variant of the Turbo D loader that reads the signal directly from the SIO DATA IN, without the joystick port. It was designed to work with data recorders upgraded to Czechoslovak Turbo 2000, that were mainstream. This is a great discovery, because all testing can be done using a modified atari800 emulator. Otherwise, the physical and logical format is the same. Turbo D plugin is a good candidate for 48 kHz sampling rate exploitation, because of the transfer speed. Things that puzzle me (for now) The system claims input through joystick port, so why (t. f. h.) the block reading routine probes SKSTAT for zero crossing as its first step. Using debugger and disassembler, I didn't find any relevant PORTA scans inside the loader. That doesn't mean these do not exist, but brings questions. Connection through joystick ports cannot trigger interrupts either. Things to do next Figure out how the checksum is calculated Add code to TURGEN to at least generate WAVE file and try it. Luckily, given the existence of the T variant of the loader, it can be tested with emulator.

Thank you. This will be sufficient. I will be able to disassemble the code in the future. Several years ago, I've disassembled the loader.

In a nutshell, these loaders are more reliable than the original system from Atari. The Turbo 6000 is modelled after the C64 tape system. The small circuit simply completely bypasses the FSK demodulator in the data recorder, amplifies the input signal and makes it square. The signal is then applied to the PIA chip. Every zero crossings of certain polarity (do not remember if 1:0 or 0:1) then triggers an interrupt which is processed by the loader. The extra circuit makes the XC12 behave like the Commodore datasette.

Prospectively, I am looking for code that writes a Turbo 6000 block to tape.

Luckily, I've created an alternate loader and file format that allows loading many more games, even those with INIT segments. Actually, you can see it in action in the video. First, a small file stored in Turbo 6000's natural format is loaded, and then ChainLoader for Turbo 6000 takes control and loads the game. If I manage to steal the write block routine for Turbo 6000, there will be possibility to create Self-Extractors for this system.

Turbo 6000 is a rather rare system. An interesting discussion at Atarionline.pl (use Google translate). The hardware is simple, yet efficient. It lets the PIA chip to do some work, namely triggering the interrupts. The file format is, shall we say, heavily inspired by C64. The software has some limitations - there are restrictions on what kind of binary load files can be stored, multiple data segments are ok, but you can forget files with INIT segments. The system is supported by TURGEN, I've reports from the past that it actually works. The name is of the system is also somehow deceptive, you definitely do not get 6000 bps

P.S. The VisiLoader is somehow elusive, but one can get it from the FLOP magazine website, issue 44, side B, file UTURLOAD.COM. For those who are interested in technical details - the loader uses PMG in non-DMA mode to show "progress bar". I've used the same "trick" for my LBE PMG loader of the Standard plugin. I've released TURGEN 9.2.11. The purpose of the release is to free my hands for Turbo D, so it is a mixed bag of enhancements and fixes, that were stinking my backlog. Mostly what I described in the posts above. One highlight is the ExpressLoading. I've modified the ExpressLoading conversion to be more SFX friendly. From now on, it never creates a turbo block longer than 42 KB, which is within the limits of the SFX capacity. This applies to all plugins supporting ExpressLoading: Turbo 2000, Lower Silesian Turbo 2000, Omicron Turbo.