1. Home
  2. Field-Programmable Gate Arrays
  3. A first FPGA project

A first FPGA project

I have been trying to find the time to start a project with an FPGA for a while and I think I've finally found one. I've messed around with my Digilent FPGA development board but I have never created a full featured standalone application.

I want to take a modern FDC I/O controller and connect it to my Altair with an 8080 processor. I understand the S-100 connections and the operation/connections of the FDC controller. The thing I need advice on is the FPGA in the middle.

I have not completed my research, but I don't think the 8080 is fast enough to keep up with a 1.4MB disk. This is one reason I would need the FPGA, to buffer one sector of data and then handle transmission to the FDC IC.

Another reason I will need an intermediate device (the FDC is 8 bit) is because I want the controller to be compatible with all MITS software. To do this I will need to emulate the simple MITS hard sector disk controller. Understanding the controller is not a problem for me. We have 77 tracks of 32 sectors of 136 bytes (or 138, can't remember off hand). I want to use the disk drive's 80x36x512 and just insert nulls to fill up the unused parts of the sectors. This way the disks can be read/written with a PC. I currently have the Altair booting CP/M off of a 3.5" disk connected to a vintage tarbell board, but its 70k formatted capacity isn't exactly standard (controller thinks its a SS SD 5.25"). ; )

I imagine the best way to handle this is to have an FPGA like the XC3S100E with some VHDL and a micro core??? I want the FPGA to be TQFP at the most for easy at home soldering.

I imagine the micro core would handle initializing and error checking of floppy disk operations. The FPGA or possibly the FPGA and micro would emulate the "fake" disk I/O status bits.

What would the suggested core be for a project like this? If I have a

100,000 gate FPGA running with a 50MHz oscillator, how fast should an average risc core run?

I'm trying to figure out what kind of performance I could get out of an FPGA. After describing the project I'm wondering if it would be better to use a hardware micro and a CPLD???

Any tips or pointers to get me start would be appreciated. : )

Thanks, Grant

Reply to
Grant Stockly
Loading thread data ...

IMHO an FPGA is overkill and a micro+CPLD would be perfectly adequate. You're basically implementing a sector buffer and bus protocol conversion

- given the access times involved you'd easily be able to implement the bulk of the smarts in software on a modern micro.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

Get your application working on that. You can't even buy the parts to build a one-off board for the price of the digilent board with the chips already installed.

You might want to think about using a flash memory card instead of a physical disk... a bit more reliable and even easier to source today.

If you are only handling a sector, you may be able to use a state- machine like architecture rather than a processor core. All you really have to do is grab the data from one sector quickly, and then let the 8080 read it out more slowly. Or maybe you can build a DMA state machine and dump it into memory? I'm almost suprised the controller doesn't have the sector buffer built in, but then I guess that would have been a non-trivial amount of memory in that day and age.

Keep in mind that you can let the disk spin between sectors - you don't have to pull them off consecutively. If you figure out the inter sector time that you can actaully read consecutively, you can devise a sector interleaving format to minimize the waiting.

I would assume controllers of that vintage would be state machines and not microprogrammed machines... but then I could be wrong.

Generally things like this are easier to accomplish with a microcontroller, quite likely not needing an FPGA or CPLD at all - the challenge is communication with the host. If you need to present a register interface or something dependent on the host's timing, there having and FPGA to bridge the busses could be good. But the possibility exists that a really fast micro could even talk the 8080 bus transactions in software!

But it should all be implementable in a state machine, too.

A small one if you want a little FPGA. Clock speed is not going to be an issue, since you can do the timing critical stuff (host bus interface) with state machine logic rather than processor cycles.

Reply to
cs_posting

Agreed.

I've actually implemented a read-only (state machine) emulation of the WDC-1793 in an FPGA which sources data from a serial flash device. It interfaces to a TRS-80 implemented within the same FPGA. So state-machine is definitely an option.

IIUC the WDC 1793 did actually have a (purpose-built?) microprocessor.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

Cool! Have you made that publicly available?

It had a state machine.

Eric

Reply to
Eric Smith

It will soon be. There's not a lot to it...

Hmmm, I'm sure I've seen _some_ disk controller datasheet that mentions an internal processor... wonder where that was... ?

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

The NEC uPD7261 Winchester disk controller contained an 8048-based processor core, IIRC.

The Motorola MC68HC98 and MC68HC99, intended as embedded SCSI controllers for disk drives, contained the 68HC11 core.

There were probably other HDC controller chips that contained a general-purpose processor core, but I'm not aware of any FDC chips that did.

It's not a disk controller, but the National Semiconductor NS455 TMP (terminal management processor) contained an 8048 core.

Eric

Reply to
Eric Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.