Port system documentation updated

All the latest updates about the ZX Spectrum Next, Website and Forum News
seedy1812
Posts: 59
Joined: Tue May 30, 2017 11:31 am

Re: Port system documentation updated

Post by seedy1812 » Mon Nov 05, 2018 4:27 pm

should_draw_pixel(x,y) = ((x1 < x2) ^ ((x1 <= x) ^ (x <= x2))) && ((y1 < y2) ^ ((y1 <= y) ^ (y <= y2))) (^ is XOR, && is AND)

Does seem a bit expensive when you can easily do ( and its a lot easier to read )

should_draw_pixel(x,y) = (x >= x1 ) && (x <= x2 ) && ( y>=y1) && (y<=y2)

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

Re: Port system documentation updated

Post by Ped7g » Mon Nov 05, 2018 8:02 pm

seedy1812 wrote:
Mon Nov 05, 2018 4:27 pm
should_draw_pixel(x,y) = ((x1 < x2) ^ ((x1 <= x) ^ (x <= x2))) && ((y1 < y2) ^ ((y1 <= y) ^ (y <= y2))) (^ is XOR, && is AND)

Does seem a bit expensive when you can easily do ( and its a lot easier to read )

should_draw_pixel(x,y) = (x >= x1 ) && (x <= x2 ) && ( y>=y1) && (y<=y2)
sounds like you completely missed the point of my formula to extend the behaviour of "x2 < x1" and/or "y2 < y1" case. Yours is probably how it is implemented now (and then any "x2 < x1" should reliably hide whole layer, i.e. can be documented like that, unless somebody will like my idea enough to reserve the right to introduce that in future, then documenting it as UB/reserved for this moment would work).

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

Re: Port system documentation updated

Post by Ped7g » Tue Dec 18, 2018 10:39 am

After reading kickstarter update #41, this badly needs further update now... :) (plus maybe you can incorporate some cleanups/fixes).

User avatar
Black_Cat
Posts: 61
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 21, 2018 1:12 pm

Port #DFFD and #7FFD is not recommended to use redundant decoding. This is due to the guaranteed ability to access these ports using the out(nn),a command , as opposed to the #1FFD port, for which this command is not recommended. Therefore, the port #DFFD, it is recommended to use the simplified decoding:
| |*||1|1|0|X|Χ|Χ|Χ|Χ|Χ|Χ|Χ|Χ|X|X|0|1| 0xdffd |ZX Spectrum 128 memory

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

Re: Port system documentation updated

Post by Alcoholics Anonymous » Fri Dec 21, 2018 4:29 pm

Black_Cat wrote:
Fri Dec 21, 2018 1:12 pm
Port #DFFD and #7FFD is not recommended to use redundant decoding. This is due to the guaranteed ability to access these ports using the out(nn),a command , as opposed to the #1FFD port, for which this command is not recommended. Therefore, the port #DFFD, it is recommended to use the simplified decoding:
| |*||1|1|0|X|Χ|Χ|Χ|Χ|Χ|Χ|Χ|Χ|X|X|0|1| 0xdffd |ZX Spectrum 128 memory
Cheers Black Cat. At the moment the decoding looks like this:

Code: Select all

TBBlue / ZX Spectrum Next Peripheral Ports

