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

MAME doesn't emulate HLCD0569. I'll see what I can do in the coming days. If it's very similar to HLCD0515, it shouldn't be a problem.

Indeed, Mattel Computer Gin also uses the HLCD0569. Ideally the more test cases for a new emulated device the better, but the UCOM4 MCU dump was bad. I've reminded kevtris that it needs to be redumped.

It's very hard to use, even with the manual available, but it looks like Horse Race Analyzer is working now in MAME.

Cool! Yeah, it's pretty intense. I wonder how many people used it, and what the results were.

Do you want me to test anything with the HLCD0569? I've still got it hooked up to a PIC, so I could test any ideas you have. I think it's pretty much identical to the 0515, but they got rid of one of the columns to have room for the V DRIVE pin. I'm guessing DATA OUT is on pin 34- I'll try a read and see if it is. And I assume you can raise /CS at any time to stop shifting in bits early, and the remaining segments will keep their current state.

I saw you found a bad bit in Electronic Detective! I got out a couple of TMS0980s a few weeks ago to see if I could figure out how to electronically dump them, but they don't have osc inputs, so I don't know how to sync the K inputs to set the page and PC to dump.

Sure, let me know if pin 34 is DATA OUT or COL25. Also, I'm assuming internal RAM(aka segments) are updated after each CLK. If it's different, eg. after CS goes high, or specifically after the last CLK, I'll have to change the emulation a bit. Also try overclocking(:D) to see if it's ignored, or segments are rewritten from the 1st bit.

elecdet: Back then, my verification routine wasn't as accurate so I'm not that surprised it had a bad bit. Tester report is here btw: http://mametesters.org/view.php?id=6467

I can't believe how small the Electronic Detective ROM pic is! The bits are so tiny, I can see how one was missed. With my new workflow, my ROM array pics now have 15x the resolution. If you have any questions about any other ROM, let me know and I'll make a bigger pic of it.

For my verification step this picture size is fine actually, just have to zoom in, see: http://tsk-tsk.net/net/temp/elecdet_bits.png
The only annoying part is the black spots, then you need to compare metal to acid layer.

I'm now running 2 different bit reading algorithms on the TMS chips. The first looks for differences in brightness over a tall, skinny rectangle centered on each bit. It's good at finding the bits in a TMS ROM since one bits are outlined in black, there's nothing there for zero bits, and there's a gap between each row. It rarely has false negatives, but dirt specks can cause false positives.

The 2nd method looks for the red channel's maximum value in a square centered on each bit. It rarely has false positives, but has a few false negatives. I manually check the differences between the two results and select the correct bits, then visually double-check the entire array. When I manually check, I've found that drawing small white squares for the one bits works best for me. And the bigger bits help me.

Here are my HLCD0569 experiment results:

Pin 21 is definitely column 12. I don't know why HRA doesn't use it.

Pin 34 is not data out. I'm not sure exactly what it is, but when /CS is high it outputs a signal at the same frequency as the row and column signals, but with double the duty cycle. When /CS is low it is low. Since there are no other unused pins, it doesn't appear that you can read the data out.

Segments are updated when /CS goes high for that row.

Init blank (mode 10) works the same as init visible (mode 11); the display is not blanked.

The last clock before /CS goes high is column 24, even if there are more or fewer than 24 clocks. First I "underclocked", and after sending the row and mode bits, sent six 0s followed by a 1, then raised /CS, repeated for each row. The segments for column 24 turned on. Then I sent a 1, five 0s and a 1, and segments 18 and 24 turned on.

Then I "overclocked" and sent 30 bits instead of 24. Again, the last clock was used for segment 24, and the previous 23 clocks were used for segments 23 to 1. The 6 clocks before those were discarded.

Maybe the read/write mode bit is ignored altogether(also used for blanking). Can you check that? If mode is set to read, clocking data bits still writes segments?

*edit* Is the shift register auto cleared after mode/rowselect or the same contents as it was before? Or is RAM copied to the shift register?

I'll check those and let you know. I also now think that previously set segments in a row will be cleared when a row is "underclocked", but I forgot to check.