Amiga RTG support (Update: Released!)
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Sponsoring RTG support
Currently it's only implemented on the Turbo Chameleon 64, which has the same FPGA as the MiST (as opposed to MiSTer) but no supporting host CPU. It shouldn't be too difficult to port to other devices though. (It does also work on the DE10-lite, since I use one of those as a dev platform - but that's a totally different board, not remotely similar to the DE10-nano.)
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Sponsoring RTG support
I do, yes - however I had to make some changes when porting the core to TC64 which broke the MiST build in my repo - I haven't got around to un-breaking it yet!
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Sponsoring RTG support
Thanks for the offer - it's much appreciated. However, I think wheels are already in motion to bring a MiSTer my way - I'll let you know if for any reason it doesn't happen, if that's OK?
- Sorgelig
- Site Admin
- Posts: 882
- Joined: Thu May 21, 2020 9:49 pm
- Has thanked: 2 times
- Been thanked: 212 times
Re: Sponsoring RTG support
Recent MiSTer framework supports framebuffer from DDR3 supplied by core. So the proper way for RTG is to use framebuffer.
Basically it's just another memory region in DDR3 (left some space in DDR3 exactly for RTG). For me, the hardest part is Amiga side, not HDL. Resolution on RTG for MiSTer isn't a problem. Up to 1920x1080 can be easily supported.
Modification is SDRAM is not required. SDRAM is only for Chip RAM.
Basically it's just another memory region in DDR3 (left some space in DDR3 exactly for RTG). For me, the hardest part is Amiga side, not HDL. Resolution on RTG for MiSTer isn't a problem. Up to 1920x1080 can be easily supported.
Modification is SDRAM is not required. SDRAM is only for Chip RAM.
Re: Sponsoring RTG support
checking if the care package has departed lol
Ultimate MiSTer Blissbox pro version, Replay Vidor version, Replay 2, Real Amiga's 500+, 500+ with pi storm, a1200 in cd32 special edition case. https://www.twitch.tv/uigiflip
Re: Sponsoring RTG support
Checked will be dispatched next week
Ultimate MiSTer Blissbox pro version, Replay Vidor version, Replay 2, Real Amiga's 500+, 500+ with pi storm, a1200 in cd32 special edition case. https://www.twitch.tv/uigiflip
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Sponsoring RTG support
Well having done it once, the software side's easy for me now.
With the framebuffer approach, does the Amiga still need to set up a CRTC frame with sync/blank counters, or is that all handled host-side with the MiSTer framework?
Sure - I did say that would be necessary for a *direct port* of what I already have working - but I realise on the MiSTer there's a better approach.Modification is SDRAM is not required. SDRAM is only for Chip RAM.
- Grabulosaure
- Core Developer
- Posts: 78
- Joined: Sun May 24, 2020 7:41 pm
- Location: Mesozoic
- Has thanked: 3 times
- Been thanked: 92 times
- Contact:
Re: Sponsoring RTG support
@robinsonb5
The idea is to use the scaler to generate the image. You provide image size, colour depth, base address and a switch to activate the thing and it will display your framebuffer instead of the existing MiniMig core output. This is how the framebuffer mode (F9 from menu) works.
(colour depths are 256c indexed, 16bits 565 RGB, 24bits RGB, 32bits RGB_)
Constraint is that line length is rounded to 256 bytes (example 800 pixels, 24bits = 2400 bytes => 2560 bytes per line)
The idea is to use the scaler to generate the image. You provide image size, colour depth, base address and a switch to activate the thing and it will display your framebuffer instead of the existing MiniMig core output. This is how the framebuffer mode (F9 from menu) works.
(colour depths are 256c indexed, 16bits 565 RGB, 24bits RGB, 32bits RGB_)
Constraint is that line length is rounded to 256 bytes (example 800 pixels, 24bits = 2400 bytes => 2560 bytes per line)
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Sponsoring RTG support
Awesome - many thanks for that.
OK, so the timings created in Picasso96Mode will be irrelevant - only the dimensions and pixel format will be needed.Grabulosaure wrote: ↑Sun Jul 19, 2020 8:48 pm The idea is to use the scaler to generate the image. You provide image size, colour depth, base address and a switch to activate the thing and it will display your framebuffer instead of the existing MiniMig core output.
OK, I've just done a quick test and it doesn't look like rounding up the row size will be a problem.Constraint is that line length is rounded to 256 bytes (example 800 pixels, 24bits = 2400 bytes => 2560 bytes per line)
- Sorgelig
- Site Admin
- Posts: 882
- Joined: Thu May 21, 2020 9:49 pm
- Has thanked: 2 times
- Been thanked: 212 times
Re: Sponsoring RTG support
ascal has been changed already current version in template has stride granularity of 16 bytes so it should be not a problem for RTG resolutions.robinsonb5 wrote: ↑Sun Jul 19, 2020 9:40 pm OK, I've just done a quick test and it doesn't look like rounding up the row size will be a problem.
Soon it will be updated with 1 pixel granularity.
I'm currently working on SVGA in ao486 which is basically similar to RTG on Amiga and uses framebuffer in DDR3.
Yes and no. HSync/Vsync has to be generated anyway from the core as scaler does sync to video. So basically scaler needs to know how fast to draw the video. But anyway it can be simplified as you don't need to generate blanking. Just HSync/Vsync will be enough.robinsonb5 wrote: ↑Sun Jul 19, 2020 9:40 pm OK, so the timings created in Picasso96Mode will be irrelevant - only the dimensions and pixel format will be needed.
- Grabulosaure
- Core Developer
- Posts: 78
- Joined: Sun May 24, 2020 7:41 pm
- Location: Mesozoic
- Has thanked: 3 times
- Been thanked: 92 times
- Contact:
Re: Sponsoring RTG support
@robinsonb5
@sorgelig
When using vsync_adjust=2, the scaler (actually a separate block in sys) tries to synchronise input video with scaled output. If the framebuffer mode is used, that same block willl still try to synchronize video, even if the "input video" isn't displayed anymore.
I don't know how RTG boards work, but if some boards used synchro pulses as interrupts, or for double buffering, then the hsync/vsync signals generated by the scaler will be needed as inputs.
@sorgelig
When using vsync_adjust=2, the scaler (actually a separate block in sys) tries to synchronise input video with scaled output. If the framebuffer mode is used, that same block willl still try to synchronize video, even if the "input video" isn't displayed anymore.
I don't know how RTG boards work, but if some boards used synchro pulses as interrupts, or for double buffering, then the hsync/vsync signals generated by the scaler will be needed as inputs.
- Sorgelig
- Site Admin
- Posts: 882
- Joined: Thu May 21, 2020 9:49 pm
- Has thanked: 2 times
- Been thanked: 212 times
Re: Sponsoring RTG support
this is why i've wrote above that even in framebuffer mode the core should generate the hsync/vsync.Grabulosaure wrote: ↑Wed Jul 29, 2020 11:44 am @robinsonb5
@sorgelig
When using vsync_adjust=2, the scaler (actually a separate block in sys) tries to synchronise input video with scaled output. If the framebuffer mode is used, that same block willl still try to synchronize video, even if the "input video" isn't displayed anymore.
I don't know how RTG boards work, but if some boards used synchro pulses as interrupts, or for double buffering, then the hsync/vsync signals generated by the scaler will be needed as inputs.
Getting sync signals from output video back to core is not an universal solution. Some cores may also need hblank/vblank for internal work. Also core may need to generate specific refresh rate instead a standard. So it's better if core will generate hsync/vsync (together with other sync signals if required) and then scaler will sync to it (if asked) as usual.
- Grabulosaure
- Core Developer
- Posts: 78
- Joined: Sun May 24, 2020 7:41 pm
- Location: Mesozoic
- Has thanked: 3 times
- Been thanked: 92 times
- Contact:
Re: Sponsoring RTG support
@sorgelig @robinsonb5
Besides HSYNC/VSYNC, The DE "Display Enable" is needed for synchronisation (because the scaled image must be aligned with the top or bottom of the input image.
The transparent multi-buffering done by the scaler isn't available in framebuffer mode.
Many options are available, such as ignoring synchronization and allow tearing, or use HDMI sync signals to software in RTG mode, or using that synchro for transparent multi-buffering : This is how works the GBA core in framebuffer mode, using the signal fb_vbl = hdmi_vblk, to synchronize multi-buffer switch with HDMI output : The software always has the original vertical frequency independantly from HDMI video mode, and double-buffering is done by the core instead of the scaler.
Besides HSYNC/VSYNC, The DE "Display Enable" is needed for synchronisation (because the scaled image must be aligned with the top or bottom of the input image.
The transparent multi-buffering done by the scaler isn't available in framebuffer mode.
Many options are available, such as ignoring synchronization and allow tearing, or use HDMI sync signals to software in RTG mode, or using that synchro for transparent multi-buffering : This is how works the GBA core in framebuffer mode, using the signal fb_vbl = hdmi_vblk, to synchronize multi-buffer switch with HDMI output : The software always has the original vertical frequency independantly from HDMI video mode, and double-buffering is done by the core instead of the scaler.
- Sorgelig
- Site Admin
- Posts: 882
- Joined: Thu May 21, 2020 9:49 pm
- Has thanked: 2 times
- Been thanked: 212 times
Re: Sponsoring RTG support
Right. This is again toward my original post - core needs to generate its sync signals in framebuffer mode. So it will control multiple buffers itself and scaler will follow the vsync.
- Grabulosaure
- Core Developer
- Posts: 78
- Joined: Sun May 24, 2020 7:41 pm
- Location: Mesozoic
- Has thanked: 3 times
- Been thanked: 92 times
- Contact:
Re: Sponsoring RTG support
Typically the analog out port can display "normal" Amiga video (OCS/ECS...) while HDMI will display the RTG output.
Re: Sponsoring RTG support
“Typically” on real Amiga, yes, but this is MiSTer, it already displays native modes on HDMI, and the analogue port seems to mirror what’s on the HDMI, so I suspect it’s not possible to seperate them.
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Sponsoring RTG support
Thanks for the useful info, Sorgelig and Grabulosaure.
I get the impression that it's the other way around - the HDMI normally mirrors what's on the analogue port, but doesn't have to - for RTG mode it can be made to display something different instead.
-
- Posts: 24
- Joined: Wed Jun 17, 2020 6:04 am
Re: Sponsoring RTG support
Although I'm sporting a monitor that can take 15kHz on the VGA, and does auto-switching between these inputs (Acer G276HL Kbix). Having additional options is always pretty cool.
In most cases, you end up with one of these screens displaying nothing but the static. I would imagine that the most people using de10-nano are either plugging a modern HDMI monitor or CRT for the VGA (if they have the analog IO board).
Though, you can't expand out the WB over two screens, like in windows. You can however run one program on screen1 and second program on screen 2 at the same time.
SpringMaus is a small utility for using 2 monitors with AmigaOS
http://www.steamdraw.homepage.t-online.de/
- Newsdee
- Top Contributor
- Posts: 830
- Joined: Mon May 25, 2020 1:07 am
- Has thanked: 98 times
- Been thanked: 209 times
Re: Sponsoring RTG support
We (Norway) say "selling the skin before the bear is shot", and from experience, this is the business model of many IT companies
Anyways, was just curious. Back in the days of CBM, this was how RTG was done on Amiga with EGS - you run most regular software on native RGB and dedicated EGS software on the graphics card output - two monitors required. On my A3000 I even had three monitors - native rgb, CVPPC and CV64, all working just fine (CyberGraphX 4) - and no garbled output on any, there are switches (env vars) that tell the RTG to keep all screens active and clear.
EDIT: Someone made youtube video presenting EGS - https://youtu.be/kFHdxdG2Hyc
If CMB/Amiga had not folded, EGS would probably have been the standard "classic" Amiga would have taken for graphics, I remember lots of discussions regarding "workbench emulation" with EGS - the "current" RTGs came years later, CyberGraphX in 1995 and Picasso96 in 1996, long after CBM was gone
Re: Sponsoring RTG support
I would personally love to see RTG added to the MiniMig core so that my newer ports could be playable on the MiSTer (which I have just brought ).
I just released a special build of ZDOOM AGA with 030 support that I hope is playable on the current MiniMig core. I can easily recompile more current RTG 060 ports for 030 if we can get RTG support.
Are there any plans to further enhance the speed of the current 020 MiniMig core, add FPU support or to maybe expand it with basic 040/060 support?
I just released a special build of ZDOOM AGA with 030 support that I hope is playable on the current MiniMig core. I can easily recompile more current RTG 060 ports for 030 if we can get RTG support.
Are there any plans to further enhance the speed of the current 020 MiniMig core, add FPU support or to maybe expand it with basic 040/060 support?
Re: Sponsoring RTG support
Strictly speaking, Minimig is the chipset and the CPU cores are Fx68k for 68000 and TG68 for 020. For discussions regarding the CPU cores, there are threads over at atari-forum.com
What has been discussed here is so called “hybrid emulation”, using software CPU, emulated 68k on the ARM CPU, along with chipset on FPGA.
What has been discussed here is so called “hybrid emulation”, using software CPU, emulated 68k on the ARM CPU, along with chipset on FPGA.
Re: Sponsoring RTG support
Hi Kolla,
Long time, no see
Yes that makes sense re the 'hybrid emulation' it has also been discussed on the Amiga forums (using something like a Raspberry Pi Zero + FPGA to simulate a real 68K CPU).
Long time, no see
Yes that makes sense re the 'hybrid emulation' it has also been discussed on the Amiga forums (using something like a Raspberry Pi Zero + FPGA to simulate a real 68K CPU).