Xbox port

[incrediclint]

Whatever it is with the clutB thing, doesn't seem to matter, it still displays fine. Weird.

On the controller thing, that might very well be my problem. I just started input code yesterday so we'll see.

Edit: Actually, it gets as far as the static 3do logo and just sits there. Doesn't ever move on to the animated Panasonic REAL screen or load CD screen. Any idea what is -required- to get it to load the rest? Nothing I'm trying seems to do anything.

Edit2: Apparently nothing is actually required beyond loading the bios file. I went through the 4DO source and disabled nvram/gamesource/input/sound so essentially it's just the core + fourdo rendering and it loads up fine. Must be something with my bios loading then.

[incrediclint]

Got a lot done today.

Input is working and loading game ISO's works. Tested Real Pinball and Trip'd, both running at 10-15 fps.

No sound yet. No UI yet. Still lots of room for optimization.

I actually played Trip'd for while. Need to test some more demanding games still.

Problem was with the way I was loading the bios image. Once I redid that everything started to fall into place.

[incrediclint]

Updates on my port of 4DO/Freedo to xbox:

Added UI to load iso's from HDD.
Loading games from the DVD drive works. (tested with cd-r's, nothing else)

So everything is basically working and needs refinement. The speed is still not acceptable and I don't think there is any more speed to be gained outside of the core.

Might be releasing a pre-alpha soon!

How far did you get with your HLE 3do emulator johnny? I'm thinking that's going to be the only way to get decent speed on the xbox. The core is the limiting factor now.

[Johnny]

The high-level approach didn't get very far in the grand scope of things. I finished the CPU emulation and was slowly piecing together the operation system calls when I called it quits.

The real killer with a fully high-level emulator was that many of the 3DO SDK's function calls (in C) were actually macro functions defined in their header files that would access and alter structures held in a known location in memory. This meant that those structures had to be kept kosher at all times, because the games out there had code that relied on it. That was true even for the simplest of function calls, like allocating memory. There was also no memory manager and thus no guarantee that a game out there wouldn't "cheat" and save some cycles by avoiding the OS calls and just looking at the structures themselves.

So, I would recommend against attempting a full-HLE approach. You may be able to intercept all the information you'd need from the graphics processing. I don't know the details of those OS calls, though. From what I understand, this is what Altmer is doing with his new emulator, Phoenix. If you wanted to attempt this I could give you a little more info and help you understand how to intercept those OS calls. 3DO's OS uses software interrupts (SWI) for most OS functions.

If you haven't definitively identified the slowness on the xbox port, I'd recommend looking into the CD read speed. I have noticed in some games that the FreeDO core seems to read sectors synchronously when the original hardware would have done it asynchronously. When running 4DO from an ISO file this is mostly negligible (and I also think a lot of games rely mainly on just synchronous fetching). If that's the problem, you may be able to band-aid this by soaking up ram with a forward-looking cache of CD sectors. If it all runs slowly even with just the BIOS, then throw this whole thought out.

[incrediclint]

I've been playing with your old HLE 4do code and started with the first SWI that I saw called when loading a game which was FindItem. I've found enough information to know what the function should do and how to deal with it's parameters, but extracting those paramaters yields unexpected results. I know the first paramater holds both the folio type number and the item type number, but extracting the numbers results in folio/item type numbers that don't exist in the SDK.

I'm assuming that it's actually something else that is causing this and the paramater isn't being passed correctly from somewhere else. Besides trying to fill in/implement those SWI functions, I haven't touched anything else. It's all far over my head.

On the xbox port: I'm afraid the xbox is just not powerful enough to emulate 3do with full LLE. I read an old post somewhere by altmer stating that the freedo core was about as optimized as it could be, hence the reason I started looking into HLE. Performance is the same with discs or isos.

I was thinking of doing exactly as you described, offloading some of the graphics processing to the xbox GPU while leaving all the rest as is. Would this be as simple as having a check in the _arm_execute_ loop checking for those graphics SWI's and responding to only those?

PS: I found quite a few games that never trigger a breakpoint when it's set to the swi handler lines in Arm::Execute in your old HLE code. Am I correct in assuming that those games don't use the 3do SDK and have custom code?

[Johnny]

I would need to understand a bit more about the "graphics folio" to help make sense of how much performance you could squeeze out of things by offloading things to a hardware graphics.

It would definitely be a shame if the hardware just can't handle it. I would think there's enough horsepower in there even without hardware acceleration. I'd be interested to hear what you find if you profile performance.

I haven't looked into commercial games and their use of SWI's (at least not for a while). I didn't come across any that weren't using SWI's. A breakpoint in the ARM execution is the right area to look into that. Are you using my HLE ARM code to determine the "type" of the instruction? If so, that would be reliable enough to investigate. I would just check the endian-ness of the instructions you're sending in.

[incrediclint]

I can get it to spit out higher FPS by overclocking the ARM core, but that only affects the ARM core, not the VDLP/DSP. It'll show higher FPS but the games/core don't actually run any faster. I saw that the ARM core was de-coupled from the rest of the system back when they implemented the multi-task mode so that would explain why.

I played around with some of the VDLP/DSP clocks in quarz.cpp and while it did speed it up, it caused many other problems. (missing sound, crashes, etc...)

I ran some basic profiling and it showed just as you'd expect... most time is spent in the arm execute loop followed by 3do_InternalFrame and XGSwizzleRect(DX function).

I should note too that I've gone through and disabled all my rendering code for the xbox so essentially the core is running and spitting out the data but I wasn't doing anything with that data. It had zero impact on performance FPS wise, which is odd because I would think it would be a massive improvement.

The only way I've gained speed was by removing/commenting out useless if/else lines in the core. There were quite a few that did nothing because it was commented out:

Code: Select all

if (isSomethingTrue)
{
  // SomeCommentedOutCode(blah,blah);
}

and sometimes an else left at the end of a block with the code for it commented out.

Commenting those out gained me another 3 FPS, which is great on the xbox. Every ounce counts there.

And yes, I'm using your HLE 4DO code. I haven't actually sent any commands in the HLE version yet. Just trying to extract the data needed to begin to implement some of the Item management code, the values i'm extracting don't make much sense though.

I'll keep plugging away at it. Slowly starting to understand more about coding at this level where everything isn't wrapped up in a nice tidy class/library.

[Johnny]

Ah, I should clarify that the HLE ARM core you're probably looking at (unless you've gone back in SVN history) is largely the same as the FreeDO core. After I'd gotten my 4DO ARM working (on non-OS games like the sonic sample you may know about), Altmer gave me his ARM emulation code in full to help me speed along as long as I gave him credit as a contributor to the project. I suppose he was uninterested in releasing any code until he knew I was serious. It was kind of a bittersweet gesture considering how long I spent on my own ARM core! This was before FreeDO was open source.

