TurboSound Control Interface

This section is for discussing everything about Next hardware and latest updates.
User avatar
Black_Cat
Posts: 70
Joined: Fri Aug 25, 2017 2:11 pm
Location: Saint Petersburg, Russia Today
Contact:

TurboSound Control Interface

Post by Black_Cat » Thu Jun 20, 2019 3:40 am

Dear ZX Spectrum Next developers! I notify You of an unacceptable violation Of the terms of the license use of the TurboSound Control Interface, the essence of which is Your violation of the prohibition to freely make changes to the control interface TurboSound or violate its integrity. If You wish to make specific changes used in the ZX Spectrum Next, then this should be done in the framework of the opportunities provided for these purposes in the management interface TurboSound, and which are described in the document "BC Info Guide #3 TurboSound Control Interface" https://zx.clan.su/forum/8-35-1#188 . For Your convenience, I offer a translation of the license agreement from the Russian language:

"1.0 Copyrights and licenses to use the TurboSound Control Interface.

The specification of the TurboSound Control Interface (TurboSound CI) was developed in 2005 by the ZX Spectrum community of the USSR ((C) USSR ZX Spectrum Community), and was first implemented by the NedoPC group in the TurboSound (TS) device.
The authorship of the TurboSound Control Interface belongs to the community ZX Spectrum USSR. The authorship of devices using the TurboSound Control Interface belongs to their developers. The use of the TurboSound Control Interface is possible under the creative Commons Plus Attribution-NoDerivs (CC+ BY-ND) license, which allows free use, subject to attribution, but prohibits free modification or violation of the integrity of the control interface. The ability to make changes to the TurboSound Control Interface is governed by a special protocol CCPlus (CC+), supplementing the Creative Commons license by the copyright holder. The license of the copyright holder, which is ZX Spectrum community of the USSR, regulates the possibility of making changes to the TurboSound Control Interface. Consideration of such a possibility provides for the public defence of the project of the changes the party offering these changes. At the same time, changes to the TurboSound Control Interface are possible only in case of a positive result of protecting the draft changes achieved as a result of the public presentation of the proposed changes to the ZX Spectrum community of the USSR, and public opposition to these changes. These changes are required to remain compatible with all previous changes to the TurboSound Control Interface."

I ask You to eliminate the violations of the license to use the TurboSound Control Interface in the computer ZX Spectrum Next. This requirement is carried out in accordance with the protocol CCPlus (CC ), which gives me the right as an opponent to defend the interests of the USSR ZX Spectrum Community. To eliminate the violations of the license You should make the following changes:

1) To refuse the use of AD6, AD5, AD1 address bits for direct address management, and to transfer the necessary management functions to one of the internal control registers in the range of internal addresses $20-$BF of the TurboSound Control Interface.

2) You must add two additional internal registers to the TurboSound Control Interface of the ZX Spectrum Next computer - the function register and the device selection register. A description of these registers is given in the document "BC Info Guide #3 TurboSound Control Interface" https://zx.clan.su/forum/8-35-1#188 .

3) Add the ability to block access to the #BFFD, #FFFD ports of the ZX Spectrum Next computer using the edge connector IORQGE signal.

4) Specify the type of Creative Commons Plus Attribution-NoDerivs (CC+ BY-ND) license used and the copyright holder (c) USSR ZX Spectrum Community in the documentation of the ZX Spectrum Next computer for the TurboSound Control Interface. The use of the name "TURBO SOUND NEXT" in the documentation is an unacceptable infringement of rights and intellectual property. The only valid interface name is "TurboSound".

P.S. If necessary, I can provide You with consulting services to eliminate your violations of the license to use the TurboSound Control Interface. I hope for Your cooperation in correcting the violations of the license.

seedy1812
Posts: 67
Joined: Tue May 30, 2017 11:31 am

Re: TurboSound Control Interface

Post by seedy1812 » Thu Jun 20, 2019 9:29 am

