The first new Model 3 program in 17 years?

[Bart]

MAME is a good place to look. Their video driver is considerably simpler and might make more sense initially.

[krom]

Bart Yay I got your model 3 demo to compile & run, using your mingw devkit you linked.

Below are the steps I took to get it to compile & run:
1. Made a base MSYS install
2. Copied contents of http://www.trzy.org/files/model3/mingw64-ppc-gcc-5.1.0.zip into "msys/mingw" directory
3. Copied contents of https://github.com/trzy/model3/ to a directory inside my "msys/home/user" folder
4. I made the source able to compile locally by editing all references to "src/" & replacing them with "./", inside the 2 "Makefile" & "libmodel3/Makefile.inc" files.
5. I also edited "Makefile" & deleted all references to "/c/mingw64-ppc/bin/", as MSYS automatically has the path to the "msys/mingw/bin" directory
6. I then ran "make" inside MSYS, & it produced a "crom.bin" file.
7. This runs on Supermodel using this command line: "Supermodel crom.bin"

This is really great so thanks for getting me this far
I also like your demo very much, it's a great test =D

Not a bad idea but it would be easier to do this on a PPC eval board or even an old Mac. Also, the tests would have to be carefully designed. There is a PowerPC stress test out there somewhere that was used once to test our PPC emulation (at least for arithmetic flags).

O.k no probs, these tests would def be better done by some with access to PPC HW, so I might skip that then.
I had N64 HW to test on to make my N64 MIPS/RSP CPU tests, so it made sense for me todo them on that system.

I didn't know that the Raspberry Pi GPU was documented. I thought a driver was needed to access it.

I was the 1st to get a triangle on the R-Pi screen without using a driver, here is the documentation I used: https://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf
All my bare metal R-Pi V3D demos are here (100% ARM assembly!): https://github.com/PeterLemon/RaspberryPi/tree/master/V3D/ControlList
The R-Pi GPU HW is interesting, it uses smaller tiles to build the full screen up, and renders to each of those tiles using a control list documented in that PDF I just gave you.
Color shaders are required to provide color to the primitives, so I used a guy called phire's help to get the assembly output of the special QPU/VC4 CPU todo these for my tests.
I have made demos for most of the GPU primitives & modes, but I still have plenty todo, next step is programming in aarch64 for the R-Pi3 =D

No real docs but I could send you the SDK and API manual. It won't be all that helpful in actually writing code, though. The best place to look is really Supermodel's code.

Heh no probs, I will checkout the Supermodel source and try to get a triangle on the screen, it'll be a fun challenge
BTW if you do not mind, I would love the SDK and API manual anyway, as I would love to see them & check them out.

Anyway take care, I'll update you with anything cool I do.

[Bart]

Ping me by email for the docs. I know it sounds like a lot of work but a really great way to get a grip on what's going on in Real3D memory is to modify ~CReal3D() to dump out the culling RAM and polygon RAM. The Real3D addresses words at a time (not bytes), so write a little program to dump each of these files like this:

Code: Select all

for (int offset = 0; offset < file_size_in_bytes; offset += 4)
  printf("%06x: %08x %f\n", base_addr + offset/4, *(uint32_t *) &buf[offset], *(float *) &buf[offset]);


Where base_addr is the base address for each of the files. Not the base address in PowerPC space but in Real3D space (there is a TranslateCullingAddress() function in Legacy3D.cpp and I think also in New3D.cpp). Polygon memory is separate so set base_addr=0 when doing this. It's the "8c000000" and "8e000000" files that are the two regions of culling RAM (which contain the scene graph). You'll see what I mean when you glance at the TranslateCullingAddress() function. One of them starts at 0x800000 (viewport 0). I'm not sure how flexible the Real3D is but it was observed long ago that one of these RAM regions seems to only contain display lists (which are a special type of culling node pointer).

Anyway, load up a game, get it somewhere with simple 3D graphics (the Ingen logo in Lost World is probably the best scene to begin with because it is very compact), and then dump the files as I suggested. This will serve as a very handy reference to see what's going on. You'll immediately be able to start following along manually and stepping through the data structures.

You could go a step further once you understand the DrawViewport() scene traversal code and actually pretty-print each node as it is traversed to the console, and log it. Stick a printf("====\n"); or something in CLegacy3D::BeginFrame() to detect frames and then save the output as a reference. I've done this many times. I should have a utility to do it automatically from memory dumps but I think I've misplaced it. You'll pretty quickly figure out what's going on. It's way, way simpler than this Broadcom GPU, needless to say


