Editing the Palette of an existing game?

[Camm]

I am currently attempting to change the palette in Super Wonder Boy in Monster Land.

Any advice would be appreciated as to what to look for in the DSK image.

I am also curious to know what tile editors (if any) are available for editing sprite tiles in DSK images. I am using Tile Layer Pro which shows up the background tiles and menu tiles, but I am unable to find the sprite tiles.

The game is using Mode 1.

I am experienced in hacking SMS and NES roms, but the CPC is a new ball game and any advice would be appreciated.

[Gryzor]

Ooh! Can't help you any, but I want to wish you good luck... will be following this closely if it takes off

[Camm]

Thanks for the encouragement 

There is some more info on the hack here: http://cpcwiki.eu/forum/index.php/topic,2093.0.html

A bit of info on myself. I am a Wonder Boy fan of many years, and have been involved in quite a few rom hacks on the SMS, NES and Mega Drive, and recently have turned my attention to the CPC version of Super Wonder Boy in Monster Land.

Hacking a CPC dsk image is on a whole different level, as there doesn't seem to be the same amount of info and applications available as there is for console rom hacks. This one has caught my interest though, as the CPC is capable of much more than a simple Spectrum port.

Any input or information will be much appreciated

[AMSDOS]

A game like Super Wonderboy in Monster Land won't have any Firmware in it (unless your extremely unlucky), so the routine that maybe in it will most likely be setting the Hardware Inks to set the colours. Hardware Inks differ from the standard palette the Amstrad has when setting them from BASIC or using the Firmware for setting the Inks (&BC32). So you maybe able to find them with a decent Disk Editor program and if the code is exceptionally nice you maybe able to do a search in a sequence for those Hardware Inks. Unfortunately I don't have on hand what they are and I'm not quite sure what maybe the best Disk Editor program to do the job, perhaps Xexor since it pretty much does everything one could want (not sure if it will search a disk for a series of bytes).

Others will probably have a better idea where and what to look for.

[arnoldemu]

Thanks for the encouragement 

There is some more info on the hack here: http://cpcwiki.eu/forum/index.php/topic,2093.0.html

A bit of info on myself. I am a Wonder Boy fan of many years, and have been involved in quite a few rom hacks on the SMS, NES and Mega Drive, and recently have turned my attention to the CPC version of Super Wonder Boy in Monster Land.

Hacking a CPC dsk image is on a whole different level, as there doesn't seem to be the same amount of info and applications available as there is for console rom hacks. This one has caught my interest though, as the CPC is capable of much more than a simple Spectrum port.

Any input or information will be much appreciated

You'll need to know Z80, but I'm assuming you know this already.

Colours:

The colours are access through the Z80's OUT (C),C style instruction.
(includes OUT (C),E, OUT (C),D etc). This performs a write to the hardware "an I/O operation".

BC is normally loaded with the I/O port to write to. and the OUT (C),reg is the value to write to it.
The colours are normally done like this:

LD BC,&7f00+pen
out (c),c
ld bc,&7f00+colour
out (c),c

e.g.

LD BC,&7f01
out (c),c
ld bc,&7f54
out (c),c

which will change pen 1 to black.

The "hardware colour numbers" are listed on www.cpctech.org.uk. Look for "Gate-Array".
Take the hardware colour number, turn it to hex, add &40 to it and you got the number.

You should be able to see these in the code. Sometimes, the screen shows more than the mode normally allows (e.g. 4 for mode 1), so to do this the colours are changed through an interrupt function.

Normally the interrupt function is called through &0038, normally a JP instruction here to the actual interrupt handler.
You can then see what it does, including OUTs just like these.

If you see an out like this:

ld bc,&7f89
out (c),c

then it's changing mode.

Generally read the gate-array document to get a handle on how to change modes, colours etc.

As for graphics.

You can use the graphics viewing tool in Winape emulator. On cpc there is no fixed tile width, height. It's all done through software functions, so you can have any size and data form as you need.
So use winape, adjust width and height until you see something sensible.

Winape also allows you to edit the graphics in place, but you can equally save out a snapshot, and work on this.

