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

>
> @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

>
> On Friday 25 September 2009 11:36:53 gaula92 wrote:
> > Thanks a lot for your translations, Andreas. Now I've a clearar picture of
> >  the possible problem.
> >
> > I believe the fact that it's working for some users is in fact a RAM timing
> >  problem, wich makes the core working "by pure chance" on some conditions:
> >  it even booted for me yesterday after 20 or so tries.
> >
> > I haven't a computer with RS232 anymore...I'll try to get an RSR232-usb
> >  adaptor, but I believe Minimig is not possible on my DE1.
> >
> > The MSX core uses 4MB of RAM, as it recreates an MSX computer with MB ram
> >  expansions. I think my RAM is wirg: it's just that timing adjustments in
> >  this new Minimig version just won't let it work on my board, because of
> >  the ZENTEL ram.
> >
> > If someone else manages to compile a DE1 version wich works on ZENTEL RAM,
> >  please upload it to the files section.
> >
> > Thanks!
>

@Tobiflexx: Allles klar, oder soll ich rückübersetzen?

On Friday 25 September 2009 11:36:53 gaula92 wrote:
> Thanks a lot for your translations, Andreas. Now I've a clearar picture of
>  the possible problem.
>
> I believe the fact that it's working for some users is in fact a RAM timing
>  problem, wich makes the core working "by pure chance" on some conditions:
>  it even booted for me yesterday after 20 or so tries.
>
> I haven't a computer with RS232 anymore...I'll try to get an RSR232-usb
>  adaptor, but I believe Minimig is not possible on my DE1.
>
> The MSX core uses 4MB of RAM, as it recreates an MSX computer with MB ram
>  expansions. I think my RAM is wirg: it's just that timing adjustments in
>  this new Minimig version just won't let it work on my board, because of
>  the ZENTEL ram.
>
> If someone else manages to compile a DE1 version wich works on ZENTEL RAM,
>  please upload it to the files section.
>
> Thanks!

Thanks a lot for your translations, Andreas. Now I've a clearar picture of the
possible problem.

I believe the fact that it's working for some users is in fact a RAM timing
problem, wich makes the core working "by pure chance" on some conditions: it
even booted for me yesterday after 20 or so tries.

I haven't a computer with RS232 anymore...I'll try to get an RSR232-usb adaptor,
but I believe Minimig is not possible on my DE1.

The MSX core uses 4MB of RAM, as it recreates an MSX computer with MB ram
expansions. I think my RAM is wirg: it's just that timing adjustments in this
new Minimig version just won't let it work on my board, because of the ZENTEL
ram.

If someone else manages to compile a DE1 version wich works on ZENTEL RAM,
please upload it to the files section.

Thanks!

So, lets try to translate...

On Wednesday 16 September 2009 21:32:26 tobiflexx wrote:
> Der Minimigcore gibt über die RS232 Debuginformationen aus. Also die
>  serielle Schnittstelle des DE1 Boards mit der seriellen Schnittstelle eins
>  PCs verbinden und das Terminalprogramm auf 115200 Baud/8Data/1Stop/no
>  Parity einstellen. Hier erscheint dann auch die erkannte Größe des
>  Kickroms. In der Terminalausgabe nach "fl:=XXXXX=" suchen. Anstelle von
>  XXXXX steht die Größe des Kickroms als HEX-Wert. Dieser Wert würde mich
>  mal interessieren.

The Minimigcore sends debug information through the RS232 port. Please connect
the serieal port of the DE1 Board with the serial port of a PC and set your
terminal program to 115200 bps 8 data bits, 1 stop bit, no parity
(115200/8N1). The size of the kickrom will be printed in the terminal window.
Search the terminal output for the string "fl:=XXXXX=" where XXXXX is the size
of the Kickroms in HEX. Tobiflexx would like to know this value.

