The first new Model 3 program in 17 years?

[Bart]

https://sourceforge.net/p/model3emu/code/HEAD/tree/

[Vasiliy Familiya]

https://sourceforge.net/p/model3emu/code/HEAD/tree/

Thank you, but I'm afraid, I'll even so need a someone's help with input functions realisation in the game code.

[Bart]

I don’t understand. How will you handle graphics (you’ll have to thoroughly understand Supermodel’s graphics emulation code)? Reading the controls should be one of the easiest things to figure out. It will get much more difficult after that.

[Vasiliy Familiya]

How will you handle graphics (you’ll have to thoroughly understand Supermodel’s graphics emulation code)? Reading the controls should be one of the easiest things to figure out. It will get much more difficult after that.

Then, the only thing is left is to find somebody who can help us with a graphics and other difficultest parts of game code.

[Vasiliy Familiya]

Does Model 3 have joypad related memory mapped IO registers like NeoGeo's $10FD94~$10FEDD, and is it possible to create the include file similar to header file iside attached archive for own Model 3 program?

input.zip

(810 Bytes) Downloaded 133 times

P.S. The header file in archive is taken from DATlib graphics library for Neo-Geo SDK by Sebastian Mihai.

[Bart]

It does and you can find their address in Supermodel’s Model3.cpp. I’m confused by your request. If you intend to write code to run on Model 3, you ought to have the necessary C language and systems-level programming expertise to work this out. There are no Model 3 development libraries. You have to code to the hardware and write your own. Reading a register is trivial — it will be much more work to get graphics on the screen.

[krom]

Hi after a long break, I've been getting back into Sega Model 3 coding =D
I saw I have missed lots of progress from Bart at https://github.com/trzy/model3/, which has been updated recently!
It took me a while to work out a way to load the compiled crom.bin file with the new xml loading in latest Supermodel WIPs...
So I thought I'd post a working solution here in case anyone needs the help:
P.S. I forgot the crom.bin needs to be loaded to the upper crom region (0x0800000 - crom size)!

Copy this crom.zip code block inside the games section of Config/Games.xml, to be able to run a zipped crom.bin
** EDIT ** (Using help from Bart Below)

Code: Select all

  <game name="crom">
    <hardware>
      <platform>Sega Model 3</platform>
      <stepping>1.0</stepping>
    </hardware>
    <roms>
      <region name="crom" stride="1" chunk_size="1">
        <!-- CROM0 -->
        <file offset="0" name="crom.bin" />
      </region>
    </roms>
  </game>

Let me know what you guys think

It would be amazing if we could get a newer PPC GCC devkit to code with to replace the old PPC GCC 5.1.0 package too!
Anyway I def want to mess with GFX now, I'll let you know how I get on! =D

** EDIT **

I found a newer devkitPro PPC GCC 8.3.0 that can compile the Model 3 source code here:
https://github.com/devkitPro/buildscripts/releases
It's just a 33MB download!

New Steps I took to get it to compile & run:
1. Made a base "MSYS-1.0.11.exe" install https://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/msys-1.0.11/
2. Copied contents of https://github.com/devkitPro/buildscripts/releases/download/devkitPPC_r35/devkitPPC_r35-win64.tar.xz 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 3 "Makefile" & "libmodel3/Makefile.inc" & the "test/test.c" files.
5. I also edited the "Makefile" & renamed all references to "/c/mingw64-ppc/bin/powerpc-603e-eabi" to "powerpc-eabi". (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.zip"

Hope this helps =D

[Jiterdomer]

It's good to see you back on the grid, krom!

[Bart]

Hey krom! Good to see you back here.

A couple of notes on loading custom ROMs with Supermodel's Games.xml mechamism:

1. You shouldn't need to specify the crc. If no CRC is specified, Supermodel will load from the zip by file name only. Conversely, when a CRC is present, Supermodel ignores the name and loads only by CRC.
2. It's true that the file will be loaded at the upper 2MB of the address space but it should be mirrored across the entire 8MB CROM space. Therefore, you should be able to specify the offset as 0.

My recent experience (last year) of trying to get SCSI DMA to the Real3D working was a failure. The code currently in libmodel3 performs DMA transfers correctly as far as I can tell. I tested copying from one CPU RAM region to another. But when I write to Real3D space, the system locks up. I suspect that the Real3D is not set up correctly. The real hardware writes a lot of data to JTAG. You'll notice that I've replicated many of these writes but I may have missed something. Or, I may be missing some other obscure sequence of register writes.

So if you want to write some 3D graphics code that has a hope of running on real hardware one day, my recommendations are:

1. Cleanly separate scene graph and other data structure preparation (matrices, viewports, texture uploads) from the rest of the code, so that it can easily be fixed when we discover what the hardware actually accepts.
2. Do not access ping pong (8e) and culling RAM (8c) in the same frame. Supermodel calls these "culling RAM high" and "culling RAM low". We don't know yet for sure but it seems very likely that ping pong memory is double-buffered and the other memory regions are not. Write your code in such a way as to ensure that culling RAM (8c) is fully set up before uploading display lists that tell the Real3D to fetch nodes there. Keep in mind that after sending an end-of-frame command (0x88000000 <- any value), the ping pong memory page will flip. So you'll probably need at least a couple of frames to transition into a safe state before updating culling nodes.
3. We don't know how polygon RAM is managed. I would be conservative and write a static mesh initially and then avoid doing per-frame updates. Model 3 games *do* frequently perform per-frame updates for dynamic and skinnable meshes but we just don't know enough about frame timing yet to be sure how this works.

Can't wait to see what you come up with!

[krom]

It's good to see you back on the grid, krom!

Nice one, it's great to be back

Thanks Bart for all the tips & help, so much cool stuff to work out on Model 3 HW, I will do my best to help out, & update you with what I find out =D