I am be missing the point but Nedo version of the TurboSound is not the original one. On the webpage (https://www.specnext.com/turbo-sound-next/) it states
The internal Turbo Sound Next interface is an evolution of the original Turbo Sound
Doing a bit of research I came across http://speccy.info/Turbo_Sound which shows the Nedo version dated 2005 but in 1995 there is the "Power of Sound" version which resembles the one in the Next ( a control register to select which audio chip you want to use and then the audio registers).

Cthutu
Posts: 8
Joined: Tue Jun 13, 2017 12:30 pm

Re: TurboSound Control Interface

Post by Cthutu » Thu Jun 20, 2019 10:55 am

You can't copyright interfaces. If you could, you wouldn't be seeing Android on any phones. Of course the irony of the fact that people in the USSR ripped off Sinclair by making illegal clones is not lost on me.

User avatar
TheSMoG
Posts: 31
Joined: Mon May 29, 2017 5:07 pm

Re: TurboSound Control Interface

Post by TheSMoG » Thu Jun 20, 2019 11:50 am

Apart from the apparent irony of a Russian claim to copyright (not to mention the fact the USSR doesn't exist) and the fact that you're asserting copyright upon an extension of prior art (which is totally invalid to begin with but I digress) and -obviously- the fact that putting a bunch of AYs together is nothing novel and has been done since the 80s, not to mention that "Turbosound" as a word has been used by numerous vendors over the years, I will assume you are only interested in assuring that Russian music software can run on the ZX Spectrum Next but you're going about it the absolutely wrong way.
First you have the option of changing the core yourself. It's open source and available already to clone.
Secondary you can contact the Next hardware volunteers' team and ask for changes. They're open enough to discuss any and every option of improving something.
Phoebus R. Dokos
ZX Spectrum Next Manual author/editor
TBBlue Distribution Maintainer Latest images & TBBlue git repo on gitlab.com
WASP/ZXnextHUB Member
All Sinclairs All The Time :D :lol:

PiyoTaro
Posts: 181
Joined: Thu Jun 01, 2017 11:13 am

Re: TurboSound Control Interface

Post by PiyoTaro » Thu Jun 20, 2019 7:28 pm

  • Black_Cat wrote:
    Thu Jun 20, 2019 3:40 am
    The circuit released by VELESOFT as "Turbo Sound" seems to be a product attached to the sound chip of ZXSpectrum, and it seems that the address decoder circuit of the ZXSpectrum version is not included. The complete schematic at the bottom of the homepage does not seem to be for Sinclair.
    https://velesoft.speccy.cz/turbosound-cz.htm

    It may still be possible to add an explanation on the Next official site, such as "Why turbo" or the existence of the original product.
---
  • About TS Next
    (We have not been able to discuss the implemented AudioInterface and the structure of the AY core)


    By the way, at the end of May 2019 , the official wiki was updated. The "A note on partial decoding" article has been added to the "BOARD FEATURE CONTROL" item.
    https://specnext.dev/wiki/Board_feature_control
    After looking at this sentence and looking at the I/O map, "Turbo Sound Next" appeared to be decoded only with A1 and A14 A15.

    This is the same as how older ZXSpectrum users attach the soundchip via the CPU socket as a logic IC "LS138" as an address decoder.

    I found in the description of the sound card sold on eBay that "it is improving the decoding circuit considering the conflict with peripherals".

    If you want foreigners to talk about 21st century hardware, I wanted you to go as far as the "full decode of IO port" implementation.
---
  • About thread "Musical potential of the NEXT."

    After receiving a reply to me saying "If you want an FM sound , even bring TurboSound",
    what I did was not to "report" to the kickstarter's comment box, but in the forum I did a wasteful thing to set up a thread of TurboSound.

    I did something useless. And although 'I' was asking for the implementation of the FM core in this forum, the position changed to the person who is trying to sell the soundcard which does not operate in turbomode.

    Also, although it has already been deleted, Mr. SMoG is also strange as an official comment on the explanation of "IP infringement".
    KORG, a manufacturer of musical instruments, has released a number of synthesizers as "FM system", but there is no story that it has been disputed with YAMAHA.

Alcoholics Anonymous
Posts: 511
Joined: Mon May 29, 2017 7:00 pm

Re: TurboSound Control Interface

Post by Alcoholics Anonymous » Fri Jun 21, 2019 2:29 am

Black_Cat wrote:
Thu Jun 20, 2019 3:40 am
Dear ZX Spectrum Next developers! I notify You of an unacceptable violation Of the terms of the license use of the TurboSound Control Interface, the essence of which is Your violation of the prohibition to freely make changes to the control interface TurboSound or violate its integrity.
TurboSound existed long before you published this document. It seems like you may not be using the correct name for this as it looks more like "TurboSound FM".

(It's a little confusing to see "USSR" mentioned when it dissolved long ago; maybe it's a translation thing and "former USSR" is meant, although you have to be a certain age these days to even know what that means).

I do think it's a good idea to remain compatible when possible however. Unfortunately the Next has been out for 2 years now with 440 boards being distributed. Software, both commercial and free, has already been published using the current specs. This is why all updates to the Next have to be backward compatible. So we can't make those sorts of changes to port FFFD any longer. However, it does remain a TurboSound-type interface, as claimed.
1) To refuse the use of AD6, AD5, AD1 address bits for direct address management, and to transfer the necessary management functions to one of the internal control registers in the range of internal addresses $20-$BF of the TurboSound Control Interface.
There is a way to retain compatibility. In your document, it's a mistake to leave don't care bits in ports and data.

Under 2.1 you're defining a control method like this:

11XX ???? where "X" are don't cares.

Under 2.3 you're defining another control method like this:

1111 XX1X

I understand why you left bits as "don't cares" - most likely you were copying this directly from a real hardware implementation that didn't decode all the bits. But if you change all these "don't cares" to 0 then there is no compatibility problem. You can leave a note that hardware adhering to such and such version of the spec may only decode the bits you have indicated but software should use 0 in the X positions.

You're probably saying you can't change that anymore as software has been written and 50 such devices are already sold. It's the same problem here as there is commercial and free software already published doing things using TubroSound Next.

I'm not worried about incompatibility though because there won't be any and should TurboSound FM ever be implemented on the fpga, there will be a simple way to accommodate both.
3) Add the ability to block access to the #BFFD, #FFFD ports of the ZX Spectrum Next computer using the edge connector IORQGE signal.
That signal has always been implemented but for compatibility reasons, it only disables the ULA to open up even ports to external devices.

However, the Next will have a much better way to ensure compatibility with external devices. It will be able to switch the expansion bus on and off during execution and it will be able to disable internal devices depending on whether the expansion bus is on or off. So, eg, it will be possible to specify ports FFFD/BFFD are disabled internally whenever the expansion bus is on and when that happens any TS FM device will be compatible. If the software does not disabled ports FFFD/BFFD, then io cycles involving these ports will not be propagated to the bus so that external devices will not see them.

User avatar
Black_Cat
Posts: 70
Joined: Fri Aug 25, 2017 2:11 pm
Location: Saint Petersburg, Russia Today
Contact:

Re: TurboSound Control Interface

Post by Black_Cat » Sat Jun 22, 2019 11:48 pm

Alcoholics Anonymous wrote:
Fri Jun 21, 2019 2:29 am
It's a little confusing to see "USSR" mentioned when it dissolved long ago
The first ZX Spectrum clone in the USSR was created in 1985, so the community of fans of this computer appeared 6 years before the USSR ceased to exist. Although the USSR is not present now, but the USSR ZX Spectrum Community exists, and is not going to cease to exist. The USSR ZX Spectrum Community includes citizens of different countries and nationalities who communicate in Russian, not just citizens of the Russian Federation, as You mistakenly assumed.
Alcoholics Anonymous wrote:
Fri Jun 21, 2019 2:29 am
maybe it's a translation thing and "former USSR" is meant, although you have to be a certain age these days to even know what that means
There is no confusion. If this community arose after the USSR ceased to exist, it would be called exUSSR ZX Spectrum Community.
Alcoholics Anonymous wrote:
Fri Jun 21, 2019 2:29 am
TurboSound existed long before you published this document. It seems like you may not be using the correct name for this as it looks more like "TurboSound FM".
It used to be "the Kingdom of great Britain", then "the United Kingdom of great Britain and Ireland", and now "the United Kingdom of great Britain and Northern Ireland". Does that bother you? The document States the correct name for the moment. Here is an image of the TurboSound device name on the original 2005 electronic circuit:

