Torlus wrote:
There are many drawbacks to a standalone solution, one of it being the processing power as you mentioned, but there is also the problem of the final price.
Currently, the board would need only a small FPGA and a few extra chips, keeping the price low. Making a stand-alone solution would bring the need of having a probably larger FPGA and/or a microcontroller, some SRAM, a LCD display for image selection, CF/SD socket, boxing, etc.
Some very good points, but the extension of your project I am hoping to work on is adding some form of removable memory storage (USB, CF, SD, whatever), two push buttons (one 'next' disk image and one for 'previous' disk image) and maybe a LED segment display to display which disk image is currently selected (0-9 (10 disk images in total) - how many games etc. are more than 10 disks? but if need, you could support hexadecimal (16 disks in total)).
The way I see the device working is software on the PC (or MAC) converts the ADF, DMS, .ST, .MSA disk image to decoded MFM data, then that MFM decoded file is renamed to fit a 'slot' of 10 spaces (ie: is named 0disk, 1disk, 2disk etc. or adisk, bdisk, cdisk if supporting up to 16 disk images) and that file is then copied on to the removable memory card connected to the PC (or MAC).
when the decoded disk image is copied to the memory card, the card is removed and inserted into the virtual floppy disk emulator and the Amiga/Atari ST powered on.
The floppy disk emulator by default looks for 0disk and loads it (if found), if 0disk isn't found, then it looks for 1disk, 2disk etc. until a disk image is found - if it cannot find a disk image then it returns the 'no disk inserted' signal to the floppy controller (and if you have a hard drive, then the computer boots from that as normal).
When a disk image has been loaded and the user presses the 'next' or 'previous' buttons - then the 'disk eject' signal is sent to the floppy controller, a small timed loop waits for however long the Amiga/Atari ST needs to register a disk has been ejected, the next or previous disk image on the storage card is selected/loaded into SRAM and the LED segment display is changed so the number/id of the selected disk is displayed; then the 'disk change/disk inserted' signal is sent to the floppy controller and the computer thinks that the disk has been changed and then tries to load it etc.
I do not think this is a lot of extra work for an FPGA chip to do, as the disk images have already been decoded to MFM data by the computer software. I'm fairly certain a PIC could be used to select the disk images from the removable memory card, select next/previous etc. and copy the disk image across to the FPGA or to memory.
Any comments are more than welcome.
Torlus wrote:
The USB connection also brings the possibility to configure the FPGA through it, meaning that for a one-time purchase, you could benefit from every software and "firmware" upgrades to support new features and platforms, so we want to keep it.
The FTDI drivers are available for Windows CE, meaning that a version of the software for PDAs could be written, so instead of having a PC/Mac next to your old computer, you could use a PDA instead (which solves room issues)
Possibly keeping the USB connection on my suggested device above would be useful, for the reasons you point out (or if possible have the PIC recognise a 'flash' file for the FPGA and if it finds it on the removable memory, then it flashes the FPGA.. but no idea if a PIC would have enough CPU to do that.. probably not.)
