AX-80 O.S. hacking co-op?

[Rasputin]

If someone wants to make a dump of the ROM (IC4) I could at least poke around a little.

I don't have the binary yet, but I plan on dumping the ROM by the end of the weekend. No promises.

One (of the many) problems with the OS hack idea is that I believe there were three different versions of firmware released, so it's likely that three separate patches would have to be made to support all machines, plus we'll need to find someone with the other versions of the firmware that can dump it.

The differences may be trivial, but it will be impossible to know until we can compare.

For strictly patch editing, the tape out/in method is 100% viable and should work with every revision of AX80. It could easily (not to jinx it) be done by a one or two person team. Not quite as ideal as far as transferring via MIDI, but the functionality would be the same.

I dunno, all those other OS hack requests seem a tall order. I'd be really surprised if someone manages it.

[commodorejohn]

Well, that depends on what the differences between the firmware versions were. Unless they were made to support, say, two board revisions that change the architecture in a meaningful way, you'd presumably just do the hack on the latest version and assume that anybody who's going to be applying it will be okay with upgrading.

[Rasputin]

Well, that depends on what the differences between the firmware versions were. Unless they were made to support, say, two board revisions that change the architecture in a meaningful way, you'd presumably just do the hack on the latest version and assume that anybody who's going to be applying it will be okay with upgrading.

Yep, it's all speculation and I have no idea what the differences in code are. Could be no worry at all, but I believe it pertains to the particular revision of CEM3372 chip being used, so there is a hardware element.

Here's what I do "know" though, for anyone wanting to follow along...

I respectfully disagree with the claim that there is no internal ROM stored on the CPU.

CPU pin 27 is MODE 1 ["high" via pull-up resistor to +5V]
CPU pin 29 is MODE 0 ["low" via pull-down resistor to ground]

Meaning that the CPU is operating in true 7811 mode, and that the memory mapping register determines the amount of external memory. There should be 4K of mask ROM in the CPU plus the 8K EPROM.

What we want to look for as far as data in and out of the CPU is activity over Port C on IC2 (Program CPU), hopefully manipulating what is sent to MIDI IN/OUT. That's key, obviously.

PC0 = MIDI OUTPUT
PC1 = MIDI INPUT
PC2 = TAPE INPUT
PC3 = DATA ACKNOWLEDGE (from key assigner strobe out via pin 20)
PC4 = NEXT INPUT (from jack PCB via pin 21)
PC5 = X
PC6 = SUSTAIN INPUT
PC7 = TAPE OUTPUT

I haven't disassembled the ROM (or even dumped it, yet) but we're likely to bump into code very similar to this:

; Initialize Port C
MVI PC,$FF

; Initialize Mode Register for Port C
MVI A,$03 ; Set PC0 and PC1 to 'ON'
MOV MCC,A ; which activates Tx/Rx of MIDI

; Initialize MIDI
MVI SMH,$4E ; Serial mode high byte register configuration
; which activates Rx, Tx, and sets to SCK Trigger, Sync mode, Internal Clock 24, and Search Mode=off
MVI A,$4E ; Configures SML as the below settings,
MOV SML,A ; Serial mode low byte register configuration:
; 1 stop, no parity, 8 data bits, Clock Rate = x16 (stop bits indicate it is asynchronous)

You'll want to look for activity on Port C in the form of...
ORI PC,$01 ; Turns on MIDI OUT
ANI PC,$FE ; Turns off MIDI OUT
and so forth.

Hope this helps some brave soul.

[commodorejohn]

I respectfully disagree with the claim that there is no internal ROM stored on the CPU.

CPU pin 27 is MODE 1 ["high" via pull-up resistor to +5V]
CPU pin 29 is MODE 0 ["low" via pull-down resistor to ground]

Meaning that the CPU is operating in true 7811 mode, and that the memory mapping register determines the amount of external memory. There should be 4K of mask ROM in the CPU plus the 8K EPROM.

Okay, that's interesting. Could make this whole shindig pretty tricky, but on the other hand, if they have different firmware revisions, then either they'd have to replace the CPU as well, or it just contains data that wouldn't need to change between revisions (interrupt vectors, lookup tables for notes, etc.) I'm curious.

[Rasputin]

