Minimig RTG possible?

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

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

BBond007
Captain Atari
Captain Atari
Posts: 366
Joined: Wed Feb 28, 2018 3:23 am

Re: Minimig RTG possible?

Postby BBond007 » Sat Jan 12, 2019 4:42 am

Alynna wrote:Maybe i'm missing something but I've never been about to get a 1280x720 resolution on anything but RTG... But the only thing I have right now that does AGA is the MiniMig MiST.. my "real Amiga" is an A1000 with a Vampire in it O.o


Sorgelig wrote:With monitor driver 720HD you can have 1280x720i50 resolution in Workbench with AGA chipset. Also 800x600 and 1024x768 modes are available. All of them are on standard AGA chipset. On real Amiga (and MiST) it requires special Commodore monitor supporting such non-standard resolution. On MiSTer it works through HDMI on any TV.


I'm pretty sure that HD720(1280x720) and HGFX(1024x768) monitor drivers came about because of Jens Schofield's Indivision scandoubler/flicker-fixer. I don't think any Monitor, including stuff made by C= supported those modes.

EDIT:

no, I'm wrong: http://aminet.net/package/driver/moni/HighGFX40_6

- higher AGA frequencies (54 Hz 22,24 kHz -> 55 Hz 22,22 kHz)
- higher ECS frequencies (50 Hz 20,25 kHz -> 54 Hz 21,81 kHz)

Supported displays without flickerfixer:
Aydin Ranger 5015LP
Aydin Ranger 5021
Commodore 1950
Commodore 1960
Commodore 21inch FST
Eizo 8060H
Idek Iiyama MF-5017
Idek Iiyama MF-5021
Microvitec (Amiga) M1438
Microvitec (Amiga) M1538
Microvitec (Amiga) M1764
NEC Multisync 3D
Nokia 417TV
Sony CPD 1402E
Sony GVM-1310
Sony GVM-2020
and all other monitors, that supports 22kHz modes.

User avatar
Alynna
Atari freak
Atari freak
Posts: 57
Joined: Tue Sep 18, 2018 5:54 pm

Re: Minimig RTG possible?

Postby Alynna » Sat Jan 12, 2019 5:22 am

Sorgelig wrote:With monitor driver 720HD you can have 1280x720i50 resolution in Workbench with AGA chipset. Also 800x600 and 1024x768 modes are available. All of them are on standard AGA chipset. On real Amiga (and MiST) it requires special Commodore monitor supporting such non-standard resolution. On MiSTer it works through HDMI on any TV.

Still don't understand your obsession of following PAL/NTSC. RTG is VGA (and HDMI) output and has nothing to do with PAL/NTSC. So you need to follow VGA/HDMI resolutions instead. You cannot play regular games on RTG. Only specifically written for RTG games can work. And those working through Workbench video output subsystem.

And thanks to FPGA, both native and RTG video outputs can share the same video output.


I'm not obsessed with having NTSC/PAL on RTG, i've been talking about having these modes on AGA the entire time. On RTG you can have any mode because you don't have to worry about timing at all. If you can have 1280x720 on AGA on mister then theres really nothing to do there. I didn't know that tho, I'm still waiting for my I/O board and SDRAM to arrive.

PurpleMelbourne
Atariator
Atariator
Posts: 25
Joined: Mon Dec 10, 2018 12:22 pm

Re: Minimig RTG possible?

Postby PurpleMelbourne » Sat Jan 12, 2019 6:17 am

Sorgelig wrote:Thanks for book!
Second link requires registration with credit card - no way i will register such strange site.

Yeah sorry about that second link. I just did a quick search to see what I could find. That's why I added the disclaimer that I didn't know what you'd find. You've done a lot of work for everyone else, so I just hoped I could lighten your load a little bit. I'm glad the first link was good :lol:

That stuff from Dave Haynie is really interesting, I hope you find it as interesting as its been for me :D

PurpleMelbourne
Atariator
Atariator
Posts: 25
Joined: Mon Dec 10, 2018 12:22 pm

Re: Minimig RTG possible?

Postby PurpleMelbourne » Sat Jan 12, 2019 7:20 am

If you want to alter PAL or NTSC then that is a special case which MIGHT be alterable by hacking Kickstart. But other than that, all you need to worry about is the bandwidth and if the monitor accepts the resultant frequency.

I used to run a variety of monitors using almost full overscan and the monitor adjusted to shrink the picture size down. I'm a bit sketchy on the details, but I THINK it was 724 x 574 which I was using. The very last two lines came out only half length so I dropped the last pair of lines from the full 576 PAL overscan.

I used a scanmode creator, who's name I don't remember at the moment. What was required about this tool was the upper bandwidth limit so you didn't go beyond the bounds of the monitor. When I got an Silicon Graphics monitor, if you overshot the frequency then you needed to pull it back a bit to relock before again advancing the frequency forward while you remember how far you could push. So it was all a bandwidth squeeze between pixel width, frame rate, and monitor bandwidth limits.

You can duplicate and then edit an existing screenmode to create a new one. If i remember correctly (getting very sketchy now) the screen-mode information was contained either in the icon information or perhaps it was a text file (think the former) which held the frequency details.

So keeping this in mind, you should be able to make an integer multiple of x2, x3 or x4 to get just about anything that you need on your framebuffer idea. I might be wrong, but I think you might be trying to do it the hard way by altering PAL / NTSC instead of just creating a completely new screenmode in workbench which then feed into the display preferences.

I haven't got my Nano yet, so I don't know if the MISTer is different.
Hopefully my weird experiments with monitors over the years proves helpful :lol:

User avatar
Alynna
Atari freak
Atari freak
Posts: 57
Joined: Tue Sep 18, 2018 5:54 pm

Re: Minimig RTG possible?

Postby Alynna » Sat Jan 12, 2019 8:13 am

All truth be told its probably better just to focus on RTG.

I don't know how much of the Buster chip is implemented in the Minimig core but it would take very little to implement the same autoconfig mechanism and allow additional RAM, RTG and other peripherials to be configured and moved into place the Amiga way. And as expansion cards, it would be freed from the strict requirements of being 'part of the chipset'.

Building RTG should actually be relatively easy, all you need to do is construct a framebuffer and the interfaces to display it, something thats done many times for many cores.

Thinking about it, I think the fastest and probably best path to RTG on MiSTer is to make a vhdl version of uaegfx.card:
https://github.com/tonioni/WinUAE/blob/ ... 96_win.cpp

Its a simple framebuffer that doesn't care about the 'speed of the memory' as long as the data can be read as fast as the signal is drawn (surely true in MiSTer's case for most resolutions) and it also means the driver would already be written :)

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

Re: Minimig RTG possible?

Postby Sorgelig » Sat Jan 12, 2019 9:45 am

From special modes only A2024 modes (like 1024x1024 at 15Hz) aren't working on MiSTer - probably some specific HW not correctly done. So if it will be fixed, then more display modes will be available.
They key point is to have dedicated developer for Minimig. No doubt FPGA part of RTG should be easy for those who knows Amiga HW well.

User avatar
Alynna
Atari freak
Atari freak
Posts: 57
Joined: Tue Sep 18, 2018 5:54 pm

Re: Minimig RTG possible?

Postby Alynna » Sat Jan 12, 2019 4:18 pm

heh well that might be me, I know the Amiga .. probably well enough. We'll see. I've been playing around with the C16 and ao486 cores right now cause thats what works without an SDRAM board
Update: apparently my sdram board is scheduled for delivery today :) I don't have the i/o board I think its coming from poland, but at least i'll be able to start trying all cores :)

User avatar
Alynna
Atari freak
Atari freak
Posts: 57
Joined: Tue Sep 18, 2018 5:54 pm

Re: Minimig RTG possible?

Postby Alynna » Sat Jan 12, 2019 5:08 pm

