Hello, Arda!

> One more question Tobias, the slow memory in minimig, can it be made Fast
> ram ? like 68k core have direct access to it ?
> here is a project for 8 mb fast ram for amiga 600. (maybe you already know)
> http://lvd.nedopc.com/Projects/a600_8mb/index.html
> it has verilog source for autoconfiguring 8 mb ram. If you can use this in
> DE1 it would be great ! (even only 4 mb)

As an author of that, I can say:
This verilog source has nothing to do with actual autoconfiguring RAM
in de1 minimig, if it is to be implemented.
Just because there will be nothing similar: no similar CPU i-face, no
similar DRAMs, etc.
Autoconfig by itself is a simple thing.

Major objective about adding 8mb of RAM is the SDRAM size of DE1. It
is only 8Mb for everything.

> One more question Tobias, the slow memory in minimig, can it be made Fast
> ram ? like 68k core have direct access to it ?
>
> here is a project for 8 mb fast ram for amiga 600. (maybe you already know)
>
> http://lvd.nedopc.com/Projects/a600_8mb/index.html
>
> it has verilog source for autoconfiguring 8 mb ram. If you can use this in
> DE1 it would be great ! (even only 4 mb)

I have done a autoconfig RAM of 8MB for the C-One Minimig Core. Autoconfig RAM
is no problem. Also a Turbomode should not bee a Problem. But why I should do
this?
English and no Feedback are Problems for me.

Best
TobiFlex

>Does anyone know how and if its possible to select a faster Cpu >Clock ?

In the current core is no turbomode available. Let me time to do this.

> I wonder if the 900 mb hdf is messing with the IDE functionality ? I'll
> erase it and try again with just the 40 mb hdf.

Not all HDF Files will work with the Minimig. Format the HDF Image with the
Minimig and it will working.

>I had a spihost.rom file from a previous attempt which I didn't >update. does
it need to be updated ?

The spihost.rom is nedded for the Z80. I have change the hostcpu from z80 to the
TG68 and now you need the menue.sys. Please delete the spihost.rom.

@gaula92: What about your DE1 Board? Can you use the new core?

Best
TobiFlex

Did you enabled the A600 Ide in the OSD ?
The HDF Support works for me but if i use it i have somtimes the same
audio problems as you described.
If A600 IDE disabled then audio is o.k.
Does anyone know how and if its possible to select a faster Cpu Clock ?

regards Dirk


co_ze schrieb:
> Hello Everyone,
> first of all, let me thank Tobias and everyone involved in the development of
this project. I haven't been able to get the previous versions work on my DE1,
but the last update works !
> I have some questions as I don't have much knowledge about the tg68k minimig.
>
> 1- I have only two audio channels audible on my de1. I can hear the other two
if I toggle sw8. Is it possible to hear all channels by some mod ?
> 2- The hardfile support doesn't work for me. I have one 40 mb hdf for
workbench, and another 900 mb one for programs/data. What may be the problem ? I
just downloaded the latest package and copied the menue.sys from there to SD
card. I had a spihost.rom file from a previous attempt which I didn't update.
does it need to be updated  ? I tried different kick.roms which didn't help. I
boot from a workbench and load sysinfo which says scsi.device isn't there.
>
> many thanks,
> CoZe
>
>
>
> --- In minimigtg68@yahoogroups.com, "tobiflexx" <t.gubener@...> wrote:
>
>> Hello group,
>> after hard work ;-) and many changes on hard and software I can send you a
new Version of the DE1 Minimig!
>> Now you can use 4 ADF Images and 2 HDF Images.
>> I have also change some things in the clock domains.
>> Now I use the good old DICE on AMIGA to compile the "menue.sys"
>> To compile the ARM replacement source type "execute make.txt" on a AMIGA with
installed DICE.
>> The ActionReplay3 is not tested on the version. Remember the TG68 is missing
the single step traps. I am afraid the AR3 don't work correct.
>>
>>
>> Best
>> TobiFlex
>>
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Hello Everyone,
first of all, let me thank Tobias and everyone involved in the development of
this project. I haven't been able to get the previous versions work on my DE1,
but the last update works !
I have some questions as I don't have much knowledge about the tg68k minimig.

