RSS feed

Nathan's Journal

Created by nkeynes on Sat 06 of Mar., 2010 18:52 PST
Last post Mon 08 of Mar., 2010 20:33 PST
(1 Posts | 1109157 Visits | Activity=2.00)

Tags: lxdream

Implemented the event queue yesterday (and it worked first time too, to my utter amazement). The PVR line events are using it now and are tested to give the right times, at least down to the microsecond. Other stuff to be added to it as I get around to finding the correct timings for them. Also incidentally discovered that I had the 2 scanline events hooked up back-to-front - no wonder they were confusing me...

Wed 03 of Jan., 2007 16:42 PST

Christmas break

Tags: lxdream

In the end I didn't get much time to do a lot of coding over christmas, but I have gotten a few little tweaks in, along with more unit tests:

  • Fix IDE PIO read size (it always returns sector-at-a-time)
  • Fix TMU counters to be accurate to within 1 SH4 instruction when read/written (events are still coarse-grained).
  • Fix crash on receipt of a bad maple packet.
  • Implement real video timing using the CRTC registers, along with the SYNCSTAT (A05F810C) register, at least for PAL. Still need to verify NTSC and test other display modes. Interestingly it looks like it's using a 27.038Mhz dot clock for both PAL and NTSC.

The above has gotten me to the title screen on one game I tested, but it hangs there unfortunately. It's also made me acutely aware of the immediate need to have finer-grained timings on at least the display events - plan is to implement sh4-relative one-shot event timers next, and then test/implement the other display modes.

Things are looking promising though - I'm aiming for an end-of-January/early-February M2 release, which should be at the point where other people can start playing with it.

Updated: Said game is trying to use the YUV converter to play video, which means it's hanging because of something not implemented (yet), rather than because something's broken. Just for a change biggrin
Sun 17 of Dec., 2006 22:20 PST

Mostly IDE this week

Tags: lxdream

Native linux CD driver is now partially implemented at long last, along with a first cut of the NOP command and the "read status" packet[0] (0x40,0x01). Unfortunately it looks like there's a good bit to be done still in ATAPI-land for normal usage, so I will probably have to keep banging on it for a while. Putting together a test disc at the moment for use in the IDE system tests, which should help as well.

On the bright side, with a couple of exceptions[1] I can now boot every demo/homebrew disc I've tried, so I will start making with the compatibility lists soon.

[0] For want of a better name. It doesn't seem to directly correspond to anything in INF-8020 as far as I can see.
[1] gg_3dEngine.nrg doesn't work for me currently. Then again, I burnt three coasters in a failed attempt to write it to disc, so my copy of the image may be corrupt.

Tue 12 of Dec., 2006 01:52 PST

I aten't dead

Although I'm not entirely sure where the last 3 months have gone, as they certainly don't seem to have been particularly productive in any way.

Hong Kong was good (got back last Wednesday), albeit very busy, and my feet are still recovering from all the shopping[0] neutral - HKG may just be the most commercialized city on the planet. Some highlights did include Victoria Peak (external link) and Ngong Ping (external link), both very nice areas (even with the tourist developments).

So... on to some DC stuff. Started doing some serious profiling today, in the interests of maybe getting performance to be less utterly terrible. Fixed a couple of lesser bottlenecks (the _big_ bottleneck being the main sh4_execute_instruction() function) and actually managed to nearly double my framerate. Combined with quartering the SH4 speed and it's nearly usable now (although still less than half speed I would guess). Nice... I doubt I'm going to eke more more speed out of it until the recompiler is done though.

For the interested - when I started profiling, the SH4 core (including memory address decoding) was consuming roughly 98% of the total runtime, of which sh4_execute_instruction() alone is ~50%. It's now down to ~96%, with execute instruction taking 73% by itself.

[0] We seemed to spend an awful lot of time in Mong Kok (external link) for some reason.

Thu 21 of Sep., 2006 21:04 PDT

Generic update

The move is mostly done now, other than a dozen or so boxes still to be unpacked (mostly miscellaneous crud), and I'm slowly getting used to the earlier start (darn commute). On the bright side, I've been able to use the half-hour or so each way to write some more test cases...

Started working through the CPU core tests, which, at a current rate of about 0.6/day I should be finished sometime next year. Hopefully it'll get faster though now that I've got some more infrastructure in place (and most of them can be made more-or-less data driven). Unfortunately there's still over 100 instructions to get through, without even counting all the variants.

The main driver for doing these now is actually so I have a ready-made test set for the recompiler, although it tests the emu quite nicely too. I've already picked up one unimplemented instruction that I'd completely forgotten about (ADDV - add w/ overflow check) which apparently noone has ever used...[0]

[0] The core has a "halt and catch fire" routine built in for any unimplemented instructions, which tends to make them hard to miss. Admittedly it's no real surprise that noone has used it though - most programming languages don't have any constructs that would compile down to it, and I honestly can't think of any real reason you'd want to use it in practice except in constructs like

        addv r1, r2
        bf normal
        mov.l exception_handler_k, r3
        jsr @r3

(In other words, converting the check into an exception of some kind)
Tue 12 of Sep., 2006 18:17 PDT

Goals for Milestone 2

Tags: lxdream

Originally I had M2 specced for August - obviously that didn't happen (in fact M1 barely made the end of June) and the this month has been rather busy with personal stuff (ie moving house). On the bright side lxdream has made some pretty big strides in its PVR2 support, but not much else has been changed significantly yet; I don't think there's enough to warrant a new release at present.

So... I'm aiming for an M2 at end of October at present, with the overall goal of getting some arbitrary game to come up and be at least somewhat playable. I've tagged the following bugs (on top of what's already done since M1) for M2 as well:

  • Preliminary SH4 dynamic translation/recompilation (Bug #bug:14?)
  • Get the AICA command port hooked up (Bug #bug:15?)
  • Implement the audio IDE commands (Bug #bug:17?)
  • Implement native CD driver (Bug #bug:19?)

If there's any time left in the month, probably knock over some more rendering issues as well.
Tue 12 of Sep., 2006 05:32 PDT

Fresh screenshots

Tags: lxdream

Well, will wonders never cease - I've now got some _very_ quick and dirty transparent sorting code in CVS now. It doesn't support intersecting triangles, or loops, or even some straight overlap cases[0], but it _does_ do everything the BIOS screens need. As you can see from the screen shots to the right - these look pretty close to exact now.

For the sake of comparison - this is what the date screen used to look like:

Updated: VQ decompression works too now. ("I wonder how long this will actually take." "Actually, not that long"). The CD in the image on the right is the VQ texture. Note that this screen currently has some visual artifacts that aren't obvious in the screenshot.

[0] For now it's just sorting based on the minimum Z in each triangle. Hey, I _said_ it was quick and dirty. A more precise version is to follow in the future.


Main menu


Thu 07 of Sep., 2006 21:06 PDT

Backplane upgrade working

Tags: lxdream

Been busy packing of late (what with moving next weekend and all), so I haven't had the chance to make a huge amount of progress. I _do_ finally have solid colour backplanes working correctly though, which is nice (screenshots to follow at some point in the future). The code deserves some kind of award for being the most complex component in the system in proportion to the hardware function it's implementing. Still wondering if maybe I should have gone with the software renderer option after all... In any case, the clock etc bios screens do look nicer with the proper background gradients on them.

I've also discovered that the PVR really doesn't like trying to do alpha blending in the opaque polygon list. Of course, some would say that that's the _point_ of having separate opaque and translucent lists, but it would have been nice if it failed in a clean, easily implementable way, rather than by going through some relatively complex display screwups[0]... Bug compatibility, natch. Also, dest blending modes[1] 4-7 don't seem to match up too well with Maiwe's list, unless they're intended to mean something other than what GL expects them to mean.

[0] By the looks of it it's not clearing out the tile before drawing over the top of it, which isn't terribly surprising, except that it's from 2-3 tiles back rather than the last tile.
[1] I haven't gone through all the src blend modes yet, but I'm guessing that similar caveats may apply.

Wed 30 of Aug., 2006 16:29 PDT

That's annoying...

Tags: lxdream

Apparently my math for the background was correct, but my GL-fu is not strong enough. To be correct, it needs to render with vertex colour clamping disabled (and only clamp at the last minute before writing to the colour buffers), for which there is a convenient extension method glClampColorARB (defined by the ARB_color_buffer_float extension). At least, it would be convenient if Mesa (external link) actually implemented it. Which, apparently, it doesn't. *sigh*

This seems to leave me with the options of a) rendering the backplane in software and uploading it as a texture (which could get complex real first once all options (texturing, etc) are supported), and b) computing all the clamp lines in the viewport and rendering a separate polygon for each clamped segment. Neither of which is particularly elegant. I suppose there's also the question of whether I'm eventually going to (have to?) do a pure software renderer or not.

Updated: Ah poo. Apparently I've misunderstood the purpose of the glClampColorARB call[0]. As it turns out, Nvidia (external link)'s driver + libraries do include it, but it appears to have no effect in this context.

[0] Yes, I'm willing to assume that Nvidia engineers probably have a better understanding of the extension "spec" than I do. smile

Sun 20 of Aug., 2006 00:33 PDT

some progress...

Tags: lxdream

Render test case is kinda working now, at least for purposes of actually rendering stuff; assertions to follow. when I decide how I'm going to do them... I'd _like_ to dump the full image to file and compare, but sadly I've got little chance of it matching up perfectly as long unless/until I write a software renderer. Something that I don't really want to do right this moment. Testing individual points of interest might be doable though.

Incidentally, it seems the pvr doesn't like drawing the backplane behind the far z-clip. Which makes sense I suppose. The backplane is kinda interesting inasmuch as it takes an arbitrary 3 points and extrapolates those out to fill the full viewport.

Fast Prev Prev PagePage: 2/32 Next Page Fast Next Last Page
1 2 3 4 6 32

About me

Nathan is a full-time software engineer and part-time maintainer of several pieces of open-source software that noone has even heard of (most notably lxdream and elr). His interests include programming language design, distributed systems, emulation, Japanese, and go.