Amiga bit rate?

[alexfreed]

I was trying to use the front end software to convert an ADF file (Workbench, so there is no copy protection) into an MFM file and use a tool derived from Cyclone20 to write to an actual floppy. Didn't work. I have noticed that using proper bit rate (2 us bit cells) the track overwrites itself.
I looked at the source and found the DEFAULT_AMIGA_BITRATE defined as 253360 which is clearly more that the 25000 I had expected.

I guess I have to redefine it for my purposes, but why this value? Is it to accommodate some copy protection scheme using non-standard longer tracks?

Thanks.

[Jeff]

I was trying to use the front end software to convert an ADF file (Workbench, so there is no copy protection) into an MFM file and use a tool derived from Cyclone20 to write to an actual floppy. Didn't work. I have noticed that using proper bit rate (2 us bit cells) the track overwrites itself.
I looked at the source and found the DEFAULT_AMIGA_BITRATE defined as 253360 which is clearly more that the 25000 I had expected.

I guess I have to redefine it for my purposes, but why this value? Is it to accommodate some copy protection scheme using non-standard longer tracks?

Thanks.

This an interesting behaviour of the amiga FDC: 253360 bit/second is something that i have mesured with a oscilloscope from a PAL amiga.
i suspect that this bitrate is a little different with an NTSC Amiga.
Note that the amiga bitrate is always over 250000 (unprotected ipf tracks report values like 251120b/s, long track report 277340 )

if you need to write back the adf file to a floppy at 250000b/s, yes you can change DEFAULT_AMIGA_BITRATE to 250000.

[Jeff]

Final word in the winuae src:

disk.c

/* writable track length with normal 2us bitcell/300RPM motor, 12667 PAL, 12797 NTSC */
#define FLOPPY_WRITE_LEN (currprefs.floppy_write_length > 256 ? currprefs.floppy_write_length / 2 : (currprefs.ntscmode ? (12798 / 2) : (12668 / 2)))

12798 / 2 = 6399
6399 * 8* 5 = 255960b/s in ntsc


12668 / 2 = 6334
6334* 8* 5 = 253360 /s in pal

[alexfreed]

>if you need to write back the adf file to a floppy at 250000b/s, yes you can change DEFAULT_AMIGA_BITRATE to 250000

Thanks for replying.

I'm not sure at what rate I need to write. Whatever makes it boot. I'm using an old and possibly buggy Cyclone20 code with minor modifications. I think it is on the very edge of hitting a USB transfer rate bottleneck. Just writing all bits 4 us apart works OK if I use 41.6*98 = 4.076us timing but results in a lot of overruns with 4.6*94.

Trying to write back an Amiga track I got CRC errors when using shorter pulses and no sector 0 - write over itself - using longer ones.
Damn, I just want to boot my new toy!

I even assembled the SD version of HxC. Now waiting for PICKIT to arrive so that I can program it.

In the long run I want to use the ARM version for both dumping and serving disk images.

[alexfreed]

12798 / 2 = 6399
6399 * 8* 5 = 255960b/s in ntsc


12668 / 2 = 6334
6334* 8* 5 = 253360 /s in pal

Right. If I had a fully functional device it would not matter but with the limited bandwidth I have to try finding the sweet spot. I guess with a gap smaller than 750 bytes it should still work fine, at least for reading.

On top of it my floppy drive registers a speed just a tad higher than the 300 which doesn't help much. No visible pot to slow it down either.

If it still doesn't work at any setting I'll need to rewrite the code to send bits rather than intervals and convert on the ARM board.

[Jeff]

12798 / 2 = 6399
6399 * 8* 5 = 255960b/s in ntsc


12668 / 2 = 6334
6334* 8* 5 = 253360 /s in pal

Right. If I had a fully functional device it would not matter but with the limited bandwidth I have to try finding the sweet spot. I guess with a gap smaller than 750 bytes it should still work fine, at least for reading.

On top of it my floppy drive registers a speed just a tad higher than the 300 which doesn't help much. No visible pot to slow it down either.

If it still doesn't work at any setting I'll need to rewrite the code to send bits rather than intervals and convert on the ARM board.

A 11 sectors amiga track fits into a 6250bytes track (250000b/s), and the amiga fdc is tolerant at ~+/-15% regarding the bitrate, so there are no problem to reduce the final gap.

[alexfreed]

Just did some measurements. Indeed the factory Amiga floppy shows about 12768 raw bytes and a couple home-written ones are in the same range.
By contrast the PC floppies are very close to the 12500 +/- 0.5%.

So I shortened the track but alas still get errors on *most* tracks. I guess it is something other than that. Interestingly reading works perfectly - I had no trouble converting a real floppy to ADF and running on an emulator. Too bad I need the opposite.

