Port system documentation updated

All the latest updates about the ZX Spectrum Next, Website and Forum News
User avatar
varmfskii
Posts: 176
Joined: Fri Jun 23, 2017 1:13 pm
Location: Albuquerque, NM USA

Re: Port system documentation updated

Post by varmfskii » Fri Jan 11, 2019 3:15 pm

So,if I attempt to write to a pre-existing 8-bit port that has a specified value for A16 using both out (nn),a and out (c),a I will succeed in writing to that port? If that is not the case, then it can cause incompatibilities. Very few of the 8-bit port addresses on the next are not pre-existing. It doesn't cause problems for the Eastern machines simply because they don't need compatibility with legacy software accessing those ports in the wrong way. Think about why you ignore A16 for writes to port $fe (all even ports)
Backer #2741 - TS2068, Byte, ZX Evolution

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

Re: Port system documentation updated

Post by Black_Cat » Sun Jan 13, 2019 3:24 am

The additional address line A16 is used selectively only when justified.

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

Re: Port system documentation updated

Post by Black_Cat » Sun Jan 13, 2019 11:49 am

varmfskii wrote:
Fri Jan 11, 2019 3:15 pm
It doesn't cause problems for the Eastern machines simply because they don't need compatibility with legacy software accessing those ports in the wrong way.
You are mistaken, in exUSSR computers, if possible, compatibility with old software is supported. Given example:

