Atarian Computing's Raven Build

[agranlund]

But your DEFAULT folder indeed fixed the anomalies.

Nice, thank you!
Then we've for sure verified it's related to blitter-fill.

I thought I'd try the OG EMULATOR.PRG with the DEFAULT you provided. Sure enough. There's a major difference as you can see:

If there's some issue with either the uploading the fill-patterns to vram, or how it's being accessed in the blitter-fill code, then I think I wouldn't put much emphasis on _how_ it looks other than if it's correct or not.

The fill pattern is basically a black and white pattern of 8x8 which is uploaded to the gfxcards vram, where a 1 means it should color the pixel with a 'foreground color' and 0 means a 'background color'.

I suspect either:
a) we give the blitter the correct address to the pattern, but pattern upload went wrong so there is 'random' rubbish data there.
b) pattern upload was correct, but we somehow give the blitter the wrong address and it's using the wrong stuff as mask (garbage in this context)

Not sure why that would be, and why on your particular card and not mine.

Hmmn.. I'm putting the patterns right at the end of vram.
How much vram does your card have? In case that's a difference between our cards which I didn't account for properly?

This is 16bit mode. It's the same with both EMULATOR.PRG

Interesting! I remember briefly testing 16bit at some point but now I don't remember when or even on what card that was
I should try it again on my Cirrus GD5434.

Best guess from the picture would be if VDI is made to believe we're in 16bit (RGB:565) but the actual mode on the card is '15bit' (RGB:x555), or vice versa, or something like that.
I'll file that under the driver-bugs folder
(I'm assuming it's the same issue in plain EmuTOS too)

[Atarian Computing]

If there's some issue with either the uploading the fill-patterns to vram, or how it's being accessed in the blitter-fill code, then I think I wouldn't put much emphasis on _how_ it looks other than if it's correct or not.

The fill pattern is basically a black and white pattern of 8x8 which is uploaded to the gfxcards vram, where a 1 means it should color the pixel with a 'foreground color' and 0 means a 'background color'.

I suspect either:
a) we give the blitter the correct address to the pattern, but pattern upload went wrong so there is 'random' rubbish data there.
b) pattern upload was correct, but we somehow give the blitter the wrong address and it's using the wrong stuff as mask (garbage in this context)

Not sure why that would be, and why on your particular card and not mine.

Hmmn.. I'm putting the patterns right at the end of vram.
How much vram does your card have? In case that's a difference between our cards which I didn't account for properly?

Interesting! I remember briefly testing 16bit at some point but now I don't remember when or even on what card that was
I should try it again on my Cirrus GD5434.

Best guess from the picture would be if VDI is made to believe we're in 16bit (RGB:565) but the actual mode on the card is '15bit' (RGB:x555), or vice versa, or something like that.
I'll file that under the driver-bugs folder
(I'm assuming it's the same issue in plain EmuTOS too)

Thanks for the quick reply. Ok, that makes sense. I have 2MB of VRAM. Also, the internet tells me that the Orchid Kelvin 64 is very close to the STB Nitro in board layout and otherwise, if that helps.

I also found the manual, which lists all the modes, if that's of any use.

I'm out of town for two nights, so no rush.

[agranlund]

Yeah I think the 16bit mode is broken and perhaps it always was. Getting the same result as you when testing GD5434 as well as GD5426.
I really thought it was working at some point but maybe it never was.

I am doing some direct hardware poking right after vgabios has changed the mode so there's a real possibility that's where I do wrong and mess up for 16bit.

For now I would stick with the 8bit modes.


The result is quite interesting though
Setting 640x480x16bpp and poking directly in vram with the raven monitor it looks like the card is treating it as 1280x480x8bpp in terms of vram->pixel on screen. Each byte appears to be going through the palette-DAC and out as a pixel, as opposed to one word of direct-colour at a time.

[Atarian Computing]

Yeah I think the 16bit mode is broken and perhaps it always was. Getting the same result as you when testing GD5434 as well as GD5426.
I really thought it was working at some point but maybe it never was.

I am doing some direct hardware poking right after vgabios has changed the mode so there's a real possibility that's where I do wrong and mess up for 16bit.

For now I would stick with the 8bit modes.


The result is quite interesting though
Setting 640x480x16bpp and poking directly in vram with the raven monitor it looks like the card is treating it as 1280x480x8bpp in terms of vram->pixel on screen. Each byte appears to be going through the palette-DAC and out as a pixel, as opposed to one word of direct-colour at a time.

Thanks for the info. I'll be pretty much away from my Raven until next year so don't feel pressured or anything. I'll get into it at some point in January as work stuff might go nuts after New Year.

I finally got a seemingly working NIC. I made sure to buy a jumpered version with the option of PnP. UIP seems to see it and it's IP and I can ping the Raven. @PhilC, I think I won't be needing a card from you after all. I'll try get MiNTNet and MagiCNet up and running at some point.

[Atarian Computing]

Another fun day with the Raven after a long Christmas break at the in-laws.

Today I updated everything to the latest release, then tackled the GD5434 blitting issue by fetching a few dozen 27C256 chips for BIOS testing.

First, I tried Diamond Speedstar 64 ver. 2.02. It worked, and the blitter issue was gone. What took its place, however, was random, jittery artifacts on the screen that progressively worsened over time until the whole screen was jittery but still legible. Unusable though.

Second, I tried ver. 2.00 of the same card. Same results.

Third, I tried STB Nitro 64. Exact same behaviour as the OG BIOS, blitting issues. No surprise, as it's pretty much an identical card to my Orchid.

Then came a few tests of random BIOSes, and none of them worked. What was curious, though, was that the terminal monitor displayed the same

Code: Select all

 8bit VRAM access

as the Mach64 does.

Finally, I came across a BIOS package for PCI cards that apparently worked for the DIY Pine card. I installed 1.24a, and it's absolutely perfect. * No jittering, no artifacts, no ghosting. So it now takes its place as my main card despite the lack of 1280x720. The hardware acceleration is just too good to pass. Here is the BIOS package I used. There's a version 1.20 that I didn't even bother trying.

GD5434.zip

(39.71 KiB) Downloaded 9 times

I'm now itching to get the Mach64 working as it looks very promising and blazingly fast. It doesn't seem to exhibit the colour issues mentioned below but almost impossible to test as I only got it to work once with the release drivers. But my goodness, did it look good, though. The 3.01 drivers output a vastly inferior image as I've explained in the main thread.

* apart from the washed-out colours that are an issue on the ET4KAX as well. From screenshots from other users here I can see the same issue. I'll do a detailed write-up with examples unless @agranlund, you're already aware of this.

[agranlund]

Finally, I came across a BIOS package for PCI cards that apparently worked for the DIY Pine card. I installed 1.24a, and it's absolutely perfect. * No jittering, no artifacts, no ghosting. So it now takes its place as my main card despite the lack of 1280x720. The hardware acceleration is just too good to pass. Here is the BIOS package I used. There's a version 1.20 that I didn't even bother trying.

That't really good to know, thanks for sharing!
And since they came from a PCI card they're probably newer and with more fixes than most older ones

[Atarian Computing]

I managed to score a slightly defective W32i from eBay for 40€. The defect is a poor connection on the VGA port, but it's not that bad. I have a few new ports I can install. It just initially needs fiddling to output all colour channels, but it is stable if you don't touch it.

It's a 1MB card, so no interleave. It's the same exact card that @LarryL bought. 1MB is all I need, as I would not use more than 256 colours anyway in 1280x720.

The colour output is perfect, unlike my GD5434 and ET4000AX. Waiting on my OSSC to arrive to see if that fixes the output for those cards. My cheap VGA-HDMI improved it significantly but didn't output BIOS resolutions.

Pretty happy with the purchase.

[LarryL]

I managed to score a slightly defective W32i from eBay for 40€. The defect is a poor connection on the VGA port, but it's not that bad. I have a few new ports I can install. It just initially needs fiddling to output all colour channels, but it is stable if you don't touch it.

It's a 1MB card, so no interleave. It's the same exact card that @LarryL bought. 1MB is all I need, as I would not use more than 256 colours anyway in 1280x720.

The colour output is perfect, unlike my GD5434 and ET4000AX. Waiting on my OSSC to arrive to see if that fixes the output for those cards. My cheap VGA-HDMI improved it significantly but didn't output BIOS resolutions.

Pretty happy with the purchase.

very good, I also like this card
I made a custom resolution for my 16:9 screen (1280x720), but I see some slight artefacts (sprayed pixels around the mouse cursor) from time to time
Do you experience the same?
Not sure if its the driver or the card...

[Atarian Computing]

very good, I also like this card
I made a custom resolution for my 16:9 screen (1280x720), but I see some slight artefacts (sprayed pixels around the mouse cursor) from time to time
Do you experience the same?
Not sure if its the driver or the card...

In my limited usage, I haven't seen any artefacts. Why did you make a custom resolution when there was a built-in one?

[LarryL]

very good, I also like this card
I made a custom resolution for my 16:9 screen (1280x720), but I see some slight artefacts (sprayed pixels around the mouse cursor) from time to time
Do you experience the same?
Not sure if its the driver or the card...

In my limited usage, I haven't seen any artefacts. Why did you make a custom resolution when there was a built-in one?

my bigger (and more modern) monitor is 16:9 and all standard resolutions were 4:3
In fact I had to fine tune all the resolutions to make them work with my 16:9 monitor
I also have a NEC 1990FXp which worked fine with the standard resolutions - need to check if there are artefacts, too