I gave some thought to RTG this morning while getting up, made some plans as to what i'd like to do with RTG.
  • Bump the Picasso RTG RAM to 128m. The RAM is there might as well use it. What would we use it for?
  • Obviously I need a hardware sprite for the mouse cursor (Could do it in software but its actually more difficult).
  • On modern hardware, the difference between a "sprite" and a "framebuffer" gets blurry. Modern 3d graphics just use one sided 3d objects as framebuffers. There is no reason to limit the size of a sprite or screen on RTG, especially with 128mb of video RAM to work with. But making a 3D Picasso96 card would be overkill and costly in cells.
  • So lets try to meet that in the middle. Just have a list of framebuffers that can be specified to be sprites or screen.
  • This also means that this RTG could have multiple "screens" like AGA and be moved independently.
  • For speed reasons, lets limit this to 256 total sprites or screens. If this is too slow, go down to like, 64 or 16.
  • Alpha and transparency support for different layers. Have to be able to see through that sprite lol
  • Layer 0 is always the main framebuffer, layer 255 is always the mouse pointer. 254 sprites or screens in between.
  • All layers can be moved around even layer 0 to negative and positive offsets from the prime position (0,0 top left). Scroll your games fast and get that virtual workbench size support on RTG.
  • Screens not turned 'on' are skipped, speed up rendering, same for sprites.
  • Basic screen culling, if a higher layer screen has no alpha channels and occupies the entire resolution of the screen, then treat it as layer 0 (cause you can't see anything under it)
  • Easy screen flipping with 2 byte regs. byte 0 = src, byte 1 = dest, if byte 1 is 00, then after flipping the layer, the source page is now being displayed
  • Fast but unsophisticated sprite/framebuffer flipx/flipy and integer scaling.
  • Simple blitter with usual functions from chip to Z3 framebuffer and back, but doing 64bit DDR3 transfers. Get your video data from here to there very quickly.

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

Re: Minimig RTG possible?

Postby ijor » Sat Jan 12, 2019 5:28 pm

Alynna wrote:Don't expect to be able to make Minimig as good as Vampire, their DDR3 is wired to the FPGA quite different and does not have to go through the HPS to be accessed.


The concept that DDR is connected to the HPS is a bit misleading. The FPGA connects directly to the DDR controller bypassing completely the ARM processor. It wouldn't be much different if you would use a DDR controller on the FPGA side. The difference is from the fact that the DDR is, obviously, shared. And is shared not only with the ARM CPU but also with the scaler.

As Sorgelig explained, it is still pretty fast and efficient. But yes, of course that it is not suitable for random access that can't tolerate any extra latency.

It's suprising how much positive Amiga talk comes out of Atari forum too. :D


This (FPGA) subforum is mostly Atari agnostic :) We certainly do welcome Amiga falks.

I'm not sure I understand this part, whats wrong with it, and what are the SEED values in referent to?


Some cores don't have proper clock synchronization and/or correct timing constrains . This might result in timing and synchronization issues depending on some random compile settings controlled by the SEED value. So somebody with expertise in the "emulated" system should better eliminate the need of using SEEDs for getting a stable build.
Fx Cast: Atari St cycle accurate fpga core

User avatar
Alynna
Atari freak
Atari freak
Posts: 57
Joined: Tue Sep 18, 2018 5:54 pm

Re: Minimig RTG possible?

Postby Alynna » Sat Jan 12, 2019 5:37 pm

ijor wrote:
Alynna wrote:Don't expect to be able to make Minimig as good as Vampire, their DDR3 is wired to the FPGA quite different and does not have to go through the HPS to be accessed.


The concept that DDR is connected to the HPS is a bit misleading. The FPGA connects directly to the DDR controller bypassing completely the ARM processor. It wouldn't be much different if you would use a DDR controller on the FPGA side. The difference is from the fact that the DDR is, obviously, shared. And is shared not only with the ARM CPU but also with the scaler.

As Sorgelig explained, it is still pretty fast and efficient. But yes, of course that it is not suitable for random access that can't tolerate any extra latency.

