Hi there,

I'm completely blown away that the mighty ELKA Synthex synthesizer (Jean Michel Jarre's laser harp, anyone?) from 1981 used a 6502 as it's main processor. I did not know until I browsed through the schematics yesterday and had to look twice at the processors pinout. See attachment.

Cool, that makes Jean Michel Jarre and Stevie Wonder two rather prominent 6502-Users.

Still, I think the circuit is rather weird. Why did they hook up the IRQ line to Pin 5, which is N.C. according to the datasheet?

Cheers,
ArnoldLayne

Well, it does connect to /IRQ (pin 4), but the signal passes through that 1K series resistor.

We can only guess what the intention was. And my guess is that it was a troubleshooting aid. One could tie pin 4 high to inhibit interrupts -- and, at the same time, observe pin 5 to see whether an interrupt was being requested. Certainly there could be other explanations, though.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Very interesting factoid! I knew the Fairlight CMI uses 6809, but this is much more relevant to my interests.

Yeah, there were quite a variety of CPUs that saw use in early computer-controlled keyboard synthesizers, from the 6502 to the 6809 (also used in the Oberheim Matrix-6 and Matrix-1000) to the 8086 (Rhodes Chroma Polaris) down to even the lowly 8048 (Roland Jupiter-4.) Heck, the Synclavier was actually built on a custom 16-bit minicomputer architecture!

(Oddly enough considering how common it was in small computers, the Z80 was just one player among many.)

I got into synths by a friend of mine sort of talking me into having a look at his Korg Polysix. I declined at first, because I did not know anything about synths and was too afraid to break it even more. I was then surprised how much vintage synths and vintage computers have in common. A vintage synth is basically a vintage computer with a hell of a soundchip(s).
The Polysix has 2 processors, by the way. An 8048 and an 8049, one as keyboard processor and one for patch assignment and memory. I do not remember which does what.
There is also a replacement/MIDI retrofit for both CPUs based on a Z80.

As of now, I was not even aware that the 6502 has been used in synths, too. I am still very excited about this.

Hi there,

I am a big fan of JMJ and love the sound of the synthex.

I do not own one (it is quite a budget these days...) However, I recently decided to dive into its electronic diagrams to understand how it works. Concerning the 6502, I found something that looked strange to me (I have some academic knowledge in electronic components and circuits, both analog and digital, but not much experience in the field). I noticed that the address and data pins of the 6502 were connected in a peculiar order to the ROM pins. I would have (perhaps naively) thought that the data pins of the 6502 - 33 to 26 - would be connected in the same order to the data pins of the ROM chip (a 2532) - 9~11, 13~17). However, the order seems without logic to me (see picture). The same happens for the address bus.

That would require the content of the ROM to be somehow "translated" after assembly; wouldn't that make the addressing more complicated?

Is it something that you often see in systems using the 6502 (or similar processors)? Any idea what the point in this would be ? "Crypting" the content of the ROM?

Thank you for you input on this, it would help my quest for learning and understanding

Welcome, Fenntil! You'll find there are quite a few other forum members who have an interest in music.

Yes, you've hit on the answer right there -- the contents of the ROM are indeed translated after assembly. So, there is an added step -- but not a very complicated one. Then later at run-time the whole thing just works.

The ROM itself doesn't "know" conventions such as "pin [whatever] is supposed to be Address Input [whatever]." Address lines can be swapped with other address lines. The assignments are actually arbitrary, and can be shuffled at will -- provided the ROM contents are translated in advance with a complementary shuffle. In a similar way, data lines can be swapped with other data lines. Any combination of these tricks is acceptable as long as you arrange things so that normal results are what end up reaching the microprocessor!

The potential advantage has to do with the physical positions of the ROM pins, which become important when you're laying out the traces on a circuit board. Sometimes the task can become significantly easier if you take liberties with the ROM pinout.

Addendum: swapping RAM pins is easier, because that extra step (the translation) takes care of itself. The data gets written in-system, meaning the data automatically gets scrambled when it's written, and the exactly opposite scramble occurs when it's read back.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks Jeff!

Now I see (at least one reason) why my attempt to de-assemble some ROM files did not make any sense; I'll have to translate them first

Whoops, yes!! -- they are a little tougher to understand before they get unscrambled.

Here is another scenario where pin-swapping paid off. Back in the 20th century I wanted to do some radical firmware mods on these funky TTL computers, but I wasn't willing to deal with expensive and non-erasable 82S115 TTL PROM's (three of which constitute each board's program memory). So I rewired the boards to use EPROM's instead.

Without pin-swapping almost all 24 pins on each chip would have needed the trace cut and a jumper wire installed. Instead I was able to do the job with just a small amount of hacking.

Attachment:

DiabCPUwsCrp 250x167.jpg [ 8.74 KiB | Viewed 5288 times ]

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Ya know, I've never thought about it, but, I mean, if you just scrambled the D0-D7 lines to the chip, the chip doesn't care, and the CPU wouldn't care.

And I guess that would be the same with the address lines (to a point).

Imagine the poor sod trying to decode that ROM without seeing the board in the first place.

This and a lot of other tricks are in the "Tip of the Day" column.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hello all,

Now I've been able to move a little further with my understanding of the Synthex. There is a particular piece of schematics I am currently stuck on :

REST is an output of an LS138, RESET is pin 40 of the 6502.

4B are on a 4093 chip (four NAND gates with Schmitt-trigger action on both inputs). 3B is on a 74LS04.

Is this perhaps some kind of protection?

Thanks for any input on the matter

I believe what you are seeing is circuit that limits the reset to the 6502 to a short pulse. In the NMOS parts, holding down reset too long causes something in the microprocessor to overheat and possible cause a failure. It was common for such systems to have their reset circuitry rigged up to prevent a sustained reset.

The Commodore 64 used a 555 timer for this purpose.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It's not completely clear that this is the case - we discussed it over here.

Yep, recall that thread. I also seem to very vaguely remembering Lloyd Sponenburgh, the engineer who developed the Lt. Kernal hard drive hardware, saying that the 6510 in the C-64 could be damaged if reset was held down too long. This was when he and I were chattering about the idea of putting a hardware reset button on the Lt. Kernal's host adapter. There has been a fair amount of anecdote about the supposed problem, but evidently no one at MOS Technology (aka Commodore Semiconductor Group) had ever admitted to such a thing.

Is there anyone out there who is will to sacrifice a 6502 to determine if this is fact or folklore?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!