Image
Alcoholics Anonymous wrote:
Fri Jun 21, 2019 2:29 am
I do think it's a good idea to remain compatible when possible however. Unfortunately the Next has been out for 2 years now with 440 boards being distributed.
However, the developers of ZX Spectrum Next deliberately made non-coordinated changes to the interface, which create a conflict with the already existing at the time the device TurboSound FM, as well as with future devices that will use the TurboSound Control Interface. This is a deliberate disregard for the copyright of the USSR ZX Spectrum Community and a violation of the license to use the TurboSound Control Interface. This violation must be corrected.
Alcoholics Anonymous wrote:
Fri Jun 21, 2019 2:29 am
Software, both commercial and free, has already been published using the current specs. This is why all updates to the Next have to be backward compatible. So we can't make those sorts of changes to port FFFD any longer. However, it does remain a TurboSound-type interface, as claimed.
This problem was not created by us, but by You. You knew about the existence of TurboSound FM, knew that making inconsistent changes, thereby creating conflicts with other devices using the TurboSound Control Interface. Now only blame yourself. You should apologize to the software manufacturers and announce that the specifications have changed. For ZX Spectrum Next, this is not the first time a specification change has led to software changes, remember ULA+. Collectors of tape cassettes and speculators will be very grateful to you, because. already sold cassettes at once will be rare and will jump up in price. All other users will download updated versions of the software from the Internet. Errors that require software changes have happened in the computer business before, this is not an exceptional situation.
Alcoholics Anonymous wrote:
Fri Jun 21, 2019 2:29 am
I'm not worried about incompatibility though because there won't be any and should TurboSound FM ever be implemented on the fpga, there will be a simple way to accommodate both.
And if such devices will be 1000? Will you add your own switch to ZX Next for each new device in the future? We practiced this approach in 91-95, when independent developers were not able to coordinate their projects, and now this approach is considered amateurish. Project ZX Spectrum Next in its ideology corresponds to our level 95-97 years, when it was developed Sprinter 97. When the kickstarter ZX Next was just beginning, we offered you to use our latest developments, such as TS-config, but you decided to reinvent the wheel. As a result, ideologically and conceptually, the ZX Next could not rise above the level we passed in 1997. But your marketing, which presents stale concepts as the most modern achievement, is certainly on top. In marketing, you are undoubtedly superior to us. :)
Alcoholics Anonymous wrote:
Fri Jun 21, 2019 2:29 am
In your document, it's a mistake to leave don't care bits in ports and data.
I will try to explain to You the logic from which we proceeded in the development of the TurboSound Control Interface. In 2005, at the stage of discussion of this interface, two proposals were made - to implement two devices: on chips YM2149 and YM2203. But since from were only available YM2149 chip, the first implemented device TurboSound. Chips YM2203, in addition to the address range of internal registers PSG $00-$0F, uses an additional address range of registers FM $20-$BF. It is quite logical that this address range was chosen as register addresses for different devices using the TurboSound Control Interface. For control of TurboSound Control Interface has two address range $10-1F, $C0-$FF. The easiest way was to perform deccoding for the range $C0-$FF, it is enough to set AD7,AD6=1.
In the $C0-$FF range, the $x0-$xF address sub-range was allocated for direct address management, and the remaining address ranges were intended for internal register management. In turn, the range of internal registers was divided into sub-range of control registers addresses r/w $10-1F, r/w %1100xx1x-%1111xx1x, wr %1100xx0x-%1111xx0x and sub-range of status regists rd %1100xx0x-%1111xx0x. Rd %1111xx0x status register has been allocated for TurboSound FM. Subsequently, to switch between different TurboSound Control Interface devices, the device selection register of the TurboSound interface r/w %1100xx1x and the function register of the TurboSound interface r/w %1111xx1x were added.
Alcoholics Anonymous wrote:
Fri Jun 21, 2019 2:29 am
However, the Next will have a much better way to ensure compatibility with external devices. It will be able to switch the expansion bus on and off during execution and it will be able to disable internal devices depending on whether the expansion bus is on or off. So, eg, it will be possible to specify ports FFFD/BFFD are disabled internally whenever the expansion bus is on and when that happens any TS FM device will be compatible. If the software does not disabled ports FFFD/BFFD, then io cycles involving these ports will not be propagated to the bus so that external devices will not see them.
No need for this initiative. You claim that 1000 switches is cool, on the contrary, we believe that the use of switches is a sign of unprofessionalism. The IORQGE signal is designed to ensure that all your switches are not needed. You can decide when the ZXBus interface will be enabled in the ZX Next computer, but in those moments when it is enabled, it should be possible to block the ports #FFFD, #BFFD by the IORQGE signal.
Last edited by Black_Cat on Mon Jun 24, 2019 10:13 am, edited 2 times in total.

User avatar
Black_Cat
Posts: 70
Joined: Fri Aug 25, 2017 2:11 pm
Location: Saint Petersburg, Russia Today
Contact:

Re: TurboSound Control Interface

Post by Black_Cat » Sun Jun 23, 2019 10:21 am

I can offer the easiest way to adapt existing software:

1) Switching modes the ZX Spectrum Next.

(to set the register address)
LD BC, 0xFFFD
LD A, 0xCx ; %1100111x selecting Device Selection Register(DSR) and PSG0/1
OUT (C), A

(to write to the DSR)
LD BC, 0xBFFD
LD A, 03 ; set ZX Spectrum Next mode
OUT (C),A

