Exported formats

Contents

Export to JPG

ZX81_logo.jpg

The created image can also be saved in normal JPG format, although this is not the main purpose of the program. However, it can be very useful if we want to compile a documentation or presentation from it (even here now), or if we just want to share our work on social media.

Image parameters:

Size including frame is 528*400 pixels.
512*384 pixels without frame.
Bit depth 8 bits.

Export to database (normal)

ZX81_logo.ZXpic

Let's look at the simple image above as an example.

If you name it "ZX81_logo", it will be saved as "ZX81_logo.ZXpic".

To open the file, you can use, for example, "Noteped" or any other program that can open txt files.

Opening the file, we can see a familiar format. Once you've selected the entire file and copied its contents into the Assembly Editor, you're ready to use.

The reference name (memory address) of the database table is "PIC_Name". If you use multiple images, I recommend renaming the "Name" section. You can even get "Logo", "Title", "GameOver" or a simple serial number.

After that, the data lines starting with "db" follow. Their number of pieces is the same as the lines of the ZX81 image, i.e. it contains 24 pieces and 32 data per line, separated by commas, stored in hexadecimal format. They store a total of 24*32, i.e. 768 characters of data. Since this takes the same number of bytes from the ZX81's (small) memory, it is not a good choice when writing many images or large programs.

Export to database (compessed)

ZX81_logo_Compressed.ZXpic

This is nothing but the image above in compressed form. There is no question that this is worth using.

The first row is similar to the previous one. Its role and use can be the same as what I wrote above. However, the data table was replaced by two rows. If you look closely, not only the zeros have disappeared, but also the consecutive data has changed.

The compression is based on the Run-Length Encoding (RLE) principle, but an even more efficient version, thanks to the fact that there are only 128 different characters, so the data to be compressed is only 7 bits. This saves an additional 1 byte in each compressed section.

Decoding process:

1. Sets the character counter to 768.
2. Scans a data and converts it to a screen character.
3. It examines the 7th bit of the read data, i.e. it is greater than 127.
4. If not, the created screen character is pushed to the screen and the character counter is decremented by one.
5. If so, then the next data is read and the character of the screen is written to the screen as many times as the value of the given data. At the same time, the character counter is decremented by one per character.
6. If the character counter is greater than zero, repeat from point 2.

Files structure

The files contain data in a compressed format. Their structure consists of the following two parts. 16 character header + data.

Branding - "[NS]"
Program ID - "ZX81SE"
File type identifier - "PR" (project)
File type version number - "v01"
Data separator - "|"
The data is consecutive, in hexadecimal format, without separators and markers.

Page updated

Google Sites

Report abuse