> > > @Mark: I found in the past that version 12e of the minimigtg68 worked
> > > fine on my ZENTEL DE1, so I've found the sources and I'm looking at
> > > them. They're too different from v20 sdram controller sources... Do you
> > > think it would be possible/good idea to build V20 with V12e SDRAM
> > > controller sources?
>
> Das macht aus meiner Sicht keinen Sinn. Ich vermute ehr, daß mit dem FPGA
>  etwas nicht stimmt. Bei jeden Compilerlauf von Quartus werden die
>  Resourcen anders in dem FPGA belegt. Wenn nun z.B ein interner Ramblock
>  defekt ist spielt das erst eine Rolle wenn er in das Design eingebunden
>  wird. Es ist möglich daß die 12e Version mal so compiliert wurde, daß ein
>  möglicherweise defekter Block nicht genutzt wurde. Das ist dann aber
>  Zufall. Wenn der gleiche Source nochmal comiliert wird kann es sein, daß
>  dieser Block jetzt aber verwendet wird und Probleme macht. Der MSX-Core
>  verwendet sehr wenige Ramblöcke. Die V12e und V13 sind da schon
>  anspruchsvoler. Und beim aktuellen Core mußte ich schon den FloppyFIFO in
>  das externe SRAM auslagern. Je mehr Ramblöcke benutzt werden desto größer
>  ist die Wahrscheinlichkeit einen defekten Ramblöck zu erwischen wenn es
>  denn einen gibt. Eigentlich sollten die FPGAs gründlich getestet sein.
>  Aber ich hatte mal einen ähnlichen Effekt in einem Virtex. Der hatte 4
>  DCMs. Designs mit nur einem benutzten DCM liefen fast immer. Mit dreien
>  manchmal und mit vier benutzen DCMs nie. Also folgerte ich, daß einer der
>  4 DCMs defekt war.

Oh, a lot of text %-) I'll give it a try... excuse the german construction of
sentences in my translation. ;-)

From TobiFlex's point of view that would not be helpful. He guesses that there
is some problem with the FPGA (i.e. it might be faulty). On each compiler run
in Quartus the resources in the FPGA are used differently. If for instance one
internal RAM Block is faulty you will only know when it is used in the current
design. It is possible that the 12e version was compiled in a way that did not
use this defective block. However that is pure chance. If you compile the same
source again it is possible that this block is now used and leading to
problems. The MSX-Core uses very few blocks of RAM. The V12e and V13 are more
demanding. On the current core Tobiflex even needed to put the FloppyFIFO into
external SRAM. The more blocks of RAM are used the higher is the chance that a
defective one gets used if there is one. Normally these FPGAs should be tested
properly. However Tobilex once had a similar effect with a Virtex. It had 4
DCMs. Designs with only one used DCM worked almost every time. With three it
worked sometimes and with four used DCMs it worked never. So he concluded that
one of the four used DCMs was faulty.

@Tobilfex: How a about a RAM test for the FPGA? Maybe consisting of whatever
CPU is easiest and a simple RAM test program. Wie wäre es mit einem RAM Test
für den FPGA? Er könnte aus einer beliebigen CPU und einem einfach RAM Test
Programm bestehen.

bye,
Andreas Micklei

P.s. My spellchecker can't check german and english at the same time. I have
to choose which half of the text I want to be red. Weird. ;-)

On Thursday 17 September 2009 13:57:07 gaula92 wrote:
> Don't try too hard at work... I preffer you keep your work!
> I couldn't live with you being fired because of a Minimig translation
>  proposed by me!! :D I can wait!

You are much nearer to the truth than you might think. I already resigned my
job and will be free beginning next once (or the month after if you count the
20 day vacation I accumulated). However I can assure you that the
circumstances are out of scope for this mailinglist and not minimig related in
any way. :-D

regards,
Andreas Micklei

Hey, hey, Andreas!
Don't try too hard at work... I preffer you keep your work!
I couldn't live with you being fired because of a Minimig translation proposed
by me!! :D I can wait!

