Port system documentation updated

All the latest updates about the ZX Spectrum Next, Website and Forum News
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 » Mon Dec 24, 2018 4:44 am

varmfskii wrote:
Mon Dec 24, 2018 3:08 am
While not in issue with an FPGA version of a Z80, with an actual Z80 how does the hardware determine whether to assert A16 or not?
The out(nn),a/in a,(nn) command trap is used.

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 » Mon Dec 24, 2018 4:46 pm

How does the hardware manage this feat? If I were to build a machine with a Z80 myself, what would I have to do to create this signal from the available signals? Not when is the signal asserted, how is the signal asserted?
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 » Mon Dec 24, 2018 5:50 pm

out(nn),a/in a,(nn) command trap
Attachments
out(nn),a & in a,(nn) command trap.PNG
out(nn),a & in a,(nn) command trap.PNG (11.68 KiB) Viewed 1156 times

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 » Mon Dec 24, 2018 9:54 pm

Alcoholics Anonymous, do you need comments on port decoding, or do you understand why the decoding is done this way?

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

Re: Port system documentation updated

Post by Alcoholics Anonymous » Fri Dec 28, 2018 6:07 am

Black_Cat wrote:
Mon Dec 24, 2018 9:54 pm
Alcoholics Anonymous, do you need comments on port decoding, or do you understand why the decoding is done this way?
No I can see how it works - it's just something you don't really want to do but if it solves all the port conflicts it might be something that you'd end up having to do for the sw compatibility. I'll come back to this when the pentagon is revisited, or maybe sooner since its percolating now.

What machines did this actually get implemented in? What about other Pentagon memory extension schemes - are there any other important ones?

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 » Fri Dec 28, 2018 5:26 pm

Alcoholics Anonymous wrote:
Fri Dec 28, 2018 6:07 am
No I can see how it works - it's just something you don't really want to do but if it solves all the port conflicts it might be something that you'd end up having to do for the sw compatibility. I'll come back to this when the pentagon is revisited, or maybe sooner since its percolating now.
What exactly can't you see? Don't you see that the presented decoding satisfies all the restrictions?

Code: Select all

+-+-++--------------------+---------+--------------------------------+
| | ||AAAAA AAAA AAAA AAAA|         |                                |
| | ||11111 1100 0000 0000|         |                                |
|R|W||65432 1098 7654 3210|Port(hex)|Description                     |
+-+-++--------------------+---------+--------------------------------+
| |*||01101 XXXX XXXX X10X| 0xdffd  |ZX Spectrum 128 memory          
| |*||1110X XXXX XXXX X10X| 0xdffd  |ZX Spectrum 128 memory          
|*|*||011XX XXXX XXXX X10X| 0xfffd  |AY addr(only if 0xdffd is not selected)
If you can refute this statement, please give your arguments.
Alcoholics Anonymous wrote:
Fri Dec 28, 2018 6:07 am
What machines did this actually get implemented in? What about other Pentagon memory extension schemes - are there any other important ones?
It makes no sense to discuss other exUSSR computer architectures until all the errors in the ZX Next architecture are fixed.

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 Dec 30, 2018 8:36 pm

Black_Cat wrote:
Fri Dec 28, 2018 5:26 pm
It makes no sense to discuss other exUSSR computer architectures until all the errors in the ZX Next architecture are fixed.
It seems that you and AA are talking at crossed purposes. The A16 from in a,(nn)/out (nn),a in exUSSR computers is an interesting hack and I'm sure that it has proved to be a great solution for the port addressing mess that exists as a result of some originally horrible port decoding, but not using it on the ZX Next does not mean that port addressing on the ZX Next is broken. Several of the 8-bit I/O ports on the ZX Next are designed to be backward compatible with existing ZX Spectrum peripherals so that existing software that uses those peripherals does not need to be modified for the ZX Next. Adding A16 decoding potentially breaks existing software which uses those ports.

It should be remembered that there have been splits in the evolution of the ZX Spectrum and that the ZX Next is a descendant of one of the paths while machines like the Pentagon and ZX Evolution are descendants of another. As a result a solution that is ideal for one may be ideal for the other.
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 » Mon Jan 07, 2019 6:19 pm

varmfskii wrote:
Sun Dec 30, 2018 8:36 pm
It should be remembered that there have been splits in the evolution of the ZX Spectrum and that the ZX Next is a descendant of one of the paths while machines like the Pentagon and ZX Evolution are descendants of another. As a result a solution that is ideal for one may be ideal for the other.
There is Altwasser architecture, and non-Altwasser architecture. The Altwasser architecture allows you to almost completely eliminate the limitations caused by incomplete port decoding. Altvasser architecture corresponds to the original ZX Spectrum, as well as exUSSR clones using the NemoBus expansion bus. No Western clone, ranging from the Spanish ZX Spectrum 128, as well as Western peripheral equipment, does not correspond to the Altvasser architecture, moreover, Western developers do not even understand what it is. To visualize the level of ignorance of Western developers, imagine a situation where Russian freely for 30 years flying into space, while Western developers believe that this is impossible, because the Earth is flat. This is the situation at the moment, and the developers of the ZX Next computer support this ignorance.

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 » Mon Jan 07, 2019 7:22 pm

It breaks compatibility with some preexisting hardware which is being referenced in the zx spectrum next. How can you not see this.
Look at the port decoding table that you have given and think a bit. The Soviet way is not the only way.

For Example: Look at port 0xff. Since this is a preexisting 8-bit port, software may exist which uses any arbitrary instruction which reads from or writes to a port that will be broken by having it decoded by only one state of A16.
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 » Fri Jan 11, 2019 5:24 am

You mentioned two ways of development, and I explained what their difference is - Russians have been developing their computers in accordance with the Altvasser architecture for 30 years, and have no problems with incomplete decoding, while in the West they know nothing about the Altvasser architecture, and they themselves create fictional problems. All compatibility issues exist only in your imagination, and are a consequence of architectural ignorance. When using the Altwasser architecture, these problems are simply impossible.

However, I don't encourage the ZX Next developers to use the Altwasser architecture - it's too late. At the moment, it is possible to talk only about how to minimize the damage to the community by correcting the errors in the ZX Next deccoding. I can help you with that.

Locked