j
: Next unread message k
: Previous unread message j a
: Jump to all threads
j l
: Jump to MailingList overview
I think old world Macs always booted in 640x480x8, but new world can boot at a higher screen resolution setup in NVRAM. The change in modes to 640x480x8 maybe for compatibility with Old World Macs.
I think reduced ATI ROM’s, that we removed the ‘NDRV’ so it would fit on a 64k EEROM always booted at 640x480x8 until the disk based “NDRV’ loaded. I don’t think anyone ever flashed a reduced Rage128 Pro ROM without the ‘NDRV’ sos I don’t really know how a new world Mac would handle that, if it could still set a higher screen resolution.
Maybe we can we can get some info from the sources of the linux r128 driver?
On Jul 25, 2019, at 5:53 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 25 Jul 2019, Jd Lyons wrote:
I take it you’ve seen this:
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&a...
Sure, that's what I use for register reference all the time (and is linked from my qmiga.osdn.io page although not directly to avoid possible copyright problems but the card page where the doc is available linked and I've told you that before and also hinted on that page. There are more docs available from the pages linked from my qmiga page, all those might have useful info (the prg and sdk guides too, even though they are for different cards but these are similar so some details are the same).
However it does not explain what AMCGPIO is, only what are the bits in those regs or did I miss that part where it actually says what should be accessible via that register? From the access pattern it looks similar to GPIO_MONID where we have the EDID so maybe the card has another connector the DDC/EDID of which is accessed via the AMCGPIO reg? The FCode checks both but switches mode after reading AMCGPIO and before getting EDID from GPIO_MONID so maybe we need to add EDID to the AMCGPIO reg? But I don't know which bits to connect it. Probably one could find out by reading the detok-ed FCode source to see what it does with the EDID and how does it select mode or find an open source driver that accesses this to find out how this should work.
But the problem currently is with the offset 8000 in the selected mode which the QEMU VGA emulation can't handle or I don't know how to make it handle. That's why picture is wrong at the moment. So either we should allow this offset or find out why FCode wants that and when it uses different mode is that better aligned then? Where does it get this 640x480x8 mode and shouldn't it use something higher by default? I don't know how MacOS works and what its default mode is.
Regards, BALATON Zoltan