real 3d registers

[Ian]

// Registers seem to range from 0x00 to around 0x3C but they are not understood

Currently we only know 1 bit out of all these registers ... The rest are totally unknown.

I had suggested before they they correspond to this data structure in the dev kit

Code: Select all

typedef struct
{
   unsigned long  data_valid   : 1;
   unsigned long  floatm1      :31;
} range_data;

typedef union 
{
   range_data  rangem1;
   float       range;
} range_return;

typedef struct
{
   unsigned long  tot_clks     :23;
   unsigned long  rend_done    : 1;
   unsigned long  update_done  : 1;
   unsigned long  ping_pong    : 1;
   unsigned long  dp_done      : 1;
   unsigned long  gp_done      : 1;
   unsigned long  spare1       : 4;

   unsigned long  vpt0_clks    :23;
   unsigned long  spare2       : 9;

   unsigned long  vpt1_clks    :23;
   unsigned long spare3        : 9;

   unsigned long  vpt2_clks    :23;
   unsigned long  spare4       : 9;

   unsigned long  vpt3_clks    :23;
   unsigned long  spare5       : 9;

   range_return   ranges[4];
   unsigned long  ls_cycle;
   Hw_Config      hw_config;
   unsigned long  words_buf_to_host;
   unsigned long  null0;
   unsigned long  null1;
} Stat_Pckt ;


The range return stuff is what is used by the line of sight command. It returns 4 possible values, one value for each priority layer (4). Well the hardware has to be returning these values somewhere .. it must be here.

Before I couldn't figure out the logic to make the line of sight to work correctly. It was drawing lens flair when it shouldn't. Anyway in the code I tried just return 0 for the rest of the registers.

This is the result

Returning 0xffffffff gives:



Returning 0 gives:



Uh, so giving the HW zero here tells the game that the line of sight test wasn't successful and not to draw lens flair ..

Importantly that means this real3d 'status bit' is actually the unsigned long ping_pong : 1;
bit :p

So my best guess is these registers correspond 100% to what is in the dev kit ..

[sonic32]

Thank you, Ian, for a great job
Does it look like an arcade, will it be added to the official set?

[Bart]

What’s Hw_Config? I don’t have the code handy at the moment. If I can get software running on the actual board, this would prove very handy. It looks like there is a lot of interesting information transmitted in these packets.

[Ian]

Code: Select all

typedef struct
{
#ifndef BIG_ENDIAN
   unsigned long   sw_revision         : 16 ;
   unsigned long   spare2              :  1 ;
   unsigned long   spare1              :  1 ;
   unsigned long   hw_revision         :  3 ;
   unsigned long   dual                :  1 ;
   unsigned long   num_cpus            :  1 ;
   unsigned long   sync_file_selected  :  4 ;
   unsigned long   hi_res              :  1 ;
   unsigned long   num_frame3s         :  1 ;
   unsigned long   text_mem_chip_sz    :  1 ;
   unsigned long   poly_mem_chunks     :  2 ;
#else
   unsigned long   poly_mem_chunks     :  2 ;
   unsigned long   text_mem_chip_sz    :  1 ;
   unsigned long   num_frame3s         :  1 ;
   unsigned long   hi_res              :  1 ;
   unsigned long   sync_file_selected  :  4 ;
   unsigned long   num_cpus            :  1 ;
   unsigned long   dual                :  1 ;
   unsigned long   hw_revision         :  3 ;
   unsigned long   spare1              :  1 ;
   unsigned long   spare2              :  1 ;
   unsigned long   sw_revision         : 16 ;
#endif
} Hw_Config ;

I don't think these are actually used at all though.

The flush method does this

Code: Select all

            v4 = ls_hw_stats(i);
          _SetRealtimeClockCount_PRO_Device__QAEXK_Z(*(_DWORD *)v4 & 0x7FFFFF);
          _SetCurrentFrameNumber_PRO_Device__QAEXK_Z(*(_DWORD *)(v4 + 36));
          _SetLOSRange_PRO_Device__QAEXMJ_Z(*(_DWORD *)(v4 + 20), 0);
          _SetLOSRange_PRO_Device__QAEXMJ_Z(*(_DWORD *)(v4 + 24), 1);
          _SetLOSRange_PRO_Device__QAEXMJ_Z(*(_DWORD *)(v4 + 28), 2);
          _SetLOSRange_PRO_Device__QAEXMJ_Z(*(_DWORD *)(v4 + 32), 3);