--- In minimigtg68@yahoogroups.com, Andreas Micklei <nurgle@...> wrote:
>
> On Thursday 17 September 2009 13:04:38 gaula92 wrote:
> > Can someone translate this into english, please?
> > Specially the part when he explains the MSX-core differencies...
> > Andreas?
>
> I'm still at work, but I will try.
>

On Thursday 17 September 2009 13:04:38 gaula92 wrote:
> Can someone translate this into english, please?
> Specially the part when he explains the MSX-core differencies...
> Andreas?

I'm still at work, but I will try.

Can someone translate this into english, please?
Specially the part when he explains the MSX-core differencies...
Andreas?

Thanks!!

--- In minimigtg68@yahoogroups.com, "tobiflexx" <t.gubener@...> wrote:
>
> Hallo Andreas,
> hier was zum Übersetzen:
> Der Minimigcore gibt über die RS232 Debuginformationen aus. Also die serielle
Schnittstelle des DE1 Boards mit der seriellen Schnittstelle eins PCs verbinden
und das Terminalprogramm auf 115200 Baud/8Data/1Stop/no Parity einstellen. Hier
erscheint dann auch die erkannte Größe des Kickroms. In der Terminalausgabe nach
"fl:=XXXXX=" suchen. Anstelle von XXXXX steht die Größe des Kickroms als
HEX-Wert. Dieser Wert würde mich mal interessieren.
>
> > @Tobiflexx: Kannst Du das Problem nochmal auf Deutsch erläutern, und welche
> > Infos Du brauchst, falls das näher spezifizierbar ist? Gibt es in den
bereits
> > gemeldeten Fehlerbeschreibungen etwas, das ich übersetzen soll?
> >
> > > @Mark: I found in the past that version 12e of the minimigtg68 worked fine
> > > on my ZENTEL DE1, so I've found the sources and I'm looking at them.
> > > They're too different from v20 sdram controller sources... Do you think it
> > > would be possible/good idea to build V20 with V12e SDRAM controller
> > > sources?
> >
> > @Tobiflexx: Hilft das? Soll er probieren?
> >
> Das macht aus meiner Sicht keinen Sinn. Ich vermute ehr, daß mit dem FPGA
etwas nicht stimmt. Bei jeden Compilerlauf von Quartus werden die Resourcen
anders in dem FPGA belegt. Wenn nun z.B ein interner Ramblock defekt ist spielt
das erst eine Rolle wenn er in das Design eingebunden wird. Es ist möglich daß
die 12e Version mal so compiliert wurde, daß ein möglicherweise defekter Block
nicht genutzt wurde. Das ist dann aber Zufall. Wenn der gleiche Source nochmal
comiliert wird kann es sein, daß dieser Block jetzt aber verwendet wird und
Probleme macht.
> Der MSX-Core verwendet sehr wenige Ramblöcke. Die V12e und V13 sind da schon
anspruchsvoler. Und beim aktuellen Core mußte ich schon den FloppyFIFO in das
externe SRAM auslagern. Je mehr Ramblöcke benutzt werden desto größer ist die
Wahrscheinlichkeit einen defekten Ramblöck zu erwischen wenn es denn einen gibt.
> Eigentlich sollten die FPGAs gründlich getestet sein. Aber ich hatte mal einen
ähnlichen Effekt in einem Virtex. Der hatte 4 DCMs. Designs mit nur einem
benutzten DCM liefen fast immer. Mit dreien manchmal und mit vier benutzen DCMs
nie. Also folgerte ich, daß einer der 4 DCMs defekt war.
>
> Viele Grüße
> TobiFlex
>

gaula92 wrote:

> @Mark: I found in the past that version 12e of the minimigtg68 worked
> fine on my ZENTEL DE1, so I've found the sources and I'm looking at them.
> They're too different from v20 sdram controller sources... Do you think
> it would be possible/good idea to build V20 with V12e SDRAM controller
> sources?

Without looking at both I can't say whether or not this is (a) possible or
(b) likely to fix the problem.

Unfortunately work and life in general is pretty hectic atm and I simply
don't have the time to look at Minimig right now. I'd like to be able to
help with this issue but can't just yet. :(

As I said I'll be coming up to speed on the new Quartus TimeQuest timing
analyzer soon and should then get the chance to look more closely at the
timing constraints on Minimig - but that's a few weeks away.

Regards,

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

Hallo Andreas,
hier was zum Übersetzen:
Der Minimigcore gibt über die RS232 Debuginformationen aus. Also die serielle
Schnittstelle des DE1 Boards mit der seriellen Schnittstelle eins PCs verbinden
und das Terminalprogramm auf 115200 Baud/8Data/1Stop/no Parity einstellen. Hier
erscheint dann auch die erkannte Größe des Kickroms. In der Terminalausgabe nach
"fl:=XXXXX=" suchen. Anstelle von XXXXX steht die Größe des Kickroms als
HEX-Wert. Dieser Wert würde mich mal interessieren.

> @Tobiflexx: Kannst Du das Problem nochmal auf Deutsch erläutern, und welche
> Infos Du brauchst, falls das näher spezifizierbar ist? Gibt es in den bereits
> gemeldeten Fehlerbeschreibungen etwas, das ich übersetzen soll?
>
> > @Mark: I found in the past that version 12e of the minimigtg68 worked fine
> > on my ZENTEL DE1, so I've found the sources and I'm looking at them.
> > They're too different from v20 sdram controller sources... Do you think it
> > would be possible/good idea to build V20 with V12e SDRAM controller
> > sources?
>
> @Tobiflexx: Hilft das? Soll er probieren?
>
Das macht aus meiner Sicht keinen Sinn. Ich vermute ehr, daß mit dem FPGA etwas
nicht stimmt. Bei jeden Compilerlauf von Quartus werden die Resourcen anders in
dem FPGA belegt. Wenn nun z.B ein interner Ramblock defekt ist spielt das erst
eine Rolle wenn er in das Design eingebunden wird. Es ist möglich daß die 12e
Version mal so compiliert wurde, daß ein möglicherweise defekter Block nicht
genutzt wurde. Das ist dann aber Zufall. Wenn der gleiche Source nochmal
comiliert wird kann es sein, daß dieser Block jetzt aber verwendet wird und
Probleme macht.
Der MSX-Core verwendet sehr wenige Ramblöcke. Die V12e und V13 sind da schon
anspruchsvoler. Und beim aktuellen Core mußte ich schon den FloppyFIFO in das
externe SRAM auslagern. Je mehr Ramblöcke benutzt werden desto größer ist die
Wahrscheinlichkeit einen defekten Ramblöck zu erwischen wenn es denn einen gibt.
Eigentlich sollten die FPGAs gründlich getestet sein. Aber ich hatte mal einen
ähnlichen Effekt in einem Virtex. Der hatte 4 DCMs. Designs mit nur einem
benutzten DCM liefen fast immer. Mit dreien manchmal und mit vier benutzen DCMs
nie. Also folgerte ich, daß einer der 4 DCMs defekt war.

Viele Grüße
TobiFlex

On Tuesday 15 September 2009 13:56:47 gaula92 wrote:
> @Andreas Micklei: Can you please ask Tobiflexx what does he think about the
> origin of the problem? He says "it cant be the sd card, it cant be the
> sdram", but I just don't get it: does he mean it can be both things? none
> of them? I believe there's an idiomatic barrier here.

None of them as I read it.

@Tobiflexx: Kannst Du das Problem nochmal auf Deutsch erläutern, und welche
Infos Du brauchst, falls das näher spezifizierbar ist? Gibt es in den bereits
gemeldeten Fehlerbeschreibungen etwas, das ich übersetzen soll?

> @Mark: I found in the past that version 12e of the minimigtg68 worked fine
> on my ZENTEL DE1, so I've found the sources and I'm looking at them.
> They're too different from v20 sdram controller sources... Do you think it
> would be possible/good idea to build V20 with V12e SDRAM controller
> sources?

@Tobiflexx: Hilft das? Soll er probieren?

regards,
Andreas

@TobiFlexx: Thanks for your help offer!
It's me who should apologize: you seem to be willing to help me even now after
my apparent complains... Thanks, that's all I can say!


@Andreas Micklei: Can you please ask Tobiflexx what does he think about the
origin of the problem? He says "it cant be the sd card, it cant be the sdram",
but I just don't get it: does he mean it can be both things? none of them? I
believe there's an idiomatic barrier here.

@Mark: I found in the past that version 12e of the minimigtg68 worked fine on my
ZENTEL DE1, so I've found the sources and I'm looking at them. They're too
different from v20 sdram controller sources...
Do you think it would be possible/good idea to build V20 with V12e SDRAM
controller sources?


--- In minimigtg68@yahoogroups.com, Andreas Micklei <nurgle@...> wrote:
>
> On Monday 14 September 2009 22:22:23 tobiflexx wrote:
> > First: It is not easy for me write in english. If you like i can answer of
> > difficult questions in German. And you problem is difficult!
>
> <delurking>
> Much of the stuff discussed here is way over my head, but translating from
> german to english ist certainly not, especially when it gets technical. If I
> can be of any help, tell me!
> </delurking>
>
> regards,
> Andreas Micklei
>

On Monday 14 September 2009 22:22:23 tobiflexx wrote:
> First: It is not easy for me write in english. If you like i can answer of
> difficult questions in German. And you problem is difficult!

<delurking>
Much of the stuff discussed here is way over my head, but translating from
german to english ist certainly not, especially when it gets technical. If I
can be of any help, tell me!
</delurking>

regards,
Andreas Micklei

Jacub has release a new Version of the Minimig core. It includes the ARM Source.
I'm locking forward and hope that I now can support a hardfile.

@gaula92
Sorry for my silence.
First: It is not easy for me write in english. If you like i can answer of
difficult questions in German. And you problem is difficult!

Second: The SDRAM Timing match all specs now. It can't bee the SDRAM. The SD
Card Timing match all specs. It cant bee the SD Card. I don't know where i must
search the error??? How I can help you. Sorry!

Third: I'm not a professional Developer. It is my hobby. That why perhapes I'm
not use all futures of Quartus correct. I have nobody who tell me: you must do
it so or so. Perhapes I do somethings wrong???
But thats why I pubilish my work. Others can lock on it and can it make better.

@mark
Here you can found the Compiler I use:
http://home.hetnet.nl/~pj.fondse/ide68k/download.htm
The "*.prj" file can you found into the source. There is also a "s.bat" file to
convert it for Quartus or to make the "menue.sys" file. But it is buggy.
Perhapes can someone found a way to use AmiDevCpp for that.

Best
TobiFlex

Javier Ruiz wrote:

> Have you seen it? What about of a port of Minimig in this board?

I haven't seen it before, but had a quick look. It seems pretty good.

The problem with Minimig is configuring the custom SDRAM controller for
different SDRAM devices. I haven't had the time to look closely at the SDRAM
stuff myself, so I can't comment on how easy or otherwise this would be.

> Maybe can be included in your arcade developement project .....

Sure. But I don't have any plans to buy one of these in the near future. :(
But I'm happy for others to submit ports to other hardware of course!

Regards,

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

gaula92 wrote:

> Ehm..yes, yes, of course. Sorry for being that retarded. I will look at
> the code and evaluate how possible is for me to write souch a
> functionality. It seems to provide output methods alreday.

It should be trivial to add a memory test to the code... the hardest part
will be figuring out how to compile and build the .hex file...

> On the other hand, should I do anything special before flashing a POF
> file with the Quartus II programmer? If soyandroid claims it's working on
> his ZENTEL board, maybe I am ommiting some steps..

With timing problems, you get some degree of unpredictability. An image that
works on one board, won't work on another. In fact, when I was playing with
older versions on my DE1 and proprietary hardware, I was getting images that
would boot sometimes, and not boot other times. That's the nature of the
issue - the design is not guaranteed to meet timing and hence not run properly!

Regards,

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

Ehm..yes, yes, of course. Sorry for being that retarded.
I will look at the code and evaluate how possible is for me to write souch a
functionality. It seems to provide output methods alreday.

On the other hand, should I do anything special before flashing a POF file with
the Quartus II programmer?
If soyandroid claims it's working on his ZENTEL board, maybe I am ommiting some
steps..

--- In minimigtg68@yahoogroups.com, Mark McDougall <msmcdoug@...> wrote:
>
> gaula92 wrote:
>
> > Do you mean building my own KICKSTART rom??? It would involve 68K
> > assembler and a lot of Amiga knowledge...
>
> No - rebuilding the Minimig boot rom - the software that prints the
> offending error message!!!
>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>

gaula92 wrote:

> Do you mean building my own KICKSTART rom??? It would involve 68K
> assembler and a lot of Amiga knowledge...

No - rebuilding the Minimig boot rom - the software that prints the
offending error message!!!

Regards,

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

>
> I can't see any easy answer looking at the source.
>
> On the one hand, the card would have to be somewhat working in order to get
> that far, as it detects the drive, loads the directory and scans it for the
> filename. That it gets to that error message shows that it can read some
> data from the card.
>
> On the other hand, it would appear that the memory is at least partially
> functioning to get that far as well. It reads data from the card into a
> memory buffer in a few places. If it were a memory problem, then one could
> ask why it's always failing at the location that holds "file.len"!?!
>

Yes, and that what puzzles me: the card partially works as it loads the
menue.sys file, but the program fails to load the kick.rom file.
It's a nonsense, and there are evidencies of both: maybe SDRAM problem, maybe
SD-CARD problem. The former is not very probable as I've tried at least ten
different cards by now.


> Did you know that Quartus enables you to update a SOF file that contains
> initialised memory blocks directly from MIF/HEX files without having to
> rebuild the project? You could (in theory) build your own test rom that, for
> example, does an SDRAM test and displays the result on the boot screen.

Do you mean building my own KICKSTART rom??? It would involve 68K assembler and
a lot of Amiga knowledge...

gaula92 wrote:

> located in the main.c source file. That function relies on other
> functions to determine the file size, and it can load both 256 and 512KB
> rom files. Even so, I tried every version to be sure.

I can't see any easy answer looking at the source.

On the one hand, the card would have to be somewhat working in order to get
that far, as it detects the drive, loads the directory and scans it for the
filename. That it gets to that error message shows that it can read some
data from the card.

On the other hand, it would appear that the memory is at least partially
functioning to get that far as well. It reads data from the card into a
memory buffer in a few places. If it were a memory problem, then one could
ask why it's always failing at the location that holds "file.len"!?!

Did you know that Quartus enables you to update a SOF file that contains
initialised memory blocks directly from MIF/HEX files without having to
rebuild the project? You could (in theory) build your own test rom that, for
example, does an SDRAM test and displays the result on the boot screen.

Regards,

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

Of course I looked for the message: it's a message from the 68k bootloader, not
the Minimig core itself.

It's in the function with signature

unsigned char UploadKickstart(const unsigned char *name)

located in the main.c source file. That function relies on other functions to
determine the file size, and it can load both 256 and 512KB rom files. Even so,
I tried every version to be sure.

On the other hand, I saw the first preview version executing rubbish instead of
the bootloader: it showed a corrupt bootloader screen. Of course it could be
executing a different kind of random rubbish, who knows, but the bootloader
shows clear and correct text now with the new versions.

--- In minimigtg68@yahoogroups.com, Mark McDougall <msmcdoug@...> wrote:
>
> gaula92 wrote:
>
> > I just wanted to know what kind of problem am I facing:
> > SDRAM timming? SD ACCESS? it's not hard to drop a line or two and say
> > "hey, it's an SDRAM problem for sure", or even "I believe it's all about
> > your SD-card".
>
> He may not know, if it doesn't fail for him.  But the error message should
> give some clue as to the failure - have you tried looking in the source for
> that particular error?
>
> > Tried all the possible kickstart 1.x and 2.x versions: the message
> > "UNSUPPORTED KICK.ROM FILE SIZE" is a non-sense: knowing for sure it's an
> > SDRAM issue would have been enough.
>
> If there is a RAM problem, the bootloader could be executing all sorts of
> rubbish...
>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>

gaula92 wrote:

> I just wanted to know what kind of problem am I facing:
> SDRAM timming? SD ACCESS? it's not hard to drop a line or two and say
> "hey, it's an SDRAM problem for sure", or even "I believe it's all about
> your SD-card".

He may not know, if it doesn't fail for him.  But the error message should
give some clue as to the failure - have you tried looking in the source for
that particular error?

> Tried all the possible kickstart 1.x and 2.x versions: the message
> "UNSUPPORTED KICK.ROM FILE SIZE" is a non-sense: knowing for sure it's an
> SDRAM issue would have been enough.

If there is a RAM problem, the bootloader could be executing all sorts of
rubbish...

Regards,

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

You're totally right. No one owes me anything, and I've thanked everyone for
their work.
All I wanted to know is if this is an SDRAM timming problem or a SD card access
problem, not a magical solution of some kind. I tried some arbitrary values to
the variables Tobiflexx talked about, without any results of course. I know
lacking the knowledge to fix it is my problem and no one else's, but I didn't
event need to fix it if it's an SDRAM problem: I just wanted to know what kind
of problem am I facing: SDRAM timming? SD ACCESS? it's not hard to drop a line
or two and say "hey, it's an SDRAM problem for sure", or even "I believe it's
all about your SD-card".

I'm sure the persistant message error I'm getting must have some real meaning
for someone who knows the bootloader source: my 1.x kickstart files are 256KB as
expected, and my 2.x versions are 512KB as expected. Tried all the possible
kickstart 1.x and 2.x versions: the message "UNSUPPORTED KICK.ROM FILE SIZE" is
a non-sense: knowing for sure it's an SDRAM issue would have been enough.

Anyway, sorry for complaining if that's what it sounded like.


--- In minimigtg68@yahoogroups.com, Mark McDougall <msmcdoug@...> wrote:
>
> gaula92 wrote:
>
> > but I have received no help whatsoever
> > from the FPGA people around here, only some vague suggestions:
>  (snip)
> > but I believe there are other interests here and making
> > it work on a general-purpose board is not one of them.
>
> First of all, no-one here owes you anything, so quit complaining.
>
> Secondly, the "vague" suggestions included looking at the timing constraints
> on the SDRAM pins. If you couldn't be bothered trying them out yourself, or
> don't have the knowledge, then that's your problem. No-one else's.
>
> Without a Zentel board, it's pretty much impossible to diagnose the problem,
> and there's not much incentive to build images that you can't test yourself.
>
> The DE2/1 ports are not the main focus of Minimig, or Tobias - he has got
> plenty of other stuff to work on. As do we all.
>
> Sorry we couldn't drop everything and fix your problem. I suggest you send a
> request for your money back.
>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>

gaula92 wrote:

> but I have received no help whatsoever
> from the FPGA people around here, only some vague suggestions:
	 (snip)
> but I believe there are other interests here and making
> it work on a general-purpose board is not one of them.

First of all, no-one here owes you anything, so quit complaining.

Secondly, the "vague" suggestions included looking at the timing constraints
on the SDRAM pins. If you couldn't be bothered trying them out yourself, or
don't have the knowledge, then that's your problem. No-one else's.

Without a Zentel board, it's pretty much impossible to diagnose the problem,
and there's not much incentive to build images that you can't test yourself.

The DE2/1 ports are not the main focus of Minimig, or Tobias - he has got
plenty of other stuff to work on. As do we all.

Sorry we couldn't drop everything and fix your problem. I suggest you send a
request for your money back.

Regards,

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

Thanks, tanyonglak! You seem to be the only person here who really helped here.

