Turgen System 8.8.x Adventures

[ascrnet]

4 hours ago, baktra said:

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.

 

perfect, thanks for the news 😉

[baktra]

Cooking continues. Now, TURGEN can generate a valid 27-byte header block that holds the file name and the number of blocks as described above. No centering of the file name yet, but that's a cosmetic issue.

The next step is obvious—convert the binary load file. Unfortunately, the file format prescribes a mild XOR-based obfuscation, so it will be more fun than anticipated. Pirated software with its own copy protection 🙂

 

[ascrnet]

18 hours ago, baktra said:

The next step is obvious—convert the binary load file. Unfortunately, the file format prescribes a mild XOR-based obfuscation, so it will be more fun than anticipated. Pirated software with its own copy protection 🙂

 

That's right, the distributor protects itself from being pirated by another distributor or user. 😆

[_The Doctor__]

Copy protection makers often broke protection of others and created their own. This was a job security method as was the practice of some that would let their own protection information leak concerning their old protection methods when they had a new and different method to sell or employ.

[baktra]

On 2/22/2023 at 5:00 PM, _The Doctor__ said:

Copy protection makers often broke protection of others and created their own. This was a job security method as was the practice of some that would let their own protection information leak concerning their old protection methods when they had a new and different method to sell or employ.

Right. I guess it is the same with computer Viruses and Anti-Viruses. And why there are always defects in software … who would pay the sustaining engineers then?

This XORing of the data is fortunately merciful. So merciful that I will keep it in the stage 1 loader and obfuscate the data in TURGEN, rather than doing it the other way. 

[baktra]

The adventure continues. After some silence from me (family matters, visiting India), I am ready to continue the development. What is on the plate for the upcoming release 9.1.4?

 

1. Finishing the NHP Support (top priority, of course)

2. Add turgen.sh convenience script (requested by @seban)

3. Fixes in the gencas.sh convenience script (requested by @seban)

4. Tape Sides creator. Add possibility to randomize order of the project items (requested by @seban)

 

[ascrnet]

1 hour ago, baktra said:

The adventure continues. After some silence from me (family matters, visiting India), I am ready to continue the development. What is on the plate for the upcoming release 9.1.4?

What good news, I was about to think that you were missing some ingredient in the kitchen.  😅

[baktra]

It was the cook who was missing. Good news is that I've finally figured out the mild obfuscation:

 

Decoding (from the loader source code):

Initialize 'magic byte' from the EOF block of the stage 0 loader (MAGIC). The magic byte is at offset X'67' of the EOF block and is different for each file.

 

For each user data byte in the SIO buffer, do the following:

1. Get next user byte from SIO buffer (BYTE)
2. Get index of the byte in the SIO buffer (INDEX)
3. Calculate TEMP = XOR(BYTE, INDEX)
4. Calculate DECODED_BYTE = XOR(TEMP, MAGIC)
5. Increment MAGIC by 1

 

Encoding (I need to implement this in Java)

Initialize 'magic byte' from the EOF block of the stage 0 loader (MAGIC)

 

For each byte:

1. Take a byte to be encoded (BYTE)
2. Take index of the byte in the SIO block (INDEX)
3. Calculate TEMP = XOR (BYTE, MAGIC)
4. Calculate ENCODED_BYTE = XOR (TEMP, INDEX)
5. Increment MAGIC by 1

 

[baktra]

Have a first NHP tape image created by TURGEN

ardys.cas

[ascrnet]

7 hours ago, baktra said:

It was the cook who was missing. Good news is that I've finally figured out the mild obfuscation

a break is not bad for recovering energy and thanks for the detail 😉

6 hours ago, baktra said:

Have a first NHP tape image created by TURGEN

 

wow😱, great progress. the title of the game still needs to be centered. we're doing great. 😁

[baktra]

9 hours ago, ascrnet said:

a break is not bad for recovering energy and thanks for the detail 😉

wow😱, great progress. the title of the game still needs to be centered. we're doing great. 😁

Yes, there are many small touches to finish.  Mostly because the new "Standard Plus" plugin is a specialty (as it is basically a plugin of sub-plugins).

I have also an additional conundrum. TURGEN is still targeting JDK 8, which is still maintained, but out of date.

What to do with that? Cast your votes

 

 

 

[ascrnet]

9 hours ago, baktra said:

What to do with that? Cast your votes

no problem, about your dilemma it is always good to improve. i recently made a project for Windows but openjdk 1.9,10,11,12 doesn't work very well for me since i was using javafx. so i went back to using jdk 1.8 but updated and never again problem with java virtual machine (JRE) in Windows. 😎

[baktra]

More updates for the NHP 3.6 in the latest commit

• Project items of the Standard Plus plugin can be saved and loaded
• Silence list is working
• Baud rate selection works
• The program title is centered