Speaking of which, that is a very cool project and you should translate that ARM code into a C program. There's a lot of educational value in understanding how a modern GPU interface works!

[Bart]

Here are the handy functions I was talking about that describe the layout of memory as seen by the Real3D (remember -- 32-bit word addressable):

Code: Select all

// Translates 24-bit culling RAM addresses
const UINT32 *CLegacy3D::TranslateCullingAddress(UINT32 addr)
{
  addr &= 0x00FFFFFF; // caller should have done this already
 
  if ((addr>=0x800000) && (addr<0x840000))
    return &cullingRAMHi[addr&0x3FFFF];
  else if (addr < 0x100000)
    return &cullingRAMLo[addr];
 
#ifdef DEBUG
  ErrorLog("TranslateCullingAddress(): invalid address: %06X", addr);
#endif
  return NULL;
}

// Translates model references
const UINT32 *CLegacy3D::TranslateModelAddress(UINT32 modelAddr)
{
  modelAddr &= 0x00FFFFFF;  // caller should have done this already
 
  if (modelAddr < 0x100000)
    return &polyRAM[modelAddr];
  else
    return &vrom[modelAddr];
}


Note that here, cullingRAMHi, cullingRAMLo, polyRAM, and vrom are all UINT32*! Hence no division by 4. cullingRAMHi is mapped to 0x8e000000 in the PowerPC space and cullingRAMLo to 0x8c000000. Polygon RAM is at 0x98000000. Textures are uploaded via a FIFO. Check Real3D.cpp for that.

[krom]

Wow thanks for all the info, I'll give your tips a try, & I'll let you know how I get on.
I'll ping your email too, cheers Bart =D

[Bart]

I should also point out that Supermodel has a pretty capable debugger. You have to define SUPERMODEL_DEBUGGER (if building w/ gcc, set ENABLE_DEBUGGER=yes in the Makefile) and perform a clean build. You can start up the debugger with -enter-debugger or by pressing Alt+B at any time. It's very helpful.

Also, note that Step 1.0 has less RAM than we thought. Only 2MB, not 8MB. I think the Real3D memory regions are a bit smaller, too. Polygon RAM is possibly as little as 1MB and culling RAM is smaller, too, I believe. Some of this is documented in the legacy rendering engine, I believe. Basically, try to make your code as small as possible to maximize the chances of it working on a real Model 3 system If you get something working, I'd be happy to try to test it on a real board once I visit my family later this year.

It'll probably take a lot of tweaking of mysterious register settings and IRQ handlers, which we can do later. You have to use the SCSI controller if you want this to run on Step 1.0, unfortunately, to copy anything to Real3D RAM. Step 2.x had a nicer DMA controller that was easy to program. However, we can probably figure out exactly what VF3 or Scud Race are doing with the SCSI device and simulate that.

Supermodel will allow you to write using the CPU (in fact, it may be possible on the hardware, too, for all I know). So I would begin with that and make your code modular enough to be easily fixable. I would also write some relatively high level functions for constructing the scene graph, in case we later discover that there are some hard requirements (e.g., like you *must* have at least one display list node or something crazy like that).

The more I think about it, your best bet would be to dump the InGen sequence and use that as your base line! Just write exactly what it writes to set up your scene database and then just supply your own polygons to polygon RAM!

[krom]

The more I think about it, your best bet would be to dump the InGen sequence and use that as your base line! Just write exactly what it writes to set up your scene database and then just supply your own polygons to polygon RAM!

Great idea, I was thinking about doing something like this, & it might get some cool results =D

Thanks for the debugger tips, I'll compile a debug build & try it out.

[Vasiliy Familiya]

Hi everybody. The successful Bart's expiriment inspired me to try to create my own game for Model 3.

And, of course, the first thing I need for game is a possibility to interact with a control devices. What commands in the Bart's SDK are responsle for interaction with a control devices?

[Bart]

Hi everybody. The successful Bart's expiriment inspired me to try to create my own game for Model 3.

And, of course, the first thing I need for game is a possibility to interact with a control devices. What commands in the Bart's SDK are responsle for interaction with a control devices?

There are none. You can add such functions easily. Just take a look at how they are emulated in Supermodel. There, you can find the addresses. I would suggest using the fighting game controls because those are simply digital inputs that can easily be wired up to a Model 3 board.

[Vasiliy Familiya]

There are none. You can add such functions easily. Just take a look at how they are emulated in Supermodel. There, you can find the addresses.

I understood. Where can I look the Supermodel sources?

I would suggest using the fighting game controls because those are simply digital inputs that can easily be wired up to a Model 3 board.

Thank you, I knew it.