Frequencies / Protocol of FDD port at the 36 pin connector or 26 pin connector

[RobertM]

You guys have been most helpful here and it's greatly appreciated.

I am wondering if there is some documentation that can tell me what signals to expect at the FDD plug / socket on the mother board of a CPC6128.

I am wondering about frequencies first so that I can decide if I can 'bit bang' it with a micro-controller or use some supporting oscillator with a micro or go straight to FPGA or CPLD.


Any pointers ?

Thanks heaps guys.

[TFM]

It's a standard Shugart connector, so you can directly connect any drive. However use MFM mode, not HD mode (the latter would require to double up the frequency of the FDC).


Look at the wiki itself to find all needed docs for FDC and the Connector. 

[OCT]

I am wondering if there is some documentation that can tell me what signals to expect at the FDD plug / socket on the mother board of a CPC6128.

I am wondering about frequencies first so that I can decide if I can 'bit bang' it with a micro-controller or use some supporting oscillator with a micro or go straight to FPGA or CPLD.


Any pointers ?

One word: HxC 

A few more words/names: Shugart, Lesea & Zaks (of Programming the Z80 fame) http://bitsavers.trailing-edge.com/pdf/shugart/_appNotes/Lesea_Floppy_May78.pdf (N.B. from a time when 5.25" was called the mini floppy, as opposed to 8")

[RobertM]

OK, After much frustration reading so much about FDD's I just thought - at the end of all this I will need some sort of LCD display so that the FDD emulation is independent of the software running in the CPC.

So I am thinking of a PLAN 'B'.

I see a ROM DIS signal on the expansion connector and that provides an opportunity to load different code at boot. Well I hope it can be used this way

Here is what I am thinking ...

Compact flash cards can be read / written to by windows using FAT32 file system.

The FAT32 file system includes a boot sector.

Compact Flash Cards are almost a complete *standard* IDE interface.

Why don't I just make a circuit board with a CPLD to make changes easy and have and IDE interface that a Compact Flash Card can plug into. It could include a boot sector and get the ball rolling from there so that I have some RSX/TSR extensions (or whatever Amstrad call them) to BASIC's disk operating system to change Directory etc to accomodate the much lager size of modern mass storage???

One problem I see straight away is that SMD CF connectors are 1/40 inch (0.635mm) and I don't know if I can do that with home made boards - also I just make single sided boards here. The CPLD will probably be 0.5mm for a larger chip or 0.8mm for a smaller chip.

I have ordered several different CF to 40 Pin IDE adapters and some CF cards and some PC type CF card readers.

Wish me luck lol.

[pelrun]

What are you actually trying to accomplish? Because it sounds like you're reinventing the wheel.


The HxC (or a cheap Gotek flashed with the HxC firmware) devices do a spectacular job of emulating FDD, and TotO's X-MASS board provides a well-supported IDE interface. They're readily available and lots of us have them already.

[RobertM]

Neither of these solutions will help be to be able to 'easily' transport data back and forth to the PC.

As far as I know the X-MASS storage card won't work by itself - you need a ROM expansion with the supporting code and on top of that - who has a PC with an IDE port - they're all SATA now. I would probably have already bought the X-MASS if I could only work out what I have to buy and if that will work or if I have to do other things as well. The website has product and price and absolutely no other useful information.

The HxC has a clumsy independent  interface on a LCD screen as it's only emulated on the CPC and uses some file format that is not native to either device. There are a gazillion versions and I don't have the slightest clue which one works with the CPC.

A Compact Flash can be written to by a PC with a simple card reader using a native FAT32 file system that includes a Boot Sector. I can use the Boot Sector to load boot code into the CPC so that it supports FAT32. All I need to add are some CPC BASIC extensions like |CD or |CWD and use most of the original disk code with extensions for FAT32.

Compact Flash cards are huge compared to the memory (RAM/ROM) space of the CPC, I could have a complete copy of the boot ROM that is edited for FAT32 load into the CPC at boot time. ... because the original code has to boot mostly before I can add the needed RSX / TSR or whatever it is called on the Amstard.

Apart from this - if I am using a CPLD (like a small FPGA) then I can re-code it whenever I want to add things like a Serial Port or a Wi-Fi link or GPIO or a bidirectional parallel port or whatever I want.

And also - the ones you mentioned are expensive in my currency. I have CPLDs lying around on my desk and everything else except the Compact Flash card and 0.1" pin adapter (ordered).  I also have plenty of SRAM / Large'ish 4Mb FLASH chips - Wi-Fi cards - USB to Serial bridges.

I need to be able to *quickly* shift data / code back and forth between the CPC6128 and a PC (Probably my laptop - right beside the CPC) because I want to write Assembly and the CPC environment has no Assembler or other tools like a sprite editor or tile map editor.

