What is Happy 3rd byte corruption bug and fix

[E474]

Hi,

 

   I'm following up on what looks like the Happy 3rd byte in sector corruption bug - from this post: 

(comment 36 onwards).

 

I've done a search on the AA forums (Happy+bug), and it looks like the fix is in this post: 

 

 

Unfortunately, I'm not totally clear on the situations that trigger this bug. It looks like it is:

 

1) Revision 2 Happy ROM, and

2) Writing to a single density disk

 

but if it's just these two situations, a Happy would be unreliable in a lot of cases, so I'm guessing there are additional requirements to trigger this bug?

 

Also, is the bug more likely to be triggered with a stock OS, or with a patched (high-speed) OS. 

 

I'd like to update my DUMP1050 utility to either workaround this bug, or at the least, warn the user that this might happen, but at the moment I'm not clear on what the bug actually is, or if there are any consequences to just sending SIO $48/$0020 and carrying on regardless.

 

Any help would be appreciated!

 

 

[phaeron]

It's a bug specific to the US Doubler emulation when handling high-speed writes, so with a stock OS you can still hit it with a high-speed capable DOS. The workarounds are to enable track write buffering, disable track buffering, or avoid USD high speed operation.

 

Note that if the drive already has track write buffering enabled and has cached writes that haven't flushed yet, sending SIO $48 will actually discard those cached writes! To do this safely, you'd need to send a Status ($53) command first to force a write flush. But in general, I'm not sure it's a good idea to try changing drive modes, especially given that you'd also have to detect the drive type first.

 

You could just put in a verify pass -- that way the user would know that something went wrong, Happy 1050 USD or not.

 

 

[E474]

Hi @phaeron,

 

   Thank you very much for your reply. 

 

   Checking the code of my DUMP1050 utility, I'm uploading a new command to the Happy RAM, then disabling both track read/write buffering and track write buffering by sending $48/$6060. Code (from github) is:

 

	LDA #$60
	STA DAUX1
	STA DAUX2 
	
	LDA #'H
	STA DCOMND
	
	LDA #$80
	STA DSTATS

	LDA #$31
	STA DDEVIC

	LDA DRIVE_NUMBER
	STA DUNIT
	LDA #2
	STA DTIMLO
	LDA #$80
	STA DBYTLO
;
	LDA #0
	STA DTIMLO+1 ; NOT NECESSARY	
	STA DBYTHI
    JSR	SIOV

 

This was done to stop the Happy over-writing the uploaded code with track buffer data, but it looks like it would also trigger the Happy 3rd byte corruption bug, as it's doing the opposite of the enable track write buffer workaround.

 

I've already posted a warning/do not use topic that this may be an issue, and cross posted to the main 8-bit forum, now I have to try and reproduce the bug, so more testing required.

 

Thanks also for the suggestion of verifying the written file, I was also wondering about this as a check, but will put it in regardless in the next version.