Almost there. Some testing, polishing of the code, and documentation updates are to go.

[baktra]

Release 9.1.4 is out.

 

Blog post: https://sourceforge.net/p/turgen/blog/2023/04/turgen-914---santiago-de-chile/

Downloads: https://sourceforge.net/projects/turgen/files/turgen/turgen_9.1.4/

 

Please be advised that the NHP 3.6 Rainbow system doesn't appear in the Wizard for files. This function will be added later.

 

[baktra]

What will be next?

• The Standard Plus plugin needs a configuration mechanism that allows its conversion types to be either included or excluded in the Wizard for files. The Omicron Turbo plugin has something similar.
• Steal more loaders for the Standard Plus plugin, perhaps SITRE. But what if @vitoco sues me for copyright infringement?
• Read this thread again and find all forgotten enhancement proposals and choose those I am willing to work on.
• Keep an eye on the JDK version poll above and make the right decision

 

[ascrnet]

I hope that in the next version it will have its flag like the others, because as it is, it is half hidden from view. 😅

I have more Chilean copiers in the folder, but I didn't want to stress you with even more. 🤭
In the list I have NHP INJEKTOR 6.0 a copier similar to NHP Rainbow but supports more baud 3900 as I recall.
Then other Turbo soft for example. All these we have the sources in mads or in mac/65 there is still a lot.

 

These copiers were the most massive in Chile.😉

 

[baktra]

2 hours ago, ascrnet said:

I hope that in the next version it will have its flag like the others, because as it is, it is half hidden from view. 😅

I have more Chilean copiers in the folder, but I didn't want to stress you with even more. 🤭
In the list I have NHP INJEKTOR 6.0 a copier similar to NHP Rainbow but supports more baud 3900 as I recall.
Then other Turbo soft for example. All these we have the sources in mads or in mac/65 there is still a lot.

 

These copiers were the most massive in Chile.😉

 

Haha.

 

The Standard Plus might eventually include loading systems from other countries, hence the 'international flag' for now. However, the conversion types combo box can have country-specific flags. So the Chilean flag will make it to TURGEN.

 

I am also thinking of changing the default order of the plugins, because when I think about it, the current order is not logical but 'patriotic' and still favors Czechoslovakia over others. There The Standard and Tape image plugins should go first.

 

Or perhaps I can make a small UI that allows customizing the order and presence of the plugins. Something to think about.

[vitoco]

I arrived late to this thread. It is an interesting project.

 

6 hours ago, baktra said:

Steal more loaders for the Standard Plus plugin, perhaps SITRE. But what if @vitoco sues me for copyright infringement?

You can use TURGEN to create SITRE tapes if the only modifications to the loader are the game name (centered, within the $00-$2F range (ASCII-32)) and the block count, which I guess they are inside the obfuscated blocks.

Notes:

• Data size in the blocks is part of each block as well as its block number, and they are not obfuscated.
• Each data block has 261:
  • 2 sync bytes: $55, $55
  • 1 byte with block number. Blocks are numbered in decreasing order, and the last one is 0. Only the LSB byte is present in the block.
  • 1 byte for the data lenght minus one. $FF means 256 bytes in the block.
  • 256 bytes of data.
  • 1 checksum byte, required by the OS.
• Silence gaps are automatically inserted before the next block after an INIT segment and the duration depends on the number of INITs found in the previous block, but I don't remember how long is each pause.
• After all data blocks there is a standard CLOSE block, which is not used by SITRE.

About XEX compatibility:

• SITRE loader runs in page 7 and 8 (with some data at page 6 that can be wipped out by the XEX being loaded), and the data buffer is in page 8-9.
• SITRE uses tape routines from unmodified OS ROM, which means that an XEX that load parts of it in RAM between $C000 and $FFFF should run OK.

More info in my SITRE's description page (in Spanish).

 

6 hours ago, baktra said:

What will be next?

•  Move NHP and other Standard Plus loaders to their own plugin, or you will find yourself adding lots of option blocks.
• International support in the frontend: languages other than English. 😬

++Vitoco

 

[ascrnet]

5 hours ago, baktra said:

Haha.

 

The Standard Plus might eventually include loading systems from other countries, hence the 'international flag' for now. However, the conversion types combo box can have country-specific flags. So the Chilean flag will make it to TURGEN.

 

I am also thinking of changing the default order of the plugins, because when I think about it, the current order is not logical but 'patriotic' and still favors Czechoslovakia over others. There The Standard and Tape image plugins should go first.

 

Or perhaps I can make a small UI that allows customizing the order and presence of the plugins. Something to think about.

Now I understand you, I think it would be good to group them by country, since in Chile there are many of them and it is a good idea to be able to define the order from the configurations. 😄

[baktra]

6 hours ago, ascrnet said:

