MiSTer FPGA Forum

rickdangerous wrote: ↑Wed May 27, 2020 3:57 pm I have the source ported to MiSTer but the SDRAM is not working. Maybe someone could help.

benitoss wrote: ↑Fri Jun 05, 2020 9:27 pm As you can see in the pictures the core can read the VHD image and load the firmware of the TBLue and several files of the VHD image file.
Now I am working in the memory part, the idea is similar than the Spectum core. The initial memory logic is done as a dual port but everything goes to the SRAM. So, we need to put the vram memory (16 Kb block X 6 bocks consecutively, 3 blocks for layer2 and another 3 blocks for shadow layer2) in total 96 Kb in the BRAM cache. The problem is that the LAyer 2 has not the same start address (it is not always in the same block of the memory, can be selected by the user through the NextOS. So I can know what is the offset of this Layer2 and apply it to read and write in the BRAM memory
All writes and reads in VRAM we send to this BRAM. The rest of the memory addresses will be handled in the SDRAM.

Sorgelig wrote: ↑Sun Jun 07, 2020 12:00 pm Where i can read technical info about Next video modes? I need to know which video modes are supported and where video frame buffers can be.

layer2_bank_eff <= (('0' & layer2_active_bank_q(6 downto 4)) + 1) & layer2_active_bank_q(3 downto 0); 

layer2_addr_eff <= (layer2_bank_eff + ("00000" & layer2_addr(16 downto 14))) & layer2_addr(13 downto 0);

Sorgelig wrote: ↑Wed Jun 10, 2020 7:08 am Need to see what communication channel is used for RPi. If it's UART then MiSTer already provides this communication, so just need to add linux app servicing Next commands.
AFAIK RPi is optional feature. It has nothing to do with ZX emulation.

Sorgelig wrote: ↑Wed Jun 10, 2020 7:08 am Need to see what communication channel is used for RPi. If it's UART then MiSTer already provides this communication, so just need to add linux app servicing Next commands.
AFAIK RPi is optional feature. It has nothing to do with ZX emulation.

Sorgelig wrote: ↑Tue Jun 09, 2020 8:13 pm if some app/game will change layer 2 position very fast, then you won't have time to re-load layer2 into BRAM.
256x192 is standard Spectrum dot clock 7MHz. SDRAM is 16bit, so every word will be fetched at 3.5MHz. If you will use 2-word burst then fetch will be every 1.75MHz. This is pretty much comfortable access time for SDRAM working at around 112MHz. So you don't need to use VRAM. You can fetch layer2 directly from SDRAM.

there is another strategy for MiSTer: use DDR3 for layer2. DDR3 should be write only from CPU. Write access to DDR3 is usually immediate as you don't have to wait for data. The video system will fetch the video data sequentially, so you can add burst mode to fetch for example a whole line to BRAM buffer and while it renders the line from BRAM to screen, you can prefetch another line from DDR3 to second BRAM buffer.

So, there are several ways to handle the video buffer.

benitoss wrote: ↑Thu Jun 11, 2020 4:09 am Here You have the two screens of configuration

photo_2020-06-10_22-54-09.jpg

photo_2020-06-10_22-54-19.jpg

Everything is working now ( VGA (15 Khz and 31 Khz), HDMI, Keyboard, joysticks, sound , and the second SD or VHD file) unless the 2 MB of memory in SDRAM.
All tests done in BRAM (maximum 400 Kb available) are good but the system has not enough memory to start the menu system.
If I solve the SDRAM memory issue the core is gonna work perfectly.

Later I can add the RTC, the UART WIFI and simulate the PI system with a UART and I2S connection (very similar that the emulation of the Munt is doing in the ao486 core, in fact we can use similar program that the Pi uses)

Regards

benitoss wrote: ↑Wed Jun 10, 2020 2:52 pm Thanks for the answer. I appreciate it
Could you give me a core example of your first strategy ?

Regards