I'm tired of trying: I spent a lot of money on both new and old SD cards jsut
for testing minimigtg68 , but I have received no help whatsoever from the FPGA
people around here, only some vague suggestions: after a month of trials and
failures with that stupid "UNSUPPORTED KICKSTART SIZE" message on the
bootloader, I don't even know if it is a SDRAM problem or a SD problem. I've
tried everything and there's no real evidence of the new core working on a
ZENTEL DE1, just one person claims to have it working. Tobiflexx could have
written a line or two after all my error reports: I invested some time testing
his work after all.

I want to state that I didn'r really need to test it for personal use: I have
several Amiga computers at home, and several Minimigs with ARM controller. I
jsut wanted to see my DE1 simulating the Amiga: it's a great MSX2+ machine most
of the time.

So that's it: have a good time with this core. I thank everyone involved for
their work, but I believe there are other interests here and making it work on a
general-purpose board is not one of them. Good luck with propietary and closed
solutions.

regards

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

From: tanyonglak

To: minimigtg68@yahoogroups.com

Sent: Thursday, September 10, 2009 11:39 PM

Subject: [minimigtg68] Re: People with ZENTEL SDRAM on your DE1, please test the new files

 

Hi,

OK ,tried your sof. Everything booted on PSC DE1- Galaga, Hybris.
I've not built the joystick.

My kickstart is v1.3 - 256K.
Let me know if you need this.
(Kickstart 3.0 512K works but have problems when playing 1943.)
Minimig_joyemu is working well for me. Nice to see the Juggler demo.

Meantime maybe you can enjoy the DE1-MSX. Fantastic job they've done there and here too. I've waited many months for Minimig PSC DE1.

Fyi.. I've found out recently (after 1 year) Terasic shipped my DE1 with faulty keys. That'a why v12e I can't select disks. There were 2 tiny arrow stickers pasted next to Key0,1 underside. QA obviously caught it but they still shipped it anyway!....sneaky.

regards
yl

.

Hi,

OK ,tried your sof. Everything booted on PSC DE1- Galaga, Hybris.
I've not built the joystick.

My kickstart is v1.3 - 256K.
Let me know if you need this.
(Kickstart 3.0 512K works but have problems when playing 1943.)
Minimig_joyemu is working well for me. Nice to see the Juggler demo.

Meantime maybe you can enjoy the DE1-MSX. Fantastic job they've done there and
here too. I've waited many months for Minimig PSC DE1.

Fyi.. I've  found out recently (after 1 year) Terasic shipped my DE1 with faulty
keys. That'a why v12e I can't select disks. There were 2 tiny arrow stickers
pasted next to  Key0,1 underside. QA obviously caught it but they still shipped
it anyway!....sneaky.

regards
yl

--- In minimigtg68@yahoogroups.com, "gaula92" <gaula92@...> wrote:
>
> Hello there
>
> I've just uploaded the binaries compiled with Quartus II V90 from V2.0
sources. Javir Ruiz (soyandroid) also compiled it with QII V9.0 and sent me the
files, but I get the same problem:
>
> "UNSOPPORTED KICK ROM FILE SIZE!!"
> "UNSOPPORTED KICK ROM FILE SIZE!!"
>
> Tried several cards, files MENUE.SYS and KICK.ROM on the cards, formatted with
SDFORMATTER and several other utilities and cluster sizes in FAT 16...
>
>
> Help needed!
>
>   Regards
>
>    Manuel
>

Hello there

I've just uploaded the binaries compiled with Quartus II V90 from V2.0 sources.
Javir Ruiz (soyandroid) also compiled it with QII V9.0 and sent me the files,
but I get the same problem:

"UNSOPPORTED KICK ROM FILE SIZE!!"
"UNSOPPORTED KICK ROM FILE SIZE!!"

Tried several cards, files MENUE.SYS and KICK.ROM on the cards, formatted with
SDFORMATTER and several other utilities and cluster sizes in FAT 16...


Help needed!

   Regards

    Manuel