Request for Help: Floppy Disk Controller WD37C65 (Scott Baker) on SC126 with RomWBW 3.2

[MartinR]

Hello -

I'm hoping that some of the knowledgeable people in this group can give me a steer. Apologies for the long posting, but I felt it was important to provide as much relevant information as I could.

Earlier in the year I built a stock SC126. It worked perfectly first time, and I'm extremely pleased with it. It's a great design by Steve Cousins, and RomWBW is a fantastic piece of work by Wayne Warthen. In April I upgraded to RomWBW 3.2 using the ROM image from Steve's website, and that's been working fine too.

https://smallcomputercentral.com/firmware/firmware-romwbw-sc126/

More recently, I decided to build Scott Baker’s FDC for my SC-126. I chose the WDC37C65C option as it was a simpler implementation.
 
https://www.smbaker.com/z80-retrocomputing-part-14-rc2014-floppy-controller-boards
        http://www.smbaker.com/wordpress/wp-content/uploads/2016/12/rc2014-floppy-wd-sch.png

Despite my eyesight and dexterity not being what they were 40-45 years ago, over a couple of weeks I hand wired the board. I took every precaution to ensure I got the build right. At each step of the way I visually checked joints with a magnifying glass, and checked for connectivity and shorts with a multimeter. As far as I can tell, everything is wired up correctly. VCC is at 4.92V. All the ICs were bought as new, and certainly the WD37C65C really does look brand new. For completeness, the 3.5" floppy drive itself is not brand new, but works fine in my desktop PC.

Of course - the floppy disk controller board doesn't work, or why else would I be writing this?

The SC126 still works as expected, so presumably I've not shorted the address/data busses, but the FDC board is not discovered. The boot-up message includes the following:

FD: MODE=RCWDC IO=0x50 NOT PRESENT

Which leads me to believe that the ROM is built for this board. I had naively expected the 'NOT PRESENT' to change....

When the SC126 reset button is pressed, there is a good solid RST to pin-19 of the controller.

The address decode seems to work as expected with the pins on the HCT138s toggling when the appropriate ports are addressed. Eg - when I address port 0x50 the CS\, pin-3 on the WD37C65C, toggles.

If I reboot the SC126 and immediately jump into the RomWBW 'monitor', I can read port 0x50, the Main Status Register, and the value 0x80 is returned. If I then read port 0x51 I get a value of 0x00, but now 0x50 returns a status of 0xD0. So - something changes, which I find encouraging.

I've had a look through the documentation, and some of the RomWBW to see if there is something that I should have done to 'enable' the firmware, but I can't find anything.

In the file SC126.ASM there are the following lines:

FDENABLE .SET TRUE ; FD: ENABLE FLOPPY DISK DRIVER (FD.ASM)
FDMODE .SET FDMODE_RCWDC ; FD: DRIVER MODE: FDMODE_[DIO|ZETA|ZETA2|DIDE|N8|DIO3|RCSMC|RCWDC|DYNO|EPWDC]

This would suggest the SC126/RomWBW is configured for the board I have built and so I don't need to select one of the of the alterantive floppy disk controller modes.

And in the file FD.ASM there is the following:

        #IF (FDMODE == FDMODE_RCWDC)
          FDC_MSR .EQU $50 ; 8272 MAIN STATUS REGISTER
          FDC_DATA .EQU $51 ; 8272 DATA PORT
          FDC_DOR .EQU $58 ; DIGITAL OUTPUT REGISTER
          FDC_DCR .EQU $48 ; CONFIGURATION CONTROL REGISTER
          FDC_TC .EQU $58 ; TERMINAL COUNT (W/ DACK)
          #ENDIF

These values match the port numbers I'm expecting from the circuit diagram. My controller chip is a WDC37C65C, so I'm hoping the references to an 8272 are typos.

I'm now going round in circles, and don't know what to check next. Can someone help, please? Is there anyone who has built one of these, or has some detailed knowledge of the WD37C65C that could advise? And does someone know if there is anything that I need to do to the ROM to 'enable' something. Have I overlooked something obvious that I now can't see for looking?!?

Grateful for any help. Thank-you.


MartinR

[Alan Cox]

> If I reboot the SC126 and immediately jump into the RomWBW 'monitor', I can read port 0x50, the Main Status Register, and the value 0x80 is returned. If I then read port 0x51 I get a value of 0x00, but now 0x50 returns a status of 0xD0. So - something changes, which I find encouraging.

This sounds right, you should get 80 and D0.

The FDU tool ROMWBW ships with in CP/M hit the hardware directly so
can be very helpful as a diagnostic and let you change all sorts of
things.

Alan

[Wayne Warthen]

Yes, it definitely sounds like you are getting a response from the FDC chip.  Everything you are doing sounds right.  RomWBW is configured to look for your FDC automatically, so it should just work.

The detection logic in the RomWBW driver expects that on the first read of 0x50, you will get either 0x80 or 0xD0.  We know you get 0x80, so that is fine.  It then expects the second read of 0x50 to be exactly 0x80.  Can you try reading port 0x50 twice in a row with the monitor and report what you see?

You definitely want to try the FDU application included on the RomWBW ROM disk.  That application interacts directly with the hardware (regardless of what the RomWBW boot says).  The FDU application is an old application and has some idiosyncracies.  There is a file called "fdu.doc" in the distribution in the folder Source\Apps\FDU that will be helpful.

Thanks,

Wayne

[MartinR]

Hello -

Firstly, a massive thank-you to both Alan and Wayne who responded so quickly with some really helpful, and reassuring, information. Thanks, both - much appreciated.

Useful to know that reading 0x80 from port 0x50 is to be expected, along with a change to reading 0xD0 after the data register has been read. Knowing that was a great help as I knew that I was talking to the FDC chip.

