Minimig Discussion Forum

Discussing the Open Source FPGA Amiga Project
It is currently Thu Sep 21, 2017 3:42 pm

All times are UTC




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: DE1-SoC port
PostPosted: Sat Oct 15, 2016 7:18 pm 
Offline

Joined: Sun Sep 25, 2016 4:05 pm
Posts: 29
Hello!
At last managed to run the great minimig core on the Terasic DE1-SoC board based on DE1 port by Chaos.

In the file sdram_ctrl.v there is an error in controller code.
That block:
Code:
assign host_ack = zena;

always @ (posedge sysclk or negedge reset) begin
  if (~reset) begin
    zena <= 1'b0;
  end else begin
    if (enaWRreg && zena) begin
      zena <= #1 1'b0;
    end
    if ((sdram_state == ph11) && hostCycle) begin
      if ((host_adr == casaddr[23:0]) && !cas_sd_cas) begin
        zena <= #1 1'b1;
      end
    end
  end
end

Host acknowledge signal host_ack resets to zero too early, at phase 15 of the controller FSM (thats where enaWRreg sets up).
While aknowledge latching takes place in the next phase only (phase 0) with the clk_7 rising edge (in qmem_bridge module).

So at my DE1-SoC with Cyclone V this leads to racing condition, leaving host_cs signal being active most of the time preventing controller idle cycles (no SDRAM refresh) and other possible side effects (spurious writes as example).

Externally this error results in very unstable minimig, with some garbage pixels on the screen and crashes while loading the games.

Code change in the line if (enaWRreg && zena) begin to if ((sdram_state == ph2) && zena) begin solves the problem.

Also I needed to add some constraints to SDRAM pins to stabilize it:
Code:
create_generated_clock -name sdr_clk -source [get_pins {amiga_clk|amiga_pll|amiga_pll_inst|altera_pll_i|general[2].gpll~PLL_OUTPUT_COUNTER|divclk}] [get_ports {DRAM_CLK}]

set_input_delay -max -clock sdr_clk 6.4 [get_ports DRAM_DQ*]
set_input_delay -min -clock sdr_clk 2.7 [get_ports DRAM_DQ*]

set_multicycle_path -from [get_clocks {sdr_clk}] -to [get_clocks {amiga_clk|amiga_pll|amiga_pll_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk}] -setup -end 2

set_output_delay -max -clock sdr_clk 1.452  [get_ports DRAM_DQ*]
set_output_delay -min -clock sdr_clk -0.857 [get_ports DRAM_DQ*]

set_output_delay -max -clock sdr_clk 1.531 [get_ports DRAM_ADDR*]
set_output_delay -min -clock sdr_clk -0.805 [get_ports DRAM_ADDR*]
set_output_delay -max -clock sdr_clk 1.533  [get_ports DRAM_*DQM]
set_output_delay -min -clock sdr_clk -0.805 [get_ports DRAM_*DQM]
set_output_delay -max -clock sdr_clk 1.510  [get_ports DRAM_BA_*]
set_output_delay -min -clock sdr_clk -0.800 [get_ports DRAM_BA_*]
set_output_delay -max -clock sdr_clk 1.520  [get_ports DRAM_RAS_N]
set_output_delay -min -clock sdr_clk -0.780 [get_ports DRAM_RAS_N]
set_output_delay -max -clock sdr_clk 1.5000  [get_ports DRAM_CAS_N]
set_output_delay -min -clock sdr_clk -0.800 [get_ports DRAM_CAS_N]
set_output_delay -max -clock sdr_clk 1.545 [get_ports DRAM_WE_N]
set_output_delay -min -clock sdr_clk -0.755 [get_ports DRAM_WE_N]
set_output_delay -max -clock sdr_clk 1.496  [get_ports DRAM_CKE]
set_output_delay -min -clock sdr_clk -0.804 [get_ports DRAM_CKE]
set_output_delay -max -clock sdr_clk 1.508  [get_ports DRAM_CS_N]
set_output_delay -min -clock sdr_clk -0.792 [get_ports DRAM_CS_N]


