Network code

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Re: Network code

Postby Spindizzi » Sun Sep 10, 2017 11:59 am

Hum, it seems to be a very very long road to do
I thought it would have been simpler
I rewrite the memory mapping part this week end that has changed the r/W handlers.
Now the dump is in one piece (concatenation of the 2 old parts)

we have now:

Network code copy ending <- false info ??
RESET NetBoard PC=000000
W32 *********************** @20800<-0 <- now it seems correct
Network code copy ending
RESET NetBoard PC=00083A
W32 *********************** @20804<-f03e000
W32 *********************** @20808<-5003000
W32 *********************** @10180<-0
W32 *********************** @10110<-800000
W32 *********************** @10110<-800000
W32 *********************** @10180<-fffffff
W32 *********************** @10110<-b00000
W32 *********************** @10110<-b00000
W32 *********************** @10000<-e407b80
W32 *********************** @10110<-900000
W32 *********************** @10110<-900000

the reset with pc=0 is certainly the power on with no code loaded

As I remember, the first thing ppc does is to test if he can r/w in network memory (shared memory ?) .If success, this means the board is present

0xc0000000-0xc000ffff is filled with 0 (net buffer)
The whole dump is transferred into network ram (0xc0020000-0xc003ffff) //typo error
The program starts in the dump at 0x800 to 0x243f (or more) and it's loaded at 0xc0020800.

W32 *********************** @10110<-900000
W32 *********************** @10110<-900000
happen right after the sentence : this is master controller
I don't know about the ppc, just that it's in loop. Apparently there are no accesses to net memory (not sure because there is the address 0xc0000000 loaded in ppc register at (ppc)pc=0x61bc (entry point pc=0x6128), However, I don't think it's net related)

On the 68k, I can debug step by step with the debugger. There is a trigger at 0x60c, according to the value inside it branches to different portion of code (0xff is for default looping, testing 0x01, 0x02, 0x03, 0x04, 0x07 )
Sadly My knowledge about irq is quite low, I don't know how to throw an irq manually and I don't add irq management in network code
Since the 68k waiting for a value change at 0x60c, the ppc must change this value but how and where

The notes Nik has found are terrible!! but beyond my skills

The new version with the more correct memory mapping is here https://yadi.sk/d/HOQ6iHd_3MmRZw
No crash when exiting now . I've included the .exe with debugging option (run with daytona2.zip -no-threads -enter-debugger)

edit : typo error
Spindizzi
 
Posts: 64
Joined: Thu Nov 17, 2016 8:55 am
Location: France

Re: Network code

Postby Bart » Mon Sep 11, 2017 6:28 am

The MAME driver contains a layout of the network board and unless I'm mistaken, it appears there are 6 x 32KB RAM chips on there. So a total of 192KB? From your findings it seems 128KB of space is touched. The other 32KB could still be there or maybe it's used by the network chip?


Looks like you're doing some good work. Let me give some advice and a suggestion first:

- Maybe we should integrate your work into the code base? As a matter of strict security policy, I do not run binaries produced by anyone. So to try out any of your changes I'll need the code. I don't have much time to contribute, and zero this week, but I could be more helpful if it was in the source tree.
- If the code is cleanly integrated and we can have it disabled by default (either via macro or, preferably, by a configuration option), that would be great. Maybe you could post a diff and we can see how much work would need to be done to clean it up and mainline it into the SVN? Then you could be granted developer access to work on this. The 68K CPU should be integrated into the debugger but I don't think that's too hard.

You've gotten this far, I think you definitely have the skill to continue debugging this. It's not easy but we all start somewhere :) Some advice and tips:

1. It's painful but you may want to consider trying to hand-translate, very carefully, the entire 68K program. Or most of it. Especially the IRQ handlers! There are many approaches for this. Maybe even a professional tool like IDA Pro could work? I've never used them. But other reverse engineering gurus do. You can find an example of how I do it manually for PowerPC code in the frame timing thread. I first comment subroutines carefully and then translate them to C. I take care to identify registers that are used as RAM base pointers and whenever I detect a global variable being accessed it, I first label it as e.g., _580e8 (the address) and if it's functionality becomes 100% clear, I rename it to e.g., _vbl_count.

2. Identifying standalone global variables (32-bit words, 8-bit bytes, etc. -- but not arrays) is often super easy in PowerPC code. To load a value from an arbitrary 32-bit address, the PowerPC needs two instructions. Each instruction is a fixed 32 bits so it cannot encode a 32-bit address. Instead, it loads the high half of the address first and then accesses the variable via a 16-bit offset.

Example 1: Computing an address (0x375be0) and storing it in another register. This is often used when it is an array and subsequently will be accessed using yet another index:

Code: Select all
0x0006852C: 0x3D200037   li   r9,0x00370000
0x00068530: 0x3B895BE0   addi   r28,r9,0x5BE0


Example 2: Accessing a variable directly (from 0x580e28):

Code: Select all
0x00038FB4: 0x3D400058  li  r10,0x00580000
0x00038FB8: 0x816A0E28  lwz r11,0xE28(r10)


This is clearly a standalone, single 32-bit variable. When I want to find what sets this, I can easily search the entire disassembly for the string: "0xE28(" (the register being indexed will likely be different each time, so don't include that in the search). It's a neat trick that is very good for variables that are rarely set (such as things set only in IRQ handlers and then read a few times elsewhere in the code).

3. Produce a disassembly of the entire PowerPC code by dumping the RAM and using ppcd. In Model3.cpp's ~CModel3(), you can uncomment some code that dumps a file called "ram" on exit. Then, the PowerPC disassembler (PPCDisasm.cpp) can be compiled with a macro defined (STANDALONE) to produce a standalone executable. I use this to disassemble the entire game code at once into a text file. You don't need to worry about origin or alignment because it starts at address 0 and each instruction is 32 bits. I disassemble the first 262144 (256K :)) instructions but there are actually far fewer. The command is "ppcd ram -l 262144 >file.txt". I recommend doing this to hunt through the PowerPC code.

4. Familiarize yourself with the PowerPC IRQ subroutine. There is only one IRQ vector on PowerPC. The game then determines who fired the IRQ by checking the IRQ controller register. The SCSI and DMA devices can fire IRQs without appearing on the IRQ controller and there is always a subroutine that is executed first to check the DMA/SCSI registers for whether an IRQ has happened. You can ignore this. Here is Fighting Vipers 2's IRQ handler:

Code: Select all
;
; IRQ handler
;
0x00003CA8: 0x3821FFC0   addi   r1,r1,-0x40
0x00003CAC: 0xBC01FF80   stmw   r0,-0x80(r1)
0x00003CB0: 0x3821FF80   addi   r1,r1,-0x80
0x00003CB4: 0x7FFA02A6   mfspr   r31,srr0
0x00003CB8: 0x7FDB02A6   mfspr   r30,srr1
0x00003CBC: 0x7FA00026   mfcr   r29
0x00003CC0: 0x7F8802A6   mfspr   r28,lr
0x00003CC4: 0x7F6902A6   mfspr   r27,ctr
0x00003CC8: 0x7F4102A6   mfspr   r26,xer
0x00003CCC: 0xBF41FFE8   stmw   r26,-0x18(r1)
0x00003CD0: 0x3821FFC0   addi   r1,r1,-0x40
0x00003CD4: 0x7CA000A6   mfmsr   r5
0x00003CD8: 0x54A504E2   and   r5,r5,0xFFFFDFFF
0x00003CDC: 0x60A51032   ori   r5,r5,0x1032
0x00003CE0: 0x7CA00124   mtmsr   r5
0x00003CE4: 0x4C00012C   isync   
0x00003CE8: 0x48005F05   bl   HandleDMAInterrupt  ; 0x00009BEC
0x00003CEC: 0x48003649   bl   HandleSCSIInterrupt ; 0x00007334 -- how is this possible? No check is made for whether this device exists.
0x00003CF0: 0x3C60FE10   li   r3,0xFE100000
0x00003CF4: 0x88630018   lbz   r3,0x18(r3)         ; r3 = pending IRQs
0x00003CF8: 0x3C800058   li   r4,0x00580000
0x00003CFC: 0x88840E30   lbz   r4,0xE30(r4)        ; r4 = g_irq_mask
0x00003D00: 0x7C632038   and   r3,r3,r4            ; r3 &= r4
0x00003D04: 0x5465063E   and   r5,r3,0x000000FF
0x00003D08: 0x7CA03120   mtcrf   0x03,r5           ; IRQ flags into cr6 and cr7
0x00003D0C: 0x40960018   bf   cr5[eq],0x00003D24
0x00003D10: 0x3C600058   li   r3,0x00580000
0x00003D14: 0x88631321   lbz   r3,0x1321(r3)
0x00003D18: 0x5460C801   rlwinm.   r0,r3,25,0x80000000
0x00003D1C: 0x41820008   bt   cr0[eq],0x00003D24
0x00003D20: 0x480036B1   bl   0x000073D0          ; some sort of time delay

