No problem! I just need a short description and one sample to test it with.Einar Saukas wrote: ↑Sat Jul 25, 2020 12:30 am The ZX81 screen only contains 256x192 pixels without attributes, so nothing can be lost in a conversion to SCR (using black INK/white PAPER). Although it would be even better to store ZX81 screens as a simple sequence of 24x32=768 bytes (one byte for each character on screen). Perhaps we can convince @moroz1999 to support this new format?
Screenshots
Re: Screenshots
Re: Screenshots
Not completely true - take a look at https://spectrumcomputing.co.uk/entry/32034 - it generates a 320x240 display on ZX81 - also there a few other demos that goes beyond the 256pixels width. I know it's really edge cases, just to get the facts correct4thRock wrote: ↑Sat Jul 25, 2020 2:53 pm For monochrome machines a 2 color PNG works perfectly and is easier to get. Thinking about the ZX80 and the Jupiter Ace
And don't forget that these machines also have a border area. If I'm not mistaken it's always white on the ZX80 and ZX81 and always black on the Jupiter Ace.
/T
https://api.zxinfo.dk/v3/ - ZXDB API for developers
zxinfo-file-browser - Cross platform app to manage your files
https://zxinfo.dk - another ZXDB frontend
zxinfo-file-browser - Cross platform app to manage your files
https://zxinfo.dk - another ZXDB frontend
Re: Screenshots
Ideally .s80/s81 should be generated by emulator, in case the goal is to achieve 100% preservation. Converting from BMP/SCR can result in misinformation, not seen by the eye. For example print chr$ 126 gives a question mark, matching against zx81 charset would give the vaule 15 - which was not originally intended in this case.Einar Saukas wrote: ↑Sun Jul 26, 2020 2:47 am Exactly.
We will need 2 formats, that could be named as follows:
- Format ".s80": a sequence of 768 character codes from the ZX80 charset
A converter should take a 256x192 monochrome image in BMP or SCR format, matching each 8x8 area against the corresponding charset. If any 8x8 area doesn't match any standard character, the image would be considered invalid thus abort with an error without converting anything. Ideally the converter should also be able to do the opposite, i.e convert a file with extension ".s80" or ".s81" to BMP or SCR.
- Format ".s81": a sequence of 768 character codes from the ZX81 charset
Just something to consider.
/T
https://api.zxinfo.dk/v3/ - ZXDB API for developers
zxinfo-file-browser - Cross platform app to manage your files
https://zxinfo.dk - another ZXDB frontend
zxinfo-file-browser - Cross platform app to manage your files
https://zxinfo.dk - another ZXDB frontend
- Einar Saukas
- Bugaboo
- Posts: 3097
- Joined: Wed Nov 15, 2017 2:48 pm
Re: Screenshots
Not really. When you print a non-printable character like CHR$ 126, the ROM puts value 15 into screen memory. For non-hires screens, the method I described should produce exactly the same result as the emulator.kolbeck wrote: ↑Fri Jul 31, 2020 8:48 am Ideally .s80/s81 should be generated by emulator, in case the goal is to achieve 100% preservation. Converting from BMP/SCR can result in misinformation, not seen by the eye. For example print chr$ 126 gives a question mark, matching against zx81 charset would give the vaule 15 - which was not originally intended in this case.
Although I agree that generating these files directly from emulators would be better!
- Einar Saukas
- Bugaboo
- Posts: 3097
- Joined: Wed Nov 15, 2017 2:48 pm
Re: Screenshots
Good point!kolbeck wrote: ↑Fri Jul 31, 2020 8:29 am Not completely true - take a look at https://spectrumcomputing.co.uk/entry/32034 - it generates a 320x240 display on ZX81 - also there a few other demos that goes beyond the 256pixels width.
Therefore I suggest:
- Format .s80 and .s81 for standard non-hires ZX80 and ZX81 screens
- Format SCR for hires screens with regular size
- Format PNG for other screen sizes
Re: Screenshots
Thanks for the info it's important. On this case the .scr is just cropping the image, another format would be better (as Einar mentioned).kolbeck wrote: ↑Fri Jul 31, 2020 8:29 am Not completely true - take a look at https://spectrumcomputing.co.uk/entry/32034 - it generates a 320x240 display on ZX81 - also there a few other demos that goes beyond the 256pixels width. I know it's really edge cases, just to get the facts correct
All these titles are marked as ZX81 Hi-res: WRX , right ?
Meanwhile, you might have noticed that ZX80 and ZX81 titles now display a white border by default.
There's also progress on displaying different border colours (using the existing .SCR and .GIFs), yet more work is needed.
This so that you guys know that this discussion is helpful and things are progressing in the background.
- Einar Saukas
- Bugaboo
- Posts: 3097
- Joined: Wed Nov 15, 2017 2:48 pm
Re: Screenshots
Currently all screenshots have black border by default, except ZX80/ZX81 screenshots that have white border by default.
However this information is configurable. For instance, the running screen for 10 OTHELLO has blue border, the running screens for Ad Lunam Plus have white border.
If anyone notices anything else that needs fixing, please help to fill this spreadsheet!
Re: Screenshots
Added a few more games to the spreadsheet!
- Einar Saukas
- Bugaboo
- Posts: 3097
- Joined: Wed Nov 15, 2017 2:48 pm
Re: Screenshots
First attempt at converting ZX81 screen dump in BMP to ASCII / ZX81 Character set.
Left is the ASCII (Unicode) Rendering, and Right is the BMP as produced by EightyOne. There are only a few characters not easily available for printing, but that's not important. The program also produces a 768 bytes file, containing values from 0-192 representing the ZX81 characters found.
/Thomas
Left is the ASCII (Unicode) Rendering, and Right is the BMP as produced by EightyOne. There are only a few characters not easily available for printing, but that's not important. The program also produces a 768 bytes file, containing values from 0-192 representing the ZX81 characters found.
/Thomas
https://api.zxinfo.dk/v3/ - ZXDB API for developers
zxinfo-file-browser - Cross platform app to manage your files
https://zxinfo.dk - another ZXDB frontend
zxinfo-file-browser - Cross platform app to manage your files
https://zxinfo.dk - another ZXDB frontend
Re: Screenshots
Found an interesting reference to timings of non-interlaced PAL:
http://blog.retroleum.co.uk/electronics ... -voltages/
http://blog.retroleum.co.uk/electronics ... -voltages/
- Einar Saukas
- Bugaboo
- Posts: 3097
- Joined: Wed Nov 15, 2017 2:48 pm
Re: Screenshots
Each S81 file should have exactly 24 rows x 32 columns = 768 bytes (one byte for each character on screen), stored from left to right, top to bottom. The bit 6 of each byte should always be zero (otherwise the file is considered invalid), therefore valid values for each byte are 0..63 or 128..191. Each byte value corresponds to a character image from the ZX81 charset. The pixel images for the first 64 characters are stored in the standard ZX81 ROM starting at address $1E00. The other 64 characters are exactly the same characters, but inverted.moroz1999 wrote: ↑Sun Jul 26, 2020 11:04 pmNo problem! I just need a short description and one sample to test it with.Einar Saukas wrote: ↑Sat Jul 25, 2020 12:30 am The ZX81 screen only contains 256x192 pixels without attributes, so nothing can be lost in a conversion to SCR (using black INK/white PAPER). Although it would be even better to store ZX81 screens as a simple sequence of 24x32=768 bytes (one byte for each character on screen). Perhaps we can convince @moroz1999 to support this new format?
The color is always black INK on white PAPER. The resulting image size should be 256 pixels wide by 192 pixels high, without border.
Here's a sample S81 file and the corresponding SCR file. Also I already added a S81 screenshot to this page so it can be used for testing.
Thank you!
- Einar Saukas
- Bugaboo
- Posts: 3097
- Joined: Wed Nov 15, 2017 2:48 pm
Re: Screenshots
The S80 format is identical to S81, except using the ZX80 charset. The pixel images for the first 64 characters are stored in the standard ZX80 ROM starting at address $0E00.
Re: Screenshots
I guess I’m far too late to contribute much, but such as it may matter: high-res modes can not only be much larger than 256x192, but also needn’t be character-based. A full linear frame buffer is an option with most expansion packs — as long as they respond to the refresh cycle (despite almost universally being SRAM) then you can work around the intended character-map entirely.
The built-in 1kb can do direct-framebuffer graphics, but only a very small amount of them.
Since sync is also programmatic, a ZX81 can also output interlaced video, though I’m aware of only one demo that does.
Many of the early high-res displays use the character mapping in principle but continually reset the in-character counter so they’re using 8x1-sized characters.
Also in a 1kb machine the video buffer is often a lot smaller than 768 bytes, as a HALT can end any line early.
The built-in 1kb can do direct-framebuffer graphics, but only a very small amount of them.
Since sync is also programmatic, a ZX81 can also output interlaced video, though I’m aware of only one demo that does.
Many of the early high-res displays use the character mapping in principle but continually reset the in-character counter so they’re using 8x1-sized characters.
Also in a 1kb machine the video buffer is often a lot smaller than 768 bytes, as a HALT can end any line early.
- Einar Saukas
- Bugaboo
- Posts: 3097
- Joined: Wed Nov 15, 2017 2:48 pm
Re: Screenshots
That's OK, we are also considering the possibility of other ZX81 screen layouts, as discussed here:
viewtopic.php?p=42698#p42698
Anyway I'm glad you mentioned it, because I just noticed that SpectrumComputing renderer is still unable to display S81 images, as seen here:
https://spectrumcomputing.co.uk/entry/3 ... /ZINVADERS
Are there any plans to support the S81 format? Or should we store standard ZX81 images as SCR instead?
viewtopic.php?p=42698#p42698
Anyway I'm glad you mentioned it, because I just noticed that SpectrumComputing renderer is still unable to display S81 images, as seen here:
https://spectrumcomputing.co.uk/entry/3 ... /ZINVADERS
Are there any plans to support the S81 format? Or should we store standard ZX81 images as SCR instead?