Many thanks to Chaos and others who make possible such a great fpga core to exist :)

Interesting - how hard it will be to adapt minimig-mist AGA core to DE1 board?


Top
 Profile  
 
 Post subject: Re: DE1-SoC port
PostPosted: Mon Oct 17, 2016 9:34 am 
Offline

Joined: Sun Sep 25, 2016 4:05 pm
Posts: 29
Another problem with the port (or addition to the previous above).

Original code has controller processor connected with the minimig SDRAM memory through qmem bus and qmem bridge.
But due to asynchronous nature of the qmem bus master->slave decoding short pulses of chip_select signal appears on the wrong slave.

For example, when controller processor makes access to his program data memory (it is located in DE1-SoC DDR SDRAM memory in my case) by rising chip_select on dbus, short chip_select pulse appears on the qmem bridge also (bridge from controller dbus to minimig SDRAM memory).

That short spike is long enough to be sampled and initiated access cycle from the qmem bridge.
That is no problem when read access is initiated. But in case of write access we have minimig memory corruption here, easily noticeable on the display screen as the garbage pixels.

Eliminating the problem by injecting two cycles filtering on the cs signal`s qmem bridge side.

All of the qmem bus, bridge and openrisc processor source code is the original minimig-de1 port code, I`ve made changes to the SRAM memory part only, redirecting it to DDR SDRAM.

It seems strange, that this problem have not been noticed on the Cyclone II.


Top
 Profile  
 
 Post subject: Re: DE1-SoC port
PostPosted: Sat Oct 22, 2016 2:48 pm 
Offline

Joined: Sun Sep 25, 2016 4:05 pm
Posts: 29
Hello there!

I`am trying to recompile DE1 firmware for the embedded ARM in Cyclone V.

You are guys have made DirectMode for FPGA while reading sectors from SD card.
This is what I need to remove as I will use built in SD controller in ARM.

What I don`t understand is that code in MMC_Read() function:
Code:
EnableDMode();
SPI_block(511);
SPI(0xff); // dummy write for 4096 clocks
SPI(0xff);
DisableDMode();


What is there doing the second SPI(0xff) command?
A single SPI(0xFF) after set block command is not enough for 4096 clock pulses (511 plus one)?
Is this error and should I remove second spi write?

Regards,
Vlad.


Top
 Profile  
 
 Post subject: Re: DE1-SoC port
PostPosted: Mon Oct 24, 2016 11:19 am 
Offline

Joined: Tue Dec 13, 2011 7:48 pm
Posts: 341
sonycman wrote:
What is there doing the second SPI(0xff) command?
A single SPI(0xFF) after set block command is not enough for 4096 clock pulses (511 plus one)?
Is this error and should I remove second spi write?


Is it perhaps there to transfer a status byte to the receiving process in the FPGA?

_________________
~ 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: DE1-SoC port
PostPosted: Mon Oct 24, 2016 1:12 pm 
Offline

Joined: Sun Sep 25, 2016 4:05 pm
Posts: 29
MMrobinsonb5 wrote:
Is it perhaps there to transfer a status byte to the receiving process in the FPGA?

Or is it just for sure that previous 512 bytes are received properly?
I decided to leave it as it is for the moment.

Yesterday removed or1200 host controller core and started to porting the firmware to the SoC`s Cortex-A9.
Need to rewrite its parts due to different endianess - or1200 is a big endian processor and Cortex is a little endian.

Another interesting thing - minimig`s floppy\HDD controller has a FIFO, but I did`nt see any checks for it to be full in the software.
Data from SD card constantly feeded through SPI in multiblock transfers.

But what if this FIFO becomes full?


Top
 Profile  
 
 Post subject: Re: DE1-SoC port
PostPosted: Tue Oct 25, 2016 5:10 am 
Offline

Joined: Sun Sep 25, 2016 4:05 pm
Posts: 29
Hard disk emulation have an option to take the whole SD card as a disk.
But DE1 design have only one FAT formatted card, containing all the system and .adf image files, which will be destroyed after switching the option on.

How is that thing is supposed to work?


Top
 Profile  
 
 Post subject: Re: DE1-SoC port
PostPosted: Tue Oct 25, 2016 10:01 am 
Offline

Joined: Tue Dec 13, 2011 7:48 pm
Posts: 341
sonycman wrote:
Yesterday removed or1200 host controller core and started to porting the firmware to the SoC`s Cortex-A9.
Need to rewrite its parts due to different endianess - or1200 is a big endian processor and Cortex is a little endian.