1- I have only two audio channels audible on my de1. I can hear the other two if
I toggle sw8. Is it possible to hear all channels by some mod ?
2- The hardfile support doesn't work for me. I have one 40 mb hdf for workbench,
and another 900 mb one for programs/data. What may be the problem ? I just
downloaded the latest package and copied the menue.sys from there to SD card. I
had a spihost.rom file from a previous attempt which I didn't update. does it
need to be updated  ? I tried different kick.roms which didn't help. I boot from
a workbench and load sysinfo which says scsi.device isn't there.

many thanks,
CoZe



--- In minimigtg68@yahoogroups.com, "tobiflexx" <t.gubener@...> wrote:
>
> Hello group,
> after hard work ;-) and many changes on hard and software I can send you a new
Version of the DE1 Minimig!
> Now you can use 4 ADF Images and 2 HDF Images.
> I have also change some things in the clock domains.
> Now I use the good old DICE on AMIGA to compile the "menue.sys"
> To compile the ARM replacement source type "execute make.txt" on a AMIGA with
installed DICE.
> The ActionReplay3 is not tested on the version. Remember the TG68 is missing
the single step traps. I am afraid the AR3 don't work correct.
>
>
> Best
> TobiFlex
>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the minimigtg68
group.

   File        : /minimig090911_DE2_V21.zip
   Uploaded by : tobiflexx <t.gubener@...>
   Description : Configfiles for DE2 and menue.sys for SD Card

You can access this file at the URL:
http://groups.yahoo.com/group/minimigtg68/files/minimig090911_DE2_V21.zip

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/general.htmlfiles

Regards,

tobiflexx <t.gubener@...>

Hello group,
after hard work ;-) and many changes on hard and software I can send you a new
Version of the DE1 Minimig!
Now you can use 4 ADF Images and 2 HDF Images.
I have also change some things in the clock domains.
Now I use the good old DICE on AMIGA to compile the "menue.sys"
To compile the ARM replacement source type "execute make.txt" on a AMIGA with
installed DICE.
The ActionReplay3 is not tested on the version. Remember the TG68 is missing the
single step traps. I am afraid the AR3 don't work correct.


Best
TobiFlex

----- Original Message -----

From: minimigtg68@yahoogroups.com

To: minimigtg68@yahoogroups.com

Sent: Thursday, October 22, 2009 8:58 PM

Subject: [minimigtg68] New file uploaded to minimigtg68

 

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the minimigtg68
group.

File : /minimig090911_DE1_V21.zip
Uploaded by : tobiflexx <t.gubener@gmx.de>
Description : Configfiles for DE1 and menue.sys for SD Card

You can access this file at the URL:
http://groups.yahoo.com/group/minimigtg68/files/minimig090911_DE1_V21.zip

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/general.htmlfiles

Regards,

tobiflexx <t.gubener@gmx.de>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the minimigtg68
group.

   File        : /minimig090911_DE1_V21.zip
   Uploaded by : tobiflexx <t.gubener@...>
   Description : Configfiles for DE1 and menue.sys for SD Card

You can access this file at the URL:
http://groups.yahoo.com/group/minimigtg68/files/minimig090911_DE1_V21.zip

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/general.htmlfiles

Regards,

tobiflexx <t.gubener@...>

Hello!

> thanks for this tip. It might be useful on the C64 side if I am a little bit
short with LEs.
> For the boot menu, the TG68 is mandatory since I want to access more than 64KB
of RAM.

What's for? I didn't see any sources but nevertheless... :)

--- In minimigtg68@yahoogroups.com, Vadim Akimov <lvd.mhm@...> wrote:
>
> Hello!
>
> You should try openmsp430 core from opencores.org.
> It is quite powerful totally 16bit core with 1 clock per memory access
> (including instruction read and data read) speed. It resembles a bit
> pdp-11 architecture, but with 16 16-bit general-purpose registers.It
> has unified 2-address architecture where both source and destination
> can be memory word or register.
>
> It is much smaller than tg68 (1600-1700 LE without debug capabilities)
> and easily approaches 35 MHz (which is 35MIPS for register-register
> ops) in cyclone II.
>
> mspgcc is quite good compiler for that. At least, it is far better than
avr-gcc.
>

Hello Vadim,

thanks for this tip. It might be useful on the C64 side if I am a little bit
short with LEs.
For the boot menu, the TG68 is mandatory since I want to access more than 64KB
of RAM.

Regards,

Frederic

Hello!

> I have tried the NIOS II with FatFS, but I was quite disappointed by the code
density. I do not want to eat up all my block RAMs with a boot ROM.
> I also thought about the AVR since there is an AVR soft core and a 1541 clone
that is AVR based.
> But finally, the TG68 seems to be a good solution. Plus, I have a specific SPI
core that takes care of some of the particularities of the SPI protocol for
SD-Cards, like automatically sending of zeroes when I just want to read the
SD-Card.
> For the boot ROM, I think I will use the cache with a pre-initialized tag and
data content at startup so it can act as a boot ROM.

You should try openmsp430 core from opencores.org.
It is quite powerful totally 16bit core with 1 clock per memory access
(including instruction read and data read) speed. It resembles a bit
pdp-11 architecture, but with 16 16-bit general-purpose registers.It
has unified 2-address architecture where both source and destination
can be memory word or register.

It is much smaller than tg68 (1600-1700 LE without debug capabilities)
and easily approaches 35 MHz (which is 35MIPS for register-register
ops) in cyclone II.

mspgcc is quite good compiler for that. At least, it is far better than avr-gcc.

--- In minimigtg68@yahoogroups.com, Mark McDougall <msmcdoug@...> wrote:
>
> requin_frederic2 wrote:
>
> > How is it going down under ?
>
> Well, Winter refuses to give way which is annoying, but otherwise OK!
>
> > I plan to use it on the boot menu of the MCC board (see:
> > www.arcaderetrogaming.com), on the Amiga core and as the sd-card/floppy
> > controller of the C64 core. It is a lot easier to manage FAT filesystem
> > with a 68000 than with a 6510 :-).
>
> I've been meaning to make a final decision on how to implement floppy media
> emulation (via FAT filesystem) on PACE projects in general. I've got the
> 1541 emulation for C64 and WD179X emulation for the TRS-80 (and perhaps a
> few other systems) waiting for a FAT filesystem back-end. Trouble is,
> there's a number of PACE targets with differing capabilities and I can't
> decide how best to implement floppy support. I'm leaning towards an ARM
> micro with SD via a SPI interface... though I would actually prefer the
> emulation to be on-chip!
>
> > Now, I am working on a unified cache implementation for TG68. I think I
> > can get a 8KB 4-way associative cache (21.5 MHz on the CPU side, 86 MHz
> > on the SDRAM side). I am wondering if I should keep the two clocks or if
> > I can clock enable the TG68 with the 86 MHz. What do you think ?
>
> I tried clock-enabling the TG68 at 12.5MHz with a 100MHz clock some time ago
> without success. In theory I shouldn't have had a problem but it simply
> didn't run correctly. I dropped it down to 50MHz and it seems good so far.
>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>

Hello,

I have tried the NIOS II with FatFS, but I was quite disappointed by the code
density. I do not want to eat up all my block RAMs with a boot ROM.
I also thought about the AVR since there is an AVR soft core and a 1541 clone
that is AVR based.
But finally, the TG68 seems to be a good solution. Plus, I have a specific SPI
core that takes care of some of the particularities of the SPI protocol for
SD-Cards, like automatically sending of zeroes when I just want to read the
SD-Card.
For the boot ROM, I think I will use the cache with a pre-initialized tag and
data content at startup so it can act as a boot ROM.

Regards,

Frederic

--- In minimigtg68@yahoogroups.com, Mark McDougall <msmcdoug@...> wrote:
>
> requin_frederic2 wrote:
>
> > I am wondering if I should keep the two clocks or if
> > I can clock enable the TG68 with the 86 MHz. What do you think ?
>
> I'm pretty sure that clocks from the same PLL that are multiples of one
> another are guaranteed to be phase-aligned!?! So you could run a slower
> clock and treat them as synchronous I believe. I haven't tried this though.
>

I actually do that on some of my designs !
With the PLL along with the clocks, I generate a clock that is a short pulse
centered on the instant where all the rising edges are together.

Then I use this short pulse to reset a shift register that tells me on what
clock period I am in.

example:

bus_clk : 21.5 MHz
ram_clk : 86 MHz (4 x bus_clk)
seq_rst : 1/6 of bus_clk (~3.5 MHz), 350 deg phase, 6% duty cycle.

HTML output from Quartus II Megawizard is very useful for tuning the pulse.


In VHDL :
   SIGNAL rclk_cyc : STD_LOGIC_VECT(3 DOWNTO 0);

   PROCESS(reset_n, ram_clk, seq_rst)
   BEGIN
     IF (reset_n = '0') THEN
       rclk_cyc <= "0000";
     ELSIF (rising_edge(ram_clk)) THEN
       IF (seq_rst = '1') THEN
         rclk_cyc <= "0001";
       ELSE
         rclk_cyc <= rclk_cyc(2 DOWNTO 0) & rclk_cyc(3);
       END IF;
     END IF;
   END PROCESS;

You can safely read registered signals from clock domain "bus_clk" in clock
domain "ram_clk" when : rclk_cyc(0/1/2) = '1'. For rclk_cyc(3) = '1', you can't.
You have to delay the signal first.

I really prefer this method than the gated clock method I find so often in open
source designs.

Regards,

Frederic

requin_frederic2 wrote:

> I am wondering if I should keep the two clocks or if
> I can clock enable the TG68 with the 86 MHz. What do you think ?

I'm pretty sure that clocks from the same PLL that are multiples of one
another are guaranteed to be phase-aligned!?! So you could run a slower
clock and treat them as synchronous I believe. I haven't tried this though.

Regards,

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

requin_frederic2 wrote:

> How is it going down under ?

Well, Winter refuses to give way which is annoying, but otherwise OK!

> I plan to use it on the boot menu of the MCC board (see:
> www.arcaderetrogaming.com), on the Amiga core and as the sd-card/floppy
> controller of the C64 core. It is a lot easier to manage FAT filesystem
> with a 68000 than with a 6510 :-).

I've been meaning to make a final decision on how to implement floppy media
emulation (via FAT filesystem) on PACE projects in general. I've got the
1541 emulation for C64 and WD179X emulation for the TRS-80 (and perhaps a
few other systems) waiting for a FAT filesystem back-end. Trouble is,
there's a number of PACE targets with differing capabilities and I can't
decide how best to implement floppy support. I'm leaning towards an ARM
micro with SD via a SPI interface... though I would actually prefer the
emulation to be on-chip!

> Now, I am working on a unified cache implementation for TG68. I think I
> can get a 8KB 4-way associative cache (21.5 MHz on the CPU side, 86 MHz
> on the SDRAM side). I am wondering if I should keep the two clocks or if
> I can clock enable the TG68 with the 86 MHz. What do you think ?

I tried clock-enabling the TG68 at 12.5MHz with a 100MHz clock some time ago
without success. In theory I shouldn't have had a problem but it simply
didn't run correctly. I dropped it down to 50MHz and it seems good so far.

Regards,

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

requin_frederic2 wrote:

> I have read your thread about the NeoGeo on Pacedev. Very interresting.
> You said the sprite engine was causing you problems. How come ?

Mostly because I've been procrastinating in putting it off! :( I can boot
Joy Joy Kid and it's running happily - I can even start a game. But as you
probably know, the NeoGeo is really one big sprite engine, and tilemaps are
seldom used, so you don't get to see a lot on the screen other than the score...

I do need to bite the bullet and get a start on it. I have already added
some dual-port sprite memory and have confirmed that the sprite registers
are updated while the game is running...

It's probably no coincidence that my NES implementation is at pretty much
the same point. :(

> FYI, the 1943 sprite engine I wrote can handle 128 sprites and the whole
> graphics chipset takes less than 3000 LEs. Of course, it is not
> implemented like an Amiga or C64 sprite engine. The sprites are rendered
> sequentially, one line ahead, in a line buffer.

Nice! The NeoGeo will work exactly the same way. In fact, if you look at the
NeoGeo reverse-engineering documents and the timings it's pretty clear that
the actual hardware does exactly that.

It's one of those things that is probably not _too_ difficult once you get a
start on it. What has deterred me a little is the code-build-test cycle
times with the TG68 core and everything else... I need to come up with a way
of testing the sprite engine without a CPU core or SDRAM controller. Again,
not difficult, just need to do it.

Regards,

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

Hello Mark,

I have read your thread about the NeoGeo on Pacedev. Very interresting.
You said the sprite engine was causing you problems. How come ?

FYI, the 1943 sprite engine I wrote can handle 128 sprites and the whole
graphics chipset takes less than 3000 LEs.
Of course, it is not implemented like an Amiga or C64 sprite engine.
The sprites are rendered sequentially, one line ahead, in a line buffer.

Regards,

Frederic

--- In minimigtg68@yahoogroups.com, Mark McDougall <msmcdoug@...> wrote:
>
> requin_frederic2 wrote:
>
> > For those who wants to play with TG68:
> > * "state_out" signal : 00: fetch cycles, 01: decode cycles, 10: data read
cycles, 11: data write cycles.
> > * "decodeOPC" : seems to be equal to 1 only when state_out = 01.
> > * "reset", "UDS", "LDS" and "IPL" are low active.
> > * "wr" signal : 0=write, 1=read.
>
> I'm using TG68 for NeoGeo. The system clock is 25MHz, though the TG68 core
> is clock-enabled at 12.5MHz on a Cyclone II C6 (TerASIC DE1).
>
> I generate a 25MHz write pulse from the write signal, and need to stretch
> DTACK in general. It's (also) bridged to the opencores yadmc (wishbone).
>
> Fun stuff. What are you planning to use it for?
>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>

Hello Mark,

How is it going down under ?

I plan to use it on the boot menu of the MCC board (see:
www.arcaderetrogaming.com), on the Amiga core and as the sd-card/floppy
controller of the C64 core. It is a lot easier to manage FAT filesystem with a
68000 than with a 6510 :-).

Now, I am working on a unified cache implementation for TG68.
I think I can get a 8KB 4-way associative cache (21.5 MHz on the CPU side, 86
MHz on the SDRAM side). I am wondering if I should keep the two clocks or if I
can clock enable the TG68 with the 86 MHz.
What do you think ?

Frederic

--- In minimigtg68@yahoogroups.com, Mark McDougall <msmcdoug@...> wrote:
>
> requin_frederic2 wrote:
>
> > For those who wants to play with TG68:
> > * "state_out" signal : 00: fetch cycles, 01: decode cycles, 10: data read
cycles, 11: data write cycles.
> > * "decodeOPC" : seems to be equal to 1 only when state_out = 01.
> > * "reset", "UDS", "LDS" and "IPL" are low active.
> > * "wr" signal : 0=write, 1=read.
>
> I'm using TG68 for NeoGeo. The system clock is 25MHz, though the TG68 core
> is clock-enabled at 12.5MHz on a Cyclone II C6 (TerASIC DE1).
>
> I generate a 25MHz write pulse from the write signal, and need to stretch
> DTACK in general. It's (also) bridged to the opencores yadmc (wishbone).
>
> Fun stuff. What are you planning to use it for?
>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>

requin_frederic2 wrote:

> For those who wants to play with TG68:
> * "state_out" signal : 00: fetch cycles, 01: decode cycles, 10: data read
cycles, 11: data write cycles.
> * "decodeOPC" : seems to be equal to 1 only when state_out = 01.
> * "reset", "UDS", "LDS" and "IPL" are low active.
> * "wr" signal : 0=write, 1=read.

I'm using TG68 for NeoGeo. The system clock is 25MHz, though the TG68 core
is clock-enabled at 12.5MHz on a Cyclone II C6 (TerASIC DE1).

I generate a 25MHz write pulse from the write signal, and need to stretch
DTACK in general. It's (also) bridged to the opencores yadmc (wishbone).

Fun stuff. What are you planning to use it for?

Regards,

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

Ok, I found the problem.
I slightly changed the AS# generation and the address decoder logic.
Now, everything runs fine.

On a cyclone III speed grade C8, I can clock the TG68 at 25 MHz.
I have decided to clock it at 21 MHz. Anyway, the core is very fast : wothout
the top level that stretches the memory access to 4 cycles, it only needs 2
cycles for a 1-word instruction and 3 cycles for a 2-word instruction. Overall
it is 9 times faster than a 7 MHz 68000.

For those who wants to play with TG68:
* "state_out" signal : 00: fetch cycles, 01: decode cycles, 10: data read
cycles, 11: data write cycles.
* "decodeOPC" : seems to be equal to 1 only when state_out = 01.
* "reset", "UDS", "LDS" and "IPL" are low active.
* "wr" signal : 0=write, 1=read.

If you want to use only tg68_fast, here is how I do it myself:

clk_ena <= '1' WHEN (clk_ena_in = '1') AND ((dtack_n = '0') OR (state_out =
"01") OR (decodeOPC = '1')) ELSE '0';
as_n <= UDS AND LDS;

I clock the memory accesses on the falling edges and TG68 on the rising edges.

Regards,

Frederic

--- In minimigtg68@yahoogroups.com, "requin_frederic2" <requin_frederic2@...>
wrote:
>
> Hello Tobias,
>
> I have a test program with a LEA $2000.W,A0, I had to replace it by LEA
$00002000.L,A0 to make it work on TG68.
>
> Any thoughts ?
>
> Regards
>
> Frederic
>

Hello Tobias,

I have a test program with a LEA $2000.W,A0, I had to replace it by LEA
$00002000.L,A0 to make it work on TG68.

Any thoughts ?

Regards

Frederic

spartan3wiz wrote:
>
> To get the TG68K working with BlockRAM should be quite easy I hope. You can,
for example,
  >use the CoreGen and a COE-file to get a simple tool-chain.
I would prefer to have my own tool chain for that. There are numerous
examples on opencores,
which take the gnu elf file, and make simply an ram_image.vhdl out of
it. If one does it right,
you can use the same file on altera and xilinx.
And because of the manufacturers tools, I have a hard time to figure out
where all the connections are going. Had to install quartus to see the
connections between the modules. Would prefer plain vhdl ...

> Which board are you using? 200K/1000K Starter Kit?
I made my own, has up to 16 mbyte of sram on it.

> If you get a good working version that can execute some 68K-binary
  >and output some to UART please share. That would also be nice to try.
  > 68K-assembler rules!


> Actually I seem to have gotten a simple DDR-controller to work with my 1600E!
  >It's not my work originally, I've just made small changes to a core
newly added to opencores.com at:
> http://opencores.org/project,sdram_controller

This one is more along my thinking.

> The core was made to work with the 500E and I managed to get i going
  >with the 1600E as well. Both 8-bit and 16-bit read seem to work at
  >100Mhz (and probably higher), but I reckon I need 32-bit for Minimig
  >in the end. This would demand 2 16-bit read after each other at
  >double the clock which is doable.