Well friends, you can thank insomnia that I dumped the ROM earlier today

Akai AX80 Revision K ROM in its 8KB glory:
https://drive.google.com/file/d/0B44NKm ... sp=sharing

Took a quick peek at it and I have to say that it's not structured that closely to what I anticipated. I have a feeling the mask ROM contains a lot of important code, but it's also true that I don't really know what I'm talking about.

If anyone has access to the Revision "I" or "L" ROMs then your contribution would be appreciated. Even aside from this project, having all of the ROMs available might help keep a few more of these machines alive. It would be a shame for one to come to a premature end since they sound so f#$@ing amazing.

P.S. I have a method for dumping the mask ROM too, but it's a bit beyond my skill level at present. Someone better than me at Assembly (doesn't take much) could probably figure it out in one session of burning the midnight oil.

[Rasputin]

Okay, that's interesting. Could make this whole shindig pretty tricky, but on the other hand, if they have different firmware revisions, then either they'd have to replace the CPU as well, or it just contains data that wouldn't need to change between revisions (interrupt vectors, lookup tables for notes, etc.) I'm curious.

Totally guess-work here, but I think that the external ROM is the only thing that alters the behavior of the CEM chips, at least as far as the potential sound difference between revisions.

I think the AX80 has two revisions of the Program CPU too, but I think any differences in the mask ROM is basically transparent to the end-user.

In other words, I very highly doubt that any CPU transplants would be required. In fact, I believe we could bypass the CPU mask ROM entirely if we made custom firmware, but that's a digression.

If I haven't made it clear enough yet, all this stuff is just wild uneducated guessing on my part. No one should take it as gospel. If anyone has any info that runs contrary to anything I've said, please please do correct me (or at least offer up a reasonable rebuttal)

[Rasputin]

Judging by what I've seen so far, it may be feasible to dump patches via MIDI.

Sections of the code I can identify are a couple memory initialization routines (Internal RAM being one), port configuration, serial port configuration, interrupt masking configuration, and timer configuration. Other sections I think I've identified are two DCO routines, velocity/dynamics routines, and possibly something to do with the tape output. Conspicuously absent is any memory mapping code, so that must be hardcoded into the mask ROM.

There isn't an abundance of code, and a fair portion seems to be table data. Interestingly (but useless), I found a date of February 01, 1985 buried in there.

There seems to be less MIDI handling stuff than I would have guessed, and the serial port is configured in a way that's different than I would expect. It looks like the serial port is set to 2 stop bits which I'm reasonably sure it shouldn't be. It's possible that the mask ROM resets this properly, or there's some other approach that I'm not picking up on. Either way, it's my semi-uneducated opinion that a lot of necessary/preferable stuff is in the CPU mask ROM.

However, I have found the serial Tx/Rx buffer routines and can probably narrow down the memory addresses where patches are stored. Which means (if nothing else) it may be possible to replace the Tape Output routine with a MIDI dump of patch memory.

Maybe someone that actually knows what they're doing can chime in with a real assessment.

[rhino]

Still getting the story from Akai that details of the AX-80 OS are long lost/destroyed. Next plan is to create a board with a small microprocessor and a bunch of tri-state buffers that can halt the CPU in the synth and do a 'body snatcher' like invasion of the RAM, translate the patches into MIDI and send/recieve them to a PC. I'll also look into the chance that I can ditch the patch ROM (bank P) and replace with RAM, giving 3 banks of 32 patches.

[Rasputin]

Still getting the story from Akai that details of the AX-80 OS are long lost/destroyed. Next plan is to create a board with a small microprocessor and a bunch of tri-state buffers that can halt the CPU in the synth and do a 'body snatcher' like invasion of the RAM, translate the patches into MIDI and send/receive them to a PC. I'll also look into the chance that I can ditch the patch ROM (bank P) and replace with RAM, giving 3 banks of 32 patches.

Maybe some ex-employee has all the juicy details tucked away in a footlocker in some attic somewhere. I wouldn't count on it though, and probably not in a timely manner even if the master plans are out there somewhere.

Given that we have the schematics and there isn't really anything proprietary in the AX80 except for the code, it's not totally hopeless. With enough time and research, I'm 90% sure all the code** can be accessed and reversed by our humble team operating out of our virtual garage.

