Turgen System 8.8.x Adventures

[baktra]

Playing with a NetBeans Profiler (profiler is a tool that tells you where your program spends CPU and other computational resources) can be enlightening and bring surprising answers...

 

Why starting TURGEN takes so much time?

A simple answer would be... because the starting the Java Virtual Machine is slow. Perhaps. But the profiler shows something different.

It is because 4 File chooser dialogs are instantiated and initialized at the beginning. Those file chooser dialogs belong to the dialog that you use for editing playlist items. Googling about this reveals that instantiation of File choosers is simply known to be costly.

 

Why starting the Wizard for files feels slow for the first time?

Same reason, 3 File chooser dialogs are instantiated. 

 

What else needlessly eats CPU?

It is the timer which is used to update progress bars when the signal is generated. It is fired up every second, even though there is nothing in progress. At the time it was the simplest solution.

 

What can we do about it?

The File choosers will be initialized lazily (first time when they are really needed - that is when you click the "Browse" buttons). This will reduce start-up time.

The timer will be replaced with a thread, which will be running only when there is something in progress. This will be done using the notify() and wait() functions.

 

 

 

[baktra]

Well, it turned out that there are actually more file choosers (JFileChooser) instantiated during startup. Seven in total.

 

1. Playlist item input (for most plugins)

2. Playlist item output (for most plugins)

3. Playlist item alternate input (for the tape image plugin, based on the idea that you keep tape images elsewhere than binary files)

4. Playlist item alternate output (for the tape image plugin, ditto)

5. Playlist load/save (owned by main window)

6. Unused file chooser originally intended for batch processing (busted!)

7. The Turbo 2000 plugin - file chooser for loading of the turbo header from an external file (a well hidden gem almost nobody uses)

 

In the latest commit, these are all lazily initialized (and #6 removed). This reduces startup time by 2-3 seconds and that must count for something. 

There are other file choosers, but these are in "transient" dialogs that are instantiated as needed, so the startup time is not affected by them.

 

Also the progress timer ticking all the time is gone and replaced by a thread which is kept in non-runnable state unless there is some progress to be shown.

The progress is updated twice per second when there is something to show.

 

Speaking of progress bars... As they are, they do not seem to be that useful when creating wave files and tape images. In most cases, if you just blink, you completely miss them, because the work is done very quickly.

This doesn't mean they should be removed, but perhaps information on items already completed should remain on screen. Like the queues of files showed by many graphical FTP clients.

It has also to do with usability (UX). When you create a wave file, the only indication that it has been successfully done is a subtle indication in the status bar. Too subtle and easy to miss.

 

Edited October 29, 2021 by baktra

[baktra]

The file chooser dialogs of the Wizard for files are the next target. There is three of them and they will be initialized lazily too. This way, the Wizard will start faster. It is a desirable change as the Wizard is used often.

 

The winner of the what's next feature is a loading system for Turbo 2000 and Omicron turbo based on the ideas of Speedy2700 and Unerring Master loading systems. So coding in 6502 assembler it will be one more time. With at least two emulators supporting loading turbo tapes, debugging will be a piece of cake.

 

But before that begins, I will deal with the Wizard and also with the Batch processing dialog. The batch processing dialog is a rather unusual (and often confusing) design with its embedded file chooser. I am going to implement a more conventional style - a label, a text field and a browse button to choose the batch file. The most recent file (or files) will be remembered for convenience.

[baktra]

Development was going well. The JFileChoosers have been dealt with and changes pushed. 

 

Before I proceed to the progress bars, I will take a detour to the Final Assault game. 

[baktra]

My detour to the Final Assault game was shorter than expected. I don't like the game that much as expected.

In the meantime, TURGEN 8.8.7 has been released. You have all the speed-ups mentioned above and a small bonus - layout of many dialogs was refined to be more consistent and streamlined. So yes, TURGEN visited a cosmetic studio this time.

[baktra]

I've started implementation of the "Express Loader" for Turbo 2000 (a loading system inspired by Unerring Master and RAMBIT).

 

I will begin with something crude, but functional, then I will try to optimize the code little bit.

 

The work is tricky, one missing PLA and things go south. Next step is to update the Turbo 2000 plugin to generate the file in the "Express" format and keep coding and testing until everything works reliably.

 

Top speed will be 2270 bps, more than enough for publishing games.

[baktra]

I am making progress with the Express Loader for Turbo 2000. It is already capable of loading complex binaries. For example the Ridiculous Reality (RR) game loads perfectly.

Now I am going to fine tune timing constants in the loader, ensure that error detection works as intended, and the loader is properly supported by TURGEN.

 

If one compares ChainLoading vs ExpressLoading of RR:

ChainLoading 17:32

ExpressLoading: 06:32

Kilobyte Blocks: 06:37

 

The code is inspired by the Speedy2700 loader (concept) and the original Turbo 2000 loading routine (decoding routines), of course. I've made two deliberate changes:

1. The checksum is for every segment (Speedy2700 for group of segments). This somehow improves error detection, but wastes one byte per segment.

2. No self-modifying code

 

 

 

[baktra]

So, for possible early adopters, the code was merged to the master branch. You can download turgen.jar to your TURGEN directory and give it a try.

ExpressLoading can be selected from the playlist item dialog and also from the Wizard for files.

 

The updated source code of the loader has been pushed to its respective location. I made it much smaller by efficient coding of the loader states and transitions between them. God bless the indexed addressing modes :-).

 