So, what keeps you from getting Minimig on this board ?
;-)

> Somebody else tried this with 500E/1600E that can feedback?

Didn't have the time yet, but this core looks very promising.

CHeers

----- Original Message -----

From: spartan3wiz

To: minimigtg68@yahoogroups.com

Sent: Monday, October 05, 2009 9:00 PM

Subject: [minimigtg68] Re: tg68 on xilinx boards

 

> I have SRAM on my board at the moment, so not to eager to have the DDR
> working. I'm more interested at the moment with having a small tg68
> running on xilinx for testing. So just a XILINX ISE project which has
> the cpu in it, uses internal block ram, and probably outputs something
> on an UART. My focus is really more on the cpu part of the project.
> ('00, '20, '30 etc.)
>

To get the TG68K working with BlockRAM should be quite easy I hope. You can, for example, use the CoreGen and a COE-file to get a simple tool-chain.

And also SRAM if you already have a nice state-machine for the memory access. But then you would of course need to init the memory through UART or other init procedure.

Which board are you using? 200K/1000K Starter Kit? If you get a good working version that can execute some 68K-binary and output some to UART please share. That would also be nice to try. 68K-assembler rules!

Actually I seem to have gotten a simple DDR-controller to work with my 1600E! It's not my work originally, I've just made small changes to a core newly added to opencores.com at:
http://opencores.org/project,sdram_controller

The core was made to work with the 500E and I managed to get i going with the 1600E as well. Both 8-bit and 16-bit read seem to work at 100Mhz (and probably higher), but I reckon I need 32-bit for Minimig in the end. This would demand 2 16-bit read after each other at double the clock which is doable.

Somebody else tried this with 500E/1600E that can feedback?

> I have SRAM on my board at the moment, so not to eager to have the DDR
> working. I'm more interested at the moment with having a small tg68
> running on xilinx for testing. So just a XILINX ISE project which has
> the cpu in it, uses internal block ram, and probably outputs something
> on an UART. My focus is really more on the cpu part of the project.
> ('00, '20, '30 etc.)
>

To get the TG68K working with BlockRAM should be quite easy I hope. You can, for
example, use the CoreGen and a COE-file to get a simple tool-chain.

And also SRAM if you already have a nice state-machine for the memory access.
But then you would of course need to init the memory through UART or other init
procedure.

Which board are you using? 200K/1000K Starter Kit? If you get a good working
version that can execute some 68K-binary and output some to UART please share.
That would also be nice to try. 68K-assembler rules!

Actually I seem to have gotten a simple DDR-controller to work with my 1600E!
It's not my work originally, I've just made small changes to a core newly added
to opencores.com at:
http://opencores.org/project,sdram_controller

The core was made to work with the 500E and I managed to get i going with the
1600E as well. Both 8-bit and 16-bit read seem to work at 100Mhz (and probably
higher), but I reckon I need 32-bit for Minimig in the end. This would demand 2
16-bit read after each other at double the clock which is doable.

Somebody else tried this with 500E/1600E that can feedback?

spartan3wiz wrote:
> I second that! And when you say Xilinx-boards I reckon you mean for example:
> - Spartan 3E Starter Board 1600E
That's a good choice.

> MinimigTG68 on Xilinx boards:
> I would be able to put hours into such a project but I would probably also
need help .
  >The biggest hurdle if I understand correctly is to get the
DDR-controller to work with the Minimig.

Yes.
> And this is NOT my cup of tea for now.. There are working DDR-controllers out
there, but there always
  >seem to give some problems/inconsistencies when tried out.. somebody
who knows otherwise?
I have SRAM on my board at the moment, so not to eager to have the DDR
working. I'm more interested at the moment with having a small tg68
running on xilinx for testing. So just a XILINX ISE project which has
the cpu in it, uses internal block ram, and probably outputs something
on an UART. My focus is really more on the cpu part of the project.
('00, '20, '30 etc.)

> Any more interested parties to this goal? There should be many people out
there who would
  >like to see the Amiga come to life on their boards I think.

Silent Majority ;-)

> In the past I've fiddled around with many small projects for example a working
FPGA-64 with my setup
  >including a working SID-chip in it! But the Amiga would be even better!

Nice little machines they are !

Cheers

I second that! And when you say Xilinx-boards I reckon you mean for example:
- Spartan 3E Starter Board 500E
- Spartan 3E Starter Board 1600E

of which at least the first is quite widely used among hobbyists.

Does the MinimigTG68 fit into a 500E, I'm not sure today..

The old: Spartan-3 Starter Kit (200K or 1000K) with it's 1 MB SRAM will probably
not be a good target I suppose.

I own one Spartan-3 Starter Kit 200K and one Spartan 3E Starter Board 1600E
which both work very well for lots of projects. I also have developed an
ArcadeExtender board which fits both and others (with some additional simple
soldering) and gives a good platform for Minimig and other similar projects and
makes the Xilinx boards more look/work like the Altera's with ALL their nice
connectors.

Arcade Extender
4096 colors, Simple Stereo Sound Output, 1 Digital Joystick (as used in
64/Amiga/ST), Extra PS/2 to host both Mouse/Keyboard, SD-Card SPI interface,
MIDI-in. I have 8 boards unpopulated and are willing to let them go for the
price they cost me to get done.. post me privately if interested. Without such a
board I think you need to extend the Xilinx-boards a lot to get something nice
out of it! Of course if you go for simple solution the FPGAArcade solder fix for
the VGA will al least fix Video in a very simple and cheap way
(http://www.fpgaarcade.com/displaytest.htm)

MinimigTG68 on Xilinx boards:
I would be able to put hours into such a project but I would probably also need
help . The biggest hurdle if I understand correctly is to get the DDR-controller
to work with the Minimig. And this is NOT my cup of tea for now.. There are
working DDR-controllers out there, but there always seem to give some
problems/inconsistencies when tried out.. somebody who knows otherwise?

Any more interested parties to this goal? There should be many people out there
who would like to see the Amiga come to life on their boards I think.

In the past I've fiddled around with many small projects for example a working
FPGA-64 with my setup including a working SID-chip in it! But the Amiga would be
even better!

For now I'm trying out a Multi-timbrel FPGA-MIDI-synthesizer built by another
Swedish FPGA-hacker which is very nice with it's included filtering-features and
up to 40 simultaneous voices split over max 2 Synthesizers!

Hi Manuel,

so here is the translation of Tobiflexx reply:

On Saturday 26 September 2009 09:28:20 tobiflexx wrote:
> > @Tobiflexx: Allles klar, oder soll ich rückübersetzen?
>
> Rückübersetzen ist nicht nötig.
> Leider kann ich mir auf das Problem mit dem ZENTEL ram keinem Reim machen.
>  Der Programmcode der die Meldung "unsupported Size" ausgibt wird ja durch
>  den Bootloader von der SD-Karte in den SD-RAM kopiert(Datei "menue.sys")
>  und dort auch ausgefürt. D.h. Lesen von der SD-Karte geht und Schreiben
>  und Lesen des SDRAMs auch. Also ohne den RS232 Dump komme ich nicht
>  weiter.
>
> Andreas, übersetzt du das bitte?
>
> Viele Grüße
> Tobias

Unfortunately I can not explain the problem with the ZENTEL RAM. The
bootloader copies the program code which outputs the "unsupported Size"
message from SD-Card into SD-RAM (File "menue.sys") and starts it from there.
This means reading and writing the SD-Card works and reading and writing the
SDRAM works as well. I can't conclude anything without RS232 Dump.

Andreas, can you please translate?

regards,
Tobias

Andreas here again: In the company I still work, I have used very cheap RS232
<-> USB Adapters (10 EUR range) successfully. These should be okay to get a
serial console.

regards,
Andreas