[Fessor]

You should take a look at Albireo - USB/SD/Serial interface for CPC

[Munchausen]

Neither of these solutions will help be to be able to 'easily' transport data back and forth to the PC.

As far as I know the X-MASS storage card won't work by itself - you need a ROM expansion with the supporting code and on top of that - who has a PC with an IDE port - they're all SATA now. I would probably have already bought the X-MASS if I could only work out what I have to buy and if that will work or if I have to do other things as well. The website has product and price and absolutely no other useful information.

The HxC has a clumsy independent  interface on a LCD screen as it's only emulated on the CPC and uses some file format that is not native to either device. There are a gazillion versions and I don't have the slightest clue which one works with the CPC.

A Compact Flash can be written to by a PC with a simple card reader using a native FAT32 file system that includes a Boot Sector. I can use the Boot Sector to load boot code into the CPC so that it supports FAT32. All I need to add are some CPC BASIC extensions like |CD or |CWD and use most of the original disk code with extensions for FAT32.

Compact Flash cards are huge compared to the memory (RAM/ROM) space of the CPC, I could have a complete copy of the boot ROM that is edited for FAT32 load into the CPC at boot time. ... because the original code has to boot mostly before I can add the needed RSX / TSR or whatever it is called on the Amstard.

Apart from this - if I am using a CPLD (like a small FPGA) then I can re-code it whenever I want to add things like a Serial Port or a Wi-Fi link or GPIO or a bidirectional parallel port or whatever I want.

And also - the ones you mentioned are expensive in my currency. I have CPLDs lying around on my desk and everything else except the Compact Flash card and 0.1" pin adapter (ordered).  I also have plenty of SRAM / Large'ish 4Mb FLASH chips - Wi-Fi cards - USB to Serial bridges.

I need to be able to *quickly* shift data / code back and forth between the CPC6128 and a PC (Probably my laptop - right beside the CPC) because I want to write Assembly and the CPC environment has no Assembler or other tools like a sprite editor or tile map editor.

I'm afraid I agree that you are reinventing the wheel. Essentially you are replacing the boot code and some ROM code, which is equivalent to having an X-MEM. Next, I don't understand your complaint about the X-MASS using IDE and FAT, when you are proposing the same thing? The X-MASS works with some compact flash cards, and can probably be made to work with more, perhaps this would be a better place to invest time (talk to @TotO). The new ACME-DOS ROM supports FAT on the X-MASS, as well as changing directory, running programs etc from a modified AMSDOS. Finally, there are loads of assemblers on the CPC itself (most recently orgams), though I think sprite editing is more difficult.

Also, if you just want to quickly test code, why not get a minibooster? You can use it to transfer files to the CPC (with bluetooth or USB), then reboot and run the program.

Pulkomandy's Albireo may be even closer to what you need, I think it can actually reset the CPC for you.

[arnoldemu]

@RobertM: You will spend more time making this hardware than programming the CPC.

If you want to make the hardware then really what you need is a board on the CPC which has ROM on it which the CPC boots into which listens.

The hardware connects to the expansion port on the CPC. The expansion board has USB on it and a microcontroller. CPC sees it as an i/o port. This would be simpler, taking the CPC's bus and writing direct is probably not a good thing to do, so avoid that.

Software on cpc is really simple. It reads a port to detect if there is any data yet. When there is it reads another to get that byte and then writes it into ram. The microcontroller does all the work of the USB. To the PC it looks like a USB memory stick. On the CPC, it recognises a files written and writes it direct into the CPCs ram.

Almost the fastest way to do it. It's one directional PC->CPC.

In this way you could fill the entire 64kb main ram.

But, when you want to give it to somebody else, then you need to write the loader because they don't have your hardware.

[PulkoMandy]

There are also much simpler solutions:

http://pulkomandy.tk/drop/cpcsd.z80

It is slower, but it does not need replacing any ROM or whatever. And the code is not very complete (it only knows how to read sectors from the SD card so far).

[TFM]

Everybody can do it complex, only the genius keeps it simple. 

[RobertM]

There are also much simpler solutions:

http://pulkomandy.tk/drop/cpcsd.z80

It is slower, but it does not need replacing any ROM or whatever. And the code is not very complete (it only knows how to read sectors from the SD card so far).

I like this - I like it a lot!

Simple!

One thing that bothers me tough is the need to load code from the floppy every time you want to use the SD or after every Reset.

I had a quick look at your code, I could see a CRC generator but the rest seems to be there.

Now that you have the low level you can load a bootloader and add the FAT(32 perhaps) support.

Just use the FAT's boot sector to put in the Z80 code for a boot loader then all your development can happen on a PC - you only want the simplest things happening from code on the actual CPC.

