Core porting, empty template?

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

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

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Core porting, empty template?

Postby hrvoje » Sat Oct 13, 2018 11:56 am

Hello,

I've been having fun trying to implement a DEC PDP emulator to run some old games in Verilog as part of a "teach yourself about FPGA" week I've been having. After getting it to work on a DE0 Nano (which is a Cyclone IV) and a 4-bit VGA output, I would like to integrate it with MiSTer / HDMI.

However, I have no idea where to start. I've read the core porting notes and this was educational, but the learning curve is quite steep.

Is there anyone kind enough who could give me a few pointers, or put together a "boilerplate" minimal, blank core project (for example which only generates a red video background) I could open in Quartus and compile?

Thanks a lot and keep up the awesome work!

Hrvoje

hubersn
Atari User
Atari User
Posts: 35
Joined: Fri Sep 11, 2015 8:10 pm

Re: Core porting, empty template?

Postby hubersn » Sat Oct 13, 2018 12:44 pm

hrvoje wrote:Is there anyone kind enough who could give me a few pointers, or put together a "boilerplate" minimal, blank core project (for example which only generates a red video background) I could open in Quartus and compile?


There are the original MIST tutorials by Till:
https://github.com/mist-devel/mist-boar ... /tutorials

I guess these should be (easily?) portable to MISTer.

Have fun
hubersn

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

Re: Core porting, empty template?

Postby Sorgelig » Sat Oct 13, 2018 2:40 pm

Almost any arcade core can be treated as a template - they are simple and have good point to split original arcade from MiSTer specific part.

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Sat Oct 13, 2018 6:05 pm

Sorgelig wrote:Almost any arcade core can be treated as a template - they are simple and have good point to split original arcade from MiSTer specific part.


Thanks for your quick response. Which arcade core would you recommend as a good example?

If I manage to get something working, I will try to contribute with some documentation about the process.

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

Re: Core porting, empty template?

Postby Sorgelig » Sat Oct 13, 2018 11:48 pm

hrvoje wrote:Which arcade core would you recommend as a good example?

Take Defender.
In Arcade-Defender.sv replace the instance defender by instance of your core.

hrvoje wrote:If I manage to get something working, I will try to contribute with some documentation about the process.

Doc(Wiki) from first porting experience would be good!

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Sun Oct 14, 2018 2:00 pm

Sorgelig wrote:Doc(Wiki) from first porting experience would be good!


Thank you very much for your advice! I will try my best.

In my current Cyclone IV attempt, I generate VGA with a simple 4-bit R-2R DAC and I know how to make a VGA signal. I've never done HDMI, can you please point me in the right direction - what kind of signal is expected on the HDMI connections (HDMI_R/G/B, HS, VS etc...) from my core? Same values and timings as VGA I'm currently outputting or something else?

Thanks again!

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

Re: Core porting, empty template?

Postby Sorgelig » Sun Oct 14, 2018 2:34 pm

hrvoje wrote:In my current Cyclone IV attempt, I generate VGA with a simple 4-bit R-2R DAC and I know how to make a VGA signal. I've never done HDMI, can you please point me in the right direction - what kind of signal is expected on the HDMI connections (HDMI_R/G/B, HS, VS etc...) from my core? Same values and timings as VGA I'm currently outputting or something else?

HDMI is handled by special chip. After proper configuration the output signals to this chip are identical to VGA signals. The only notable difference is requirement of DE signal. This signal is basically DE = ~(HBLANK | VBLANK). Also HDMI requires pixel clock because it's digital interface.
Ah, i've forgot that Arcade cores have separate video for HDMI to make a rotation.
Ok, forget about arcade as a sample :)

Take Jupiter ACE core as a sample. It's as simple as arcade and doesn't have separate HDMI signals - so easier to connect to your core.

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

Re: Core porting, empty template?

Postby Sorgelig » Sun Oct 14, 2018 2:37 pm

Actually, you can take even Genesis core - it has simple connection to MiSTer API and includes all latest changes to API and framework.

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Sun Oct 14, 2018 9:13 pm

Sorgelig wrote:Actually, you can take even Genesis core - it has simple connection to MiSTer API and includes all latest changes to API and framework.


After a lot of fiddling around, I did manage to compile the Jupiter ACE with Quartus 16.1, so the first milestone is achieved. Lesson learned - the lite version is needed, because the compiling the regular one takes unbelievably long. Is there some trick I should know about, or every single change really needs that long to compile?

What's the deal with clocks? Do I need to set up an additional PLL to generate, let's say, 148.5 MHz pixel clock for 1920x1080p @ 60 Hz?

Should I just plug the horizontal/vertical sync and R, G, B as input to an instance of video_mixer module?

Please excuse my questions, I have nobody else to ask because nobody I know knows anything about FPGA and I really want to teach myself how to do this...

Thanks a lot for your help and guidance!

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

Re: Core porting, empty template?

Postby Sorgelig » Sun Oct 14, 2018 9:42 pm

HDMI clocks are handled in framework (sys_top.v) with separate PLL and you don't need to care about it.
Your entry is instance of your module inside the emu module. Everything in upper layer should not be touched. Also hps_io should be included in emu.

Full version compilation takes long time and if your computer is not powerful enough it may take very long time. So, for development, LITE revision should be used. When everything is OK, you compile the FULL revision for release.

There is no way to compile it faster/partially except using faster computer. Amount of CPU cores don't affect compilation time much. MHz of CPU is the key feature for faster compilation.

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

Re: Core porting, empty template?

Postby Sorgelig » Sun Oct 14, 2018 9:44 pm

hrvoje wrote:Should I just plug the horizontal/vertical sync and R, G, B as input to an instance of video_mixer module?

yes. And it's very important to provide HBlank and VBlank signals as well.
Also i suggest to use video_cleaner module right after your module which will align the signal properly.

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Fri Oct 26, 2018 11:18 am

Sorgelig wrote:
hrvoje wrote:Should I just plug the horizontal/vertical sync and R, G, B as input to an instance of video_mixer module?

yes. And it's very important to provide HBlank and VBlank signals as well.
Also i suggest to use video_cleaner module right after your module which will align the signal properly.


After some waiting for the IO board to arrive, I made some progress. Video works, core works, everything was surprisingly painless. Thanks for doing a great job!

I've bound commands to PS2 scancodes which is OK, but I would also like to add joysticks.

Can you tell me about joystick_0, joystick_1 and status registers? How do I know which bit of joystick_0 corresponds to which key?

Thanks a lot!

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

Re: Core porting, empty template?

Postby Sorgelig » Fri Oct 26, 2018 11:52 am

bits 0..3 are directions (check any arcade core to make sure which direction of each bit).
bits 4..15 are buttons according to OSD option J - you can check arcade cores as well for example J usage. J1 means lock the keyboard in joystick emulation - useful for keyboard-less cores.

logic 1 - button is pressed.

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Fri Oct 26, 2018 7:09 pm

Sorgelig wrote:bits 0..3 are directions (check any arcade core to make sure which direction of each bit).
bits 4..15 are buttons according to OSD option J - you can check arcade cores as well for example J usage. J1 means lock the keyboard in joystick emulation - useful for keyboard-less cores.

logic 1 - button is pressed.


Thanks! I've managed to get the keyboard working, now joystick and re-writing the framebuffer. I'll do my best to document some of these things to help somebody else who might try developing something for MiSTer.

There is a weird issue I'm facing - I can't seem to get rid of some "info box" in upper left corner which display the video resolution and refresh rate.

