Phil C's Raven build

[agranlund]

Nice!

Looks like there's an incompatibility with the color-expansion pattern fill.
There are a few blitter related register differences in 29 compared to 26-28 so I would blame shoddy code for now :lol:

Update: Oh hang on, you had a 29 before as well. Did the corrupt pattern start appearing when the Siig was upgraded to 2MB ram?
That new card you got, does it also have 2MB? I'm uploading the fill patterns at the end of vram and perhaps I have bugs in that code.

[PhilC]

Nice!

Looks like there's an incompatibility with the color-expansion pattern fill.
There are a few blitter related register differences in 29 compared to 26-28 so I would blame shoddy code for now :lol:

Always happy to blame shoddy code :P

[PhilC]

So messing around with ram speed on the GD5429 does give some interesting results.

I've supposedly got two 83mhz and two 100mhz ram chips in bank 1 and 2 of the card but am able to set an MCLK on the card of 93mhz before it plateaus using the blitter test on Gembench. Now I could just be lucky that this card overclocks really well, so I've got a second one exactly the same (supposedly) that I'll try the same benchmark on and will see how we go.

If we could get the drivers optimised for this chip, then that would make it faster than a W32i.

I'm sure the GD5434 & GD5440 would be even faster but at around £300 a card I'm going to pass unless I find one at a silly (low) price sometime.

For those who might like to try the same on their GD5429 you need to try the following:

Code: Select all

pb $810003c4 $1F
pb $810003c5 $34 (speed is worked out by 1.79 x $34 = 93.08mhz)

Of course, your mileage may vary depending on card and ram speed.

[agranlund]

@PhilC that's some crazy overclocking. My GD5426 won't go anywhere near those settings :)

Here's a test for your 2MB GD5429 card to see if all of that ram can be accessed correctly.
(since I suspect the fillpattern issue you are seeing is somehow related to accessing the top of your 2MB region)

If you run c:\nova\default\test\rvtest.tos and select option 3 it will scroll through your entire vram, which should be filled with cats :)
Also numbers on the right hand side indicating which offset in vram you're looking at.

The program doesn't automatic switch resolution so you want to be in 640x480x8bpp when you run it.. it's just a simple program I use for testing things out.

You'll need to use the emulator.prg which is also in the zip.

rvnova_test.zip

[agranlund]

And this updated emulator.prg might fix >1MB access on GD542x cards.
Turns out linear aperture size is 1Mb by default and changing it to 2Mb is done through a completely different register.
I have no way of testing this myself so not sure if anything more is required or not for 2MB.

rvnova_test_update.zip

[PhilC]

@agranlund cool, thank you, cats? I thought you were a dog person. :lol:

[agranlund]

@agranlund cool, thank you, cats? I thought you were a dog person. :lol:

Haha yeah, but I've grown to like our cat too.
To be fair she spends most time outside murdering smaller animals, or hanging around the dogs when we go for walks.
I'm pretty sure I'm only valuable as the free-food delivery guy :lol:

IMG_8802.jpg

[PhilC]

@agranlund That test seems to work just fine, other than when it does the higher 1mb the image is shifted the right half the screen as below.

And if anything, the desktop background was more corrupted with the new emulator prg?

[agranlund]

@PhilC that was with the updated emulator posted just after the bigger zip, right?

The image should uniquely fill the entire 2MB and it looks here like it wraps around at the 1MB mark. This hints to me that the cpu<->vram aperture size is still probably only the default 1MB instead of 2MB.

And if anything, the desktop background was more corrupted with the new emulator prg?

I think it'll end up corrupt in different ways a bit randomly since the pattern data wouldn't end up in the correct place in vram. There will be some garbage for pattern data instead of the correct stuff.
(solid fill too, is depending on the pattern data. A solid pattern, but all the same an 8x8 mono pattern that we upload to vram from the cpu)

[PhilC]

@PhilC that was with the updated emulator posted just after the bigger zip, right?

The image should uniquely fill the entire 2MB and it looks here like it wraps around at the 1MB mark. This hints to me that the cpu<->vram aperture size is still probably only the default 1MB instead of 2MB.

And if anything, the desktop background was more corrupted with the new emulator prg?

I think it'll end up corrupt in different ways a bit randomly since the pattern data wouldn't end up in the correct place in vram. There will be some garbage for pattern data instead of the correct stuff.
(solid fill too, is depending on the pattern data. A solid pattern, but all the same an 8x8 mono pattern that we upload to vram from the cpu)

Yes you are right, the background patterns are all corrupted, so what it is actually doing is filling it the correct way? but the sources of the fill are corrupt.