Another Floppy Controller Board

[Alan Cox]

I needed to do a floppy board because I've got a box of 37C65s but they are all PLCC. I also wanted to fix a few of things about the Scott Baker board

- The lack of  26 pin connector (for 3" drives)

- The ability to use dual crystals for some 5.25" configurations (and for handling weird stuff)

- Don't ground pin 3 as on some devices that is Vcc as a few obscure old drives use it as Vcc (26pin is even weirder - I didn't deal with it this time but in the final one I probably should also support the EME-215FS and some of the other oddities that put Vcc on 1-3-5 and HD out on 9 on the 26 pin).

The other thing I tidied up was the address ranges. I didn't like the way the original splatted stuff around, so this one uses a tight block of 6 I/O ports, the upper four of which can be overlaid by another device that is read only.

Still just testing it as I need to sort out some power arrangements for the drives and system.

Alan

[Tom Szolyga]

Hi Alan,

I like it!  When you are done testing, please share the design.  I want to build one.

Tom

[Wayne Warthen]

On Monday, April 20, 2020 at 11:34:51 AM UTC-7, Tom Szolyga wrote:

Hi Alan,

I like it!  When you are done testing, please share the design.  I want to build one.

Yeah, I'm going to want one of these as well.

-Wayne 

[Ed Brindley]

Good work on putting the cable exit on the right hand edge.

Adding it to my to-build list along with your dual serial and PS/2 boards, JB's TMS9918 and Steve's CTC board

Cheers,
Ed

[Anna Christina]

Hi Alan,

very nice!

So, it is compatible with RomWBW's "FDMODE_RCWDC" mode?

It would be great if it will be possible to get a board as soon as you are finished.

I would replace my smbaker board with this one, as its shape matches all other boards :) (will it also be available in blue? *g*)

Regards,

Anna

[Peter Schmelzer]

Hi Anna,

if you are only looking for a RC2014-Style Floppy Controller Board, look here:

https://easyeda.com/alaorjr/RC2014_Floppy-51da5496cc974dff88028fa1d400e761 

It's based on Dr. Scott Bakers design.

I've got a few of them here and planned to sell the on ebay Germany at the end of this week.

I can send you one today if you are interested. Drop me a PM with your address.

Best regards/Viele Grüße

Peter

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/c58da6d6-11ef-4355-92f2-0cd210981720%40googlegroups.com.

[Anna Christina]

Am Dienstag, 21. April 2020 11:55:33 UTC+2 schrieb Peter Schmelzer:

Hi Peter,

if you are only looking for a RC2014-Style Floppy Controller Board, look here:

https://easyeda.com/alaorjr/RC2014_Floppy-51da5496cc974dff88028fa1d400e761 

It's based on Dr. Scott Bakers design.

 No, I like Alan's idea of a thight address range without any "mirrored" IO ports.

Thank you!

Regards,

Anna 

[Alan Cox]

On Tuesday, 21 April 2020 10:34:48 UTC+1, Anna Christina wrote:

Hi Alan,

very nice!

So, it is compatible with RomWBW's "FDMODE_RCWDC" mode?

Unless I've screwed up then yes it should work with ROMWBW. It's still a 37C65 so just the addressing will need a tweak.

It would be great if it will be possible to get a board as soon as you are finished.

I would replace my smbaker board with this one, as its shape matches all other boards :) (will it also be available in blue? *g*)

 Once I've debugged and tested it I'll upload the Gerbers to hackaday so you can have any colour you like!

Alan

[Anna Christina Naß]

Am 21.04.20 um 16:08 schrieb Alan Cox:

Hi Alan,

>> So, it is compatible with RomWBW's "FDMODE_RCWDC" mode?
> Unless I've screwed up then yes it should work with ROMWBW. It's still a
> 37C65 so just the addressing will need a tweak.

What do you mean with the tweak?
The tweak you did to narrow the IO port usage or is a configuration
tweak in the software neccessary?

Thank you!

> Once I've debugged and tested it I'll upload the Gerbers to hackaday
> so you can have any colour you like!

Cool, thank you!

Regards,
Anna

[Wayne Warthen]

On Tuesday, April 21, 2020 at 7:08:36 AM UTC-7, Alan Cox wrote:

On Tuesday, 21 April 2020 10:34:48 UTC+1, Anna Christina wrote:

