Update 41 and "2.00.X."

This section is for discussing everything about Next hardware and latest updates.
Alcoholics Anonymous
Posts: 463
Joined: Mon May 29, 2017 7:00 pm

Re: Update 41 and "2.00.X."

Postby Alcoholics Anonymous » Wed Jan 09, 2019 8:53 am

Ped7g wrote:
Wed Jan 02, 2019 9:51 pm
Q1 (the "-" points are how I read the docs and set values in code, i.e. not questions, but let me know if you spot mistake):
- default ZX48 ULA screen (white border 7, white paper 7, black ink 0, cls)
- ULANext mode enabled (NR$43=1) and ink_mask$42=7 (i.e. default ULA attribute $38 turns into paper 7 + ink 0 in ULANext mode)
- so ULA palette offset 135 is for border and paper now (7 + 128 = 135)
- transparency fallback NR$4A set to $8F (raw cyan)
- ULA palette offset 135 modified to $E3 (pink, actually 9b pink in code $E300)
- global transparency colour modified to $E3 too, so border and paper is "transparent" now
- in emulator #CSpect 2.2.0 paper *is* transparent, showing raw cyan (all pixels transparent = fallback colour) = works as expected
? border is pink, not using fallback for transparent colour.
The border should be transparent too. If Cspect is not doing that, that's a bug. If you have a test program I can verify it on real hw.
Q2: when ULANext mode is not enabled (bit0 in NR$43 is zero = "flash enabled"), should transparency in ULA layer even work? I mean, no matter how you modify ULA palette, only the default ZX colours will be displayed, right?
Yes transparency will work. In standard mode the ULA colours come from indices 0-7 for ink, 8-15 for bright ink, 16-23 for paper and 24-31 for bright paper if I remember correctly. Border comes from paper.

Transparency is a test on the final colour generated by the ULA.
Q2b: when you enabled only Layer2 in such case, and over ULA layer, the L2 should display normally in Next-way (including working transparency for Layer 2 letting ULA pixels to be seen under), only ULA layer is sticking to classic ZX and not using transparency?
Yes but standard ULA can also be transparent as mentioned.
Q2c: when you enable LoRes, but ULANext is disabled ... does the LoRes override that and turn classic ULA into LoRes layer?
Yes LoRes replaces the usual ULA behaviour so its pixels go through the ULA palette without any modifications.

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

Re: Update 41 and "2.00.X."

Postby Ped7g » Wed Jan 09, 2019 8:17 pm

Alcoholics Anonymous wrote:
Wed Jan 09, 2019 8:53 am

The border should be transparent too. If Cspect is not doing that, that's a bug. If you have a test program I can verify it on real hw.
Yup, this older test is doing that (setting "paper 7 + border 7" to $E3, and setting fallback to $1F (cyan)):

https://github.com/MrKWatkins/ZXSpectru ... ansparency

Both emulators show the border as pink instead of cyan, but I guess that's just under-implemented at this moment and they will fix it over time.

If you can try it on real board + provide photo, I will update readme description + include photo.

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

Re: Update 41 and "2.00.X."

Postby Alcoholics Anonymous » Thu Jan 10, 2019 3:08 am

Ped7g wrote:
Wed Jan 09, 2019 8:17 pm
Yup, this older test is doing that (setting "paper 7 + border 7" to $E3, and setting fallback to $1F (cyan)):

https://github.com/MrKWatkins/ZXSpectru ... ansparency

Both emulators show the border as pink instead of cyan, but I guess that's just under-implemented at this moment and they will fix it over time.

If you can try it on real board + provide photo, I will update readme description + include photo.
This is on 2.00.25:
https://drive.google.com/file/d/10APZ2g ... sp=sharing

2.00.24 shows a black border which is incorrect. It was mapping the border colours to ink instead of paper.

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

Re: Update 41 and "2.00.X."

Postby Ped7g » Thu Jan 10, 2019 6:10 am

Alcoholics Anonymous wrote:
Thu Jan 10, 2019 3:08 am
Ped7g wrote:
Wed Jan 09, 2019 8:17 pm
Yup, this older test is doing that (setting "paper 7 + border 7" to $E3, and setting fallback to $1F (cyan)):