I've also fixed an annoying bug - TURGEN had a tendency to forget directories of the most important file choosers (and offer the 'Documents' directory instead). An error in the implementation of the lazy initialization.

 

I will keep playing with the timings in the loader (the loader has to compensate for cycles that were consumed by actions performed between reading bytes). I will be making observations using Altirra debugger and possibly refine the values. But the values present seem to work just fine.

 

If I don't find any problems, there will be TURGEN 8.8.8 soon. What a nice number for a version.

 

 

[baktra]

The 8.8.8 "First Express" is out together with the ExpressLoading conversion.

I'll keep the ExpressLoading conversion in a non-prominent position until it is proven "in the field". If it is, both ChainLoading and BlockLoading will lose their prominent positions in the Turbo 2000 plugin, but they will be allowed continued existence.

[baktra]

As the ExpressLoading for Turbo 2000 is out, I've started work on support for the Omicron Turbo. It is going surprisingly well.

The funny part seems to be the color scheme, because when the signal goes from the joystick port, the loading bars do not have as good looking colors as they probably should.

 

The problem is simple. 

When the signal comes from the SIO port, we get the following bit on (SKSTAT):

...1 ....

So, we get $10 or $00 . Then the bit is shifted to the right, so we get $08 or zero. Therefore we get black and light gray loading bars. That's how the Czechoslovak Turbo 2000 code has always worked with loading bars. And Omicron is based on that code.

 

When the signal comes from the joystick port, we get the following bit on:

1... ....

We get $80 or 0. Then the bit is shifted to the right, so we get $40 or zero. Therefore we get black and very dark purple loading bars. You see such bars when one of the stage 1 Omicron loaders is being loaded by the stage 0 loader.

 

The new coloring scheme for Omicron's Express Loader is as follows:

1. Take the value ($10 or $80)

2. Shift to the right ($08 or $40)

3. Bitwise or with $12, so we will get $12 for SIO and $52 for joystick port as the color for incoming logical 1. This results in dark orange/black and dark purple/black color schemes. The $52 purple is brighter than $64 purple, so the color scheme is more acceptable.

 

The challenge here is to come up with acceptable color scheme and keep the number of cycles that are consumed to "calculate" the color.

[baktra]

The ExpressLoading for the Omicron Turbo is available (at least in the git repository).

It is funny to see how many mistakes I made in the previous post about colors.

 

To keep it simple:

For input from the SIO port, we get either $10 or $00. Then we shift it right, so we get $08 or $00. This makes black and medium gray bars.

For input from the joystick port, we get either $80 or $00. Then we shift it right, so we get $40 or $00. This is black and very dark purple (on PAL machines).

 

Both combinations are little bit bland and ugly.

Therefore, for SIO port, I or the value with $10, which means we get very dark orange/brown and medium orange/brown which looks good.

For joystick port, I or the value with $24. This shifts the colors and increases luminance. The final result is blue and purple. This is not perfect, but looks good enough.

 

I will propagate this color scheme to other Omicron Turbo loaders. And now it is all correct.

 

Perhaps one day, someone will release a game on tape, side A in standard tape records, side B in Omicron Turbo. Given the licensing issues, it would have to be one of the modern homebrews.

 

 

[baktra]

Now you can fully enjoy Omicron Turbo with new color schemes and ExpressLoading. TURGEN 8.8.9 is out.

