Using C64 Core on MiniMig boards.

[TheDaddy]

>>standars ITX ones, but they are expensive as hell  

I know, I have built a few pcs using those cases.

>>Did you make that white nice box in plastic ? If so, great work. Looks very nice.

Thank you. The second batch arrives tomorrow. 50 cases, 30 have already been booked and paid for. So if anyone needs one let me know.

>>It is just a shame that the market for these boards are limited to the retro-people. So not much money to earn here. Although, they do earn quite some respect in the community, and this is priceless, right ? ))

Well, as the designer of the Minimig case I can tell you that you are absolutely right. :-)

[dirkv]

n.t.

[jkonstan]

mikej wrote:
Peter's C64 core has already been ported and runs on my standard Spartan3e board (we have been chatting for a while). I haven't released the port on fpgaarcade as I'm waiting to include a highly accurate SID port - and it needs the DDR RAM controller which is not quite finished yet.

Mike,

Are you writing your own DDR controller or are you using the Xilinx DDR controller from the Xilinx Core generator/MIG ? I have used the Xilinx DDR controller from Core generator/MIG, and it seems to work ok on the Xilinx Spartan3e evaluation board.

I would like to try out FPGA64 on my Xilinx Spartan3e evaluation board. Please let me know when you can release/post the project & source code.

 :-)

[RobertB]

TheDaddy wrote:

Are you talking about the C-One? Do we know how many have been sold?

Over a hundred.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore/Amiga Network
http://www.sccaners.org/

[mikej]

I'm using my own DDR controller, I was not happy with the Xilinx one - and there are complications with me re-releasing the code for it.

You can run in internal block RAM to play with it, download the code from Peter's website, change the UCF and it just worked.

Mail me at the fpgaarcade address and I can send you the wrapper files for the internal RAM version if you need.

/Mike

[denli]

Palm wrote:
we should be able to get alot of cores running on it [minimig] before switching to a new mobo probably. If the Replay and the MiniMig users keep fairly good sharing between the mobos and if cores can be shared for these two boards without too much hazzle

How about developing a HAL (Hardware Abstraction Layer) in the cores?
That way it would be very easy to identify what parts need converting and what parts are generic in the cores.

The generic part would then be fully interchangeable regardless if it was running on Replay, C-One or the Minimig.

Updates of the generic part of the core would then also be fully interchangable between different revisions?

Would a HAL take to much time to implement or would it make the life of the VHDL-coders better?

A HAL could mean some restrictions so all developers would have to come to terms what it should contain and work.

[Palm]

Sounds like a nice idea to me. I personally am not involved in any development, but I like your idea. Generic cores with HALs on each mobo to use the core in its fpga. Sounds ok.

Espen

[mikej]

I quite like the idea of a Hardware Abstraction Layer, for, um, hardware

I try and do this already to an extent. The game cores have a pixel clock input and pins like "button_a" etc. A top level wrapper file maps this to the FPGA IO pins and sorts out any interfacing and board/clock issues.

However, as often as not, IO interfaces require core changes to make them work, for example the DRAM controller on my board is separate from the main design. You could easily write an SRAM controller which did the same sort of thing for a different board, but that requires a good understanding of what exactly it does and then you have to verify it. Sometimes it's much easier to make the changes in the core, which breaks the whole idea.

/Mike

[boing4000]

Some little update...
Im on it and with some help from "Dirk" it could work soon. Right now the FPGA64 core only print its register dump on a total blank screen, but it indicate some working action.

There may be some timing problem in the way of sram access (sram chips get a bit warm), but I have a good faith that the FPGA64 core will work fine on Minimig V1.1 board.
But just the core, Im not able to reprogram the PIC to be a C1541 floppy or something. The 3 available spare i/o jumper connector could be a real IEC bus to connect a real C1541 floppy drive.

I'll keep you up to date :-)

[boing4000]

Additional update:

FPGA64 on minimig V1.1 board: IT WORKS!!
pictures will be uploaded soon.

[alexh]

As I said, doing the initial port is the easy and fun bit. Getting it to be usable is the hard and boring bit.

[dirkv]

You´re right. But someone must do the first step.
Without a minimig board its not really easy.

[Palm]

Boing4000 and Dirk: Good :-)

Now, throw out those screenshots for us to admire. Hehe.

Is it really necaessary to create IEC conenctor ? Wy not just D64 support from SDIO card ?


Espen

[boing4000]

To be fair I MUST say Dirk did 99% of the work and I tested the core on the a minimig board. Additional fixup made it possible!

[alexh]

Palm wrote:
Why not just D64 support from SDIO card ?

Cos it's a load of extra work that's why!

And it's not simple interface logic & wiring work (like porting the core) it's lots of reading about the different image formats, disk drive interfaces, reverse engineering the current FPGA-PIC interface, remembering how to write PIC programs etc. etc.

While you get a big pointer in the right direction cos most cores already done something similar, trying to come up with something that will fit in just makes your head spin.

Once you've got stuff on the screen, interest goes away fast. Plus the FPGA Synthesis & Mapping is not a quick process by any means. Waiting becomes a regular part of your debug, especially as you start uploading PIC firmware via serial.

If there is enough interest and people start posting their source codes (as they are required to) and a dialogue between developers opens then maybe things will accelerate fast. I dunno if you've been reading but there is a distinct lack of technical discussions about FPGA programming and MiniMig here on Amiga.org I just put it down to everyone here being "users" and no-one being interested.

All that said, nothing gets your interest in a project going again faster than competition and collaboration.

[Palm]

So, what if we approach the situation in the other end. You mention that you quickly loose interest in a project as soon as you get over the first hurdle (get things visible on the screen for instance). And I know what you mean. So, if most "users" out here cannot contribute in a technical way of bringing the development progress fast forwarding, how about if we give out bounties instead ? That is a way to encourage people to continue developing. I for sure would like to contribute for a c64 core and features around it such as running on minimig and have d64 support on the SD card.

So, what do you say guys. Anyone else who aggrees ? This way we, the community, can contribute from both sides.

a) Developers and ppl with FPGA knowledge can contribute in the techie way
b) "Users" with money they can spare can contribute to the bounty.


It is a win-win situation.



Espen