So here's a little evening fun project that I have been working on for a while now. It's just your average 65C02 based computer system with the addition of a Floppy Disk Controller on the board and with a PCB which makes it possible to mount it directly on the floppy drive. For my system I selected to go with a 3.5" drive but the system should be able to work with older 5.25" drives but not with really old 8" drives.

After the initial board debugging process I have managed to write a small test program that currently is capable of starting the disk motor and selecting the drive, stepping the head to an arbitrary track, reading a track, writing a track and formating a track. Reading and writing of sectors is still to come.

The intention is to have DOS/65 running on the system and to make a simple graphics/game/keyboard card, making it an autonomous computer. I could even make a few games for it then and develop them on the system itself.

The processor is running at 2 MHZ, a limitation set by the UART and FDC, which is perfectly fine for me. A 256 byte I/O segment is created from $F800-$F8FF with with an IO select signal going out on the expansion connector for the available IO addresses. The CPU board itself uses $F800-F827 for its internal IO devices. The FLASH and SRAM occupy the higher and lower 32Kbyte respectively. On the expansion connector there is a "disable" signal which expansion cards can use to inject their own functions into memory space.

That's all for now I guess. I will take some pictures and link to in a day or two.
/P

Edit: Changed the title

Have anyone here ever worked with WD2793 ? I'm experiencing problems during formating, where all of the sudden the controller no longer generates DRQ pulses and no interrupt arrives. I've tried bending my program in all imaginable directions to no avail, so for the moment I'm stuck. I have tested both the drive and the diskette in a PC and they both work fine there, I've also tested to replace the controller chip with a brand new one with the exact same result.

Reading and writing from/to a disk formated in a PC also seem to work although I haven't done so much testing since the format is different from what i have selected.

My interrupt strategy is to use the FDC interrupt to terminate the FDC commands, pop the three interrupt stack entries, clear the interrupt disable flag and then rts.

All suggestions are welcome.......

I don't see anything in the data sheet that says the WD2793 is intended to control a 3-1/2 inch drive. The data sheet seems to imply that only 8 inch and 5-1/4 inch drives are supported, in single or double sided mode.

BTW, posting a schematic may help.

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

Hi PontusO
Not quite sure what you mean here, and it might not be relevant, but just in case: if you want to use RTS to return from an interrupt routine then you have to know that the address on the stack for RTS is one less than the address you return to, but the address on the stack for RTI is the exact address to return to.
Just in case!
Cheers
Ed
(demonstration in visual6502)

You haven't mentioned DMA, so is it correct to assume you're using a tightly-coded software loop instead? Ie, does the 65c02 somehow poll the FDC's DRQ (Data Request) line in order to time the bytes written to (or read from) the FDC's Data Register?

I have some familiarity with the polled approach, having used it in an SBC with FDC I built years ago. I used different chips -- a Z80 CPU and a 2797A FDC -- but probably many of the issues will be similar to what you're facing.

Timing is very tight if you're attempting to use "double density" 1.44 mb formats on the 3.5" disk. It's a case where the 65xx cpu's seldom-used SO (Set Overflow) input may be of invaluable aid! Perhaps you already thought of this: Hardware gates the DRQ signal onto the SO input pin on the cpu. Then your software could use a BVC instruction as a wait loop until each DRQ pulse arrives. This is quicker than routing DRQ through a conventional input port; there's no "LDA Port_Whatever" instruction required, so the polling is comparatively rapid.

Thanks, BDD. I agree -- a schematic would be helpful. BTW I was successful using a 2797A with 1.44meg 3.5" floppies. But the 2793 may not be up to the job, as you noted.

-- Jeff

