HD62098 register 02 bits 4:0 during Yamaha AN1x startup #318
Unanswered
Northonone
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I am investigating the original Yamaha AN1x 1.04 startup with an H8/3002
CPU model. I am looking for programming documentation or an independently
recorded host-bus capture for the discrete HD62098 / XM309A00 MEG.
The relevant CPU-side facts from our conditional board/CPU analysis are:
4f72c8c595258ec9de83006287cc9b14f1450349a2253ebbf4d7437c22f95cbe.
0x400007, decoded as MEG register 03 on the documented board profile.
Later, after 1,606 driven MEG writes, its final store addresses 0x400005,
register 02, with all five subsequently polled low bits driven high.
A driven CPU write is not evidence of chip acceptance or readback.
The following mask consumes bits 4:0. Branch 0xd7a0 repeats at 0xd790
while any consumed bit is set; fallthrough to 0xd7a2 requires all five
consumed bits to be zero. Bits 7:5 do not decide this branch.
No selected device status, readback mirror or fixed completion delay
has been introduced to make it pass.
Could anyone provide a primary source establishing:
write-one-to-clear, command-triggered busy flags, or something else?
chip clock/synchronization and the external DRAM configuration?
successful initialization showing the preceding write and later reads?
For a capture, the useful signals are chip /IC, /CS, /RD, /WR, A0..A4,
D0..D7 and chip clock, with board/ROM identity, sampling rate and trigger
documented. The useful interval runs from reset/initialization through the
register-02 poll. One successful measured run would constrain that run;
we would not turn it into a universal reset or timing rule without support.
The AN1x service manual identifies the MEG pins (PDF page 12 / printed 17)
and board wiring. Its audio-based FX/DRAM diagnostic does not specify this
host-register transition. The MEG embedded in SWP30B is a different target
and has not been used as the discrete chip's register/timing specification.
MAME reference reviewed:
https://github.com/mamedev/mame/blob/9c761818e14b447ffec65f7e5827692f8f5c34f9/src/devices/sound/meg.cpp
At that revision, s2_r returns fixed zero and s2_w logs the write. We are
not treating those stubs as a hardware rule. Is there underlying research
or documentation for the discrete chip that could establish this behavior?
Firmware contents are not needed for this request. Addresses, document
references and appropriately identified measurements would be useful.
All reactions