Friday, April 18, 2014

My Debug Xbox is Dying...

Although I'm doing quite well these days, my debug Xbox is not.  Right now, it's currently suffering from an internal hardware issue that has been known to happen every so often to original Xboxes (mostly to the v1.0 and v1.1 models).  This is quite tragic, and highly disappointing.

What's wrong with it?  I came home from work one day, and upon walking into my apartment, I discovered that my debug Xbox was ON and Panzer Dragoon ORTA was playing because I had lazily left the disc in there.  Apparently, I had also forgot to turn off the TV, so I heard it as I was walking inside.  At first I was thinking someone else was in there, which shouldn't be because I live by myself, but nothing in my room was altered, so that wasn't the case.  Instinctively, I walk over to turn it off, and the power button wasn't working, nor was the eject button, IIRC.  So I ended up unplugging it, and off it went.  As a test, I plugged it back in, and not only did it turn back on, I heard a little spark as I put it in.  Strange, huh?

Baffled as to why this was happening, I made a post on assemblergames.com, and discovered that this was a problem that occasionally happens to original Xboxes.  My thread was especially sad, because they had never seen this happen to a debug Xbox before.  What typically causes this?  A number of issues can be the cause of this problem:

  • A corroded bus line connecting the power button.
  • A blown or leaked capacitor.
  • And another issue I forgot involving the board that the power button is on, IIRC.
I haven't determined which one it is yet, because I don't have my torx screw driver set handy.  Since I have no soldering experience whatsoever, I'll probably look into finding someone else who can fix the problem, assuming it comes to this.  But looking on the bright side, my debug Xbox has lived a full and blessed life and it helped me learn more about Xbox's inner workings, much of which for the good of emulation.  Of course, I'm not letting it die without a fight, because it's a privilege to own one of these, and chances are I will never find another one.

And lastly, I just wanted to apologize for disappearing.  I didn't realize that it's been over a year since I've said anything.  Right now, I no longer have a healthy PC running 32-bit Windows to test on.  As of late, I've been primarily using a Mac to get my work done (don't worry, I'm not an Apple fanboy; although I like this OS, I only have a Macbook because I needed it).  I do have a working PC, but it's running x64, and x64 support still isn't too stable yet.  Frankly, I'd like to look into the issues with Virtua Cop 3 some more, and see if I can figure out why the JVS error is occurring.

Thanks for reading.

Shogun.

Sunday, March 31, 2013

More on Virtua Cop 3

Out of sheer curiosity, I wanted to see if I could at least get into the test menu for Virtua Cop 3.  Did I? Yup, I sure did.