Next stop - rewrite the code to send MFM bytes and convert to pulses on the ARM. Or figuring out WTF goes wrong... Unless the PICKIT arrives first

In any case the SAM7 appears to be a great platform to port your HxC. It seems to work just fine directly driving the floppy without any buffers. Every pin can be switched from input to output so the same connector can be used to read real floppies and emulate them later. No sync USART as in the PIC18, but easy enough to use the timer.

[Jeff]

Just did some measurements. Indeed the factory Amiga floppy shows about 12768 raw bytes and a couple home-written ones are in the same range.
By contrast the PC floppies are very close to the 12500 +/- 0.5%.

yes exactly.

So I shortened the track but alas still get errors on *most* tracks. I guess it is something other than that. Interestingly reading works perfectly - I had no trouble converting a real floppy to ADF and running on an emulator. Too bad I need the opposite.

which pulse width are you using to write the floppy ?
every sectors are bad ?

In any case the SAM7 appears to be a great platform to port your HxC. It seems to work just fine directly driving the floppy without any buffers. Every pin can be switched from input to output so the same connector can be used to read real floppies and emulate them later. No sync USART as in the PIC18, but easy enough to use the timer.

Finally i am not so sure.

Regarding buffer, there are needed since output you must be able to draw at least 24mA from the floppy buffer bus (only 4 ios can draw 16mA on the arm7, and others cannot exceed 8mA). Some old 5"1/4 drive use 150Ohms pull-up (33mA !).

In the input side,schmitt trigger buffers are recommend since there may have some important ringing on the floppy bus.

There are something like the USART in the SAM7 (the SCC), but i don't know if the bitrate can be changed on the fly. if yes, i will have a look, if no this chip is finally not so interesting for the emulation.
Doing this is with a timer sounds to me as a bad idea, because finally i will be more or less in the PIC18F situation with some additionnals problems (cpu cache memory can add some difficulty to control timings ) , with something more expensive.

I think that doing the floppy signal generation with a small FPGA or a CPLD is far more reliable and effective than using uC to do this task, especially if you want something able to handle protected floppy disks.

[alexfreed]

which pulse width are you using to write the floppy ?
every sectors are bad ?

Went to very slow 41.6*98 -> 12232. Same result: some sector are read back (consistently) with a bad checksum but some whole tracks are OK, but only a few. Mostly 1 to 4 sectors are bad.

I may try writing a simple pattern over the whole track and trying to analyze what exactly get written wrong. The graph (Mr. Floppy) shows a few readings way outside the bell curve.

Finally i am not so sure.

Regarding buffer, there are needed since output you must be able to draw at least 24mA from the floppy buffer bus (only 4 ios can draw 16mA on the arm7, and others cannot exceed 8mA). Some old 5"1/4 drive use 150Ohms pull-up (33mA !).

In the input side,schmitt trigger buffers are recommend since there may have some important ringing on the floppy bus.

If I were designing a device at my day job (and designing electronic stuff actually is my day job) I would agree. For a hobby thing that only needs to operate at room temperature, etc. a direct connection seems like an option. At least it appears to work fine with the 4 floppy drives I have used.
Only one at a time, so never 2 pull-ups in parallel.

There are something like the USART in the SAM7 (the SCC), but i don't know if the bitrate can be changed on the fly. if yes, i will have a look, if no this chip is finally not so interesting for the emulation.

I looked briefly a while ago and it appeared not to be trivial to use.
On the other hand the timer based pulse generation is already written.

There is also a project that uses an AVR at 16 MHz to read/write high density floppies doing encoding/decoding on the fly! Adding pre-compensation too for a good measure. Using a timer for pulse generation. So I don't think that is a big drawback.

Doing this is with a timer sounds to me as a bad idea, because finally i will be more or less in the PIC18F situation with some additionnals problems (cpu cache memory can add some difficulty to control timings ) , with something more expensive.

AFAIK the ARM7 does not use an instruction cache. ARM9 does.

I think that doing the floppy signal generation with a small FPGA or a CPLD is far more reliable and effective than using uC to do this task, especially if you want something able to handle protected floppy disks.

Now you are talking my language I love FPGAs. See my
http://alexfreed.com/FPGApple

If I really needed to capture data from a protected floppy at a high resolution I would have used the Spartan 3 board with the USB 2.0 high speed module. With 1 MB rather fast RAM on board I can capture a whole track with say 10 ns resolution into SRAM and not even need the fast USB... That's a thought. Maybe I should use that board to write to a real floppy.
I was just hoping to use an existing device with minimum mods. I have no need to capture protected data but emulating floppies is cool. Apparently your PIC18 design is quite adequate. No reason to reinvent the wheel.
I just was under the impression that you were working on an ARM version.