The API is being updated with the 4 LOS values, the frame number and the real time clock count? I guess those are the most important things. Wonder if any of these are effecting magical truck ..
I should be able to find out where else in the api ls_hw_stats is being called. Because that has the ping pong bit in it ..

[Bart]

Keep in mind that this is the PC interface to what is effectively a Model 3 board running its own software. The device connected to the PC via SCSI cable. Seems like the API mostly sets up memory regions on the Real3D but it’s possible, especially for something like a stat packet, that parts of it are assembled or otherwise processed on the Real3D board by its PowerPC software.

It would be fun to one day try emulating the Pro-1000 itself and see if we can get it running as an emulated peripheral connected to a VMWare session

[Ian]

Keep in mind that this is the PC interface to what is effectively a Model 3 board running its own software.

sure But what do you think the dev kit looked like? Wouldn't be surprised if it was a real3d pro-1000, or a pc connected to the model3 with a scsi cable ;p
Some of the games actually boot with a viewport size of 640x480

Gonna poke these registers a bit more. Not looked at the code, but to read the registers, we have to sync with the GPU. How does the threading work here ?

[Bart]

Keep in mind that this is the PC interface to what is effectively a Model 3 board running its own software.

sure But what do you think the dev kit looked like? Wouldn't be surprised if it was a real3d pro-1000, or a pc connected to the model3 with a scsi cable ;p
Some of the games actually boot with a viewport size of 640x480

Gonna poke these registers a bit more. Not looked at the code, but to read the registers, we have to sync with the GPU. How does the threading work here ?

It's definitely worth digging into these drivers. But what I mean is that the Pro-1000 had code running on it that is the equivalent to the games we are emulating. The Model 3 dev unit may indeed have been just a Pro-1000 but it's quite likely that they were transferring code onto the board itself as opposed to having the game logic running on the PC and sending commands down to the Pro-1000, where some fixed BIOS software picks it up (which is how the Pro-1000 works).

By the way, that BIOS ROM is present in the SDK! Could be worth disassembling and having a peak. If all it's doing is shuttling data between the PC and Real3D chipset, then maybe there isn't all that much to it and there may even be an initialization routine that's easy to tease apart.

[Bart]

Oh, by the way, do your disassemblies give you any insight into where the actual Windows NT SCSI driver layer is? I don't know anything about Windows device drivers but I imagine at some point, some sort of Windows kernel-level function is called to actually send data. I'm curious whether there is any way that we could hook into a VM running Windows NT 4 and actually simulate the hardware, piping the data out to a separate process outside the VM that emulates the Real3D. VMWare does have an API that allows shared memory regions to be mapped between host and guest systems. Not sure if it supports NT4, though.

A little digging reveals that NT4 probably used SPTI, which is implemented via Windows' DeviceIOControl API.

[Ian]

I'm curious whether there is any way that we could hook into a VM running Windows NT 4 and actually simulate the hardware, piping the data out to a separate process outside the VM that emulates the Real3D.

In the SDK the example program needs the dll wnaspi32.dll, so I am pretty sure they are talking to scsi through that. According to google that's some dll by the CD Rom manufacturer adaptec. My guess was their wrapper handles windows 9x/NT with the same code path, since there were differences in how the API worked between those 2 OSs.

This is what they were using
http://www.cdrlabs.com/reviews/cdr-tech ... mands.html

http://webcache.googleusercontent.com/s ... =firefox-b

Once upon a time I wrote a cd ripping tool lol. But I wrote it using low level commands. So you'd look up the relevant 6 byte commands or whatever they were in the draft mmc standard, and just pass them directly to the CD drive. But you did it with deviceio control. You could do stuff like set the drive speed, and all kinds of things you can't do with normal APIs. This would work on all NT versions. Windows is super backwards compatible like that. Anyway the point is there is a very good chance this would work on windows 10, no modifications required. After all you could use any scsi card with this setup, they didn't make their own special hardware to talk to this thing, with drivers that wouldn't work with a modern windows. It would be like talking to the serial port in windows. Assuming you have one, code from 20 years ago under NT should still work.

I suppose the obvious question is, do any real3d pro-1000s exist anywhere? (That still work)

By the way, that BIOS ROM is present in the SDK! Could be worth disassembling and having a peak.

Yes definitely but I'm not sure how to disassemble it