Hardware poking and RTG cards

[jman]

Hello,

I think I need some explainations about running direct access code on an RTG enabled Amiga.

If I've understood correctly, the main purpose of the RTG graphic mode is to provide a uniform interface for the graphics, thus excluding completely the custom chipset.
This is why if I run my (hardware banging) code I see just nothing, is that correct?
How does this work actually? When the code is executed what happens to the output of the custom chipset? Is it somehow "discarded"?
How does the CGX or Picasso drivers translates the code that sets bits in the $dff000 copper range?

Anyway, provided these thing I've said above are correct, I'd like to know if there is a way to circumvent this.
Before installing utilities at random on my A4000, I checked ModePro or RTGMaster but I don't think they would help me.

My target machine is a stock A4000 with LCD attached. Currently the machine is equipped with an RTG card and embedded SD/FF, this card is driven by the CGX 4 driver.
I thought the scandoubler was enough to view hardware banging code at work because I assumed the issue was the horizontal syncing, but I'm afraid I was wrong.
If I attach a CRT monitor and disable the CGX driver, my code is ok (using PAL driver).
If I attach the LCD monitor, it cannot sync with the PAL resolution, so I have to revert to the CGX driver.

After all these tests, I think the only option is to remove the card and replace it with a bare scandoubler and give up higher resolutions.

Thank you for any piece of advice and correcting me if any of the above is wrong.

[thomas]

Having a gfx card in an Amiga is like having two gfx cards in a PC. The motherboard gfx is responsible for what comes out of the Amiga video port and the gfx card is responsible for what comes out of the VGA port. If you poke into the motherboard gfx registers, the gfx card does nothing because it just does not recognise what you did. Only the Amiga video changes.

In order to see the native gfx through the VGA port you need to activate the scandoubler, i.e. you need to tell the gfx card to switch off the VGA gfx and to pass through the Amiga gfx.

Only the RTG driver (CGX or P96) knows how to do it for each of the different supported gfx cards. This means you cannot do this by banging hardware, you need to call OS routines. Easiest way is to open an intuition screen with PAL screen mode. Then the RTG driver automatically switches into scandoubler mode if available. After that you can bang the custom chips.

[jman]

Very interesting.
I've understood the principle but I'll have to investigate how to implement such, I'm no experienced coder.

Thanks!

[Samurai_Crow]

I am considering a patch for the graphics macros used to create custom copper lists in hardware banging code to convert to fragment shaders. This still rules out anything that writes to the copper or blitter addresses directly or stores copper lists as raw chip memory blocks (as most hardware banging software does). This would allow the system-friendly Copper functions MrgCop() and RethinkDisplay() to work correctly on graphics cards though for a subset of the functions of the Copper.

This won't be an easy project and won't work for the majority of graphics cards as the requirement is at worst, an OpenGL 3.0+ capable graphics card, or at best, an OpenGL 2.1 card with a certain extension to allow boolean operations in the shader code. The project is stalled since the drivers on my Mac requires Mac OSX 10.7.x or better and I'm not upgrading until they get the bugs worked out.

[StingRay]

Originally Posted by jman

This is why if I run my (hardware banging) code I see just nothing, is that correct?

If you flush the view correctly, you'll see your hardware code on the RTG screen as long as you have some kind of scan doubler installed.
If you don't flush the view in your startup code, the system won't switch to your hardware screen thus you'll still see the RTG screen instead.


To flush the view you just have to call LoadView with 0 as parameter followed by 2 calls to WaitTOF (2nd call is needed for interlaced displays).

[jman]

Originally Posted by StingRay

To flush the view you just have to call LoadView with 0 as parameter followed by 2 calls to WaitTOF (2nd call is needed for interlaced displays).

For a moment I thought I could simply solve the issue amending the startup code that kills/restore the system, but ... I'm using *your* startup code v2.26 that already does it :-))
So, thanks, but I'm afraid the only path is as per Thomas suggestion.

CGX programming is beyond my current learning scope, so I'll see how much effort it will take. I don't know if I can (or it is worth) write another assembly startup code that opens a PAL screen using CGX calls. It looks a bit of an overkill. I'll check the documentation and some sample code.

[NovaCoder]

Hiya,

There is another way. For my port of ScummVM over to RTG systems I didn't have the time (or the energy) to use the CGX API so I just used the Amiga OS API instead.

Lots of the standard API calls are patched by the RTG installs so your code can just use the standard API calls and it will work for either CGX or P96 (eg WriteChunkyPixels).

So to go from AGA coding to RTG it took me about 3 lines of code

[absence]

Originally Posted by jman

If I attach a CRT monitor and disable the CGX driver, my code is ok (using PAL driver).
If I attach the LCD monitor, it cannot sync with the PAL resolution, so I have to revert to the CGX driver.

After all these tests, I think the only option is to remove the card and replace it with a bare scandoubler and give up higher resolutions.

