MikeJ has been busy. See here:-

http://www.fpgaarcade.com/

Fantastic!

He has indicated plans to support many other platforms.

Maybe Atari ST is not welcomed round here, but I might try and fly Star Glider I
guess.

And as this is a DE1/ DE2 board have a look at this thread too:-

http://zet.aluzina.org/forums/viewtopic.php?f=4&t=7&start=20

All the best to fellow retro FPGAers everywhere!

Hi Mark, et al.

--- In minimigtg68@yahoogroups.com, Mark McDougall <msmcdoug@...>
wrote:
> AFAIK there are two issues with (DE1) Minimig atm...
>
> (1) SDRAM timing. Some DE1 boards use different SDRAM chips which
aren't
> compatible with the Minimig SDRAM controller out-of-the-box. I also
believe
> that SDRAM problems can be mitigated to some extent via timing
constraints
> in Quartus.

The SDRAM controller files for v12d and v12e have one difference.
The SDRAM controller file for V13 reverts to using the 12d version.

FMAX setting for 13 is markedly different from either 12 versions.

SPIHOST.rom appears identical for 12 versions, but different for V13.
V13 spihost.rom still works for me when using 12d build.

Haven't looked too much at differences between other file versions.

My experience with different versions:

12d works fine, with versions: 7.1, 7.2, 8.0, 8.1 (all FULL versions)
12e builds fine, but always gives me a spihost load timeout error.

13 only works for me when built using 8.0 (sp0/sp1).
Blanks screen when built with 7.x , and I get the RED error screen
when built with 8.1 $%#!!! (I think ozkanocakli had the same problem).

I have the later SDRAM chip : PSC - A2V64S40CTP
I contacted TerASIC support, as the PSC web-site :
http://www.psc.com.tw/ doesn't provide any datasheets.
TerASIC support told me that data for the PSC chips is covered by an
NDA, but they believed the PSC chips were identical to the ISSI chips
(for which data is freely available).

I can only suspect that the chips are ever-so-slightly different, and
the SDRAM controller is running just within tolerance for ISSI chips,
but outside that of the PSC chips.

I did get this:
http://whoyouvotefor.info/altera_sdram.html
SDRAM controller working on my DE1 ok, might try grafting it on to
minimigtg68 over the xmas break.

> (2) Reportedly some SD cards aren't compatible with the Minimig SD
> controller. People have had success with some previously failing SD
cards
> using certain format utilities.

I haven't found an SD card that wouldn't work correctly *AFTER* being
formatted with SD card specific software. I mainly use Toshiba brand.

> Anyone else disagree with this summary?
A fair assessment.

Cheers,
Leslie

ozkanocakli wrote:

> de 1 board shows regular messages
>
> spihost.rom found
> kick.rom loading

AFAIK there are two issues with (DE1) Minimig atm...

(1) SDRAM timing. Some DE1 boards use different SDRAM chips which aren't
compatible with the Minimig SDRAM controller out-of-the-box. I also believe
that SDRAM problems can be mitigated to some extent via timing constraints
in Quartus.

(2) Reportedly some SD cards aren't compatible with the Minimig SD
controller. People have had success with some previously failing SD cards
using certain format utilities.

Personally, I've had mixed success with the various releases of Minimig on
the DE1, DE2 and my own hardware platform, both with .SOF releases and my
own builds with various versions of Quartus.

Unfortunately, until timing issues etc are resolved it's a case of "luck of
the draw" for the DE1/2 builds as far as I can tell. Seems most people have
managed to find a version that works on their hardware. I've been menaing to
take a closer look at the DE1/DE2 problems but haven't found the time.

Unfortunately there's probably not a lot you can do except try the different
builds and different SD cards. Not sure anyone else can help you either?!?

Anyone else disagree with this summary?

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

first of all if I bothered with my posts I am sorry, the point i am
able to send sof file via jtag or pof file with programing mode.

de 1 board shows regular messages

spihost.rom found
kick.rom loading

then black screen turns red like amiga, when gives custom chipset
error, and it resets it self

I can get minimig menu by pressing blue key switch

best regards

ozkanocakli wrote:

> I download latest version 8.1 , when i try to compile it it gives
> several errors

