FPGA Replay Board

[Belial6]

While I could see a PCI slot on a future FPGAArcade, I would be shocked to see a Zorro slot.  Remember, FPGAArcade is not an Amiga board.  It is a Retro system board.  Zorro would only have a use for those of us using it for Amiga.

[Belial6]

While you can never have enough memory, we also need to keep in mind that machine specs are always a tradeoff.  Getting a working product out now is better than having the promise of a product in the future.

This seems to be one of the problems facing Natami.  Changing specs keeps it from ever making to to production.  I will happily take 128M memory on the FPGAArcade, and if that turns out to be too little in a few years, I will happily pay to buy a new FPGAArcade with more memory at that time.

This way I can play today, AND play tomorrow.  As opposed to hoping that some day I will get to play with the perfect board.

[Belial6]

@mikej

Please don't let feature creep derail your project.  You also don't want a thousand different models when it comes to warranty/add-ons/tech support.

[Belial6]

But what will you do when applications are produced that require more? You're screwed.

Nope.  Not screwed.  When applications are produced that require more, we buy an FPGAArcade 2.  I can't imagine that bloat is going to be so fast that we will be running out of 128M in the next year or two.

No matter how much power Mike puts on the board, it will always have the potential to need more.  By allowing feature creep to prevent a proper roll out, the only way that adding more memory would prevent someone from running out is by having the board never completed in the first place.

[Belial6]

That is good to hear.  I really am looking forward to being able to buy one, and I am doing my best to remain patient.  And that is really hard!

[Belial6]

On the one hand, you have to keep in mind that Amiga 68k isn't the only machine that the FPGAArcade can be.

On the other hand, the question should really be, what task would need 128M, where 512M wouldn't be too little.

[Belial6]

Sure, that is why there is so much now.  At some point you have to say, this is enough for this model.  It would be great if we could have 128 petabyte, but 32 on the basic board and 128 with the daughter card is fine.  Delaying the boards to squeeze in a little more that still won't be "enough" would have been a mistake.

[Belial6]

32, 64, 128.  Pretty much anything over 8 is fine and increasing it wouldn't be worth any delay in production.

You can be sure that if the boards make Mike a profit, and people find that they need more memory than what is currently offered, there will be an FPGAArcade 2.

[Belial6]

The best way to handle the configuration is to implement a standard serial port on the floppy controller processor module that is already implemented in the FPGA.  Connect these lines to a serial port on the Amiga side, and you now have a simple communication system between the low level floppy controller and Workbench.  From there it should be trivial to write a bit of code that lets you copy files from the Amiga side over the serial line to write it to the SD card.  The Amiga should see the floppy controller as a floppy drive from one direction, but should also see the floppy controller as a remote computer connected over the serial port not even realizing that they are the same processor.

While writing the floppy controller code would likely be limited to a small subset of programmers, the Amiga side of things could be handled by a much wider range of developers.  As a bonus, the floppy controller could have a second serial port exposed to header pins so that an adapter could be made that allowed external control via simple DIY projects.

As for bundling extra information, the best way to handle that is to adopt the RP9 file format from Amiga Forever.  This would not only give you your image files, help files, manuals and whatnot, it would also allow you to store you Amiga configuration file in with the rest, all in one file.

As a seperate task, if the disk controller serial connection described above were implemented, the disk's startup file could be set to auto initiate a download of the various files from the serial port to a ramdisk.  This means that all of your supporting files would be available to you on Workbench from the same RP9 file.