This is a temporary project page to archive the work I'm doing on reverse-engineering the 'Autocue' function as fitted to the 'Micro' range of Citronic disco consoles (Tamar, Isis and Thames-II), late 1980s to early 1990s.
tl;dr - jump straight to the 6502 disassembly.
Autocue is a method of cueing-up records on disco consoles. Put the needle down, it finds the start of the song and then winds it back about 2-3s ready to play. Meant to take the hassle out of it - not everyone's cup of tea and results can be variable, but it's there.
This effort concentrates on Citronic's own implementation.
Here's the relevant bit of the instructions from the Tamar/Thames-II manual:
Hah, I'm not mad, no. My curiosity was piqued when I saw some of the Citronic consoles had this device fitted which would 'hunt' the beginning of the track on a record once the needle was placed down. I own another disco console (LAD GAJ-835 with Sound Creations SC909 mixer) which I use as part of Mrs R's Retro Roadshow, also with autocue. But the Citronic one is far inferior, so I set out to discover why and hopefully make it better.
My original aim was to build a replacement (aftermarket?) ROM, enhanced to run like the Sound Creations autocue - possibly even with a configurable set of parameters.
I'm sure I don't really need to say this but I'm going to say it anyway: I will not be held responsible in any way for any breakage, fault or failure brought about by your use of this information or code. In particular your attention is drawn to the warning around sensitivity to manufacturer-specific parts. You are responsible for your own research, I can only report back on my own findings. No guarantee or warranty is given, express or implied. Your mileage may vary.
Now I've got that bit out of the way, on with the show.
In a move which I can't quite work out is genius or madness, the sequence runs like this (I'll update this as I work out a bit more):
* (Other superior autocues (eg. aforementioned SC909) work off the audio, not a flashing LED... anyway, I'll stop grouching about that now...)
The Autocue has at its heart an 8-bit 6502 CPU, linked to a 6532 RAM/IO/timer (RIOT) chip and software from a 2716 EPROM with a whole 2K of program space.
I've only seen the Rockwell R6502AP and R6532AP variant of the chipset used; there aren't any undocumented/illegal opcodes in the disassembly from what I can see and other makes could probably be substituted (although see the note about EPROM variants below). Being 6502-based makes it really easy to disassemble, like wot I used to do with BBC Micros back in t'day.
Although pin-compatible, the 2716 cannot be switched with a 2732 to give 4K program space, because A11 is not linked up from the EPROM - therefore only a maximum of $7FF memory is addressable. There's absolutely nothing to prevent using 2732 EPROMs but you'd need to do the usual trick of duplicating the code in-ROM as A11 is left floating from the 2716 so there is no way of addressing this extra space (and A11 on the 6502 is already used for CS2 on the 6532).
Update 7 May: Since acquiring a stash of assorted 2716 EPROMs, it has become evident that the Autocue unit can be a bit sensitive about timing, possibly to do with ɸ2 on the 6502. For instance despite the datasheets being near identical, my own Tamar's original EPROM is a Thomson Components ET2716Q-1 (running at 450ns) which works just fine, but sometimes M2716-1 chips won't work. I've had a few successes with using 2516 EPROMs and have a batch of ET2716Q-1 and 2516 EPROMs on the way to test this theory. We did wonder about timing originally - plain 2716s are 350ns, the 2716-1 are 450ns - but it seems more than that. Note this could just be put down to age and availability of old-stock EPROMS.
It is important to point out, the mixer buttons will not function if the EPROM is not present or the Autocue has another fault in the 6502/6532. It relies on the EPROM code to init to bring the control lines down and stop the deck motors (which is why they start and stop quickly when you switch the console on) and further rely on the EPROM code to decide what to do when the buttons are pressed (eg. cancel an autocue sequence).
It's a very simple layout, comprising:
$5000 - $507f | 6532 (RIOT) volatile RAM (128 bytes) |
$5400 - $5403 | 6532 (RIOT) I/O ports (see below) |
$57FF | 6532 (RIOT) timer - this is unused in the code from what I can see |
$5800 - $5fff | EPROM image (max 2048 bytes addressable) |
As the EPROM starts at $5800, the code running calling point at $58A0 (the first 160 bytes are given to a copyright message followed by a whole heap of NOPs).
Code start point is stored at $5FFA as called by the 6502 on initialisation.
The 1983 copyright has in it:
K.DRAPER(0225)705600 EXT28I am wondering if K Draper is still about and might be able to chat about some of the design decisions involved... drop me a line if you know, please!
The 6532 has two 8-bit IO ports (PA and PB). Pin direction (I/O) is set as a bitmask at $5401 and $5403:
0x01 | PA0 | I | Tone arm D1 microswitch input | PB0 | O | D1A (fwd) cue button |
0x02 | PA1 | I | Tone arm D2 microswitch input | PB1 | O | D1B (rev) cue button |
0x04 | PA2 | O | Select D1 cue | PB2 | O | D2A (fwd) cue button |
0x08 | PA3 | O | Select D2 cue | PB3 | O | D2B (rev) cue button |
0x10 | PA4 | O | Mute D1 enable | PB4 | I | Audio sense input (hooked to -15dB on LED ladder) |
0x20 | PA5 | O | Mute D2 enable | PB5 | I | Autocue on/off switch |
0x40 | PA6 | O | D1 LED out | PB6 | I | D1 deck start pressed |
0x80 | PA7 | O | D2 LED out | PB7 | I | D2 deck start pressed |
I=input, O=output, obviously. So push PB1 high if you want deck 1 to reverse, or PA1 goes high when deck 2's tonearm is lifted.
The unit I have here employs CL300D decks and my Autocue PCB is PCB1038 Issue E.
I had some interesting moments as my PCB diagrams have the reverse and forward buttons the other way round. Explanation follows from Malcolm Barnes...
"If it rotated in reverse to start, it's usually a very early unit and AFAIK this was corrected in the EPROM prog. You could trick early machines to play backwards... I have seen at least 5 variants of the mecha PCB which all at a glance looks the same. The early BSR TTs employed different motors and arm rest sense, so the PCBs are slightly different and not directly interchangeable without accepting speed variables with different feedback sensing (motor current)."
I discovered another autocue_rom.bin binary (see FB groups below) which was different, but only in that it had $EA (NOP) at address $5F5C. My original had $E2 (illegal opcode) at that location, which I've put down to bitrot in bit 3 of that particular byte. I am therefore thinking the main deployed version is V2.19AN as written on the label.
If you own a Citronic 'Micro' console (Tamar, Thames-II, Isis) and would be willing to provide me with a dump of your version of the EPROM - expecially if it uses BSR decks - that'd be really superb please, as I can always augment the disassembly with version branches.
There are several limitations owing to the way the Autocue has been designed, the principal one is that it can only cue one deck at a time as there's only a single VU meter and cue has to be switched to the focus deck. However it may be possible to stack cue requests so that a second deck can start its autocue process once the first has completed and the LED starts flashing. (The code does have some stack implementations in it although this is more to do with temporary variable storage.)
In some cases the autocue process will not start on the second deck if the first one has its LED flashing. I haven't worked out the pattern for this but suspect that it's to do with the polling mechanisms in the code.
It's also possible to confuse the autocue audio sensing by switching the cue channel halfway through the hunt, as there is no way of locking the cue for the duration. In an ideal world I'd probably build a little daughterboard to go in between audio channel and PB4 with an adjustable sensing pot, but this seems like a lot of work. Maybe something for the future.
Occasionally with dirty discs doing a click-and-pop, quiet passages and short lead-in times, the Autocue will "get it wrong" (indeed I've known Autocue reverse back enough to drop the stylus on the slipmat!). This is a problem common to all autocue implementations and arguably not even an autocue problem per-se, so I will largely ignore it for now.
I frequently upload my latest disassembly here with added notes.
Individual files:
Pre-ca65 manual disassembly, left here in case it's useful in the future. This is quite old and a lot has happened since this initial version:
There are limited possibilities owing to the way this has been put together in hardware, but the following has been mooted in pub brainstorming. This is little more than a jotter for ideas right now which may or may not be possible in hardware:
The Facebook group "Double Deck Consoles From Citronic & Others - old DJs and old gear!" has been an excellent source for circuit diagrams and other service data for the Citronic decks. I wouldn't have figured out the Autocue module IO anywhere near as quickly without it. Special thanks to Malcolm Barnes, the grand wizard of all disco consoles.
My hardware hacker friend Ray Bellis has been absolutely invaluable in working things out, converting the initial disassembly to a ca65 build, and providing pointers where I needed them.
I'm also indebted to Norbert Landsteiner's online 6502 disassembler, which is quite an excellent tool. Thanks Norbert!
Finally thanks to Rachel, and all my other pals on FB and Fedi who also gave me a hand figuring it out.
That's cute, ta.
This is a hobby project. if you want to show some appreciation something nice off my Amazon wishlist would be lovely! Or even better, make a donation to The Good Law Project's fight for transgender rights.
More about me and some links elsewhere on the index