You'll find people are going to be more willing (and able!) to help if you
actually bothered to describe _what_ errors you're getting and the steps you
took to get to that point, rather than just waving your arms and saying "it
doesn't work".

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

type of de1 board does not match with the compiled sof file,


minimig13_de1_quartus81 device is EP2C20F484

when I check my device, it says EP2C15/20


so the file download is not suitable how will i fix it

--- In minimigtg68@yahoogroups.com, Alex Perez <aperez@...> wrote:
>
> Why not recompile it? It's not that hard, and you can do it for free
> with Quartus 8 Web Edition from the Altera site.
>
> On Dec 2, 2008, at 12:56 PM, ozkanocakli wrote:
>
> > I tried every ever pof & sof files, not working, I got minimig
menu
> > but
> > red screen came to dcreen thats mean custom chips error :(
> >
> >
> >
>
I download latest version 8.1 , when i try to compile it it gives
several errors

--- In minimigtg68@yahoogroups.com, Alex Perez <aperez@...> wrote:
>
> Why not recompile it? It's not that hard, and you can do it for free
> with Quartus 8 Web Edition from the Altera site.
>
> On Dec 2, 2008, at 12:56 PM, ozkanocakli wrote:
>
> > I tried every ever pof & sof files, not working, I got minimig
menu
> > but
> > red screen came to dcreen thats mean custom chips error :(
> >
> >
> >
>

I am able to program de1 but I could not get boot screen, I will be
happy if you can help me via msn

I tried every ever pof & sof files, not working, I got minimig menu but
red screen came to dcreen thats mean custom chips error :(

No. But I have turned it to the C-ONE.
http://c64upgra.de/c-one/s_news.htm
http://c64upgra.de/c-one/pics/c1extender_final3.jpg

Regards,
TobiFlex

>
> Hi
>
> Whether I too new user DE2-70.
> have turned out at you port minimig on this board?
>

Hi Mark,
I'm glad that you work with the TG68 Core and that the bug was a
false alarm.

Regards,
TobiFlex
>
> Gary Hoyles wrote:
>
> > You seem to be crying wolf a lot, why not keep your errors to
yourself
> > untill you are !00% sure
>
> It may seem that way, but since I've been working on it pretty
much full
> time for the last 24 hours, I did actually get to the point where,
after a
> few solid hours staring at one particular problem, I thought I
_was_ sure...
> you can't ever be 100% sure either BTW.
>
> It wasn't immediately apparent to me that timing was an issue,
because
> although the system clock rate is reasonably high, the clock
enable is only
> 12MHz. Apparently that is still a problem. By lowering the clock
rate and
> keeping the 12MHz enable, it starts to behave more sanely.
>
> In any case, I stand by the assertion that the address is changing
while AS#
> is asserted, and that _will_ cause grief.
>
> FWIW I also note that there is a new version on opencores that is
not used
> in Minmig, despite the fact that AFAIK Minimig v13 was released
after
> changes were made to the core. I have no idea if the changes
address this issue.
>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical
Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less
resistance!"
>

Hi

Whether I too new user DE2-70.
have turned out at you port minimig on this board?

Gary Hoyles wrote:

> You seem to be crying wolf a lot, why not keep your errors to yourself
> untill you are !00% sure

It may seem that way, but since I've been working on it pretty much full
time for the last 24 hours, I did actually get to the point where, after a
few solid hours staring at one particular problem, I thought I _was_ sure...
you can't ever be 100% sure either BTW.

It wasn't immediately apparent to me that timing was an issue, because
although the system clock rate is reasonably high, the clock enable is only
12MHz. Apparently that is still a problem. By lowering the clock rate and
keeping the 12MHz enable, it starts to behave more sanely.

In any case, I stand by the assertion that the address is changing while AS#
is asserted, and that _will_ cause grief.

FWIW I also note that there is a new version on opencores that is not used
in Minmig, despite the fact that AFAIK Minimig v13 was released after
changes were made to the core. I have no idea if the changes address this issue.

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

Mark McDougall wrote:

> move.l #$0810, a0
> move.w #$1234, d0
> move.w d0,(a0)
>
> ...doesn't work. It outputs #$1234 on *both* address and data_out buses!

***SIGH***

Sorry Tobias, a false alarm. Should've checked the timing report!!!!

All looks OK...

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

Hi Tobias,

2) I *think* I've found an execution bug.

move.w #$1234, d0
move.l #$0810, a0
move.w d0,(a0)

...works correctly. It writes $1234 to address $0810. However...

move.l #$0810, a0
move.w #$1234, d0
move.w d0,(a0)

...doesn't work. It outputs #$1234 on *both* address and data_out buses!

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

Hi Tobias,

OK, I've started a new thread because I think I know a little more about
what is going on. I still reserve the right to a big "DOH" if you point out
something stupid that I've done!! ;)

I should mention that I assert DTACKn immediately after AS# is asserted.

1) The core is changing address whilst AS# is asserted. From what I can
tell, this is a big no-no. It's a problem on writes as you can imagine. I
also appears to be holding AS# for quite a long time - longer than I would
think necessary. My temp fix was to strobe my RAM-write on the leading-edge
cycle of AS# asserted.

2) I *think* I've found an execution bug.

