.SCR file structure

[fiorefr73]

I made a search in the forum but wasn't able to find this information.
Can someone point me to a definition of the .SCR file structure?
I found out that the first 128 byte are composed by a standard AMSDOS Header:

Byte 00: User number (value from 0 to 15 or #E5 for deleted entries)
Byte 01 to 08: filename (fill unused char with spaces)
Byte 09 to 11: Extension (fill unused char with spaces)
Byte 16: first block (tape only)
Byte 17: first block (tape only)
Byte 18: file type (0:basic 1:protected 2:binary)
Byte 21 and 22: loading address LSB first
Byte 23: first block (tape only?)
Byte 24 and 25: file length LSB first
Byte 26 and 27: execution address for machine code program LSB first
Byte 64 and 66: 24 bits file length LSB first. Just a copy, not used!
Byte 67 and 68: checksum for bytes 00-66 stored LSB first
Byte 69 to 127: undefined content, free to use

But what about the rest?

Thanks in advance for your help!

[roudoudou]

SCR files are binary files. There is no header (amsdos header is read but loaded only in system area)
OCP Art studio SCR files do not have a proper loading adress, you must specify destination LOAD"OCP.SCR",&C000
But if you save the current screen in Basic SAVE"MYSCR.SCR",B,&C000,&4000 you can reload without destination adress => LOAD"MYSCR.SCR"
The SCR extension has no purpose, you can use any extension (except BAS i guess)

[fiorefr73]

Sorry but I don't understand your sentence "There is no header (amsdos header is read but loaded only in system area)". 

In this SCR file there is the AMSDOS header (see below screenshot).
I understand that the system can ignore it and just read the remaining information to be loaded on screen, but in the file structure there is the header.

I would like to know how to manage the remaining information to be able to manipulate the SCR file outside of the Amstrad CPC.
I guess that, based on the size, they are just 2 pixel colors contained in one single byte...

[andycadley]

Is it not just a raw dump of the display memory?


Art packages like OCP might attach more information like palette entries and mode

[roudoudou]

the system take care about the header (default loading adress, exact size of the file to load in memory) but as a user, you wont see anything about this header
if you want to make/edit a screen outside the CPC, just skip the header to do your math and poke screen adresses
do you know how the memory is displayed by the CRTC ?

[fiorefr73]

Yes, that's exactly what I would like to do! 
No, I don't know how the memory is displayed by the CRTC.
Can you point me to the right direction? 

[fiorefr73]

I found this one: https://neuro-sys.github.io/2019/10/01/amstrad-cpc-crtc.html
I will study it, hopefully it will give a sense to the remaining bytes. 

[roudoudou]

I found this one: https://neuro-sys.github.io/2019/10/01/amstrad-cpc-crtc.html
I will study it, hopefully it will give a sense to the remaining bytes. 

yes, check the "Character adressing section" you will have the secret revealed

[GUNHED]

Byte 64 and 66: 24 bits file length LSB first. Just a copy, not used!

Only FutureOS has a 24 bit file-length, other CPC OS use 16 bit file-length (see FutureOS manual).