[alexfreed]

I think I know the problem or at least where to look: I tried writing a fixed pattern: 3 pulses 4 us apart and one 8 us later over the whole track. On readback it is *almost* right, but a lot of noise - pulses all over the range from 2 to 12 and beyond. Tried the opposite - 3 pulses 8 us and one 4 us and got a much cleaner result. So it's quite likely that sending the stream in the form of delays takes so much bandwidth that there are timer overruns.

Still no PICKIT in the mailbox. Maybe I'll try to rewrite the code to send MFM bytes and convert to pulses on the ARM side. And buffer the whole track too.

[Jeff]

I think I know the problem or at least where to look: I tried writing a fixed pattern: 3 pulses 4 us apart and one 8 us later over the whole track. On readback it is *almost* right, but a lot of noise - pulses all over the range from 2 to 12 and beyond. Tried the opposite - 3 pulses 8 us and one 4 us and got a much cleaner result. So it's quite likely that sending the stream in the form of delays takes so much bandwidth that there are timer overruns.

Still no PICKIT in the mailbox. Maybe I'll try to rewrite the code to send MFM bytes and convert to pulses on the ARM side. And buffer the whole track too.

<<Using a timer for pulse generation>>maybe this is the problem finally .
This part are in C or ASM ?

Regarding the pickit, you can also use an homemade jdm interface to program the pic (with winpic):

http://img220.imageshack.us/img220/6051/jdmmod7on.gif

[shprivat]

I think I know the problem or at least where to look: I tried writing a fixed pattern: 3 pulses 4 us apart and one 8 us later over the whole track. On readback it is *almost* right, but a lot of noise - pulses all over the range from 2 to 12 and beyond. Tried the opposite - 3 pulses 8 us and one 4 us and got a much cleaner result. So it's quite likely that sending the stream in the form of delays takes so much bandwidth that there are timer overruns.

Still no PICKIT in the mailbox. Maybe I'll try to rewrite the code to send MFM bytes and convert to pulses on the ARM side. And buffer the whole track too.

<<Using a timer for pulse generation>>maybe this is the problem finally .
This part are in C or ASM ?

Regarding the pickit, you can also use an homemade jdm interface to program the pic (with winpic):

http://img220.imageshack.us/img220/6051/jdmmod7on.gif

I built this programmer and using it with great success:
http://www.instructables.com/id/JDM2-ba ... rogrammer/

Programming software: Winpic800
http://www.winpic800.com

Sven

[alexfreed]

<<Using a timer for pulse generation>>maybe this is the problem finally .

Yes, with a qualifier "while taking frequent USB interrupts".

This part are in C or ASM ?

I was using the old version of the Cyclone20 as-is, all "C".
I'm pretty sure it will work if the track is buffered. The timer should be quite accurate if no interrupts are taken. I'll see if I can make it happen.

Regarding the pickit, you can also use an homemade jdm interface to program the pic (with winpic):

http://img220.imageshack.us/img220/6051/jdmmod7on.gif

Thanks. I saw a whole lot of serial programmers on the net but decided it was worthwhile waiting for the already payed for PICKIT to arrive.

I used PICs years ago starting from 16C54 and up to 16F877. Didn't realize the good old original ICD didn't support the 18Fxxxx. Nor my Picstart Plus. The $45 toll won't hurt anyway.

[alexfreed]

OK, so I rewrote the timer IRQ handler to just set 3 times 4 us intervals and once a 6 us interval and not listen to the USB stream. The result looks almost picture perfect read back from the floppy - no more noise!

I didn't write any real data yet and it is 4 a.m. so that will have to wait
At least it seems clear what to do: send an MFM track, buffer the 13K bytes in RAM that we have plenty of and write from the buffer. Will not write tracks with fancy copy protection perhaps but good enough for my purposes.

Talking of the copy protection. Likely a lot of schemes that care about timing will count the actual number of bytes per track. We can fake that without sending each individual pulse's length.

[Jeff]

OK, so I rewrote the timer IRQ handler to just set 3 times 4 us intervals and once a 6 us interval and not listen to the USB stream. The result looks almost picture perfect read back from the floppy - no more noise!

I didn't write any real data yet and it is 4 a.m. so that will have to wait
At least it seems clear what to do: send an MFM track, buffer the 13K bytes in RAM that we have plenty of and write from the buffer. Will not write tracks with fancy copy protection perhaps but good enough for my purposes.

Talking of the copy protection. Likely a lot of schemes that care about timing will count the actual number of bytes per track. We can fake that without sending each individual pulse's length.

ok good.
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?