archive.worldofdragon.org

How do your palette mappings compare to running XRoar with "-machine-palette dragon64"? That palette was created by measuring actual output voltages from the VDG on a running machine. If it seems close, maybe you could derive "precise" vaues from there.

robcfg wrote: ↑Sun May 12, 2019 10:57 am Meanwhile, as you can compile it, I suggest you just copy the old palette values on top of the new ones and compile it again.

Thnaks, i already recompiled it.
I rolled back to MAME 208 (22 April) with the latest 2 fixes.
which also has the incorrect NTSC artifacting on PAL machines.

With old and cheap TV modulators, i am sure there will be discrepances in colour palettes between machines.
If cost wasn't an option in prodution at the time, i am sure every Dragon would have had true sharp RGB output.

Please consider tweaking Black & White (dark/light grey).
so i do not need to re-compile with every new release.
And yes please, show me all the files you changed.

sixxie wrote: ↑Sun May 12, 2019 11:37 am How do your palette mappings compare to running XRoar with "-machine-palette dragon64"? That palette was created by measuring actual output voltages from the VDG on a running machine. If it seems close, maybe you could derive "precise" vaues from there.

If I push up the contrast on Gimp, I can get close to your colours.

Did you measure the chip output directly? I ask because then you have some resistors and the circuitry that generates the composite signal output, so I guess the signal is greatly modified from the source.

I got my colours from a composite video capture device, capturing areas and averaging the colours. I know it's far from perfect but the colours are very close to what I see on the capture device and on my tv.

Please consider tweaking Black & White (dark/light grey).
so i do not need to re-compile with every new release.
And yes please, show me all the files you changed.

Here are my modifications:
https://github.com/mamedev/mame/pull/4980/files

The only files changed are /src/devices/video/mc6847.h and /src/devices/video/mc6847.cpp.

It would be nice to be able to specify a custom palette, for example. But I feel that would be part of a larger discussion.

robcfg wrote: ↑Sun May 12, 2019 2:38 pm It would be nice to be able to specify a custom palette, for example. But I feel that would be part of a larger discussion.

I'm trusting your judgement on the colours as I have nothing to compare them with, they should match the real hardware which is what you've done, though I'm not sure how good a reference point a composite output would be. If XRoar uses measured output then there's probably still room for improvement.
I was actually surprised at how quickly your changes were merged, as I was expecting some internal discussion beforehand. As the MC6847 is only used in a handful of machines it was probably considered relatively safe.

A custom palette in MAME is a definite no. I'm not even sure about how valid the existing artifacting options are, a real MC6847 doesn't have a switch for these options.

The XRoar values for that palette (not used by default) were measured at the output of the chip, yes.

But you absolutely can't apply one set globally - the reason those values are so different from the data sheet "ideal" outputs are because in a Dragon, the loading on the output is quite significant. I remember taking similar measurements on a (PAL) CoCo, and they were a lot closer to the "ideal" (which was also obvious from the display).

On top of that, artifacting and colour blend happens on the tv set and not on the video chip or the computer.

The good thing is that anyone can contribute new values to the source code and I consider this a first step.

with one of these NEW updates, the extension slot command-line got broken.

this used to boot the dragon32 machine without DDOS.
mame dragon32

and required this to turn it on.
mame dragon32 -ext dragon_fdc

it's always enabled now.

.mad. wrote: ↑Mon May 13, 2019 10:37 am with one of these NEW updates, the extension slot command-line got broken.

this used to boot the dragon32 machine without DDOS.
mame dragon32

and required this to turn it on.
mame dragon32 -ext dragon_fdc

it's always enabled now.

DDOS has been the default cartridge for many years now, nothing has changed.

Yes, but now the ddos rom is mandatory and the system will not boot without it.

robcfg wrote: ↑Mon May 13, 2019 1:13 pm Yes, but now the ddos rom is mandatory and the system will not boot without it.

The dragon32 driver has specified dragon_fdc as the default ext device for at least 4 years. I tried mame dragon32 in the 0.209 release and DDOS loaded, which version is it not the default? To start without DDOS you could mame dragon32 -ext pak, which is essentially an empty cartridge.