CR: LT GT EQ SO

7 LT
6 GT
5 EQ
4 SO
3 LT
2 GT
1 EQ
0 SO

0x00003D24: 0x419F0111   btl   cr7[so],handle_irq_01 ; 0x00003E34  ; IRQ 0x01
0x00003D28: 0x419E0131   btl   cr7[eq],handle_irq_02 ; 0x00003E58  ; IRQ 0x02
0x00003D2C: 0x419D023D   btl   cr7[gt],handle_irq_04  ; 3f68 IRQ 0x04
0x00003D30: 0x419C01D1   btl   cr7[lt],handle_irq_08 ; 0x00003F00  ; IRQ 0x08
0x00003D34: 0x419A02D1   btl   cr6[eq],handle_irq_20 ; 0x00004004  ; IRQ 0x20
0x00003D38: 0x419B00D9   btl   cr6[so],handle_irq_10 ; 0x00003E10  ; IRQ 0x10
0x00003D3C: 0x419802B5   btl   cr6[lt],handle_irq_80 ; 0x00003FF0  ; IRQ 0x80
0x00003D40: 0x41990291   btl   cr6[gt],handle_irq_40 ; 0x00003FD0  ; IRQ 0x40  MIDI interrupt
0x00003D44: 0x38600005   li   r3,0x00000005
0x00003D48: 0x38210040   addi   r1,r1,0x40
0x00003D4C: 0xBB41FFE8   lmw   r26,-0x18(r1)
0x00003D50: 0x7F4103A6   mtspr   xer,r26
0x00003D54: 0x7F6903A6   mtspr   ctr,r27
0x00003D58: 0x7F8803A6   mtspr   lr,r28
0x00003D5C: 0x7FAFF120   mtcrf   0xFF,r29
0x00003D60: 0x7FDB03A6   mtspr   srr1,r30
0x00003D64: 0x7FFA03A6   mtspr   srr0,r31
0x00003D68: 0x7C210B78   mr   r1,r1
0x00003D6C: 0xB8410008   lmw   r2,0x08(r1)
0x00003D70: 0x80010000   lwz   r0,0x00(r1)
0x00003D74: 0x80210004   lwz   r1,0x04(r1)
0x00003D78: 0x38210040   addi   r1,r1,0x40
0x00003D7C: 0x4C000064   rfi   


Notice in the middle how it cleverly dispatches the various different IRQ sub-handlers for each IRQ. It reads the IRQ register into the condition code field. Each bit will correspond to a condition and I've mapped that out for you. Almost every game uses this method (although I think Daytona 2 does not!). This is how you can find where all the IRQ handlers are. One of them is the network board IRQ. You can now try to make sure this code is executed in the debugger or by triggering in in CModel3::RunMainboardFrame().

