I did a few power tests to see if there were variations (didn't see any) but a strange thing, though: after running sometimes a red light comes on for the FDSStick and never shuts off. If I power cycle while this is happening I think I end up corrupting the disk sometimes, and get an "err 32" trying to load after that.

That sounds oddly similar to what Pokun mentioned, too. But I can't really see how the test could be causing it - it does absolutely nothing after displaying the results. Maybe a bug with the FDSStick itself?

I feel like writing repeatedly to $4023 has consequences for disk activity, like it's causing the RAM adapter to send signals to the drive in some way. Maybe not important in terms of nailing this IRQ behaviour down but relevant to disk behaviour? It's weird how inconsistent it is, though.

Trying to check what the corruption was, I tried to read the "corrupted" disk back using the FDSStick program, and it was only 16 bytes long. (FDS,$1A header + 12 x $00) So... that's strange. Maybe it's just from powering off while it's trying to write?

I don't know what the held red light on the FDSstick means. Actively writing? Usually it turns on whenever I press the button, and the green one turns on any time the disk is being read, I think. (Similarly on my other test a few posts back, I'd get a repeating held green light on that one where it just never stops reading?

I do notice that in my example I zeroed out RAM, even though I was masking the value from $FA ($4025 write mirror) when applying mirroring to $4025. Maybe this put the disk into write mode? (There's also bit 5 that the wiki says "always set to 1", which is a direction this violates but I don't know if that's meaningful.) The default value for $FA should be $2E, which is the last thing the BIOS set it to on reset.

I should fix my example not to clobber those BIOS variables. I thought I tried to avoid that, but I missed the ZP ones.

I still think weird stuff can happen with the drive when writing to $4023, but seems well behaved/quiet as long as $4025 is properly set back to $2E beforehand? Anyhow, probably not relevant to the IRQ testing.

I also tried patching V5 to see if this affected that it hangs with only 1 heart displayed, but it's the same, so at least THAT wasn't my fault.

I guess it didn't like write mode being turned on? Odd that this would matter since it also meant the motor was turned off - hard to see how the FDS could corrupt a disk while the motor is disabled..

I'm guessing there is probably a reason for the BIOS to be writing $83 to $4023 instead of $03, but there is no mention of bit 7 in $4023 anywhere, from what I can see.

I updated the wiki with the information that was confirmed from these IRQ tests.I might try writing another set of tests for the drive itself (though that will be trickier I'd imagine) - it would be nice to get a solid understanding of all the flags in in $4030/$4032 as well as the behavior of the disk IRQs.I'm guessing the actual timing of the disk read/write operations can't really be tested with the FDSStick, though?

Hi all, I am trying to get these tests to work on BizHawk. The first problem I ran into is that the .FDS file indicates that there are 6 files on the disk, but looking over the file in hex editor I only see files 0-4. (Also, two files are both named FILE2, but that's not relevent to anything.)

I added in a blank file 5 to get it to run, but then it just repeatedly fires IRQ's and doesn't do anything else.

Hi all, I am trying to get these tests to work on BizHawk. The first problem I ran into is that the .FDS file indicates that there are 6 files on the disk, but looking over the file in hex editor I only see files 0-4. (Also, two files are both named FILE2, but that's not relevent to anything.)

Thanks for posting this up Sour! I would like to try to implement this fix into nestopia as well. I am taking the hot spot snippet from the Nestopia plus! SVN here. This was the last commit which fixed the freeze in Lutter but now makes the game putter have no sound.

The text next to each test is essentially a summary of what the emulator should do.

As far as I remember:03 Starting irq counter when reload value is 0 should still cause an irq04 The irq reload value should never get reset (by anything other than $4020/$4021 writes)05 Disabling disk registers while waiting for an irq should cancel that irq (it should never be triggered)06 Starting an irq when disk registers are disabled should be impossible0A Writing to $4022 with bit 1 set ($02) should not acknowledge the irq0B Writing to $4023 with bit 0 set ($01) should not acknowledge the irq0D Writing to $4022 to start the irq counter while the irq counter was already running resets the counter and delays the irq.0E Writing to $4022 to start an irq while disk regs are disabled, and then enabling disk registers should not cause an irq11 Writing $00 to $4022 should not reset the irq reload value12 Writing $02 to $4022 4 times in a row (with a small delay between each write) when reload value is 0 should cause 4 irqs15 Starting the irq counter with the repeat flag & a reload value of 0 should cause an infinite never-ending loop of IRQs

Some of these tests are a bit redundant since I was trying to test for every possible edge case I could think of.

Thank you for the clarification Sour. It's a little confusing but i see someone has it working in Nestopia.

Obviously ZxbDragon wants to throw it in my face that he has it working in his private modified build of Nestopia plus! so maybe he can help share this information, since he shared his other FDS fixes. So what do you say dragon, do you mind sharing your findings please? Since you already obviously have this working.

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum