View Full Version : De1
tcdev
6th July 2009, 01:00 PM
I've spent the last week or so getting all DE1 projects to build - or more correctly - elaborate successfully. The only project outstanding atm is Zet, because it's largely a moving target, and has its own DE1 port anyway.
I won't make any guarantees at this stage that the above-mentioned projects actually run - or even synthesize correctly. In particular, some platforms have DE1 projects yet are currently unsupported on the DE1. You need to check the status of the ports in the sticky threads of this forum to see if a particular platform is actually supported on the DE1.
Let me know if you're particularly interested in a particular platform and are having problems with it on the DE1. Or even if it is unsupported on the DE1 - there may be a way around that problem that I just haven't gotten around to implementing yet.
tcdev
6th July 2009, 03:32 PM
Most (not all) of the NB1 builds have now elaborate correctly.
Phew - this is a long and tedious process! Some of the projects are still in the pre-re-architect stage. Hopefully it is now a lot harder to break the framework!?!
tcdev
9th July 2009, 07:56 AM
On to DE2/P2 now....
vanfanel
15th July 2009, 09:23 AM
Hey TCDev, I've asked this question to the forum admin in an e-mail, but I am not sure you're the same person, so...
I read in the softcore 68k yahoo group that the Minimig port to Altera DE1 does not work with newer Altera DE1 boards: has it ever been fixed?
Is there a release of that core anywere? I've got a new Altera DE1 and I'd like to experiment with the Amiga core on it :D
Thanks!
tcdev
15th July 2009, 09:46 AM
Hey TCDev, I've asked this question to the forum admin in an e-mail, but I am not sure you're the same person, so... Yeah, that's me!
I read in the softcore 68k yahoo group that the Minimig port to Altera DE1 does not work with newer Altera DE1 boards: has it ever been fixed?
Is there a release of that core anywere? I've got a new Altera DE1 and I'd like to experiment with the Amiga core on it :DTo be honest, I haven't kept up with the latest Minimig developments. It would seem Tobias - who did the original DE1 port of Minimig - has been focusing all his efforts on the C-One lately, and hasn't really done much with the DE1.
IIUC, the problem with some DE1 boards (and I'm not sure if it's the newer or the older) is that the SDRAM chip is different and - worse still - the specs aren't open. That's a real problem when trying to get the controller working...
Having said that, I had problems early on with my DE1 (PSC SDRAM) and then later builds started working OK. I was going to look further into it, as I wasn't sure whether the problem was the parameters in the controller itself, or simply the timing constraints on the SDRAM pins, but never got around to it.
vanfanel
15th July 2009, 11:33 AM
So what version of the Minimig port should I try on my new Altera DE1?
What's tle latest version?
tcdev
15th July 2009, 01:52 PM
So what version of the Minimig port should I try on my new Altera DE1?
What's tle latest version?I'm running v13 on my DE1 and I've just booted Hybris!
There's a copy in the PACE SVN source repository... just check out the .zip and build from there...
vanfanel
16th July 2009, 09:01 AM
Great, will try tonight!
Should I be able to use a USB joystick with a USB-to-PS/2 adapter?
A Minimig is good with keyboard & joystick, but I bet it's even better with a Joystick :P
tcdev
18th July 2009, 12:21 AM
Great, will try tonight!Did you have any luck?
Should I be able to use a USB joystick with a USB-to-PS/2 adapter?
A Minimig is good with keyboard & joystick, but I bet it's even better with a Joystick :PI'm not sure what type of luck you'll have using a USB-to-PS2 adapter with a gamepad. AFAIK they're only designed to work with keyboard and mice.
That aside, a lot of Amiga games were designed to work with the joystick port, so that wouldn't work for those games.
Your best bet is to wire up an adapter to the DE1 expansion connectors and use either a digital joystick or the DC/NGC controller cores in PACE. I've used the NGC controller on a couple of arcade games, the C64 and the Coco 3 (in analogue mode) but am yet to actually use it on Minimig...
vanfanel
18th July 2009, 11:46 AM
Well, TCDev (I should call you that here, shouldn't I?), I tried the Minimig cores with no luck. I tried both the V12c published on Dennis's official page and V13 in the PACEDev repository, both without luck, so I need a little help.
Let's concentrate on V13, the one you recommended me. It includes the source files and the .POF/.SOF files for the DE1, ready to program, in a folder called "Quartus_DE1".
I just opened the Quartus Programmer application, changed the programmin mode into "Active Serial Programming", opened the file and clicked on "Start Programming". The USB Blaster was of course detected, as this machine is usually configured as an MSX so I've programmed it before ith the MSX core the same way without problems.
When programming finished, I just changed the switch into Run mode (I put it on Program mode before), but all I get (with swithes 0-3 ON as indicated in the instructions of V12C release, since V13 doesn't come with any docs), but all I get is a nice 88888 on the 7segment displays, and several leds on, and nothing more.
Of course, in my SD card (properly reformated as FAT16) there are the SPIHOSHT.ROM and KICK.ROM files.
So, what am I doing wrong? I also compiled V13 with Quartus V7.2 Web Edition, but I don't know where the generated POF/SOF went. The only ones I found had the same creation date as the original ones included.
I am sorry to ask, but...could you upload you FINAL POF along with the SPIHOST.ROM you use for V13? In the form of a final package. I could also use exact instructions for programming V13's included POF if those included files are the ones you used.
Thanks in advance, and sorry for asking so newbie questions. I promise I will help others trying to jump into the FPGA wagon for Amiga simulation.
tcdev
18th July 2009, 02:26 PM
I am sorry to ask, but...could you upload you FINAL POF along with the SPIHOST.ROM you use for V13? In the form of a final package. I could also use exact instructions for programming V13's included POF if those included files are the ones you used.I've attached the .SOF and SPIHOST.ROM file. Just program the DE1 in "run" mode with the .SOF (JTAG) to see if it'll work for you. I have SW9,8,3-0 all ON (UP). That's enough to boot KICK.ROM and load and run HYBRIS.
If that works, you can actually use Quartus to produce a .POF from the .SOF - using "Convert Programming File". If you can't figure it out, let me know and I can post/email the POF directly.
There's a chance I've been "lucky" with the build - things can be "flaky" if the correct constraints aren't specified. I'm not sure which SDRAM is supposed to work and which isn't?!?
vanfanel
18th July 2009, 03:58 PM
I've tried what you told me: programmed the SOF in JTAG mode. No errors on Quartus programing module, but I get the same result: ALL 88888 in the 7segment display and no video output.
I left the switches as you told me, too. Also tried different combinations with no luck.
It doesn't seem to have any led/alphanumeric display activity upong JTAG programing of the POF file: it just shows the 88888, and that's all. Could it be the SDRAM problem? I got my DE1 a week ago.
wheedal
18th July 2009, 04:16 PM
SD card:
http://www.sdcard.org/consumers/formatter/#download
has a more compatible formatting utility.
I had to sort through several sd cards until I found ones that worked well with minimig. The card is important, as nothing indicates life until you get one that the project can read. I think the timing/mode constraints are way too tight on that as well. Anyway, make sure you have a few cards to try. Weird that the San Disk stuff didn't work at all for me, but I hear they've been as bad as anyone lately with substituting various controllers in their cards.
PSC memory image:
Also, here is an image file from a google forum that worked on mine. I'm still having a hard time finding the correct version/compiler combination that makes a working image on my board. I'm using quartusII 9.0sp1. Anyway, this one seems to do the trick.
http://minimig.googlecode.com/files/Minimig_DE1_config_13.zip
I might also add that most of the versions would work far enough on the new DE1 board to show the blue on screen menu on the monitor, so long as the SD card was compatible, formatted correctly and had the correct files on it. It was when you tried to boot kick.rom that the various versions would give graphics errors until I got a version that had the sram timing correct on my de1.
Also, you might press the left of the 4 momentary switches, as that they control the on screen handler menu that should show up regardless of the kick.rom file. If you get that then you know that the card and spihost.rom file read correctly, so you can then concentrate on getting the amiga to boot.
vanfanel
18th July 2009, 04:42 PM
Thanks for your help, wheedal, but I have the same results:
-Formatter my old Pioneer card with that new utility in fat16
-Copied both SPIHOST.ROM & KICK.ROM
-Programmed both the SOF in JTAG mode, and tried the POF in Active Serial Programmin mode.
Same results: 8888 in the display, and no LED activity. What does happen when you start the DE1 with no SD card? Do you get the same 8888??
wheedal
18th July 2009, 05:12 PM
Thanks for your help, wheedal, but I have the same results:
-Formatter my old Pioneer card with that new utility in fat16
-Copied both SPIHOST.ROM & KICK.ROM
-Programmed both the SOF in JTAG mode, and tried the POF in Active Serial Programmin mode.
Same results: 8888 in the display, and no LED activity. What does happen when you start the DE1 with no SD card? Do you get the same 8888??
It sounds like your card is your problem. If you have an incompatible card, it won't boot correctly, and will show the 8888 as you have seen. I'd concentrate on changing out the cards.
Now that you have the project in the serial memory, you can just try several cards and cycle power to see if any boot up properly. You should see 000 on the led's and a blue on screen window pop up when you press the left momentary key. If you don't spihost.rom has not been loaded and the microcontroller handling the floppy emulation isn't running.
Time to dig out some other cards. I got a 2 GB kingston and 2GB patriot sitting on my DE1 kit that work. The 2GB and 1GB San Disks do not, and I had problems with a few other brands not sitting in front of me. Its wierd, but when doing embedded work, I usually have problems with the kingstons and few issues with san disk. This project seems to be the opposite of that.
vanfanel
18th July 2009, 07:07 PM
Great, whedaal, I ALMOST made it work now!
I formatted a Kingston 2GB card I had in my GameCube, and DE1 loads the SPIHOST and KICK.ROM files, showing the Amiga 1.3 ROM white screen (without the "hand with the disk" picture...is that normal??)
I also included severa ADF images, wich I tried to load with the F12 menu, by pushing home on their names.
It says "inserting adf ******" and the menu exits after APPARENTLY completing insertion, but the games/demos won't boot. I tried soft-reseting, too, in the old Amiga style (CTRL+ALT+ALT), but it won't boot into the games/demos. I'm sure you know if there's something wrong...we're ALMOST there!! :D
wheedal
18th July 2009, 08:55 PM
I saw corrupted kickstart screens when I was using sof files set up for the other memory type. The version 13 link I showed to you did the trick for me. As soon as I got that going I was able to see the screens just fine.
http://code.google.com/p/minimig/downloads/list
you might look at the other images on the list and see if they work better for you. the quartus 8.1 compiled version 13 is the one that says psc compatible, but I actually had better luck with the other de1 version 13 that I pointed to last time.
Your getting close!
vanfanel
18th July 2009, 11:21 PM
I've tried the version compiled with Quartus V8.1 and it has the same problem: no hand-with-floppy image, just a white screen and no games/demos booting.
The memory on my DE1 has "Zentel" written on it: I think it's a newer version, wich would explain why I can't get it working with the current versions of the core... any other ideas, wheedat or TCDev? I will make any tests as you can think of, but I'm starting to think that it won't work...
tcdev
19th July 2009, 12:54 AM
That you can get the kickstart roms to load but not the ADF is most probably an SDRAM problem. I had this same problem for a long time before I finally found a build that worked. I also had the same problem on my 'P2' hardware as well. :(
As an aside, I'm using a 512MB SanDisk. I purposely sought out some old (low capacity) cards for use with PACE/Minimig hoping that they'd be more compatible. I also found - after much searching - a 32MB SanDisk? but as yet haven't had to use it as the 512MB seems to work fine. It also works in Alex Freed's DE1 Apple II project. :cool:
Interesting that someone has found the PSC specs. What exactly is written on your Zentel SDRAM? Perhaps we can find the specs for that and work out why the SDRAM controller is incompatible?
I haven't checked for a while but for reliable SDRAM operation you really need to constrain the pins on the SDRAM and skew the clock, which means the SDRAM should be using 2 PLL outputs - one for the controller core logic and the skewed output goes to the SDRAM clock pin.
FWIW the Zet project has similar stability issues and I suspect it's also the way SDRAM is implemented.
When I get the chance I'll have another look at the Minimig SDRAM controller...
tcdev
19th July 2009, 01:30 AM
I haven't checked for a while but for reliable SDRAM operation you really need to constrain the pins on the SDRAM and skew the clock, which means the SDRAM should be using 2 PLL outputs - one for the controller core logic and the skewed output goes to the SDRAM clock pin.Just had a very quick look at the v13 source code. Seems it is using a skewed clock - about -3ns - on the SDRAM after all, so that's a start. But no pin constraints, which isn't ideal.
wheedal
19th July 2009, 02:12 AM
I see theres a few pictures of it on new DE1 boards on some Russian tech forums. Don't have a clue what they are saying, but it looks like they are discussing a similar problem.
http://www.xdevs.com/e107_plugins/mediagallery/view.php?119
Looks like a zentel A2V64S40CTP-G6
http://www.zentel.com.tw/index-eng.html
tcdev
19th July 2009, 10:11 AM
The Zentel specs look very similar, though I notice a couple of parameters that are different; for example CLK to valid output is 5,6ns as opposed to 4.5 on the PSC memory.
The trouble is, the Minimig SDRAM controller is not commented at all - it's dual-ported for access by the Z80 and designed with a fixed-frequency input clock synchronous to the SDRAM clock (no doubt so it can be accessed by video logic) which makes it very difficult to decipher what's going on. It would require careful reverse-engineering in order to be able to modify it for the Zentel chip.
vanfanel
19th July 2009, 04:59 PM
I can confirm that my Altera DE1's SDRAM chip is labeled A2V64S40CTP-G6, so that's the same model you've mentioned.
Do you think it can be fixed, TCDev? Well, if I can give more information or conduct some more tests, please tell me.
I believe you should check at Caro & HRA!'s port of the OCM, as it works flawlessly on every DE1 model:
http://www.msx.org/forumtopic8494.html
How are things going in the FGPA64 front for this board? In the platform/target matrix it says the 1541 emulation is WIP, and you told me DSK loading is unreliable, but... do you have a version with partial DSK support or .c64 file loading support? The C64 was my first computer and I would love to see it running anything on the DE1...
Thanks!
tcdev
20th July 2009, 12:08 AM
Do you think it can be fixed, TCDev? Well, if I can give more information or conduct some more tests, please tell me.Unfortunately it's not so straightforward. Ordinarily, you'd expect to find a generic, parameterized SDRAM controller, like yadmc in the Zet project. If Minimig used this, it would be much easier.
However (unlike Zet) Minimig uses SDRAM for video memory as well, so the operation must be synchronous to the video clock and both cpu and refresh must be interleaved with video accesses. This ties the design of the SDRAM controller very closely to the video and system timing of Minimig.
Also, since it's dual-ported and all-but-completely-uncommented code, it makes it very difficult to work out exactly what is going on. And it may be (worst case) that the slower Zentel memory won't actually work with the current clocking scheme and it would have to be re-designed.
I believe you should check at Caro & HRA!'s port of the OCM, as it works flawlessly on every DE1 model:I've seen that in the past, but haven't really looked into it since I got OCM running on my P2 hardware. But I'd imagine you'd run into the same problems as Minimig since - IIUC - it is also using SDRAM for video memory. The clocking on OCM would be completely different to Minimig, so I very much doubt you could use anything from the OCM controller.
How are things going in the FGPA64 front for this board? In the platform/target matrix it says the 1541 emulation is WIP, and you told me DSK loading is unreliable, but... do you have a version with partial DSK support or .c64 file loading support? The C64 was my first computer and I would love to see it running anything on the DE1...It's been quite a while since I looked at the C64/1541, but I was thinking about it just the other day. The problem is I have so many projects "up-in-the-air" atm I'm having trouble focusing on one. However what has been lacking in a lot of projects is a FAT/SD core that I can use in TRS-80, Zet, Neo-Geo and others including C64/1541, that I've seriously looking at focusing on that atm.
I need to sit down and decide which is the best way forward for this. Previously I was running FatFS on a NIOS with a software bit-banged SD interface, but that's far from ideal. What I really want is a HDL back-end SD/CF with a HDL module that can read files from the root directory of a FAT16/FAT32 partition. But not sure how feasible that is...
vanfanel
20th July 2009, 08:01 AM
I think a FAT/SD core to support all those projects would be a great idea, indeed. The FPGA64 core, for example, remains out of reach for most users as it only loads files from SD in that expensive and limited C-One board.
Other cores have the same problem: they are ported by you or other people to general-purpose boards like the DE1 or DE2, but they lack SD file-loading, preventing them from being really useable for general users. I think souch a generic loader core would be a GREAT step forward, indeeed.
In other words, I believe it would be a single solution for multiple problems, or for a problem that spawns over several cores, and ALL they would be very improved at once.
invzim
20th July 2009, 11:20 AM
I can confirm that my Altera DE1's SDRAM chip is labeled A2V64S40CTP-G6,
I recently got my DE1 board, and mine also has this SDRAM chip.
Other cores have the same problem: they are ported by you or other people to general-purpose boards like the DE1 or DE2, but they lack SD file-loading, preventing them from being really useable for general users. I think souch a generic loader core would be a GREAT step forward, indeeed.
I'm not sure this is doable without a microcontroller or similar logic, I can't really see the Cyclone II reconfigure itself and believe the only source it has is the EPCS4 at powerup.
tcdev
20th July 2009, 01:50 PM
I'm not sure this is doable without a microcontroller or similar logic, I can't really see the Cyclone II reconfigure itself and believe the only source it has is the EPCS4 at powerup.The idea is to have a small HDL core that can load files from the root directory of a FAT-formatted SD/CF card. Not out-of-the-question, but a reasonable amount of work. The HDL back-end isn't so much of a problem, it's the state machine required to read a file that would be challenging.
There's a milestone I'd like to meet first - a HDL back-end and FAT file read implemented by the host processor. Initial targets would be Zet and NeoGeo - both reading ROM data from SD into SDRAM. Obviously Zet would require a small x86 boot-loader whilst NeoGeo requires a 68k version.
My NeoGeo is part-way there atm - a 68K bootloader executes on the NeoGeo CPU to load ROM data into SDRAM from flash on the DE1, then switches into "emulation mode" and resets the CPU.
vanfanel
21st July 2009, 07:34 AM
Great! So there's hope for full SD support in those projects on the DE1...!
I've been looking at the Zet project you mentioned, and it's very interesting, too. Speaker emulation will be a nice feature :)
vanfanel
27th July 2009, 03:33 PM
calling everyone who helped me with the Minimig core on the DE1 with ZENTEL SDRAM chips!
Minimig_de1_12e.zip on http://code.google.com/p/minimig/downloads/list DOES work on newer Altera DE1 boards with ZENTEL SDRAM! Time to play some lemmings... :D
BTW,TCDev, do you think you can use the time constrains in V12e to make V13 compatible with newer DE1, too?
thanks!!
tcdev
29th July 2009, 01:45 AM
BTW,TCDev, do you think you can use the time constrains in V12e to make V13 compatible with newer DE1, too?I'd have to compare the two versions and see what they've changed. If the interface hasn't changed between the two, I'm guessing you'd probably be able to re-compile v13 with the v12 SDRAM controller?!?
vanfanel
29th July 2009, 07:40 AM
Well, I'm not into VHDL, or Verilog... can you please take a look at the and tell me what you think? If you can compile a V13 version with v12e (it has to be 12e) SDRAM controller, that would fix it for sure... I just hope I am not asking too much, TCDev.
Thanks
wheedal
30th July 2009, 06:44 PM
Now that we're through the minimig/SDRAM issue, how does the FPGA64 project look at running on the DE1? I've compiled it, but it seems to want to target to an ECS16 instead of the ECS4 that is stocked on the DE1. I'm not entire sure why it is targeting the larger part.
Anyone familiar with this project?
tcdev
31st July 2009, 02:28 PM
Now that we're through the minimig/SDRAM issue, how does the FPGA64 project look at running on the DE1? I've compiled it, but it seems to want to target to an ECS16 instead of the ECS4 that is stocked on the DE1. I'm not entire sure why it is targeting the larger part.
Anyone familiar with this project?
I'll take a look at it in the next few days. Away from home atm. It may be as simple as selecting ECS4 and re-assembling. Maybe the older DE1 has an EPCS16??? I can't recall.
roglio
2nd August 2009, 08:13 PM
hi tcdev I'm doing something wrong or some projects ported to DE1 are actually broken?
I'm referring to:
\pacedev.net\sw\synth\platform\adventurevision\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\asteroids\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\astrocade\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\bbcmicro\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\colecovision\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\nes\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\tutankhm\de1 - Error: Can't fit design in device
All of them claims problem with the actual pll clock rate:
Error: "Error: Can't fit fan-out of node pll:\BLK_CLOCKING: pll_27_inst|altpll:altpll_component|_clk0 into a single clock region"
I was able instead, to synthesize the followings without any issue:
\pacedev.net\sw\synth\platform\appleii\ii\de1
\pacedev.net\sw\synth\platform\appleii\iiplus\de1
\pacedev.net\sw\synth\platform\c64\de1
\pacedev.net\sw\synth\platform\centiped\de1
\pacedev.net\sw\synth\platform\coco3-becker\de1
\pacedev.net\sw\synth\platform\dkong\de1
\pacedev.net\sw\synth\platform\frogger\de1
\pacedev.net\sw\synth\platform\galaxian\de1
\pacedev.net\sw\synth\platform\invaders-fpgaarcade\de1
\pacedev.net\sw\synth\platform\jumpbug\de1
\pacedev.net\sw\synth\platform\ladybug\cavenger\de 1
\pacedev.net\sw\synth\platform\midway8080\galxwars \de1
\pacedev.net\sw\synth\platform\midway8080\invaders \de1
\pacedev.net\sw\synth\platform\midway8080\invadpt2 \de1
\pacedev.net\sw\synth\platform\midway8080\lrescue\ de1
\pacedev.net\sw\synth\platform\mooncres\de1
\pacedev.net\sw\synth\platform\neogeo\de1
\pacedev.net\sw\synth\platform\pacman\de1
\pacedev.net\sw\synth\platform\pengo\de1
\pacedev.net\sw\synth\platform\scramble\de1
\pacedev.net\sw\synth\platform\scramble-fpgaarcade\de1
\pacedev.net\sw\synth\platform\system09\de1
\pacedev.net\sw\synth\platform\trs80\m1\de1
\pacedev.net\sw\synth\platform\trs80\m3\de1
\pacedev.net\sw\synth\platform\trs80\m4\de1
\pacedev.net\sw\synth\platform\videopac\de1
\pacedev.net\sw\synth\platform\zigzag\de1
\pacedev.net\sw\synth\platform\zx\trs\de1
tcdev
3rd August 2009, 03:03 PM
\pacedev.net\sw\synth\platform\adventurevision\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\asteroids\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\astrocade\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\bbcmicro\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\colecovision\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\nes\de1 - Error: Can't fit design in device
\pacedev.net\sw\synth\platform\tutankhm\de1 - Error: Can't fit design in device
All of them claims problem with the actual pll clock rate:
Error: "Error: Can't fit fan-out of node pll:\BLK_CLOCKING: pll_27_inst|altpll:altpll_component|_clk0 into a single clock region"
You need to refer to:
http://pacedev.net/forums/showthread.php?t=11
http://pacedev.net/forums/showthread.php?t=13
http://pacedev.net/forums/showthread.php?t=12
Adventurevision: (I'll look into it)
Asteroids: Not supported
Astrocade: Not supported
BBCMicro: Not supported
Colecovision: (I'll look into it)
NES: WIP
Tutankham: Not supported
tcdev
3rd August 2009, 03:30 PM
I think there's a problem with DE1 vs other platforms.
It's to do with the clocking and distribution of PLLs in (non-PACE) projects which have their own PLLs instantiated inside them.
tcdev
3rd August 2009, 03:39 PM
This message needs to be at least 10 characters.
roglio
6th August 2009, 05:13 PM
Thank you!
vBulletin® v3.6.8, Copyright ©2000-2010, Jelsoft Enterprises Ltd.