2) Work in ZX Spectrum Next mode.

Bit 7 = “1”
Bit 6 = “0” to select PSG2, and/or disabled the audio channels;
"1" to select PSG0/1 when both audio channels are enabled.
Bit 5 = Right audio (“1” - enabled, “0” - disabled)
Bit 4 = Left audio (“1” - enabled, “0” - disabled)
Bit 3 = “1”
Bit 2 = “1”
Bits 1 and 0 as: “11” - Selects the PSG0 (default);
“10” - Selects the PSG1;
“01” - Selects the PSG2.

For example, to select the PSG1, sound on both audio channel:

LD BC,0xFFFD
LD A, 0xFE ; %11111110 binary
OUT (C), A

To select PSG2 and right audio channel:

LD BC,0xFFFD
LD A, 0xAD ; %10101101 binary
OUT (C), A

3) Return to TurboSound/TurboSound FM mode.

(to set the register address)
LD BC, 0xFFFD
LD A, 0xCx ; %1100111x selecting DSR and PSG0/1
OUT (C), A

(to write to the DSR)
LD BC, 0xBFFD
XOR A ; set TurboSound/TurboSound FM mode
OUT (C),A

As you can see, it is possible to get the same functionality without violating the license to use the TurboSound Control Interface.

Alcoholics Anonymous
Posts: 511
Joined: Mon May 29, 2017 7:00 pm

Re: TurboSound Control Interface

Post by Alcoholics Anonymous » Sat Jun 29, 2019 12:12 am

(deleted - double post)
Last edited by Alcoholics Anonymous on Sat Jun 29, 2019 12:14 am, edited 3 times in total.

Alcoholics Anonymous
Posts: 511
Joined: Mon May 29, 2017 7:00 pm

Re: TurboSound Control Interface

Post by Alcoholics Anonymous » Sat Jun 29, 2019 12:13 am

Black_Cat wrote:
Sat Jun 22, 2019 11:48 pm
[The USSR ZX Spectrum Community includes citizens of different countries and nationalities who communicate in Russian, not just citizens of the Russian Federation, as You mistakenly assumed.
??? What do you think USSR means? Does it just mean Russia? It's pretty hard to make that assumption with USSR used all over the place.
There is no confusion. If this community arose after the USSR ceased to exist, it would be called exUSSR ZX Spectrum Community.
Maybe in Russian but that's not how it works in English.
It used to be "the Kingdom of great Britain", then "the United Kingdom of great Britain and Ireland", and now "the United Kingdom of great Britain and Northern Ireland". Does that bother you? The document States the correct name for the moment. Here is an image of the TurboSound device name on the original 2005 electronic circuit:
The USSR didn't exist in 2005 either. It would be very strange if I started producing documents that originated from "the dominion of Canada", "Upper Canada", "Lower Canada", "Rupert's Land" (where I am sitting right now), "Kanata" and so on. They're historical names.

But it doesn't matter as this is highly pedantic and I know you mean "former USSR".
However, the developers of ZX Spectrum Next deliberately made non-coordinated changes to the interface, which create a conflict with the already existing at the time the device TurboSound FM, as well as with future devices that will use the TurboSound Control Interface. This is a deliberate disregard for the copyright of the USSR ZX Spectrum Community and a violation of the license to use the TurboSound Control Interface. This violation must be corrected.
TurboSound goes back to at least 1995, ten years before you published this document. I'm not sure how you think you can change what "TurboSound" means ten years later. At least change the name to what it is, as in "TurboSound FM" or "TurboSound 2.0" if you are concerned about any confusion. Or maybe the name is "TurboSound Control Interface". In that case, it should be clear from the name "TurboSound Next" that no control interface is involved.

This is not going to be changed because we're not going to force the existing software to be changed. You can't unsell software that has already been distributed in physical form.

If there were a compatibility issue I might be more concerned. Fortunately there is no compatibility issue - the zx next will be able to use external turbosound fm devices and run its software. Should this be added to the fpga at some time, it will be easily added as well, but probably in the reverse direction of your suggestion. In your suggestion you assume the turbosound interface is in "turbosound control interface" mode and must change to next mode whereas we'd likely assume the reverse. In the meantime, a turbosound fm implementation is not claimed and people will not be able to run turbosound fm software without an external turbosound fm device. This shouldn't be a surprise as there are no fm devices implemented on the fpga.

If you're concerned about zx next sound programs running on other systems - it's very likely zx next programs will be using special features of the machine that will not run on those systems anyway. Even if it's just the music, the Russian machines cannot select ABC/ACB stereo, mono per AY, panning left & right, a third AY chip and so on. So it's only really the turbosound subset that will work. If anyone cares, they could also implement a mode switch as you suggested to reach that compatibility.
For ZX Spectrum Next, this is not the first time a specification change has led to software changes, remember ULA+.
Do you think that has something to do with the zx next project?

There are many, many devices from the community integrated into the Next. You speak of only two items here, one of which isn't a real issue (turbosound). Compatibility is held in high importance in this project - being able to run the existing software of *all* sinclair models and being able to attach as many legacy devices as possible are high priorities.

This is not a priority of the former USSR. You are right - the scene there was a mess with lots of slightly different implementations of things. But the current computers are not compatible with anything but themselves and a few Russian clones. This doesn't fit with the vision of this project which is what a following Sinclair-branded computer might look like.
As a result, ideologically and conceptually, the ZX Next could not rise above the level we passed in 1997. But your marketing, which presents stale concepts as the most modern achievement, is certainly on top. In marketing, you are undoubtedly superior to us. :)
You still don't know what a Next is so how would you know?
No need for this initiative. You claim that 1000 switches is cool, on the contrary, we believe that the use of switches is a sign of unprofessionalism. The IORQGE signal is designed to ensure that all your switches are not needed. You can decide when the ZXBus interface will be enabled in the ZX Next computer, but in those moments when it is enabled, it should be possible to block the ports #FFFD, #BFFD by the IORQGE signal.
EDIT: I thought I'd better explain this.