As Wayne suggested, I tried multiple reads of 0x50 to see if if returned 0x80 each time I did. And, I can confirm that it does - and repeatedly so. I rebooted and did multiple reads of 0x50 and it stayed at 0x80 until I finally read 0x51, at which point it changed to 0xD0. I repeated the whole reboot many times. This begs the question, why is RomWBW not detecting the board and continuing to show "FD: MODE=RCWDC IO=0x50 NOT PRESENT"? Any ideas where I should look next?

Both suggested having a play with FDU.COM. Much appreciate the reminder! I'd noticed this utility when I first got my SC126 running, but not having a FDC board at the time I only gave it a passing glance. It seems my memory is heading the same way as my eyesight and dexterity!

The results I got from FDU.COM were very positive!

On trying to read a track or sector the whole system immediately rebooted - repeatedly so. But, I'd noticed the drive's LED very briefly flash on and the drive made a very brief mechanical noise. It was definitely trying.... So I reckon the 2A power supply I'm using doesn't seem to be able to cope with the drive spindle motor turning on, and causes the VCC rail to drop somewhat, at which point the DS1233 supervisory chip asserts reset. Not an ideal result, but happy that there's a plausible explanation. A new PSU is now on the shopping list.

I then started to explore the "FDC (C)MDS" menu. I seem to be getting encouraging results here. I'm not sure what all the commands do for me, and any that attempt to start the spindle motor cause a reboot. However, from this menu I can reliably "(S)EEK" and "RE(C)AL". I can hear the head step in or out as applicable across the stationery disk.

I'm beginning to think that with an adequate PSU the board might actually be functional, though this doesn't explain why RomWBW fails to detect the board despite it repeatedly returning 0x80. Is there likely to be a timing issue with the reset? Could it be that the first time the SC126 reads from 0x50 the FDC is not yet properly reset and therefore garbage is read instead of the expected 0x80? Entirely supposition on my part.

Apart from buying a new PSU, what should I do, or check, next?

Thanks again for the help - it's much appreciated.


MartinR (in the UK)

[Alan Cox]

On Tue, 22 Aug 2023 at 10:48, MartinR <marti...@gmail.com> wrote:
> Apart from buying a new PSU, what should I do, or check, next?

Purely speculative but maybe rebuilding and flashing the ROM with the
maximum waitstates on IO or if you have one handy swapping the can
oscillator to 7.3MHz (remembering it'll change your baud rate too
probably). I don't think it's a speed of response issue but the 765
isn't a particularly fast bit of electronics.

Power for floppies is a big issue - mine are on their own PSU or on a
machine using a PC power supply.

Alan

[MartinR]

Hi Alan - 

Thank-you for your reply. 

Wait states: it's an idea for sure. But I'm not sure it's the answer to the problem I'm seeing. The SC126 defaults to including two wait states for IO. At sign-on, the SC126 reports the wait states being used way before it reports on finding (or not!) the floppy-drive interface. 

I don't believe that additional wait states would help as I am getting consistent results for reading port 0x50, and also with the seek and recalibrate commands under FDU.COM. Also, this is the stock 3.2 ROM, so I am trusting that it's been configured correctly. I might have a look at the IO timing diagrams for the Z180 at 18.432MHz and compare them to the timing diagrams for the WD37C65 with a 16MHz clock. 

I don't have the slower oscillator module to hand, but I would suspect they're not that difficult to come by. 

It would be interesting to hear if anyone has successfully used an SC126 with this FDC board. 

I shall definitely be addressing the power supply issue. I could tap off the 5V supply from my desktop PC, but I'd be concerned that should I get something wrong on the SC126 the current available would cause significant damage! Certainly a 5V supply for the drives independent of the SC126 5V supply would give good isolation and be a good idea. 

 

MartinR

[Alan Cox]

> I shall definitely be addressing the power supply issue. I could tap off the 5V supply from my desktop PC, but I'd be concerned that should I get something wrong on the SC126 the current available would cause significant damage! Certainly a 5V supply for the drives independent of the SC126 5V supply would give good isolation and be a good idea.

If you use a PC supply you definitely need polyfuses on it.

Alan

[Tadeusz Pycio]

The SC126 supports the FDC controller without any changes. It is possible that these are power supply issues.

[MartinR]

At the very least!

MartinR

[MartinR]

Thank-you for your reassuring posting. It's great to have it confirmed that this FDC is supported by the SC126.

You have a really neat system - something which I aspire to and is work-in-progress. I hand wired my FDC, possibly not the best solution with hindsight, but would you mind telling me where you got your FDC PCB from?

Very many thanks -

MartinR

[Tadeusz Pycio]

I found this project on OSHWLab (PCB v2)!!!

[Kevin Boone]

FWIW the problems I had with my FDC board turned out to be related to inadequate PSU. I guess I was 'luckier' because my PSU was _completely_ inadequate; had it been borderline, I guess the problems would have been harder to detect.

I originally thought that the drive would take power from its 12V connection but, in fact, it does not. Everything comes from the 5V connection that was shared with the rest of the system.

With a heftier PSU and a scattering of fat capacitors, everything seems OK now.

Best wishes

Kevin

[MartinR]

Hi Kevin -

Many thanks for your helpful comments. I've got some 470uF electrolytics on order, so I'll add a few of those to the 100nF that I put across every IC. Yes - the drives do only need a 5V supply. The label on one of mine states a requirement for 950mA - presumably when the spindle motor is running. Maybe the problems will disappear entirely once I've got that better power supply - but I'd still to know why RomWBW is not currently discovering the board when I can read 0x80 repeatedly from port 0x50.

MartinR

[MartinR]

Thank-you! If I can't get my hand-wired board to work, then I may well have to invest in a PCB. Good job I socketed all the ICs.

[Richard Deane]

