diff options
author | MetalliC <0vetal0@gmail.com> | 2020-08-18 19:55:03 +0300 |
---|---|---|
committer | MetalliC <0vetal0@gmail.com> | 2020-08-18 19:55:03 +0300 |
commit | d2d1540681c6bb85e6f10e68645aad49110ed7d8 (patch) | |
tree | cdeb6439d1b64385027fc3cda2315e1129daead7 | |
parent | e96932a60bd676f29612caa6faa204a781bd2710 (diff) |
midxunit.cpp issue note update, cleanup security chip access
-rw-r--r-- | src/mame/drivers/midxunit.cpp | 19 | ||||
-rw-r--r-- | src/mame/machine/midxunit.cpp | 14 |
2 files changed, 24 insertions, 9 deletions
diff --git a/src/mame/drivers/midxunit.cpp b/src/mame/drivers/midxunit.cpp index d47202dfb11..c233650567f 100644 --- a/src/mame/drivers/midxunit.cpp +++ b/src/mame/drivers/midxunit.cpp @@ -12,13 +12,18 @@ Known bugs: * POST test ends with "CUSTOM CHIP U76 BAD" message, - however this is caused by fully clipped blitter DMA request: - DMA command 8003: (bpp=0 skip=0 xflip=0 yflip=0 preskip=0 postskip=0) - offset=00000000 pos=(0,257) w=448 h=1 clip=(0,0)-(511,0) - palette=0505 color=0000 lskip=00 rskip=00 xstep=0100 ystep=0100 test=0000 config=0010 - it is not clear if it's due to DMA emulation flaws (unemulated command bit 6 - clipping mode, 0=offset??? method), - or if some protection device may modify routine code in the RAM (unlikely). - set BP 20D31340 to see check routine (notice: 20D31550: MOVE A14,@C08000E0h,0 have no effect because of FS0 selected). + However, this is caused by failed blitter DMA test, it's buggy code: + 20D31460: MOVI 100000h,A14 ; control register value, set H-clip access + 20D31490: MOVE A14,@C08000E0h,1 ; 32bit write control reg + 20D314C0: MOVI 1FF0000h,A14 ; H-clip range value 0-511 + 20D314F0: MOVE A14,@C08000C0h,1 ; 32bit write H-clip reg + 20D31520: MOVI 300000h,A14 ; control register value, set V-clip access + 20D31550: MOVE A14,@C08000E0h,0 ; 16bit(!!) write, upper word ignored in MAME, control reg still set to H-clip access + 20D31580: MOVI 1FF0000h,A14 ; V-clip range value 0-511 + 20D315B0: MOVE A14,@C08000C0h,1 ; 32bit write, in MAME write goes to H-clip registers + in result of not set V-clip range in MAME the whole DMA request is clipped. + It is possible X-unit DMA registers block C08000xxh access is 32-bit only (/CAS0-3 lines ignored), so any write access always update whole 32bits. + At the moment TMS34020 incorrectly emulated as 16bit wide data bus CPU, so we can't properly handle this issue. *************************************************************************** diff --git a/src/mame/machine/midxunit.cpp b/src/mame/machine/midxunit.cpp index 762a092b331..2bcda95e389 100644 --- a/src/mame/machine/midxunit.cpp +++ b/src/mame/machine/midxunit.cpp @@ -267,6 +267,8 @@ void midxunit_state::machine_reset() m_dcs->reset_w(0); m_dcs->reset_w(1); + m_security_bits = 0; + /* reset I/O shuffling */ for (int i = 0; i < 16; i++) m_ioshuffle[i] = i % 8; @@ -290,14 +292,22 @@ uint16_t midxunit_state::midxunit_security_r() void midxunit_state::midxunit_security_w(offs_t offset, uint16_t data, uint16_t mem_mask) { if (ACCESSING_BITS_0_7) - m_security_bits = data & 0x0f; + { + m_security_bits &= ~0xf; + m_security_bits |= data & 0xf; + m_midway_serial_pic->write(m_security_bits ^ 0x10); + } } void midxunit_state::midxunit_security_clock_w(offs_t offset, uint16_t data, uint16_t mem_mask) { if (offset == 0 && ACCESSING_BITS_0_7) - m_midway_serial_pic->write(((~data & 2) << 3) | m_security_bits); + { + m_security_bits &= ~0x10; + m_security_bits |= BIT(data, 1) << 4; + m_midway_serial_pic->write(m_security_bits ^ 0x10); + } } |