Thank you for this excellent software. I am trying to use it to reverse engineer my own game from 1985, that I lost the source code for. However, I have one major issue with it when trying to import from a snapshot.
My understanding of how multi-colour character mode works is that the MSB of the colour RAM nibble enables multi colour mode. This would mean that in the map the same character could be displayed both in single colour mode and in multi-colour mode depending on the colour RAM. I stored my levels as full copies of the screen ram and colour ram.,
But when importing from snapshot, the character attributes (L1) look to be a single definition for if a character is single colour or multi colour. This makes sense from a character map and tile map perspective, but given I store the screen and colour maps in binary form, there will be no place in my code where this attribute map exists on a character by character basis.
I don't mind editing these attributes myself, but I can see no way to do that within the Character Set Editor or Character Editor. Also, it isn't in my program to import. Why is it 256 bytes in length, instead of the full size of the colour ram ($03e8)? I have no idea how I can get the colour data into the character map. Sorry if I have just got completely confused about how this works.
Hi,
Thank you very much for your support and feedback,
So I think you have basically just run into one of the few features that are not currently supported, ie. a "per map cell" colouring/attribute method.
CharPad currently supports 3 colouring methods, 'per project', 'per tile' and 'per char'.
ie. a colour (or set of colours for the bitmap modes) can be attributed to either the whole project or each tile or each char.
L1 attributes (bytes) are Material (nybble) + 1 colour nybble (Colour RAM).
L2 attributes (bytes) are for the bitmap modes (each byte = 2 colour nybbles for each Video RAM cell).
'Per map cell' colouring/attributing has never been supported, mainly due to it being very uncommon, probably due to the amount of memory it would consume, ie. one extra byte for every map cell (potentially two for the bitmap modes), I have yet to find any commercial game that uses it.
But you are not the first person to ask about it and almost certainly will not be the last!
Other reasons for its exclusion simply come down to the complexity that it would add to an already very complex piece of software, it may seem simple but CharPad supports 5 display modes and 3 colouring methods, that's already 15 configurations that need to be considered for most operations, adding 'per map cell' and possibly also 'per tile cell' would raise that to 25.
In a nutshell, if it were simple, it would have been done, believe me.
Maybe some future version will support it but the work and complexity involved to add it has just not been considered worthwhile thus far.
I am sorry to disappoint.
Ps. the 'Project' window contains the tools you need to control the colour and material values for each char (in 'per char' colouring method) and likewise for the other colouring methods.
ie. select a char (or a tile if using per tile colouring) and you can change it's own matrix colour(s) using the the Project window.
nb. Materials (0-15) are always 'per char'.
nb. If you really want to use the same char with different colours you could try creating a 1x1 tile set and using that instead of a simple char map.
I'm sure you can appreciate just how complex things can become and how we have done our best to accommodate the most commonly useful configurations.
Cheers.
Thanks for the detailed response and the support.
The trouble is I think I am fine with "per char", because even though it is technically possible to have the same char in single colour mode and multi-colour mode, I do not currently do that.
All I am trying to do is find a way of configuring each char in the UI to either single colour mode or multi colour mode, and set the only configurable colour for that char. My game only had 4 levels, so storing 1k for screen and 1k for colour for each level was fine.
I have the original binary dump of the game and I have created a snapshot of it using VICE. But a game snapshot in memory from what I can see would never have this 256 byte L1 attributes block, it would have a dump of the screen memory and dumps of the colour ram.
So in summary, all I want to be able to do is configure on a character by character basis the colour mode, and be able to import the colour ram for the map.
Even if I manually created this 256 L1 attribute block manually, can I even import it? Can you explain the format of this area again in detail please? What is the Material nybble? The colour ram only needs a nybble to convey both the colour of the character (bits 2-0) and the type (bit 3).