Floppy Disk Controller and Real Time Clock (Flock) V2 Improvements

[Sergey Kiselev]

Hi,

I would like to re-spin the Floppy Disk Controller and Real Time Clock module, and I would appreciate community feedback on my ideas, as well as suggestions for other improvements and features.

Suggested changes or improvements:

- Jumper configurable RTC address - 0xC0 for Z80 based boards, or 0x0C for Z180 based boards

- I plan to use ATF16V8 SPLD for address decode and such. Some people might be uncomfortable with using programmable logic. This particular part is being currently manufactured. It can be programmed using commonly available EPROM programmers (MiniPro, XGecu), and the programming process is no different than programming a Flash ROM or an EPROM. Development is done using open source galasm tool. The logic equations are pretty easy to read, probably easier than understanding the logic looking at the gates and decoders on the schematics diagram

- Use RCBus form factor; Use 80-pin connector that provides better support, and makes it less likely to install the board incorrectly (e.g., by shifting it 1 position to the right)

- Add an option to use CR2032 battery instead of supercapacitor. Either one could be used, but of course not both together

- Option to add the second 9.6 MHz crystal. That crystal is used by 37C65 FDC to generate clock for 300 Kbps transfer rate, used with 360 KB disks in 1.2 MB drives (perhaps other drives too?! 8"?). Not sure if that's a common use case, so I'd appreciate your feedback. Do you think it is important to have, or not so much?

- Option to route IRQ/INT signal to the RCBUS. It will be a jumper block allowing to choose one of the following signals nINT, nNMI, INT1, INT2, or none if jumper is not installed (default)

- Potentially replace the connector used for powering the floppy drive. Flock V1 uses 2-pin shrouded locking male connector (AMP/TE MTA-100 series). That is not the most common connector ever. So it was a recommendation to replace it with something more common. In my opinion, to prevent short-circuiting the power rails it should be either a shrouded male connector or a female connector. It is also important that a cable-mounted counterpart is available. Any recommendations here? Perhaps use a more common 2.54 mm shrouded locking header, similar to that used in older IDE CD-ROM drives for audio output (4 pin version: https://www.mouser.com/ProductDetail/571-5-103673-3, 2 pin version: https://www.mouser.com/ProductDetail/571-5-103673-1) Also should I use 2-pin, 3-pin, or 4-pin connector? Presumably 3 or 4 pins would allow for 2 ground pins, providing better ground, but with that being said floppy interface already has ground on almost every other pin, so I don't think having an additional ground would make any difference. Any opinions or recommendations about what connector to use?

Anything else I am forgetting here?

A couple of RCBus questions (Steve and Tadeusz, I am looking at you here):

- I have a bit of confusion about RCBus INT1 and INT2 specs. Looking at Chapter 7 of RCBus specifications, these signals don't have an "n"/active low prefix. But then, in Chapter 8.3 it says nINT1 and nINT2 - active low. Which one is true?

- Also, looking at Chapter 13. Appendix B, it appears that the 3.2 mm hole is slightly shifted relative to pin 1 of the header compared to RC2014. Is that intentional? The potential issue here, is that some people might use these holes to secure boards to each other, and that little shift might be enough to cause a misalignment.

Thanks,
Sergey

[Wayne Warthen]

Everything you are proposing sounds great to me Sergey.  I don't have a strong opinion about the floppy power connector.  I was fine with the connector on the V1 board, but open to change.

Thanks,

Wayne

[Tadeusz Pycio]

The /IRQ1 and /IRQ2 signals are activated in the low state. When using the Z80 CTC or PIO as an interrupt controller, this is actually a conventional issue, but it is useful to keep the state low. Unlike the /INT signal, the OC output is not required for the device.

[Sergey Kiselev]

Thanks for the important clarification that /INT (nINT) should be an open collector output. I'd think the same should apply to /NMI, /BUSREQ, and possibly /WAIT?

It would be nice to document that in the RCBus specs. It only mentions that nINT should be open collector in the context of Motorola bus extension.

On my side, I'll need to come up with a way to implement an OC output for the interrupt. Perhaps use an actual NPN or an nMOS transistor?

Or just skip that part and only implement INT1/INT2.\

How does everyone feel regarding interrupts for FDC? I recall we did some experiments with interrupt-driven I/O back in N8VEM SBC times, and it wasn't working any better than programmed I/O.

[Tadeusz Pycio]

Hi Sergey,

You are right, in hindsight it appears that a few things should have been added to the specification. The aforementioned OC requirements for the /INT, /NMI, /BUSREQ and /WAIT signals, the normalisation of the DMA handler request signals, the addition of the alternative signals /CTS, /RTS in place of TX2, RX2.

I think redirecting the INT signal from the floppy controller to the /IRQ1, /IRQ2 pins (I prefer these designations which clearly separate from the otherwise working /INT signal) is not a bad idea. The use of interrupts may be useful for multitasking operating systems, in other cases, polling will do the job just fine.

[Tadeusz Pycio]

I solved the retention of the /INT signal requirements and the redirection to /IRQ1 or /IRQ2 as follows in the 16C450/550 module:

[Steve Cousins]

Sergey,

You are right about the inconsistent naming of INT1 and INT2. I'll make a note to correct this in any future update of the specification.

To clarify, both are active low.

I agree with Tadeusz, the specification should also specify open collector (or not) for the interrupt signals. And, as you say, all signals should specify this.

I think the specification for the interrupt pins should also state if they are edge or level sensitive.

As for the the slight difference in position of the 3.2mm hole relative to bus pin 1, I'm not sure why there is a difference. I've just checked the math between Spencer's template and the RCBus specification, and can confirm the difference is 14 mil on the Y axis and 19.5 mil on the X axis, assuming I didn't miscalculate. I have aligned 2 boards with header pins through both boards to align the bus pins and the difference is clearly visible. Is it enough to cause a problem if a rod is used between a set of boards to secure the modules? Possibly. In the real world I think it is probably close enough for most use cases. See photo.

I think the intention was to have the hole in the same position relative to pin 1 but somehow it ended up being a little out.

For what it is worth, I supply my kits with spacers to ensure a minimum distance between the modules. I think this solves the problem of modules leaning over and touching. I see this as the main reason to have the holes. With 80-pin connectors the modules are quite stable and definitely won't fall out. Thus, the 3.2mm holes are not needed to keep the modules from falling out by running a rod through all of the modules. Having spacers fitted also gives you something to get hold of when trying to remove modules. With the spacer approach the hole alignments are not critical, which is fortunate given the position issue. Just my two cents worth.

Steve

[Alan Cox]

> I agree with Tadeusz, the specification should also specify open collector (or not) for the interrupt signals. And, as you say, all signals should specify this.
> I think the specification for the interrupt pins should also state if they are edge or level sensitive.

Edge or level is not a property of the bus but of the processor and
the software so I disagree on this. The rest makes sense. A device
pulls the IRQ line down when it wants attention. What happens then is
up to the CPU card from "I vector the interrupts" to "what is an
interrupt I only poll". There is no hardware difference. You don't
want edge triggered for a shared line unless you are a masochist line but
that's a separate matter.

Probably it should also note that
- any device should support using \IRQ as that may be all there is
- a device may support the other lines
- a backplane may have options to route some interrupt lines to some
slots but should allow them all to use \IRQ





Alan

[Sergey Kiselev]

Below is the updated design.

The modifications are:

- Use ATF16V8B SPLD for address decode
- Add RTC address selection jumper: 0xC0 (Z80-compatible) or 0x0C (Z180-compatible)
- Use RCBUS specifications: module formfactor, signal names, 80 pin connector
- Either a CR2032 battery or a supercapacitor can be used for RTC
- Add interrupt support. Interrupts can be routed to /INT, /NMI, /IRQ1, or /IRQ2
- Add 9.6 MHz crystal for 360 KB in 1.2 MB drive support (300 Kbps transfer rate)

- The floppy connector rotated 180 degrees, so that a right angle connector can be used (right angle connectors have pin #1 on the right side)

There are probably more things that I am forgetting...

Please review

-Sergey

[Tadeusz Pycio]

Looks good, great idea with the nINT/nNMI jumper, although here I have my doubts that the 74LVC1G04 has an OD output (I haven't read the documentation) and that it won't scare off retro purists with its casing ;-)

[Mark T]

That should probably be a 74lvc1g06, just wasn’t renamed after picking something with the same footprint.

I’m not sure a pull down resistor is a good idea for irq1 and irq2, is it not likely that the processor card will have pull up resistors?

[Tadeusz Pycio]

I’m not sure a pull down resistor is a good idea for irq1 and irq2, is it not likely that the processor card will have pull up resistors?

It seems that this pull-down resistor is the correct solution. The /IRQ1 and /IRQ2 lines are routed to the interrupt controller, not the processor for the RCBus intended for the Z80.
The suggested problem may arise for 680x and 6502 processors, but there the connection to /IRQ1 can be dispensed with.

[Sergey Kiselev]

Good catch. I meant to use 74LVC1G06 instead of 74LVC1G04!

They are available in SOT-23-5 packages, and I use a large, hand soldering friendly footprint. Also, it is an optional part, only needed for /INT or /NMI support.

/IRQ1 and /IRQ2 should be regular logic inputs, not open collector / open drain. Typically they are Z80 CTC trigger inputs or Z80 PIO GPIOs.

It is a good question what is the actual implementation on the interrupt controller side though... If needed the pull-down resistor value can be decreased, so that when the 74HCT125 gate floats the output, it will stay below VIL voltage.

Again, interrupts are optional for this board operation. I believe currently RomWBW doesn't use interrupts. FDU might use interrupts?! (it's been a while, I don't remember).

Of course, we can say that interrupts are not required, and get rid of all circuitry related to interrupts.

- Sergey

[Sergey Kiselev]

The other option, is to use 74LVC1G06 output for all interrupts, but in case of IRQ1 and IRQ2 use a built-in pull-up. Tadeusz does this in his 16C450 module mentioned above

[Sergey Kiselev]

After checking RomWBW, my old Zeta SBC V2 and ECB Disk I/O V3 notes, and exchanging emails with Alan (thanks!), I think I am going to scrap the interrupt feature.

There seem to be no use for it in RomWBW or FUZIX.

What should I do with the available 74HCT125 gate? I can use it as a one bit input. Zeta SBC does that. It has a jumper that can be read through bit #6 of the RTC port.

Also, I have two unused 74HCT174 outputs. Should I make some blinkenlights? :)

-Sergey

[Tadeusz Pycio]

Regarding the need for interrupts for FDCs, I have no opinion, but would like to add some solution to the OC/OD problem for outputs /INT as used in the 16C2552 module - a diode for normal TTL logic.

[Steve Cousins]

Well you can never have too many blinkenlights!

How about connecting the two spare outputs, the input, RTC_CLK, GND and 5V to a header for use as an SPI port.

Steve

[Sergey Kiselev]

How about connecting the two spare outputs, the input, RTC_CLK, GND and 5V to a header for use as an SPI port.

Any particular bits of the data bus / port 0x0C or 0xC0 you'd recommend?

Looking at SC126, the first SD card /CS uses D2, the second SD card /CS uses D3, and I2C uses D0 for SCL

I can use D7 for the available input (74*125 output).

But that will actually conflict if the card is used with SC126, although the RTC bits will conflict too...

A bit of feature creep... But if I use a single inverter (or a transistor), I could free up another 74*125 for I2C bus implementation... (or just use an additional single gate 74LVC1G125)

[Steve Cousins]

Compatibility with SC126 is a good point. I've sold 572 SC126 kits, some PCBs (I'd guess about 50), plus others may have sourced their own so compatibility with SC126 is a significant issue.

The real time clock conflict with the one on SC126 is the first problem to solve, I think. The conflict is the read from RTC at address 0x0C bit D0. A jumper on the output of U5C pin 8 (D0) would allow isolation. Not pretty but it would fix the conflict with SC126 whilst allowing it to be enabled for use with other Z180 systems that don't have a RTC. 

SC126 uses port 0x0C input bit D7 to read the I2C SDA signal. Any use by Flock of D7 as an input would create the same sort of conflict as the RTC D0. 

For info: I have several I2C modules. SC137 and SC704. Both have a totally configurable I/O address. Both use D0 for SCL (both input and output), D7 for SDA (both input and output). My documentation and example code assume the address is 0x0C (for software compatibility with SC126).

Given the availability of the I2C modules and the conflict with SC126 that already has an I2C port, perhaps trying to add I2C to Flock is not the best use of the spare bits.

One simple option would be just to provide a header for the spare outputs, the spare input, GND and 5V. They would then be available for custom functions. I would suggest avoiding the input being D0 or D7 to avoid a conflict with SC126, but any other bit should be okay I think. LEDs on the spare outputs would be a nice bit of eye candy.

Steve

[Sergey Kiselev]

Another attempt :)

