Sonnet 7200 PCI programming

[grelbfarlk]

Nice videos Buli!

[Timtheloon]

Originally Posted by BULI

Here slower in Interpreter MODE, but more games from PSX are compatybility with this mode:
[ Show youtube player ]

This looks like a lot of fun not that I need it having a PS3 with all the PS1 games on my network drive , but why not fun to see an Amiga PPC play a PSX Game

[grelbfarlk]

Originally Posted by Timtheloon

This looks like a lot of fun not that I need it having a PS3 with all the PS1 games on my network drive , but why not fun to see an Amiga PPC play a PSX Game

If someone put a Cell PPC chip on a PCI card then we could have the same luxury. Because what would happen is that you know we'd have a virtual machine PS3 emulator running natively. But we don't have that yet, I blame Wrangler.

[Cowcat]

After all this years, people debate about PPC yes/no/good/bad/cool/suck/dead (mostly in the "hate" debate). But I don't give a damn while still find challenging a "corpse cpu".

Meanwhile, some small program has been upgraded after a couple of decades.

[grelbfarlk]

Originally Posted by Cowcat

After all this years, people debate about PPC yes/no/good/bad/cool/suck/dead (mostly in the "hate" debate). But I don't give a damn while still find challenging a "corpse cpu".

Meanwhile, some small program has been upgraded after a couple of decades.

I like small programs and upgrades!

[BULI]

Originally Posted by Cowcat

After all this years, people debate about PPC yes/no/good/bad/cool/suck/dead (mostly in the "hate" debate). But I don't give a damn while still find challenging a "corpse cpu".

Meanwhile, some small program has been upgraded after a couple of decades.

Yes, thanks to this, We have Super Mario 64 with hardware 3D support, and we can play PSX games on Amiga Ragnarok

[grelbfarlk]

What are the updates to the PSX emulizer?

[Cowcat]

@grelbfarlk PM me here.

[Wrangler]

Originally Posted by grelbfarlk

But we don't have that yet, I blame Wrangler.

TBH, I blame him for a lot things

[Hedeon]

Originally Posted by grelbfarlk

If someone put a Cell PPC chip on a PCI card then we could have the same luxury. Because what would happen is that you know we'd have a virtual machine PS3 emulator running natively. But we don't have that yet, I blame Wrangler.

I once spoke to the guy from Escena. He had a source for those Cell processors quite cheap. Was thinking about making a card with it. Zorro, though. Five years it must have been. Didn't materialize.

[grelbfarlk]

That's it, I'm going to have my guy acquire a couple of these 3.2GHz Cell CPU PCI-E cards to stick it to Timtheloon and Wrangler.

[BULI]

Beta 2 port of FPSE -
FullScreen and SCALING work
..and the most important:
Sound and Music too !!

Big THANKS to Cowcat!!!
[ Show youtube player ]

Here is new thread about this FPSE:
https://eab.abime.net/showthread.php...94#post1662294

[Hedeon]

Guys, which exact version of P96 made Warp3D slower now that i may have THOR's attention? Still could be an issue at my side, but would be nice what change in P96 triggered it.

[trixster]

These were my findings

https://eab.abime.net/showpost.php?p...&postcount=156

[Hedeon]

Anybody had that issue and followed the FAQ to fix it? I currently don't have access to the FAQ, just reacting on reports from people.

I cannot get through to Thomas otherwise. As i have no clue why he is referring to CVPPC while this is about 3DFX Voodoo slowing down with 3.0 rtg.library

[Hedeon]

Ok, I read the FAQ and it tells me to update the CVPPC firmware.

[Hedeon]

OK, so far:

rtg.library 2.1 vs 3.4, all in FS:

glQuake 640x480: 62fps vs 53fps (minigl)
WipeOut2079 demo 640x480: 45 fps vs 35 fps (TB) and 35 fps vs 25 fps (DB) looking at the start of the demo.
ByNight from Encore, part 1: 44 fps vs 35 fps

Tried the gearsPPC demo, but the fps is not shown correctly with 3.4. It barely shows up every 1000 frames or so while 2.1 it shows flickering so probably every 30 frames. Not sure if this is revevant.

[Karlos]

Are 68K applications affected at all, or only WarpOS ?

[Hedeon]

As I understand, only WarpOS

[Karlos]

For Picasso96 systems, the W3D_Picasso96(PPC).library is responsible for bitmap allocation, locking and generally knowing where textures and buffers are.

From memory (and we are talking decades), the allocation routines for buffers is somewhat generalised:

1) The required buffer size, in bytes, is used to work out a 2D BitMap size. This is just the square root of the memory size rounded to the nearest 16 bytes that's strictly equal to or larger than that value.

2) There is an assumption that the Screen BitMap (which is pointed to by the W3D_Context drawregion) is already in VRAM. So, allocations of VRAM use this as a friend bitmap. From my own experiments with CGX this was the only guaranteed way to get things into VRAM but I don't know about p96.

This ensures (at least then) that the BitMap to be allocated will both in VRAM and in a "compatible" (read "same") format as the Screen BitMap. So, the required height of the BitMap we want to allocate is then divided by the bytes per pixel of the Screen BitMap. Note that it only needs the byte size of the allocation to be big enough, so it doesn't don't care at all about the actual pixel format because the memory is going to hold texture or z buffer or something. It's not an image to be displayed.

So in summary, VRAM allocation goes something like this (function/identifier names might be off a touch):

struct BitMap* bitmap;
struct BitMap* screen_bitmap;
ULONG vram_memory_size;

ULONG bitmap_width = ( ((ULONG)(sqrt(vram_memory_size))) & ~0xF ) + 16;

ULONG bitmap_height = bitmap_width / P96GetBitMapAttr(screen_bitmap, P96_BYTES_PER_PIXEL);

bitmap = P96AllocBitMap(bitmap_width, bitmap_height, 8, ... (can't remember) ..., screen_bitmap, ...);

The things that I definitely do remember are the funky bitmap size calculaiton, a requested depth of 8 and using the existing screen bitmap as the "friend" or "template" or whatever the terminology is.

What happens next is that there's a check to see if the new bitmap is in VRAM already. I think this is another call to P96GetBitMapAttr(). If it's not, the bitmap is freed.

When it comes to lock the hardware to render a frame, there's quite a lot of P96 calls to check that all the bitmaps for the important buffers (Z buffer, stencil, etc) are resident.

I also dimly remember that there was an issue with the code with respect to where the draw memory address was in relation to the base address of the VRAM. There was a terrible hack but I don't know when and under which circumstances it kicked in but I do think it was specific to the P96 side. It did something like checking the W3D_Context draw_memory address was less than the W3D_Context vram_memory_base address, it would incrementally increase draw_memory address by some value until it was no longer the case. I have no idea why it was there or why it just wasn't more directly calculated without a loop, but if there is a big difference between these pointers suddenly that wasn't there before, maybe it's busy looping it.