In this IRQ handler, address 0x3cf4 is where the pending IRQs are read from the controller:

Code: Select all
0x00003CF0: 0x3C60FE10   li   r3,0xFE100000
0x00003CF4: 0x88630018   lbz   r3,0x18(r3)         ; r3 = pending IRQs


So after you execute line 0x3c4 in the debugger, you could load r3 with your own value to simulate IRQs you want and step through them.

I hope these tips help you. The network board took Nik a lot of time. There is no shortcut. The 68K program needs to be studied carefully. He never understood the whole program but spent a lot of time digging into it and also trying the various different 68K IRQs to see what effect they had. When the PowerPC is stuck somewhere, you may have no choice but to open up the game disassembly file (that you produced with ppcd) and start manually translating the subroutines to understand what they might be doing.

It's a piece-by-piece, iterative, and frustrating process. But if you're methodical, you'll suddenly find yourself making progress after an initial slow period of confusion.
User avatar
Bart
Site Admin
 
Posts: 2058
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Network code

Postby nikdd » Mon Sep 11, 2017 7:06 am

Hey Bart, hey everyone, how's it going? Wow, first post in four or five years or so... rumours of my demise have been greatly exaggerated - I'm still alive and kicking (just!) :-)

Great to see Supermodel is still going strong - the recent improvements to the graphics engine look fantastic - nice job!

Various people have got in touch via various means (hi Ian, hi Boomslangnz!), asking for my old network code. Apologies for being so elusive until now, real life just simply got in the way (oh to be young and carefree again...). Anyway, I don't want to promise too much but I will try to salvage what I can of the code (it's on a hard disk in a box somewhere, still unpacked from a recent house move) and upload it to SVN, probably as a separate branch since it's based off an old revision. No doubt the code has stagnated somewhat by now, and it was never fully functional in the first place, but it might be of some help...

Either way, I hope to be able to pop by here more often in the future... and maybe some day I'll even get some time to work on Supermodel again :-)...

Keep up the good work and all the best, Nik.
nikdd
 
Posts: 180
Joined: Fri Sep 02, 2011 10:39 am
Location: London

Re: Network code

Postby Bart » Mon Sep 11, 2017 8:48 am

Return of the Jedi! :shock:

Good to hear from you, Nik! I hope all is well in the real world :) It would be awesome if you could upload that code to a separate branch as you suggested. If you're willing, your GUI version of Supermodel with Supermodel GUI Debugger would also be tremendously useful. I've been wanting to add a wx-based GUI and there's no way I would be able to attempt replicating your incredible debugger work. If you're willing to share that code, it would be super useful down the road. I supplied Ian with the binary you gave me years ago and I know he still uses the visual debugger to this day. It's extraordinarily useful and with the new rendering engine, it would be simply a phenomenal experience. I've been wanting to add support for dumping out models, graphics, and even entire scenes to editable files.

I hope we'll hear from you again soon!

nikdd wrote:Hey Bart, hey everyone, how's it going? Wow, first post in four or five years or so... rumours of my demise have been greatly exaggerated - I'm still alive and kicking (just!) :-)

Great to see Supermodel is still going strong - the recent improvements to the graphics engine look fantastic - nice job!

Various people have got in touch via various means (hi Ian, hi Boomslangnz!), asking for my old network code. Apologies for being so elusive until now, real life just simply got in the way (oh to be young and carefree again...). Anyway, I don't want to promise too much but I will try to salvage what I can of the code (it's on a hard disk in a box somewhere, still unpacked from a recent house move) and upload it to SVN, probably as a separate branch since it's based off an old revision. No doubt the code has stagnated somewhat by now, and it was never fully functional in the first place, but it might be of some help...

Either way, I hope to be able to pop by here more often in the future... and maybe some day I'll even get some time to work on Supermodel again :-)...

