Amiga bit rate?

[alexfreed]

so, the pulse generator routine is in the main loop ?
Strangely, putting it in a NMI/timer style irq seems to me a better way to avoid this kind of problem.
Maybe there are not the time budget to call an irq to generate each pulse?

The pulse generator is in the IRQ. The timer has several compare registers. The first is responsible for the pulse width - not important. The second one determines the delay till the next pulse - actual data payload. The original code from Cyclone20 did all the processing of the data stream inside the IRQ service routine: mostly the delay till next pulse but also commands like stop writing, wait till an index pulse, etc.

When I first saw the problem I added code to set an unused pin when entering the routine and reset it at the exit. The scope showed that at full (DD) rate writing a track spent about 50% of the time servicing the interrupt. This told me that:
1. the routine was not the problem
2. this won't work for an HD stream

Now the IRQ routine is a lot smaller as it doesn't try to interpret the commands in the stream and can be re-coded in assembly if needed for the HD. (If anyone decides to do it.)

Here is my plan. Please comment as you did several implementation already.

All the commands will go over the command endpoint: reset the buffer, start storing data coming from the EP1 to the buffer, spin up, wait for the index, etc.
The MFM stream for one full track will be stored in a buffer. With 64K RAM there is plenty of room even for an HD track.

Once the writing starts, the IRQ happens every time a new pulse starts. At this time we should calculate the delay till the next pulse by shifting the buffered data and setting the new timer value. Very fast.

The same procedure will be used for both writing to a real floppy and emulating one.

Why do it at all if a PIC version is available? First of all I want to add Apple 2 format and I feel a lot more comfortable with a lot of RAM and MIPS to burn. Second the built-in USB is nice. Using an inexpensive SAM7S256 board ready made that has both an MMC/SD connector and USB it should be possible to combine the functionality of both HxC variations.

[Jeff]

so, the pulse generator routine is in the main loop ?
Strangely, putting it in a NMI/timer style irq seems to me a better way to avoid this kind of problem.
Maybe there are not the time budget to call an irq to generate each pulse?

The pulse generator is in the IRQ. The timer has several compare registers. The first is responsible for the pulse width - not important. The second one determines the delay till the next pulse - actual data payload. The original code from Cyclone20 did all the processing of the data stream inside the IRQ service routine: mostly the delay till next pulse but also commands like stop writing, wait till an index pulse, etc.

When I first saw the problem I added code to set an unused pin when entering the routine and reset it at the exit. The scope showed that at full (DD) rate writing a track spent about 50% of the time servicing the interrupt. This told me that:
1. the routine was not the problem
2. this won't work for an HD stream

Now the IRQ routine is a lot smaller as it doesn't try to interpret the commands in the stream and can be re-coded in assembly if needed for the HD. (If anyone decides to do it.)

Here is my plan. Please comment as you did several implementation already.

All the commands will go over the command endpoint: reset the buffer, start storing data coming from the EP1 to the buffer, spin up, wait for the index, etc.
The MFM stream for one full track will be stored in a buffer. With 64K RAM there is plenty of room even for an HD track.

Once the writing starts, the IRQ happens every time a new pulse starts. At this time we should calculate the delay till the next pulse by shifting the buffered data and setting the new timer value. Very fast.

The same procedure will be used for both writing to a real floppy and emulating one.

Why do it at all if a PIC version is available? First of all I want to add Apple 2 format and I feel a lot more comfortable with a lot of RAM and MIPS to burn. Second the built-in USB is nice. Using an inexpensive SAM7S256 board ready made that has both an MMC/SD connector and USB it should be possible to combine the functionality of both HxC variations.

i don't have the source code so it's hard to say something about this.
The interesting thing to do is maybe to get the generated asm code during the C compilation to check if you can really optimize the code in asm.

[alexfreed]

i don't have the source code so it's hard to say something about this.
The interesting thing to do is maybe to get the generated asm code during the C compilation to check if you can really optimize the code in asm.

The source I started with is in the Cyclone20 project's sourceforge archive and I'm playing with ways to store the whole track (works great) and converting to pulses inside the IRQ. Not so great. Apparently overruns do happen and efficient assembly code may help a lot. However after spending several hours trying to get the software working I got a delivery - the PICKIT! Naturally I switched to the already built HxC as the main goal was to get a floppyless Amiga off the ground. Worked like a charm! A very good design clearly optimized for low cost and home PCB manufacturing. The only complaints: lots of jumpers - price to pay for a single layer and the 74LS01 is quite scarce these days. Not available from usual suspects like DigiKey. Fortunately I had a couple of plain old 7401 chips in the "junk box". If I didn't could have used LS00 given that with a single device on the bus and no real floppies the open drain is not really a must but the pinout is different. 74LS38 also has a different one.
I should probably mention in the thread about alternative PCBs that the 74LS38 have a lot better availablility.

BTW I have measured the control current with a few standard 3.5" (single) floppy drives and it is about 3 mA. Not a problem to drive directly from SAM7S not to mention the PIC18F4620 that allows up to 25 mA.

Going back to the SAM7S - I may return to it when I have more time but right now HxC answers my immediate needs. Writing ARM assembly code is not my idea of fun I'm afraid One approach that may work is to create a small circular buffer that would be filled with time intervals my code running in the main thread while the IRQ (in "C") would do absolute minimum of work - take the next one and update the pointer.