#323 ULAplus interface

[Sergio Baldoví]

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:

• Code has been modernized upto revision r5074.
• Code has evolved from a Spectrum SE mode to a separate interface because ULAplus will soon be a real replacement for 48k models.
• Support for GTK+ and win32 UIs.
• Support for reading/writing to SZX snapshots.
• Removed registerport_read as it is not defined in the current specification.
• By default the whole palette is black and it is initialized to black on reset.
• Don't invalidate display because of flash attribute.
• Widgets menus are drawn with the standard palette and don't use the current ULAplus palette. It is the same with keyboard help.
• As Philip suggested, ulaplus_dataport_write() refreshes display only on changes. However refreshing the whole display is inefficient and essentially wrong as it breaks palette cycling (see multicolour demo).
• As Fred suggested, remove clut_update_palette() and uidisplay_plot8_64() by using a pre-computed palette of 256 colours.

Still pending:

• Fix dirty display on palette cycling.
• Save/load screen dumps.
• Support more UIs. Currently unsupported UIs are fb, svga, wii and xlib.
• Check non-sinclair machines, i.e., timex and pentagon.
• Perhaps allow to load pre-configured palettes.

[Sergio Baldoví]

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:

• MSX2 computers (VDP V9938 + Screen 8/graphics 7). The scene knowledge state a complex method ([1]).
• ZX-Uno use a 3-bits DAC ([2]).
• VGA built-in output of the Digilent Inc. NEXYS 2 FPGA board (i.e., ZX-Badaloc) use a 2-bits DAC ([3]).
• The Uzebox gaming console use a 2-bits DAC ([4]).
• Palette 4 of the IBM PGC use a 4-bits DAC ([5]).
• SGI Indy 8-bit XL graphics (newport) use a complex method ([6]).

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

[Sergio Baldoví]

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:

• Use hmlhmlhm pattern (255/7 levels) for 3-bits to 8-bits conversion. Thanks, Stuart.
• Keep Bbb scheme for now.
• Simplified expressions for extracting colour components. Thanks, Stuart.
• Fix multicolour, HAM256 and HAM8x1 glitches.

Outstanding bits are:

• Refactor palette handling on ui_xxxdisplay
• Improve display routines
• FMF movie recording ULAplus movies
• Save/load screen dumps.
• Support more UIs. Currently unsupported UIs are fb, svga, wii and xlib.
• Check non-sinclair machines, i.e., timex and pentagon.
• Perhaps allow to load pre-configured palettes.

We should likely do a branch to keep track of changes individually.

[Fredrick Meunier]

Good catch on copy_critical_region().

Check non-sinclair machines, i.e., timex and pentagon.

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

[Sergio Baldoví]

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?

Mixed screens are not currently supported as settings stored in display_last_screen are being ignored. Thanks for pointing mcleod_ideafix's test.

[Fredrick Meunier]

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:

• Includes the Timex video modes (optional)
• Changes the preferred way of multiplexing the 2-bit blue value to obtain a 3-bit blue value.
• Adds 256 greyscale support (optional)
• Deprecates HSL and CMYK support

[Sergio Baldoví]

There is an updated ULAplus spec

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)

[Sergio Baldoví]

There are a lot of things to do. I've just created branch 2014-09-07-ulaplus in [r5092].

[Sergio Baldoví]

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

[Fredrick Meunier]

Thanks Sergio, did you mean to attach the spec text?

[Sergio Baldoví]

Spec attached for further reading until it is available online. Thanks.

[Fredrick Meunier]

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).

[Sergio Baldoví]

I've just checked in a simplification of the display handling in this branch under [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.

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).

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

[Fredrick Meunier]

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).

[Fredrick Meunier]

Thanks, addressed the regression in [r5296] which standardises the use of the ULAplus palette when it is the ULA in use in a machine.

[Stuart Brady]

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.

[Fredrick Meunier]

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).

[Sergio Baldoví]

I'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.,

OUT 48955,66: OUT 65339,1

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:

• The use of a greyscale palette could be stored as a flag.
• Video mode could (should?) be stored as another field, but I guess that should break existing software. There is enough space (6 bits) in the flags byte, but IMO that looks ugly.

Maybe we should ask Andrew about the current (and future) status of this block.

[Fredrick Meunier]

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!

[Sergio Baldoví]

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) :

fuse --ulaplus

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):

fuse --no-ulaplus

Loading a snapshot with ULAplus active has the same effect than the previous point (WRONG):

fuse --no-ulaplus ulaplus.szx

[Sergio Baldoví]

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:

• Loading a different hi-res mode when there is currently another hi-res mode has no effect.
• Loading a hi-colour mode when there is currently a hi-res mode has no effect.

[Fredrick Meunier]

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.

[Sergio Baldoví]

I'm not sure what is the best approach, maybe using writeport_internal worth a try, but that could be stopped by a breakpoint.

[Fredrick Meunier]

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.

[Sergio Baldoví]

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.

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 was thinking something more like a machine->set_display_mode() that is implemented per machine to abstract away the SCLD/ULAplus differences?

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?

[Sergio Baldoví]

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.