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
Network code
Forum rules
Keep it classy!
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
by Spindizzi » Sun Sep 10, 2017 11:59 am
- Spindizzi
- Posts: 196
- Joined: Thu Nov 17, 2016 8:55 am
- Location: France
Re: Network code
by 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:
Example 2: Accessing a variable directly (from 0x580e28):
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:
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:
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.
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.
-
Bart - Site Admin
- Posts: 3086
- Joined: Thu Sep 01, 2011 2:13 pm
- Location: Reno, Nevada
Re: Network code
by 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.
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
by Bart » Mon Sep 11, 2017 8:48 am
Return of the Jedi! 
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!
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.
-
Bart - Site Admin
- Posts: 3086
- Joined: Thu Sep 01, 2011 2:13 pm
- Location: Reno, Nevada
Re: Network code
by Ian » Mon Sep 11, 2017 9:14 am
Welcome back Nik
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!
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: 2044
- Joined: Tue Feb 23, 2016 9:23 am
Re: Network code
by 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
-
Jiterdomer - Posts: 627
- Joined: Mon Sep 26, 2011 6:37 pm
- Location: Los Angeles, California
Re: Network code
by 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!
-
MrThunderwing - Posts: 702
- Joined: Fri Sep 02, 2011 11:31 am
- Location: Bristol, UK
Re: Network code
by Conversus W. Vans » 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?
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?
"We're cowboys on the freeway." - Masanori Takeuchi, 1997
-
Conversus W. Vans - Posts: 277
- Joined: Sun Apr 27, 2014 3:27 pm
- Location: Grubnatraps, South Carolina
Re: Network code
by 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.
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. Ferraris are the most prestigious cars ever made in my opinion. There very delicate and pristine☺️.
i5-4670k, 3.4 Ghz
Nvidia GeForce GTX 1060 3 GB
i5-4670k, 3.4 Ghz
Nvidia GeForce GTX 1060 3 GB
-
ferrarifan - Posts: 231
- Joined: Sun Mar 29, 2015 7:38 pm
Who is online
Users browsing this forum: No registered users and 1 guest