It might be worth investing in a cheap gotek floppy emulator (uses usb stick), approx $15 from Aliexpress. It might avoid the need for a better psu. Could be cheaper than psu too. I use one to avoid the baggage of psu and cable.

Richard

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/b3a4518a-7cc1-4847-a42a-d3821661ba39n%40googlegroups.com.

[Wayne Warthen]

On Tuesday, August 22, 2023 at 2:48:18 AM UTC-7 MartinR wrote:

I'm beginning to think that with an adequate PSU the board might actually be functional, though this doesn't explain why RomWBW fails to detect the board despite it repeatedly returning 0x80. Is there likely to be a timing issue with the reset? Could it be that the first time the SC126 reads from 0x50 the FDC is not yet properly reset and therefore garbage is read instead of the expected 0x80? Entirely supposition on my part.

I am also surprised that RomWBW is not detecting your FDC (even with inadequate power).  I am going to recreate your system and exact RomWBW ROM version just to be sure there is no software issue.

If necessary, I would be happy to provide you with a copy of RomWBW with some extra debugging that will show exactly what values RomWBW is reading during the detection process.

Thanks,

Wayne

 

[Wayne Warthen]

On Tuesday, August 22, 2023 at 10:34:35 AM UTC-7 Wayne Warthen wrote:

On Tuesday, August 22, 2023 at 2:48:18 AM UTC-7 MartinR wrote:

I'm beginning to think that with an adequate PSU the board might actually be functional, though this doesn't explain why RomWBW fails to detect the board despite it repeatedly returning 0x80. Is there likely to be a timing issue with the reset? Could it be that the first time the SC126 reads from 0x50 the FDC is not yet properly reset and therefore garbage is read instead of the expected 0x80? Entirely supposition on my part.

I am also surprised that RomWBW is not detecting your FDC (even with inadequate power).  I am going to recreate your system and exact RomWBW ROM version just to be sure there is no software issue.

I have confirmed that my SC126 running stock RomWBW v3.2.0 is detecting my Scott Baker FDC WD36C65 module.

I don't know why your FDC is not being detected since you are recreating the detection logic manually.  RomWBW does read the status port twice in a row with a very short delay in between.  Perhaps there is a subtle difference in your system that is causing the FDC to not be ready for the second read quickly enough.  Seems unlikely though.

Thanks,

Wayne

[MartinR]

Hi Richard

I hadn't thought about a floppy-emulator, but it rather defeats the retro-experience of booting from a physical drive. It would be nice if there was a design that would interface to a USB memory stick, but I believe that USB memory sticks work in a very different way to CF or uSD cards which makes it difficult.

[MartinR]

Hi Wayne -

Many thanks for your responses - and for confirming that your stock 3.2.0 works fine with Scott Bakers design. I've checked the +5V supply, admittedly only with a multimeter, and it remains at 5.04V to 5.06V throughout the boot process.

I'll happily try a ROM image with additional debugging info to help try and resolve the issue. Thank-you for the offer. I've attached a screen-grab of the messages that come up as the SC126 starts, in case it is of any help to you.

[Alan Cox]

On Tue, 22 Aug 2023 at 19:19, MartinR <marti...@gmail.com> wrote:
>
> Hi Richard
>
> I hadn't thought about a floppy-emulator, but it rather defeats the retro-experience of booting from a physical drive. It would be nice if there was a design that would interface to a USB memory stick, but I believe that USB memory sticks work in a very different way to CF or uSD cards which makes it difficult.

There's also a chip for the job. I have a board that seems to work but
due to real world workload hasn't got a proper driver test yet.

Alan

[Wayne Warthen]

I don't see anything unusual in your boot messages.

I am attaching a file called SC126.DAT.  After you download the file, rename it to SC126.COM.  This is required because GMail will not allow .COM files to be attached to messages.  From CP/M or ZSDOS, you can upload this file via XModem to your system.  Then just run the file like a regular application.  Your system will perform a normal boot, but with the debug BIOS in SC126.COM.  Let me know if you need help with the XModem transfer.

During the boot, you will get a couple of extra hex bytes displayed (highlighted below) when the FD driver loads.  Here is an example from my system:

FD: MODE=RCWDC IO=0x50 80 80 UNITS=2

These two bytes are the values read from the FDC status register during the detection process.

Thanks,

Wayne

[Tadeusz Pycio]

There's also a chip for the job. I have a board that seems to work but
due to real world workload hasn't got a proper driver test yet.

Hi Alan,

Is this solution based on the MAX3421E chip? 

[MartinR]

Hi Wayne -

Many thanks for the file - and your continued help. I've done exactly as you've described but first included a hardware reset followed by a fresh load of CP/M 2.2 - and then run SC126.COM.

The screen-grab is attached. The output shows it reading 0x80 twice as part of the detection - and then reporting success and that I have two units (drives)! Actually,  I only have one drive ; configured as FD1 as it's a non-twist cable. Selecting '3' causes the drive to attempt to spin up, at which point the inadequate power supply dropping out causes a reset. When the system reboots to the ROM based 3.2.0, detection fails. Run SC126.COM again, and detection works. This whole process is repeatable. Note: the FDC chip is a WD37C65C-PL - if that makes any difference? 

I'm now completely confused. Has the additional time taken to write the extra characters to the serial port provided an extra delay between consecutive reads from the FDC, thus allowing success. Why would that be necessary on my board and not yours? And - what's the significance of "UNITS=2", when I only have one physical drive?

Thanks again!

[Alan Cox]

> Hi Alan,
> Is this solution based on the MAX3421E chip?

CH375 - which is much easier to interface to a classic 8bit machine.

[Wayne Warthen]

On Tuesday, August 22, 2023 at 12:26:51 PM UTC-7 MartinR wrote:

