Core porting questions

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Wed Oct 18, 2017 8:37 am

udo wrote:Oh thanks I missed the hints in the Porting guide. So they are "only" needed for the hdmi scaler? VGA Output should work without them too?
So far I can not try it on target, because my IO-Board is still not here ...

These signals are used for VGA too. For blanking and OSD. See the sys.top.v source - it's not so big to explore.

Even though you want only ST core, i suggest to learn on more simple cores. Since many cores are ported from MiST, you can compare both versions of same core. Again - simpler core is better for start.

olin
Atari maniac
Atari maniac
Posts: 88
Joined: Tue Nov 21, 2017 8:57 pm

Re: Core porting questions

Postby olin » Tue Feb 06, 2018 8:21 pm

Another technical question:

While compiling QL core and Apple II core for DE0ns the fitter stops and complains that the device does not have enough memory M10K blocks:

Code: Select all

Error (170048): Selected device has 270 RAM location(s) of type M10K block.  However, the current design needs more than 270 to successfully fit


I found out the memory blocks are probably defined in "altsyncram" altera IP (or megafunction?), but I can not find how to view these IP blocks or modify them in Quartus 17.1 (I can only see the .v generated source). They don't appear in IP component list (only pll and pll_hdmi are listed there). If it is trivial to find and edit parameters of these memory blocks, could you point me where I can do it in Quartus? Or if there is anything else I could do (apart form rewriting the whole core, or porting it so use SDRAM) please let me know (like remove specific built-in catridge or extra add-on roms etc.).

EDIT: the X68000 core has a similar issue:

Code: Select all

Info (170034): Selected device has 270 memory locations of type M10K block. The current design requires 277 memory locations of type M10K block to successfully fit.
Info (170043): The Fitter setting for Equivalent RAM and MLAB Paused Read Capabilities is currently set to Care. More RAMs may be placed in MLAB locations if a different paused read behavior is allowed.
   Logic utilization (in ALMs)   12,370 / 15,880 ( 78 % )
   Total block memory bits   1,715,936 / 2,764,800 ( 62 % )

How to change a memory design to use MLAB location rather than M10K block for some of the memory blocks?

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Core porting questions

Postby ijor » Wed Feb 07, 2018 1:13 am

olin wrote:I found out the memory blocks are probably defined in "altsyncram" altera IP (or megafunction?), but I can not find how to view these IP blocks or modify them in Quartus 17.1 (I can only see the .v generated source). They don't appear in IP component list (only pll and pll_hdmi are listed there). If it is trivial to find and edit parameters of these memory blocks, could you point me where I can do it in Quartus?


Memory block can be explicitly instantiated, such as when using megafunctions, but can also be inferred from the HDL source code. In the latter case you won't see any parameters, and won't appear in any IP component.

Or if there is anything else I could do (apart form rewriting the whole core, or porting it so use SDRAM) please let me know (like remove specific built-in catridge or extra add-on roms etc.).


There is no trivial method without being familiar with the core. The only possibility without modifying the code is to disable RAM blocks usage, so that they won't be inferred, at least for some of the cases. It is possible to use logic blocks as RAM, but it is slow and it might take too much space.

Info (170043): The Fitter setting for Equivalent RAM and MLAB Paused Read Capabilities is currently set to Care. More RAMs may be placed in MLAB locations if a different paused read behavior is allowed ...
How to change a memory design to use MLAB location rather than M10K block for some of the memory blocks?


See this: http://quartushelp.altera.com/15.0/merg ... lities.htm

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Wed Feb 07, 2018 7:32 am

if at least synthesizer part finished before this error, then it's better to view compilation report. Look into "Resource utilization by Entity" and there you will have idea which module allocates M10K.

olin
Atari maniac
Atari maniac
Posts: 88
Joined: Tue Nov 21, 2017 8:57 pm

Re: Core porting questions

Postby olin » Thu Feb 08, 2018 11:57 pm

