Minimig Discussion Forum

Discussing the Open Source FPGA Amiga Project
It is currently Sat Oct 21, 2017 6:49 am

All times are UTC




Post new topic Reply to topic  [ 144 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14, 15  Next
Author Message
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 12:32 pm 
Offline

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
Master of Gizmo: yes, a joint repository is my wish as well, we already discussed this. We have a Github 'organization' set up: https://github.com/organizations/minimig-dev Hopefully, sometime in the future ;)

The minimig-de1 port should be fairly easy to use with an external microcontroller, as the control block is completely separate from the minimig - just remove the ctrl_top and connect appropriate wires (like SPI) to FPGA pins (it was my plan to attach an external ARM uC to the DE1, so I prepared some things for it).

You could also use the original minimig (http://code.google.com/p/minimig/), although I don't know how up to date that is. Maybe it would be better to use updated sources from boing4000 - the minimig-de1 doesn't differ much from it. Apart from the SDRAM controller and TG68 core, ofcourse ;)

Enjoy!

_________________
** my minimig builds: http://somuch.guru/ **


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 2:30 pm 
Offline

Joined: Tue Sep 25, 2012 7:15 pm
Posts: 105
I just read this entire thread for the first time and i am not 100% sure i understand what is booted from where.

Am i right that i have to store the de1_boot.bin in flash? The DE2 i am using isn't mine and i'd like to avoid doing any permanent changes, so i was delighted that my experiments so far only required the download of the sof file and the placement of files on the sd card. Also i don't have a windows box and i now have to figure out how to write to the flash from a linux box. Chaos? You seem to be doing everything under linux. How do you upload to the d1 flash?

So there's now a oc1200 doing the io controller part. There's de1_boot.bin which is the io controllers firmware. There's the bootrom.v which contains 68k boot code which i always thought would be loading the kick.rom, but i don't see where that happens. Which part is loading the de1_boot.bin from where? And if the io controller is booted that way why do we need the 68k code at all? Can't the io controller load kick.rom by itself?


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 2:50 pm 
Offline

Joined: Tue Dec 13, 2011 7:48 pm
Posts: 341
Yeah this is confusing - there are three different schemes in use currently:

"Classic" Minimig:
Controller has internal firmware which loads the FPGA core from SD card.
The core contains a simple ROM for the Amiga CPU which reads a Kickstart image from the Amiga disk drive subsystem. The Controller uses its disk drive emulation to send that Kickstart image

Tobiflex's ports to C-One, DE1, DE2 and Chameleon:
The FPGA core is stored in an on-board configuration device, or sent over JTAG.
The core contains both an "Amiga" CPU and a "Controller" CPU - both TG68s, and contains a bootrom for both.
The Amiga CPU's bootrom is the same as the classic Minimig's.
The Controller CPU's bootrom is a very compact assembly routine that loads the main Controller firmware from SD card. Once it's done that, the sequence of events is essentially the same as the classic Minimig.

Chaos's evolution of the DE1 port:
The Controller CPU is now an OR1200. Because the original Controller boot ROM was writting in 68k assembly it would take significant effort to port to OR1200, and because the OR1200 has lower code density it would take up more block RAM. Thus, this variant stores the Controller firmware in flash rather than using a boot ROM to load it from SD card.

In all cases, the two CPUs communicate only over SPI, and have no access to each others' address spaces.

_________________
~ Amiga 4000/030 ~ Amiga 1200 030/50MHz ~ Turbo Chameleon 64 ~ Altera DE1 with Minimig core ~
Details of my projects: http://retroramblings.net


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 3:46 pm 
Offline

Joined: Mon Dec 01, 2008 9:58 pm
Posts: 1568
Location: .de
If anyone is willing to handle sourceforge, I do own the http://sourceforge.net/projects/minimig-amiga/ archive.

I can provide account login data to any developer via PM :)

_________________
_____________________________
JMP $00000BED ; will guru-meditation until next morning


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 7:08 pm 
Offline

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
Master of Gizmo wrote:
Am i right that i have to store the de1_boot.bin in flash? The DE2 i am using isn't mine and i'd like to avoid doing any permanent changes, so i was delighted that my experiments so far only required the download of the sof file and the placement of files on the sd card.

Yes, the de1_boot.bin is meant to be written into flash. Like MMrobinsonb5 described it, there's just not enough free space for an SD card bootloader in the DE1's FPGA. I sure wish it was different, I tried to write the barest possible code to boot the real firmware from SD card, but there's no way to fit it inside the FPGA (two "advantages" that the M68000 has over OR1200 and allows the code for the M68000 to fit: CISC vs. RISC and variable instruction length).

Quote:
Also i don't have a windows box and i now have to figure out how to write to the flash from a linux box. Chaos? You seem to be doing everything under linux. How do you upload to the d1 flash?

I use windows for the upload part. ;) Sorry, I have no idea if that's possible from linux, it certainly seemed it would take too much time to try and make it work. Now that I think of it, I do have the sources for the Control Panel program, so something similar could be written for linux ...

Anyway, it is possible that the FPGA on the DE2 board has more free memory, which would allow you to remove the FLASH controller and simply put an internal ROM there. Can you compile and check the fitter report for the number of free M4K blocks? And I'll look where I put my bare bootloader code and I can send it to you, if you want.

Quote:
So there's now a oc1200 doing the io controller part. There's de1_boot.bin which is the io controllers firmware. There's the bootrom.v which contains 68k boot code which i always thought would be loading the kick.rom, but i don't see where that happens.

The bootrom.v does load the kick.rom, among other things. Actually, the controller firmware & the Amiga side firmware do that together - they do it through the disk interface (SPI).

Quote:
Which part is loading the de1_boot.bin from where?