https://github.com/MrKWatkins/ZXSpectru ... ansparency
This is on 2.00.25:
https://drive.google.com/file/d/10APZ2g ... sp=sharing

2.00.24 shows a black border which is incorrect. It was mapping the border colours to ink instead of paper.
Nice, thank you. I guess the black dots are start-up code in ULA screen for SNA loading. I should probably clear that explicitly in the test to make them produce stable outcome.

I will try to add few more of those basic tests, and then somewhere later I will try to persuade you to go through all of them and validate them (that they work as expected, and if not, then we will have to figure out, if it's test or core fault). In ideal world I would like to be in sync with the cased next, i.e. all tests run flawlessly on the delivered core. :)

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

Re: Update 41 and "2.00.X."

Postby Ped7g » Thu Jan 10, 2019 7:38 am

And one more question... how does actually the snapshotting knows, what border was currently set? As far as I can tell, it's not possible to read set border back. All those tests are made by assumption the border is white (like "started from fresh BASIC"), but that's not very reliable assumption and snapshot actually does not store this information either, right?

So that's another thing to refresh in those tests, make sure they set border explicitly, if they describe the desired behaviour in any way.

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

Re: Update 41 and "2.00.X."

Postby Alcoholics Anonymous » Thu Jan 10, 2019 3:25 pm

Ped7g wrote:
Thu Jan 10, 2019 7:38 am
And one more question... how does actually the snapshotting knows, what border was currently set? As far as I can tell, it's not possible to read set border back. All those tests are made by assumption the border is white (like "started from fresh BASIC"), but that's not very reliable assumption and snapshot actually does not store this information either, right?
Snapshots do store this information, see SNA in:
https://www.worldofspectrum.org/faq/ref ... s.htm#File

But the information is not readable from the port; that's not a problem for emulators of course. If building an SNA there's sometimes an option to specify the border byte depending on what you are using to build SNAs. The original Mirage microdriver device that created SNAs probably read a system variable to set border colour if it implemented the border colour at all.
So that's another thing to refresh in those tests, make sure they set border explicitly, if they describe the desired behaviour in any way.
I would set all initial state you're depending on. You never know what some other program has done before yours runs and you can't know for sure if those other programs were exited normally or via reset.

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

Re: Update 41 and "2.00.X."

Postby Ped7g » Thu Jan 10, 2019 3:44 pm

Alcoholics Anonymous wrote:
Thu Jan 10, 2019 3:25 pm
I would set all initial state you're depending on. You never know what some other program has done before yours runs and you can't know for sure if those other programs were exited normally or via reset.
Normally yes, but these short codes are targetted at emulator authors (and to check certain aspects of real board in case where dry formal docs are a bit too complicated and code example may help). So in some cases they intentionally exercise expected default state - and they mention that in the description. But this "border is white" was not supposed to be part of that test, that's simply bug (oversight in design). And they are supposed to be run after power-on only.

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

Re: Update 41 and "2.00.X."

Postby Ped7g » Tue Jan 15, 2019 8:57 pm

Alcoholics Anonymous wrote:
Fri Dec 28, 2018 4:25 pm
Ped7g wrote:
Fri Dec 28, 2018 8:10 am
I was toying around with emulators and Timex 512x192 mode, and I wonder if you can tell me some definitive answer, how the Next will work in this regard.
If in Timex hi-res mode the colour is completely determined by port 0xff including the border colour matching the paper of the hi-res mode. Timex hi-res is always bright as you noted.

ULAnext mode takes the attribute byte generated by the ULA and reinterprets the bits to decide what colour ink and paper will be. This does not change no matter what mode the ULA is in. So for Timex hi-res mode you're going to have some ink/paper attribute set by port 0xff (01PPPIII) which will pass through the ULAnext system that decides how many of the rightmost bits are ink in the attribute byte and the rest are paper. So some weird effects may happen.
So I programmed it like this, and it works on board with core 2.00.24. Great.
https://github.com/MrKWatkins/ZXSpectru ... op/release -> "LmxHiRes.sna"

Unfortunately both emulators are at this moment unusable in TimexHiRes combined with L2/Sprites scenario.

In case somebody else will be curious and would want to experiment with it, this is current status:

- ZEsarUX7.1 (7.2-git-snapshot) does handle colours (including ULANext palette) correctly, but it draws the whole HiRes layer at the end of the frame (modifications of palette/control registers don't show in the middle), and it doesn't do the final transparency check/composition, so only HiRes layer is visible (even if one of the two colours is set as transparent).

- #CSpect2.2.0 - has it almost working, except that whenever there's transparency in HiRes/HiCol or clip of classic ULA (making part of pixel area "transparent" in ULA layer), the pixel-combinator does produce solid pixel from previous line(s) instead of fetching other layer or fallback colour, which makes in the end output unusable too, but I guess Mike may need less work to fix it. Also his decoding of colour and translation through palette may be inaccurate, not using ink-mask same way as HW does, but I'm not sure about that.

(EDIT a workaround for aspiring developers: I would suggest to use ZEsarUX in this case, just switch the Timex screen0/screen1 mode instead of HiRes, set 768 bytes of attributes to desired monochrome values you will use in HiRes, and you can develop like this, seeing only every other column of HiRes chars/pixels, which may be enough to do basic development + debugging... then flip the real HiRes mode and validate HiRes layer content in ZEsarUX and finally check the result with real board if the layer mixing works as expected).

QUESTION: ULA-clip-window will apply also to HiRes mode? What will happen to border (I guess border will ignore content of clip-window, as it's already not clipped while default 0,255,0,191 is set)? And if clip window does apply to pixels, I guess it will take them by two on X-axis, i.e. X1=1 will clip two hi-res pixels (= one classic pixel)?
Last edited by Ped7g on Wed Jan 16, 2019 9:46 am, edited 1 time in total.

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

Re: Update 41 and "2.00.X."

Postby Ped7g » Wed Jan 16, 2019 9:41 am

And one more technical detail question...

The Timex hi-res mode is strictly bound to that BRAM 5 bank (or was it 4?),? If you would use Timex mode and also use the shadow-bit of 128k, will it not switch to bank 7 (for the price of losing Layer2)? Or the Timex is hard-wired to the bank 5 and ignoring the state of shadow-buffer bit of 128k machine?

Overall there are many different bits in the machine selecting contradicting features, like LoRes vs Timex, etc.. I would love to see some technical docs listing priorities of those, i.e. which setting wins in the end, if they collide.

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

Re: Update 41 and "2.00.X."

Postby Alcoholics Anonymous » Thu Jan 17, 2019 2:39 am

Ped7g wrote:
Tue Jan 15, 2019 8:57 pm
QUESTION: ULA-clip-window will apply also to HiRes mode? What will happen to border (I guess border will ignore content of clip-window, as it's already not clipped while default 0,255,0,191 is set)? And if clip window does apply to pixels, I guess it will take them by two on X-axis, i.e. X1=1 will clip two hi-res pixels (= one classic pixel)?
Yes the clip applies to all ULA screens and in 512x192 mode, each sub-pixel is paired to make one ULA pixel as far as the hw is concerned. The border is outside the clip area and is always on but you can overlay the border with other layers (eg sprites) or make the border the transparent colour so it becomes transparent.
The Timex hi-res mode is strictly bound to that BRAM 5 bank (or was it 4?),? If you would use Timex mode and also use the shadow-bit of 128k, will it not switch to bank 7 (for the price of losing Layer2)? Or the Timex is hard-wired to the bank 5 and ignoring the state of shadow-buffer bit of 128k machine?
The Timex screens should move to bank 7 although I haven't tried it.

We recently found that ULA bank 7 access suffers the same problems as Layer 2 access in that you can't run above 7MHz when either the shadow screen is active or layer 2 is active. So the auto-slowdown also applies when the shadow screen is active. There is a difference between layer 2 and the shadow screen in that the slowdown only applies to the vertically non-clipped area of layer 2 but it applies to the full area of the shadow screen because the ULA module is always actively fetching from memory even outside its clipping area.
Overall there are many different bits in the machine selecting contradicting features, like LoRes vs Timex, etc.. I would love to see some technical docs listing priorities of those, i.e. which setting wins in the end, if they collide.
LoRes replaces the ULA. The lores scroll registers apply to the ULA screen as well but for the ULA, currently only hardware character scrolling horizontally is possible. Vertical scrolling is per pixel on ULA screens.


Who is online

Users browsing this forum: No registered users and 1 guest