View Single Post
Old 07 November 2006, 16:28   #26
Registered User
Join Date: Sep 2005
Location: melbourne
Age: 49
Posts: 510
Originally Posted by alexh
Bit of a waste of a PIC when you have an FPGA but hey.
it's to keep the circuit simple, no need to upgrade the FPGA to a bigger, faster (more expensive) one - use the current design and have the PIC do the 'dumb' loading and shifting work. A PIC should be much cheaper and easier to add than upgrading the FPGA.

Originally Posted by alexh
Even if they open-sourced it... the amount of horse power required to decode the IPF file in the FPGA might prove to be prohibitive.
nope, the software on the PC is used to decode the IPF file (if IPF support can be added - maybe that's an advanced step - just get basic (ADF/DMS) MFM disk support happening with a flashcard first, then look at IPF support as it will need an extra table for the floppy errors).

Originally Posted by alexh
The exisitng IPF DLL could be used with any software. What do you think the current Floppy server uses?
Ahh, I forgot the IPF decoding with the PC software was already implemented.

To have IPF support on the floppy emulator would need some extra development for the PIC and the FPGA.

From Toni's comments how WinUAE handles IPFs :

it would seem "ADFs/IPF/whatever are converted to raw data + a separate buffer for possible timing data (IPFs only)".

So IPF support would mean extra programming for both the PIC and the FPGA to be able to read the errors from a second file/table, as well as how to act with the errors.

Originally Posted by alexh
Even if you could create a program that converts IPF to MFM data how large would that file be?
A standard DD disk is 901120 bytes in size, so only 1MB SRAM required to store the entire decoded MFM image (ADF/DMS images) in memory on the floppy emulator.

IPF support would need an extra area of memory to hold the 'error table' and would need extra development for the FPGA to 'know' about the IPF error table, as well as how to handle it. So IPF support is definately advanced work, best to just get a flashcard floppy emulator working with ADF and DMS support first.

Originally Posted by alexh
Is it even possible to extract an IPF to a single file? Does the DLL give the same MFM data every time for the same disk commands? I thought that some copy protection relied on fluctuations.
No idea, as you said - it's closed source. But there is a similar project on the Atari ST named 'pasti' which supports copyright protected disk images on the Atari ST, and they might also offer some assistance with implementing support, once a standalone flashcard floppy emulator is available. I'm not saying the SPS guys won't help, but actually doing the development for a standalone SD/MMC floppy emulator with ADF/DMS etc. support will certainly get them interested with helping implement IPF/pasti support.

Originally Posted by alexh
Adding write support between the FPGA and the SRAM is trivial. If it were easy, the author would have added write support. There will be a "gotcha" somewhere.
The current design for the Torlus floppy emulator only has 256KB or RAM and relies on the data streaming from the USB port - that's something I forgot to mention above - the Torlus design would need to include more memory as well as some (minor) FPGA programming to have extra address lines to the FPGA can access more than 256KB (at least there are a few unused pins on the FPGA, so they can be programmed as I/O address lines for the memory).

2MB of memory should more than cover a fully MFM decoded floppy image, as well as a seperate error index table (please IPF/SPS guys - if it won't please at least let us know the maximum filesize a decoded IPF image might be).

I just realised that writable support to a floppy emulator with enough RAM on board to store an entire decoded MFM image should be extremely trivial - the Amiga and the Atari ST both do the MFM encoding themselves in software (Amiga) or hardware (Atari ST) - so with enough RAM to support a full MFM image in memory then the device should also be able to write data to the interface (as the floppy emulator should be 'transparent' to the original Amiga/Atari ST hardware - it just sees it as a normal floppy drive). The PIC can then be used to copy the memory image back to the flashcard.

What do you think?
gizmomelb is offline  
Page generated in 0.04034 seconds with 10 queries