Aside from the fact that it looks rather bad (it's because of a render target issue, causing the primary colour buffer not to be cleared properly AFAIK), it does work and I can change the settings and what not.  How did I do it?  I simply ran the vc3_t.xbe which takes you into the test mode.  That .xbe doesn't do much except pass along some parameters to tell Virtua Cop 3 to start in test mode.  Cxbx saves those parameters to disk as CxbxLaunchData.bin and loads it during the next call to GetLaunchData.  If VC3 doesn't find this data, then it will just try to load normally.  Trying to exit and resume normal loading will cause a crash unfortunately.  A call to RtlEnterCriticalSection that crashes when it calls EmuSwapFS is something I've never figured out how to fix as there are a handful of games that do this.

Still haven't worked out the problem with JVS not being recognized yet.  Just thought I'd share that since the Cxbx news front has been getting silent lately.

Shogun.

Virtua Cop 3 is starting to work.

Well, I spent my entire Saturday afternoon working on Cxbx for one request (now do you know how much I love you guys?) and finally got a result worth posting.

Okay, I have good news and bad news.  The good news is that it's finally confirmed that Cxbx is capable of emulating Sega Chihiro games.  Good thing, because it's a load off of my mind.  The mystery was killing me!  The bad news is that there are some parts of the JVS I/O board may have to be emulated in order for games to work.  Instead of emulating the JVS, I've been skipping and ignoring the port mapped I/O access functions as well as just creating stubs for the hijacked JVS functions.

This screen shot is proof.


Although I'm very pleased to have reached this far with Virtua Cop 3, I'll have to further research Chihiro's JVS hardware.  There's a chance that we may not have to emulate it though, since JayFoxRox's emu managed to get passed this.  It's probably a matter of satisfying a few conditions.

I'll put more work/thought into this later.  It's passed 1AM and I'm tired.  I'm just glad it's showing something for the time being.

Shogun.

Saturday, March 30, 2013

More on Chihiro

Okay, I do get people that continuously ask me about the possibility of playing SEGA Chihiro games on Cxbx.  Tbh, I do think it's possible, but no one has done it yet.  What it would take to do it is also a mystery.  Have I been working on it?  Yes, I spent some time last night doing some work on it.

By a fairly popular request, I've been working on Virtua Cop 3.  The reason I've chosen to accept this request is because it works on a debug Xbox without any major issues, as long as you have a TV that supports HD component cables.  Fortunately, I have a debug Xbox and a CRT that does support it, so there's a possibility I could use a lightgun.  Using the gamepad is really hard because the thumbstick is extremely sensitive.  One of these days, I should make a video of me playing it.

Now, before I go any further, I wanted to do a bit of backtracking so you understand where I'm coming from.  Remember when I made a post regarding Martin_sw's progress on his branch for Chihiro?  Although I haven't seen him in ages, I have had to essentially rediscover his work on my own.  Meaning, the Jvs functions I had to start adding myself.  I don't know exactly what the functions do or exactly what their parameters are, but at least I know the names of each function and how many parameters per function.  So, I added some stubs for the following functions:

  • JvsEEPROM_Read
  • JvsBACKUP_Read
  • JvsBACKUP_Write
  • JvsEEPROM_Write
  • JvsScFirmwareDownload
  • JvsScFirmwareUpload
  • JvsFirmwareUpload
There's more to add, but I haven't added them all yet.  So, what's stopping it from working?  The game appears to be accessing some port mapped I/O addresses directly and I haven't stopped to examine exactly what hardware is being accessed.  It was passed 2am and I was ready to hit the sack.  I could easily just make Cxbx skip over that stuff, but I'd rather see exactly what it's trying to do.  Since I'm on my Mac right now, I can't load up the disassembler right now and show you exactly what I'm talking about.

So there you have it.  For those of you who were wondering what I've been doing with Chihiro, this is it.  I'd like to try some more games to see if I get the same thing, or if this is just specific to Virtua Cop 3.  Thanks for reading.

Shogun.

EDIT: I copied and pasted the PMIO code I was talking about to pastebin, right here: http://pastebin.com/Ac1fgPWz

In particular, this is the one I'm examining since it's causing Cxbx to crash atm.


.text:000F5F50 sub_F5F50       proc near               ; CODE XREF: sub_F6C70+4F p
.text:000F5F50                                         ; DATA XREF: .data:off_215C58 o
.text:000F5F50                 mov     dx, 4026h
.text:000F5F54                 mov     ax, 102h
.text:000F5F58                 out     dx, ax
.text:000F5F5A                 mov     dx, 40E0h
.text:000F5F5E                 mov     al, 5
.text:000F5F60                 out     dx, al
.text:000F5F61                 retn
.text:000F5F61 sub_F5F50       endp

Since I don't know what ports these are off hand, I may have to do a bit of research on what they are.  I have two options, attempt to ignore the privileged instructions (in, out), or try to emulate the functionality.

Thursday, March 14, 2013

Castlevania: Curse of Darkness

This is something that I've been meaning to talk about for quite some time now, but kept forgetting to blog about it and get everyone else's viewpoint on it...

Right now, the game that's been showing the most progress on Cxbx is Castlevania: Curse of Darkness.  What does it do?  Well, for starters, it DOES go ingame, but does have two key issues with the, and they are:

- Lack of 8-bit palettized texture support
- Incomplete and buggy vertex shader conversion.

The first one has been implemented rather well in Dxbx.  I just haven't gotten around to adding it in Cxbx.  This is something that I can most definitely do, since I have a basic .tga loader which I modified to support 8-bit textures and have created a very basic mini-3rd person shooter for Xbox once, so I have a means of testing it thoroughly.  In short, I'm not too worried about this atm.

But what DOES worry me is the vertex shader problems.  Honestly, I have absolutely NO IDEA how Cxbx converts the vertex shader to a readable form, nor do I understand how the vertex or pixel shader is converted on a real Xbox.  I know it should be straight forward, but I've always had trouble grasping it.

Fixing these two things will get the game playable beyond the shadow of a doubt.  Input, background music, and everything else works fine.  Keep in mind that this game was ported from PS2 and still contains some coding architecture that is best optimized for PS2.  Replacing the VU transformation code, all of the transformations are done in the vertex shaders.  The textures are also all palettized because of the PS2's video memory limitations (only 4MB, but lots of bandwidth).

But the biggest question is, do people want this?  Honestly, that's not a very big concern for me because I care more about the emu's success and compatibility than what people want to play from an immediate perspective.

So, please let me know what you all think of this.  I'm really curious to know.

Shogun.

Thursday, February 14, 2013

My Game Development Blog

I just wanted to let you guys know that I've been putting alot of my time and energy into building my own game dev company for a while now.  Given the fact that there isn't much hiring going on in this region for those who don't have 5+ years of experience or more on the job, I'd much rather take my chances going out on my own doing what I enjoy.  This has been my plan for a few years now, but at first I wanted to get more industry experience before getting started, but that plan isn't working due to the overwhelmingly pickiness of hiring managers these days.

Although I haven't released any of my games yet, I've gotten off to a good start.  I have the equipment, hardware and software to do most things that I plan to do, made a nice little office in my apartment, and a few games that people are already looking forward to buying/playing (not just people, one 3rd party company is interested in one of my games).  Sounds great in all, but there's much more work to be done besides coding and designing levels/artwork. =)

My blog is located at: blog.shogun3d.net

This doesn't mean that I've stopped working on Cxbx at all!  It just means that I have more than one project going on (one that will hopefully pay off).  I still have time during my off days and weekends to work on Cxbx and other emulation related stuff.

So if you want, feel free to follow this blog and give your opinions on the games I'm working on.  Any feedback is welcome.  And at this point, I can use all the good advice I can get. :)

Shogun.

Friday, February 8, 2013

Dead to Rights: BSOD anyone?

I recently bought a few Xbox1 games from a used game store about 2 weeks ago, one of them was Dead to Rights.  I already own the game, but I bought another copy since my other copy of it is out of reach (in another state with most of my Xbox games).  So I dump the game, thinking "Yeah, now I can finally fix that crash I couldn't track before...".  As soon as I get ingame, what happens?  BSOD.  Wtf? Cxbx hasn't given me a BSOD since that time I tried to emulate Wolfenstein back in 2004-05ish!  The worst part is, I have no idea what's causing it. I think it's an issue with XP.  It keeps bringing up win32.sys, so it's probably kernel related...

Back when I had vista, this wasn't a problem.  I never thought I'd say it, but I actually do miss vista a little.  While I and most other users hated it, Cxbx loves it with a passion, as it's the most compatible version of Windows running it.  I tried Win7 and 8, and none of them ran Cxbx as well as Vista did.

"This game is on PC, who cares?"  I do.  This is a battle for completion, and I don't have as many games using XDK 4432 as I'd like, so...

Meh, I'm not going to worry about it too much, so I'll just have to work on some other games until I either fix what's wrong with this laptop or get a new PC altogether (the latter would be nice).  Maybe I'll just keep bashing away at Otogi or something like that.

Shogun.