Ensoniq Display/Keypad and/or Emu Emax Keyscan Project

[Rasputin]

In a fair amount of Ensoniq gear (ESQ1, VFX, VFX SD, SD-1, SQ80, et al), the display and keyscan circuit is controlled by an NCR 6500/11 chip. Obviously, there are quite a few proprietary parts/chips in Ensoniq gear that can no longer be sourced without scrapping another machine, and the 6500/11 is one of them. This chip is of particular interest as there are a couple viable options for cloning/substituting/emulating it without a 1:1 replacement, which is nice because while Rainer Buchty had a few NOS spares for a while, I believe the chip simply no longer exists outside of board pulls / donor boards.

Long story made short, the most surefire way of producing a 100% compatible replacement option is to base it off the original code. This is problematic because the chip does not have an external ROM, but rather 3K of mask ROM which is (nearly) impossible to read as it is embedded within the chip during the manufacturing process.

I have a few ideas/leads on how to retrieve the code and produce a working substitute, but would like to know if anyone else has any desire to either preserve the mask ROM for academic / hacking sake, or to manufacture a short-run of replacement chips for a select range of Ensoniq synths.

Similarly or alternately, the E-mu Emax / Emax II / Emulator III has an identical problem in that the keyscan MPU is also a 6500/11 MPU which is difficult to find and replace. [R1125-11 IM368 Keyscan IC]

If anyone has access to these chips, any spares, any motivation, or any need to have these chips read out and cloned then please do let me know. I know there are a few people with dead keyscan chips who can no longer use their Emax control panels, or SQ80 owners with good mainboards but dead display boards who would benefit greatly from the success of such a project, but I don't know just how in demand or worthwhile this undertaking would be.

I am fairly confident that this can be achieved, but first I would like to get a feel for whether it is a waste of my time, money, and effort.

Additional Questions:

Both Rockwell and NCR made a 6500/11. Does anyone know if these are 100% identical, or if there are significant differences? Also, does anyone know if the mask ROM is identical or at least compatible between all the Ensoniq products and/or E-mu product which use these chips?

[blueknob]

I may have mentioned this elsewhere. About 15 years ago my ESQ1 display chip expired and I went to great lenghts to write some PIC code which ressurected my synth. My code/PIC wasn't 100% but got most of the button functions, and then the display half of the chip started to fail so I sold the synth for parts.

At the time I was in communication with R.Buchty who was helpfull with suggestions AND had the chips for $49 (at the time) which was the best fix of all. We did exchange notes/ideas on the 6500 chip but we both knew it was going to take a lot of time and effort to reverse engineer the functionality, for what would be, very little in return. Just buy his NOS chip was the best solution, besides most people now in the internet age expect things for free, a download, so there was no real incentive to do anything further.

Thinking back and reading Mr R's post. I bought another working ESQ1 (£120 at the time), I had the two in my workshop, one set up to read the codes and the other one (with no display) hooked up to a PC so I could test my discovered codes. Once the display half started to fail I quit the project.

In my dreams... I figured somewhere on planet earth exists a floppy with the original code the engineers at Ensoniq wrote. I then dreamed, it would be easier to search (probably the USA) for those same engineers and ask/bribe them. Interestingly, the engineers behind the FX chip are still around, so why not the 6500 programmers too? I do realise of course, highly unlikely.

[Baus]

When was the last time you were in contact with Rainer Buchty?

He finished engineering a display kit for the ESQ-1 last year and I think he's working on the VFX and other units as well.

[Rasputin]

When was the last time you were in contact with Rainer Buchty?

He finished engineering a display kit for the ESQ-1 last year and I think he's working on the VFX and other units as well.

If he has now solved this problem then it would be terrific news. If so, there still remains a few questions and concerns though.

1) Are all 6500/11 chips in the Ensoniq / E-mu lines cross-compatible? This seems highly unlikely to me, yet I have heard claims that the scanning chip for the EMAX will work in Ensoniq devices as well. I could eventually test this myself, but would rather ask if anyone knows for sure before bothering.

