Or more bluntly, "nobody checked what 'disabling FDS registers' via $4023 actually meant until now".
TakuikaNinja wrote: Tue Apr 08, 2025 4:39 pm
(I swear I posted here last night... whatever)
So it turns out that the read-only registers are mapped and functional even they're disabled via $4023. I haven't checked the sound registers yet but I would expect them to behave in the same way. This means that only the write-only registers are actually disabled in this state. I've seen some emulators map the read-only registers to open bus when "disabled", so those are incorrect.
Exhibit 1 - $4030-$4033 are still readable when $4023 = 0:
registers_disabled_but_still_readable.png
Exhibit 2 - $4032 can still recognise the disk being inserted/ejected while in this state (first/second reads = while inserted, third read = after ejection):
registers_disabled_but_eject_is_recognised.png
I finally got around to making a program to better visualise/test this behaviour. I will be making separate threads for individual FDS test programs from now on as to not clutter the FDS emulation thread with different topics.
Summary:
$4023 state at top of screen. %10000011 on startup/reset, bit 7 cannot be changed.
Hex dump of $4020-$409F below, updated in realtime so it can recognise actions such as ejecting/inserting a disk.
B toggles $4023.D1 (sound registers), A toggles $4023.D0 (timer IRQ & disk I/O registers).
Measures have been put in place to reduce the chance of PRG-RAM corruption caused by leaving $4023.D0 = 0 (DRAM refresh watchdog is disabled). However, it may be necessary to do a full power-cycle/reload should the program ever halt or otherwise fail to reset properly.
I'll just have the program attached here. I might get a GitHub release going once I get results from other consoles/emulators. I think I need to update the mirroring test as a result of this new one, and then get back to the DRAM refresh watchdog at some point... Not to mention the tests I also want to make for the byte transfer flag and its IRQs.
Hardware recordings from my Twin Famicom will be posted here soon.
You do not have the required permissions to view the files attached to this post.
I have a video recording now and will get that up on YouTube in a short moment. Here's a minor update with an adjusted palette for the hex dump - I've found that my EasyCAP doesn't handle grey-on-black very well.
You do not have the required permissions to view the files attached to this post.
Readable disk I/O registers ($4030-$4033) are still readable when $4023.D0 = 0.
$4030.D3 (nametable arrangement status) is seemingly cleared when setting $4023.D0 = 0. It stays cleared, despite setting $4023.D0 = 1 again, until reset (when $4025.D3 is newly written to?). I'll have to test this further in my mirroring test.
$4032 can still recognise the disk being inserted/ejected while $4023.D0 = 0.
Readable sound registers are still readable when $4023.D1 = 0, though a few of the mod table registers ($4093, $4095) seem to change values?
Wavetable RAM ($4040-$407F) seems to return an initial state (note: top 2 bits are open bus), albeit likely influenced by the active wavetable position/accumulators (judging by the reset flakiness)?
Things to further test/research:
Does $4030 have any other responses to setting $4023.D0 = 0?
Does $4033 reflect the FDS expansion port state while $4023.D0 = 0?
Does Wavetable RAM ($4040-$407F) have an actual initial state, or is it undefined?
Sound registers in general. I personally don't have a good understanding of them.
Update on the wavetable RAM: Loading the program from power-on as early as possible (by having the FDSKey remember the disk image between power cycles) resulted in the below hexdump. On my unit, it seems to return open bus bits | $02 and doesn't change across resets.
You do not have the required permissions to view the files attached to this post.