Example 1. The demo often uses the following hack: out (#fc), a . This hack allows the ZX Spectrum 128 to switch memory pages and change the border color at the same time. In my proposed decryption, the software that uses this hack will be executed correctly. But with the current ZX Next decoding, this software will not work.

Example 2. The old software uses two equal addresses of the Kempston joystick read port: #1f and #df. My proposed decryption allows you to correctly execute software using any port, and at the same time, thanks to the use of A16 allows you to avoid conflict with Kempston Mouse. The current ZX Next decoding does not allow to correctly execute the old software that accesses the joystick at #df.

Example 3. Some old ZX Spectrum software uses the port address #ff to read the current value of the display attribute. The same port is used in Timex 2048/2068 computers. My proposed decryption allows you to combine the use of these ports with a simple rule:

- if the port #ff was not written, then the port #ff corresponds to the architecture of the ZX Spectrum;
- if the #ff port was written to, the #ff port corresponds to the Timex architecture until the hardware reset;

In addition, it is recommended to use the additional address #bfff when using the Timex port from now on. The appeal on this address allows correctly executed software including computers Timex 2048/2068.

There is no mention in the documentation of the ZX Next computer of the possibility of execution of the software ZX Spectrum, using reading the current value of the screen attribute through the port #ff.

As you can see, my proposed decoding is more advanced than the current ZX Next decoding, which has poor compatibility with the old software.

User avatar
varmfskii
Posts: 176
Joined: Fri Jun 23, 2017 1:13 pm
Location: Albuquerque, NM USA

Re: Port system documentation updated

Post by varmfskii » Sun Jan 13, 2019 3:50 pm

I see the general superiority of your (eastern, soviet, exUSSR, etc.) decoding scheme, but you seem simply incapable of understanding how it breaks compatibility. I do not know if this is a failure in communication, you being too stubborn to actually have an open enough mind to perceive the problem, or that you are trolling.

It is very simple: if a port could be accessed through any instruction before and you restrict it to only being able to be accessed through certain instructions, you break compatibility with software that used instructions other than the ones you restrict it to. How is it that you can fail to understand this very simple concept.

It solves some problems and introduces others. As always TANSTAAFL.
Backer #2741 - TS2068, Byte, ZX Evolution

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

Re: Port system documentation updated

Post by Black_Cat » Sun Jan 20, 2019 10:26 am

varmfskii wrote:
Sun Jan 13, 2019 3:50 pm
I see the general superiority of your (eastern, soviet, exUSSR, etc.) decoding scheme, but you seem simply incapable of understanding how it breaks compatibility. I do not know if this is a failure in communication, you being too stubborn to actually have an open enough mind to perceive the problem, or that you are trolling.

It is very simple: if a port could be accessed through any instruction before and you restrict it to only being able to be accessed through certain instructions, you break compatibility with software that used instructions other than the ones you restrict it to. How is it that you can fail to understand this very simple concept.

It solves some problems and introduces others. As always TANSTAAFL.
Wery well. Let's look at the origins of your misunderstanding. Indeed, misunderstanding can be caused by mentality. In the West too exaggerate and mythologize "absolute freedom". Russians have a more pragmatic attitude - we understand that in the real world "absolute freedom" does not exist, has never existed before, and will never exist in the future. The freedom of programming for the ZX Spectrum computer is limited by the rules. Although these rules did not arise immediately, in most cases they were observed even before their appearance. Such rules include the prohibition of the use of teams out(nn),a for ports #1FFD, #FFFD, and commands in a,(nn) for ports Kempston mouse #FADF, #FBDF, #FFDF. These rules are quite natural, and do not cause programming complications. Compliance with these rules determines the possibility of application in the decoding of A16. There are other rules, for example,when accessing #7ffd with the command out(nn), a,the higher discharges d7, d6 of the accumulator must always be set as 01. This rule provides software compatibility between ZX Spectrum 128 and ZX Spectrum +2/+3. This rule appeared for the first time in the West, and therefore some part of exUSSR software had to be corrected to comply with this rule. Nothing is given for nothing, it is necessary to pay for standardization and further development of programming rules. The motivation to follow the rules is to preserve the professional reputation of the programmer. No one wants to be called an Amateur unfamiliar with the rules of programming for a ZX Spectrum computer.

User avatar
varmfskii
Posts: 176
Joined: Fri Jun 23, 2017 1:13 pm
Location: Albuquerque, NM USA

Re: Port system documentation updated

Post by varmfskii » Sun Jan 20, 2019 4:17 pm

The only misunderstanding is yours. A16 adds *new* rules. How much existing software is broken by these new rules.

It is you who have the abrasive opinion that not following the rules for a separate branch of development is somehow broken.
Backer #2741 - TS2068, Byte, ZX Evolution

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

Re: Port system documentation updated

Post by Black_Cat » Sun Jan 20, 2019 6:44 pm

varmfskii wrote:
Sun Jan 20, 2019 4:17 pm
The only misunderstanding is yours. A16 adds *new* rules. How much existing software is broken by these new rules.

It is you who have the abrasive opinion that not following the rules for a separate branch of development is somehow broken.
In cases where it is intended to use A16, the existing software usually does not violate the rules. This is quite natural, since using in a, (nn) for Kempston mouse ports does not make sense. At the same time, the use of any other commands except in a, (nn) to read Kempston joystick also does not make sense. Therefore, the use of A16 to separate these devices is quite natural, and does not cause contradictions. In other cases, the situation is similar. At its core, in most cases, the rules fix on paper the existing state.

Ped7g
Posts: 83
Joined: Mon Jul 16, 2018 7:11 pm

Re: Port system documentation updated

Post by Ped7g » Sun Jan 20, 2019 7:29 pm

Not sure if I fully follow you, but just recently I wrote again some Z80 code (after ~21 years of hiatus), to test some Next abilities...

And if using `out (c),a` vs `otir` vs `out (nn),a` counts for you as "different", then I already managed to break your rule on about ~500 lines of my new code (using all three of them for the same port for uploading sprite attribute data, depending on the part of the code)...

User avatar
varmfskii
Posts: 176
Joined: Fri Jun 23, 2017 1:13 pm
Location: Albuquerque, NM USA

Re: Port system documentation updated

Post by varmfskii » Sun Jan 20, 2019 8:00 pm

Black_Cat wrote:
Sun Jan 20, 2019 6:44 pm
...the existing software usually does not violate the rules... ...in most cases...
Exactly the point it sometimes does.

Say, I want the value in a register other than A, especially if I want to preserve A.
Backer #2741 - TS2068, Byte, ZX Evolution

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

Re: Port system documentation updated

Post by Black_Cat » Sun Jan 20, 2019 8:28 pm

Sometimes the plane crashes, but nonetheless, the aircraft continues its development. Civilization means development. The exUSSR community has 30 years of ZX Spectrum development, and we are not afraid of possible problems. The Western community is taking only the first steps in this direction. The Western community has the opportunity to either benefit from our experience or reinvent the wheel.

Locked