It's suprising how much positive Amiga talk comes out of Atari forum too. :D


This (FPGA) subforum is mostly Atari agnostic :) We certainly do welcome Amiga falks.

I'm not sure I understand this part, whats wrong with it, and what are the SEED values in referent to?


Some cores don't have proper clock synchronization and/or correct timing constrains . This might result in timing and synchronization issues depending on some random compile settings controlled by the SEED value. So somebody with expertise in the "emulated" system should better eliminate the need of using SEEDs for getting a stable build.


This I understand a little better for some reason I thought you all were talking about actual "random number" seeds being introduced into the timing. I would hope that cores could be rolled using completely deterministic methods.

Also I was wondering for those who have compiled cores for Mister:
512m is "excluded from Linux use" clearly, but can I still access it from Linux? If I could, then the entire function of the RTG board (except final rendering) could run on core 2 of the HPS and eliminate the need to spend (alot of) cells on it.

Grabulosaure
Atari maniac
Atari maniac
Posts: 89
Joined: Tue Sep 05, 2017 9:35 pm
Contact:

Re: Minimig RTG possible?

Postby Grabulosaure » Sat Jan 12, 2019 6:04 pm

[Disclaimer : I don't know much about Amiga graphics]

The "ASCAL" HDMI scaler could be turned relatively easily into a framebuffer output.
This scaler stores the image generated by the cores into DDR3 then reads, expands and filters it to generate high resolution video. Storage format is packed RGB 24bits.
Advantages :
- Low effort
- Supports high resolution such as 1920x1200. Arbitrary resolution.
- Saves on RAM bandwidth compared to a separate framebuffer used in addition to the scaler.
- Could allow dual screen by using both the analog VGA for legacy modes and HDMI as independant output.

Modifications :
- Need mapping the DDR AVALON bus into the target address space.
- Switching between legacy video and high resolution modes is just disabling the scaler input datapath. --> Done. Just a signal to connect ("FREEZE").
- Add support for different colour depths : 24bits, 16bits truecolor, 8bits indexed colours, ... --> Easy.
- Add a hook in the scaler output pipeline for inserting a palette for indexed colours, or a cursor overlay --> Not difficult.

Of course, an independent blitter/line drawer,... can be added later for proper accelerated video.

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

Re: Minimig RTG possible?

Postby ijor » Sat Jan 12, 2019 6:18 pm

Alynna wrote:Also I was wondering for those who have compiled cores for Mister:
512m is "excluded from Linux use" clearly, but can I still access it from Linux? If I could, then the entire function of the RTG board (except final rendering) could run on core 2 of the HPS and eliminate the need to spend (alot of) cells on it.


There are ways to access that memory. And also the FPGA can access any memory allocated to Linux. But if hybrid emulation is preferable and desirable, that's a whole topic in itself. I don't know. It's not only a technical issue, but also "ideological" in the sense of emulation vs hardware reimplementation.
Fx Cast: Atari St cycle accurate fpga core

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

Re: Minimig RTG possible?

Postby ijor » Sat Jan 12, 2019 6:26 pm

Alynna wrote:Some cores don't have proper clock synchronization and/or correct timing constrains . This might result in timing and synchronization issues depending on some random compile settings controlled by the SEED value. So somebody with expertise in the "emulated" system should better eliminate the need of using SEEDs for getting a stable build.


The SEED value controls the compiler place & route algorithm. Different values normally produce a different build. If cross clock domain synchronization is done correctly and timing was correctly constrained, then the compiler will find and verify a build that complies with your timing regardless of the SEED. If you don't, then, depending on the SEED, place and route might produce a build that happens to produce timing violations or synchronization issues.
Fx Cast: Atari St cycle accurate fpga core

User avatar
Alynna
Atari freak
Atari freak
Posts: 57
Joined: Tue Sep 18, 2018 5:54 pm

Re: Minimig RTG possible?

Postby Alynna » Sat Jan 12, 2019 6:44 pm

rtg-fpga.PNG


Here is what I was looking at doing but I will look at the ASCAL scaler to provide a good starting point :)
Please provide link.
You do not have the required permissions to view the files attached to this post.

