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

Cool! I uploaded a scan of the D&D playfield. The printed part is glued onto a folded plastic piece with conductive traces, like a lot of games. I tried to remove it, but it's stuck on so well that it was pulling off the paint, so I scanned it as-is. That means you can see some of the traces through the printing, but that's how it really is. The case covers up a lot of it anyway- just the centers of each square are visible.

D&D is interesting; just 72 buttons and a speaker. But it's another one of those electronic games with pieces, which makes it more difficult to emulate in MESS.

I uploaded pics of the Little Professor 1982 LCD. One pic has all the segments on, and 3 others are the different segments that make up the Professor's face.

http://www.seanriddle.com/tp0456.html

I posted info on Texas Instruments Spelling B that Hap sent: www.seanriddle.com/tmc0270.html

Great! =) looking forward to emulate it.

I finally got a good dump from the TMC0355 in MrChallenger, so I posted that info, too: www.seanriddle.com/tmc0270.html

I've dumped TMS6100s and TMC0430s before, so I figured the TMC0355 wouldn't be too hard, but it gave me some trouble. It outputs 4 bits at a time instead of 1 bit like the other chips I've dumped, but that was easy to fix. But it looks like it is using an internal oscillator that I couldn't figure out how to disable, which gave my PIC-based dump hardware issues.

If I tried to clock it with the PIC, it mixed its clock with mine and bytes were skipped. If I left its clock disconnected or tied low, no data came out. If I tied it high, then data came out, but because I wasn't clocking it, the M0/M1 signals I sent to load addresses and read nibbles weren't synced. For large stretches of bytes, everything was OK, but occasionally nibbles were missed.

I was going to have the PIC sync to the ROM's clock, but the datasheet says that the M0/M1 edges need to be within 1 uS of the clock, which is pretty tight. So first I checked 144 of the dumps that I had made with the clock tied high, and found that 27 of them matched. I examined that data and figured out it was a simple dictionary of the words the game uses; top of ROM has 2-byte pointers to the words, which are stored 0=A, 1=B, ..., 25=Z, with the high bit set on the last letter. I wrote a program to make sure the data was consistent, so I'm sure the dump is good. I can decap the chip and visually compare if needed.

Is there any news on emulation? Can these games can be dumped using software? Has somebody already dumped these?

I have the Nu Pogodi IM-2 here, but apparently some (battery?) fluid got inside the LCD, rendering the left side semi-useless. Maybe someone more knowledgeable can salvage it?
PCB is in a rough shape, I suspect it met water at some point, but the game works nonetheless. IC is unmarked, but pinout seems to match КБ1013ВК1-2 from Russian thread.



cYa,

Tauwasser

Yes, last time I chatted with MetalliC he let me know that Sergei has dumped(decapped) a couple more of these.

In MAME, I will add them when the parent CPU emulation is mature enough. For this, we need more test data first(aka Nintendo and Konami LCD game dumps).

The type of damage shown indicates the lcd glass itself is cracked, and the black stuff is the lcd material itself leaking or oxidizing due to air or moisture getting in through the crack, or some similar process. It is not fixable.

LN

Well, maybe I should have mentioned it earlier, but whatever. The black color is only visible through the polarizing film. When I took it apart, I could see the intended shapes on the LCD as well as this liquid, no obvious crack, so I doubt it's oxidation, but still probably not fixable.

However, maybe someone more knowledgeable than me could still use the LCD to take pictures of the shapes using some kind of polarizing filter? How are the shapes dumped (for a lack of a better term) anyway?

Anyway, any takers for this game let me know, I'll ship it. Willing to get this thing dumped even if it's only for confirmation of the ROM that's floating around.

cYa,

Tauwasser

I've had a little luck taking pics of an LCD through my microscope like a chip die, but for many of them, I can't get enough contrast to be useful, even with polarizing filters.

I bought some PIC microcontrollers with LCD outputs, but haven't had a lot of luck driving panels with them. For the TI Little Professor with an LCD panel, I used a signal generator to create a 100Hz or so sine wave and varied the amplitude around 2V until I got good contrast. Then I applied that signal to the different inputs to map them, and then connected it to all the inputs to get a picture of all the segments.

I need to work on a better way to get pictures. The panels have conductive traces instead of wires, and it's tough to connect to them. Usually there's a little rubber piece that has conductive material in it that is sandwiched between the LCD panel and the PCB, but it has to be squeezed pretty hard to get all the connections to conduct. So the best bet would be to modify the existing game case to get access to the connectors. I didn't have that option with Little Professor because there is no PCB- it uses a sheet of plastic with traces on it, which is difficult to solder to because the plastic melts. So I built a little jig to connect a PCB to the panel, but it's not flat on the front to fit on my scanner, which means I had to take pics, and it was hard to get straight-on shots without glare.

And even the simple Little Professor panel has 72 segments, which is a lot to map out. It has 7 7-segment digits, and those formed a logic pattern, which helped. A game like Top Gun has over 100 segments- see patent US5137277. It would be very time-consuming to describe each segment, so it seems like the best bet would be to take one picture per segment. That means an automated system would be helpful.

I'll finish mapping Top Gun's LCD segments so Hap can work on the driver some more.

If no one else responds about the Nu Pogodi you can ship it to me. I can try a different polarizer to see if that helps the blob issue. I'll be working on dumping Sharp SM5xx MCUs again in a week or so, so I might be able to dump it electronically. Worst case, I could decap it and read the ROM visually, but that would destroy the MCU.