cong. tobiflexx, when you release files :)

--- In minimigtg68@yahoogroups.com, "tobiflexx" <t.gubener@...> wrote:
>
> Hello,
> now i have finesh a new core with the latest minimig source from 270409 for
the DE2 Board. There are two 68K IPs inside. The core need 59 EABs. No Problem
for the DE2 FPGA. But the DE1 FPGA has only 52 EABs :-(
> If i disasable the hires vr_filter from amber.v the core needs 54 EABs.
Damned!!!
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> Perhapes I can use the SRAM for the floppy FIFO. That will free 32 EABs.
> I will try it....
>
>
> Best
> TobiFlex
> .
>

Hello,
now i have finesh a new core with the latest minimig source from 270409 for the
DE2 Board. There are two 68K IPs inside. The core need 59 EABs. No Problem for
the DE2 FPGA. But the DE1 FPGA has only 52 EABs :-(
If i disasable the hires vr_filter from amber.v the core needs 54 EABs.
Damned!!!
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Perhapes I can use the SRAM for the floppy FIFO. That will free 32 EABs.
I will try it....


Best
TobiFlex
.

Hi and welcome here!
The V12e and V13 are old versions. Currently I'm working on a new Core Version
for the DE1, DE2 and C-One with the latest minimig source YQ090421. I'm also
change the SDRAM module to a 3-3-3 Timing. I hope this will solve the problems
with different SDRAM chips.
The C-One version will have HD support with a real IDE Connector.
The DE1 and DE2 version will don't have HD Support until the ARM Code with HD
image support is not available.

best
TobiFlex

> Hello there
>
> I'm new to this group (and FPGA in general) but this Minimig core is the best
thing has ever happened to the Altera DE1 board!
>
> I had to try a lot of versions before I found out that ONLY version 12e is
compatible with the newer Altera DE1 board using ZENTEL-labeled SDRAM chips.
Version 13 is incompatible with those new boards.
>
> So I wanted to ask:
>
> 1) What are the advantages/differences between V12e and V13? Is V12e supposed
to have disk write support?
>
> 2) If SDRAM is the problem, can you please compile V13 POF files with the V12e
SDRAM controller? Or can you provide basic instructions so I can do it myself?
>
> Thanks, Tobiflexx and the rest!
>

Hello there

I'm new to this group (and FPGA in general) but this Minimig core is the best
thing has ever happened to the Altera DE1 board!

I had to try a lot of versions before I found out that ONLY version 12e is
compatible with the newer Altera DE1 board using ZENTEL-labeled SDRAM chips.
Version 13 is incompatible with those new boards.

So I wanted to ask:

1) What are the advantages/differences between V12e and V13? Is V12e supposed to
have disk write support?

2) If SDRAM is the problem, can you please compile V13 POF files with the V12e
SDRAM controller? Or can you provide basic instructions so I can do it myself?

Thanks, Tobiflexx and the rest!

Hello,
look into the "c.bat" file. There you can see that I use the SDCC.
After installing SDCC on your system remove or rename  the standard "crt0.o"
from the "SDCC\lib\Z80" Folder. Bigrom use his own crt0.asm!

TobiFlex

>
> I need to know the development tools used to program the TG80 so I can modify
the bigrom for minimigtg68 please ?
>
> I am looking to load the KS into the flash to enable selecting kiskstart using
switches.
>
> Enya.
>

I need to know the development tools used to program the TG80 so I can modify
the bigrom for minimigtg68 please ?

I am looking to load the KS into the flash to enable selecting kiskstart using
switches.

Enya.

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 :(