Close

09-11 march 2016

A project log for Project 72 - Korg DW-6000 wave memory expansion

An attempt to reverse engineer and modify Korg DW-6000s firmware in order to expand its wave memory.

mateuszkolanskimateusz.kolanski 03/12/2016 at 18:320 Comments

I started replacing some constants with nice labels, to make the code look more readable:

That's my IDE

I made a simple excel sheet that converts hexadecimal values into 7 segment characters to be able to decipher some values at the end of the file.

Seeing "words" like TAPE, LOAD, etc gave me a few hints about how the code works. I also added some constants pointing to known places in external RAM.

Now it's time to spend some time with the MAME debugger. I have to look carefully at the routines doing something with PA/PB (keyboard reading) and those which use the corresponding data saved in RAM. I'm pretty sure that I have a rough idea about how they work, but I wasn't able to change anything on the displays (well... make the display memory to change to be exact) just by entering some values to where the switch memory is supposed to be. Long way to go.

The more I know about the inner workings of DW6000, the more worried I am about the available space in ROM (whopping 72 bytes - I think, that "project 72" would make a good name for this one). Right now I think (or better said I expect, because I didn't have a chance to verify this guess), that the parameter selection is performed on a base of jumps to subroutines (that's what the data at the end of the file is for?), where each combination generates an offset to a function pointer. If a given combination is invalid, the resulting pointer will invoke this same subroutine which just waits for another, valid keypress. If it worked this way (i.e. one jump address per combination), it would be possible to modify some jump addresses without wasting precious bytes. If not (i.e. the code check if the keypress is in a fixed range), things will get more complicated.s We'll see. My other concern is, that since PORTB is partially used for row addressing (you know what I mean) and I want to use its second half for extra memory addressing, I will have to make sure, that the existing code which "shares" PORTB will do the masking first. And that means some extra code.

It turns out, that my little project brings other people's attention. I was explaining my idea to a fellow geek and he suggested, that I could (or even should) use a latch driven by PC2 or PC4 (right now I feel that I might need both of them...). This way I won't have to think about preserving PB's value between function calls. Great idea. Might give it a try, although I like to keep things (look ;-D) as simple as it gets. He also suggested that I could profit from constructing a simple device emulating my ROM chip, something like an SRAM chip with serial programming interface. Another good idea, definitely worth considering.

I could really use a kind of versioning system since now I'm dealing with some proper source code:) All you wish me luck and keep the fingers crossed.

Discussions