Thanks for the tips. I've managed to find the RAM definition in apple ii core and decrease it from 256kb to 128kb. The core now builds and I can run some games on it as well. I understand that some software that requires more than 128kb will not run, but still better than not having the core at all.

The X68000 will be probably tougher to resolve as it has plenty of small memory areas like 1x256 bits - I think that's the reason why the design doesn't fit. The small memory area probably occupies the whole M10kbit ram block and wastes 90% of it. I guess if I could somehow join 8 to 32 of these areas to occupy the same M10k block I could save enough ram blocks, but that would need some code changes how the data bits are retrieved (8x256) or addressed (1x 2048) from the memory block. My very naive idea would be to fit an intermediate module between the ram block (altsyncram) and the part that access it, which would do the address or bit position translation (Edit: oh wait, that means only one access to the M10k block at a time, instead of parallel access to all of them at the same time., hmm...this might not work). I'm sure there is other solutions...

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Core porting questions

Postby ijor » Fri Feb 09, 2018 2:20 am

olin wrote:The X68000 will be probably tougher to resolve as it has plenty of small memory areas like 1x256 bits - I think that's the reason why the design doesn't fit. The small memory area probably occupies the whole M10kbit ram block and wastes 90% of it. I guess if I could somehow join 8 to 32 of these areas to occupy the same M10k block I could save enough ram blocks ...


You can merge two single port blocks into one dual port. Because they are dual port, they still can be accessed both of them independently at the same cycle ...

I could swear that the fitter could do some of that automatically, or at least some versions of Quartus. But right now I can't find any setting to control merging of RAM blocks.

Also note that small blocks are good candidates to be replaced with standard logic. You do can change some compiler settings for this purpose.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Fri Feb 09, 2018 6:50 am

X68000 is far from usable state - most of games don't work or have a lot of glitches. So, you can simply skip this core - you won't loose anything.

GreyRogue
Atari maniac
Atari maniac
Posts: 89
Joined: Thu Mar 22, 2018 3:50 am

Re: Core porting questions

Postby GreyRogue » Thu Mar 22, 2018 4:02 am

So, I just made a quick mod to support loading 32KiB save files in the NES core, (created an 8K Zelda save file in an emulator and pasted it 4x). I used the File Config (F) to do this. In order to support writing a sav file, I assume I'll have to switch to the mounted image (S) type instead, true? Since it will only contain just the one file, is direct sector addressing a good idea or should the image be FAT formatted? Is there already existing FPGA code that can save a chunk of the SDRAM to a file? Or is maybe the code in the Spectrum core a good place to start copying/modifying from?
I think the idea is to disable the NES clock when the user selects a write save option from the OSD and perform the write, and then re-enable the clock when done. At least as a first step. Maybe switch to immediate writes after this is working.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Thu Mar 22, 2018 7:39 am

Currently there is no option opposite to F, i.e. save to file due to some reasons. And you are right, currently there is only way to save something is to use S (Mount) option.
The mounted image is simple file on SD card. What you will write in this image is up to you. You don't need to format it if you don't need and just write directly to sectors which is just offsets inside the mounted file.

MiSTer supports automounting of "/<core_folder>/boot.vhd" image upon core boot. You can add "S" option explicitly to allow to change the image to other virtual memory card.

I suggest to use the same format as NES memory cards, so you will be able to re-use the same mounted image for several games. Card managing will be do by NES code. You just need to implement the memory card hardware.

There are many cores supporting write including ZX. The signals used for write/read of mounted image are sd_*
ZX core implements disk hardware, so the whole implementation may look a little complicated. So you just need to check how core uses the sd_* signals.

