stefano wrote: ↑Fri May 03, 2024 12:36 pm
test_wrxi_3.p
New version. I tried to mockup a theorical high resolution face symbol.
I also removed the blurred picture, it now shows the flickering/ghosting picture (almost the worst case scenario of a single frame in use).
Looks nice:
Siggi, don't get crazy testing everyting, I think your feedback is already rather good.
No problem:
I'm mostly concerned for the crash reported by Moggy, I suppose the ZXpand provides 32K, it shouldn't crash.
Don't forget: ZxPand has its own eprom (replacing the rom), where the character generator has been replaced by code (chargen in rom only readable during refresh) and the LOAD/SAVE-routine is patched and (afaik) the printer routines are removed ...
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware http://zx81.ddns.net/ZxTeaM
Wow, on the photo it looks fantastic compared to the standard rez on the right !
It is probably flickery, but it is worth the effort of a specific library.
@nollkolltroll, I'll look at your code. How did you address the phase issue?
EDIT:
I must apologise, I totally forgot about that post.
Are the time I didn't notice that my gray-scale attempts in WRX mode were poor because of the interlaced rate picture.
I was using an no-even frame counter.. It took me several years understanding this!
Now the gray-scale driver is fixed and flickers like hell!
In the meantime I could have found a way to sort out the timing for 35 byte rows without using a stack based RET chain.
This could increase the X resolution to 280 pixels, I think I'll try to put it all together, but it is that sort of tricks which looks sound on an emulator and doesn't work in the real life.
The zxpand should be supported, this new driver is not much different than the usual z88dk one.
Some problems could now arise with the 35 bytes X line mode, it uses a couple of different instruction in the row pivot string, which in my information is run in a ghosted position (bit a15 set) AND with some sort of hardware masking?
Stefano, my code generates 2 different vsyncs, one for odd fields and one for even fields. That makes it easy to know which phase you're in and which part of the graphics should be used.
A delay of half a line before the odd vsync shifts the field to start between the lines of the previous field.
The old BW analog TV does not know which field is drawn, it simply draws where the beam-timers are positioned. That is why I could make a 3-lace graphics mode as a proof of concept. https://www.sinclairzxworld.com/viewtop ... 068#p33068
NOTE: I might have odd/even swapped around, memory fails me.
Even vsync:
generate vsync for 4 lines
Odd vsync:
NOP-delay for half a line
generate vsync for 4 lines
