6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 17, 2024 10:24 am

All times are UTC




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Dec 21, 2013 3:54 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Hi,

in my introduction (http://forum.6502.org/viewtopic.php?f=1&t=1935&start=180) I mentioned the IDE Interface I have built into my 6502 Computer and as it seams the subject of HDD interface in general is of larger interest. So I decided to elaborate a bit about my solutions.

First why an IDE Interface? At the time I was building my IDE Interfaces you could get a small IDE Harddisc for free. Mostly because many people were upgrading their computers and what was left was a small IDE Harddisc. I had already a SCSI Card for my Apple II and even built a SCSI interface for my homebrew 6502 computer. But I had only one SCSI Disk left. No backup! So I decided to build my own IDE interface. There are quite few examples in the internet and one is even commercially available (CFFA 3000). Today of course it is very hard to get a IDE Harddrive, but there's something even better than a IDE Harddrive that works perfectly with IDE Interfaces and thats a CF-Card (Compact Flash). The interfaces are all simple polling interfaces.


So let me start the presentation with the simplest IDE Interface I have built.

Attachment:
File comment: IDE Interface Schematic for a normal Apple II
AppleIIe-IDE-Interface.pdf [388.04 KiB]
Downloaded 569 times


This is an Apple II compatible interface that includes the decoding logic required in a Apple Slot and contains the ROM (an EEPROM Xicor X2864) and a scratchpad RAM (HM6116) with the appropriate logic for the Slot-ROM and the C8-ROM space. The logic for the ROM/RAM selection is burned into a GAL16V8 (AIIEIDE2) and is not required when interfacing with a generic 6502 system.

The interface itself only requires the GAL16V8 named AIIEIDE1.
Code:
GAL16V8
AIIEIDE1

/DEV    A0     A1     A2     A3     PHI0  /DDEV   nc     nc    GND
 RW    /OEW   /OER    ENW    ENR   /CS1   /CS0   /IOW   /IOR   VCC

;
; Generate the signals for the IO Registers which are
; C0x8 .. C0xF  Normal Access to the ATA Registers
; C0x0          Write only access to the ATA Data Register
; C0x7      Read back of the High-Byte Register
; C0x6          Read Write Access to the Alternate Status/Control Register
; C0x1          Read Write Access to the High-Byte of IDE Bus Data
;

IOR   =  DDEV   * /A3   *  A2   *  A1   * /A0   *  RW   ; C0x6
   +  DDEV   *  A3            *  RW   ; C0x8..F

IOW   =  DDEV   *  DEV   * /A3   * /A2   * /A1   * /A0   * /RW   ; C0x0
   +  DDEV   *  DEV   * /A3   *  A2   *  A1   * /A0   * /RW   ; C0x6
   +  DDEV   *  DEV   *  A3            * /RW   ; C0x8..F

CS1   =  DEV    * /A3   *  A2   *  A1   * /A0      ; C0x6

CS0   =  DEV   * /A3   * /A2   * /A1   * /A0   * /RW   ; C0x0
   +  DEV   *  A3               ; C0x8..F

ENR   =  DEV   * /A3   *  A2   *  A1   * /A0   *  RW   ; C0x6
   +  DEV   * /A3   *  A2   *  A1   *  A0   *  RW   ; C0X7
   +  DEV   *  A3            *  RW   ; C0x8..F

ENW   =  DEV   * /A3   * /A2   * /A1   *  A0   * /RW   ; C0x1

OER   =  DEV   * /A3   * /A2   * /A1   *  A0   *  RW   ; C0x1
   +  DEV   * /A3   *  A2   *  A1   *  A0   *  RW   ; C0x7

OEW   =  DDEV   * /A3   * /A2   * /A1   * /A0   * /RW   ; C0x0
   +  DDEV   * /A3   *  A2   *  A1   * /A0   * /RW   ; C0x6
   +  DDEV   * /A3   *  A2   *  A1   *  A0   *  RW   ; C0x7
   +  DDEV   *  A3            * /RW   ; C0x8..F

DESCRIPTION
/*

IOR   This is the ATA Interface IO Read Request Signal and is low only when
   IO-Registers C0x8 .. C0xF and C0x6 are read accessed
   
IOW   This is the ATA Interface IO Write Request Signal and is low when
   IO-Registers C0x8 .. C0xF and C0x6 are write accessed or when C0x0 is
   write accessed. Reading to C0x0 does not activate IOW. This is
   to avoid additional read cycles when writing to the ATA Dataregister
   this is required as the 6502 processor always reads the location
   before writing to it and some IDE Interfaces count the number of
   access rather than the number of write access when transferring a
   block of data from the Host to the Device.
   
CS0   This is the standard CS0 Select Signal of ATA Interface and is used to
   access the packet interface registers. This signal is asserted during
   write access to C0x0 and during any reference to C0x8 .. C0xF.

CS1   This is the standard CS1 Select Signal of ATA Interface and is used to
   access the alternate status or control register. This signal is
   asserted during access of addresses C0x8 .. C0xF.
   
OER   Output Enable of the Read High-Data Register. This is enabled when
   reading locations C0x1 and C0x7. When reading C0x7 the current value
   of the data high-byte register of the IDE interface is read back.
   When reading C0x1 the last value of high-byte read from the IDE bus
   is returned. Note that accessing C0x7 destroys the last value read
   from the IDE bus and is only used for debugging purpose.

OEW   Output Enable of the High-Byte Data Register to the ATA Device.
   This signal is asserted with every write access of the IDE bus.
   The high-byte data register must be set previously by writing the
   appropriate value to C0x1. This signal is also asserted when reading
   location C0x7 in order for the Read High-Data Register to read the
   current Write High-Data Register value for debugging purposes.

ENR   Enable Read High-Data Register Latch. Activated on each read cycle
   to the ATA Registers and when reading location C0x7 to fetch the
   previously store value of the high-byte data register.

ENW   Enable Write High-Data Register Latch. This is only asserted when
   writing to location C0x1 to set the high-byte data value which then
   is used on every write cycle to the IDE bus.

*/
END


This interface is only suited for slow 6502 based computers as the ATA Register Cycle length is equal to the High-Phase of PHI. On the other hand it only requires generic TTL ICs. Although the IDE interface is a 16-bit interface it makes use of 16-bit transfers only during the data transfer. Command and Status are sent and retrieved using 8-bits only.

Attachment:
File comment: Source Listing of IDE Driver Code
IDEDriverv30-n.txt [54.32 KiB]
Downloaded 298 times


I have attached the source listing. To understand the code you need to know the following.

The code starts with code that writes the code into the EEPROM.
The code in Slot-ROM is not position independent. Normally you should avoid that in Apple Interfaces. But it worked for me
The driver expects a FAT-16 partition but does not read/write individual files. It only tries to find PRODOS diskimages. These images must be contiguous, in the root directory and have the extension .HVD. Also they must not have a header (like .2img diskimages). So a PRODOS block can be mapped one-to-one to a 512byte block in the diskimage by just adding the offset of the file on the FAT-16 volume.

I have also built a IDE interface that works with faster 6502 (up to 6MHz). If there is interest I can post this information as well.

Peter


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 21, 2013 7:07 pm 
Offline

Joined: Sun Jul 28, 2013 12:59 am
Posts: 235
We've established that interfacing to PATA devices is fairly simple. From what I've seen it's even simple when using standard logic instead of programmable logic (four or five chips, I think it was). This gives us easy, cheap bulk storage, plus the ability to control a CD or DVD reader (and maybe writer). There are adaptors that can be used to connect a SATA device to a PATA controller, which means that we could easily control a modern hard drive (terabytes of space!) from a 6502 based system. Can we go one further, and set up a DMA channel, so the host CPU doesn't need to sit there transferring data?


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 21, 2013 8:09 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
With a SATA to PATA interface, one can even take advantage of a newer/faster Solid State Drive which are seem to be SATA.

nyef wrote:
...Can we go one further, and set up a DMA channel, so the host CPU doesn't need to sit there transferring data?

With a FPGA or CPLD even, I imagine that would be easy to do.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 21, 2013 8:21 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I also have IDE interface plans in the future, nothing specific yet, but was looking at this type of SSD:

http://us.apacer.com/products/ADMIII-44P-270D/SSD/

For myself, I don't see the need for massive storage requirements (gigabytes and terabytes) on an 8-bit system, then there's the filesystem side of things... managing it all.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 21, 2013 8:53 pm 
Offline

Joined: Sun Jul 28, 2013 12:59 am
Posts: 235
nyef wrote:
...Can we go one further, and set up a DMA channel, so the host CPU doesn't need to sit there transferring data?

ElEctric_EyE wrote:
With a FPGA or CPLD even, I imagine that would be easy to do.

I think I have an angle on doing it with standard logic. A couple of bus tranceivers to isolate the memory from the CPU during phi1, some latches to hold the upper address bits, a direction flag, possibly chip-selects, an 8-bit counter for A1-A8, and half a 74xx74 for A0. Plus some loose bits and pieces of control logic.

I'm nowhere near ready to actually flesh this out or implement it, but I expect that I'm building up a truly vicious case of second-system effect.


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 22, 2013 3:57 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8494
Location: Midwestern USA
cbscpe wrote:
The driver expects a FAT-16 partition but does not read/write individual files.

Why would a driver's operation be contingent on a particular filesystem being present? A driver's job is to run the hardware, not access and/or manipulate a filesystem. In combining one function with the other, the driver's generality has been decreased.

In my POC unit, the SCSI driver is limited to issuing commands to the target device (disk, CD/DVD or tape) and processing the ensuing data flow (an oversimplification, to be sure). The driver sees the data flow only as a stream of bytes that have a source and a destination, e.g., a disk and a buffer. It's the job of higher level functions to decided what to do with the data. That's the way virtually all modern computer systems operate. Drivers drive, and nothing more.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 22, 2013 3:58 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8494
Location: Midwestern USA
nyef wrote:
nyef wrote:
...Can we go one further, and set up a DMA channel, so the host CPU doesn't need to sit there transferring data?

ElEctric_EyE wrote:
With a FPGA or CPLD even, I imagine that would be easy to do.

I think I have an angle on doing it with standard logic. A couple of bus tranceivers to isolate the memory from the CPU during phi1, some latches to hold the upper address bits, a direction flag, possibly chip-selects, an 8-bit counter for A1-A8, and half a 74xx74 for A0. Plus some loose bits and pieces of control logic.

I'm nowhere near ready to actually flesh this out or implement it, but I expect that I'm building up a truly vicious case of second-system effect.

I've given some thought to pressing a CPLD into service as a DMA controller. In principle, it isn't difficult to quantify. However, the devil is in the details... Understanding state machines, as well as bus management will be essential.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Mon Dec 23, 2013 8:25 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 22, 2013 8:46 am 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
BigDumbDinosaur wrote:
cbscpe wrote:
The driver expects a FAT-16 partition but does not read/write individual files.

Why would a driver's operation be contingent on a particular filesystem being present? A driver's job is to run the hardware, not access and/or manipulate a filesystem. In combining one function with the other, the driver's generality has been decreased.


I understand your concern. However, in my case I not only wanted a simple HDD interface but also create a "link" between my real Apple II system and the Apple II Emulator "Virtual ][" on my Mac. I already previously built a SCSI controller and connected my 20Mbyte SCSI HDD to the Apple II. This driver was just reading and writing blocks. But I had no way to exchange data with the emulator. Also running a backup to DISK-II Floppys took a lot of time. So I came up with the idea to use a FAT-16 formatted Disk and just exchange the Disk-Images from "Virtual ][" and the Apple II. The File-System within the disk images is fully handled by ProDOS. So the disk images are somewhat "virtual Disks". And running a backup is now a breeze.

If you look at the driver code itself you will find, that the FAT-16 stuff is used only once when accessing the device the first time. Once the code in the ROM found the "virtual Disks" it behaves like a real driver starting at "DCHK2". Here it translates the File-System Volume ID form the OS to the appropriate "virtual Disk" (UNIT2IDY), converts the logical block to physical blocks (BLK2LBA) and then executes the desired action (DREAD or DWRITE). Beside these routines you only need to initialize the IDE Harddrive (7 instructions at label INIT8) and the IDEWAIT sub-routine. So all you need for a generic driver is there.


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 23, 2013 7:51 am 
Offline

Joined: Mon Aug 05, 2013 10:43 pm
Posts: 258
Location: Southampton, UK
nyef wrote:
rom the CPU during phi1, some latches to hold the upper address bits, a direction flag, possibly chip-selects, an 8-bit counter for A1-A8, and half a 74xx74 for A0. Plus some loose bits and pieces of control logic.

I'm nowhere near ready to actually flesh this out or implement it, but I expect that I'm building up a truly vicious case of second-system effect.


I am possibly misunderstanding here, but it is possible to implement a simple IDE interface using nothing but a couple of gates, assuming you can find a 8 bit compatible CF card or old HDD. My 6809 computer implements exactly this, and there are other examples with Spectrums etc.

http://www.worldofspectrum.org/zxplus3e ... tml#simple

If you want 16bit access (I've not rigged that myself) you'd need a couple of latches and a few more gates, presumably.

DMA, of course, presents its own set of challenges. But for the size of files you'd ever want to move around on a 8 bit micro, that seems like pointless overkill. Though an interesting challenge at the same time, which is what matters in some ways...

_________________
8 bit fun and games: https://www.aslak.net/


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 23, 2013 8:30 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8494
Location: Midwestern USA
Aslak3 wrote:
DMA, of course, presents its own set of challenges. But for the size of files you'd ever want to move around on a 8 bit micro, that seems like pointless overkill. Though an interesting challenge at the same time, which is what matters in some ways...

I'd have to disagree on the overkill part. Even your average IDE drive is able to read/write faster than a 20 MHz 65xx MPU can physically move the data. My SCSI setup could theoretically transfer 10MB/second with the bus operating in synchronous mode. No way the 65C816 can stay with that data transfer rate. A DMA controller could, however.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Mon Dec 23, 2013 9:03 pm 
Offline

Joined: Sun Jul 28, 2013 12:59 am
Posts: 235
BigDumbDinosaur wrote:
Aslak3 wrote:
DMA, of course, presents its own set of challenges. But for the size of files you'd ever want to move around on a 8 bit micro, that seems like pointless overkill. Though an interesting challenge at the same time, which is what matters in some ways...

I'd have to disagree on the overkill part. Even your average IDE drive is able to read/write faster than a 20 MHz 65xx MPU can physically move the data. My SCSI setup could theoretically transfer 10MB/second with the bus operating in synchronous mode. No way the 65C816 can stay with that data transfer rate. A DMA controller could, however.

A DMA setup should be able to (with appropriately clever design) move a byte per clock cycle, using phi-1 time. A 65816 using MVP moves a byte every seven cycles, assuming that I'm reading the datasheet correctly. Plus your CPU does the MVP, while the DMA controller runs in the background. Plus your DMA controller can presumably be configured to start as soon as the data is available, while having the CPU do the transfer requires either an interrupt or a polling loop. If your memory system allows for 16-bit native transfers then the comparison simply gets worse, DMA in two bytes per clock cycle.

Also, file size isn't necessarily all that important, sometimes it's simply the ability to do other things while the transfer is going on. A data acquisition task or cheap video are two things that come to mind here.


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 24, 2013 8:39 am 
Offline

Joined: Mon Aug 05, 2013 10:43 pm
Posts: 258
Location: Southampton, UK
All I was saying is if you want a SIMPLE 8 bit IDE interface it can be added to your micro only with *wires*. I personally think this is useful information in the context of the title of this thread.

_________________
8 bit fun and games: https://www.aslak.net/


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 25, 2013 9:14 am 
Offline

Joined: Fri Nov 26, 2010 6:03 pm
Posts: 46
Location: NSW, Australia
Aslak3 wrote:
All I was saying is if you want a SIMPLE 8 bit IDE interface it can be added to your micro only with *wires*. I personally think this is useful information in the context of the title of this thread.
14 wires, to be exact-- and friend and I did this for a SYM-1 project mentioned in http://forum.6502.org/viewtopic.php?p=12599#p12599


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 25, 2013 11:37 am 
Offline

Joined: Mon Jun 24, 2013 8:18 am
Posts: 83
Location: Italy
Hello everyone
ofcourse a simple IDE interface can work fine in PIO mode (transfer block of 512 bytes at time), but is possible to use a DMA like 82C37. Even if this dma chip is for 80xx system it can easyly interfaced with 65XX (one need only to not gain access to memory till dma finish).
The problem is the 16bit-wide ide bus: interfacing the ram with 8bit bus with 16bit ide bus require sophisticated hardware (82C37 will handle a the same time an "even" and an "odd" address of buffer ram, while cpu will access the even and odd address as consecutive address).
Somebody have good ideas?

_________________
http://65xx.unet.bz/ - Hardware & Software 65XX family


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 25, 2013 1:37 pm 
Offline

Joined: Sun Jul 28, 2013 12:59 am
Posts: 235
One approach to the 8/16 bit memory bus thing would be to have two 8-bit wide memories in the system and select which to use for the CPU by having A0 control a MUX to select which half of the memory bus to use and which RAM chip to enable... And let the DMA controller use both halves and both RAMs. Looks like 16-bit memory to the DMA controller, looks like 8-bit memory to the CPU, and doubles your memory package count, plus additional logic.

The other approach could be to do 8-bit DMA transfers and have some logic at the drive interface to break the 16-bit data up into 8-bit bytes.

The approach that I'm currently thinking of taking (once I get this far) is to build a "DMA controller" out of whatever bits of logic I can find that suit, and run it during phi1 so that it's invisible to the CPU, and it would use a latch to break up the 16-bit data into 8-bit bytes for the RAM.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: