Real3d pro-1000 emulation

[Ian]

Not talking about the model 3 at all. Bart suggested the idea that he could emulate the actual stand alone real3d pro-1000. My initial thoughts were, yeah not in 100 years lol. But then the brain started working. The pro-1000 sdk talks not directly to windows, but through a dll called wnaspi32.dll which is a fairly standard, but 3rd party way to talk to CD/hdd/tape drives etc.

I thought how hard could it be to write a dummy hook dll and just give it the inputs it needs ...
Turns out not really that hard since the real3d is using so few scsi commands.

Anyway I got this far ..
https://i.imgur.com/BrcNGa3.png

The test program that comes with the real3d sdk gets as far as recognising there is a real3d attached ..
I don't think it would be too hard to finish it so we can actually run all the demos from the sdk .. I mean the renderer is like 99% complete. Just need to feed it with the right input.

[Ian]

Well I made a bit more progress with the real3d scsi test program
basically it passes now



SCSI address 0 corresponds to the real3d read registers

[mashakos]

You're emulating unreleased hardware now? Absolute Madlad lol

looking forward to more updates!

[Bart]

The Pro-1000 was released. That's how we have the SDK Unfortunately, I haven't been able to come across a real unit. They seem to have been produced in limited quantity and quickly became obsolete. I think this is an awesome project!

Ian: you may be able to just pipe the data to your renderer and display the demos, which would be a high-level emulation. But I wonder what, if anything, the PowerPC on the Pro-1000 was doing and whether it makes sense to properly emulate it as well?

[Ian]

Unfortunately, I haven't been able to come across a real unit.

I've googled around and I've never even seen anyone talking about this hardware. Ie they have owned this HW and did a blog post or something about it. I'd be super interested to know if anyone does actually own one.

Ian: you may be able to just pipe the data to your renderer and display the demos, which would be a high-level emulation. But I wonder what, if anything, the PowerPC on the Pro-1000 was doing and whether it makes sense to properly emulate it as well?

I assume the powerpc just ran the actual code, and by that I mean it processed the display data for the frame, ie parsing the culling does etc. It probably also handled all the input/output from the scsi hardware. The real3d pro-1000 actually had graphics hardware that is entirely missing from the model 3, or not missing they replaced it. The real3d has it's own kind of tilegen which draws background bitmaps, that can scroll and you can apply fog to. In the model3 its been replaced with the tilegen from the system24 and probably model1/2 boards.

I did make a bit more progress with this last night.

Code: Select all

      else if (command->cmd.CDBByte[0] == SCSI_READ6) {      // read command

         //==========
         int address;
         int length;
         //==========

         length = command->cmd.CDBByte[4] * LBA_SIZE;

         address = command->cmd.CDBByte[1] & 0x1F;
         address = (address << 5) | command->cmd.CDBByte[2];
         address = (address << 8) | command->cmd.CDBByte[3];

The read and write methods look something like that for scsi. Basically you have a struct and pull out the addresses and other fields from it. But the address structs for read and write always seem to be zero. I couldn't work that out to start with .. but the io_structs_h header file in the sdk has this

Code: Select all

} Scsi_Head;

Which contains the field unsigned long address;
So I am pretty sure the data is just following this header. I've yet to actually look at the data though.

I did find this in the SDK

Code: Select all

/*
    The members of this structure Pro_Ret_Dat should not exceed 512 bytes
    since this is what is allocated on the HOST and in the PRO
*/
typedef struct
{
    Scsi_Head   scsi_head;
    Stat_Pckt   stat_pckt;
    unsigned long magic;
    Sync_Info   sync_info[LINE_RATES];
    Misc_Info   misc_info;
} Pro_Ret_Dat ;


So I tried just returning this struct and filling out the appropriate members ... and it works. Well it works enough for the test program

https://i.imgur.com/gY5gB7G.png

Before I just filled the entire 512 byte buffer with 0xFF and it gave the previous screenshots. But here it actually correctly sets the values, so definite progress. Next step is to see what is actually written.

[Bart]

Unfortunately, I haven't been able to come across a real unit.

I've googled around and I've never even seen anyone talking about this hardware. Ie they have owned this HW and did a blog post or something about it. I'd be super interested to know if anyone does actually own one.

Likewise. It definitely existed. I found one of the sales managers on LinkedIn, in addition to various people who supported or helped develop the product at Real3D. Given that customers were primarily military/aerospace, it's not too surprising that there isn't much of a trail on Google.

I assume the powerpc just ran the actual code, and by that I mean it processed the display data for the frame, ie parsing the culling does etc. It probably also handled all the input/output from the scsi hardware. The real3d pro-1000 actually had graphics hardware that is entirely missing from the model 3, or not missing they replaced it. The real3d has it's own kind of tilegen which draws background bitmaps, that can scroll and you can apply fog to. In the model3 its been replaced with the tilegen from the system24 and probably model1/2 boards.

You're right -- although I would think there would be zero parsing of culling nodes going on. Model 3 just feeds those straight to the Real3D video memory and I would assume the PowerPC driver for the Pro-1000 did the same, unless they are transmitted over the SCSI bus in a different form.

I wonder why on earth Sega would opt for a tile generator over a proper scrolling frame buffer. Cost of memory, I guess?

Before I just filled the entire 512 byte buffer with 0xFF and it gave the previous screenshots. But here it actually correctly sets the values, so definite progress. Next step is to see what is actually written.

Very cool

[Ian]

The scsi test program polls the real3d registers until
unsigned long rend_done :1

changes to a 1. Currently we always return 1 for this thing.

Other parts are testing the valid bit is 1

I wonder why on earth Sega would opt for a tile generator over a proper scrolling frame buffer. Cost of memory, I guess?

Yeah could be cost. The system24 tile gen was a lot more flexible than the real3d scroll layers.

Wonder if we could find someone with working hardware .. i guess that's a super long shot. These things retailed from like 20-50k or something.