Some suggestions for core 2.00.xx changes

This section is for discussing everything about Next hardware and latest updates.
Ped7g
Posts: 48
Joined: Mon Jul 16, 2018 7:11 pm

Re: Some suggestions for core 2.00.xx changes

Postby Ped7g » Tue Jan 01, 2019 6:22 pm

Actually I'm updating now wiki with those details, and there's another quite trivial workaround for almost-non-interrupt wait-for-line:

All you have to do is just to `di` and set up line interrupt in $22+$23 and then keep reading $22 in loop until "INT" is raised -> restore interrupt settings in $22 and `ei`. (I mean again if you have some idea where in frame you already are, i.e. for example waiting from code finished somewhere during ~first part (lines 80..100) for line 128 to modify something particular, but being too lazy to install full interrupt handler, and not wanting to use copper for detection).

EtchedPixels
Posts: 16
Joined: Fri May 04, 2018 10:59 am

Re: Some suggestions for core 2.00.xx changes

Postby EtchedPixels » Fri Jan 04, 2019 6:30 pm

From an OS perspective things that would be nice to have
- a way to lock all the magic system I/O ports until an unlock key is written again
- mark any 8K as write protected
- NMI option on writes to write protected memory in 8K slices (really helps debugging code scribbles)
- way to check if the serial write FIFO is full so you don't overrun it with bursty writes. Right now if the docs are correct you can check for RX data present by reading TX but the other bits are not used so there is no TX full indicator.

More complex stuff would include
- flexibly map the video and spectrum 128K pages to system pages (so you can virtualize 128K software better)
- set the address of video for next fetches (including from copper) - so you can do more hardware split scrolling and Amiga style screens
- de-interlacing using that - so you'd set the video top, wait for bottom, set the second video top, wait for bottom, repeat and get a 384 pixel display on the VGA side and CPU free interlace on the classic output.
- branch trace FIFO like a modern era CPU so you can see how you got to the point the code went boom

If you wanted to fix the CPU architecture a bit compatibly I'd probably be better stealing bits from the Z280, which is Z80 compatible and fixes a lot of the gaps in the Z80. In particular you've got

maths and logic ops against addresses
push and pop to address, push constant
more 16bit ops (add, sub, load, compare, indirections like ld hl,(hl))
multiply/divide
16bit IX, IY, SP and HL relative
(IX+HL) (IY+HL) and (IX+IY)

and trivial but incredibly useful stuff like

ex h,l
ex a,anyreg
add hl,a

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

Re: Some suggestions for core 2.00.xx changes

Postby Alcoholics Anonymous » Wed Jan 09, 2019 9:20 am

EtchedPixels wrote:
Fri Jan 04, 2019 6:30 pm
From an OS perspective things that would be nice to have
- a way to lock all the magic system I/O ports until an unlock key is written again
- mark any 8K as write protected
- NMI option on writes to write protected memory in 8K slices (really helps debugging code scribbles)
There is very likely going to be a way to turn off io ports to gain more compatibility with external peripherals but the architecture is currently a long way off from having any sort of supervisor mode.
- way to check if the serial write FIFO is full so you don't overrun it with bursty writes. Right now if the docs are correct you can check for RX data present by reading TX but the other bits are not used so there is no TX full indicator.
There isn't a Tx Fifo currently - it's just a single byte shift register. The status register can be polled to find out when the shift register is empty:

Code: Select all

# PORT 0x133B: UART Status (read only)

