Macro help?

[dwight]

Pool it not suppose to be a violent game.
You don't need to run or jump. No body to body
contact.
Maybe you play it different then I do.
Looking at it, I think Jeff's has the right though. The address
decoder in the chip is slow and allows glitches to get through.
The 11 address seems to be sensitive to getting such a glitch.
Dwight

[barrym95838]

https://www.youtube.com/watch?v=OuU60r7VT30

[parental advisory: strong language and violence]

Mike B.

[floobydust]

barrym95838 wrote:

https://www.youtube.com/watch?v=OuU60r7VT30

[parental advisory: strong language and violence]

Mike B.

That would certainly explain it, but for the life of me I can't remember all of the details. It must have been a "momentary lapse of reason".

[Dr Jefyll]

floobydust wrote:

Unfortunately, I've managed to tear a miniscus in my left knee and have limited mobility (including standing) for the next few weeks at a minimum.

Sorry to hear that. Here's hoping the brain is still active while your body heals.

floobydust wrote:

The thing with the macro, it doesn't appear to be a timing related mechanism, but to ensure that the instruction that will read the status register is located in ROM at an address where the lower two address bits are not zero.

Right. And relocating the instruction that reads the status register also relocates the following instruction.

dwight wrote:

Looking at it, I think Jeff's has the right though. The address
decoder in the chip is slow and allows glitches to get through.
The 11 address seems to be sensitive to getting such a glitch.