I really should slow down the release cadency and neglect the project for a few months ?

 

Whoever can do that, please try the new functions and report problems.

[baktra]

I've tested the ExpressLoading of Omicron turbo with few games and my real hardware. Works just fine, which is the pleasant surprise. With Turbo 2000, the ExpressLoading works either. Using a cassette adapter is a different story (I bought a branded one - PHILIPS). Playing the game 'find the right volume' is not that funny.

 

Or it is just the fact that my remaining recorders - one XC12 and XL12 just need proper and deep servicing, something I am not capable of doing yet. Damn those half broken wires, aged capacitors and worn-out belts. 

 

[manterola]

I have a question regarding the different "turbo" modes available in Turgen. Is there any one that does NOT require a modified Cassette player (program recorder)? Like Stac or Sitre from South America.

 

 

[baktra]

13 hours ago, manterola said:

I have a question regarding the different "turbo" modes available in Turgen. Is there any one that does NOT require a modified Cassette player (program recorder)? Like Stac or Sitre from South America.

 

 

Not yet. I am still planning to add my own and open-source loading system similar to STAC/SITRE/PRISMA/Turbo 2600. I am saying similar, as those I mentioned have certain unpleasant limitations. I am aiming for the following:

 

1. 256 to 384 byte blocks

2. Increased baud rate

3. Loader not located in RAM under ROM

4. Support for binary load files that have INIT segments

5. Optional progress indicator

6. Preferably having circumvention of the faulty baud rate  detection ROM routine

 

I would need to combine the best of the four systems above.

 

[manterola]

Another question, I build (in a protoboard aka breadboard, for now) a Turbo6k interface.

I made it work, by using turgen to create a wav that I recoded in a real cassette. Both Turgen and then the high speed I got are fantastic!

However, i am using the original Chaos Loader included in the TurbUtil.atr that also needed to put at the beginning of the cassette ((C)opy D:chaoslad.cad,C:) chaoslad.cas in not really a modern .CAS file.

Anyway, I have been trying a more convenient way of loading the chaos loader. And I found an xex in your github directory:

turgen_tape_loaders/ge_turbo6000_chainloader/t6k_chainloader.xex

i put that xex it in the AVGCart and it runs, it activates the motor but it does not load anything. I remember you mentioned you developed a better load for Turbo 6000 and I guess is the one I tried.... or am I missing something? How I should use that XEX? or other?

 

[baktra]

You cannot use the t6k_chainloader.xex directly from cartridge. All can be clarified by explaining the "Input file type" selection in Turgen.

 

If you select "Compatible binary file", then your input file is converted to the natural file format of the Turbo 6000 and can be loaded with the "Chaos Loader"

If you select "Binary file", then firstly, the t6k_chainloader.xex is converted to the natural file format loadable by the "Chaos Loader". Then your file is converted  to a special file format understandable only by the t6k_chainloader.

 

If you place t6k_chainloader.xex to the cartridge and try to load, then it will fail, because it will encounter the natural file format first, which it doesn't understand, so the computer will freeze. But at least the screen should blink green and/or brown for a few moments to indicate some data was processed.

 

So, the easiest way seems to be placing the original chaosloader to the universal cartridge. The chaosloader on that disk image is probably nothing else than a cassette boot file. It should be easy to take that boot file and modify it to be a .xex file. 

 

I am attaching an experimental chaosloader.xex from other source, you can try it with your universal cartridge.

 

 

chaosloader.xex

[baktra]

As the Turbo 6000 was discussed in the previous posts, let me share some information on it.

 

If you didn't know before, the natural file format used by the Turbo 6000 system  is exactly the same as the file format of the popular "TurboTape" for Commodore C64. What a coincidence.

 

The signal from the Turbo 6000 is applied to the PROCEED pin of the SIO port. This pin is connected to the PIA circuit. The loader sets the PIA circuit to trigger an interrupt whenever there is a LO->HI edge on the PROCEED pin. This also means that the polarity of the pulses matters, because PIA can be set to trigger an interrupt on either edge, but not both. This is controlled by the bit 1 of PACTL. If the polarity of the pulses is accidentally reversed, you will not load anything. The interrupts will be triggered in the middle of the pulses, not at their beginnings.

 

 

[baktra]

I've also pushed the fixed chaosloader.asm to the git repository, including the .xex file.

 