Even some of the code in the file can be put into the boot loader.

I would be happy to make this hardware here and help you develop the code for FAT support as I have to do that for my project anyway.

[RobertM]

I'm afraid I agree that you are reinventing the wheel. Essentially you are replacing the boot code and some ROM code, which is equivalent to having an X-MEM. Next, I don't understand your complaint about the X-MASS using IDE and FAT, when you are proposing the same thing? The X-MASS works with some compact flash cards, and can probably be made to work with more, perhaps this would be a better place to invest time (talk to @TotO). The new ACME-DOS ROM supports FAT on the X-MASS, as well as changing directory, running programs etc from a modified AMSDOS. Finally, there are loads of assemblers on the CPC itself (most recently orgams), though I think sprite editing is more difficult.

Also, if you just want to quickly test code, why not get a minibooster? You can use it to transfer files to the CPC (with bluetooth or USB), then reboot and run the program.

Pulkomandy's Albireo may be even closer to what you need, I think it can actually reset the CPC for you.

Ok off the bat - I don't have any means whatsoever of getting any code into the CPC apart from the keyboard so most of the hardware solutions offered are actually useless to me.

Second - I want power on compatibility. Turn the machine on (or reset it) and it instantly has compatibility with the hardware.

As for the X-MEM / XMASS the real problem is I don't have a clue. They may be great but the website tells me nothing about how it works and I am not going to spend that much money on something that might end up in the bin because it doesn't work because because because I don't have a clue. I can't even work out what I would need to buy.

I didn't know the X-MASS was FAT32 - that's not written anywhere. As for being IDE - YES what I am doing is actually XTA or 8 bit ATA and you call it IDE because of the connector and pinout and that's *close enough* but I am using a storage medium that is NOT End Of Life. Modern card readers will read CF Cards for some time yet - the humble old 40 pin 0.1" IDE (AKA PATA) is all but buried.

The CF card has the the ease of transporting code as it can plug into a reader and the reader into a USB port on a PC.

The CF card also has the disadvantage of the 0.025" pin spacing which is going to test my ability with making PCBs.

The other current issue I have is that (apparently) a CF card's ATA mode is CMOS voltages so it can't work with my 3.3 Volt LVTTL *5 Volt tolerant* CPLDs. Actual *5 Volt* CPLDs are long gone.

I have to work out if it's true that the voltages to the CF Card actually have to be CMOS - there is a lot of confusion today between CMOS *technology* and CMOS *Voltages* - things like a 74HCT06 or the *HCT* series uses CMOS *technology* but maintains TTL Voltages and that is confusing a lot of EEs.

If it's *IS* an issue then I will investigate using 3.3 Volts for the CF card and that means I would have to send everything through the CPLD so I can use it as a level translator as well.

Anyway - I have to go find the spec for CF ATA mode.

[arnoldemu]

T13 has the specifications for ATA, they may have the compact flash one too, although that may be a protocol rather than a specific ATA specification.

[arnoldemu]

Second - I want power on compatibility. Turn the machine on (or reset it) and it instantly has compatibility with the hardware.

Easiest is to need the software in an expansion ROM (ROMDIS active if rom 0 is selected and A15 is set to 1) or a lower-rom replacement (ROMDIS permanently active, A15=A14=0). soft968 describes the structure for expansion rom.

It may be possible to take over the cpc's bus (BUSRQ) and force the data into ram. I'm not sure if it's been done before either, this would have to be a pure hardware solution.

[gerald]

The CF card has the the ease of transporting code as it can plug into a reader and the reader into a USB port on a PC.

The CF card also has the disadvantage of the 0.025" pin spacing which is going to test my ability with making PCBs.

The other current issue I have is that (apparently) a CF card's ATA mode is CMOS voltages so it can't work with my 3.3 Volt LVTTL *5 Volt tolerant* CPLDs. Actual *5 Volt* CPLDs are long gone.

I have to work out if it's true that the voltages to the CF Card actually have to be CMOS - there is a lot of confusion today between CMOS *technology* and CMOS *Voltages* - things like a 74HCT06 or the *HCT* series uses CMOS *technology* but maintains TTL Voltages and that is confusing a lot of EEs.

If it's *IS* an issue then I will investigate using 3.3 Volts for the CF card and that means I would have to send everything through the CPLD so I can use it as a level translator as well.

Anyway - I have to go find the spec for CF ATA mode.

If you only intend to use CF on your interface, just use the memory mapped mode, limited to the 8 1st byte (ie register file). This will give you direct 8 bit compatibility (in IDE mode you have to configure it). Regarding operating voltage, a CF must work at 3.3V and 5V, whatever the used mode is.
Some link to specification :
1.4 : ftp://ftp.wintel.fi/manuals/General/CompactFlash.pdf
3.0 : http://rumkin.com/reference/aquapad/media/cfspc3_0.pdf