Basically the usage is simple, similar to HDD LBA access:
1) core sets the desired offset in sd_lba (unit is 512bytes) and activates sd_wr or sd_rd signal
2) HPS activates sd_ack to signal that soon block will be sent/received (block of 512bytes)
3) HPS starts to send the data through sd_buff_* signals (HPS pulses sd_buff_wr when HPS sends the data, or simply changes the sd_buff_addr if HPS receives the data). These signals are compatible with altsyncram, so can be directly connected to memory block of 512bytes. Just make sure hps_io and altsyncram use the same clock - you can see connection in ZX core.
4) HPS deactivates sd_ack which means the transfer is done.

img_* signals are also related to S option.

User avatar
Newsdee
Atari God
Atari God
Posts: 1226
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Thu Mar 22, 2018 9:22 am

Save/SRAM support for NES would be fantastic... it's the one key feature we are still missing for the core to be completed!

GreyRogue
Atari maniac
Atari maniac
Posts: 89
Joined: Thu Mar 22, 2018 3:50 am

Re: Core porting questions

Postby GreyRogue » Mon Apr 02, 2018 2:37 am

Well, that took longer than I would have liked, but considering this is the first time I've ever looked at FPGA programming, I guess it wasn't too bad. Not having an IO board is brutal, though. 30+minutes for every minor change or even changing what I want to monitor with Signal Tap is quite a time sink.

It looks like it works now, though. Somebody who knows what they're doing should take a look at it though. Back up any files you care about before using.

Sorgelig wrote:I suggest to use the same format as NES memory cards, so you will be able to re-use the same mounted image for several games. Card managing will be do by NES code. You just need to implement the memory card hardware.

The NES doesn't use memory cards. Games that support saves have a RAM chip in the cart with a battery attached. The save is just the contents of the RAM. Either 0x2000 or 0x8000 bytes in size (actually there might be some smaller EPROMs as well, and the Famicom Disk System is different as well, but I don't think that's in the current core). Your notes were very helpful. Thanks.

Usage:
Requires an existing save file (either 0x2000 or 0x8000) in size.
After having loaded a game, select an image file from the OSD. The NES will load the save and reset.
When done playing, Select Save RAM write. The previously selected sav file will be overwritten and the NES will reset.
It looks like sometimes the game gets in a weird state. Reloading the ROM seems to correct it. I never disabled the NES while the saves are being accessed, which is probably causing it to overwrite ROM data.

I noticed that line 626 in apu.sv looks wrong to me. Pretty sure that >= should just be an ==.
Edit: Ignore this comment. I misunderstood the logic. >= is correct.
Last edited by GreyRogue on Mon Apr 02, 2018 1:14 pm, edited 1 time in total.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Mon Apr 02, 2018 6:26 am

Are you posting your code somewhere?

GreyRogue wrote:The NES doesn't use memory cards. Games that support saves have a RAM chip in the cart with a battery attached. The save is just the contents of the RAM.

I think i can add custom support for NES core from HPS side. I can add auto-mounting the save file with every ROM loading. For example, if there is the same file name as ROM with .sav extension, then it will be automatically mounted.

P.S.: i think, it can be a standard feature for all cores rather than NES only. Potentially every console can use this feature.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Mon Apr 02, 2018 9:26 am

GreyRogue wrote:Well, that took longer than I would have liked, but considering this is the first time I've ever looked at FPGA programming, I guess it wasn't too bad. Not having an IO board is brutal, though. 30+minutes for every minor change or even changing what I want to monitor with Signal Tap is quite a time sink.

i suggest to use lite revision for debug compilations. It reduces compilation times twice or more. But you will need to use VGA output.

GreyRogue
Atari maniac
Atari maniac
Posts: 89
Joined: Thu Mar 22, 2018 3:50 am

Re: Core porting questions

Postby GreyRogue » Mon Apr 02, 2018 11:52 am

Sorgelig wrote:
GreyRogue wrote:Well, that took longer than I would have liked, but considering this is the first time I've ever looked at FPGA programming, I guess it wasn't too bad. Not having an IO board is brutal, though. 30+minutes for every minor change or even changing what I want to monitor with Signal Tap is quite a time sink.