Many LCD monitors are 60 Hz, while PAL is 50 Hz (or nearly 50 Hz in the case of Amiga's display signal), so I would guess that a scan doubler won't solve the issue of LCD not working when CRT does. Disclaimer: I don't have experience with scan doublers or RTG, so I'm just quoting numbers.

[jman]

Originally Posted by absence

Many LCD monitors are 60 Hz, while PAL is 50 Hz (or nearly 50 Hz in the case of Amiga's display signal), so I would guess that a scan doubler won't solve the issue of LCD not working when CRT does. Disclaimer: I don't have experience with scan doublers or RTG, so I'm just quoting numbers.

In theory could I start the Amiga in NTSC mode from the Early Startup and test if I can sync to 60Hz?
Unfortunately that's not doable as the Early Startup screen is out of sync :-\

I'm also afraid of damaging something if I set NTSC using the CRT and then once the startup has finished hot-swap to the LCD.

[absence]

Originally Posted by jman

In theory could I start the Amiga in NTSC mode from the Early Startup and test if I can sync to 60Hz?
Unfortunately that's not doable as the Early Startup screen is out of sync :-\

I'm also afraid of damaging something if I set NTSC using the CRT and then once the startup has finished hot-swap to the LCD.

I don't know how sensitive LCD monitors are to exact refresh rate, but keep in mind that NTSC is 59 Hz, not 60. If you want to try, you can probably select an NTSC screen mode in Prefs instead of using the early startup. That way you can swap monitors with the power off.

[jman]

Originally Posted by absence

I don't know how sensitive LCD monitors are to exact refresh rate, but keep in mind that NTSC is 59 Hz, not 60. If you want to try, you can probably select an NTSC screen mode in Prefs instead of using the early startup. That way you can swap monitors with the power off.

You were right. Surprise surprise, the LCD shows something exactly at 59Hz, though very blurry (see attachment).
If I run my crappy test code the LCD goes out of sync.

So, in the end I can say that my LCD is not able to sync PAL at all and that's too bad.
I have to find a way to use it through the CGX driver. Or I'll try the rtg.library from Picasso driver to pilot the PicassoIV card, but I don't expect things to improve.

[absence]

Originally Posted by jman

So, in the end I can say that my LCD is not able to sync PAL at all and that's too bad.

Maybe a small LCD tv will work? Assuming you have or want one.

[jman]

Originally Posted by absence

Maybe a small LCD tv will work? Assuming you have or want one.

heh, I thought about such that. Problem is I have to discard the output of the GFX card and use the 23pin-RGB/scart cable, right? I would have to stick to basic PAL resolutions.

[absence]

Originally Posted by jman

heh, I thought about such that. Problem is I have to discard the output of the GFX card and use the 23pin-RGB/scart cable, right? I would have to stick to basic PAL resolutions.

It's unclear to me what you actually want. Aren't these your two options?

• Classic hardware banging with 23-pin output
• RTG API with VGA output

It sounds like you somehow want to mix these (e.g. classic hardware banging with VGA output), and I don't think that's possible. Feel free to correct me if I'm wrong of course, I'm not entirely sure of this.

[jman]

Originally Posted by absence

It's unclear to me what you actually want. Aren't these your two options?

• Classic hardware banging with 23-pin output
• RTG API with VGA output

It sounds like you somehow want to mix these (e.g. classic hardware banging with VGA output), and I don't think that's possible. Feel free to correct me if I'm wrong of course, I'm not entirely sure of this.

You are right, I wanted to mix these two options and the more I learn about this, the more I agree with you :-)
So either I can manage some tricks with CGX programming (which is a bit out of my knowledge span) or I'll use the direct ECS/AGA chipset output.

EDIT: I'll have a look at one of those LCD declared "multisync", It could be interesting to know how do they work.

[jman]

Well,

I have a Dell U2211H LCD attached to the PC that can sync everything, from bare PAL to the highest RTG resolution allowed by the GFX card. My ASM hardware banging code works like a charm.
I can attach a VGA from the Amiga and a DVI from the PC and I can switch between them with the monitor selector.

The solution have been on my desk for a year

[dissident]

Originally Posted by StingRay

If you flush the view correctly, you'll see your hardware code on the RTG screen as long as you have some kind of scan doubler installed.
If you don't flush the view in your startup code, the system won't switch to your hardware screen thus you'll still see the RTG screen instead.


To flush the view you just have to call LoadView with 0 as parameter followed by 2 calls to WaitTOF (2nd call is needed for interlaced displays).

Well, flushing and returning to the RTG screen works fine with this method if you use a 15 kHz hardware coded display. But what happens if it's a hardware coded 31 kHz display like a 640x480 VGA/Productivity screen and you return to the RTG screen? I guess none every tried to do so, because this special mode isn't used in intros/demos. For the 31 kHz display I have to set these registers on my AGA machine:

HTOTAL
HSSTOP
HBSTRT
HBSTOP
VTOTAL
VSSTOP
VBSTRT
VBSTOP
HSSTART
VSSTART
HCENTER
BEAMCON0

LoadView(0) only seems to restore BEAMCON0=$0020 for a PAL machine or $0000 for a NTSC machine. All other registers are untouched. Funnily the RTG screen is distorted when my routine returns to the system. This display error remains the same if I open a PAL screen before LoadView(0). But why? RTG don't use the CUSTOM chips I thought?