move.w #$1234, d0
move.l #$0810, a0

...works correctly. It writes $1234 to address $0810. However...

move.l #$0810, a0
move.w #$1234, d0

...doesn't work. It outputs #$1234 on *both* address and data_out buses!

I can provide you with signaltap traces if you like.

BTW TG68.vhd v1.01, TG68_fast.vhd v1.04 as from Minimig v13 disto.

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

Mark McDougall wrote:

> OK, my fault for not understanding the 68k timing (haven't done a 68k design
> myself).
> I see that a standard 68000 bus cycle is 4 MPUCLKs long...

My last post was utter trollop.

I'm afraid I don't understand how the TG68 core is supposed to work... :(

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

Mark McDougall wrote:

> Not sure what I don't understand here?!? I tried DTACK# tied low, then tried
> setting DTACK# to AS# in a clocked process. Am I asserting DTACK# too early
> here??? Otherwise, I don't really know how I'm supposed to use the TG68
> core... :(

OK, my fault for not understanding the 68k timing (haven't done a 68k design
myself).

I see that a standard 68000 bus cycle is 4 MPUCLKs long...

Is it true that to run the TG68 core at 12MHz I need a 24MHz clock_ena?

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

Hi Tobias,

I'm attempting to instantiate your TG68 core in a project of mine and am
having trouble getting it to behave as I expect.

I've got a small internal RAM and have written a small test bootstrap ROM
for it. It reads the stack and reset vectors, jumps to the start and appears
to execute the code OK.

BUT...

(1) AS# and RW# are asserted during a memory write instruction, but not
de-asserted before the next instruction fetch starts. So the next
instruction is overwritten while being fetched... I did a quick fix by
pulsing the memory write on leading edge of AS# & RW#...

(2) The memory write drives the correct address and then asserts AS# and
RW#, but the write data doesn't appear on the data (out) bus until approx 10
cycles have elapsed!!! In that time it has fetched and executed a number of
BRA instructions!!!

Not sure what I don't understand here?!? I tried DTACK# tied low, then tried
setting DTACK# to AS# in a clocked process. Am I asserting DTACK# too early
here??? Otherwise, I don't really know how I'm supposed to use the TG68
core... :(

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"

--- In minimigtg68@yahoogroups.com, Alex Perez <aperez@...> wrote:

> I also have successfully rebuilt the POF/SOF using Quartus 8.1 Web
> Edition (it's free) and have a DE2 board with the new PSC SDRAM
chips.
> This has taken care of all issues I've had with regards to stability.
>

Is possible to upload your pof file in files?
i havnt now 8.1 version :(

Sergio and Phil,

On Oct 31, 2008, at 7:03 AM, sergio_stunt wrote:

> --- In minimigtg68@yahoogroups.com, Philip Pemberton <ygroups@...>
> wrote:
> >
> > Hi guys,
> > It seems there's a compatibility issue between the DE1 bitstream
> files and
> > the new-rev DE1 hardware with the PSC SDRAM chips.
> > Basically, I used the precompiled microcode (POF/SOF) files on the
> > filebase. V1.2e booted Kickstart, but kept sporadically rebooting
> >(as in, from  "loading SPIBOOT.ROM"). V1.3 wouldn't even load --
> typically it
> >failed with a
> > solid colour screen and the blue OSD visible, but with no OSD text
> > (or garbage instead of text).
> >
> > I rebuilt V1.3 with the latest Quartus (V8.1 Web Edition) and
> programmed it
> > into my DE1, and it booted fine. Kickstart is up and running, and
> the demo ADF
> > loads OK. Unfortunately I don't have the microphone mod sorted out
> yet, so I
> > can't get Protracker to play any sound, but at least it boots...
> > Last point -- Quartus throws out a lot of timing analysis
> warnings, and a
> > couple relating to the SPI bootROM. These are probably worth
> looking into, but
> > I'm almost certainly not the best person for the job, given that
> I've only
> > been using Quartus for a few days... I did use Xilinx ISE in
> Verilog HDL mode
> > for a good year or two, so maybe that'll help a little :)
> >
> > Thanks,
> > --
> > Phil.
> > ygroups@...
> > http://www.philpem.me.uk/
> >
> what about rebuild all for DE2?
> cos cant use minimig properly at this board due sdram crash issue.
>
I also have successfully rebuilt the POF/SOF using Quartus 8.1 Web
Edition (it's free) and have a DE2 board with the new PSC SDRAM chips.
This has taken care of all issues I've had with regards to stability.

--- In minimigtg68@yahoogroups.com, Philip Pemberton <ygroups@...>
wrote:
>
> Hi guys,
>    It seems there's a compatibility issue between the DE1 bitstream
files and
> the new-rev DE1 hardware with the PSC SDRAM chips.
>
>    Basically, I used the precompiled microcode (POF/SOF) files on
the
> filebase. V1.2e booted Kickstart, but kept sporadically rebooting
(as in, from
> "loading SPIBOOT.ROM"). V1.3 wouldn't even load -- typically it
failed with a
> solid colour screen and the blue OSD visible, but with no OSD text
(or garbage
> instead of text).
>
>    I rebuilt V1.3 with the latest Quartus (V8.1 Web Edition) and
programmed it
> into my DE1, and it booted fine. Kickstart is up and running, and
the demo ADF
> loads OK. Unfortunately I don't have the microphone mod sorted out
yet, so I
> can't get Protracker to play any sound, but at least it boots...
>
>    Last point -- Quartus throws out a lot of timing analysis
warnings, and a
> couple relating to the SPI bootROM. These are probably worth
looking into, but
> I'm almost certainly not the best person for the job, given that
I've only
> been using Quartus for a few days... I did use Xilinx ISE in
Verilog HDL mode
> for a good year or two, so maybe that'll help a little :)
>
> Thanks,
> --
> Phil.
> ygroups@...
> http://www.philpem.me.uk/
>
what about rebuild all for DE2?
cos cant use minimig properly at this board due sdram crash issue.

@philip, I did everything you said still nothing happend,:(

ozkanocakli wrote:
> I tried every combination but no sucess,

That's odd. All I did was downloaded the V1.3 source code, opened the
"minimig_DE1" project with Quartus 8.1 Web Edition, then double-clicked
Compile Design. It does take a long while to compile though...

I've put the POF and SOF files I used in the Filebase on the group's homepage.

Remember: All switches OFF except 9, 3, 2, 1, 0 (which should be ON). Toggle
SW0 to reset Minimig. You need an SD card or Multimedia Card with KICK.ROM,
SPIHOST.ROM and a Workbench disk (ADF file) in the SD card slot. FAT16 format,
folks.

The DE1's mode switch should be set to "RUN", *not* "PROG". Let it run the
Demo code, then reload the FPGA using the Quartus programmer app. It'll start
booting Minimig (you'll see the hex displays change into a track/head counter).

I suspect Minimig/tg68 is sending something to the serial port as well,
because I saw the TXD LED light. No idea what it's sending though, debug info
perhaps?

--
Phil.
ygroups@...
http://www.philpem.me.uk/

I am somewhat confused by this. According to the datasheet, the
IS42S8800 is organized as 2Mx8x4, whereas the PSC chip is 1Mx16x4..

--- In minimigtg68@yahoogroups.com, "Javier Ruiz" <soyandroid@...> wrote:
>
> Dear Mark
>
> Now, i now for sure that the problem is in the SDRAM memory that
cames with the news DE1 and DE2 boards.
>
> In the old boards they mounted the IS42S8800 from ISI.
>
> In the new boards they are mounting the A2V64S40CTP from PSC (Power
Chip Semiconductors)
>
> Now i have two DE1 boards, one with the old IS42S8800 SDRAM that run
with all the versions of Minimig and never crashes and one new DE1
with the SDRAM from PSC, this board only runs the precompiled versions 12.
>
> With Quartus 8.0 SP1, i succesfully syntetized the version 13 for
this new DE1 board, it runs, but hangs very often by problems of
memory corruption.
>
> Best Regards
> Xavier Ruiz
>
>
>   ----- Original Message -----
>   From: Mark McDougall
>   To: minimigtg68@yahoogroups.com
>   Sent: Wednesday, September 24, 2008 8:52 AM
>   Subject: [minimigtg68] DE2 & V13
>
>
>   Hi all,
>
>   Been having some problems with v13 and thought I'd see if anyone
else has
>   had the same experience as me!?!
>
>   1st of all, I've downloaded the new v13 source and have built a
project for
>   my own hardware, which has an EP2C35. I've copied the new
spihost.rom to my
>   SD card and can boot Minimig and subsequent ADF images from the SD
card no
>   problems.
>
>   However, if I program a DE2 with the pre-compiled .SOF file from
v13 and use
>   the same SD card as above, I get nothing. Nothing at all! No video
sync, no
>   LED light on reset - absolutely dead.
>
>   Ditto if I compile the DE2 project from the v13 sources.
>
>   Now, I have an old project from when I ported the DE1 port to the
DE2,
>   before Tobias released a DE2 project. I replaced the top-level
schematics in
>   this design with VHDL equivalents and a DE2 wrapper around the DE1
>   top-level. If I build this project - I get video sync and the OSD
which says
>   that SPIHOST is found and booting. However, it never finishes
booting and
>   often displays the OSD again - looping ad-infinitum. If I try
resetting the
>   board with SW0, I get various results such as green screen, yellow
screen,
>   grey screen, black screen - with and without the OSD message.
>
>   Time to look at timing methinks...
>
>   Regards,
>
>   --
>   | Mark McDougall | "Electrical Engineers do it
>   | <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
>

I tried every combination but no sucess,

--- In minimigtg68@yahoogroups.com, Philip Pemberton <ygroups@...>
wrote:
>
> Hi guys,
>    It seems there's a compatibility issue between the DE1 bitstream
files and
> the new-rev DE1 hardware with the PSC SDRAM chips.
>
>    Basically, I used the precompiled microcode (POF/SOF) files on
the
> filebase. V1.2e booted Kickstart, but kept sporadically rebooting
(as in, from
> "loading SPIBOOT.ROM"). V1.3 wouldn't even load -- typically it
failed with a
> solid colour screen and the blue OSD visible, but with no OSD text
(or garbage
> instead of text).
>
>    I rebuilt V1.3 with the latest Quartus (V8.1 Web Edition) and
programmed it
> into my DE1, and it booted fine. Kickstart is up and running, and
the demo ADF
> loads OK. Unfortunately I don't have the microphone mod sorted out
yet, so I
> can't get Protracker to play any sound, but at least it boots...
>
>    Last point -- Quartus throws out a lot of timing analysis
warnings, and a
> couple relating to the SPI bootROM. These are probably worth
looking into, but
> I'm almost certainly not the best person for the job, given that
I've only
> been using Quartus for a few days... I did use Xilinx ISE in
Verilog HDL mode
> for a good year or two, so maybe that'll help a little :)
>
> Thanks,
> --
> Phil.
> ygroups@...
> http://www.philpem.me.uk/
>
http://whoyouvotefor.info/altera_sdram.html
here is info about sdram controller for new chip
i havnt time too look by myself but maybe usefull for someone.
regards.