FDS $4023 Testing

[TakuikaNinja]

Or more bluntly, "nobody checked what 'disabling FDS registers' via $4023 actually meant until now".

(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.

Source code: https://github.com/TakuikaNinja/FDS-4023-Test

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.

[TakuikaNinja]

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.

[TakuikaNinja]

Right, here's the recording from my Twin Famicom: https://youtu.be/rbvNSA2-kNI

Here's the list of actions taken:

1. Initial load, $4023 = %10000011
2. Disk eject + insert
3. Set $4023.D0 = 0 (disk I/O registers)
4. Disk eject + insert
5. Toggle $4023.D1 (sound registers) a few times
6. Press reset a few times

[TakuikaNinja]

Main findings so far:

• 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.

[TakuikaNinja]

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.

[TakuikaNinja]

SCSR got back to me with some analysis of $4023 behaviour:

The written registers seem to deny writes when $4023.0 is 0, this happens because it also disables part of the clock generator. However, if you enter the test mode, you should be able to write to these registers, since the part of the clock generator that is disabled is bypassed and the other parts are directly clocked through the clk pin. The read registers use different clock signal that is not disabled. This also affects the audio registers. As far as I know, the $4023.1 bit only affects the circuit generating the audio signal.

Setting $4023.0 to 0 also seems to reset IRQ, DRAM refresh and disk I/O related counters and hold reset until 1 is written to $4023.0.

Setting $4023.0 to 0 resets the $4025 to value $06.

I haven't seen anything that would reset the wavetable RAM to specific state, so it's probably random. Most of the audio circuit is still not traced, so I can't say much about it for certain

The "hold in reset state until the bit is set again" behaviour lines up with what's observed in the program.

$4025 being reset to $06 explains why it was affecting $4030 - bit 3 (nametable arrangement) is being cleared. My program does not touch $4025 aside from letting the BIOS reset handler initialise it, which fortunately allowed this behaviour to be detected. Now I have to update my mirroring test to check for this behaviour...

Yuri213212 had made similar observations last year regarding $4023. Regarding the sound registers, they noted that clearing $4023.D1 halts the current wavetable output after a brief pop (wave accumulator & mod counter being reset?) and can be resumed simply by setting the bit again. That's likely why a few of the readable sound registers were changing when toggling the bit. (It only took over a year to catch up...)