User avatar
Alynna
Atari freak
Atari freak
Posts: 57
Joined: Tue Sep 18, 2018 5:54 pm

Re: Minimig RTG possible?

Postby Alynna » Sat Jan 12, 2019 6:56 pm

ijor wrote:
Alynna wrote:Also I was wondering for those who have compiled cores for Mister:
512m is "excluded from Linux use" clearly, but can I still access it from Linux? If I could, then the entire function of the RTG board (except final rendering) could run on core 2 of the HPS and eliminate the need to spend (alot of) cells on it.


There are ways to access that memory. And also the FPGA can access any memory allocated to Linux. But if hybrid emulation is preferable and desirable, that's a whole topic in itself. I don't know. It's not only a technical issue, but also "ideological" in the sense of emulation vs hardware reimplementation.


I think that won't matter for RTG. There was never a "pure Amiga version" of RTG and indeed many RTG boards were implemented using off the shelf SVGA chipsets by S3 and Cirrus Logic. So our hybrid "RTG board" could just be considered a "new chipset" only without the chips. Doing all of this extra rendering on the HPS will lead to the fastest possible RTG implementation and minimize the amount of FPGA cycles needed to implement it :)

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

Re: Minimig RTG possible?

Postby Sorgelig » Sat Jan 12, 2019 8:15 pm

Both FPGA and HPS can access the whole 1GB DDR3 at any time. On FPGA side it's just a matter of address.
On HPS side you can simply mmap desired range of memory and use it as just generic RAM.
Division has been made just to make sure the both parties won't touch each other's memory without a reason.
In case of hybrid emulation FPGA region can be assigned on HPS side as memory of emulated system for emulated CPU, So it will be most effective way to share the memory between CPU and chipset. Since HPS already has caching mechanism, the access to emulated memory from HPS doesn't require any special hadling - just traditional software emulation of CPU is enough to get it done.

I never had RTG on real Amiga, and i always though it's just business oriented addon to speed up the 2D output fro Workbench and have some application like painter or similar. Never thought about 3D support in RTG. The cards used for RTC were just 2D cards.

Same goes for sprites - i don't think they will be used. Basically only one sprite is required - for mouse pointer. And it can be done in BRAM, so it doesn't requires more complicated implementation. Just one sprite only is separate memory.

User avatar
Alynna
Atari freak
Atari freak
Posts: 57
Joined: Tue Sep 18, 2018 5:54 pm

Re: Minimig RTG possible?

Postby Alynna » Sat Jan 12, 2019 8:27 pm