+-+-++-------------------+---------+--------------------------------+-------------------
| | ||AAAA AAAA AAAA AAAA|         |                                |
| | ||1111 1100 0000 0000|         |                                |
|R|W||5432 1098 7654 3210|Port(hex)|Description                     |Disable
+-+-++-------------------+---------+--------------------------------+-------------------
|*|*||XXXX XXXX XXXX XXX0| 0xfe    |ULA                             |
|*|*||XXXX XXXX 1111 1111| 0xff    |Timex video, floating bus       |Nextreg 0x08 bit 2
| |*||0XXX XXXX XXXX XX01| 0x7ffd  |ZX Spectrum 128 memory          |Port 0x7ffd bit 5
| |*||01XX XXXX XXXX XX01| 0x7ffd  |ZX Spectrum 128 memory +3 only  |Port 0x7ffd bit 5
| |*||1101 XXXX XXXX XX01| 0xdffd  |ZX Spectrum 128 memory (precedence over AY)   |Port 0x7ffd bit 5
| |*||0001 XXXX XXXX XX01| 0x1ffd  |ZX Spectrum +3 memory           |Port 0x7ffd bit 5
|*| ||0000 XXXX XXXX XX01|         |ZX Spectrum +3 floating bus     |Port 0x7ffd bit 5
|*|*||0010 0100 0011 1011| 0x243b  |NextREG Register Select         |
|*|*||0010 0101 0011 1011| 0x253b  |NextREG data/value              |
| |*||0001 0000 0011 1011| 0x103b  |i2c SCL (rtc)                   |
|*|*||0001 0001 0011 1011| 0x113b  |i2c SDA (rtc)                   |  
|*|*||0001 0010 0011 1011| 0x123b  |Layer 2                         |  
|*|*||0001 0011 0011 1011| 0x133b  |UART tx (esp)                   |
|*|*||0001 0100 0011 1011| 0x143b  |UART rx (esp)                   |
|*|*||XXXX XXXX 0110 1011| 0x6b    |zxnDMA                          |
|*|*||11XX XXXX XXXX X101| 0xfffd  |AY reg                          |Nextreg 0x06 bit 0
| |*||10XX XXXX XXXX X101| 0xbffd  |AY dat                          |Nextreg 0x06 bit 0
| |*||XXXX XXXX 0000 1111| 0x0f    |DAC A                           |Nextreg 0x08 bit 3
| |*||XXXX XXXX 1111 0001| 0xf1    |DAC A (precedence over XXFD)    |Nextreg 0x08 bit 3
| |*||XXXX XXXX 0011 1111| 0x3f    |DAC A                           |Nextreg 0x08 bit 3
| |*||XXXX XXXX 1101 1111| 0xdf    |DAC A,C specdrum                |Nextreg 0x08 bit 3
| |*||XXXX XXXX 0001 1111| 0x1f    |DAC B                           |Nextreg 0x08 bit 3
| |*||XXXX XXXX 1111 0011| 0xf3    |DAC B                           |Nextreg 0x08 bit 3
| |*||XXXX XXXX 0100 1111| 0x4f    |DAC C                           |Nextreg 0x08 bit 3
| |*||XXXX XXXX 1111 1001| 0xf9    |DAC C (precedence over XXFD)    |Nextreg 0x08 bit 3
| |*||XXXX XXXX 0101 1111| 0x5f    |DAC D                           |Nextreg 0x08 bit 3
| |*||XXXX XXXX 1111 1011| 0xfb    |DAC D                           |Nextreg 0x08 bit 3
| |*||XXXX XXXX 1110 0111| 0xe7    |SPI /CS (sd card, flash, rpi)   |Nextreg 0x09 bit 2
|*|*||XXXX XXXX 1110 1011| 0xeb    |SPI /DATA                       |Nextreg 0x09 bit 2
|*|*||XXXX XXXX 1110 0011| 0xe3    |divMMC Control                  |Nextreg 0x09 bit 2
|*| ||XXXX 1011 1101 1111| 0xfbdf  |Kempston mouse x                |Nextreg 0x09 bit 3
|*| ||XXXX 1111 1101 1111| 0xffdf  |Kempston mouse y                |Nextreg 0x09 bit 3
|*| ||XXXX 1010 1101 1111| 0xfadf  |Kempston mouse wheel, buttons   |Nextreg 0x09 bit 3
|*| ||XXXX XXXX 0001 1111| 0x1f    |Kempston joy 1                  |Nextreg 0x05
|*| ||XXXX XXXX 0011 0111| 0x37    |Kempston joy 2                  |Nextreg 0x05
|*|*||XXXX XXXX 0001 1111| 0x1f    |Multiface 1 disable             |
|*| ||XXXX XXXX 1001 1111| 0x9f    |Multiface 1 enable              |
|*|*||XXXX XXXX 0011 1111| 0x3f    |Multiface 128 disable           |
|*| ||XXXX XXXX 1011 1111| 0xbf    |Multiface 128 enable            |
|*|*||XXXX XXXX 1011 1111| 0xbf    |Multiface +3 disable            |
|*| ||XXXX XXXX 0011 1111| 0x3f    |Multiface +3 enable             |
|*|*||0011 0000 0011 1011| 0x303b  |Sprite slot, flags              |
| |*||XXXX XXXX 0101 0111| 0x57    |Sprite attributes               |
| |*||XXXX XXXX 0101 1011| 0x5b    |Sprite pattern                  |
+-+-++-------------------+---------+--------------------------------+
I think there is no problem with relaxing port decoding on 0xdffd so it should be ok to change.


