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

possibly these systems should use IPT_KEYPAD which does not trigger the modal behavior and was introduced for this exact reason

We need to be able to "focus" keyboards, so you can emulate a system with two keyboards and type on them both using one keyboard. If we had a system that allowed that then controlling the emulator could just be another "keyboard".

Basically it would need to detect mapping conflicts and if there are any then somehow allow you to select which device wins.

It probably shouldn't be limited to keyboards, but the method to switch between other devices may get complicated. You might for example have two keyboards and two joysticks, the keyboards could have some conflicts with each other and the joysticks conflict with each other. But one of the keyboards could conflict with one of the joysticks. The non conflicted keys should always work no matter what device is selected.

Here's the driver for elecdet:
https://github.com/mamedev/mame/blob/master/src/mess/drivers/elecdet.c

I have no clue how to play this game, but I think I have everything right. The romdump looks fine as is, I could double-check it when you've make a post-acid die shot.

I'm hopeful it will be warm enough on Thursday to Whink some chips.

I torched the TMS1400 from Split Second today and took pics: www.seanriddle.com/tms1400.html

I also uploaded a 6000x5000 pixel XCF: www.seanriddle.com/splitsecond.xcf

It has double the ROM space of the TMS-1100; the ROM array is twice as wide. I haven't figured out the mapping yet, but my guess is that the rows are mapped the same as the TMS1100, the first 16 bits in each row are bit 7 for the 16 pages in chapter 0 (in the top half, chapter 1 in the bottom half), and the second 16 bits in each row are bit 7 for the 16 pages of chapter 2 (in the top half, chapter 3 in the bottom half). The next 16 bits would be bit 6 for chapter 0, then bit 6 for chapter 2, etc.

The O output PLA looks the same, but with the full 32 possibilities instead of the 20 that the TMS1100 was limited to.

The instruction PLA looks the same but rotated 90 degrees counter-clockwise on the die.

The only datasheet I've found for it is on Kevtris' site, linked from my page above. To handle the additional ROM chapters, the COMC instruction was changed to TPC. It also has a 3-level subroutine stack!

The rest of the Split Second hardware is pretty simple: 6 buttons, a speaker, and 53 LEDs in a 7x8 matrix.

I think these are the instructions

http://www.samstoybox.com/toys/instruct/electronicdetective/elecdetect01.html

Sean: do you have the raw romdump of Split Second?
eta: yup that's the manual, thanks =)

Not yet- I haven't removed the top metal layer, so the contrast between 0 and 1 bits isn't enough for my program to detect. I'm transcribing them manually, but there are 32768 bits! If not for this pesky job, I'd be done....

Here's the two NatSemi application notes for dumping the COPS mcus.
I didn't link this before because I thought what I linked WAS this:
http://www.ti.com/lit/an/snoa631/snoa631.pdf
and here's what I linked before, which is an addendum to the above:
http://application-notes.digchip.com/006/6-9487.pdf

LN

LN- thanks. I think the addendum has all the info you need, but the appnote has even more!

I uploaded the Split Second raw ROM dump and a rearrangement like the TMS1100, but with every other column of 16 bits treated as chapter+2 (that's just a guess without trying to disassemble the resulting code; it could easily be that the chapter+2 column comes first). There are about 7 obscured bits that I'll double-check after removing the top metal layer.

www.seanriddle.com/splitsecondraw.bin

www.seanriddle.com/splitsecond.bin

I'll document the hardware tomorrow.

"Ahhh, what an awful dream. Ones and zeroes everywhere... and I thought I saw a two."