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

I scanned 35 TMS1100 and TMS1000 dumps currently working in MAME, looking for BR/CALLs that this method would miss. The average number of bytes per dump that have the same lower 6 bits as the next PC address is 32: the range is from 3 to 61. The average number of these that are really BR/CALLs is 7, ranging from 0 to 23.

This is higher than I was hoping, since these would have to be determined by running the ROM and looking for issues, or doing code analysis to determine if the opcode is really a BR/CALL.

I thought about using a similar method, shifting in an address, executing the opcode there, then shifting out the ROM byte at the next address. This could identify jumps to different pages, since the ROM byte at an address in one page is usually different from the ROM bytes at the same address in the other 31 pages. It would not identify a jump to the same page, which I guess is used as a NOP. But doing the analysis, I was surprised how many times the ROM byte was found at the same address of a different page: an average of 32 jumps are to addresses with the same lower 6 bits as the next PC address, and an average of 14 of those have the same next ROM byte in at least one other page. And since shifting the opcode out destroys the chapter and page, we can't shift out multiple bytes to uniquely identify the chapter and page.

By dumping the whole ROM first (lower 7 bits) and then testing for bit 7, don't you already know the page it's supposed to go to from LDP?

I mistyped above, but I don't think it matters much: "an average of 32 jumps are to addresses" should have been "an average of 32 possible jumps are to addresses".

Testing for bit 7 only works if the BR/CALL isn't to the same PC as the next one that would have been executed if the opcode wasn't a BR/CALL. It can't tell if a 01 opcode at the beginning of a page is an ALEM instruction or a BR to PC 01, since the results are the same in both cases.

With the second method, if the next opcode dumped was not the one from the current page, then you'd know the original opcode was a BR/CALL. What I found from analyzing the dumps is that almost 1/2 of the possible jumps are followed by an opcode that is also in the same position of another page. So you still can't tell if the original opcode was a BR/CALL. My first thought was to dump a few more bytes so you could uniquely ID the page, but you can't dump any more bytes because shifting the opcode out destroys the page.

I posted info on Coleco Electronic Quarterback: www.seanriddle.com/tms1100.html

Quarterback was dumped electronically, right?
And what is TP2 pad on K8?

Yes, I dumped it electronically and then decapped it to compare.

TP1 and TP2 are test points at the bottom of the PCB. They are accessible with the battery compartment lid removed. I forgot to list TP1; it's connected to R0.

If you turn the game on with TP1 connected to TP2 and then press up, down or left/right, the display shows 8.8.8.8.8.8.8.8.8. If you press Pass/Kick, it plays a tune.

I wound up with another unit that has an older PCB revision but a newer TMS1100. It's still labeled MP3415, but this one is a Rev E. Both units have the TMS1100 in sockets, which is unusual.

ok, Coleco Electronic Quarterback is added and playable =)

Cool!

I played with the TMS1100 rev E from Lost Treasure, seeing if I could get it to dump all 8 bits. Most of the dumping process has the reset line asserted, but you have to release it for a few clocks to get the data to dump. I changed the timing of when reset is released, and was able to get all 8 bits to dump. But when I tried it on other Rev E dies, it didn't work. The Lost Treasure MCU is a 28 SDIP marked DES, and I don't have any others marked the same to test. I decapped it and I'll confirm that the 8-bit dump I got was correct.

I still haven't had any luck dumping the O output PLAs from TMS1000s or Rev E 1100s. I'm not sure why it's not working.

I confirmed that the electronic dump of Lost Treasure is correct, and posted the info: www.seanriddle.com/tms1100.html

I wonder if something about the O PLA is different on this chip. When you release a TMS1100 from reset, that clears the O register, so the PLA entry for 0 is output. After making changes to the timing of the dumping process, I noticed glitches in O7 that corresponded to ROM bits that had bit 7 low. But the glitches weren't in identical places on multiple dumps. Then I put a pulldown resistor on O7, and that made all the dumps match. So it looks like O7 is not being driven for a brief moment after reset is released if the bit is low. But the other rev E chips that I tried didn't respond like that.

I posted info on Coleco Zodiac: www.seanriddle.com/tms1100.html

I dumped this one electronically and can't figure out the O PLA: the first 16 values are the numbers 0-9 and letters A d E J L U, leaving just 4 more entries in the PLA. The other 16 values can almost be represented using the 4 bytes 08, A0, 40, 06, but 5 of the 16 values don't match. I could make it work if there were 2 more entries in the PLA.

7E 0C B6 9E CC DA FA 0E FE CE EE BC F2 3C 70 7C
01 08 A0 A8 40 48 E0 E8 06 10 A6 B0 46 50 E6 F0