It says 513x989 80.00 Khz 75.3Hz and below 1280x1024 108.00MHz 60.0Hz (which is the res I'm outputting). How do I turn this box off?

I did not yet try HDMI, but I'm still excited about getting the controls and video output working without days of debugging.

Thanks again!

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

Re: Core porting, empty template?

Postby Sorgelig » Fri Oct 26, 2018 7:54 pm

Open USB console to check there - probably you will see frequent messages about new resolution.
It's because unstable video signal your core provide.

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Fri Oct 26, 2018 8:06 pm

Sorgelig wrote:Open USB console to check there - probably you will see frequent messages about new resolution.
It's because unstable video signal your core provide.


Thanks, I'll re-check my video timings...

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Thu Nov 01, 2018 7:15 pm

Hello Sorgelig,

I've made some progress - core seems to be working relatively stable. I'm still sometimes seeing timing issues which are probably beyond my skill set to solve at this point, but I'm learning.

Is there any way to write text to something like a popup box and display it to the user as a notification? (something like that notification box informing me of resolution changes) What would be the best way for me, in your opinion, to implement the front panel switches? e.g. test word has 18 switches (on/off) which affect running of the program... it would be awesome if they could somehow be altered through the menu. Spacewar also works! It would be nice to have the very first computer game ever running on MiSTer, but also other available software for this machine.

Video



Any advice is greatly appreciated!


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

Re: Core porting, empty template?

Postby Sorgelig » Fri Nov 02, 2018 12:25 am

Cores cannot output text to popup.
As you may already know HDL is not so friendly with text string handling.

Usually emulated systems are self-contained, so they output text using emulated system resources.
For extensive overlay graphics probably you need to add second softCPU with its firmware and overlay display. OSD settings have 31 bits for options. So you can implement these 18 switches as options in menu. Probably some switches can be grouped to simplify the settings.

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Sun Nov 04, 2018 4:38 pm

Sorgelig wrote:Cores cannot output text to popup.
As you may already know HDL is not so friendly with text string handling.

Usually emulated systems are self-contained, so they output text using emulated system resources.
For extensive overlay graphics probably you need to add second softCPU with its firmware and overlay display. OSD settings have 31 bits for options. So you can implement these 18 switches as options in menu. Probably some switches can be grouped to simplify the settings.


Thanks for the hints and guidance, I've grouped the switches just like you suggested. Is there a way to implement file download asynchronously? That is, if I set ioctl_wait high, the menu will just sit there until it goes low again and download can finish. Can this be done so that the image is "attached" and the core takes as much data as it can process (control the flow with something like ioctl_wait signal) until there is no more left, but the menu isn't "frozen" until the core finishes reading the image?

Another tip for anybody reading this (which I will try to submit in documentation) - if you save options in the F12 menu and then you redefine some options in the core configuration string, you end up chasing ghosts because the options start behaving unexpectedly (because the saved file addresses the options as they were at save time). This is not really a bug, more of a "how not to waste 2 hours debugging like I did"... :)

Cheers!

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

Re: Core porting, empty template?

Postby Sorgelig » Sun Nov 04, 2018 5:03 pm

hrvoje wrote:Is there a way to implement file download asynchronously? That is, if I set ioctl_wait high, the menu will just sit there until it goes low again and download can finish. Can this be done so that the image is "attached" and the core takes as much data as it can process (control the flow with something like ioctl_wait signal) until there is no more left, but the menu isn't "frozen" until the core finishes reading the image?

ioctl_* is for downloading the whole file at once. You cannot pause it. You can download it whole to SDRAM or DDR3 and then use from there at any rate you want.
Another way is to mount the file (sd_* signals) and read/write it by blocks (512b) at any pace you want. You can see how these signals are used in several cores, for example ZX core.

hrvoje
Retro freak
Retro freak
Posts: 16
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Postby hrvoje » Thu Nov 08, 2018 9:20 pm

Sorgelig wrote:ioctl_* is for downloading the whole file at once. You cannot pause it. You can download it whole to SDRAM or DDR3 and then use from there at any rate you want.
Another way is to mount the file (sd_* signals) and read/write it by blocks (512b) at any pace you want. You can see how these signals are used in several cores, for example ZX core.


Hello,

I've successfully implemented ioctl_* interface with some timeout logic so it will be OK. Thanks for the hints and patience to answer my questions.

There are not many problems left, just one issue with video I can't figure out no matter how hard I try. Occasionally I see random pixels flashing around. What would you suggest as probable causes and if you saw this in your own project, what would you assume the problem was? I'm attaching video because text descriptions are not as good. Static dots are supposed to be there, flashing ones are not...

Thanks a million.

Video of flashing pixels


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

Re: Core porting, empty template?

Postby Sorgelig » Thu Nov 08, 2018 9:30 pm

There can be different kind of issues. It's FPGA - so it behaves like hardware. If your project is asynchronous, then it will be a result of compare some counter with value and transition between counter changes get registered. Even in synchronous project it may happen if there is complex arithmetic on the wires, so result can be delayed too much so transitions may be registered.
FPGA project problems are coming not only from real bugs but from timing issues as well.


Return to “MiSTer”

Who is online

Users browsing this forum: No registered users and 2 guests