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.

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.

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

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

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

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.

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

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.

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 boardUpdate: 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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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)

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.

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.

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 seeall 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 1000back 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.....

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)?

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.

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.