The de1_boot.bin firmware is "self-loading" - it copies itself from ROM (flash) to RAM (SRAM) and continues execution there. Only the OR1200 uses & sees this code.

Quote:
And if the io controller is booted that way why do we need the 68k code at all? Can't the io controller load kick.rom by itself?

You still need the bootrom.v for the initial on-screen text display (soon to become graphical ;) and the kick.rom copy. The io controller can't copy the kick.rom to memory, because it has no access to it, besides going through the disk interface to the bootrom code, which than saves it to memory.

Enjoy!

_________________
** my minimig builds: http://somuch.guru/ **


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 8:30 pm 
Offline

Joined: Tue Sep 25, 2012 7:15 pm
Posts: 105
I am doing another build atm to write down the free m4k blocks ... this takes ca 40 Minutes on my aging PC.

The IO controller code copies itself from flash to sram? Why? Is the sram faster?

I don't see a reason why the io controller couldn't be enabled to read and write to arbitrary memory regions on "the other side". The current design works well, agreed. But it's pretty amiga centric.

Before digging into the details of minimig i expected the io controller to have full access to the 68k's address space in order to be able to put everything into place before giving the 68k a go. I never expected the 68k itself to be involved in this. Technically it should be pretty simple to let the spi client send and receive data over the 68k's bus while the 68k itself is being halted. The io controller could even initialize video, draw a splash screen or do something else.

This would imho be a cleaner setup and would expecially be independent from the target OS. E.g. when booting TOS the io controller would then just write the tos rom images into those memory regions and one wouldn't have to write seperate 68k code for amiga startup, for atari/tos startup etc. Of course the io controller would still contain target specific parts as it e.g. needs to understand how to serve adf files for amiga and tos disk images for atari. And it would need to know about the targets memory layout. But it's probably not much more than that.


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 8:58 pm 
Offline

Joined: Tue Sep 25, 2012 7:15 pm
Posts: 105
Where do i see the m4k blocks? What i can tell you is that it uses 161408 bits of 483840 available (33%). And since the ep2c35 has 105 m4k blocks with 4608 bits each (being exactly 483840 bits) i assume that i am currently using 36 of the 105 m4k's.

I have plenty of spare memory :-)


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 9:03 pm 
Offline

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
Master of Gizmo wrote:
The IO controller code copies itself from flash to sram? Why? Is the sram faster?

Yes, a lot faster.

Quote:
I don't see a reason why the io controller couldn't be enabled to read and write to arbitrary memory regions on "the other side". The current design works well, agreed. But it's pretty amiga centric.

There's nothing amiga - centric in the io controller hardware itself - if the need arises, you could just add another SPI select line to talk to some SPI slave that would act as a master for the Amiga memory. The firmware is, of course, very Amiga - centric, since that is its only purpose.

Your idea to put some SPI master on the Amiga side could well work, but it would complicate the SDRAM controller further - either by adding a bypass mux for the whole bus, which would be used by the added SPI master on boot up to load the kick.rom and/or AR3.rom, or you'd have to add another port to the SDRAM controller. Either way, timings might be affected, and currently the minimig is unstable enough as it is ;) It is certainly something worth digging into, but the current minimig-de1 build with the TG68K core is still fairly new, and nothing much has been done, other than squeezing it into the DE1's FPGA (and it was a tight fit!), and making it more or less stable.

Enjoy!

_________________
** my minimig builds: http://somuch.guru/ **


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 9:08 pm 
Offline

Joined: Tue Nov 09, 2010 3:10 pm
Posts: 316
Master of Gizmo wrote:
Where do i see the m4k blocks? What i can tell you is that it uses 161408 bits of 483840 available (33%). And since the ep2c35 has 105 m4k blocks with 4608 bits each (being exactly 483840 bits) i assume that i am currently using 36 of the 105 m4k's.

I have plenty of spare memory :-)


Wow, I had no idea that the EP2C35 has that much memory - that is twice as much as the EP2C20! :)

The exact number of used M4K blocks can be seen in the Compilation Report -> Fitter -> Resource Section -> Resource Usage Summary ( look for M4Ks or Total block memory implementation bits).

You could probably easily fit the whole de1_boot.bin inside the free space :)

Enjoy!

_________________
** my minimig builds: http://somuch.guru/ **


Top
 Profile  
 
 Post subject: Re: New minimig build for the DE1
PostPosted: Wed Oct 10, 2012 10:02 pm 
Offline

Joined: Tue Dec 13, 2011 7:48 pm
Posts: 341
Master of Gizmo wrote:
I don't see a reason why the io controller couldn't be enabled to read and write to arbitrary memory regions on "the other side". The current design works well, agreed. But it's pretty amiga centric.


There's no reason at all why it couldn't do that (modifications to the SDRAM controller notwithstanding - but the original DE1 port runs both CPUs from SDRAM and ignores the DE1's SRAM completely, so it's certainly doable. The partitioning between the two CPUs is entirely artificial, and merely reflects the project's heritage.)

Quote:
Before digging into the details of minimig i expected the io controller to have full access to the 68k's address space in order to be able to put everything into place before giving the 68k a go. I never expected the 68k itself to be involved in this.


Yes, it surprised me too - the reason is of course that the design has evolved from the "classic" Minimig, in which the controller is a PIC or ARM µC that has no access at all to the RAM. The main argument in favour of keeping the current arrangement is simply that most of the "classic" Minimig code is used with only minimal changes; the DE1 and Chameleon ports mostly "wrap" rather than diverge from the classic codebase.

_________________
~ Amiga 4000/030 ~ Amiga 1200 030/50MHz ~ Turbo Chameleon 64 ~ Altera DE1 with Minimig core ~
Details of my projects: http://retroramblings.net


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 144 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14, 15  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Translated by Xaphos © 2007, 2008, 2009 phpBB.fr