Any 6500/1 experts out there?

[Studio263]

Does anyone have any experience in programming the 6500/1 microcontroller IC? This is a 6502 derrivative but includes 2k of ROM and 64 bytes of RAM on board, along with a few other tasty bits and pieces. It appeared in the late 1970s and seemed to be in use until at least the mid 1980s.

The key questions are:

1) is it possible to read the contents of the ROM part?
2) if so, what equipment would be needed to transfer the recovered programme onto another IC?
3) Is the ROM reusable or is it a one write only device?
4) If one write only, are there any "blank" ICs still in circulation?

(very) basic data sheet attached. Can anyone point me in the direction of some further reading on this device?

[KeithsTV]

As it's a mask programmable device the program will have been put in when the chip was manufactured so I doubt if it's possible to read the ROM contents or reuse it.

Keith

[8 Tracker]

Looking at the data sheet, doesn't "mask programmable ROM" mean programmable at the time of manufacture?

To get at the programme, I think you would have to write a small routine on the chip to output the contents of the ROM to a set of the output ports, as there are no address and data lines available on the 6500/1. But then you can't get a routine into the chip for the same reason. If you had the /1E device, that would be easier as the lines are available.

An interesting device, by the way. NCR, is that National Cash Registers?

Mark.

[mike_newcomb]

Hi Mark, NCR is/was National Cash Registers, who at one time produced mini computers (NCR Century). The ones I saw looked weird, having keyboards that reminded me of comptometers.

Here in London, their now demolished offices were near Brent Cross

Studio - I understood there is a NCR Museum, which if correct, may have more details for your programmer.

Regards - Mike

[8 Tracker]

Thanks for the info, Mike. Interesting.

Thinking about it, there really is no way of getting the programme off the chip, so unless you know what is was programmed for in the first place, any chip you had would be useless.

Mark.

[Studio263]

A bit more background:

This chip is used in B&O's first computer controlled receiver, the Beomaster 8000 of 1980. It uses two in a master / slave configuration to deal with radio tuning and source selection, remote control, digtial readouts, interaction with the other units in the system (tape recorder, record player) and volume / balance control.

After working without problems for many years my own 8000 has now developed the fault where only the standby light shows and nothing else works. The +5V line is up, the reset line is not asserted and the crystals of both 6500/1s are oscillating at the correct 2 MHz, yet there are no other signs of activity (no keyboard strobe for example, this should be running all the time that the unit is powered). I have tried a "manual reset" using the shorting link provided while the power is on but this does nothing. There is a little ripple in the supply to the chips suggesting that the clock dividers are working but the lack of any other activity suggests to me that either the programme counter is stuck at 0 for some reason or the internal memory has been wiped somehow.

I think if I asked really nicely I could borrow another (functioning) unit from somewhere to copy the chips from it that was possible but it seems from the replies already that that won't work. My "fallback" plan is to construct a whole new microprocessor PCB using PIC devices and programme those to mimic the functions of the original systems, this is currently at the boundary of my technical knowledge but with a bout of serious study and a huge amount of work I could probably acomplish it in a year or two...

[G0HZU_JMR]

I haven't done anything in the past with the 6502 but I have found ways to get at the masked ROM of various 68xx chips from the 1980s.

My guess would be that there will be a (factory) way to verify the ROM contents on your chip and it probably involves setting one of the pins at a certain voltage when the chip comes out of reset. If so, then this will open up a factory exploit that allows the ROM to be dumped out of the chip. eg it may allow the chip to have a custom reset vector or maybe it just lets the chip count through all its addresses in a test mode.

In my case I managed to get the 680x based chip to run my own code which asked it to spit out its internal masked ROM.

[SiriusHardware]

Without knowing any specifics of the circuit, a few more things to consider:

Does the unit include either / or a dedicated battery backed realtime clock IC or a battery backed memory IC (for retention of system settings, stored radio frequencies, etc).