Well maybe just to keep it less complex we'll go with just 1 BRAM sprite. But I still think the extra screens and layers would be a nice addition and they really aren't much more trouble to implement once a single framebuffer is already implemented, its just rendering the next layer on top of the scaler framebuffer while processing the alpha pixels (and seeing through to the previous layer as necessary. And if people want, they can just use these extra layers as sprites (it won't care about its size or position) :)

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

Re: Minimig RTG possible?

Postby Sorgelig » Sat Jan 12, 2019 9:06 pm

Several screens don't add complexity as it just the offset in the memory.
Layers - again, this feature i'm sure is not used in RTG. The only thing can be really useful for RTG i think is blitter. Of course it must be supported in driver.
Another thing probably can be used in RTG is emulation of the Workbench virtual screens. It's when you can pull down the current screen and see the other one beneath it in Workbench. This is not really layers. So it doesn't include any complex things like alpha-blending or transparency. It's just the line number at which render should switch to other buffer - easy to implement.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 803
Joined: Mon Nov 04, 2013 5:23 pm

Re: Minimig RTG possible?

Postby JimDrew » Sat Jan 12, 2019 10:35 pm

Sorgelig wrote:Btw, besides unisual 1280x800 i hope you will make standard resolution 1280x720 as well.


The Amiga itself can use any resolution. You could have 1920x200 if you wanted to.
I am the flux ninja

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 803
Joined: Mon Nov 04, 2013 5:23 pm

Re: Minimig RTG possible?

Postby JimDrew » Sat Jan 12, 2019 10:36 pm

Alynna wrote:Well maybe just to keep it less complex we'll go with just 1 BRAM sprite. But I still think the extra screens and layers would be a nice addition and they really aren't much more trouble to implement once a single framebuffer is already implemented, its just rendering the next layer on top of the scaler framebuffer while processing the alpha pixels (and seeing through to the previous layer as necessary. And if people want, they can just use these extra layers as sprites (it won't care about its size or position) :)


The Picasso96 system takes care of the extra screens and layers. You just need a simple frame buffer and a xxx.card driver that will translate AmigaOS and Picasso96 specific library functions. I have experience with all of this due to Replay's RTG support.
I am the flux ninja

djmartins
Atari maniac
Atari maniac
Posts: 97
Joined: Wed Nov 21, 2018 10:26 pm

Re: Minimig RTG possible?

Postby djmartins » Sun Jan 13, 2019 2:11 am

Wow! I had hoped there was interest in this and am pleased to see there is.
So much in the Amiga community isn't open sourced and simply ends up dead.
Odd how giving away source code can make money for people but that is what you see
all over the tech world now.
I am not a dev, more of a mechanical engineer with a lifetime interest in computers and other stuff and loved my Amiga 1000
back in the 80s.
It seems that the FPGA in MiSTer could do a high end Amiga and all it will takes is a mere LOT of people and
a LOT of programming to get there.....

Roman
Atarian
Atarian
Posts: 7
Joined: Thu Dec 24, 2015 2:18 pm

Re: Minimig RTG possible?

Postby Roman » Wed Jan 30, 2019 12:39 pm

What about RAM bandwidth (SDRAM vs DDR3) from the simulated m68k point of view?

I mean - on the original Amiga using more more colors and/or higher screen resolution slowed down ChipRAM access while keeping FastRAM access speed intact. AFAIK currently no emulator / FPGA reimplementation replicates this. If the general rule would be:

- into SDRAM put: the ChipRAM (up to 4MB), SlowRAM (less than 2MB), possibly the Kickstart (up to 2MB), and possibly RTG memory (we would be left with 24 MB)
- into DDR3 put all the FastRAM

wouldn't this replicate the original Amiga memory architecture, so that software putting data into FastRAM instead of ChipRAM would actually see performance increase (depending on the screen resolution and color depth)?

BBond007
Captain Atari
Captain Atari
Posts: 366
Joined: Wed Feb 28, 2018 3:23 am

Re: Minimig RTG possible?

Postby BBond007 » Wed Jan 30, 2019 2:21 pm

Sorgelig wrote:Another thing probably can be used in RTG is emulation of the Workbench virtual screens. It's when you can pull down the current screen and see the other one beneath it in Workbench. This is not really layers. So it doesn't include any complex things like alpha-blending or transparency. It's just the line number at which render should switch to other buffer - easy to implement.


If I'm not mistaken, CyberGraphX supports screen-dragging and Picasso96 does not.

Roman
Atarian
Atarian
Posts: 7
Joined: Thu Dec 24, 2015 2:18 pm

Re: Minimig RTG possible?

Postby Roman » Wed Jan 30, 2019 5:15 pm

CyberGraphX is no longer developed for AmigaOS, it's driver API is not public and (AFAIK) it is no longer possible to obtain it to write a driver for the new hardware.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 803
Joined: Mon Nov 04, 2013 5:23 pm

Re: Minimig RTG possible?

Postby JimDrew » Wed Jan 30, 2019 10:52 pm

Picasso96 supports screen dragging. The Cybergraphics developer APIs were available for any company making products that needed low-level access. I got the APIs so I could write video drivers for FUSION and PCx, after signing a NDA of course.
I am the flux ninja


Return to “MiSTer”

Who is online

Users browsing this forum: Bing [Bot] and 4 guests