[RobertM]

There are also much simpler solutions:
http://pulkomandy.tk/drop/cpcsd.z80

It is slower, but it does not need replacing any ROM or whatever. And the code is not very complete (it only knows how to read sectors from the SD card so far).

OK I just soldered pin headers to the edge connectors on my CPC6128 and while I was there I added a +5V pin to the printer port.

I should have everything else here now to make your SD interface so I will give it a go.

I am still going to do the CF/IDE thing on the expansion bus but I like your project so much that I just have to give it a go.

[PulkoMandy]

It may be possible to take over the cpc's bus (BUSRQ) and force the data into ram. I'm not sure if it's been done before either, this would have to be a pure hardware solution.

This is not that easy, because the gate array will still access the VRAM (it ignores BUSRQ). So your device would have to time its memory accesses like the the z80.

[RobertM]

There are also much simpler solutions:

http://pulkomandy.tk/drop/cpcsd.z80

It is slower, but it does not need replacing any ROM or whatever. And the code is not very complete (it only knows how to read sectors from the SD card so far).

Hi PulkoMandy,

I downloaded the zip file when you posted and had a quick read.

Today I found that I have a SD card module that did the 5v0 to 3v3 voltage translation so after I put pin headers onto the edge connectors it was really easy to connect with some push on connectors.

I haven't done anything except connect the SD reader to the printer port. I am just preparing at this stage.

The first issue that rose is that there are SD and SDHC formats. I found that Windows wants to use FAT (which I assume to be FAT16) to format 2GB or less SD cards and Windows uses FAT32 to format 4GB and above SDHC cards.

So the first question I have is - your code - is it written for SD or SDHC?

I did read the SD/SDHC spec a long time ago but I have never written code to interface either.

The other is not so much of a question but a suggestion that you may want to comment on or offer advice - all appreciated.

One of the sites that I am a member of has an open challenge - to view a retro web page on a retro computer so I have been considering a TCP/IP stack for the CPC. I stumbled on a shortcut that may be an answer to other problems as well.

There is a WiFi / SD card called the FLASH AIR made by Toshiba. It's a SD(HC) card that has an inbuilt micro controller running WiFi.

I think this would be a great solution to fix the isolation the old CPC feels in the modern world.

Any thoughts???

I have the Full specs for the FLASH Air here - the full specs for developers or coders that gives details right down to the micro controller code (from memory) I can post this if you want ... it's rare info.

Anyway - I have achieved all I wanted to achieve today and my beer is tasting really nice lol so I will chat tomorrow.

Also - thanks heaps for your help so far - you a legend!!!

Also - for the others that posted links to info - thanks heaps - especially for the CF info - it's hard to find unless you want to pay $100 to the CF organization.

[RobertM]

I just ordered an eye-fi card as they will (apparently) connect to an existing wifi network as opposed to the Flash Air that sets itself up as a wifi access point. First option is much easier to manage from the PC end.

[PulkoMandy]

Hi,
As I mentionned I tested SD cards only with sector read/write code. I didn't plug a filesystem onto it.
The code supports both SD and SDHC cards. It detects which type is plugged and adjust the commands sent.


The only difference at the low level is that SD cards use byte addressing, while SDHC uses sector addressing.


You can then format the cards with any filesystem you want.

[RobertM]

Well, here is where I am at so far. I'm feeling good about this and everyone's help has been excellent, thanks all.

It was even a long way to get here. The CPC was dead at the start.

[RobertM]

There are also much simpler solutions:

http://pulkomandy.tk/drop/cpcsd.z80

It is slower, but it does not need replacing any ROM or whatever. And the code is not very complete (it only knows how to read sectors from the SD card so far).

Which assembler did you use for this? All the onesI downloaded for Windows GUI aren't compatible.

I hope it was a GUI assembler and not DOS lol

[PulkoMandy]

vasm portable and retargetable assembler

(you need the "z80 oldstyle" version).

Executables for windows available somewhere here: AJ/freem's Neo-Geo Development Page

A GUI assembler? Sorry but no, I'm not going to click click click for half an hour to convert my z80 sources into a DSK file. I need automated and scriptable tools.

[RobertM]

vasm portable and retargetable assembler

(you need the "z80 oldstyle" version).

Executables for windows available somewhere here: AJ/freem's Neo-Geo Development Page

A GUI assembler? Sorry but no, I'm not going to click click click for half an hour to convert my z80 sources into a DSK file. I need automated and scriptable tools.

Yep that's definitely "old style" lol - now i have to remember how to write .bat files has been a while since I did that lol

Thanks for the links.