trunk/src/mess/drivers/minicom.c
| r31394 | r31395 | |
|---|
| 27 | 27 | |
| 28 | 28 | Changelog: |
| 29 | 29 | |
| 30 | 2014 JUL 22 [Felipe Sanches]: |
| 31 | * Fixing alignment of 14-seg display multiplexation |
| 32 | |
| 30 | 33 | 2014 JUL 19 [Felipe Sanches]: |
| 31 | 34 | * Got the display working except for a few glitches |
| 32 | 35 | |
| r31394 | r31395 | |
|---|
| 126 | 129 | { |
| 127 | 130 | case 0x00: |
| 128 | 131 | { |
| 129 | | m_p[offset]=data; |
| 132 | if (data != m_p[offset]) |
| 133 | { |
| 134 | m_p[offset]=data; |
| 135 | |
| 136 | //Bit P0.1 is the serial-input of a 20-bit shift register (made of a couple of chained UCN5810AF chips) |
| 137 | //We are emulating the display based on the assumption that the firmware will multiplex it by defining one digit at a given time |
| 138 | //It would be better (in terms of being closer to the actual hardware) to emulate the 20 bit shift register and update all digits |
| 139 | //for which a bit is TTL high. It seems to me that in the real hardware that would result in dimmer brightness in the display and it |
| 140 | //does not seem trivial to me to implement this using our current layout system. I'm leaving this note to whoever finds it exciting |
| 141 | //to explore these possibilities (perhaps myself in the future?). |
| 142 | if (BIT(data,1)){ |
| 143 | m_digit_index = 0; |
| 144 | } |
| 145 | } |
| 130 | 146 | break; |
| 131 | 147 | } |
| 132 | 148 | case 0x01: |