Edit: Ah, I take that back. There is a case where a music program is using port 0xC0FD to access the AY register (port 0xFFFD). This would conflict with this relaxed 0xDFFD encoding.

Link:
https://drive.google.com/file/d/1kws2K4 ... sp=sharing

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

Re: Port system documentation updated

Post by Black_Cat » Sat Dec 22, 2018 11:11 am

Alcoholics Anonymous wrote:
Fri Dec 21, 2018 4:29 pm
Edit: Ah, I take that back. There is a case where a music program is using port 0xC0FD to access the AY register (port 0xFFFD). This would conflict with this relaxed 0xDFFD encoding.

Link:
https://drive.google.com/file/d/1kws2K4 ... sp=sharing
:) In the highest degree imprudent to rely on when developing a hardware architecture ZX Next, on the ignorant software. Such software needs to be corrected. That's what all competent exUSSR developers do. Among exUSSR developers,it is considered a good practice to prohibit the use of the out(nn), a command, for #1FFD, #FFFD ports, while for #7FFD, #DFFD, #BFFD ports, the use of this command is allowed.
Using the out(nn),a to address port #C0FD will lead to the fact that such a program will not be correctly executed on the YM2149. This is due to the fact that the YM2149 synthesizer uses a full byte of data to address the internal registers, while the AY891x synthesizer uses only four lower bits of data.

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

Re: Port system documentation updated

Post by Alcoholics Anonymous » Sun Dec 23, 2018 7:10 am

Black_Cat wrote:
Sat Dec 22, 2018 11:11 am
:) In the highest degree imprudent to rely on when developing a hardware architecture ZX Next, on the ignorant software. Such software needs to be corrected.
Unfortunately this might be an important one - it's common in sw that does sid-like effects on the AY. Using 0xC0FD as the port address for AY reg, you can do writes to the AY like this:

Code: Select all

out (c),a
outi
inc b
...
What is being aimed for is maximum compatibility with existing software, not necessarily with what *should* be done but rather with what is *actually* being done.

If the decoding on port 0xDFFD turns out to introduce incompatibility for the Pentagon then we'd likely have to change the decoding for the Pentagon machine type or maybe offer a configuration bit that will change the decoding so that DFFD works or AY works for this software but not both.

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

Re: Port system documentation updated

Post by Black_Cat » Sun Dec 23, 2018 4:48 pm

:) Wery well. :) Thus, we have come to understand the need to apply the exUSSR concept of ZX Spectrum port decoding. :)
The essence of the exUSSR port decoding concept is to add an additional A16 address to the I/O port address space:

A16=0, if out(nn),a/in a,(nn) is not used;
A16=1, if out(nn),a/in a,(nn) is used;

Here's what port decryption #DFFD will look like when using the exUSSR port decoding concept:

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  |
A side effect of using the exUSSR port decoding concept is to extend the address range of I/O ports to 65536+256=65792.

User avatar
Black_Cat
Posts: 61
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 1:43 am

Also, I would recommend changing the port decoding:

Code: Select all