define(`__IO_UART_STATUS', 0x133b)

define(`__IUS_RX_AVAIL', 0x01)  # active high
define(`__IUS_TX_BUSY', 0x02)   # active high
define(`__IUS_RX_FULL', 0x04) # active high
- set the address of video for next fetches (including from copper) - so you can do more hardware split scrolling and Amiga style screens
You can set the vertical and horizontal scroll registers at any time. I'm not sure if that's what you're thinking of.

EtchedPixels
Posts: 16
Joined: Fri May 04, 2018 10:59 am

Re: Some suggestions for core 2.00.xx changes

Postby EtchedPixels » Wed Jan 09, 2019 2:42 pm

I'm not suggesting any kind of supervisor mode. Trying to add that to a Z80 would be hard and loads of gates. You'd also need a lot of very different software because a supervisor mode really implies having two different SP values and that breaks everything in the T80 core.

Thanks for the FIFO pointer - I trusted the wiki which only documents it having values 1 or 0.

Scrolling registers help for some cases but not for interlace to get a decent vertical resolution and not if you want to combine multiple screens effectively. Imagine you've got say four virtualized 48K games and you want to be able to show slices of each according to how the user places title bars. At that point you really need to be able to set the full bank and offset for the video so you can move between displays.

Yes you can fake it with big copies but its ugly and slow.

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

Re: Some suggestions for core 2.00.xx changes

Postby Alcoholics Anonymous » Wed Jan 09, 2019 3:37 pm

EtchedPixels wrote:
Wed Jan 09, 2019 2:42 pm
Imagine you've got say four virtualized 48K games and you want to be able to show slices of each according to how the user places title bars. At that point you really need to be able to set the full bank and offset for the video so you can move between displays.
Virtualizing the standard ula screen has architectural hurdles. Bank 5, which contains the ula display, is held in a 16k x 8 memory on the fpga. There cannot be more than one copy of this bank so you're stuck with copying, however the dma can make short work of that especially considering the small size of ula mode displays.

Layer 2 is in main memory and can be moved around. But it is currently confined to the first 512k chip (which amounts to pages 0-31, out of which each layer 2 display takes 6 pages) again for different technical reasons. Bank 5 (pages 10,11) has to be excluded from that range.

I don't know if any of this will change in future.
Thanks for the FIFO pointer - I trusted the wiki which only documents it having values 1 or 0.
Yes the wiki is quite a bit out of date and does have some wrong information there though there is a forum member here trying to update it.

I put some technical information into z88dk's config files:
https://github.com/z88dk/z88dk/tree/mas ... zxn/config

config_zxn_uart.m4, config_zxn_copper.m4, config_zxn_dma.m4, etc but I have fallen behind as spare time as been spent on other zx next things.

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

Re: Some suggestions for core 2.00.xx changes

Postby Ped7g » Wed Jan 09, 2019 7:16 pm

Alcoholics Anonymous wrote:
Wed Jan 09, 2019 3:37 pm
Thanks for the FIFO pointer - I trusted the wiki which only documents it having values 1 or 0.
Yes the wiki is quite a bit out of date and does have some wrong information there though there is a forum member here trying to update it.
I'm trying, I'm trying... but the UART things are somewhat out of my radar, and it's been some years since I did any low level serial, so at this moment the UART description is beyond my horizon... (I'm preparing to rewrite Sprites article, and keep main NextRegs and ports up to date as much as possible ... maybe later something about DMA, but I need first to write few tests for it, and ask somebody with board to run them, so I can be sure I got it right).

BTW, while David Saphier helped me to test one of those tests, just exercising almost all NextRegs, and on two occasions his board reported $42 (INK_mask) as 00 ... (seems like when he loads the snapshot through NextZXOS or I don't know the precise path ... boot into 48k mode + sna load = $42 is expected 15, so default is OK) - makes me wonder, as mask 0 is like "forbidden" in docs, who wrote it there and why, so does it have some functionality, or is it just some bug somewhere, and the board simply survives 00 without big problem?

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

Re: Some suggestions for core 2.00.xx changes

Postby Alcoholics Anonymous » Thu Jan 10, 2019 4:52 am

Ped7g wrote:
Wed Jan 09, 2019 7:16 pm
BTW, while David Saphier helped me to test one of those tests, just exercising almost all NextRegs, and on two occasions his board reported $42 (INK_mask) as 00 ... (seems like when he loads the snapshot through NextZXOS or I don't know the precise path ... boot into 48k mode + sna load = $42 is expected 15, so default is OK) - makes me wonder, as mask 0 is like "forbidden" in docs, who wrote it there and why, so does it have some functionality, or is it just some bug somewhere, and the board simply survives 00 without big problem?
I don't know how the 0 got there but the hardware reset value is 0x0f. The hw will default to 0x0f for undefined values but this is not something that should be relied on as it's not impossible that sometime down the road other meanings are attributed to other values.


Who is online

Users browsing this forum: No registered users and 2 guests