Is the 2797 FDC somehow similar to the WD1771 FDC? I built two board with the 1771 (similar to Commodore's VC1581) and have code on my web page:

http://www.6502.org/users/andre/csa/shug/index.html
http://www.6502.org/users/andre/csa/drvio/index.html

May be of help. On 2MHz it works with 1.44M floppies even without the use of the SO signal.

André

I'm thinking a tightly-coded IRQ handler should be able to produce the required throughput. My only thoughts with use SO is only the 65(c)02 has it. There's no equivalent on the 65C816.

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

Since my last post I dragged out the doc on my old project, and discovered that the FDC chip I used is virtually identical to what PontusO has -- in fact they're covered by the same data sheet. (Minor difference: his 2793 features an internal clock divide input on pin 25, whereas I opted for a 2797, which features a Side Select output on pin 25.)

BDD, your comment is all too correct. The data sheet fails to even mention 3.5 inch floppies -- yet they are within the capabilities of the chip, and without exceeding the rated clock input. I recall some extreme frustration getting it all sorted out: 1 MHz vs 2 MHz clock, single density vs double, 8 inch vs 5 inch disks, and inferring from all that how to manage a 3.5 inch. I sure hope an updated data sheet has been issued since then!

As for polling the DRQ line, pulses arrive every 16 µs on average for a 1.44M disk. PontusO mentioned he is using a 2 MHz 65C02, so 16 µs would correspond to 32 cpu cycles. I expect (and fachat's remark confirms) that'd be sufficient for a software loop to wait for each DRQ and move a byte to/from memory in response.

D'oh! I admit being slightly disappointed. The 6502 SO pin seems like such an intriguing "solution looking for a problem"!

-- Jeff

O.T. ps: the reason timing was a challenge with my project was that I was using a 4 MHz Z80. Heck, it seemed like a good idea at the time! The Z80 INI and OUTI instructions seemed impressive (transferring between I/O and an auto-incremented memory address), and I relied on them to turbo-charge the READ-DATA and WRITE-DATA loops. The code looked great, and the overall loop times were satisfactory. But a lot happens during an INI or OUTI instruction (16 clocks of activity; they are CISC, not RISC), and unfortunately the actual I/O access occurs toward the end of it all. Consequently the latency from DRQ to the FDC I/O access was marginally excessive, and occasionally a byte would get dropped. So I abandoned polling and resorted to an unholy kludge: I routed DRQ indirectly to the system EPROM's ms address line, letting it select between two almost identical program images -- one Ready, one not.

Looks like I promised you all a picture so here you go.



The AC/DC block is a 60W Meanwell converter which has basically the same form factor as a floppy drive.

And here's the schematic as well: http://www.ivattochtorrt.se/images/pontus/schematic-revb.pdf. The LS123 is incorrectly connected in this schematic but I've corrected it on the PCB.

@BigDumbDinosaur
Yeah, there's no mentioning of 3.5" drives in the datasheet, nor in the datasheet from TI either. I have assumed that this is just due to that 3.5" drives were not really available at the time the datasheet was written and it hasn't been updated since then. Is it not so that 3.5" drives were deliberately designed to operate in place of 5.25" drives with only minor parameter changes ??

@fachat
I will certainly have look at you code to see if i have missed something. Thank you for sharing.

@Dr Jefyll
No DMA so your assumptions are correct. I have narrowed the loop down to max 29 cycles. I didn't think about the SO flag for this application but it sounds like a good thing to try out.

@BigEd
What I am doing is using the interrupt signal to terminate the execution of a tight loop. So when the interrupt comes and the service routing is called is that I pop the interrupt entries from the stack and discard them. Then when rts is executed it looks like I am returning from the function with the loop.

PB6 and PB7 are being pulled low during system initialization, configuring the system for double density and 5.25" and compatible drives (3.5"). I did make a mistake in connecting the FDCINT signal to CB1 of the VIA since it requires resetting both the FDC interrupt source as well as the VIA interrupt. I also didn't think to much about the fact that I will be using the VIA timers and interrupts which in the end will require a lot of overhead disabling VIA interrupts. I will modify the board to have the FDC interrupt hooked alone to NMI and the VIA and UART will share the IRQ line.

Thanks guys
/P

IIRC I had to use a tightly controlled loop to transfer the 512 byte for a block. I was even tempted to actually use the SO pin, but I managed to do without. No way any IRQ handling would fit in there. Even if the CPU is 10 or 20MHz you'd just be out of IRQ before you had to get back in.

Or did you mean an IRQ handler that, in the IRQ routine, transfers the whole block without further IRQ?

André

No picture visible and the link points to nowhere.

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

Right. I was thinking when the FDC interrupted the MPU, the IRQ handler would grab the entire block before going back to the main program. If one were coding a multitasking OS, one would not want the kernel busy-waiting on a peripheral if at all possible.

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

Very nice, PontusO! Btw I had no trouble viewing the photo (or the schematic).

Were you able to resolve the difficulty you mentioned in your April 19 post?

Certainly it's undesirable to hang up the cpu, especially with regard to multitasking as you mentioned, BDD. But, lacking DMA, there seems to be no alternative -- or has there been some option overlooked? The challenge is to read (or write) 512 bytes spaced at 16 µs intervals. Presently the cpu does it in software, fully occupying about 8 ms.

-- Jeff

Picture's fine for me, both the original and your quoted one!

I was just thinking... My code is polling the wd2793 status register with a very tight loop.



Could it be that my reading the status register is cancelling out the interrupt before it is generated externally. The random occurance of the problem could support that problem, indicating some sort of race condition in the controller itself. Hmmm, doesn't seem likely but i'll try hooking the drq signal to PA7 and poll the io port instead of the status register.