Most hardware documentation is here on cpcwiki, but also on www.cpctech.org.uk.

I hope this gives you a step in the right direction, feel free to ask more questions, I'll be happy to help.

EDIT: My advice is to first edit a snapshot to get a feel of how the code is doing the colours and graphics.
When you're happy with that, writing it back to a disk image is a bit more work.

(involves writing files using cpcxfs or similar tool, and if the game is a hack, the fun of possibly repacking the file, or if it's an original the fun of either re-cracking it, or trying to write the data direct to the sectors in a way that still works with the protection None are impossible, but they vary in their complexity. ).

[Camm]

Thanks for the info CP/M User and arnoldemu, it has helped put some of the pieces together 

Ok so I have managed to find the palette data on disk 2, using a hex editor. The reason I couldn't find it before was because I was looking for the value with 40 already added, and on the disk it stores that number before the 40 is added. So black is stored as 14 not 54 on the disk (for example).  Fortunately the 4 colors where actually stored in sequence! Which made it quite easy to find in the end, once I knew what I was looking for.

Still can't find the sprite info on the disk, but progress is being made.

More info soon and thanks again!   

[arnoldemu]

Thanks for the info CP/M User and arnoldemu, it has helped put some of the pieces together 

Ok so I have managed to find the palette data on disk 2, using a hex editor. The reason I couldn't find it before was because I was looking for the value with 40 already added, and on the disk it stores that number before the 40 is added. So black is stored as 14 not 54 on the disk (for example).  Fortunately the 4 colors where actually stored in sequence! Which made it quite easy to find in the end, once I knew what I was looking for.

Still can't find the sprite info on the disk, but progress is being made.

More info soon and thanks again!

Why not run the game in the emulator and find the sprites/tiles/colours through the emulator?
Much easier to find, but then the problem is then how to translate the data from it's memory form to it's disk form.

Could you extract the files using cpcxfs or another dsk tool  (dsk-manager)?
Then you can look at the graphics?

How are you searching for the gfx?

it is possible that the coder chose to store the sprites/tiles in a mode 2 form (2 colour, 8 pixels per byte) and then translate them to mode 1 at runtime....

I am pleased you are making progress.

[Camm]

I have been using Tile Layer Pro to look for and edit the tiles. The background tiles are viewable/editable and are stored as 1BPP, but as mentioned the sprite tiles aren't showing up and would need to be stored as 2BPP as they have a 3rd color used for masking/transparency (I would assume).

I can view the sprites in Winape, but using a DSK editor/manager is something that I have no idea about, let alone using one to get my edits from Winape onto the disk. Guess I need to do some fast learning 

[Devilmarkus]

WinApe's DSK editor is quite simple!
Press CTRL + SHIFT + F1 to access DSK in drive 0 or CTRL + SHIFT + F2 to access drive 1.

There you can drag & frop files from DSK to any explorer window or from windows to DSK.
Make sure, that the files have an AMSDOS header!
You can select "Add/Remove AMSDOS header" to add a pseudo header to each file you put on your DSK.

I also coded a little AMSDOS header tool, which allows you to add or remove an AMSDOS header to every file you find.
I'll attach it here...
If you are confused, how to run it:
You need Java on your PC.
Then you can run it by double click or use a .BAT file with this content:
java -jar AMSDOS.jar

[Camm]

Ok thanks for the info.

I think the part that I am confused about is if I edit the sprites in ram in Winape, how does that help put them on the disk.

[arnoldemu]

Ok thanks for the info.

I think the part that I am confused about is if I edit the sprites in ram in Winape, how does that help put them on the disk.

Well, you could load each file into Amstrad's ram.
then you can edit them (via Winape) and save them back to disk.

it would be something along these lines:

in basic:

load"<file>",&4000

edit the file

back to basic:

save"<file>",b,&4000,<length>

knowing the length of the file is important, and the dsk editor can help.
If the file is long, loading to &4000 will not be low enough, and you may need to load it lower.
But it's another possible way to edit the graphics.

[Devilmarkus]

JavaCPC's GFX editor also allows you to store the binary direct to your harddrive.
It works almost like WinApe's.
But you can select a range of sprites and store them. (Incl. AMSDOS header of course)
These you could edit and after merge them back into your program.
E.g.: Game's binary is from &4000 to &7fff, sprites are located between &5000 and &5fff.
Then you edit the sprites, save them to your PC and move the .bin on your DSK.
Then you would load the game like this:
MEMORY &3FFF:LOAD"GAMEDATA",&4000:LOAD"SPRITES",&5000:CALL gamestart

Info about JavaCPC's GFX-viewer:
http://cpcwiki.eu/forum/index.php/topic,484.msg15088.html#msg15088

You can find it in my latest beta:
http://cpc-live.com/data/list.php?dir=-beta

[Camm]

Your doing some very nice work there Devilmarkus

I have managed to find the sprite data on the disk image, and have also discovered why I can't see it in Tile Layer Pro, or any of the other rom hacking tile editors (I have tried a pile of them). It is to do with the width of the tiles. When the tiles are viewed in Winape the width has to be altered in order to see the sprites. Also in Winape, if I actually load in the disk image directly to the debugger (see attached image), I can still see the sprites, I just can't save any changes back to the disk image.

Ironically, in Tile Layer Pro I can see and edit the 1bpp background tiles, which don't show up in Winape's editor.

I think all this has really exposed the need for a tile editing tool, with settings specific for the Amstrad, that edits the disk, tape or rom directly, with features like variable width tile viewing like in Winape. I think something like this would really open up the hacking/mod potential of the Amstrad community. So if any of you tool makers out there are feeling inspired, this is something that I think would be really worth while for the amstrad community.

[Devilmarkus]

With this feature in WinApe's debugger you just loaded a DSK image into CPC's ram!
It's not for editing disks!
It's meant to load binaries into ram...

You can basically edit sprites in my GFX-Editor, too... (well, no fill function, but you can zoom them and change all pixels)

[Camm]

With this feature in WinApe's debugger you just loaded a DSK image into CPC's ram!
It's not for editing disks!
It's meant to load binaries into ram...

Yes, I was just pointing out, that when I did that (not the intention of the tool), I was able to see the sprites, which means the raw sprite data is on the disk, it is just the tile editors that don't have the ability to view it because of the abnormal tile size, or the way in which the data is laid out.

The idea would be to have a tile editor, that loads the disk data directly, displays it graphically, then you just edit that data and re-save the disk file. There are a pile of them out there, with Tile Layer Pro being the most popular, but nothing that I am able to find that allows to vary the width of viewed tiles like in Winape. I think something like this would be really great for the amstrad community.
   

[Devilmarkus]

The idea would be to have a tile editor, that loads the disk data directly, displays it graphically, then you just edit that data and re-save the disk file. There are a pile of them out there, with Tile Layer Pro being the most popular, but nothing that I am able to find that allows to vary the width of viewed tiles like in Winape. I think something like this would be really great for the amstrad community.

My idea is:
I will use CPCInAJar as base (It contains all necessary functions)
and code a GFX-editor around it. It will look like the GFX editor in JavaCPC.
But the difference will be that you can select the files from your DSK to edit them.
You would have to setup the palette then manually! Also the screenmode.
But the editor could write directly the edited files back to your dsk. (I will use CPCXFS to make it possible)

Perhaps I will also show the CPC screen as small display and so you could do like this:
- Load and run your game
- So you get screenmode and palette
- Now select a file from your dsk and edit it.
- Save the file back to dsk, when edited and reset the tool and check your game

[Camm]

Sounds awesome.

Now understand that I am an amstrad noob, and am not used to dealing with dsk images that contain individual files. What I am used to is SMS and NES roms.

From what I can see though, the dsk image has all the data from it's contained files clearly readable and unaltered. So it should just be possible to read in the dsk directly and display the whole disk image as it is. Any tile data should show up regardless of whether the individual files have been separated or not ... Is this actually the case, or is there something that I am missing here?

With other systems, quite often an emulator will be able to save the palette of the game to a file, then this file is readable by various tile editors. Quite often though, it is enough just to muck around with the palette in the tile editor (with a color selection type tool in the editor) and put together a palette that allows you to see enough to work with.

I think it would probably be simpler to not add any emulation to the tool itself, but maybe have something like a palette file that is dumped by the emulator and readable in the editor.

Just some thoughts, forgive me if I sound a bit noobish when it comes to Amstrads 

[Devilmarkus]

No worries about that!

Well, I already begun coding it...
Working on the GUI and then I will implement all features


In this panel you can use the CPC emulator as it should be used.
(Load games, play them etc...)

In the other panel the GFX-editor will take place.

Well, still lots of work

Edit: Perhaps I should use double screensize here, what do you think?
Then also MODE 2 would fit properly...

[arnoldemu]

From what I can see though, the dsk image has all the data from it's contained files clearly readable and unaltered. So it should just be possible to read in the dsk directly and display the whole disk image as it is. Any tile data should show up regardless of whether the individual files have been separated or not ... Is this actually the case, or is there something that I am missing here?

The disk is generally 40 tracks, with 9 sectors (512 bytes size) for each track. This is the disk's formatted and base structure.
On top of this is the AMSDOS/CPM based filesystem (similar to how a PC stores files and how the IDE/SATA drive is structured - same concepts).

The files are then organized, as multiple blocks of data (2K each) which are potentially spread anywhere on the disc (similar to pc). So the data is not necessarily continuous.

The dsk is a dump of a real disk, with added structures defining the raw disc format, in a way that an emulator can read it, and a tool such as CPCdiskxp can write it back to a real disk to use on a real computer.

So you can load a disk image into memory (well not so easy since it is 178k and Amstrad's base ram is 64k), and edit it this way, or edit it in a hex editor, but  then viewing it may result in finding half a sprite in one part of memory, and half in another, and in addition you risk destroying some important headers and then it can't be read in an emulator.

There is added complication in that the data on disk could be encrypted or compressed, or even not stored as files, but there are plenty of hacks where the protection has been removed, so I think this is not so much of an issue.

Generally I think roms (sms etc) are stored in continous blocks, and are often uncompressed and not encrypted, so hacking them is much easier, and in additiont the hardware of these consoles have hardware and fixed format tiles and sprites.

Hacking, for example, a Amstrad Plus cart would be much more familiar to you after it has been converted to raw binary.
(e.g. to hack a + cart, convert cpr to bin, edit it, convert bin back to cp and test it).

An editor as Devilmarkus suggests, which allows you to focus on individual files within a dsk, although a slightly different way of working, will probably yield a better result, because the data you will edit and see will be continuous (it will also take care of ensuring the appropiate file headers are correct for the Amstrad's filesystem, and that it is written correctly onto the dsk).

Some games come in 2 parts (loader and then main binary), some come in more, but I think this way could be the best.

I think mostly the editing issue is down to the structure of the emulator file, and how the data is structured within in, and the way to edit this in a way which is easy.

Please try the tool when it is ready, please give feedback, and hopefully it is heading in a direction that makes editing games like this much easier for a new Amstrad user such as yourself.

[einoeL]

Very nice project, Markus.
That will be a useful tool, go on!

[arnoldemu]

I think that what you are doing is a good thing, because I think many CPC games could be improved with some hacking, some require graphics changes, some require recoding.

And because you're new to it on CPC, you can highlight more easily for us, the problems and the way it can be done.
I already read in the other thread that you found something with the other black colour, which is interesting, something I wasn't really aware of.

[Camm]

Thanks for that info arnoldemu, it certainly makes things much clearer 

Looks great Devil, and I agree with the idea of making it bigger.

[Camm]

And because you're new to it on CPC, you can highlight more easily for us, the problems and the way it can be done.

It is exciting for me to provide an outsider perspective, for what appears to be a very worthy and much loved machine 

[Devilmarkus]

Also noobs inspire me for new ideas
So, noobs from all countries, unite!

[Camm]

lol I am glad we have a use for something