Maybe the original Minimig or MIST firmware would be useful reference, since they both run on ARM CPUs rather than a soft CPU core.

Quote:
Hard disk emulation have an option to take the whole SD card as a disk.
But DE1 design have only one FAT formatted card, containing all the system and .adf image files, which will be destroyed after switching the option on.

How is that thing is supposed to work?


You wouldn't normally use the entire SD card as the primary hard drive, but by using that setting for the slave it's possible to mount the SD card using the fat95 filesystem. This makes it easier to transfer files into the Minimig environment. It's not well tested, however.

The Amiga's RigidDiskBlock partition table doesn't have to be on the first block of the drive, so it theory it would be possible to put a RigidDiskBlock and the fat95 filesystem after a regular PC partition table, and boot from the Fat32 partitioned card - though I've not actually tried it, and don't know of any software that can write the RDB somewhere other than the first block.

_________________
~ 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: DE1-SoC port
PostPosted: Tue Oct 25, 2016 1:15 pm 
Offline

Joined: Sun Sep 25, 2016 4:05 pm
Posts: 29
Quote:
Maybe the original Minimig or MIST firmware would be useful reference, since they both run on ARM CPUs rather than a soft CPU core.

Yeah, apparently I will take a look at the latter.
Because running Minimig AGA core from MIST on the DE1-SoC is my next goal :)

Quote:
You wouldn't normally use the entire SD card as the primary hard drive, but by using that setting for the slave it's possible to mount the SD card using the fat95 filesystem. This makes it easier to transfer files into the Minimig environment. It's not well tested, however.

So we can mount the entire card as a FAT read only volume under amiga workbench?
Did`nt know about that.

Thanks for the help!
The forum is kind a deserted nowadays...


Top
 Profile  
 
 Post subject: Re: DE1-SoC port
PostPosted: Thu Oct 27, 2016 6:00 pm 
Offline

Joined: Sun Sep 25, 2016 4:05 pm
Posts: 29
Get the port worked today!
With the HPS ARM as a system controller.
Need some testing though.

Its interesting, I thought you guys have made video output pixel doubler in both vertical and horizontal directions.
But it is vertical line doubler only!
Scandoubler indeed, as you name it :)

So it appears that original Amiga has a very strange video resolution - 640x256 pixel, i.e. kind of a widescreen!
How is it possible that such a widescreen proportions resolution have been showed from square sided old 15kHz monitors?
They are stretched the picture vertically somehow maybe?


Top
 Profile  
 
 Post subject: Re: DE1-SoC port
PostPosted: Thu Oct 27, 2016 9:48 pm 
Offline

Joined: Tue Dec 13, 2011 7:48 pm
Posts: 341
sonycman wrote:
So it appears that original Amiga has a very strange video resolution - 640x256 pixel, i.e. kind of a widescreen!
How is it possible that such a widescreen proportions resolution have been showed from square sided old 15kHz monitors?
They are stretched the picture vertically somehow maybe?


Yes, in high res mode the pixels aren't remotely square. The original chipset can do 320x256 or 640x256 (for PAL, 200 for NTSC) by adjusting the pixel clock, and is coupled very tightly to the TV standard. The ECS chipset added a 1280x256 mode and some limited multiscan modes, and the AGA chipset added a lot more flexibility regarding scanrates.

_________________
~ 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  [ 22 posts ]  Go to page 1, 2, 3  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:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Translated by Xaphos © 2007, 2008, 2009 phpBB.fr