I would like to cover the entire range of same or similar chips / devices, including the keyscan in the Ensoniq Mirage.

2) While I appreciate the possible need to make some $$$ to offset the research and development of reversing the 6500/11, I would also want to make sure that the information wasn't ultimately lost to the sands of time yet again. If someone ends up making a clone then what happens when that source dries up as well? I would like to preserve the code for use in future projects like MESS/MAME et al.

Given Mr. Buchty's status and agendas, if he's found a solution then I can probably put this project safely on the shelf. Fingers crossed.

[Rasputin]

I may have mentioned this elsewhere.

besides most people now in the internet age expect things for free, a download, so there was no real incentive to do anything further.

one set up to read the codes and the other one (with no display) hooked up to a PC so I could test my discovered codes. Once the display half started to fail I quit the project.

it would be easier to search (probably the USA) for those same engineers and ask/bribe them. Interestingly, the engineers behind the FX chip are still around, so why not the 6500 programmers too?

Yes, you did mention this earlier, and I appreciate your continued contributions.

Yes, other than simply being altruistic there really is little incentive these days to share all your hard work and discoveries. Yet, I would often rather feel the sting of unappreciated/uncompensated effort than not do such a project. If someone like us doesn't do it then who will?

I haven't personally gotten to the display behavior of the 6500/11, but I am assuming the mainboard simply sends ASCII (or similar) characters over the serial port and the 6500/11 reconstructs the serial into ASCII then breaks each character into an equivalent 14-segment character using a lookup table. I'm sure there's some general overhead to talk to the display drivers (TL5812 control registers, etc.) but I'd think once you capture enough display traffic sent from the mainboard then it would be apparent how to send arbitrary strings of text to the 6500/11 via computer. Once you know what kind of input the display portion of the 6500/11 is expecting then it should be fairly trivial to drive any given 14-segment display (or most any display, for that matter) as those will already be well-documented.

I don't mean to trivialize the effort/expertise involved, but I don't think the problem is insurmountable even without gaining access to the mask ROM which is what I ultimately hope to do.

[blueknob]

You got me thinking, I did actually read in the codes destined for the VFD display, it was quite straightforward. I had it where I could see the ascii codes on my PC display, I may just have used MS Terminal app in Win98. I may still have my notes somewhere where I tabulated all the display codes and the button presses I found. I did look at the MUX needed for the VFD too but stopped there, was taking too much time/effort. I can't remember if there was a data latch or not.

[Rasputin]

You got me thinking, I did actually read in the codes destined for the VFD display, it was quite straightforward. I had it where I could see the ascii codes on my PC display, I may just have used MS Terminal app in Win98. I may still have my notes somewhere where I tabulated all the display codes and the button presses I found. I did look at the MUX needed for the VFD too but stopped there, was taking too much time/effort. I can't remember if there was a data latch or not.

I would absolutely appreciate any research or notes regarding your progress in the past. Anything to make it easier is welcome, as it will be around 2 or 3 hundred $$ U.S. to make a small run of drop-in replacements even in the best case scenario of retrieving the original mask ROM and that's aside from time and effort.

Reading out the mask ROM is a bit of a long shot, but I'm currently exploring a promising option, so... time will tell.

[jxalex]

Does that SQ80 keyboard controller firmware is also usable for Your VFX? If so then that 6500 eprom readout may be usable for your further reverse engineering?

how much far away is that 6500 chip? It seems somehow like 80c51 chip which as the EPROM memory inside too. Does that 6500 has the "write protect" flag?

[Rasputin]

Does that SQ80 keyboard controller firmware is also usable for Your VFX? If so then that 6500 eprom readout may be usable for your further reverse engineering?

how much far away is that 6500 chip? It seems somehow like 80c51 chip which as the EPROM memory inside too. Does that 6500 has the "write protect" flag?

