Home Page Forums MAME MAME TMS-09xx/1xxx thread (was New Dumps)

ah nice. I wanted to try and dump my milton without frying the chip open. I thought it was a 6804 instead of a 6805 going by the pinout. this is a similar chip but is bit-serial so the die is smaller (but runs slower). I think I figured that out via the pinout, but I could be wrong on that. it was a couple years ago.

Guess if it's a 6805 I can try the usual "secret" dumping method on it.

At least one variant of the 6805 has the same pinout as the 6804. The Milton chip and die don't have the part number, but one of the 6804 manuals compares the 6804 die with the 6805 die (to show that it's smaller, like you said) and the Milton die is identical to the 6805 die in that pic. I also found a book that went along with a 6805 seminar that has some parts of the 6805 die annotated. And the ROM array on the Milton die has the same weird number of bytes as the 6805 data sheet shows - 1216 (128 bytes of zero-page ROM, 964 bytes of user ROM, 116 bytes of self-test ROM and 8 bytes of vectors).

I searched for info on dumping the 6805, but it remained secret to me!

ok so it IS a 6805. Good to know. LN and balrog hooked up a logic analyzer to their device programmer and traced what it did to dump the ROM out, so I did the same thing on the allpro and it seemed to work. I dumped a number of 68705's anyways and it worked. I believe I dumped a few 6805's as well, but all 40 pinners (except the 68705's which there were some 40 and 28 pin variations).

it's been a couple years so I forgot how it all works though.

IIRC it involves pulling one pin (one of the port C pins? pins 7,8,9,10,or 11?) to +12v on /RESET to kick the chip into test/debug mode.

In that mode, assuming the chip is not a 68705p5 with the secondary security bit set, you can synchronously feed bytes to port A and the chip will execute them as opcodes (I think it may immediately execute the words meaning you need to manually 'make up' immediate-value-only code to move your real program into the 0x0000-area ram, then jump to that to run it). This is used to put a small program into the 68705's memory, which spits the rom contents out port B sequentially, using port A or part of C for timing?

This works even on "protected" 68705P3 chips, where the protection bit on the very last eprom byte (actually a sort of flag/mode byte) before the mask rom is in memory is set. (if this bit is clear, I forget what the difference is)
The 68705P5 version added a second security bit which when set I think prevents port A from being read by the mcu (at least in test mode), effectively locking out the test/debug mode.

There is the 'other' more well known 68705 flaw however which still works on the P5, the one involving the built in rom's verify mode taking a different number of cycles to toggle the 'increment external address' line when in verify mode depending on a byte match or mismatch, which allows a 256 passes of one of each byte attack to dump the internal rom contents.

The 68705P5 attempted to prevent that by making the test/verify mode vector point to 3 bytes before the end of the eprom (which is immediately before the start of the mask rom/test code) with the intent that you would put a jump to the normal reset vector there to disable the test mode completely as protection, but this can be bypassed with voltage glitching to make the eprom bytes read as 0x00 (NOP).

We have yet to demonstrate this attack against a protected 68705P5 (from taito games etc), but according to what appears to be testimony from people in the security industry who dealt with these mcus before, that trick does work for dumping protected P5 chips.

LN

Woo-hoo, I've got bits. Thanks! I was just missing grounding RA3.

Ah- I had seen some of the 68705 stuff (like verifying the ROM 256 times!) But I didn't think any of that would be applicable to the 6805 with its mask ROM.

Plastic stuck to the die, and I wound up torching it a bit too much. Most of the bits are readable, but I'm worried there might be a few ambiguous ones- the ROM bits are more subtle (like the 3853, not easy like the TMS1000). And I couldn't get a top metal shot because of the stuck plastic.

I'm not sure if the 68705 stuff DOES apply to 6805, but given both the 6805 and 68705 appear to have that internal 'fixed' rom of 81 or 116 or whatever bytes or so, then it may apply to both. the internal fixed rom contents may be different though.
The EPROM-based chips (68705p3 and p5, and u3/u5 which are 40 pins I think) fixed mask ROMs are dumped, so having the MASK-rom-based chips (6805px/ux) fixed mask ROM could be very useful.

LN

I uploaded the Tandy Baseball info: http://www.seanriddle.com/pic1650a.html

I dumped the 6805 visually, then disassembled the code and found one obvious bit error in the self-test code. After I fixed that I ran the self-test code and the ROM checksum didn't match. It just does an XOR of every byte and only one bit was wrong, so I checked that column in the ROM array and found a bit I had missed. Now the checksum is correct, but since it's just an XOR, it's possible that I still have other errors that cancel out.

Putting 9V on the timer pin for self-test mode moves the vectors up 8 bytes in memory, so you get new reset and interrupt addresses. The self-test code checks the ports then does a RAM test- it fills RAM with the pattern 00 80 40 20 10 08 04 02 01 then verifies it, then shifts the pattern to 80 40 20 10 08 04 02 01 00 and verifies it, etc.

Then it does the ROM test, XORing all the bytes from $080 to $7FF (including unused bytes, which must all read the same and therefore don't change the checksum). The ROM test is done with self-modifying code, using some of the residue from the RAM test! I guess they were trying to cram as many tests as possible into the smallest amount of ROM as possible.

I noticed that the old sim6805 program coded the CLRA opcode incorrectly by also clearing the carry bit (which messed up the RAM test code), so I checked the MAME/MESS code. CLRA and CLR direct are OK, but CLRX and the 2 CLR indexed opcodes clear the carry bit. The data sheets I have say that carry is unaffected.

I don't see a way to dump ROM using the test mode (normally or "creatively"), so I guess we'll have to figure out non-user mode. Unfortunately, my 6805 die got pretty cooked and I don't have a top-metal shot, so it's probably not too useful.

www.seanriddle.com/mc6805p2.html

I found a few more incorrect bits and updated the files. I think it's about as good as I can do it visually with this die. The test code runs and passes the ROM checksum, and the disassembly looks good. Next time I use acid on a chip, I'll see if I can clean this one up a little more and see if anything looks different.