These patches try to emulate the ULAplus interface, based on previous work by Gilberto Almeida available in [patches:#209], [patches:#210], [patches:#211], [patches:#212] and [patches:#213].
Changelog:
Still pending:
Feature Requests: #95
Patches: #209
Patches: #210
Patches: #211
Patches: #212
Patches: #213
Wiki: Fuse 1.2 Release Plan
Wiki: Fuse 1.2.2 Release Plan
Wiki: Fuse 1.3.0 Release Plan
Wiki: Fuse 1.3.1 Release Plan
Wiki: Fuse 1.3.2 Release Plan
Wiki: Fuse 1.3.3 Plan
Wiki: Fuse 1.3.4 Release Plan
Wiki: Fuse 1.3.5 Release Plan
Wiki: Fuse 1.3.6 Release Plan
Wiki: Fuse 1.3.7 Release Plan
Wiki: Fuse 1.3.8 Release Plan
Wiki: Fuse 1.4.0 Release Plan
Wiki: Fuse 1.4.1 Release Plan
Wiki: Fuse 1.5.0 Release Plan
Wiki: Fuse 1.5.1 Release Plan
Wiki: Fuse 1.5.2 Release Plan
Wiki: Fuse 1.5.3 Release Plan
Wiki: Fuse 1.5.4 Release Plan
Wiki: Fuse 1.5.5 Release Plan
Wiki: Fuse 1.5.6 Release Plan
Wiki: Fuse 1.5.7 Release Plan
Wiki: Fuse 1.6.0 Release Plan
Wiki: Fuse Next Release Plan
Miguel Angel dissertation has spotted that my interpretation about BbB scheme fixing blue-ish tints is a subjective appreciation. AFAIK there is not clearly a best scheme.
From a hardware point of view there are several methods for outputting the blue component:
Unfortunately, this fragmentation also happens in software ([7]) and emulators ([8]), so there is not currently a standardised palette.
[1] MSX2, page 12
[2] ZX-Uno, page 1
[3] NEXYS2, page 10
[4] Uzebox, page 7
[5] IBM PGC, page 24 and 177
[6] SGI Indy, page 6
[7] Image2ULAplus
[8] emulators
I've gone in depth into copy_critical_region() and seems that it refresh the display region between the previous beam position and the current beam position. In this case, the ULAplus palette should be updated after display_update_critical(). That fix the visual glitches from previous posts.
I've attached a new patch:
Outstanding bits are:
We should likely do a branch to keep track of changes individually.
Good catch on copy_critical_region().
For this, mcleod_ideafix's mode splitting test program doesn't seem to work on the TC2048. Oddly it is the conventional Timex modes that seem to be failing - maybe switching into ulaplus mode too soon?:
http://www.atc.us.es/~rodriguj/modesplit_pussyonboots.tap
http://www.atc.us.es/~rodriguj/splitmode_clone.jpg
http://www.atc.us.es/~rodriguj/splitmode_specemu_vs_clone.jpg
Mixed screens are not currently supported as settings stored in display_last_screen are being ignored. Thanks for pointing mcleod_ideafix's test.
There is an updated ULAplus spec at http://www.zxshed.co.uk/sinclairfaq/index.php5?title=ULAplus, version 1.1 adds the following and has changes to the blue mapping:
Hopefully that closes the arguments against Bbb scaling scheme.
And now there is a version 1.2 with:
- Port mirroring for Timex video resolution (optional)
- Planar modes (optional)
There are a lot of things to do. I've just created branch 2014-09-07-ulaplus in [r5092].
Related
Commit: [r5092]
Andrew Owen wrote:
Hi,
I'm the author of the ULAplus spec. I've reverted the spec to version 1.1 on the basis that this is the version implemented in the ZX-One FPGA core, the ZX-Uno project, and the ZX Spectrum Vega. I now consider this to be set in stone with no further changes. The main change from the older version is that there is now a fixed palette of 256 colors which is a superset of the standard Spectrum palette. This was done for ZXDS. As the FAQwiki is currently borked, here's the text. Let me know if there are any questions.
Cheers!
-Andrew
Thanks Sergio, did you mean to attach the spec text?
Spec attached for further reading until it is available online. Thanks.
I've just checked in a simplification of the display handling in this branch under [r5294].
I think that this interface should be disabled for Timex machines (I don't believe there is any real prospect of a real Timex SCLD replacement being implemented in reality and the resultant timings would be hypothetical). For similar reasons, I don't think that it should be enabled for Pentagon or Scorpion machines.
I think we should however implement the Timex-like port #FF and the optional mirror of Timex port #FF behaviour in the ULAplus implementation.
I think our ULAplus interface should be defined for the 48k, Sinclair 128k and not for the Amstrad models (as again there is no real prospect of a genuine implementation for real hardware while ULAplus has been implemented in a drop-in solution to add to Sinclair 48K machines and separately in clones which probably have their own unique timing behaviour).
Related
Commit: [r5294]
Thanks, looks really neat. Unfortunately, there is a regression with test_border.szx [1], dirty pixels may not be refreshed when enabling ULAplus and the current paper is the same value than the ULAplus colour index.
The attached patch is a proof of concept. What do you think about packing display_chunk_type and ULAplus status in a byte? There could be a frame splitted with different screen modes, so storing the chunk mode seems appropriate.
Sounds fine to me, but will FPGA implementations count as actual hardware? ZX-Uno is on the way...
[1] https://sourceforge.net/p/fuse-emulator/patches/323/#d7a1
Related
Commit: [r5294]
Hi Sergio,
I'm on my phone so quoting will be non-existent :)
The regression will be removed when we use a single palette for ulaplis when it is disabled or enabled. I haven't committed this change yet as I have not quite decided whether the change is better in a form that will break fb, xlib, svgalib or not.
For what counts as being worth emulating I think there are machines which are part of the Sinclair spectrum history and should be preserved on that basis (original machines, NTSC variant, timex clones, Amstrad models). For clones I think it depends on there being a level of interest in the community, a distinct software base and clearly being a close relative of the spectrum (I don't see the point in adding something that is modified to the point it is a distinct machine like a msx style machine or an Amiga-like with a z80) etc. Russian clones are clearly in, modern clones with a handful of users and no significant distinct software have a bigger case to make.
If zx-uno attracts a user base and distinct software I think we should consider adding support for it. In hindsight I think adding the spectrum se clone was a mistake as there are neither users or a distinct software base.
I also think that ulaplus is marginal (interest in supporting it in new software has dropped off sharply, pages have limited/no maintenance etc).
Thanks, addressed the regression in [r5296] which standardises the use of the ULAplus palette when it is the ULA in use in a machine.
Related
Commit: [r5296]
ULAplus emulation should be added for the ZX Spectrum SE, for which combining of ULAplus and Timex modes will be needed. This really is worth supporting, although I'm afraid I shall have to ask you to take my word for it.
I have a strong opinion that we shouldn't add support for non-existent hardware which aligns with Phil's previously expressed opinion (e.g. see [feature-requests:#13]).
When a SE-style machine is created that has ULAplus support, we can check timings and other implementation details against the real implementation for accuracy and can consider creating a new machine geared towards the implementation details of this hardware (e.g. I don't believe any such machine will be created with timings aligned with the Timex SCLD implementation).
Related
Feature Requests:
#13I've given a go to last changes ([r5303]) and have spotted some bugs...
HIRES and HICOLOUR modes are broken in Timex machines, the flashing pixels don't work properly. As far as I have seen, the new timex_video mode is set after reseting the machine and initializing the display, so display_set_mode() set the wrong display handler. The patch timex.diff reverts the previous behaviour on Timex machines.
ULAplus could change the video mode with the register port (not data port), so the video mode should be set with the value: ulaplus_current_register & 0x3F.
Moreover, ulaplus_dataport_write() can't handle the case where ULAplus is enabled and video mode is set in the same operation, i.e.,
The patch videomode.diff fix these issues. BTW, this is another demo for HICOLOUR mode:
http://opencores.org/websvn,filedetails?repname=zx_ula&path=%2Fzx_ula%2Fsoftware%2Fulaplus_demos%2Fslideshow_ulaplus_timexhicolor_famous_pictures.tap
In the other hand, the ULAplus block in SZX format doesn't fully support the latest specification:
Maybe we should ask Andrew about the current (and future) status of this block.
Related
Commit: [r5303]
Thanks Sergio. This is my second attempt at replying as sourceforge ate my first go.
I've tried to rationalise the mode setting and fix the Timex breakage a bit differently in the attached patch - do you see any improvements from here?
Thanks for the pointer to the demo, I think these are the best ULAplus pictures I've seen.
I've asked Andrew what his opinion is on the SZX block - my gut feel is that we should have a byte for the mode group (ULAplus palette enabled/greyscale enabled), effectively the chFlags byte. There should be a second byte for the mode group selection byte/video mode selection byte (also set by writes to port #ff).
I've committed the videomode.diff as [r5317], thanks!
Related
Commit: [r5317]
Yep, that fixes the video modes on original Timex machines.
There are also side effects with the filters and main window size, e.g.,
Starting with ULAplus active, the main window is 2x and the Timex Half filter is available (OK) :
Starting with ULAplus disabled and enabling ULAplus by hand, force a machine reset but main window is 1x and the Timex Half filter is not available (WRONG):
Loading a snapshot with ULAplus active has the same effect than the previous point (WRONG):
I've attached a proposal for reading SCR files with an ULAplus palette, basically, set ULAplus mode if the peripheral is available and switch to a suitable normal/hi-colour/hi-res mode.
I've also fixed (hopefully) some issues with Timex display modes:
Looks reasonable to me.
It would be nice if we had further abstracted the display mode setting so that the screenshot code didn't have to try to talk directly to the ULAplus and SCLD implementations.
I'm not sure what is the best approach, maybe using writeport_internal worth a try, but that could be stopped by a breakpoint.
I was thinking something more like a machine->set_display_mode() that is implemented per machine to abstract away the SCLD/ULAplus differences? Anyway not compulsory for now, just a nice to have.
Last edit: Fredrick Meunier 2015-10-09
So you are thinking on these layers:
UI -> machine -> SCLD | ULAplus -> display
I guess that would help if we ever expand the peripherals that manage the display (Spectra?).
I've factored out ulaplus_set_status() to hide ULAplus internals and machine_set_display_mode() to abstract peripheral handling. IMO there is no need to use the fuse_machine_info struct unless we do a major refactoring.
But I find display_set_mode (sinclair/timex/pentagon) and machine_set_display_mode (standard/hi-res/hi-col) naming slightly confusing. The former set a screen handler/type and the later set a mode that will be interpreted by the current handler. Opinions?
This patch fixes PNG write support and does an initial palette refactoring, i.e., unify spectrum palette between display code, PNG handling and SVG capture.
UIs still use alternative palettes with colours (generally) packed in uint32_t for faster updates in the back buffer screen. It's not trivial unpacking the colour components (especially with < 24bpp), and I don't like the idea of limiting the portability of SDL UI. So currently there are 4 palettes (unpacked colour, unpacked b/w, packed colour, packed b/w) per hardware device.