Core porting, empty template?

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

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

hrvoje
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Core porting, empty template?

Post by hrvoje »

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
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 102
Joined: Fri Sep 11, 2015 8:10 pm

Re: Core porting, empty template?

Post by hubersn »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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

hrvoje
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

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
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

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.

hrvoje
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

Long time without a reply, but I wasn't idle - the core is operational and not that awful. I plan to release the sources before the month is over. Can't build the RBF with VIP scaler / HDMI since I don't have a full Quartus Prime.

I know it's not the greatest contribution to MiSTer due to limited software available, but it's one of the oldest platforms anywhere running the oldest real computer game from the original tape. Must have that as a retro gaming console! :)

Could you please advise how could I convert 1080p output to 1080i or 720p ? I'm trying to feed it into a HDMI recorder and it seems too much bandwidth for it to handle.

Is is enough to configure width, hfp, hs ... etc in sys_top.v and change fpga pll pixel clock from 148.5 MHz to 74.25 MHz ?
I've tried setting the progressive/interlaced flag in vip_config.sv to 1, halving the video clock to 74.25 and adjusting the parameters in sys_top.v but it didn't work. What did I forget?

Thanks!

Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: Core porting, empty template?

Post by Sorgelig »

default HDMI resolution is 720p.
Interlaced HDMI output is not implemented.

hrvoje
Atari nerd
Atari nerd
Posts: 44
Joined: Wed Nov 29, 2017 1:32 pm

Re: Core porting, empty template?

Post by hrvoje »

Sorgelig wrote:default HDMI resolution is 720p.
Interlaced HDMI output is not implemented.
Thanks for the tip, I didn't know that. I started with Arcade-Defender as my template and its sys_top.v specifies:

//1920x1080@60 PCLK=148.5MHz CEA
reg [11:0] WIDTH = 1920;
reg [11:0] HEIGHT = 1080;
...

Arcade-Galaga has

//Output video parameters.
//It's good to keep 1280x720@60 resolution among all cores as most compatible resolution.
parameter WIDTH = 1280;
parameter HEIGHT = 720;

Are some arcade cores built with different output resolution? Thanks again!

Locked

Return to “MiSTer”