Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Palm on January 12, 2009, 12:18:05 PM
-
Is it possible to load a C64 core onto the MiniMig board via the SD card ? If so, will the CPU be "emulated"/implemented in the core itself (making the onboard 68k cpu "disabled"/unused ?
Is the MiniMIg board capable of running more than just a Amiga core ? E.g. Atari or other which uses 68K CPU.
Just curious, since I read that C-one can run C64 cores + minimig cores (with modifications). Having both Amiga and C64 on the same board would be supercool. Maybe a bootloader to choose core ? :)
Espen
-
I do not see why this would be impossible. The C64 is much smaller than an Amiga 500.
There is plenty of ram memory.
-
The question is basically that who would like to write the FPGA code? The MiniMig Spartan 3 should be enough to run a complete C64 class computer entirely off the FPGA (leaving the MC68000 idling). Any machine that is of Amiga 500 class using a 68000 CPU should be possible to implement too (early Apple and some Atari systems for example). Verlog/VHDL-gurus out there - start the coding...;-)
-
I have thought about previously, I am pleased with my efforts, no progress has been made. The ROM's and the C64 Core should fit in the 400K gate Spartan3, but the alignment of the Minimig board and the PIC are somewhat complex.
Generally, any matching system on the Minimig to be set up. The limits are really only in the existing wiring and the space in the FPGA.
An Atari ST and C64 are (in my opinion) much simpler and "smaller" than the Amiga chipset.
Perhaps Jakub or anyone else find a solution :-)
(raw translation by google...)
-
If the MinMig board is sold in even larger quantities, maybe more ppl see the interest to release C64 Cores for it aswell. It would be supercool if the MiniMig board could be released in a new version too, with much open design so that it can be added modules to it (e.g. busboards and stuff like that) so that 3rd parties can create whatever HW they want for it (and make the drivers ofcoz). That way, the MiniMig could be a more like a "open" board which has the ability to run MiniMig core _aswell_ as much other stuff.
E.g.:
1. Have option to insert own cards that holds chips. (e.g. a 6581 SID chip, 6510 CPU) for better c64 emulation etc
2. Open design that lets ppl create insertion-boards (although todays design is pretty open :)
3. Have the possibility to choose which FPGA to use (if they can be hot-swapped and pinouts are the same) to enable the owner of the board to run larger cores...if this is really necessary..i dunno...just emptying my mind here :-)
4. Maybe over-dimension things in the design to extend the lifespand of the board so that cores etc. which is made 2 years from now which might be 10x larger than todays, can be used too without making a new board.
Is it possible to have a jumper for the pic that tells the pic which core to use ? Or even better, a OSD which does this ? E.g you can have CORE1.BIN, CORE2.BIN...COREN.BIN on the SDIO card and by switching the jumper from 1 to 2, or from 2 to 3 it will load the corresponding core. That way you can add a ince display on the front of the minimig case which says which core is being used :-)
Can HDMI port be added ?
Are there any Linux cores which can be used on the MiniMig ?
I´ll stop here ... :-)
Espen
-
Since the Minimig v1.1 core was adapted to the C-On then perhaps the easier solution would be to try and adapty the C-One C64 core to the Minimig.
One thing I like about the C64 core on the C-One is that I have my Simons BASIC cartridge working in the expansion slot and a real C1571 floppy drive hooked up. :-)
@ The Daddy: This is one board that seriously needs a professional case with room for a PC power supply, slots at the back for the ports and access to the C64/VIC20 cartridge slot and the CF card. I'm using an old PC tower at the moment with the side left off.
-
So, the question is:
Which board to go for. MiniMig or COne board. Whichever runs the most cores and has best development and is cheapest, will probably win the tug.
I for sure would like to have my two favourite machine in the same FPGA (c64+amiga500 ...or a1200 if possible in the future). I also want as much options as possible to connect all my legacy HW to it (drives, cartridges etc).
Of course, this is a wet dream, I hope for the best.
At the moment, I own a minimig. So I hope to see a clean and nice C64 core for it as soon as possible :-)
If that happens, what are the electrical possibilities to see functions added like expansion slots and IEC bus ? Does the FPGA has some pins I can pull this from if a C64 Core is made/adapted ?
Espen
-
Maybe my 3.0 version of my MiniMig could be something - 8 MB SRAM and the yaqube ARM controller directly on the board (no more PIC). Already on MiniMig 2.0 there is a new pin header that allows direct access to the pins of the FPGA that goes to the video DAC. I could add more pin headers, but I need to know on what side/bus - memory or CPU? To keep signal integrity, a header with tight spacing should be used (like the one I have for the RGB pins). How many signals from the FPGA is actually needed for these add-ons?
-
Illuwatar wrote:
The question is basically that who would like to write the FPGA code? The MiniMig Spartan 3 should be enough to run a complete C64 class computer entirely off the FPGA (leaving the MC68000 idling). Any machine that is of Amiga 500 class using a 68000 CPU should be possible to implement too (early Apple and some Atari systems for example). Verlog/VHDL-gurus out there - start the coding...;-)
Genesis/MegaDrive? Neo-geo? X68000? sun-1? SGI sparc 1000? :-)
-
Hi Darrin,
@ The Daddy: This is one board that seriously needs a professional case with room for a PC power supply, slots at the back for the ports and access to the C64/VIC20 cartridge slot and the CF card. I'm using an old PC tower at the moment with the side left off.
Are you talking about the C-One? Do we know how many have been sold? I could give it a go :-)
-
If the custom chips needed to implement these are in par with the A500 OCS or less and if you are able to reverse-engineer them, then it should be possible.
-
Mini-Mig, JTAG cable, and a good book could make for a good dev. board.
-
TheDaddy wrote:
Hi Darrin,
Are you talking about the C-One? Do we know how many have been sold? I could give it a go :-)
I've no ideas on the numbers. You'll have to ask Jens. I don't think there were many produced and as the next step will be the Clone-A then I doubt any more will be.
Chances are there's not a big enough market for you to make the effort.
-
Regarding MiniMig ITX V3.0
----------------------
* Will it still feature the MiniITX 17x17 form factor ?
* WIll the ports on the back have the same positions as on
the 2.0 board ?
* Is it possible to create addon-cards/daughterboard for 2.0 which lets the 2.0 owners have 3.0 options if they want ?
* Will there be some kind of a trade-in deal for upgraders from 2.0->3.0 ?
* Is there a roadmap for 3.0 (and 4.0 ?) or a spec-list ready ?
I believe there are many wishes for what to add to the 3.0 board. Let the duscussion flow here a bit so that as much cool stuff is added to the 3.0 mobo as possible. The more the merrier :)
Regs
Espen
-
@everyone
Please make a C64 core for the Minimig.
It would be great! Have tohe choice of loading C64 or Amiga games!
The way I see it:
A C64 core
An Atari ST core
A ZX Spectrum core
This would be absolutely awesome!
Imagine how many people you can attract to the Minimig :-)
-
I have asked Peter Wendrich(the author of the C64 core)
to port the code to the Minimig.
He told me that he doesn't have a Minimig, so he can't make a port.
I would donate him a Minimig, but I have at the moment only parts for my own Minimig.(only one blank PCB)
I hope that Illuwatar will finish his Board design so I can buy from him some blank Boards.:)
Jens
-
Hm, I think oscillator timing will be an issue.
-
Peter at Illuwatar also sells pre-soldered boards. I bought one from him a few days ago, so he is definitely shipping :-)
If someone can make a working c64 core and continue to develop it, I fure sure would be part of donating.
Anyone ?
-
There are several open-sauce FPGA cores which work (i.e. fit) on MiniMig v1.1
CPC-TREX (http://www.symbos.de/trex.htm)
FPGA-64 v0.27 (http://www.syntiac.com/fpga64.html)
A few Arcade games (http://www.fpgaarcade.com/games.htm)
MSX II (http://www.grauw.nl/blog/entry/385)
Sinclair Spectrum (http://www.zxbada.bbk.org/badaloc_fpga/index.htm)
ZX80/ZX81 (http://tech.groups.yahoo.com/group/zxgate/[/url)
These are just a few I've played with over the months. With the exception of CPC-TREX (which is written in AHDL and needed converting) all were easy to add a MiniMig I/O wrapper.
Although I never tried it there is also an Atari ST in the form of Suska (http://www.experiment-s.de/en) which should fit although may need a different xtal.
The SD Card I/O and the PIC is harder ;-)
I'll happily walk someone through the process if anyone feels like being a MiniMig HDL coder?
-
That is good news. What need now is some kind of a bootloader for which core to load. Is this possible to make using the onboard PIC ? It kinda sucks to have to swap SD card just to boot different cores :-)
It would be like the old days with the disk-boxes. But instead of disks, we have SD cards :) Imagine how small a sexy that box would look hehehe...
Espen
-
Someone set up a bounty for the following:
C64 core to the Minimig
Atari ST core to the Minimig
ZX Spectrum core to the Minimig
I am willing to donate :-)
-
Dude, me too. Right away :)
Who sets up bounties. And what should it be. I guess C64 core would be most appreciated ? What do you think ?
Espen
-
It kinda sucks to have to swap SD card just to boot different cores :-)
It is easily possible but why? What is wrong with the One SD card = one core (plus all the games). I see no problem at all? Especially as 2Gig SD cards are £3.50 each at Tesco! This is certainly a feature request to put at the bottom of the to-do pile.
What is more-likely to suck is that there is very little scope in the PIC for multi-platform support and in my experiments I had to re-program the PIC using the serial cable between cores. (But I wasn't really trying to get a single all-singing all-dancing PIC)
-
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. The Replay (fpgaarcade) dev board will run multiple cores out of the box, including my VIC-20 core (also available on C-one) and my ST core.
There is no reason Peter's core would not run on the original Minimig board. You just need to change to top level wrapper file to get the correct IOs. It would also need some work to get the tape or cartridge interface to talk to the SPI connection to the SD card.
More info is available on the SID and VIC2 chips thanks to Michael's very impressing IC die scans :
http://mail.lipsia.de/~enigma/neu/6581.html
/Mike
-
1) C64 Core (I don't mind if you have to have it on one SD Card, a 512MB SD Card should do with all the games and the core on)
2) Atari ST
3) ZX Spectrum
These would make the Minimig a superb multi console/computer station :-)
-
Allright, I can for sure live with different SD cards for different cores. If a C64 Core would be released, i am totally for that.
Is there anyeone who has tried to load a c64 core to the minimig ? Is there a way to join up for such a task ?
Maybe a some kind of a wiki for the minimig and other FPGA solutions would be nice. To collect all info in one place.
Espen
-
Would it be possible to use the core of a C64DTV if it could be extracted somehow ???
-
probably. We have been working on the code for the Atari Jaguar and un-released Atari Jaguar2 for a while.....
-
So, what is the major difference between MiniMig and your board ? I am just curious. Which one is most modular in design to be able to use most cores which are available/will be available ?
Seems to me that the "future" are FPGA boards which are generic in design being able to run all sorts of cores of old machines. Just a big question remaing:
-Which board wins the race.
-Which is the best and has the right price
-And which one gets most users.
I would love that MiniMig, FpgaArcade and other FPGA-board developers kind of teamed up somehow so that most cores either works on all boards, or that the board-developers try to make them boards compatible with eachother as much as possible so that the users gets to enjoy all the different cores around.
I do believe that for the MiniMig developers, they are interested in getting as much running on its board as possible, to pull users. And I believe FpgaArcade developers wants the same :-)
So, can someone list pros and cons for MiniMig and fpgaArcade (and other spartan3 boards ?) so that we can compare them ?
Espen
-
The FpgaArcade (now called Replay) board has the following :
Large Spartan3E device (1200). 3x minimig size
Expansion connector for real processor or other IO (like a real SID) / Ethernet. 68K daughter board already designed to test the 68K soft core. I can't remember the exact number, but it's got about 100 IO pins and another 30 odd input only pins plus some clocks and power on the expansion connector.
ARM micro controller for hardfile support + USB.
24 bit DVI(HDMI) output + analogue output.
Good quality Wolfson audio DAC.
32 MByte memory.
SVHS/Composite video (on tiny expansion board)
small form factor (17cm x 8cm) and fits in an ITX case.
External input connectors for wiring joysticks / buttons up in an arcade machine.
It has been a long time in development, as I keep adding bits to it. It was completely finished and ready to be manufactured before we decided to move from the AVR to the ARM controller. Should be done in another week. Price is unknown but will become clearer once I get the first batch made.
The reason I designed this board was so I can run the game cores I develop. I did the vic-20 core used on C-one and I have a cycle accurate ST chipset. I also debugged and maintain the T65 and T80 CPUs used in a lot of projects.
Any board is only as good as the software and firmware support - without this it doesn't do much. I'm an FPGA engineer, so I will continue to support the Amiga and other cores on this platform. Other people can continue to port them to other boards if they wish. Most of the emails I get are people having problems getting things to work on other boards, so having one "reference" board will from my point of view save me a lot of time.
What it will do is boot multiple environments from the OSD menu. An environment includes ROMs and the FPGA image. The ROM files are copied over to the memory at startup. You can then select a run-time image, either a floppy or later a hardfile image the FPGA can access while it is running.
My aim for platforms (initially) :
(working code exists for all of these on my other boards)
Amiga A500 - Minimig core + Mike memory controller
Atari ST - Mike + Wolfgang)
Vic20 - Mike
C64 - Peter + Mike SID
Spectrum
BBC B
Bally Astrocade
+few others
Pacman / Pengo
Frogger / Scramble
Defender
Asteroids
StarWars
Spaceinvaders
/Mike
-
Palm wrote:
Would it be possible to use the core of a C64DTV if it could be extracted somehow ???
It cannot be extracted. Why not? It's a modern ASIC which was synthesised from HDL and then flattened and implemented using deep submicron technology. Even if you took xray photos of the DIE you'd never work out what was going on. You can extract the information from the much older original C64 ASIC's because they were created by hand in the form of schematics using a much larger technologies making the DIE's almost human readable.
If you knew the C64DTV developers and could get a copy of the HDL source code they used then sure. (But I doubt you'd be able to get them to part with it legally)
But I feel that C64 HDL development has moved on since the C64DTV and the C64DTV was under some price constraints so they had to leave out several seldom used original C64 features.
-
I guess your´re right there Alexh. And the DTV is kinda like not really a c64. It has some extra stuff, which imo should not be there. It is too pimped up :)
But back to Mike´s post. I wonder if I might have bought the Minimig too early. To me, the Replay board seems to have much more coresupport than the minimig has.
However, parting with my newly obtained mini itx minimig is kinda sad too. I think that if the minimig community can get the Replay cores ported and running on minimig boards, it would be very nice.
Let us just hope that this FPGA thing does not end up in a war between the different developers :-)
Espen
-
Palm,
well, I'll say it before anybody else does - I would wait until you see pricing and the board is up and running and available for shipping.
We could hit some snag before then, but I hope not.
As the boards get more features porting the code between them does get more difficult. The integration with the micro controller is also a big deal - hence the last minute change to the ARM.
/Mike
-
If I am not mistaken, the new ARM board from Yaqube replaces the minimig PIC.
Or do I remember wrongly here ?
Espen
-
Yes. I have changed to the same controller to make sharing code easier.
/Mike
-
Ah, very nice. I like that. Good.
So when can we expect to see a demo of your board ? youtube maybe? running c64 core ? It would be very nice to see it.
Espen
-
Could we please stay a bit on the ground?
Jakub's ARM board is not even released or finished and we are planing ahead of the not even known hardware.
Sure the Minimig board is able to run different core like FPGA64 or Atari-ST. The current PIC (or ARM board) should be able to handle different core files and the extension of disk files (i.e. .adf, .d64, .st etc.). Its also possible to rename all files in .adf as long as the sector size is still 512 byte per block. That would not require different PIC version or bit changes in its firmware, since there is no much space left.
For any new Minimig hardware releases or board revisions, the designer should be open for other core and programming ways. Right now the Minimig is an open Amiga replacement with some more options.
Don't plan ahead too much, all step by step :-)
-
I agree.
Let's exhaust the Minimig first.
C64, Spectrum and Atari ST Cores, let's make sure the Minimig as it is gets fully supported and fully used.
Then, all together, we can provide an updated version which can offer more.
Just my two cents :-)
-
"C64, Spectrum and Atari ST Cores, let's make sure the Minimig as it is gets fully supported and fully used.
Then, all together, we can provide an updated version which can offer more."
I actually agree, that's why I have been using the Xilinx Spartan3e "standard" board for ages. However, I really want a board with the features I want - so I designed one. That is the one I will support from now on, it just takes too much time to do multiple ports. I feel the current minimig board is too feature limited.
To answer some other questions I have been getting, the Replay board will only be available fully assembled and tested - it's not easy to build by hand even with professional tools.
/Mike
-
Quick n dirty ports are very easy. You can usually have something on the screen in 20 minutes. For Spectrum you can create the port very quickly because it was written very well. Add the MiniMig I/O wrapper for CLOCKS, RAM/ROM, VGA, Joystick and keyboard and combine the ROM and an SNA file to replace KICK.ROM. A few pokes and an RUSR and you're playing the game. Not particularly user friendly as it is only one game per SDCARD ;-)
To get it to work better you need a replacement OS or HDL to replicated either the Disciple or +3 interfaces.
Like most things it's no fun once you've got it working a little bit. It becomes "work" to get it that next bit further, at least to me.
-
boing4000 wrote:
The current PIC (or ARM board) should be able to handle different core files and the extension of disk files (i.e. .adf, .d64, .st etc.). Its also possible to rename all files in .adf as long as the sector size is still 512 byte per block. That would not require different PIC version or bit changes in its firmware, since there is no much space left.
But that's just it, AFAIK they are not the same (although I've never tried)
AMSTRAD / Spectrum +3 DSK format for example has different possible sector sizes and non are the same as Amiga ADF.
However I'm not sure for MiniMig how much of the disk image file access is inside the PIC and how much is inside the FPGA. If all the track/sector handling is inside the FPGA and it just requests data from the PIC as an offset within the file then it should be possible to use the existing PIC (at least for reads).
-
Taken into consideration that the minimig is quite a nice board, we should be able to get alot of cores running on it 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, it would be nice with another mobo on the market. Nice to have a choice. But my biggest fear is that the boards (and future fpga board) develop in different direction so that neither boards can share cores easily. That is kind of like a lose-lose situation for all of us. Maybe a common roadmap for the developers of the boards would be a good idea.
I am sticking to my minimig hoping for a c64 core soon. That makes my world a perfect one :) One CD card labeled "Amiga" and the othe "C64". Could I ask for more ? :-)
(oh, I could...but I wont hehe)
Regs
Espen
-
>>Taken into consideration that the minimig is quite a nice board, we should be able to get alot of cores running on it before switching to a new mobo probably.
Totally agree. I want to use it to its fullest and make sure it becomes a mature product, like a classic Amiga and keep it.
Also I make and produce the cases for this little beauty :-)
>>But my biggest fear is that the boards (and future fpga board) develop in different direction so that neither boards can share cores easily.
This will eventually kill one of the two boards and that is a shame.
>>I am sticking to my minimig hoping for a c64 core soon. That makes my world a perfect one :) One CD card labeled "Amiga" and the othe "C64". Could I ask for more ?
Totally with you there :-) It makes sense to exploit the Minimig to the full, hoping for a C64 core and more cores later on.
-
Yes. Fingers crossed. Regarding casing, I have the ITX version so I have the possibility to choose standars ITX ones, but they are expensive as hell :-( So I am gonna make a simple homemade PLEXI box for it instead. Will cost me a fraction of a commercial mini itx casing.
Did you make that white nice box in plastic ? If so, great work. Looks very nice.
Even though minimig dies in the end because other boards are for sale which has more power and more capacity, that doesn´t matter too much because every board has its lifespan, and the minimig is not that new anymore. But it was "the" board which probably kickstarted all this amiga-in-a-chip in the beginning. I am very thankful for both the minimig board and Dennis´ work here. But as time goes by, more people will follow in his footsteps and make better boards. And this is just normal i guess. It benefits everyone. 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 ? ;-)))
Regs
Espen
-
>>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. :-)
-
n.t.
-
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.
:-)
-
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/
-
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
-
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.
-
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
-
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
-
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 :-)
-
Additional update:
FPGA64 on minimig V1.1 board: IT WORKS!!
pictures will be uploaded soon.
-
As I said, doing the initial port is the easy and fun bit. Getting it to be usable is the hard and boring bit.
-
You´re right. But someone must do the first step.
Without a minimig board its not really easy.
-
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
-
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!
-
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.
-
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
-
I did some VLSI design a few years ago. And have experience with microcontrollers. So this things about lacking FPGA discussion here, got me interested in picking up on things.
Can I use my MIniMig board as a test-board ? (I guess it must be possible...) or so I have to buy a Spartan kit ?
Espen
-
Palm wrote:
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 ?
The amounts of money involved in these bounties are inconsequential. If it was about money we'd do another few hours of contracting instead ;-)
I'm telling you, as soon as a few engineers start posting their source code, talking about technical problems, goading others to solve them and help out, the projects will start flowing.
At the moment active developers are Tobiflex and Yaqube and RedSkull and they keep their cards pretty much to themselves (either that or they are on another forum?) and I think they have all moved away from the MiniMig 1.1 PCB.
-
Palm wrote:
Can I use my MiniMig board as a test-board?
Of course. The FPGA image lives on the SD card. You make a new one on the PC with the Xilinx tools, transfer it to the SD card and pop it in MiniMig.
-
I guess I have to call the .bin file minimig1.bin then, no matter whether it is a c64 core :) My guess is that the pic bootloader automatically tries to look for the file called minimig1.bin or something ?
Thanks for the tip. I will DL and check it out.
-
I am not 100% familiar with Yaqube's PIC updates but originally the FPGA image file must be named "MINIMIG1.BIN" and the file to be preloaded into SRAM must be "KICK.ROM" and I think it had to be padded to 512Kbytes but I'm not too sure about that.
-
Yes, you are right alexh, those are the names of the files needed. However, I wonder if the firmware really preloads the kick.rom file if there is another core used (e.g. a c64 core). Is it the FPGA itself which loads the kickfile to sram after minimig1.bin is loaded, or does the pic firmware both preload the kick.rom and afterwords. Reason why I ask, is if a new core is to be used, do we need a new fw that does not expect kick.rom on the sd card ?
Espen
-
The sources are widely available. You can a have a look at them and see how it works.
The PIC firmware configures the FPGA with MINIMIG1.BIN file. No matter what it contains.
The Minimig FPGA file contains a ROM with bootloader for the external 68000 CPU. This bootloader uses Amiga floppy DMA controller to talk to the PIC. The PIC sends an Amiga ROM file which is received by disk DMA and put in the RAM buffer. Then the 68K CPU copies it to the specified location.
In the latest firmware only two ROM sizes are supported: 256KB (no need for mirroring to 512KB) and 512KB.
-
with new fw you can specify another kickstart file which will be used after boot
-
alexh wrote:
I am not 100% familiar with Yaqube's PIC updates but originally the FPGA image file must be named "MINIMIG1.BIN" and the file to be preloaded into SRAM must be "KICK.ROM" and I think it had to be padded to 512Kbytes but I'm not too sure about that.
You are right, the core file has to be named "minimig1.bin" no matter whats inside (Amiga or C64 etc.) to be loaded from PIC into the FPGA.
After that its up to the core how to handle surrounding hardware like io-pins and PIC communication. Right now the FPGA64 core dont know anything about PIC nor SPI bus at all. Its just a native C64 with ps/2 keyboard (and mouse) support. No joystick ports are implementet yet, but thats an relative easy think to do.
To have some 1541 floppy simmulation via PIC, its firmware has to be altered and reflashed! Also the C64 core has to be adapted in order to use some OSD and .d64 etc. file support.
I think that may be the next-next(-next?) step ;-) Currently Dirk and I are fixing some problems in unconnected fpga pin what causes random C64 system crash.
Next step could be: Adding IEC bus to spare-i/o pin and joystick support.
ps: Minimig board is in my point ov view an excellent testing env. it provide all necessare i/o ports and the core is simple to load in the fpga (via sd card, not via some maybe self made jtag interface).
-
yaqube wrote:
The Minimig FPGA file contains a ROM with bootloader for the external 68000 CPU. This bootloader uses Amiga floppy DMA controller to talk to the PIC. The PIC sends an Amiga ROM file which is received by disk DMA and put in the RAM buffer. Then the 68K CPU copies it to the specified location.
Interesting... I do remember something about this... I dont remember it being like you describe (it's complicated, and I'm not one for complicated) but you are the master at this subject. So what did I do?
There is certainly not enough RAM in the FPGA to implement 16Kbytes (let alone 48Kbytes)... I'll have to look back at it see what I did...
-
I still dont get the rush for c64 cores. When the Amstrad CPC is by far a better machine.
Get the CPC core working first :-D
-
That may be but think about this: C64 is more famous and provide (afaik) a bigger palette of games and demos. Also much more ppl got a C64 in the past then CPC.
I also like the CPC and have got an Amstard 6128 with color monitor (using on minimig ;-)) here. But I dont have much floppy disk and even less useable games. Also its a bit mor complex to get the disk-file on real floppy to make it use on real CPC.
Perhaps in the future the CPC core will be ported to the minimig board as well. It would certainly be an interesting project and result :-)
-
I did try on that for a few nights when I got my MiniMig. Tobiflex's excellent TREX CPC is written in AHDL which is a language specifically for Altera FPGA devices. You CAN convert to VHDL/Verilog using tools but they are buggy and produce non-human readable code (plus all the comments go).
Might be worth looking at once more.
-
Allright, how about adding IEC option thru the pinout then. I have a uIEC unit and a 1541-3 unit that I can use. This will give me what I need to use the core. If the core can supply me with kb+joysticks+iec I would be a happy man. Of course, the sid+vic must work properly ;-)
Can you say if the current c64 core works as it should when it comes to emulating the c64 as good as possible ? Does demos work ok?
Another thing: Can JiffyDOS be implemented in the core ? If I do own JDOS chips, can I add the JDOS kernal myself somehow ?
Regs
Espen
-
alexh wrote:
There is certainly not enough RAM in the FPGA to implement 16Kbytes (let alone 48Kbytes)... I'll have to look back at it see what I did...
The XC3S400 has 16 RAM blocks of 18K bits each. It gives you 32KB of RAM.
-
First of all the core has to be fixed due to some reset and bootup freeze. Then Dirk and I can take care of adding IEC support. Keyboard is already working and provide switching between PAL and NTSC by pressing F12 key.
How compatible the FPGA64 core is to a real C64 I can not say because right now I can't load any game or demo.
The core is using one sram chip of minimig pcb and provide full 64KB of ram! No need to use another fpga blockram. Currently all 3 C64 rom images are stored using blockram, so there are still some space left for some other invention/expansion.
-
That sounds very nice. But to add another kernal, this must be embedded in the master-binary file (minimig1.bin) right ?
So I need the sources to enbed my own kernal. And the sources are not released, if I understood correctly ?
Boing4000+Dirk: Keep up the good work!!!
Have you thought about how to add cartridge support somehow?
Maybe F11 as freeze-button ? :-) ..or even better: BREAK
Regs
Espen
-
Yes to use another kernal the whole core has to be recompiled. Currently the only "external" thing in use is IC7 (sram0) to provide 64KB of memory. everything else like cartridge has to find its place inside the FPGA. This space is very limited as Jakub already said and there is already 13 of 16 blockram in use.
Loading anything else (additional rom image) into sram would require the PIC and a matching file handling. This is too much for me! Im not an expert in FPGA coding, so pls dont expect too much in too little time.
Right now Im very happy to see a working C64 core on minimig. An IEC bus would make this think good enough for me :-)
Lets see what can be done in the future.
-
yaqube wrote:
The XC3S400 has 16 RAM blocks of 18K bits each. It gives you 32KB of RAM.
Yeah, not quite enough to load 48k ZX Spectrum RAM snapshots via the FPGA IMAGE loading mechanism built into MiniMig's PIC.
Which means :
I never loaded any games (I'm almost sure I did)
I used 16k interface 2 ROM's (Horace goes skiing, PSSST, TransAM etc.) or
I did something else involving the PIC and loading from SD (unlikely as at first my PIC didn't have a bootloader).
-
Nice. How is the video output handled? It isn't just VGA output it it? Not interested if it is, unless there's a near perfect PAL emulation filter in there. I gotta have my low-res blindness to get those extra colours. ^_^
But then again, I guess it should be possible to output a chroma/luma signal from the VGA port, selectable with the scanrate jumper perhaps...
-
Currently the core is based on 31KHz at 50/60Hz switchable via F12. to have the same feature as Minimig to select between 15/31KHz by jumper, it has to be adapted into the core. A scandoubler is already there and could maybe be switched on/off. But unlike Minimig the whole system is based on the already doubled frequence, so its not that easy to adapt. Perhaps Dirk and Peter are able to so.
I also would like to see FPGA64 at 15KHz PAL (or NTSC) :-)
-
I thought that Yaqube's latest MiniMig sources included some sort of filter? Dunno how easy it would be to adapt, credited of course. Some of the more easy filters should be simple to implement from scratch especially having more free space in the FPGA than with an Amiga core.
-
How is the 64 core doing. ?
Can I ask, is the sources for this available ?
Is it the ISE Foundation 10.1 I need to be able to load a source, compile it and get a binfile ?
Xilinx has a free 60 day eval version, but I am not sure if I need the webpack of the FOundation.
Anyyone who can enlighten me ?
Espen
-
Peter's original code is available here :
http://www.syntiac.com/fpga64.html
I currently still use ISE 9.2 service pack3 as it, well, works. ISE 10.1 is probably ok but I don't trust new Xilinx software as a general rule.
Webpack is ok for the Spartan3.
http://www.xilinx.com/ise/logic_design_prod/webpack.htm
I don't use the GUI, I provide a batch file which runs the tools. You can practice on my VIC-20 core.
Download,
replace the dummy ROMs with real ROMs in \roms directory
run build_roms.bat (produces VHDL ROM files)
run build_xst.bat
.bit file produced.
You can then modify the .prj and .scr files for the C64 files.
/Mike
-
Thanks for that info. I will definitely try it out. I just downloaded the webpack 10.1, and I just bought a usb-2-rs232 adapter so I can flash my minimig with new fw aswell, and bought some plexiglass to make a temporary casing for the minimig board to ease the tear on it :)
I was wondering, do you know how to make a jtag cable or is there a resource on the web to which I can make one ?
Have to drop by work to pick up a adapter so my USB keyboard can be used on the minimig (which only supports ps2 kbd). After that, I will go ahead and try out webpack. This is totally new for me, so it´ll fun.
BTW: Above, you write ".bit file produced". Do you mean ".bin file" (as in, the file I can rename to minimig1.bin and boot up at the minimig) ?
Regs.
Espen
-
I was wondering, do you know how to make a jtag cable or is there a resource on the web to which I can make one ?
http://www.nuhorizons.com/products/digilent/jtag-cable.html
there are also usb ones, which are definitely faster solution (with par. port its around 6 minutes to push 64kb of code)
-
Palm wrote:
I was wondering, do you know how to make a jtag cable or is there a resource on the web to which I can make one ?
BTW: Above, you write ".bit file produced". Do you mean ".bin file" (as in, the file I can rename to minimig1.bin and boot up at the minimig) ?
If you build a .bin file no jtag cable will be required. Just rename the "something_project.bin" after compiling into "minimig1.bin" and store it in root of your (testing) sd-card. Minimig's PIC will upload this file to the fpga and don't care about its contents. Im doing this all the time in testing new fpga64 and minimig core file.
Jtag is a bit faster and no sd-card changing will be necessary. But the cable and fitting software has to be there. Jtag connection will require a .bit file to program the fpga.
-
Chain wrote:
there are also usb ones, which are definitely faster solution (with par. port its around 6 minutes to push 64kb of code)
The parallelport Jtag is much faster.
The bitfiles for my Spartan x3s1000 have a size of 403 KB, it tooks nearly 12 seconds to configure the FPGA via par port.
Cheap Xilinx lpt port jtags are available on ebay.
For developing i would prefer always the jtag solution.
Dirk
-
Update: IEC bus is working now. Loading via a (selfmade) cable and 1541-II is possible. Games tested so far: Giana Sisters, Airwolf and Arkanoid. All working fine, but scene demo "Deus Ex - Machina" crash while loading the next part. I think is has to do with some kind of speedloader and not yet 100% accurate core timing. Could be fixed in the near future.
Pictures and german information here: click me (http://www.a1k.org/forum/showpost.php?p=227877&postcount=197) (If unwanted, I will remove the external link.)
I found it very exciting to do some code + hardwiring and suddenly an external floppy drive is working :-)
-
At this rate you'll have a release ready in no time ;-)
-
Impressive. I await the day that I'll be able to run edge of disgrace (http://video.google.com/videoplay?docid=4387496359091532951) on my Minimig. (Actually could you test that? I'm interested how well it could work cause it took me 2 weeks to get my C64 to play it all the way through without crashing or seriously glitching).
But out of curiosity, the game you tested were single load games. It might be worth testing with some multiload games as well. The loaders in some games can be quite forgiving while others are rather more strict (Creatures 2 comes to mind, the non cracked version that is)
-
"BTW: Above, you write ".bit file produced". Do you mean ".bin file" (as in, the file I can rename to minimig1.bin and boot up at the minimig) ?"
A .bit file is produced automatically - it contains a header with some extra info in. If you add the options to bitgen -Binary Yes (from memory so might be wrong) then the tool will produce a .bin file which is just the configuration data. That's what you need for the SD card.
There is something called a parallel cable 4 which runs a lot faster than the basic parallel configuration cable and is cheaper than the USB one - although not as fast. I found somebody making a clone of the Xilinx USB cable really cheap but I can't remember where I saw it. Probably in China.
/Mike
-
@Hojo_Norem
edge of disgrace is certainly one of the very best C64 demo I've ever seen! I will try this as soon as I got it on real floppy disk.
May be the multiloader will fail as in "Deus ex machina" but a few hours ago I found the right timing setting. Now fpga64 shows a 49Hz 30.8KHz PAL screen! Its possible that now all loader will work, but I have to sleep a bit before testing (it's almost 01:00 o'clock in europe :-)).
@alexh
To release a binary or source, I have to remove the ROM images or replace its content with "$00" ro keep up existing copyrights. Currently the fpga core itself comprised the ROM images and I can not make this public, sorry.
To keep copyright up the core should load the image from sd-card, like minimig is doing. But this would require PIC reprogramming or some other solution.
If anyone has a better idea or request, please send PM to me!
-
GOod job there!
Let us know when we can test it :-)
-
"To release a binary or source, I have to remove the ROM images or replace its content with "$00" ro keep up existing copyrights."
How do VICE and FRODO legally release a rom? I always assumed that they used a rom that was clean room cloned. Could the ROM from one of those be used?
-
May be the multiloader will fail as in "Deus ex machina" but a few hours ago I found the right timing setting. Now fpga64 shows a 49Hz 30.8KHz PAL screen!
49Hz sounds a little slow. I thought the PAL C64 refreshed at 50.12Hz? (I know this because when recording my Panasonic DVD-recorder skips a frame now and again and my Sharp DVD-recorder makes the audio go out of sync with the video).
-
Hojo_Norem wrote:
49Hz sounds a little slow. I thought the PAL C64 refreshed at 50.12Hz?
Yep it should be at least 50Hz @ 30-31KHz but the timing settings are a bit difficult to adjust. First it was 56Hz and everything was running too fast. Perhaps I may be able to create a 2nd dcm clock generator to gain a better adjustment.
Until now also PAL and NTSC 15KHz screen is available. Currently just static but also in the future selectable via existing 15/31KHz jumper. Im working on it...
I found out that multiloader are very sensible programming stuff. Right now no scene demo is able to load the next part. It may caused by the core (source) itself but I can not reproduce that theory. If possible someone else could test the following demos on another FPGA64 porting:
- Deus Ex - Machina
- Oxyron - Natural Wonders
- Execute - Overdrive
@Belial6
I will inform me about that issue. If there are public/free ROM image available, I could implement them in the core. But first I'll have to make sure.
Thx :-)
-
Belial6 wrote:
How do VICE and FRODO legally release a rom? I always assumed that they used a rom that was clean room cloned. Could the ROM from one of those be used?
For FRODO:
http://lachner-net.de/index.php?option=com_content&task=view&id=3&Itemid=5
The emulator needs also C64 ROM files. For copyright reasons this [sic] files are not included in the ipk package. This files can, for example, copied from a original C64. After Frodo is installed [...], this [sic] files must be copied to "/opt/QtPalmtop/bin/frodo". The following files are needed:
Kernal ROM
Basic ROM
Char ROM
1541 ROM
This page contains some links for the C64 that might be of interest (including the original manual).
http://frodo.cebix.net/
-
If you want testers, and don't want to distribute your core as it is (containing embedded roms) .. how about we email you a copy of our roms, so you see we have them, then you make the core available to us (email back?) after we have acknowledged having roms beforehand.
I know this is totally silly, as probably everyone can DL them illegally from the net, but still -- it would provide a way to do it....somehow.
BTW: It would be cool if there were some kind of dram or other storage device on the minimig (apart from SD card) which enabled core to easily load data from it. Then we could have filled this space-area/chip (whatever) with e.g. rom files for the core to load upon boot.
Is itpossible to add a memorychip to any existing lines so we can connect dram or flash or something ? I think the next gen of minimig should have a easy flashable chip in which we can stuff with romsfiles. That would make core-sharing so much easier when they could be shared without pre-compiled romdata.
Any opinions on this ?
-
denli wrote:
Belial6 wrote:
How do VICE and FRODO legally release a rom? I always assumed that they used a rom that was clean room cloned. Could the ROM from one of those be used?
For FRODO:
http://lachner-net.de/index.php?option=com_content&task=view&id=3&Itemid=5
The emulator needs also C64 ROM files. For copyright reasons this [sic] files are not included in the ipk package. This files can, for example, copied from a original C64. After Frodo is installed [...], this [sic] files must be copied to "/opt/QtPalmtop/bin/frodo". The following files are needed:
Kernal ROM
Basic ROM
Char ROM
1541 ROM
This page contains some links for the C64 that might be of interest (including the original manual).
http://frodo.cebix.net/
:-?
AFAIK when I downloaded VICE from their main site it worked out of the box. And I vaguely remember something of certain Commodore 64 software being legally freely available.
-
Dude, same here. I downloaded vice(x64?) for OSX and it too worked out of the box.
Espen
-
I dont know the full rights-system of emulators including rom images on the internet. But if one will share this files without permission it could cost a huge amount of money. Even if this rom copyrights are very old like the C64 one.
The idea of having some kind of flashrom to store necessary rom images is a good one! Using PIC to upload (different) rom files in the current state, will require an intelligence how to handle Amiga-kick.rom and anything-else.rom to the just uploaded core file.
Handshaking is a difficult thing to do, especially in complex (working) core files like a native C64 that dont have any clue of SPI bus system or "whats a PIC...?".
Perhaps in the future it will be possible, but it would require a lot of work and knowledge about the ported system structure. Still it is possible, like we see on Minimig Amiga Chipset and its PIC communication (floppy simmulation) :-)
-
Is there a hard reset on MiniMig PCB? Could you program the FPGA with a core which will transfer a file from SD CARD to the SRAM using the standard PIC and then reprogram the FPGA with your core? The SRAM should hold it's contents.
-
That could indeed be a way. The s-ram will hold its data even while hard resetting or reprogramming the FPGA.
We would use the working minimig Amiga chipset core to fill a special part of s-ram with some rom image. Then simply swap sd-card, reset the system by pgm reset button and let PIC upload the next core. If this core will look for its rom data in the same address range uploaded before, then it could actually work!
In this case no PIC reflashing will be necessary! I can try to check this out by some test-core that only read particular add.ranges filled by the "Amiga" core.
Thx for this idea :-)
-
I was wondering, are the sources for the c64 core free so that I can download them, embed my own ROMs from my C64 into the source, compile to a single .bin file so that I can use this ?
It would require ppl to install ISE and compile themselves, but after reading you tutorial, it looks very easy to do.
(downloading SP4 IDE webpack now -- soon trying to compile the minimig sources..ehhe)
Espen