That core does catch SWI's correctly, so your findings are probably accurate.

I'm not able to spin back to full speed on 4DO development yet, but when I do I could look and may be able to give a sanity check for anything obvious to get more speed out of the core. Altmer's core was already very optimized (his ran 5 times as fast as mine), so plain optimization would be pretty difficult. I'm still hoping there's something obvious sapping the speed.

Here are some ideas...
* Hopefully you're building "release" and not "debug". Sorry for the remedial suggestion, but occasionally I build the wrong one in 4DO and confuse myself.
* Definitely use "multi-task" mode. I believe this merely means that the core will run until a real visual "frame" is done. This allows you to save time by reducing how often you read the frames. Otherwise you'll be reading it 60 times a second; the first 4DO versions were making this mistake. Sounds like you already disabled your frame processing, so this isn't relevant yet.
* If you're listening to any KPrint or FreeDO core debug printf messages, you could ignore them. KPrint is a SWI too, so you could even short circuit it early if you get tricky.
* Use the "new" FreeDO core as opposed to the HLE one you have. I don't know what version of FreeDO the HLE core ARM is from, but it was given to me maybe 3 years ago.

[incrediclint]

The multi-task mode seems to just remove the VDL line generation from the _3do_InternalFrame_.
in particular i've found this bit:

Code: Select all

if(_qrz_QueueVDL())
{
      line=_qrz_VDCurrLine();
      _clio_UpdateVCNT(line, _qrz_VDHalfFrame());

      //  When using multi-task, scipframe will be true, otherwise its false.
      // _vdl_DolineNew is executed  in FDP_DO_FRAME_MT 256 times to
      // generate the screen.
      // When not in multi-task mode a new line is generated each time
      // through this block.
      if(!scipframe)
         _vdl_DoLineNew(line,curr_frame);
      
      // I'm not sure of the significance of 16 here,  but in multi-task mode 
      // this is our chance to swap out another buffer in the main app, or 
      // a trigger that tells us a frame is done. So this gets called, and we pass
                            // in another frame buffer with FDP_DO_FRAME_MT and it gets filled
                            // completely.
      if(line==16 && scipframe) io_interface(EXT_FRAMETRIGGER_MT,NULL);
      
      // Start of a new frame/set of lines?
      if(line==_clio_v0line())
      {
         _clio_GenerateFiq(1<<0,0);
      }
      
      // If line == last line in frame.
      // When not in multi-task mode this is how we know a frame is done and why
      // EXT_SWAPFRAME is called.
      if(line==_clio_v1line())
      {
            _clio_GenerateFiq(1<<1,0);
            _madam_KeyPressed((unsigned char*)io_interface(EXT_GETP_PBUSDATA,NULL),(int)io_interface(EXT_GET_PBUSLEN,NULL));
            curr_frame->srcw=320;
            curr_frame->srch=240;
            if(!scipframe)curr_frame=(VDLFrame*)io_interface(EXT_SWAPFRAME,curr_frame);
      }

}


On the xbox, there is no gain in performance from multi-task mode. If I'm understanding the code above correctly, multi-task mode just means that the entire frame buffer will be generated each time _qrz_QueueVDL() returns true, and in non-multitask mode only a single line is generated each time _qrz_QueueVDL() returns true.

So basically it boils down to generating a single line each time through, or all of them.

Am I understanding this right?

I've already commented out all the debug printf stuff and most of the Kprint stuff too. I am using the new 4DO code for the xbox port, but messing with the old 4DO code for PC HLE. (Get that working then port it to xbox.)

I'm not too concerned about the speed of the HLE code, moreso in trying to extract the data needed to load games' resources and get them to render in directx. So far it's proved to be a royal PITA.

[Johnny]

I'm not too concerned about the speed of the HLE code, moreso in trying to extract the data needed to load games' resources and get them to render in directx. So far it's proved to be a royal PITA.

I'll bet it is! Some good news is that it may be more doable than I originally thought...

The FreeDO core we're looking at has a capability render to something other than 320x200. In their code it's something like TEXTURE_SCALE or RESSCALE (it's also a setting in the FreeDO interface function).

Come to think of it, make sure you currently have TEXTURE_SCALE set to 0 (setting it to 1 results in double the resolution because of a bit shift of 1). I remember 4DO was running slowly until I realized the FreeDO core was attempting double resolution. I have not reintroduced this feature as an option, either. I suppose I'm a bit scared of the performance feedback I'd get after all that work.

So, the FreeDO code, even though it's all LLE, somehow knows the geometry you'd need. I don't fully understand why. But, I would expect that if you need hardware acceleration that's the best place to start looking.