+-+-++--------------------+---------+--------------------------------+
| | ||AAAAA AAAA AAAA AAAA|         |                                |
| | ||11111 1100 0000 0000|         |                                |
|R|W||65432 1098 7654 3210|Port(hex)|Description                     |
+-+-++--------------------+---------+--------------------------------+
|*|*||XXXXX XXXX XXXX XXX0| 0xfe    |ULA                             
|*|*||01011 1111 1111 1111| 0xbfff  |Timex video(future software recommended)
|*|*||1XXXX XXXX 1111 1111| 0xff    |Timex video(old Timex software compatible) 
|*| ||1XXXX XXXX 1111 1111| 0xff    |Attribute(if there was no write to 0xff/0xbfff)
| |*||001XX XXXX XXXX X10X| 0x7ffd  |ZX Spectrum 128/+3 memory       
| |*||10XXX XXXX XXXX X10X| 0x7ffd  |ZX Spectrum 128/+3 memory       
| |*||01101 XXXX XXXX X10X| 0xdffd  |ZX Spectrum 128 memory          
| |*||1110X XXXX XXXX X10X| 0xdffd  |ZX Spectrum 128 memory          
| |*||00001 XXXX XXXX X10X| 0x1ffd  |ZX Spectrum +3 memory           
|*|*||011XX XXXX XXXX X10X| 0xfffd  |AY addr(if 0xdffd is not selected)
| |*||X10XX XXXX XXXX X10X| 0xbffd  |AY data                        
|*| ||01111 1011 1101 1111| 0xfbdf  |Kempston mouse x                
|*| ||01111 1111 1101 1111| 0xffdf  |Kempston mouse y               
|*| ||01111 1010 1101 1111| 0xfadf  |Kempston mouse wheel, buttons  
|*| ||1XXXX XXXX XX01 1111|0x1f/0xdf|Kempston joy 1                  
|*| ||1XXXX XXXX 0011 0111| 0x37    |Kempston joy 2                 
| |*||1XXXX XXXX 0000 1111| 0x0f    |DAC A                           
| |*||1XXXX XXXX 1111 0001| 0xf1    |DAC A                           
| |*||1XXXX XXXX 0011 1111| 0x3f    |DAC A                          
| |*||1XXXX XXXX 1101 1111| 0xdf    |DAC A,C specdrum                
| |*||1XXXX XXXX 0001 1111| 0x1f    |DAC B                           
| |*||1XXXX XXXX 1111 0011| 0xf3    |DAC B                           
| |*||1XXXX XXXX 0100 1111| 0x4f    |DAC C                           
| |*||1XXXX XXXX 1111 1001| 0xf9    |DAC C 
| |*||1XXXX XXXX 0101 1111| 0x5f    |DAC D                           
| |*||1XXXX XXXX 1111 1011| 0xfb    |DAC D                           
| |*||1XXXX XXXX 1110 0111| 0xe7    |SPI /CS (sd card, flash, rpi)  
|*|*||XXXXX XXXX 1110 1011| 0xeb    |SPI /DATA                       
|*|*||1XXXX XXXX 1110 0011| 0xe3    |divMMC Control                  
|*|*||1XXXX XXXX 0001 1111| 0x1f    |Multiface 1 disable             
|*| ||1XXXX XXXX 1001 1111| 0x9f    |Multiface 1 enable              
|*|*||1XXXX XXXX 0011 1111| 0x3f    |Multiface 128 disable           
|*| ||1XXXX XXXX 1011 1111| 0xbf    |Multiface 128 enable            
|*|*||1XXXX XXXX 1011 1111| 0xbf    |Multiface +3 disable            
|*| ||1XXXX XXXX 0011 1111| 0x3f    |Multiface +3 enable             
|*|*||00011 0000 0011 1011| 0x303b  |Sprite slot, flags              
| |*||1XXXX XXXX 0101 0111| 0x57    |Sprite attributes               
| |*||1XXXX XXXX 0101 1011| 0x5b    |Sprite pattern                  

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 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?
Backer #2741 - TS2068, Byte, ZX Evolution

Locked