I think the SQ80 and VFX series have different revisions (even varying within a particular model) for their KPC boards, but I think they are more-or-less interchangeable. The KPC firmware for the VFX and SQ80 isn't so much of a problem as they're just standard EPROMs and at least one version for each model has been read out. I just did the KPC board on the VFX recently.

The 6500 in the Ensoniq line is something like a variant of the MOS (Commodore, at that point, I guess) 6502 licensed by NCR and manufactured with a custom mask ROM. I believe all the E-mu versions of the 6500/11 are the same thing, albeit licensed by Rockwell instead.

I have a lead on non-destructively reading out the mask ROM, but I don't know if it's going to work. The most viable alternative is to send it to an IC decapsulation specialist, but that's likely going to be big $$$ and a long wait even if it's just a well-versed hobbyist. And that's obviously going to kill the chip. Very dead.

[blueknob]

ok then Mr R, give me a moment and I'll rummage through some boxes of tech info I keep. Expect to receive main board -> display CPU codes and Button CPU->main board codes in a table/list. I tapped into the 2 data lines that link the two boards.

As maybe a silly thought, China is the main tech zone now, send them a few chips and ask "copy this" Then we will have 1 million units shortly followed by identical cheaper ones (plus fakes) on eBay (via Hong Kong) - we live in a bizarre world!

[blueknob]

Sadly, some spiders have been evicted in the making of this post.

I’ve found my notes (from Dec 2000), alas not as complete as I thought, the main code/display table has vanished. Anyway, here’s some pointers.

The opening helpful tip came from R. Buchty who said, get a RS232 card and change the xtal to 2.0MHz which will then align with the 6500’s max speed. This worked a treat. Check the data/spec and you’ll see how this all aligns perfectly. Then set MS Terminal to 8N1 (I think) and we’re off.

With the display, I seem to recall this was easy. Tap into the data stream from the main board to display, might need a few Rs to match the levels, I might have used a MAX232 chip. I think all is visible, so it’s a case of converting that data into suitable mux lines for the VFD. All standard stuff but time consuming to code up, and with just a few unique characters to accommodate. My concern was the VFD must always be muxed (on the move), if not, it could easily fry segments.

I forget if there is some handshaking at startup so the main board knows if the display board is there.

I have a pik of the key codes and button matrix that worked for me with my set up. There is a code for key down and key up. Plan your code for two buttons down. I didn’t know the full list of two key downs. There might even be a 3 button down too when in self-test mode. I scanned the keys at 10Hz

I created a button matrix (chart) so I could reference each button on the ESQ1’s ribbon cable, this might be unique to my effort. I then used that to reference pins on my PIC.

I have paper copies of my PIC assembler code, not sure if that would help but you’re welcome to it (13 pages). It did all work and is nicely annotated, sadly I can’t yet find the disk I stored it on. I made up a PIC and ran my ESQ1 like that until segments started to disappear.

I would think even with the small amount of info I have given here, once you have your kit setup and running, all things will just fall into place. It will be time to get coding!



and the matrix..

[Rasputin]

Thank you for the effort. These are the posts that put a smile on my face

This seems quite in line with my own findings, so I think the data is good. Thanks again. If you stumble upon any more ideas or materials, please do contribute them. I'm all about these brain jam sessions.

[jxalex]

Aujeee... I hope here will be more posts like these..
Very neat stuff and... addictive.

[FL200]

Hi,

Sorry to jump onto an old post. I am currently getting back into my synths and dragging them down from the loft (it’s been about 15 yrs!).

I would be interested in a replacement of the 6500/11 for the display processor on ESQ1 as I currently need at least 3 of them, and 1 for a VFX (If it’s the same processor). I currently have a working VFX, 2x EPS, and a Mirage, and also have a motherboard a display board for an SQ80 (with 6500/11 fitted) which I hope to restore to life. Add to that a couple of SDP1 and a motherboard for an AWP5000 to restore as well. I seem to like Ensoniq?!?

I would be glad to hear of any progress there has been on a replacement display processor, if any, and am happy to help if I can with the development of it.

Thanks

Jon.

[flpfire109]

+1