Many thanks for the file - and your continued help. I've done exactly as you've described but first included a hardware reset followed by a fresh load of CP/M 2.2 - and then run SC126.COM.

Good.

The screen-grab is attached. The output shows it reading 0x80 twice as part of the detection - and then reporting success and that I have two units (drives)! Actually,  I only have one drive ; configured as FD1 as it's a non-twist cable. Selecting '3' causes the drive to attempt to spin up, at which point the inadequate power supply dropping out causes a reset. When the system reboots to the ROM based 3.2.0, detection fails. Run SC126.COM again, and detection works. This whole process is repeatable. Note: the FDC chip is a WD37C65C-PL - if that makes any difference? 

Well, this is good news.  The implication is that your chip/system needs a tiny bit more time between status register reads (no idea why).  My chip is also a WD37C65C-PL, so that is not the issue. 

I'm now completely confused. Has the additional time taken to write the extra characters to the serial port provided an extra delay between consecutive reads from the FDC, thus allowing success. Why would that be necessary on my board and not yours? And - what's the significance of "UNITS=2", when I only have one physical drive?

I am also surprised by this, but it does appear that your system needs a tiny bit more time between the register reads.  I have no explanation for why your system would need this and mine does not.

The floppy driver does not do anything fancy to determine the number of actual physical floppy drives attached to your FDC.  The UNITS value simply reports the number of drivers the driver is configured to support.  You can change this to 1 drives (UNITS) if you build a custom ROM.

I now suspect that the delay I am using between register reads is "marginal" and should be increased for reliability for all users/systems.  I am going to prepare another test build for you that increases the delay, but removes the debug output.  I am hoping you will try this.  If it works for you, then, I will make this change permanent in RomWBW.

Thanks,

Wayne

[Wayne Warthen]

Here is a new test file for you to try.  Use it exactly the same as the previous one and post your results when you can.  This increases the delay between register reads and removes the debug output.

Thanks,

Wayne

[MartinR]

Hi Wayne -

Many thanks for the second test file. I've done the same as before, and run it from a clean boot and clean CP/M. And - success!!! I tried it 5 times, and each time it successfully discovered the FDC board. It seems to work reliably and I've attached a screen-grab again. Maybe there was just a marginal timing issue. By what margin have you increased the delays? I guess you've now allowed a 'safe' margin to allow for other edge-cases popping up.

I'm really, really pleased that things with my SC126 and FDC now appear to work. Thank-you for all your kind help - and work. Of course, I shan't be able to complete my testing until I get that new power supply, but I am now very optimistic.

You mention that you'll make the changes permanent in RomWBW. I'll need to get myself a properly updated SC126 ROM image. Is this something that Steve Cousins would do, or is rebuilding the ROM image I'm going to  have to do for myself (breaking new ground!).

Thanks also for the explanation of "UNITS=2". My intention is two have two drives (OS and data) for that retro-experience I am looking to create, and so I won't change anything.

MartinR

[Wayne Warthen]

On Tuesday, August 22, 2023 at 1:42:20 PM UTC-7 MartinR wrote:

Many thanks for the second test file. I've done the same as before, and run it from a clean boot and clean CP/M. And - success!!! I tried it 5 times, and each time it successfully discovered the FDC board. It seems to work reliably and I've attached a screen-grab again. Maybe there was just a marginal timing issue. By what margin have you increased the delays? I guess you've now allowed a 'safe' margin to allow for other edge-cases popping up.

Excellent.  Previously, I was using a simple instruction loop to perform the delay.  This is cheating because it will be a shorter delay on faster hardware.  I have switched to a cpu speed compensated delay of 2.4ms.  This is a substantially longer delay than before, but still so short that no one will ever notice the delay during bootup.  I think this should be very safe.

I'm really, really pleased that things with my SC126 and FDC now appear to work. Thank-you for all your kind help - and work. Of course, I shan't be able to complete my testing until I get that new power supply, but I am now very optimistic.

I'm happy as well because I want RomWBW to be robust and I have no way to test all possible hardware scenarios.  Reports like this help everyone.  Yes, I think that you should be in good shape with a better PSU.

You mention that you'll make the changes permanent in RomWBW. I'll need to get myself a properly updated SC126 ROM image. Is this something that Steve Cousins would do, or is rebuilding the ROM image I'm going to  have to do for myself (breaking new ground!).

I will post something here after I post the new build.  My build will be a "Development Snapshot" on the RomWBW GitHub Releases Page.  Steve would not typically distribute a snapshot build, so you should get it from GitHub.  I will post a link when it is ready.

Thanks also for the explanation of "UNITS=2". My intention is two have two drives (OS and data) for that retro-experience I am looking to create, and so I won't change anything.

Sounds good.  The default distribution allows for the maximum number of physical drives since it does no real harm if you have less than that.

Thanks,

Wayne 

[Wayne Warthen]

I have posted RomWBW Development Snapshot v3.3.0-dev.46 to the RomWBW GitHub Repository.  This build increases the delay between FDC status register reads during FDC detection.  This should resolve the FDC detection issue.

Complete ROM upgrade instructions are found in the "RomWBW User Guide.pdf" document included with RomWBW distributions.  In your specific situation, the following is a brief overview:

The new build package can be downloaded from the RomWBW GitHub Releases Page.  On this page, you will see an entry for RomWBW Development Snapshot.  In that entry, use the Assets dropdown to select and download the build package .zip file (RomWBW-v3.3.0-dev.xxx-Package.zip).  Unzip the archive.  In the Binary directory, you will find "SCZ180_126.rom".  This is a binary ROM image that you can program onto your SC126 ROM.  Since you will be upgrading from v3.2 to v3.3, you will also want to refresh your SD Card contents from the hd1k_combo.img file in the Binary directory.  This will avoid version mismatch warnings and errors.

