Miroirs/mame
1
0
Fork 0
mirror of https://github.com/mamedev/mame.git synced 2024-11-16 07:48:32 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 3

docastle: update notes

Browse source
This commit is contained in:
hap 2022-09-01 21:02:41 +02:00
parent 67be13960b
commit b18ac4c63e
2 changed files with 28 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
src/mame/universal/docastle.cpp
View file

@ -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)

21
src/mame/universal/docastle_v.cpp
View file

@ -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;