Russian ATM Screen Preservation (ZX-Evo)

[PeterJ]

After seeing posts from [mention]DenisGrachev[/mention] here:

viewtopic.php?t=2158

and from [mention]Alone Coder[/mention] here:

viewtopic.php?p=37916#p37916

I thought I would start looking at taking screens for the existing ATM2 titles in ZXDB, and start working through the new ones.

Firstly, I have to say I know very little about these machines.

I downloaded the 2014 competition results from here:

http://alonecoder.nedopc.com/zx/ti5_pack.zip

This download includes the Unreal emulator, which takes some getting used to but finally I managed to get games running.

This is Zooming Secretary

https://spectrumcomputing.co.uk/index.p ... 6&id=30127



Couple of questions...

The screen output from Unreal seems to be a .PNG file. Is it possible to output a screen format that is more preservation friendly so I can use the tools from [mention]moroz1999[/mention]?

Are we OK for now with me providing .PNG files?

The screenshot includes the icons on the top left, the FPS etc. Is there a way of outputting without these?

I'm also testing es.spectrum which supports these models.

[Alone Coder]

I fear there is no palette information in Unreal Speccy screenshots.
However, I have the original resources (*.bmp) for this and many other games.

The indicators disappear is you press grey /.

[PeterJ]

Thank you [mention]Alone Coder[/mention],

When you have time, could you upload them to Google Drive or similar for me? Thanks!

[Alone Coder]

https://drive.google.com/file/d/1pEiIln ... sp=sharing

[Seven.FFF]

That link brings up an embedded windows which says:

"You need access
Ask for access, or switch to an account with access."

[Alone Coder]

Maybe now it will work?
https://drive.google.com/file/d/1pEiIln ... sp=sharing

[Seven.FFF]

[mention]Alone Coder[/mention] yes, that is good!

[PeterJ]

Thanks [mention]Alone Coder[/mention],

It looks like ZX-Image does support ATM screens. Just need to find an emulator that exports them.

"atmega" - ATM Turbo 2+ EGA graphics mode. 32128 file containing pixel data and palette.

[moroz1999]

ZX-Image currently supports:
1. BMP files for ZX EVO. It doesn't restrict the palette yet, but I will add it to be sure that we are actually preserving something.
https://zxart.ee/rus/grafika/poisk-po-b ... pe:zxitem/ - some of these are already added into ZX-Art, but really far from collecting them all.
I think that we can produce such BMPs from any other formats like PNG. There is no risk of losing something as long as I add a palette restriction control.

2. "atmega" - ATM Turbo 2+ EGA graphics mode. 32128 file containing pixel data and palette.
This truly has been implemented some time ago, but I don't have any images in this format.
There are some images in ATM's TRD files which can be extracted, but unfortunately they lack the palette data.

There is one more format (hires) which is not implemented yet in ZX-Image because I haven't found any of the samples in this format.

[Alone Coder]

Hires images in .grf format (common for ATM and Profi):
http://alonecoder.nedopc.com/zx/MCX04.zip

[Lethargeek]

2. "atmega" - ATM Turbo 2+ EGA graphics mode. 32128 file containing pixel data and palette.

please not again, every time ATM 16c mode is called "EGA" a cute fluffy kitten dies somewhere

[moroz1999]

please not again, every time ATM 16c mode is called "EGA" a cute fluffy kitten dies somewhere

Please let's not start holy war about naming. I don't care how it's named, I'm using it because it's clear what ATM mode I'm talking about.

[Lethargeek]

please not again, every time ATM 16c mode is called "EGA" a cute fluffy kitten dies somewhere

Please let's not start holy war about naming. I don't care how it's named, I'm using it because it's clear what ATM mode I'm talking about.

Please don't justify spreading of the old marketing misinformation under the pretext of avoiding a holy war. It has nothing in common with the real EGA in both hardware and software aspect. Also calling it just "ATM 16c APA mode" is much more clear in addition to being 100% true.

I really hope it won't be designated in ZXDB as "EGA"

[PeterJ]

On the discussion of the ZX-Evo, does anyone have one of these?

https://www.sellmyretro.com/offer/detai ... card-27537

I've read the English manual, but I would like a SCART cable rather than having to build one myself.

[moroz1999]

I have ZX-Evo as my main ZX, I'm using it almost daily.
I'm using it with modern LCD 50hz compatible monitor through built-in VGA. I haven't used it with RGB, it has a connector on a motherboard, but I'm not sure about how easily it can be connected to cable, never done it.

[moroz1999]

Hires images in .grf format (common for ATM and Profi):
http://alonecoder.nedopc.com/zx/MCX04.zip

Thank you! I will take a look and implement it in Zx-Image, so GRF files from both ATM and Profi could be displayed here on Spectrum Computing and on ZX-Art.
Is there any way to preview them? MCX viewer doesn't seem to open the format or I didn't find how to do it.

[moroz1999]