** The only code that I'm not sure we can access is any mask ROM on the key decoder CPU.

Your plan would definitely get the job done, but I don't know how handy it would be to most owners. I guess you could sell a kit, but I can see a lot of people doing some sloppy soldering and ruining a relatively rare board.

The "poor-man" tape in/out method is sure fire. This is the worse case scenario, but it's a virtual certainty and is 100% universal and risk-free.

I've made a lot of progress on reversing the ROM though, and more things I think I've identified are the main "kernel" loop, pitch bend/mod wheel/sustain pedal stuff, keypress routine, and bit more. By my estimate, about 25-28% of the code is in the form of lookup tables, but I can't tell what the LUTs are yet.

The biggest hindrance so far is figuring out what the memory addresses correspond to.

If anyone wants to make (or has) a chart showing all the parameters and their potential values then that would be very helpful in a lot of ways. Coding a patch editor will depend on knowing what can be changed by the user and what values each setting can be changed to. It would also help me (or anyone else that wants to take a look) determine what may be in each address space.

I'm thinking something in the form of: Patch Banks (A/B/Preset, composed of 1-32), Velocity (0-127), etc.

Oh, and @rhino, what revision ROM do you have? If you don't mind me asking.

[Rasputin]

I have the majority of the code broken up in to general regions and am making lots of progress as far as identifying/documenting functions. Making slight progress on the memory address issue, but it's still the bugbear.

By my estimate, there are about 74 bytes free to cram some new features into, assuming no other optimizations are done. There's some wiggle room, but not a ton -- only about 28 more lines of code.

Pretty tight, but there's no accounting for clever. (The cleverness of someone else, hopefully.)

Whomever initially scanned and posted the service manual is my hero, but interestingly I think Akai made an error on the diagram for the IC2 CPU pinout (as posted earlier in the thread) because AN6 and AN7 are reversed.

Further updates (7/28/16):

I have found where and how the AX80 generates MIDI messages, at least enough to do something like change the modulation wheel to another control like MIDI volume, portamento, or breath controller.

The most important remaining obstacle is to figure out exactly in memory where patch storage is, but I believe I can find that in a few more days.

I've also decoded most of the LUTs, a good portion of which are memory address tables, some containing addresses pointing to code in the CPU mask ROM which makes it impossible to see what they actually do.

At this point, the SysEx hack is looking plausible, probably it's just a matter of tight coding. The free-running LFO would probably be super easy to achieve once the LFO parameter is identified. I'm not sure about the rest of the wish list as there are still a lot more eggs to unscramble.

7/30/16 Update:

I've unraveled the ball of yarn to the extent that I'm quite confident MIDI patch save/load can be achieved without undue effort. My preliminary plan is to piggyback MIDI patch save/load onto Tape In/Out so that they work in tandem and no functionality is lost. That idea may need to be modified as more inner-workings are uncovered, but that method seems easy enough to implement and would achieve the basic goal, if not 100% gracefully. It would be at least enough to warrant the coding of a patch editor.

7/31/16 Update:

I now have the addressing for patch banks A/B & PRESET. It's now possible for me to create custom firmware which replaces the factory presets with custom presets, although it's pretty much more trouble than it's worth until someone codes a patch editor. Also, until someone wants to send me their non- Revision K chip (or BIN dump) then any custom firmware advances** will only work properly with boards that use Revision K EPROMs.

** Not that I'm guaranteeing anything.

[mrtransistor]

Rasputin,

You seem to be the AX80 genius.
My needs are likely hardware.
I am an electronics tech.
I am trying to fix an AX80.

Cleaned and applied conductive rubber to switches. All switches good.

Problem is keys with no sound. It is always 8 keys apart.

And it is funny that the sequence will "slip".

key 8,16,24,32,40,48,56 will be out (numbering keys 1-61)

& without touching anything......... then 7,15,etc

and have seen 3,11,19 ............ with the previous keys that were no sound "healing"

ICI is the keyscan micro.

Seen this before? Any ideas?

Jim mrtransistor@charter.net

[Rasputin]

Problem is keys with no sound. It is always 8 keys apart.

Are you testing this by playing random things or are you always testing the keyboard chromatically? I ask because it would behave like that if one voice was out and you were just going up (or down) the keyboard one note at a time.