IORQGE is not intended to switch off ports FFFD, BFFD. It is only for disabling port FE to open up even port addresses. What you're asking for is to introduce another possible incompatibility and for what? To solve a problem that doesn't exist?

Adding FFFD, BFFD is a bit self-serving isn't it? Was it added just for your TurboSound Control Interface? Why stop at FFFD, BFFD? Why not 7FFD, DFFD, 1FFD? Why not all the devices inside the computer: FE, FF, 7FFD, DFFD, 1FFD, 243B, 253B, 103B, 113B, 123B, 133B, 143B, 6B, FFFD, BFFD, 0F, F1, 3F, DF, 1F, F3, 4F, F9, 5F, FB, E7, EB, E3, FBDF, FFDF, FADF, 1F, 37, 9F, BF, 303B, 57, 5B ?

I'll help you answer the last one. It would be nice to be able to attach devices and leave them attached to the computer without having to disable the entire computer to use them. You don't have anything more than a 48/128/+3/Pentagon if you cannot use extended features while something else is attached. There are hundreds if not more than a thousand devices made for the spectrum that you and I know nothing about. They've assigned port addresses to themselves that conflict with everything in that list above. In fact there are important mainstream peripherals that conflict with many of the ports above. We have no control over most of the port assignments of the devices internal to the zx next because they are established by existing peripherals, so it's not an option to change those.

The IORQGE thing solves nothing except allowing your TurboSound thing an easy path to plugging into zxbus computers. It isn't a solution to anything.

The problem being solved in the zx next is not a problem encountered by Russian developers because legacy device compatibility is not a concern for them. The way it's being solved in the next allows Turbosound FM to be attached to the machine without making this change to IORQGE and therefore without introducing a possible incompatibility with machines in the Sinclair line.

As for ts-config, the former USSR does not care about the Sinclair legacy. It started by smuggling a few examples of the Sinclair line into the USSR in 1985/1986 or so which led to several copies being made (incorrectly). This led to a different path of chaotic development that occurred long after Sinclair was commercially dead in the West. As a result you have a different experience that branched off from 1985/1986 in our timeline as you were isolated from the goings on of the rest of the world.

We don't ignore what went on in the former USSR and in fact the the ZX Next will be able to run most Pentagon software and we will make sure it's as compatible as we can make it to that machine and some relatives. But some of the development in Russia was not good. The disk system is terrible (the system copied was not the best choice), there were no standards as you noted with a mess of incompatible machines having been developed resulting in limited software support except for a few that attained some popularity, and some of the improvements made no sense in the context of the Sinclair architecture. There is a modern revival in ts-config but again the Sinclair heritage is largely ignored because it doesn't match the pentagon one.

The goal of this project is to extend the Sinclair line in an exercise of what might have happened after. The last machine was the +3 and that's the starting point. Besides extending the +3, delivering a machine that can run most software (of all Sinclair models) and use most devices (of all models) conveniently using modern displays and using a modern file system is the goal. ts-config is not about this.

Locked