Now I understand you, I think it would be good to group them by country, since in Chile there are many of them and it is a good idea to be able to define the order from the configurations. 😄

Another possibility is to allow multiple flags for a plugin.

[baktra]

I have a green light from @vitoco to implement support for SITRE, provided that I will not modify the loader.

 

So, the immediate plans are the following:

• Finish refactoring of the way the transfer speed is specified in the GUI and CLI. Up to the present time, you were specifying “pulses” (an id string) to identify the transfer speed. After the refactoring, you will be specifying a "transfer speed", which is an integer. It will be up to the plugins to convert the transfer speed to PWM pulses or do anything else with the value. The point of this refactoring is that the implementation of what is the "transfer speed" is a private matter of the plugin. Of course, most of the plugins will be using the repository of the pulses as before. This also involves a documentation update and many updates to the screenshots. There will be also an incompatible change in the GENCAS syntax.
• Fix bugs in the NHP 3.6 (Rainbow) support. So far, there is only one known, the transfer speed is displayed as 0 in the Project. It is a cosmetic issue.
• Allow to use the NHP 3.6 (Rainbow) system from the Wizard for Files.
• Implement support for the SITRE system.

Further thoughts

• Since the Standard Plus will support up to 3-4 systems (NHP, STAC, SITRE), I will have them under one umbrella of the Standard Plus plugin. Project items and sub-items seems to be working. If there will be a need to have multiple flags for one plugin, I will implement them.
• I will consider localization. It would be a good opportunity for me to learn about Java Resource Bundles, which are used for i18n. However, making the strings translatable is brutal work. Only slightly less brutal than the translations. To cover the most of the user base, it would have to be Czech, Polish, English and Spanish.

[baktra]

The work on the SITRE system is going well. TURGEN just performed its first conversion, including setting the number of the blocks and program title in the obfuscated stage 1 loader.

[ascrnet]

On 4/26/2023 at 8:55 AM, baktra said:

I have a green light from @vitoco to implement support for SITRE, provided that I will not modify the loader.

 

So, the immediate plans are the following:

• Finish refactoring of the way the transfer speed is specified in the GUI and CLI. Up to the present time, you were specifying “pulses” (an id string) to identify the transfer speed. After the refactoring, you will be specifying a "transfer speed", which is an integer. It will be up to the plugins to convert the transfer speed to PWM pulses or do anything else with the value. The point of this refactoring is that the implementation of what is the "transfer speed" is a private matter of the plugin. Of course, most of the plugins will be using the repository of the pulses as before. This also involves a documentation update and many updates to the screenshots. There will be also an incompatible change in the GENCAS syntax.
• Fix bugs in the NHP 3.6 (Rainbow) support. So far, there is only one known, the transfer speed is displayed as 0 in the Project. It is a cosmetic issue.
• Allow to use the NHP 3.6 (Rainbow) system from the Wizard for Files.
• Implement support for the SITRE system.

Further thoughts

• Since the Standard Plus will support up to 3-4 systems (NHP, STAC, SITRE), I will have them under one umbrella of the Standard Plus plugin. Project items and sub-items seems to be working. If there will be a need to have multiple flags for one plugin, I will implement them.
• I will consider localization. It would be a good opportunity for me to learn about Java Resource Bundles, which are used for i18n. However, making the strings translatable is brutal work. Only slightly less brutal than the translations. To cover the most of the user base, it would have to be Czech, Polish, English and Spanish.

as far as I can see he still has a lot of work to do, so I will slowly prepare the other NHP that I am interested in that is in TURGEN. 😅

[baktra]

On 4/22/2023 at 9:39 PM, ascrnet said:

no problem, about your dilemma it is always good to improve. i recently made a project for Windows but openjdk 1.9,10,11,12 doesn't work very well for me since i was using javafx. so i went back to using jdk 1.8 but updated and never again problem with java virtual machine (JRE) in Windows. 😎

How was your personal experience with JavaFX? Is it much better than Swing or SWT?

[baktra]

On 4/27/2023 at 3:11 PM, ascrnet said:

as far as I can see he still has a lot of work to do, so I will slowly prepare the other NHP that I am interested in that is in TURGEN. 😅

The refactoring is done, bugs and missing support for NHP 3.6 Rainbow in the Wizard is also there. SITRE is almost complete.

 

When I am done with SITRE  I will take a deep breath and see what else I can 'export to Chile'.  I have also two todo 'export articles' for Poland: Turbo 2600 and Turbo Rapider.

 

As for the i18n. It is 17 years behind the development. The only viable way of doing that seems to be an iterative approach. With each version, make one or two dialogs translatable and provide the English translation. Other translations will be up to the volunteers: "Here is your .properties file and make yourself useful". I did not make my mind about i18n yet. Still trying to weight its business value.