Thanks,

Wayne

[MartinR]

Hi Wayne -

Many thanks for the overnight update you posted on GitHub. I've downloaded the Development Snapshot, copied the "SCZ180_126.rom" file to my SC126 and written it to a brand new flash chip. And to be sure that I'd done it correctly, I read the data back out of the flash chip, and copied it back to my desktop PC where I did a binary file-compare against the .ROM in the .ZIP file. They match exactly.

Note - I've yet to do the "hd1k_combo.img"; but will do - thanks for the reminder.

But if, like me, you thought that the updated "SCZ180_126.rom" would resolve the issue permanently, then sadly that's proven not to be the case. I have to admit to being rather surprised myself! I've repeatedly reset and rebooted the system, and each time "NOT PRESENT" for the FDC. Obligatory screen-grab is attached.

But booting into a fresh CP/M and running the second version of SC126.COM, just as before, does indeed show it detecting the FDC.

The only difference I can think of between the two instances is that one is a cold hardware reset, and the other is a somewhat warmer boot.

Could this indicate that from a hard reset the first read of 0x50 is happening before the WD37C65 has properly come out of reset and restarted? You mentioned adding a 2.4mS delay - but did you put any additional delay before the first read of 0x50?

I checked the datasheet for the WD37C65 and it states that a minimum of 32 'MCY' periods are required between RES going low (inactive) and the first CS\. Table-13 on Page-31 shows that for MFM at 500kbps, with a 16MHz clock, 'MCLK' is 4MHz. Therefore, 32 'MCY' periods calculates out at 8uS. I can't believe that your code is trying to access the WD37C65 within 8us of the CPU starting up - even at 18.432MHz, and allowing for some additional nS delays through an HCT125 buffer to the FDC!

I'm not sure where to go from here. Maybe someone has some ideas?

MartinR

[Derek Cooper]

Martin,

When you boot into cp/m and use the SC126.COM program. there is an option to re-boot "r" it would be interesting to see if that allows the ROM version to see the FDC. It restarts but without a reset of hard power off etc.

Derek

[MartinR]

Hi Derek -

That's an incredibly valid question! And I've tried it out. The results are:

1. Hardware reset; boots into ROM v3.3.0-dev.46 = FDC not discovered
2. Boot CP/M 2.2; run SC126-2 (Wayne's second version) = FDC discovered
3. Press 'R' to reboot system from ROM = FDC discovered

In addition:

1. Hardware reset; boots into ROM v3.3.0-dev.46 = FDC not discovered
2. Press 'R' to reboot system again from ROM = FDC discovered

After seeing both those tests change from a 'not discovered' to 'discovered', I thought I'd revert to the original v3.2.0 that I had been using. And:

1. Hardware reset; boots into ROM v3.2.0 = FDC not discovered
2. Press 'R' to reboot system again from ROM = FDC discovered

I should like to add that all the above are repeatable. I tried many times with each, and the results were consistent.

So - there's something about the hardware reset..... but I can't figure our what. Maybe it just needs a bit more delay before the very first read of 0x50 - though the timing constraints of the WD37c65C would seem contrary to that. 

MartinR

[Derek Cooper]

Hi again,

If you have a logic probe or scope maybe its worth having a close look at the reset signal. A quick look at the circuit indicates that pin 19 on the WD37c65c is reset and needs a logic 1 to be reset. it's driven high by the 74HCT125 gate (pin 11) when the system reset goes low (pin 13 on the 74HCT125). When rest is not active R3 pulls the reset signal on pin 19 low (WD37c65).

Since the sc126 uses a DS1233+5 reset chip, the signal should be active for approx 300ms, enough for you to see even if you only use an LED and resistor as a simple logic probe. 

Derek

[MartinR]

Hi Derek - 

I've checked previously - but at your suggestion I've checked again.

My logic probe shows Pin19 as firmly low with no indication of any spurious pulses. Pin19 goes high while I have my finger on the reset button, and then stays high for something less than a second after I take my finger off the button. This fits with the reset chip doing it's job. I've also confirmed with a multimeter that there is indeed 4k7 resistance between Pin19 and GND - ie the pull-down. Some versions of this design show this as 10k.

I don't have a scope - it's an aspiration -  so the best of my capabilities I consider the reset signal to the FDC to be working correctly.

Your continued help and ideas are welcome and appreciated. Thank-you.

MartinR 

[Derek Cooper]

Does it act in the same way without a floppy drive connected ? (or with if you have not connected one so far)

Derek

[MartinR]

Currently there is no floppy drive connected. So I would expect reset as-is to allow the FDC to be 'discovered'. 

But later I'll check up on whether having a drive makes a difference.  I have played with this board with and without drives attached and other observations didn't seem dependent on whether there was a drive or not. 

[Wayne Warthen]

Excellent suggestion to try a software reset Derek.  This situation is very odd.  Offhand, I can't think of any reason for the FDC to not be detected after a hardware reset.  It absolutely should not make any difference whether a drive is connected or not.  Most of my testing is without any drives connected.  There are a pair of jumpers on the Scott Baker board.  I don't remember their function, but will try to track that down in case a jumper setting matters.  I don't think so, but worth checking.

Otherwise, I will give this a bit more thought.

Thanks,

Wayne

[MartinR]

Good idea about the jumpers. Apart from the base address selection there are two jumpers, and according to my build notes, I set them according to the details in FDU.DOC. 

I'm not entirely sure of their function or how they interact with the RomWBW code. But - now they've  been mentioned, I'll go back and recheck.

MartinR

[MartinR]

I've now had the time to check the connections to the two jumpers with my multimeter, and I can confirm that my board matches Scott Baker's circuit diagram at:

http://www.smbaker.com/wordpress/wp-content/uploads/2016/12/rc2014-floppy-wd-sch.png

JP1/1=JP1/2 are jumpered together and JP2/2=JP2/3 are jumpered together. This is as detailed in FDU.DOC "The RCBus Scott Baker WDC-based floppy module should be jumpered for I/O base address 0x50 (SV1: 11-12), JP1(/DACK): 1-2, JP2 (TC): 2-3."

For completeness, here are the test results I've just recorded:

*** JP1 - DACK\ ***

JP1 Pin1 = HCT125 Pin1
JP1 Pin2 = FDC Pin5 DACK\ with 4k7 to +5V
JP1 Pin3 = HCT138 Pin15 Port00

JP1 Pin1 = JP1 Pin2 jumpered together

HCT125 EN\ Pin4 = FDC Pin17 DOR
HCT125 i/p Pin5 = FDC Pin1 RD\

*** JP2 - TC ***

JP2 Pin1 = HCT125 Pin8
JP2 Pin2 = FDC Pin6 TC with 4k7 to 0V
JP2 Pin3 = +5V

JP2 Pin2 = JP2 Pin3 jumpered together

HCT125 i/p Pin9 = +5V
HCT125 EN\ Pin10 = HCT138 Pin14 PORT04

I think perhaps Wayne, you were going to give this a bit more thought if the jumpers checked out.... I certainly don't know where to go next with this, so I am open to ideas.

I very much appreciate everyone's help with this frustrating problem - doubly so when others have posted that their boards worked first time!

MartinR 

[Derek Cooper]

I'm a bit stumped now. Other than trying to swap chips out - in case of dodgy chips? O know that may not be practical.

Wayne: Does the driver issue the software reset to the chip (mentioned in the datasheet) or does it assume a hardware reset must have happened to get to this point? Can a software reset be added ?

Derek

[Wayne Warthen]

On Thu, Aug 24, 2023 at 9:46 AM Derek Cooper <derek.coo...@gmail.com> wrote:

Wayne: Does the driver issue the software reset to the chip (mentioned in the datasheet) or does it assume a hardware reset must have happened to get to this point? Can a software reset be added ?

A good question.  Yes, in the case of the WD37C65, the driver uses the chip's in-built mechanism to soft reset the chip prior to performing the detection algorithm.  The software reset on the chip is supposed to be equivalent to a hardware reset, but that kind of thing is always hard to prove.

It is a very odd situation that the same code fails after hardware reset, but works fine after that.  This FDC does have multiple operational modes and you could make a case that the mode is different immediately after a hard reset.  However, I would expect that scenario to fail on all systems with that chip.  No one else has reported this kind of issue and the WD37C65 is the most popular FDC supported by RomWBW.  I think we are dealing with a corner case and just need to track it down.

Thanks,

Wayne

[Wayne Warthen]

On Wednesday, August 23, 2023 at 10:41:21 PM UTC-7 MartinR wrote:

I've now had the time to check the connections to the two jumpers with my multimeter, and I can confirm that my board matches Scott Baker's circuit diagram

OK.  I have also moved the jumpers around on my board and the detection logic works in all cases.  So, I don't think this is a jumper issue.  Oh well.

I think perhaps Wayne, you were going to give this a bit more thought if the jumpers checked out.... I certainly don't know where to go next with this, so I am open to ideas.

Yup.  I didn't have any epiphanies, but I have a couple ideas for getting more information.

First, since you have an SC126, I assume you have the cool dual ROM setup.  By default, the alternative ROM would be Steve's SC Monitor, right?  By setting the right jumper, you can boot into the SC Monitor, right?  I would like you to do that and then read the FDC status register twice and post the results.  By booting into the SC Monitor, the FDC should remain totally untouched until you access it with the monitor.  This may give us different results.

Second, I would like to go back to our original approach of dumping the values of the FDC status register when they are read during detection.  However, this time I would like to ask you to actually reprogram your actual ROM with the special debug code.  This way, we should see the values being read after reset (which the previous approach failed to do).  I will post a full test ROM for you shortly.

Thanks,

Wayne 

[Wayne Warthen]

On Thursday, August 24, 2023 at 10:30:58 AM UTC-7 Wayne Warthen wrote:

Second, I would like to go back to our original approach of dumping the values of the FDC status register when they are read during detection.  However, this time I would like to ask you to actually reprogram your actual ROM with the special debug code.  This way, we should see the values being read after reset (which the previous approach failed to do).  I will post a full test ROM for you shortly.

Here is the debug ROM image.

Thanks,

Wayne

 

[MartinR]

Hi Wayne -

Thank-you for your replies and continued support. Personal commitments yesterday prevented me from working on the SC126. Still dead keen on getting it working, though!

Yes - the SC126 has dual ROMs. It was one of the features that appeal to me: one to hold a 'good' ROM and a second for me to play with. I'd pulled the SCM ROM and put a blank in it's place so that I could try the Dev version of RomWBW without affecting the stable 3.2 ROM. I've put SCM back....

As you suspected, the first read of port 0x50 does not result in 0x80. Instead the first read is either 0x50 or 0x00. I've not seen any other value returned in many, many tests, though I suppose it could be possible. Subsequent reads of 0x50 always return 0x80 until a read of 0x51 turns it to 0xD0. This is repeatable across many hardware resets.

I cannot discern any pattern or rationale for either 0x50 or 0x00 value being returned. I've tried leaving it longer and longer between hardware reset and reading the port. And it doesn't seem to make a difference between the two.

SCM has a 'reset' command. And always, after a 'warm' reset, a read of 0x50 returns the same value as was previously read, be that 0x80 or 0xD0. This is to be expected as SCM doesn't touch the FDC.

I'll move on and try your debug ROM image....


MartinR

[MartinR]

Hi Wayne - 

I've swapped ROMs back to one I can overwrite and play with, and have flashed your test code (SC126.ROM) into it. 

Across multiple hardware resets it consistently shows 0x00 being returned. I'm unconvinced as to how consistent a read of 0x00 would be as under SCM I saw a value of 0x50 also being returned. I've tried exercising the system in various ways between hardware resets to see if that makes any difference. As expected - it doesn't. It is a hardware reset, after all.

The results from the manual tests under SCM to the automated test under the test ROM seem in agreement. Is it the case that the FDC detection algorithm needs to read 0x50 three times and discard the first response? 

I feel we're getting closer to the answer. Thank-you!

MartinR

[Alan Cox]

> As you suspected, the first read of port 0x50 does not result in 0x80. Instead the first read is either 0x50 or 0x00. I've not seen any other value returned in many, many tests, though I suppose it could be possible. Subsequent reads of 0x50 always return 0x80 until a read of 0x51 turns it to 0xD0. This is repeatable across many hardware resets.

0x80 / 0xD0 is the usual pattern. The 0x80 is how it comes up out of
reset, the 0xD0 is the result of then

> I cannot discern any pattern or rationale for either 0x50 or 0x00 value being returned. I've tried leaving it longer and longer between hardware reset and reading the port. And it doesn't seem to make a difference between the two.

It's more likely to be an unclean reset or some kind of difference in
timing and reset behaviour I think. 00 is command completed ok without
a seek completing, 50 is command aborted, equipment check so 50
doesn't seem unreasonable with no drive attached depending how things
float.

Looks like you have an answer though in reading it twice.

It's not clear anything is at fault - the 0x80/0xD0 probe is just the
usual way of testing the device presence, it's not written in stone
anywhere I am aware of in the data sheets.

Alan

[Wayne Warthen]

On Friday, August 25, 2023 at 3:59:58 AM UTC-7 MartinR wrote:

Across multiple hardware resets it consistently shows 0x00 being returned. I'm unconvinced as to how consistent a read of 0x00 would be as under SCM I saw a value of 0x50 also being returned. I've tried exercising the system in various ways between hardware resets to see if that makes any difference. As expected - it doesn't. It is a hardware reset, after all.

The results from the manual tests under SCM to the automated test under the test ROM seem in agreement. Is it the case that the FDC detection algorithm needs to read 0x50 three times and discard the first response? 

As Alan says, the behavior of your FDC seems unusual, but not necessarily broken.    I see little harm in modifying the detection algorithm to try twice to get the 0x80 value, so I am going to do that and post a new Development Snapshot later today.  I will post here once it is available.

Thanks,

Wayne 

[MartinR]

Hi Alan - 

Thanks for the explanation. I didn't appreciate that the method of reading 0x80 from port 0x50 twice was not a proscribed algorithm, but rather something that come about through usage. It's still odd that mine is such an edge case.

I would hope that the reset to the FDC is 'good' having been through a buffer close by, and pulled low with a resistor.  Would doing a software reset of the FDC immediately before the detection algorithm  eliminate any issue with the hardware reset. 

With no drive attached, all the inputs to the FDC should be pulled high - and that ought to ensure a consistent result.

MartinR

[MartinR]

Hi Wayne - 

OK - many thanks for yet another Dev snapshot. I'll look out for that and will try it as soon as practicable.

I wondered whether a software reset of the FDC immediately before the detection algorithm would eliminate any issue with the hardware reset? Could doing that have any adverse impact? Or maybe it's been included already? 

MartinR

[Wayne Warthen]

On Friday, August 25, 2023 at 10:16:16 AM UTC-7 MartinR wrote:

I wondered whether a software reset of the FDC immediately before the detection algorithm would eliminate any issue with the hardware reset? Could doing that have any adverse impact? Or maybe it's been included already? 

The RomWBW floppy driver has always done a software reset before the detection algorithm.  So, that doesn't explain this.

FWIW, if I boot directly to the SCM Monitor, and immediately read port 0x50, I do get the value 0x00.  Subsequent reads return 0x80.  If I do a software reset before reading port 0x50, I get 0x80 right away.  This implies there might be something amiss with your FDC chip such that it is not actually responding to the software reset.

Regardless, I will be publishing the new build shortly that should accommodate your system.

Thanks,

Wayne 

[Wayne Warthen]

RomWBW Development Snapshot v3.3.0-dev.48 has been posted on the RomWBW Releases Page.  This includes the revised FDC detection.

Thanks,

Wayne

[MartinR]

Hi Wayne -

Many thanks for your reply.

OK - I suspected that you'd have done a software reset before the FDC detection. But, good to have it confirmed.

Interesting that your FDC responds immediately with 0x80 after a hardware reset followed by a warm reset. Under the same conditions mine responds reliably with 0x00 until that second read of port 0x50. I agree that it suggests something awry with the software reset on my FDC. I'm not sure how to confirm this, apart from getting another FDC, which may not prove conclusive.

I've tried RomWBW Development Snapshot v3.3.0-dev.48 - and - woohooohoooooo!! It now reliably reports that I have an FDC. Apologies for posting one last screen-grab - but I just had to! Thank-you!!

Now that RomWBW reliably detects my FDC I am planning to move on, leaving the question of the software reset on my FDC chip to one side, and instead look to getting a suitable power supply for the two drives themselves. In time to come I may revisit the software reset as it nags at me. But.....

As a way of wrapping up this thread, I'd like to thank everyone who has contributed  to resolving what can only be considered as an extreme edge-case. Particular thanks must go to Wayne, and also to Alan and Derek. What a community!! Thanks, everyone!!

MartinR

[Wayne Warthen]

Very glad to know that it is working.  This may help others in the future without them even knowing it.

Good luck getting your actual drives working.

-Wayne

[MartinR]

Thanks, Wayne. And pleasing to know that inadvertently I've possibly helped others.

[G Kr]

Hello everyone,
I took the discussion as an opportunity to put my own (RC2014 Floppy Controller, WD37C65 version) into operation on my SC126. Unfortunately with even less success than MartinR. I updated RomWBW to v3.3.0-dev.48. The boot output is shown below. On the query: "I 50" in the monitor I only get 0x78 as with non-existent addresses.
I have already exchanged the cips WD37C65 and both 74HTC138... without any effect.
Does somebody still have an idea?
Thanks in advance

Gerd

RomWBW HBIOS v3.3.0-dev.48, 2023-08-26

Small Computer SC126 [SCZ180_sc126] Z8S180-N @ 18.432MHz IO=0xC0
0 MEM W/S, 2 I/O W/S, INT MODE 2, Z180 MMU
512KB ROM, 512KB RAM
ROM VERIFY: 00 00 00 00 PASS

AY: MODE=RCZ180 IO=0x68 NOT PRESENT
ASCI0: IO=0xC0 ASCI W/BRG MODE=115200,8,N,1
ASCI1: IO=0xC1 ASCI W/BRG MODE=115200,8,N,1
DSRTC: MODE=STD IO=0x0C Sat 2000-01-01 23:09:05 CHARGE=OFF
MD: UNITS=2 ROMDISK=384KB RAMDISK=256KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: ATA 8-BIT LBA BLOCKS=0x0007A2B0 SIZE=244MB
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
SD: MODE=SC OPR=0x0C CNTR=0xCA TRDR=0xCB DEVICES=1
SD0: NO MEDIA
FP: IO=0x00 NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ASCI0:      RS-232            115200,8,N,1
Char 1      ASCI1:      RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      MD1:        ROM Disk          384KB,LBA
Disk 2      IDE0:       CompactFlash      244MB,LBA
Disk 3      IDE1:       Hard Disk         --
Disk 4      SD0:        SD Card           --


Small Computer SC126 [SCZ180_sc126] Boot Loader

Boot [H=Help]:

[Alan Cox]

> I took the discussion as an opportunity to put my own (RC2014 Floppy Controller, WD37C65 version) into operation on my SC126. Unfortunately with even less success than MartinR. I updated RomWBW to v3.3.0-dev.48. The boot output is shown below. On the query: "I 50" in the monitor I only get 0x78 as with non-existent addresses.
> I have already exchanged the cips WD37C65 and both 74HTC138... without any effect.
> Does somebody still have an idea?
> Thanks in advance

Check the jumpers and the connectivity of the lines using for the
decode first in case it is a bad solder joint. I would start by
writing some code to keep doing an access of the port 0x50 and check
if the chip select line is going low on the decoder output. That will
tell you if the problem is on the 7C65 side or on the decode side. In
my experience the chips are the least likely to be the problematic
bit.

Alan

[G Kr]

Hello Alan,
I forgot to mention the jumpers... they are in the places as shown in all the pictures available to me. SV1 on address 40, JP1 on between 1 and 2 and JP2 between 2 and 3.
When accessing 0x50 and 0x51, FDC_DS goes low.
So the address decoding seems to be working.

FDC_DOR and FDC_CCR remain high.

Gerd

[Alan Cox]

On Mon, 28 Aug 2023 at 12:05, G Kr <krie...@gmail.com> wrote:
>
> Hello Alan,
> I forgot to mention the jumpers... they are in the places as shown in all the pictures available to me. SV1 on address 40, JP1 on between 1 and 2 and JP2 between 2 and 3.
> When accessing 0x50 and 0x51, FDC_DS goes low.
> So the address decoding seems to be working.

Is RESET low (on the 7C65 side) ? Otherwise the RD line is about all
that matters for getting some kind of response and is a direct
connection. Other than that only the power rails and maybe clock
should be needed to get some kind of response.

[G Kr]

Attached is a logic analyzer recording.
G2A is the input of IC7. Otherwise as labeled.
It actually looks good... only the read value is 0x78.  :-(

[G Kr]

I just see that the pictures show a WD37C65C. I have a WD37C65B in use. The differ in the data rate ... is that relevant here?

Gerd

[Wayne Warthen]

On Monday, August 28, 2023 at 6:45:07 AM UTC-7 G Kr wrote:

I just see that the pictures show a WD37C65C. I have a WD37C65B in use. The differ in the data rate ... is that relevant here?

WD37C65B is fine.  I have another system that uses one.  The WD37C65C basically just added the ability to handle 2MB floppy drives, but RomWBW does not use that functionality.

Thanks,

Wayne 

[G Kr]

Well, what else could it be? The signals look pretty good so far... right? The signals are measured directly on the WD37C65, once at address 0x50 and at 0x51. As already seen above, RESET is low and the 16MHz clock is also there.
A CF adapter runs fine, so the bus is ok, there must be something on the WD card.
I won't be able to continue on with it for a good two weeks, but maybe one or the other has an idea...

Gerd

[Wayne Warthen]

I don't see anything wrong with the traces.  Sorry, not sure what to suggest.

You may need to try replacing the chip itself.

Thanks,

Wayne

[G Kr]

First of all, thanks Wayne.
I've already swapped all the chips involved... with no effect.

[Wayne Warthen]

On Tuesday, August 29, 2023 at 1:19:00 PM UTC-7 G Kr wrote:

I've already swapped all the chips involved... with no effect.

OK.  I guess you could try adding I/O wait states and/or reducing CPU clock speed.

-Wayne 

[G Kr]

Et voilà! A newly ordered WD37C65C! (WD37C65B before) leads to immediate success. The controller is recognized. A floppy disk can be formatted and written to.
Thank you again for your assistance.

Gerd

[Wayne Warthen]

Very glad to hear it is working now.  Odd that the WD37C65B chips did not work.

Thanks,

Wayne