Changes:

- Remove interrupt circuitry

- Add header for otherwise unused signals for the RTC I/O port 0xC0/0x0C: 

  - Outputs are connected to D0 and D2 

  - Input is connected to D6

- Add a solder bridge jumper on the back side for disconnecting the RTC output from D0 signal. This solder bridge is normally closed (with a PCB trace)

- Use a solder bridge jumper for enabling 9.6 MHz crystal. The default position disables 9.6 MHz crystal

The default settings should work for most users.

SC126 users will need to cut the JP2 bridge

Users that want to use 9.6 MHz crystal will need to cut the JP3 bridge, position 1-2, and put a solder blob at position 2-3

[Alan Cox]

On Thu, 21 Sept 2023 at 22:01, Sergey Kiselev <skis...@gmail.com> wrote:
>
> How about connecting the two spare outputs, the input, RTC_CLK, GND and 5V to a header for use as an SPI port.
>
>
> Any particular bits of the data bus / port 0x0C or 0xC0 you'd recommend?
> Looking at SC126, the first SD card /CS uses D2, the second SD card /CS uses D3, and I2C uses D0 for SCL
> I can use D7 for the available input (74*125 output).
> But that will actually conflict if the card is used with SC126, although the RTC bits will conflict too...

D7 is always good for SPI in because you can rotate it into the result directly.