If it has a realtime clock, one of the first things the system may do when it powers up is to try to read the time from it. If it fails, it may just hang there and not proceed to the next step. In a system which uses an RTC which runs primarily from its own local battery and is only charged from the DC supply when active, a failing battery may no longer be able to supply enough voltage / current to run the RTC.

Similar for battery backed RAM - if such a facility exists the system may try to read the current parameters from it as soon as it starts up - if the contents are corrupt it may not be able to proceed further. The same can also occur with other types of non volatile but changeable parameter memory such as Flash / EEPROM - corrupted contents may prevent the system from starting up at all.

Keypad and other momentary-press buttons: Are any of these physically or electrically stuck on? Very often, key scanning schemes wait until a pressed key is released before continuing. If the unit is immediately finding what it thinks is a pressed key, it may hang forever while it waits for the key to be released, and not proceed to any of the other tasks it is expected to perform (such as display initialisation / management).

[G0HZU_JMR]

Some good points there from Sirius...

To reinforce what is being suggested by Sirius, the 680x chips I dumped the ROM from had a dedicated pin to allow battery backed RAM. It looks like the 6500/1 is the same?

One of the first routines in the ROM (in my case) was an internal checksum of the ROM and also a AA/55 read/write pattern test of all of the internal RAM except the RAM that held status/error codes. This bit of RAM used mirroring as a means of self checking so each error code byte was stored along an inverted /mirrored version of itself.

Obviously, if there was a problem with the (external) voltage feeding the internal RAM then the RAM write/read tests would fail. From memory, the system then reset itself via an external watchdog and it tried again (and again...) to pass the internal ROM and RAM tests. It would not allow the main program to run with a fail in these tests because this MCU chip was inside a car engine ECU and it would cause a safety issue if the RAM was unreliable...

So it's definitely worth checking with a scope that the battery pin Vrr stays at a healthy voltage level throughout the initial startup routine.

[Studio263]

Originally Posted by SiriusHardware

Does the unit include either / or a dedicated battery backed realtime clock IC or a battery backed memory IC (for retention of system settings, stored radio frequencies, etc).

Keypad and other momentary-press buttons: Are any of these physically or electrically stuck on?

There is no battery, the user data is stored in NV RAM (TMS 3529). Vrr is returned directly to the same +5V supply that runs everything else (present and correct).

I've disconnected the keypad completely but still no activity at all.

[SiriusHardware]

Ok - regardless of how exactly the NVRAM retains its content, how easily can you remove it? If it's not too difficult to do, try removing it temporarily and switching the unit on - does that alter its behaviour in any way?

(This is to pursue the possibility alluded to earlier, that the system may be halting because it is finding corrupt / nonsense / out of bounds data in the NVRAM).

Without the device in situ, whatever tries to read it will probably read all the locations it tries to access as either all 00 or all FF, which will also be invalid of course, but it would be interesting to see what (if any) difference presenting it with different data will make.

Are you able to say a little more about the fault history? Was it switched off (working) and switched back on and found to be no longer working, or did it fail while it was actually running... or do you not know?

[Studio263]

Originally Posted by SiriusHardware

Are you able to say a little more about the fault history? Was it switched off (working) and switched back on and found to be no longer working, or did it fail while it was actually running... or do you not know?

Well I wasn't there at the time but this is the story I got: I was using it in the morning and because of the elaborate shut-down sequence that the computer performs when the unit goes into standby I forgot to switch the system off at the mains before I went to work. When I got home my wife told me that the baby had got into the listening room and put the set onto Radio 3 and turned the volume right up, that's 2 x 150W into large, efficient loudspeakers(!!!). She then came running down the stairs and to stop the noise pulled the mains plug out of the wall, thus circumventing the shut-down programme (which turns the main power-consuming circuits off in a pre-determined order). When I came home I tried the set again and discovered the fault condition described at the start of this thread.

My guess is that the colapsing field in the mains transformer has caused a spike on either the power supply to the microcomputer or on one of the data lines (which go everywhere) and caused the problem.

The NV RAM is in a socket so is easily removed, I will give this a try and report back.