Alone Coder, one more question to you: I will add the control of BMP palette in ZX-Image, so only the real colors would be stored/processed.

Is this a real palette? If so, I will use it.

1. What should I do if BMP uses a "wrong" color? Should I ignore it and show black instead?
2. I can automatically replace it with the "closest" one from the ZX-Evo palette. But will this be right thing to do? How would such BMP be displayed on a real software? Will some correction be done or it will be ignored?

3. The palette values seem to be designed for linear RGB without color correction. Each of them represent 1/3 of RGB channel intensity: 85, 170, 255. It really makes sense for the linear RGB, but I think they should be gamma-corrected when displayed on PC hardware stack.
So instead of 85, 170, 255 I should display 156, 213, 255. These colors match 1/3, 2/3 and 3/3 of intensity on sRGB. Does that sound right to you? Please advise.

[Alone Coder]

MCX Viewer views .grf if your computer has ATM2+ compatibility. You can also try NedoView in NedoOS, sources: http://nedoos.ru/svn/listing.php?repnam ... e851c9c66f
As for the levels, the regular precision of resistors used in amateur hardware was +-10%, and the gamma curve of TVs was not controlled.
The only thing I remember, we only controlled that colors 0,1,2,3,4,5,6,7 in both bright and nobright went in ascending order in B/W.
I make ATM gfx in 0,85,170,255 (these are not sRGB or any other standard colors, just values in a file). Someone proposed me a palette with 0,93,162,255. Your picture shows 0,80/85,170,255. All three versions fall in +-10% range. So, don't bother. 0,85,170,255 is just regular.

[moroz1999]

MCX Viewer views .grf if your computer has ATM2+ compatibility. You can also try NedoView in NedoOS, sources: http://nedoos.ru/svn/listing.php?repnam ... e851c9c66f

rose.g, snowcat.g, doktorsk.g - are these GRF files or did I take the wrong ones? I've tried it on ZX-Evo with baseconf, but with no luck.
I'll try NedoOS one day, thanks, just not on this week.

As for the levels, the regular precision of resistors used in amateur hardware was +-10%, and the gamma curve of TVs was not controlled.
The only thing I remember, we only controlled that colors 0,1,2,3,4,5,6,7 in both bright and nobright went in ascending order in B/W.
I make ATM gfx in 0,85,170,255 (these are not sRGB or any other standard colors, just values in a file). Someone proposed me a palette with 0,93,162,255. Your picture shows 0,80/85,170,255. All three versions fall in +-10% range. So, don't bother. 0,85,170,255 is just regular.

Ok, thanks. I think I'll make some samples for comparison and then we'll decide what looks better. The problem is that if we use srgb values (0, 156, 213, 255), they would be far from 10% of precision. But these are the numbers if we want to divide palette values by 33% of luminance for srgb gamma-corrected displays.
The picture I have was just some picture I've found in internet, it's not mine. I was just curious if somebody really knows what are the true colors of the ZX-Evo palette.

[Alone Coder]

I don't have a ZX Evo, so I can't test, but I asked Sashapont to test, and he said it works on his ZX Evo.
In UnrealSpeccy in ATM3 mode it also works well.
UnrealSpeccy shows pictures with values 0,96,160,255 (palette "Alone", looks right) or with 0,118,205,255 (palette "Pulsar", looks wrong).

[PeterJ]

Apologies if I have missed something here, but is the only way of getting screens from emulators, as PNG from Unreal at the moment?

[Alone Coder]

You can switch pages in UnrealSpeccy manually to save the actual picture data from memory, but UnrealSpeccy doesn't allow to save the current palette...
Maybe Deathsoft will add a special function if you write him? deathsoft [a] yandex ru

[moroz1999]

I don't have a ZX Evo, so I can't test, but I asked Sashapont to test, and he said it works on his ZX Evo.
In UnrealSpeccy in ATM3 mode it also works well.

https://www.youtube.com/watch?v=Ip0HvPs ... e=youtu.be - strange, this is how it works for me. Same thing if I take Unreal Speccy, select ZX-Evo there and try to load it.

UnrealSpeccy shows pictures with values 0,96,160,255 (palette "Alone", looks right) or with 0,118,205,255 (palette "Pulsar", looks wrong).

Ok, thanks, I'll take 0,96,160,255 then for ATM BMP files.

[Alone Coder]

Maybe it depends on firmware? I see you have BASE&TS.
That's how it works in UnrealSpeccy 0.39.0 from NedoOS repository (the detect also affects 3-color pictures):
https://youtu.be/nE43nwp0V8M
Similar ATM2 detection routine is also present in ACNews and maybe somewhere else. You can open MCX sources in ALASM, the cursor in the source just points to it.

[moroz1999]

It may easily be the problem of firmware indeed. Hires itself is working fine in ANSI viewer, I've selected ATM2 80*25 mode and it worked.
Thanks for examples, now I now how images should look like, I can now implement it in viewer.