23 October 2011, 19:32 | #1 |
Registered User
Join Date: Nov 2010
Location: .
Posts: 351
|
Hardware poking and RTG cards
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. |
23 October 2011, 20:09 | #2 |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 7,000
|
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. |
23 October 2011, 22:49 | #3 |
Registered User
Join Date: Nov 2010
Location: .
Posts: 351
|
Very interesting.
I've understood the principle but I'll have to investigate how to implement such, I'm no experienced coder. Thanks! |
24 October 2011, 01:46 | #4 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,187
|
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. |
24 October 2011, 09:59 | #5 | |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
Quote:
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). |
|
24 October 2011, 21:07 | #6 | |
Registered User
Join Date: Nov 2010
Location: .
Posts: 351
|
Quote:
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. |
|
25 October 2011, 07:34 | #7 |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,400
|
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 |
25 October 2011, 22:10 | #8 | |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
Quote:
|
|
25 October 2011, 23:28 | #9 | |
Registered User
Join Date: Nov 2010
Location: .
Posts: 351
|
Quote:
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. |
|
25 October 2011, 23:58 | #10 | |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
Quote:
|
|
29 October 2011, 20:08 | #11 | |
Registered User
Join Date: Nov 2010
Location: .
Posts: 351
|
Quote:
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. |
|
30 October 2011, 11:22 | #12 |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
|
30 October 2011, 13:29 | #13 |
Registered User
Join Date: Nov 2010
Location: .
Posts: 351
|
|
30 October 2011, 13:34 | #14 | |
Registered User
Join Date: Mar 2009
Location: moon
Posts: 373
|
Quote:
|
|
30 October 2011, 13:55 | #15 | |
Registered User
Join Date: Nov 2010
Location: .
Posts: 351
|
Quote:
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. Last edited by jman; 30 October 2011 at 20:42. |
|
01 November 2011, 16:10 | #16 |
Registered User
Join Date: Nov 2010
Location: .
Posts: 351
|
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 |
22 June 2018, 23:46 | #17 | ||
Registered User
Join Date: Sep 2015
Location: Germany
Posts: 260
|
Quote:
Quote:
|
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Hardware RTG board emulation | Toni Wilen | request.UAE Wishlist | 54 | 25 July 2015 23:42 |
RTG Games | James | HOL data problems | 16 | 02 April 2011 19:40 |
FS: Merlin RTG | Fieldday | MarketPlace | 0 | 01 December 2009 12:44 |
RTG problem | affleck | support.WinUAE | 2 | 22 October 2006 01:05 |
RTG Problem :( | BippyM | support.WinUAE | 1 | 12 November 2002 01:09 |
|
|