summaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
author hap <happppp@users.noreply.github.com>2022-09-01 21:02:41 +0200
committer hap <happppp@users.noreply.github.com>2022-09-01 21:02:53 +0200
commitb18ac4c63eb382d44812a5028f17b48d3f7f33a2 (patch)
tree15f5fa4f381fde2a7eb728e60c720e684d19f399
parent67be13960b2fffa5460c3e5dbb0a7f9736b87d3e (diff)
docastle: update notes
-rw-r--r--src/mame/universal/docastle.cpp20
-rw-r--r--src/mame/universal/docastle_v.cpp21
2 files changed, 28 insertions, 13 deletions
diff --git a/src/mame/universal/docastle.cpp b/src/mame/universal/docastle.cpp
index 145dddb3496..f8dbdd45581 100644
--- a/src/mame/universal/docastle.cpp
+++ b/src/mame/universal/docastle.cpp
@@ -117,7 +117,12 @@ Notes:
TODO:
-----
-- third CPU
+- Third CPU. According to schematics, it's a doorway for the sprite RAM. The
+ main cpu actually doesn't have full access to sprite RAM. But instead, 0x9800
+ to 0x9fff is a latch to the 3rd cpu. CPU3 reads 0x200 bytes from maincpu, and
+ then passes it through (unmodified) presumedly to the sprite chip. It looks
+ very much like hardware protection. And it's easy to circumvent in MAME by
+ pretending the maincpu directly writes to sprite RAM.
- docastle schematics say that maincpu(and cpu3) interrupt comes from the 6845
CURSOR pin. The cursor is configured at scanline 0, and causes the games to
update the next video frame during active display. What is the culprit here?
@@ -151,6 +156,14 @@ TODO:
- bad communication in idsoccer
- adpcm status in idsoccer
- real values for the adpcm interface in idsoccer
+- bad adpcm sound in attract mode for idsoccer clones (once you get them to boot up)
+- idsoccer clones lock up MAME after writing junk to CRTC. Workaround:
+ idsoccera/idsoccert: maincpu bp 1120 -> pc=1123 -> run
+ asoccer: maincpu bp 1120 -> pc=1135 -> run
+ Or simply ROM_FILL(0x247, 1, 0x23 or 0x35 instead of 0x20) on the slave cpu (not
+ guaranteed that a permanent ROM hack like this won't break anything).
+ This 0x1120 is a return address written to the stack after communicating with
+ the slave CPU. Maybe protection. See MT05419.
2008-08
@@ -250,9 +263,8 @@ void docastle_state::docastle_map3(address_map &map)
{
map(0x0000, 0x00ff).rom();
map(0x4000, 0x47ff).ram();
- map(0x8000, 0x8008).r(FUNC(docastle_state::docastle_shared1_r)); // ???
- map(0xc003, 0xc003).noprw(); // EP according to schematics
- map(0xc432, 0xc435).noprw(); // ???
+ map(0x8000, 0x8000).nopr(); // latch from maincpu
+ map(0xc000, 0xc7ff).noprw(); // sprite chip?
}
void docastle_state::docastle_io_map(address_map &map)
diff --git a/src/mame/universal/docastle_v.cpp b/src/mame/universal/docastle_v.cpp
index 9f4c4af2c77..d63b1fb8df7 100644
--- a/src/mame/universal/docastle_v.cpp
+++ b/src/mame/universal/docastle_v.cpp
@@ -78,13 +78,18 @@ void docastle_state::docastle_colorram_w(offs_t offset, uint8_t data)
uint8_t docastle_state::inputs_flipscreen_r(offs_t offset)
{
- // inputs pass through LS244 non-inverting buffer
- uint8_t buf = (m_inp[1]->read_h() << 4) | m_inp[0]->read_h();
+ uint8_t buf = 0xff;
- // LS273 latches address bits on rising edge of address decode
- flip_screen_set(BIT(offset, 7));
- m_inp[0]->write_s(offset & 7);
- m_inp[1]->write_s(offset & 7);
+ if (!machine().side_effects_disabled())
+ {
+ // inputs pass through LS244 non-inverting buffer
+ buf = (m_inp[1]->read_h() << 4) | m_inp[0]->read_h();
+
+ // LS273 latches address bits on rising edge of address decode
+ flip_screen_set(BIT(offset, 7));
+ m_inp[0]->write_s(offset & 7);
+ m_inp[1]->write_s(offset & 7);
+ }
return buf;
}
@@ -121,11 +126,9 @@ VIDEO_START_MEMBER(docastle_state,dorunrun)
void docastle_state::draw_sprites( screen_device &screen, bitmap_rgb32 &bitmap, const rectangle &cliprect )
{
- int offs;
-
screen.priority().fill(1);
- for (offs = m_spriteram.bytes() - 4; offs >= 0; offs -= 4)
+ for (int offs = m_spriteram.bytes() - 4; offs >= 0; offs -= 4)
{
int sx, sy, flipx, flipy, code, color;