Yes. The FDC seems to act as if Chip Select is still true for a short time after the status register has been read and CS has gone false. And (without the macro) the address at that time could be the 11 address, which is read-sensitive. My hunch is that the read of the status register proceeds normally and successfully. The trouble happens in the cycle following the SR access -- the rogue read produces a side effect that impacts internal FDC logic. Unfortunately the side effect can't immediately be observed. Probing this by using a logic analyzer would involve examination of some rather lengthy traces which also aren't exactly repeatable (because the rotation of the disk isn't synchronous). But there's another way to attack the mystery.

Are you game to try a little hardware hack, floobydust? The macro is a software workaround for the flaky FDC chip, but a hardware workaround is also possible. Just make it so the A1, A0 signals avoid the 11 address for about 500 ns after the status register has been read and Chip Select goes false. It's plain that the macro does ensure A1, A0 won't equal 11 in the cycle after the SR access, but it's not proven that that's why the macro is effective. (The macro also affects the address seen before the SR access.) By removing the macro and using hardware to target only the cycle after the SR access I believe the question can be laid to rest.

I doodled around and came up with a 2-chip solution and a 1-chip solution to keep A1/A0 stable longer and thus avoid the 11 address. Dunno what parts you happen to have on hand, but either of these -- or a hybrid -- could be made to work. Kinduva fun experiment, if you're up for it!
[Edits]

[floobydust]

Hi Jeff,

I just pulled the trigger on a Mouser order.... albeit those chips shown aren't in my stash, who knew?

Doing therapy on the knee, hope it improves soon, I hate being disabled and I have to travel to Nashville in two weeks for business Not to mention taking out the fun toys with manual shift is a bit difficult ;-( Even cycling a bit was painful this past weekend.

Anyway, I keep thinking about this... I keep thinking that if the 1772 were truly a bit flaky, then it would likely show up somewhere on the net as such, especially as the Atari machines made heavy use of this chip as well. I also keep looking at the basic hardware design of the 1581 and the default memory access for ROM and RAM, which basically bothers me. There's also a section in the ROM code that does a BIT test against the busy flag after reading the status register and immediately loops back endlessly until it changes. Still, you could easily be correct that it's what follows the SR read that creates the anomaly.

I'm in the process of removing all of the chips on one of the 1581 drives and socketing the entire board, Should have that completed next week and be in a better position to make some HW design changes without any slice 'n dice of the PCB. This is an interesting puzzle... as there's not yet an obvious explanation for the Macro, but it certainly doesn't work without it. Also, as the 6502 in the 1581 is driven with a 2MHz clock, that results in a cycle time of 500ns. Based on the CPU clock rate, there's always going to be enough time between accesses (referencing the datasheet timing values). The other registers which can be written and read are specified as requiring a specific amount of time before attempting a read (following a write). As the control and status register share the same address, this is not an actual requirement, otherwise looping on reading the status register and testing the BUSY bit wouldn't work.

I'm still intent on trying to figure this one out... with the assistance of the kind folks here as well. Thanks to all who have been putting forth ideas (Jeff in particular).

[BigDumbDinosaur]

floobydust wrote:

Anyway, I keep thinking about this... I keep thinking that if the 1772 were truly a bit flaky, then it would likely show up somewhere on the net as such, especially as the Atari machines made heavy use of this chip as well.

Dunno if you have one handy, but it would be interesting to replace the 6502 in your 1581 with a 65C02. The thought had occurred to me that the way the 6502 behaves with some instructions, doing a double write in some cases, may have something to do with the macro and its need.

[floobydust]

BigDumbDinosaur wrote:

floobydust wrote:

Anyway, I keep thinking about this... I keep thinking that if the 1772 were truly a bit flaky, then it would likely show up somewhere on the net as such, especially as the Atari machines made heavy use of this chip as well.

Dunno if you have one handy, but it would be interesting to replace the 6502 in your 1581 with a 65C02. The thought had occurred to me that the way the 6502 behaves with some instructions, doing a double write in some cases, may have something to do with the macro and its need.

Yes, I have some of the older Rockwell 65C02 chips, both 2MHz and 4MHz and some of the WDC chips. Replacing the NMOS part with a 65C02 is the plan.... they only socketed the EPROM on the PCB, everything else was soldered ;-( Using the Rockwell part is a simple plug-in, the WDC will require a pin 1 float at the least.

[Dr Jefyll]

BigDumbDinosaur wrote:

Dunno if you have one handy, but it would be interesting to replace the 6502 in your 1581 with a 65C02. The thought had occurred to me that the way the 6502 behaves with some instructions, doing a double write in some cases, may have something to do with the macro and its need.

The NMOS double write occurs in the last two cycles of read-modify-write instructions, and this firmware doesn't use RMW instructions to access the FDC registers. Still, I'd be in favor of giving a Rockwell 'C02 a try. Maybe there's not much chance of uncovering new clues, but it's a simple enough experiment. Doing the switcheroo would be easy since the plan is to socket the CPU anyway.

floobydust wrote:

Still, you could easily be correct that it's what follows the SR read that creates the anomaly.

Yes I do primarily suspect it's the change from address 00 to 11 that holds the key, but my eye is on the change from 10 to 00 as well. (IOW both after and before the SR access.) It's hard to rule anything out.

Here's a more thorough presentation of the possible address sequences. I've been reminded that only accesses to the Status Register seem to require the macro, and I've noted that. The five cycles listed for each sequence are: the ROM access to read the LDA opcode; the ROM access to read the LS operand byte; the ROM access to read the MS operand byte; the FDC access to read the specified register ; and the ROM access to fetch the opcode of the following instruction.

• 00 is the address of wdstat, the Status Register. The following A1 and A0 values can be present during & after execution of a LDA wdstat instruction (depending on where in memory the instruction is stored):
  1. 00,01,10,00,11 <-- problematic
  2. 01,10,11,00,00
  3. 10,11,00,00,01
  4. 11,00,01,00,10
  01 is wdtrk, the Track Register. The following A1 and A0 values can be present during & after a LDA wdtrk:
  1. 00,01,10,01,11 <-- NOT problematic!
  2. 01,10,11,01,00
  3. 10,11,00,01,01
  4. 11,00,01,01,10
  10 is wdsec, the Sector Register. The following A1 and A0 values can be present during & after a LDA wdsec:
  1. 00,01,10,10,11 <-- NOT problematic!
  2. 01,10,11,10,00
  3. 10,11,00,10,01
  4. 11,00,01,10,10
  11 is wddat, the Data Register. The following A1 and A0 values can be present during & after a LDA wddat:
  1. 00,01,10,11,11 <-- NOT problematic!
  2. 01,10,11,11,00
  3. 10,11,00,11,01
  4. 11,00,01,11,10

[floobydust]

An update from my end:

1- Still can't walk right... knee, ugh.
2- Mouser order received - yay!
3- Entire 1581 PCB has been socketed (including Can Osc) and all new caps installed as well
4- Replaced all logic chips with 74HCT series
5- Rockwell R65C02P4 installed, Intel 27C256 EPROM, Alliance 8KB RAM
6- Only original chips reused were the WD1772 and CSG 8520A

Burn-in completed, everything works as expected. Attaching a pic of the PCB completed (also defluxed the board). With a working drive again, I can now do some additional tests on the code side. I'm also attaching a 3rd party datasheet for the WD1772. There are some specific timing requirements in polled-I/O mode per the datasheet. In some cases, these are not implemented in the 1581 code. In other cases, timing delays between register writes and reads are followed (as in 20 NOPs in a row). At least I'm in a better position to do some testing and changes and the only risk is popping the 8520 or 1772.

WD1772-JLG.pdf

(1.1 MiB) Downloaded 108 times

[BigDumbDinosaur]

floobydust wrote:

1- Still can't walk right... knee, ugh.

Ice it and take it easy. That's about all you can do.

Quote:

3- Entire 1581 PCB has been socketed (including Can Osc) and all new caps installed as well

Betcha that kept you busy for a while.

Quote:

Attaching a pic of the PCB completed (also defluxed the board).

It's probably been a good 20 years since I last looked at a 1581's PCB. Which drive mechanism is in that unit? I wonder if a (relatively) modern 3.5 inch PC floppy drive could be made to work. I've got at least a half dozen of those things (Teac units) here that were salvaged from upgraded PCs and servers that went through our shop.

Quote:

...and the only risk is popping the 8520 or 1772.

I don't think there is much risk there, as long as your power supply doesn't do anything stupid.

[floobydust]

BigDumbDinosaur wrote:

floobydust wrote:

1- Still can't walk right... knee, ugh.

Ice it and take it easy. That's about all you can do.

Quote:

3- Entire 1581 PCB has been socketed (including Can Osc) and all new caps installed as well

Betcha that kept you busy for a while.

Quote:

Attaching a pic of the PCB completed (also defluxed the board).

It's probably been a good 20 years since I last looked at a 1581's PCB. Which drive mechanism is in that unit? I wonder if a (relatively) modern 3.5 inch PC floppy drive could be made to work. I've got at least a half dozen of those things (Teac units) here that were salvaged from upgraded PCs and servers that went through our shop.

Quote:

...and the only risk is popping the 8520 or 1772.

I don't think there is much risk there, as long as your power supply doesn't do anything stupid.

Yes, the knee just hurts... doing some PT per the Doc's recommendation (other option is surgery).

Socketing... I cheat a bit. For the 74LS logic chips, I just snip the leads at the chip itself, then use the iron to melt and lift each one out, then a solder bulb to clean them out. Pretty quick overall. I did the same for the RAM chip as these are cheap as well. The EPROM was socketed, but I put a better one it's place (matches the rest of the new ones). Of course, salvaging the CPU, CIA and FDC were important, so these took the majority of the time.

The 1581s I have use a Chinon FB-354 drive. I also have a few of the Teac FD-235HF/HG drives, but depending on some of the submodels, some of the line functions change. There are some tiny zero-ohm SMTs that can be removed/installed to change some of those options however. I am thinking it should be feasible to swap out to one of the Teac drives, but it may require a slight wiring change at the connector.

I'm using the stock Commodore power supply... but I'm thinking of using a single 5-volt regulated Condor switching supply once I opt on a Teac drive swap. Overall, the drive is running cooler as all of the chips, sans the CIA and FDC are now CMOS. Time to start making some code changes to see if anything changes with the 65C02.

[Dr Jefyll]

floobydust wrote:

Overall, the drive is running cooler

Nice work -- I bet that feels good. Gotta love CMOS.

Quote:

Time to start making some code changes to see if anything changes with the 65C02.

It'd be good to do just a quick test to see if the drive works with a 'c02 present and the macros absent. But are there other code changes you had in mind? It seems to me pursuing other changes could become a diversion from the main focus.

If the main focus is to solve the mystery of why the macro is needed then it'd be good to try to zoom in on the problem. For example we know the macros go in places where the code accesses the FDC Status Register, and drive fails when all the macros are removed. But that leaves the cause of failure ambiguous, doesn't it.

It'd be better to leave all the macros in place except one, and in that one case use a special anti-macro to guarantee the wrong alignment. Then when the failure occurs we know exactly what code was executing. The scope of the mystery is much smaller because we're looking at one specific SR access instead of guessing among many.

-- Jeff

[floobydust]

Dr Jefyll wrote:

floobydust wrote:

Overall, the drive is running cooler

Nice work -- I bet that feels good. Gotta love CMOS.

Quote:

Time to start making some code changes to see if anything changes with the 65C02.

It'd be good to do just a quick test to see if the drive works with a 'c02 present and the macros absent. But are there other code changes you had in mind? It seems to me pursuing other changes could become a diversion from the main focus.

If the main focus is to solve the mystery of why the macro is needed then it'd be good to try to zoom in on the problem. For example we know the macros go in places where the code accesses the FDC Status Register, and drive fails when all the macros are removed. But that leaves the cause of failure ambiguous, doesn't it.

It'd be better to leave all the macros in place except one, and in that one case use a special anti-macro to guarantee the wrong alignment. Then when the failure occurs we know exactly what code was executing. The scope of the mystery is much smaller because we're looking at one specific SR access instead of guessing among many.

-- Jeff

Hi Jeff,

Yes, the first goal is to ensure a misalignment of the NOP macro against one of the SR routines. This will simply be a test to see if the 65C02 replacement has an effect on the code operation. I can just scan the listing file and comment out one of the Macro entries that provides a NOP. I just need to find one that is fairly general in operation, as the format track code has a long list of SR reads

There is still the WD documentation that states wait times for reading the status register after writing to the command register, which the 1581 code doesn't adhere to, so who knows what really does work or not.

[Dr Jefyll]

floobydust wrote:

I can just scan the listing file and comment out one of the Macro entries that provides a NOP.

OK, that works, too -- comment out one of the Macro entries that does provide a NOP. (Many of them don't, depending on how the alignment works out.) And something else just occurred to me. Having removed one macro and the NOP it produced, you'll want to add a NOP (or otherwise waste a byte) further down in the code. Otherwise you'll unintentionally affect whether subsequent macros do or don't get triggered. And we want all that to stay the same.

(Hmm -- on second thought it probably doesn't matter if a different subset of the subsequent macros gets triggered. It's important to be aware of unintended side-effects, but in this case I'm maybe being too nervous.)

[floobydust]

Some initial testing sans the Macro and ensuring bad alignment.

First, some background on the source code. There are only TWO segments in the code that actually write to the Command register (address is shared with the Status register). One is an abort command, which is only found once in the code, which is:

Code: Select all

	lda  wdforceirq
	sta  wdcmd      ; send command
	jsr  delay40    ; wait 40uS
	jsr  delay40    ; wait 40uS
	jsr  delay40    ; wait 40uS
	jmp  wdunbusy

Note that the Macro is not used here, so apparently the terminate command to the FDC is not a sensitive one for the address, or perhaps the fact that there is just a group of delays following the terminate command. The second place in the code that the Command register is written to is where ALL FDC commands are handled as:

Code: Select all

wdbusy
	WDTEST
	sta  wdcmd      ; send command

	lda  #bit0
	WDTEST

1?      bit  wdstat
	beq  1?

	jmp  delay16

The Macro is used above for both sending a command to the FDC and again for testing the busy bit in the Status register. Another commonly used code piece is here:

Code: Select all

wdunbusy

	lda  #bit0
	WDTEST
1?      bit  wdstat
	bne  1?

	rts

As in the previous code segment, the Macro is used to ensure the address alignment. So my first test was to disable the Macro in these two code segments and add NOPs to ensure a bad alignment of the instructions, i.e., the lower two bits are zero for each access to the Command and Status register. This required 6 NOPs added and the Macro commented out. I burned another EPROM, put it into the drive and.... it works fine, or at least appears to. I assembled my old C64 DOS front end (uses dozens of files) and it completed without an issue. I also deleted some files, recreated them, did a CHKDSK command, etc. and it functions normally.

So, my initial take away on the this is the instructions used to test the Status register. In the cases above, the BIT instruction is used, not the LDA instruction. It would appear that using the BIT instruction doesn't cause an error, or, as Jeff mentioned earlier, perhaps it's the post alignment that doesn't cause a problem. I don't feel I'm any closer to figuring this out, but perhaps the Commodore team didn't fully understand the problem either (based on the above findings).

All other accesses of the Status register are done by using LDA WDSTAT and all of these appear to require the address alignment. The majority of these code segments are identical:

Code: Select all

main7	ldx  #12
	WDTEST		; chk address
cmd70   lda  wdstat
	and  #3
	lsr  a
	bcc  v1	
	beq  cmd70

	lda  #0
	sta  wddat
	dex
	bne  cmd70

The above snippet from the format track code. So perhaps it's something specific to the differences between the BIT and LDA instructions or the following instructions after the LDA.