[manterola]

The chaos loader you uploaded did not work. No colors, no MtrCtrl On, nothing.

I manage to transform the cassette boot file (original one, form the original package) to XEX, but still does not work (it crashes after a few seconds)

Another news: Soon I'll be giving away some Turbo 6000 PCBs I designed. This circuit is based on the original design but adapted to "modern" LM339 comparator. 

And I would like people to test them with XC11 , Atari 1010, etc. But it should take 2 or 3 weeks for the PCBs to arrive.

 

[baktra]

9 hours ago, manterola said:

The chaos loader you uploaded did not work. No colors, no MtrCtrl On, nothing.

I manage to transform the cassette boot file (original one, form the original package) to XEX, but still does not work (it crashes after a few seconds)

Another news: Soon I'll be giving away some Turbo 6000 PCBs I designed. This circuit is based on the original design but adapted to "modern" LM339 comparator. 

And I would like people to test them with XC11 , Atari 1010, etc. But it should take 2 or 3 weeks for the PCBs to arrive.

 

I am sorry to hear that. I tested only with Altirra where the loader worked. How do you run the .xex on real hardware? From universal cartridge?

[manterola]

Yes, I used AVGCart.I have not tried from Diskette Menu or DOS (L)oad. I am also trying to build the cart with EPROM and switch, since I could not make the ROM (.car) to work in AVGCart, after trying many different cartridge types.

I check the notes in the cart construction, and I found that it mostly resembles a Phoenix type of cart. Anyway, I will post more updates, but let me say again that Turgen is fantastic.

I also have 3 PCB with the original Turbo6000 design to give away. Probably to people located in Europe, since they should have it easier to get those two old ICs from Germany.

 Are you interested @baktra?

Edit: I have sent small PCBs before as a regular letter in a regular envelop with a stamp

Edit2: Please PM me, and DO NOT reply here since I have already hijacked this thread enough.

 

Edited February 4, 2022 by manterola

[baktra]

26 minutes ago, manterola said:

Yes, I used AVGCart.I have not tried from Diskette Menu or DOS (L)oad. I am also trying to build the cart with EPROM and switch, since I could not make the ROM (.car) to work in AVGCart, after trying many different cartridge types.

I check the notes in the cart construction, and I found that it mostly resembles a Phoenix type of cart. Anyway, I will post more updates, but let me say again that Turgen is fantastic.

I also have 3 PCB with the original Turbo6000 design to give away. Probably to people located in Europe, since they should have it easier to get those two old ICs from Germany.

 Are you interested @baktra?

Edit: I have sent small PCBs before as a regular letter in a regular envelop with a stamp

Edit2: Please PM me, and DO NOT reply here since I have already hijacked this thread enough.

 

I will reply here as your post definitely does belong here. To your offer, I have to say: "No, thank you". I am keeping my Atari hardware at minimum levels.

I have one cartridge image with CHAOSLOADER for this Turbo 6000, perhaps it is the same as you have. In Altirra, it works as a 'Blizzard Cart'. The .xex I've attached before is a re-assembly of a cracked version.

 

You can also try software from this package: https://atarionline.pl/forum/?PostBackAction=Download&AttachmentID=9088. This is Turbo STAR, another clone of Turbo 6000.

caos_1_16k.rom

[manterola]

On 2/4/2022 at 2:02 PM, baktra said:

caos_1_16k.rom 16 kB · 3 downloads

This one made magic happen!

 

[baktra]

Back to the topic of showing what items are being or have been already processed.

 

Currently, when you generate a wave file or a tape image, it happens very quickly, so you can barely see the progress bars. And then you are left wondering if the wave file was created or not, unless you are watching the status bar.

 

The new implementation of the progress panel will keep all items in the list, until they are manually deleted.

 

This is how the prototype looks like. Promising, but still a long way to go.

 

I will have to resolve a few concerns.

 

Does it make sense to have individual STOP/RESUME buttons for each item?

It seems not, WAVE and CAS files are generated very quickly, so one cannot possibly click the buttons anyway.

For audio output, there can be only one at a time, so one STOP/RESUME button would be sufficient too.

Does it make sense to have STOP and STOP ALL buttons for audio output?

Also probably not, I've never seen a reason to use STOP, always STOP ALL.

 

So it is very likely that the progress panel will have just a simple common set of buttons as follows:

STOP|RESUME|CLEAR