If you play the same note over and over and the key goes dead every 8th press then it's a voice issue.

If it sounds fine playing over MIDI then it's not a voice issue. If one key is dead and you immediately try a key 8 keys up and that is dead (two bum notes in a row) then it would seem to have to do with the keyscanning.

If it's failing in random groups of [C, G#, E], [C#, A, F], [D, A#, F#], [D#, B, G] and so on then I'd check the headers of the keyboard. There's one header that's 8-pin and one that's 16-pin. Check the 16-pin header both on the keyboard PCB and also where the same header comes in to the mainboard.

If IC1 is the problem and it's truly cooked (not just fed bad power, etc.) then you're pretty well sunk without another AX80 to cannibalize, at least so far as I know. It would be nigh impossible to replace the keyscan CPU. Main CPU would be a tremendous hassle too, but IC1? Forget it.

Contrary to possible appearances, I'm far from an AX80 guru, but I'm flattered.

[tim_m]

Problem is keys with no sound. It is always 8 keys apart.

Are you testing this by playing random things or are you always testing the keyboard chromatically? I ask because it would behave like that if one voice was out and you were just going up (or down) the keyboard one note at a time.

If you play the same note over and over and the key goes dead every 8th press then it's a voice issue.

If it sounds fine playing over MIDI then it's not a voice issue. If one key is dead and you immediately try a key 8 keys up and that is dead (two bum notes in a row) then it would seem to have to do with the keyscanning.

If it's failing in random groups of [C, G#, E], [C#, A, F], [D, A#, F#], [D#, B, G] and so on then I'd check the headers of the keyboard. There's one header that's 8-pin and one that's 16-pin. Check the 16-pin header both on the keyboard PCB and also where the same header comes in to the mainboard.

If IC1 is the problem and it's truly cooked (not just fed bad power, etc.) then you're pretty well sunk without another AX80 to cannibalize, at least so far as I know. It would be nigh impossible to replace the keyscan CPU. Main CPU would be a tremendous hassle too, but IC1? Forget it.

Contrary to possible appearances, I'm far from an AX80 guru, but I'm flattered.

Mr. Transistor PM'ed me, and I sent him this way to test this way as well:

Press one key, hit the chord memory button, and hit one key again. This should force the AX80 into a sort of mono mode. Do all of the keys work now?

This could help differentiate between whether it's a keyscanning issue or a dead CEM chip.

Amazing work on the CPU, by the way!

[commodorejohn]

If IC1 is the problem and it's truly cooked (not just fed bad power, etc.) then you're pretty well sunk without another AX80 to cannibalize, at least so far as I know. It would be nigh impossible to replace the keyscan CPU. Main CPU would be a tremendous hassle too, but IC1? Forget it.

Though this suggests another possible angle to the project - if by looking into the main CPU you can figure out what kind of input it expects from the key-scan CPU, it should be relatively simple to rig up a replacement for the latter using any of a variety of microcontroller options, like the Teensy series of system-on-a-DIP-board solutions.

[Rasputin]

If IC1 is the problem and it's truly cooked (not just fed bad power, etc.) then you're pretty well sunk without another AX80 to cannibalize, at least so far as I know. It would be nigh impossible to replace the keyscan CPU. Main CPU would be a tremendous hassle too, but IC1? Forget it.

Though this suggests another possible angle to the project - if by looking into the main CPU you can figure out what kind of input it expects from the key-scan CPU, it should be relatively simple to rig up a replacement for the latter using any of a variety of microcontroller options, like the Teensy series of system-on-a-DIP-board solutions.

That's a really good idea.

From everything I've seen so far, the mask ROM in IC2 receives / translates all the keyscan data and stores it in working registers which the EPROM accesses. For most purposes, the low level functions (that I'm only assuming are there) would be pointless to directly access, but would be mega-helpful for a keyscan replacement.

Not that surprisingly (and I think you alluded to the idea earlier), the mask ROM seems to handle a fair portion of the really basic low-level stuff and then (more) easily editable code in EPROM handles the higher level functions.

I'm planning on dumping the mask ROM at some point because (if for no other reason) it will help fill in some of the little details I haven't worked out yet, or things it may be virtually impossible to workout.