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!
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)
Sorry but I don't understand your sentence "There is no header (amsdos header is read but loaded only in system area)". (https://www.cpcwiki.eu/forum/Smileys/SoLoSMiLeYS1/smiley.gif)
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...
Is it not just a raw dump of the display memory?
Art packages like OCP might attach more information like palette entries and mode
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 ?
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? 8)
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. :)
Quote from: fiorefr73 on 13:04, 26 June 20
I found this one: https://neuro-sys.github.io/2019/10/01/amstrad-cpc-crtc.html (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 :D
Quote from: fiorefr73 on 09:05, 26 June 20
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).