Hi Alan,

very nice!

So, it is compatible with RomWBW's "FDMODE_RCWDC" mode?

Unless I've screwed up then yes it should work with ROMWBW. It's still a 37C65 so just the addressing will need a tweak. 

Will probably be a new FDMODE setting, perhpas FDMODE_EPFDC.  Trivial to implement in RomWBW.

-Wayne 

[Alan Cox]

On Tuesday, 21 April 2020 15:30:01 UTC+1, Anna Christina wrote:

Am 21.04.20 um 16:08 schrieb Alan Cox:

Hi Alan,

>> So, it is compatible with RomWBW's "FDMODE_RCWDC" mode?
> Unless I've screwed up then yes it should work with ROMWBW. It's still a
> 37C65 so just the addressing will need a tweak.

What do you mean with the tweak?
The tweak you did to narrow the IO port usage or is a configuration
tweak in the software neccessary?

Changing the I/O port range that it expects and the offset for some ports.

Alan

[Alan Cox]

Will probably be a new FDMODE setting, perhpas FDMODE_EPFDC.  Trivial to implement in RomWBW.

I am currently pondering how to auto-probe this and the FDC reliably and if I need to arrange anything to provide a way to probe it. Right now there are a couple of ways to do it that might work. The first is that you can issue a command that does data transfer and try one TC address and look for a timeout. The second is that mine has an address to hit the reset pin (because I've had enough fun with ancient FDCs getting totally confused) and I think you can get the FDC into a position that a status read will tell you if the read caused a reset and thus the register map to use.

I made a lot more progress than expected (ESO is down which helped no end!) and t's almost working

Bdos Err On D: Bad Sector
FD: READ 46 01 01 00 01 02 12 1B FF --> 41 10 00 01 00 02 02 [OVERRUN]
Bdos Err On D: Bad Sector

which I think is because I forgot to wire DACK and TC together. Little bit of blue wiring required.

The software side is going to need some more work I think. The 180K 3" drive I want to use for some of this is DD 40 track and may also need some different step timings. Then I have an easier way to get stuff onto my ZX Spectrum +3, CPC6128 and PCW machines, although I need to fix the CPC6128 it turns out. Fortunately all these systems use the same arrangement for CP/M file formats.

Alan

[Alan Cox]

Still getting overrun errors. Apart from that it appears to be driving the FDC correctly.

Should a 7.3MHz system be able to handle 1.44MB disks under ROMWBW ?

Also FDU doesn't behave - is FDU using ROMWBW/asking ROMWBW for config data or does it have have all the config hardcoded for each controller ?

Alan

[Anna Christina Naß]

Am 22.04.20 um 15:36 schrieb Alan Cox:

Hi Alan,

> Should a 7.3MHz system be able to handle 1.44MB disks under ROMWBW ?

I'm using a smbaker FDC with a WD37C65C on my RC2014 (7.3 MHz) running
RomWBW - and I can use 1.44MB floppy disks without any problems.

Regards,
Anna

[Wayne Warthen]

FDU operates directly on hardware and has no interaction with RomWBW HBIOS at all (unless it uses it for console I/O, don't remember now).

Like Anna, I have also been successful with 1.44MB floppy on a 7.3MHz system.  It looks like FDU does not disable interrupts for sector read/write.  That can definitely cause overrun errors on a system that is generating periodic interrupts.  I am sure I disabled interrupts in RomWBW HBIOS for sector I/O.  Not sure why I did not do that in FDU.  I should change that in FDU.

-Wayne

[Alan Cox]

I fixed up FDU and it gets even more interesting.

If I set the unit = 01, media 1.44MB, mode poll then my second drive works reliably at 1.44MB within FDU. I can format, do read/write tests and all appears to be great so the hardware appears to be up and running. The other drive (which I assume is unit 0) doesn't want to play but that might be the drive or something else. If I try to use it in CP/M (or ZSDOS) then the C drive fails and the D drive gives bad sector errors with overrun (Same drive model. same manufacturer).

Even more interesting if I run it under my emulator with lib765 based 765 emulation (original 765 but with the PC operation/control registers added and not 37C65) then FDU works there too, and ZSDOS and CP/M also fail on the emulator. I think that means I've probably got a software problem or don't understand something about how ROMWBW expects the drives to be cabled. I wouldn't read too much into it failing in the emulation because I don't yet know why it fails in the emulation and what I may have screwed up.

Alan

[Sergey Kiselev]

Alan,

How your first drive (0) and the second drive (1) are wired, particularly how Drive Select (/DS1, /DS2) and Motor On (/MO1, /MO2) signals are connected?

I am pretty much sure RomWBW and FDU expect PC/AT cabling, that is both floppy drives are configured as the "second drive" ("DS2" or "DS1", depending if they count from 1 or from 0) and the cable has a twist between the second drive (closest to the controller) and the first drive (at the far end of the cable) that swaps Motor On and Drive Select signals.

It wouldn't work correctly when using a straight cable and floppy drive jumpers to configure drive number. That is the second drive will work, but not the first one.

--Sergey

[Alan Cox]

On Thu, 23 Apr 2020 at 16:50, Sergey Kiselev <skis...@gmail.com> wrote:
>
> Alan,
>
> How your first drive (0) and the second drive (1) are wired, particularly how Drive Select (/DS1, /DS2) and Motor On (/MO1, /MO2) signals are connected?
> I am pretty much sure RomWBW and FDU expect PC/AT cabling, that is both floppy drives are configured as the "second drive" ("DS2" or "DS1", depending if they count from 1 or from 0) and the cable has a twist between the second drive (closest to the controller) and the first drive (at the far end of the cable) that swaps Motor On and Drive Select signals.
>
> It wouldn't work correctly when using a straight cable and floppy drive jumpers to configure drive number. That is the second drive will work, but not the first one.

They'll be set up the proper way (ie not the PC/AT way) as they are
not from the PC world. That would explain why FDU only works with the
second drive, but not why ZSDOS/CPM report overruns and FDU doesn't.
Thanks - one mystery resolved.

Alan

[Wayne Warthen]

On Thursday, April 23, 2020 at 9:02:54 AM UTC-7, Alan Cox wrote:

They'll be set up the proper way (ie not the PC/AT way) as they are
not from the PC world. That would explain why FDU only works with the
second drive, but not why ZSDOS/CPM report overruns and FDU doesn't.
Thanks  - one mystery resolved.

For better or worse, all of the existing WD37C65 implementations (before yours) use AT style connectors/cabling.  I assume you overcame this with FDU when you created a new variation for your hardware.  The RomWBW floppy driver will require a similar change.  Should not be too hard -- the driver doesn't really care about cabling, it just needs to initialize the FDC in the correct mode.

Sadly, all of this floppy code (both FDU and the RomWBW driver) was created a decade ago when I was just learning Z80 assembler.  Never really revisited it because it always worked.

-Wayne

[Alan Cox]

For better or worse, all of the existing WD37C65 implementations (before yours) use AT style connectors/cabling.  I assume you overcame this with FDU when you created a new variation for your hardware.  The RomWBW floppy driver will require a similar change.  Should not be too hard -- the driver doesn't really care about cabling, it just needs to initialize the FDC in the correct mode.

Sadly, all of this floppy code (both FDU and the RomWBW driver) was created a decade ago when I was just learning Z80 assembler.  Never really revisited it because it always worked.

-Wayne

Yep. I switched to an old PC drive and cabling and that also works reliably with FDU - but not ROMWBW (git head). I guess I should try my mods on ROMWBW 3.0 or another known good for RC2014 floppy ROMWBW to eliminate that from my investigation. At the moment I am debugging the Fuzix FDC code to see if that gives me any more clues.

Anna - what ROMWBW version are you using that woks with floppies ?

Alan

[Wayne Warthen]

On Thursday, April 23, 2020 at 11:43:48 AM UTC-7, Alan Cox wrote:

Yep. I switched to an old PC drive and cabling and that also works reliably with FDU - but not ROMWBW (git head). I guess I should try my mods on ROMWBW 3.0 or another known good for RC2014 floppy ROMWBW to eliminate that from my investigation. At the moment I am debugging the Fuzix FDC code to see if that gives me any more clues.

Anna - what ROMWBW version are you using that woks with floppies ?

There is one significant difference in the operation of FDU and RomWBW HBIOS code.  FDU was modified to not require the TC signal.  Instead, when it programs the FDC to read/write a sector, it tells the FDC that the sector requested is the last sector on the track, so the FDC will automatically stop I/O after reading one sector.  By default, the FDC will continue reading sectors until it has read the last sector of the track.

I never modified RomWBW HBIOS with this change.  Instead it uses the approach of asserting TC to force the FDC to stop reading/writing.  There have been no recent changes to the fd.asm driver and I would be very surprised if any recent version of RomWBW produced different results.  I would suggest looking very carefully at the TC signal or propagating the end of sector logic from FDU to HBIOS fd.asm driver.

Of course, you may make better progress with your own driver in Fuzix!

-Wayne

[Sergey Kiselev]

I was going to suggest that the overrun error might be caused by the TC implementation. It might be worth checking the TC signal connection on your FDC.

Although, Zeta SBC V2, that uses the same floppy code, has TC tied HIGH permanently, and it works just fine.

Also, did you check that you don't get any interrupts while transferring the data to/from FDC? Last time I tested it (5 years ago), HBIOS code worked reliably with Z80 running at 6 MHz on a system without interrupts.

More details:

RomWBW uses NEC µPD765 and the follow-up designs, including WD37C65, in DMA mode (if I recall correctly, DMA mode works faster than programmed I/O mode). Of course we don't have DMA, so we fake it using /DACK instead of /CS to read or write data to FDC. Now, in DMA mode FDC expects to get TC signal at the end of transfer, and if it doesn't get one, it reports "Abnormal termination" error. It is possible to fake TC, or just ignore that "Abnormal termination" error in case that all data was send/received from FDC.

--Sergey

[Sergey Kiselev]

I did some more digging through my e-mails, and found a 5 years old e-mail exchange with Wayne.

So, RomWBW does use the programmed I/O mode (and not pseudo-DMA as I thought). But, even with programmed I/O, when running in IBM PC/AT mode, the 37C65 expects TC to be pulsed at the end of the transfer. Also, in IBM PC/AT mode TC is qualified with /DACK. So basically just connecting TC high and pulsing /DACK by reading the respective register (0x38 for Zeta SBC V2, it seems that the default is 0x58 for Scott Baker's board) is enough ;-)

BTW, Scott Baker's board has a jumper for TC signal... not sure why... it shouldn't be needed :-)

-- Sergey

[Anna Christina]

Am Donnerstag, 23. April 2020 20:43:48 UTC+2 schrieb Alan Cox:

Hi Alan,

> Anna - what ROMWBW version are you using that woks with floppies ?

Version 3.0 (master branch) and also the latest dev versions of this week/the last weekend.

I'm using a standard PC drive (1.4MB) at the end of a "twisted" floppy cable.

Regards,

Anna

[Alan Cox]

There is one significant difference in the operation of FDU and RomWBW HBIOS code.  FDU was modified to not require the TC signal.  Instead, when it programs the FDC to read/write a sector, it tells the FDC that the sector requested is the last sector on the track, so the FDC will automatically stop I/O after reading one sector.  By default, the FDC will continue reading sectors until it has read the last sector of the track.

And this was indeed the problem. I didn't know all the weird and wonderful magic about PC/AT mode. WIth Sergey's explanation I swapped it over to pull TC high and strobe DACK and now all is happy in ROMWBW

Of course, you may make better progress with your own driver in Fuzix

The Fuzix 37C65 driver is far from perfect and a lot less featured still. I have yet to add format detection, disk formatting and the like to it.

Tightening the inner loop to run 1.44MB at 3.5MHz doesn't actually look too hard for ROMWBW. The classic way it was done was to make use of left shift, jr c, jp p and ini. The FDC will always let you out of the loop with an error or other status. If I get a moment I'll take a look at it.

Alan

[Wayne Warthen]

On Thursday, April 23, 2020 at 1:46:21 PM UTC-7, Alan Cox wrote:

And this was indeed the problem. I didn't know all the weird and wonderful magic about PC/AT mode. WIth Sergey's explanation I swapped it over to pull TC high and strobe DACK and now all is happy in ROMWBW

Very glad to hear it is now working. 

Tightening the inner loop to run 1.44MB at 3.5MHz doesn't actually look too hard for ROMWBW. The classic way it was done was to make use of left shift, jr c, jp p and ini. The FDC will always let you out of the loop with an error or other status. If I get a moment I'll take a look at it.

Always happy to get code improvements.

-Wayne