Keep up the good work and all the best, Nik.
User avatar
Bart
Site Admin
 
Posts: 2058
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Network code

Postby Ian » Mon Sep 11, 2017 9:14 am

Welcome back Nik :)

Great to see Supermodel is still going strong - the recent improvements to the graphics engine look fantastic - nice job!


Thanks! It actually worked out better than I ever expected :) Bart managed to get a copy of the real3d pro-1000 SDK which helped a load!
Ian
 
Posts: 1216
Joined: Tue Feb 23, 2016 9:23 am

Re: Network code

Postby Boomslangnz » Mon Sep 11, 2017 11:58 am

Hi Nik!!!! :mrgreen: :mrgreen:

Good to hear from you man
Boomslangnz
 
Posts: 109
Joined: Mon Jul 23, 2012 10:35 pm

Re: Network code

Postby Jiterdomer » Mon Sep 11, 2017 12:37 pm

Welcome back Nik! Hopefully you'll be working on the GUI and Networking with Ian, Bart, and Harry!
Feel the heartbeat of my machine through this tight seat. I feel every motion of my machine
Image
User avatar
Jiterdomer
 
Posts: 472
Joined: Mon Sep 26, 2011 6:37 pm
Location: Los Angeles, CA

Re: Network code

Postby MrThunderwing » Mon Sep 11, 2017 1:10 pm

nikdd wrote:Hey Bart, hey everyone, how's it going? Wow, first post in four or five years or so... rumours of my demise have been greatly exaggerated - I'm still alive and kicking (just!) :-)

Great to see Supermodel is still going strong - the recent improvements to the graphics engine look fantastic - nice job!

Various people have got in touch via various means (hi Ian, hi Boomslangnz!), asking for my old network code. Apologies for being so elusive until now, real life just simply got in the way (oh to be young and carefree again...). Anyway, I don't want to promise too much but I will try to salvage what I can of the code (it's on a hard disk in a box somewhere, still unpacked from a recent house move) and upload it to SVN, probably as a separate branch since it's based off an old revision. No doubt the code has stagnated somewhat by now, and it was never fully functional in the first place, but it might be of some help...

Either way, I hope to be able to pop by here more often in the future... and maybe some day I'll even get some time to work on Supermodel again :-)...

Keep up the good work and all the best, Nik.


Holy shit! I was genuinely worried that something bad had happened to you. Glad to know that all's well Nik!
User avatar
MrThunderwing
 
Posts: 428
Joined: Fri Sep 02, 2011 11:31 am
Location: Bristol, UK

Re: Network code

Postby ConversusVans » Mon Sep 11, 2017 3:44 pm

Welcome back, Nik!! :)

You happen to be the one who fixed a bunch of mess with Harley and ECA, preventing them from being tremendously slow with garbage on screen.

If networking sees the light of day, I cannot wait! Did link mode work for L.A. Riders?
- Conversus W. Vans (Paul)
User avatar
ConversusVans
 
Posts: 193
Joined: Sun Apr 27, 2014 3:27 pm
Location: The Abandoned Land

Re: Network code

Postby ferrarifan » Mon Sep 11, 2017 6:43 pm

Hey Nik welcome back to the Supermodel fourm. Glad to hear from you again. Progress has been awesome lately. So happy to hear from you. :) Ian's 3D engine now looks closely to the original hardware and Supermodel has been improved. I remembered using Supermodel in 2011 on my old desktop with an Intel Pentium 2.8 GHZ with an AMD Radeon GPU(Which still runs at decent speeds) for the first time and i always wanted to play Daytona 2 using network play. But overall,we might be able to play online someday. But there's no rush guys. I'll wait for the network emulation. :)
User avatar
ferrarifan
 
Posts: 136
Joined: Sun Mar 29, 2015 7:38 pm

PreviousNext

Return to The Dark Room

Who is online

Users browsing this forum: YoYo09 and 1 guest