i suggest to use lite revision for debug compilations. It reduces compilation times twice or more. But you will need to use VGA output.

Doesn't that require the IO Board?

My code is the only fork of the NES Mister core in GitHub.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Mon Apr 02, 2018 5:26 pm

GreyRogue wrote:Doesn't that require the IO Board?

yes. It needs IO Board. Original idea for I/O board was for debugging, and later it developed to where it is :)

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Mon Apr 02, 2018 5:29 pm

GreyRogue wrote:My code is the only fork of the NES Mister core in GitHub.

please make a pull request to my repository, so i will merge your changes

NegSol
Captain Atari
Captain Atari
Posts: 268
Joined: Sat Dec 05, 2015 9:22 pm

Re: Core porting questions

Postby NegSol » Mon Apr 02, 2018 7:27 pm

Sorgelig wrote:P.S.: i think, it can be a standard feature for all cores rather than NES only. Potentially every console can use this feature.


Great progress guys! I really hope this can be ported over to the GB core as well - it should be really similar to the NES approach - one save per rom should be enough for everyone :mrgreen:
:cheers:

User avatar
Newsdee
Atari God
Atari God
Posts: 1226
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Tue Apr 03, 2018 12:09 am

Sorgelig wrote:P.S.: i think, it can be a standard feature for all cores rather than NES only. Potentially every console can use this feature.

Yes, this would be extremely useful. It would also benefit the GB and Genesis cores at least. For SMS/GG only a handful of games support saves but having the option would be good. For PC Engine I think the save works differently but it can perhaps be made to fit (not many Hucard games support saves anyway).

With this it will be possible to play long games on the MiSTer!

GreyRogue
Atari maniac
Atari maniac
Posts: 89
Joined: Thu Mar 22, 2018 3:50 am

Re: Core porting questions

Postby GreyRogue » Tue Apr 03, 2018 2:38 am

Sorgelig wrote:
GreyRogue wrote:My code is the only fork of the NES Mister core in GitHub.

please make a pull request to my repository, so i will merge your changes

While testing the save feature, I noticed in the Legend of Zelda that the chime that plays when selecting which slot to use was missing. I just figured it out. The Square Wave generators are supposed to have a minimum period of 8. The code looks like it was trying to do Period/8 >= 1 (i.e. Period >= 8 ), but accidently did Period/8>=8 (i.e. Period >= 64 [8*8] ). This meant that anything higher than two and a half octaves above middle C (~1700Hz) wouldn't play. The Square wave should play three octaves higher than that. This fixes the chime in The Legend of Zelda, and the Super Mario Bros 3 missing sound effect mentioned here:
https://github.com/mist-devel/mist-board/issues/42
I added this into the pull request as well.

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Tue Apr 03, 2018 3:17 am

It's good that NES got some attention and it's not from me :)
Thanks!

User avatar
Newsdee
Atari God
Atari God
Posts: 1226
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Tue Apr 03, 2018 5:57 am

Great work! The sound was also a long standing bug!

Time for me to update the compatibility spreadsheet :)
https://docs.google.com/spreadsheets/d/ ... p=drivesdk

User avatar
Newsdee
Atari God
Atari God
Posts: 1226
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Wed May 23, 2018 2:32 pm

Can somebody add the full build (i.e. with HDMI) to the repository?

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Wed May 23, 2018 3:01 pm

i totally forgot about it.
Will check it and compile

Sorgelig
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3160
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting questions

Postby Sorgelig » Wed May 23, 2018 3:12 pm

What game i can use to test the saves?

User avatar
Newsdee
Atari God
Atari God
Posts: 1226
Joined: Fri Sep 19, 2014 8:40 am

Re: Core porting questions

Postby Newsdee » Wed May 23, 2018 3:32 pm

Sorgelig wrote:What game i can use to test the saves?

Legend of Zelda! :D


Return to “MiSTer”

Who is online

Users browsing this forum: No registered users and 4 guests