SC126 folks can always disable that bit of the flock or run it behind
a bus extender (although that does mean it won't work with ROMWBW)

Alan

[Sergey Kiselev]

Another, hopefully final iteration.

Changes:

- Use D7 for the GPIO input instead of D6 (easier to shift data for serial comms)

- Change JP2 jumper connection and type (3 position/1-2 closed by default). Soldering it to 2-3 position will disable all reads from RTC port (both RTC/D0 and GPIO/D7). It can be used to disable RTC in case an RTC already exists in the system (e.g. SC126)

- Rotate J4 / GPIO header, so it is facing the right side of the board, and a right angle connector can be used there.

[Sergey Kiselev]

Flock V2 is tested and working.

GitHub repo: https://github.com/skiselev/flock-v2

Changes from V1.0:

• Update form factor from RC2014* compatible to to RCBus
• Add an option to use CR2032 battery instead of a super capacitor for the RTC
• Use right angle connector for the floppy interface

• Use ATF16V8B SPLD for address decode

• Add JP1 jumper for selecting RTC I/O address. Either 0xC0 or 0x0C can be used
• Add JP2 jumper for disabling the RTC.
• Add an option to support 300 Kbps transfer speed
• Add a header for GPIO signals

[Amardeep Chana]

Hello Sergey,

Very nice design.  I notice in your picture you're using the ST AIC37C65 part.  A few years ago (when I last looked) there was some trouble using those, perhaps on the Zeta 2?  It was recommended to get the WD part instead.  I had no luck finding a data sheet for the ST but have a few of those laying around.  So currently is it working as expected?

Thanks,

Amardeep

[Sergey Kiselev]

Hi  Amardeep,

Yes, I am using the ST AIC37C65 part. It works just as well as the Western Digital part. At least I haven't found any problems with that so far, and none were reported.

I did see a few reports - some posts here or in RC2014 talking about defective WD37C65 ICs.

BTW, Zeta SBC V2 uses PDIP part, I am not sure ST ever made a PDIP packaged 37C65.

Thanks,
Sergey

[Tadeusz Pycio]

As I recall, there were only problems with the AIC37C65 chip in the REH-CPU280 board, in my Flock v1.0 I use it without any problems.

[Sergey Kiselev]

On Tuesday, October 24, 2023 at 10:16:11 AM UTC-7 Tadeusz Pycio wrote:

As I recall, there were only problems with the AIC37C65 chip in the REH-CPU280 board, in my Flock v1.0 I use it without any problems.

Yes, there is a discussion about that here: https://www.retrobrewcomputers.org/forum/index.php?t=msg&th=93&goto=1759&

From a quick look, it appears that the issue is related specifically to the design of this board, and for whatever reason it only works with the SMC FDC37C65C chip.

 

[Amardeep Chana]

Thanks for the details, everyone.  I wasn't sure if the ones I'd purchased were wasted but it sounds like it was an issue limited to certain boards.  I do have them in both package types, PLCC44 as well as DIP40.