The Making of Project UnReality
Project UnReality is one of the first next generation emulators, second to
PSEmu, that emulate the newer and currently popular gaming systems. Project
UnReality is an incredible project that has been documented daily by its
author, Micheal Tedder, alias bpoint. The following 'article' is a collection
of daily press releases, many of which have long been removed from Project
UnReality's homepage. What's the point? History, preservation, and perhaps
Well, got a couple more COP1 opcodes working before bed. There's a
new N-logo in the left frame over there thanks to Jeff Skalski... and
I added a Links page to a few popular sites I visit. Enjoy!
Hmm.. I sure botched the upload to the new server didn't I? :) Oh
well, for those of you who saw the really weird stuff for about 15
minutes, I apologize. Everything should be okay now...
Well, if you're seeing this, then you obviously know about the site
move. :) I need to thank Datawiz / BlackBag for allowing me to make
the once-mirror the now-official site of Project UnReality. This
should speedup transfer times to everyone as my lowly cable modem
doesn't compare to his T3. Please change your bookmarks to point to
http://projunreality.blackbag.org. My page at ml.org will still serve
as a forwarding notice, but I won't keep it up forever. :) My email
address is still the same, so there is no change there.
Lots of stuff was done tonight too. A few important opcodes are
working (mainly LDC1 and SDC1 now that the COP1 overhaul was
completed), and more COP1 opcodes were implemented (mostly *.D
opcodes). COD/MAP file support is finished, so symbols are now
visible in the debugger instead of addresses.
Brian and I are now working out of the same source tree. We're using
RCS to handle working with the multiple files to avoid constant file
exchanges and merges during IRC sessions. This will speed our
development time drastically as well...
Brian hacked out quite a few more RSP opcodes and even setup for RDP
preperation. Still nothing really cool happening yet :( , but we're
continuing to do more opcodes... eventually something will happen. :)
Again, a big thanks to Datawiz for allowing me to move to his server.
Time to go coding... :)
Wheee! More opcodes done, COP1 overhaul almost done, crash problems
(in certain ROMs [ie: GoldenEye]) fixed (Project UnReality wasn't
executing code out of ROM space...), and COD/MAP file support just
What more could be done in the past 2 days? :)
Again, I forgot to mention something. :) LaC's MOD player performed
excellent on the P2-266 at work. The realtime emulated mixing of the
audio was near-perfect, with very few discernable clicks between
sample buffers! On the bad side, almost the entire CPU time was spent
doing audio processing rather than video, so the frame rate was
*really* horrible. I guess I'll have to add an audio disable
BTW, LaC's audio mixing is done in software using a separate thread.
He does not use the RSP at all, which I'm quite positive all
commercial games use. The RSP's audio mixing task does not need to be
emulated through opcodes, but rather can be done through native Intel
code (hence, DeltaPlayer). So RSP sound emulation will be *much*
faster than emulated mixing.
The FAQ is online. Check it out here, or in the bar on the left.
Oh yeah, I forgot to mention that many of the existing audio problems
are now gone with DeltaPlayer's integration. There is nearly a 50%
speedup in audio emulation now... the latest test of LaC's MOD player
runs at an "acceptable" speed on my P166. The audio is discernable,
but it is somewhat choppy. I'll test this on my P2-266 at work today
and see how well it works...
Hmm... last night was not very fun. I guess I caught something since
I didn't feel too good. I spent most of the night sleeping... mmm..
plenty of rest for the weekend ahead. :)
I did start work on a FAQ, however, as I'm starting to see the same
questions come through about 3 or 4 times a day. So, to save your
time and mine :), I decided it's time to get one done.
I should have it finished sometime this evening, so you're welcome to
come back then and check it out. :)
Yahoo!!! (No, not the site.. :) )
Today, the RSP officially executed it's boot code! So what does this
mean? It means there's enough going on in the RSP to start looking at
what else is happening emulation-wise. We already saw the RSP attempt
to start it's first task (a graphics task, at that)!
Apparently I need to get more opcodes done before we'll see some
action, but we're definately making headway. Stay tuned for more
news! Back to coding!
Not too much new today... I patched up the remaining sound bugs; it
appears to be pretty clean now (with a few exceptions :) ). I was
able to get in some opcode work this evening, starting with the COP1
changeover. It's not too big of a deal, but I have to re-code every
*.D opcode (ie: CVT.D.W, ADD.D, SQRT.D, etc) and test it, which just
takes time. Yes, I actually *TEST* every opcode I implement to make
sure it's working correctly. I don't hammer out every opcode and try
to hunt down why something doesn't work later. In the long run, I
think it saves time. :)
Brian did a few more (4 or 5?) RSP opcodes today... more to come in
the next couple of days of course.
Good news today! Brian and I just spent the last 4 hours working on
the RSP. We've got a fairly small core working, even though it
doesn't emulate any opcodes yet. :) There appear to be a few things
we still need to iron out, but once we get the RSP generating
interrupts like a real N64 does, alot, and I mean *alot* of stuff will
start to work... however, only stuff that uses the standard 'putpixel'
type of drawing will actually show stuff. Remember WaveRace64? The N
logo appeared on it... I'm wondering what else uses the 2D buffer in
WaveRace... hmmm.... :)
There's still many many more bugs to fix... I've got a huge list
that's a few pages long. I'll probably be tackling these bugs while I
wait for Brian to wake up tomorrow. :)
Again, a thanks to everyone who is visiting our sponsors!
Aaaah! Finally! I've been trying to get the audio emulation working
to a good point, and I found out that I left DeltaPlayer in a
semi-broken state where static and streaming buffers don't support
stereo. It took me a good portion of today and yesterday to figure
out how to get them to be in stereo...
It may sound easy to just add stereo support, but streams and buffers
have to be masked as individual samples which are remixed back into
the output. Normal stereo data is usually interleaved (LRLRLRLR), and
a sample has to be a single channel only, so two channels must be
created, one at the left, another at the right, each with their own
sample data. Beh, not fun, but it's done now. Yay!
More updates to come later... Brian and I are about to tackle the RSP
stuff very soon... :)
Oops! I've been forgetting to update the BlackBag mirror. :) Sorry
'bout that. It's all fixed now.
Not too much new, so I figured I'd do an update before I become 3 days
The DeltaPlayer integration is done, all I need to do now is actually
emulate the N64 audio using static buffers. I should write a new
audio interrupt handler to disallow reentrancy and fix any potential
I also started on a COD/MAP file parser. The debug info isn't
actually loaded yet, but it's close. Ah well, tomorrow's Friday...
I'll have lotsa time to do stuff over the weekend. :)
Hmm... cable modem service has been down for over an hour and a half
now and it looks like there's no hope of it being back online soon
(I've been on hold for about 50 minutes now), so... I figured I could
do an update. :)
Put simply, the entire audio emulation core of Project UnReality has
been completely revamped. I have implemented my own tracked music /
MPEG audio player (called DeltaPlayer) in Project UnReality as it
already supports handling between devices which support hardware
acceleration (wavetable), and ones that don't. It also supports older
style soundcards (ie: SB Pro v2 [heh.. tc1 :) ]) and can
downsample/upsample to any sample rate. DeltaPlayer supports advanced
resampling features such as high quality mixing and interpolation (and
soon, even realtime effects like echo, reverb, etc.). This can be
used to actually make the audio sound *better* on Project UnReality
than on an original N64.
Aside from being very fast, DeltaPlayer also dynamically mixes up to
256 channels, which is perfect for RSP audio emulation. What's RSP
audio emulation, you ask? It's what's used when you fire up Mario64
and hear "It's 'a me, Mario!". All we need to do now is figure out
the RSP commands for processing audio mixing, and DeltaPlayer will
handle the rest.
As an added bonus, I have kept the replayer module inside Project
UnReality, so you can listen to your fave MOD, S3M, XM, or MPEG audio
(ie: MP1, MP2, or MP3) while listening to sounds being emulated. This
is toggleable, of course, and may be enabled or disabled at will. I
bet you never thought an emulator would have a module player built in
it, eh? :)
All crashing and hanging bugs appear to be taken care of. I'm not
seeing any more problems with DirectDraw in fullscreen mode now, so
I'm fairly sure everything's fixed. Brian is off investigating more
of the internals of the RSP, and will be for some time. I'm currently
looking into the COD/MAP file loading for debugger stuffs, which will
help us track down the Pong paddle problem. I expect to join Brian on
the RSP hacking this weekend, so perhaps we will have a very basic RSP
emulator going in a week or so.
Finally, a big thanks to everyone supporting us! Continue to visit
our sponsors and continue we'll bring you more neat things. :)
Oh, by the way, if you are curious about DeltaPlayer's comparison to
other module players (ie: MOD4WIN, Cubic Player, etc.) click here to
find out more.
Yowza! In an interesting twist of coding, the very BASICS of the RSP
have begun. (Note I stress the word basics...)
This form of emulation just makes the RSP appear to the R4300i that it
is indeed there, much like SPC700 emulation began for the SNES. So
far, the Shag'a'delic demo is now working perfectly, as shown in the
I have fixed all crashing/hanging bugs in the emulator, so the next
release should work alot better for all of you. :) There is still a
minor problem with the fullscreen stuff, but rest assured, it will be
fixed before 0.3b is released. I am continuing on with the debugger
stuff while Brian is looking more into the RSP emulation and his
Kanned Goods also did an interview (and they are a mirror as of today)
with me. You can access that here.
I want to thank everyone for their continued support! Please visit
our sponsors and we'll continue to deliver the cutting-edge of
emulation! (Just wait till you see what else is coming in the next
version... *cackles evily* :))
Okay, it looks like the Pong problems have settled. It seems that the
culprit for most of you was 256k of L2 cache (as opposed to 512k),
while others had been running in 16.7 million colors. So I'm glad to
know I don't have some crazy bug that's slowing some systems down for
no reason at all. :)
On the good news side, Brian and I have hacked out the VI_CURRENT_REG
which (in a weird sort of way) handles horizontal retrace. Absolute
Crap 1 and 2 are now functional, and here's a screenshot of Absolute
Crap 2 running on the latest build...
Unfortunately, it is rather slow, and it's not going to be easy to
speed up. The demo idlewaits nearly 90% of the time in a loop that
polls the VI_CURRENT_REG continuously. I'm sure we can come up with
some kind of idlewait detection for this demo, but we're not too
concerned about it yet.
Apparently there's still a little bit of confusion on the slow frame
rate problem. Specifically, I am only interested in Pong, not any
other demo. I also only want to know the frame rate when the game is
actually playing (ie, there are two paddles and there is a white ball
somewhere on the screen). The title screen averages about 3fps on my
P166, so I'm not concerned about that specifically.
Now that you know what I'm looking for, go ahead and email me based on
the criteria from yesterday's news...
It looks like everything's back to normal. Email services are back
up, so if you emailed me before and you got a bounceback, go ahead and
send it again. Once I brought the server back online, quite a few
emails flowed in... :)
I received some information from people who have been looking into the
slow frame rate problem with Pong. If you're one of these having this
problem, check the following things:
Thanks goes to Maxon (the author of Pex, a PlayStation emulator) for
supplying the info about the L2 cache. I have confirmed that this is
indeed quite possible... I removed the L2 cache module from a P200MMX
and Pong's frame rate dropped from about 40fps (with the cache module)
to nearly 6fps.
- You are not using a Pentium Pro. PPros do not handle 16-bit code
very well at all. The entire colorspace conversion code to go
from the N64's frame buffer to a Windows frame buffer is in
- You are running in a 16-bit video mode (that's 65536 colors).
Any other bit depth will require Windows to do extra colorspace
conversion, thereby slowing frame blits down. Suggestion: Use
full screen mode [but very carefully, as there are a few bugs in
it :) ].
- You have 512k of L2 cache, and it is set to write-back, not
write-through. Many name brand systems (Dell, Gateway, Compaq,
HP, etc) do not ship with L2 cache to cut costs. If it does have
L2 cache, it might be set to write-through.
If the L2 cache is the problem, you're out of luck. I won't be able
to help you with that one.
If you've checked all of the above points and you're absolutely sure
that they're all fine and you still have a slow frame rate, email me
your system type (exact CPU, motherboard, video card, everything)
including model numbers [ie: an Asus Triton 430FX TP55/4N is what I
want to know].
Finally, I'm back online!
To make a really long story short, I was trying to get my CD-RW
working again, regardless of the consequences, back on Sunday. I
somewhat succeeded, but I ended up wiping out my C drive in the
process. (Nothing to fret over, all my important stuff was on my D
After realizing what would be required to bring my system back online,
I decided it was an opportune time for a system upgrade. Yes, thanks
to ALL of you who have supported us, I purchased a brand new Quantum
Fireball 6.2Gb Ultra SCSI, and have replaced my rather slow IDE drives
with it. As of today, I am officially IDE-less. :)
My system is magnitudes faster than before, so this drive will not
only allow me to have more space but I will be able to have faster
compiles (which means less time required to test stuff, which means I
get more done in the long run). Everything seems to be working well,
and I don't think there will be any more problems in the near future.
Email services are still down, however... I haven't yet reinstalled
the SMTP/POP3 server. Gimmie another day, and they'll be back online.
So what happened in the past 4 days? Well, Brian has been looking
into the Pong paddle problem, and found a pretty major bug relating to
interrupts. The interrupt flag specific to that interrupt wasn't
being cleared once the interrupt was done. So on every vertical
retrace, a serial interrupt was being done, a timer interrupt was
being done, etc, etc. This could lead to some bad things, but we
haven't finalized what's exactly wrong with Pong, so this could be
We've also been looking at sprite stuff (more 2D video-related
things), and we've already come upon the evil display list. :) We
are still deciding the best way to emulate the list...
That's all for today, it's time for bed. Once again, I'd like to
thank EVERYONE who has supported us. Without all of you, I wouldn't
have this nice fast drive in my system. :)
(BTW: Lots of the infamous crashing bugs in 0.3a have been fixed.
You might want to keep your eye out for 0.3b to arrive soon...)
Wheeee! I highly hosed my box trying to get my Philips OMNIwriter
working again. I'm forced to do this update remotely... and I suppose
by all of you seeing this, you were smart enough to go to the mirror.
It might take me about 3 days before my box is back in working
The Compatibility Page is finished, have fun. The Status page has
also been updated.
My official "break" is in effect as of now; it will last for a few
days (probably till Friday or Saturday of next week [ie: the 5th or
6th]). So don't panic if you don't see any updates for a while.
Final thanks to all Dextrose members for allowing me to link directly
to their demos archive on the Compatibility Page, and for hosting
POM'98. May the future of N64 demo coding live on! :)
February 27 [ release today at 9-10pm PST ]
I just got back from a fun day out with relatives who were in town, so
the Compatibility Page is on it's way.
I've received quite a few emails about systems that run Pong (and many
other things) are really SLOW framerates on higher speed systems like
a P200MMX. I haven't the foggiest idea as to why this might be
happening, as many other emails praise the incredible speed in Pong.
I looked through the frame sync code and there is a potential bug
which will halve the 30fps framerate lock (at most). My suggestion to
those of you having the slowdown is to disable the 30fps lock
(Options->Video Settings), and see what happens.
The only other thing I can think of is that your video card is not
cabable of colorspace conversion and Windows is doing it through
software. Project UnReality creates a frame buffer dependant on the
ROM you're using, so a 15-bit display mode (which uses 5:5:5 for RGB)
would be optimial as there is no colorspace conversion necessary.
Well, I still haven't finished the Compatibility Page. It sure takes
a long time to get snapshots of everything that works. :) For now,
head to http://www.dextrose.com and look under 'Demos'. Lots of stuff
there works, even stuff with sound. Go have a blast.
I'll have the compatibility page up sometime today... just be
February 25 [ 2 days till release date ]
Well, today's the day. I have to be honest and say that there are still a few minor bugs and other
unimplemented things I'd like to see fixed before the release, but hey, I can't have everything. :) Version
0.3a will be released somewhere between 9 and 10pm Pacific Standard Time this evening. Adjust
accordingly for your timezone.
Among the list of things that don't work or are currently not implemented are:
- Pong is *somewhat* controllable. There's a deep hidden bug somewhere in the emulator core that
is only allowing the paddle to move up and not down.
- Analog stick emulation is only available through the mouse right now. I couldn't get either one of my
two joysticks to work under NT. :(
- Fullscreen mode is working VERY well, but there's no way to exit it. The only current method is to hit
Alt-F4 and exit Project UnReality.
- Audio still doesn't use DirectSound, so certain ROMs that try to play audio may not work on some
I'm setting the release time to around 9pm to allow me to clean up as many of these bugs as possible. I
don't think I'll be able to nail them all down, so version 0.3b is likely to follow within a week or two which will
fix all of the above problems.
Project UnReality v0.3a will be available from a number of places. You can track my bot down on IRC (in
#emu) on Efnet named 'bpt-dcc', or something of the sort. Alternatively, you can download it directly from
the BlackBag mirror. I will update the Download page as soon as it is available. The compatibility test
page will probably be updated around 7 or 8pm, depending on how long it takes thecrazy1 to do his new
At any rate, I hope everyone will enjoy the new version as there's lots to look forward to. Thanks to
everyone for their supportive emails -- you've definitely helped motivate me to continue the project.
February 24 [ 3 days till release date ]
Lots of progress this evening. Many of the bad bugs have been
fixed... there don't seem to be any more crashes during loading of a
new ROM or resetting. FPS locking is in place which bolts the blitter
to a maximum of 30 FPS. This is optional of course, and the FPS
counter has been put back in. I'm showing speeds of 50fps on my P166
for Pong without the FPS lock, so I guess it runs faster than I
I started to work on the fullscreen code, but it doesn't seem to be
doing anything right. :/ The bug seemed simple in 0.2a, but now it
looks completely wrong. There's also no easy way to get Project
UnReality _out_ of fullscreen mode either. I'm not sure what I'm
doing wrong here, so I'm going to play with it more some other time.
First thing on the list to do tomorrow is (finally) analog stick
emulation. I'll also have to find my analog joystick and hope it
works under NT.
In other news, the NT problems appear to be gone... I've tracked the
bluescreens down to my Philips OMNIwriter. I don't know what's wrong
with it other than when it's not powered up, I don't get bluescreens.
Eeeeek. 2 days left. Boy, it's going to be close. :) Thanks to all
of you who continue to support us!
February 23 [ 4 days till release date ]
Return of system problems? Who knows... all I know is NT has
bluescreened on me nearly 10 times tonight. Nothing major, just a
pain in the arse to have to reboot. I hope it's still running when I
wake up... :)
Aside from the bluescreens this evening, I did manage to get the sync
thread code nearly done, and the blitter is now integrated back in the
CFB update code where it belongs (rather than a different thread).
Things are still a little broken, so I can't get a clean compile just
I'm sure I'll see more of these problems... but hopefully it's not
anything serious and they'll just go away. :)
February 21 [ 6 days till release date ]
A couple of site-related changes were done today to prepare for the
release in a couple of days. First of all, I have removed my site as
an offical page to receive the latest versions (as well as demos and
stuff) from. My bandwidth can't support the number of people
accessing this page AND handle transfers of the most recent stuffs.
The primary site is now on BlackBag's server (at
I've also received LOTS of emails from people who download version 0.1
and expect the Firedemo (as well as other things, but I won't get into
that right now) to work. I am no longer keeping an archive of past
versions on the server. If you want them, you'll have to find them,
but I won't take time to support them.
Also added is a 'Legal Issues' page to inform everyone about what is
legal and what isn't... as this question usually pops up quite a bit
before the release date. Finally, I added the Greets/Thanks page...
Tonight will be spent synchronizing the blitter code to the N64's
emulated vertical retrace. This will remove the shearing problem
that's apparent on systems that run Pong too fast. I'm also going to
add code (as an option, of course) to lock the emulation and blitter
down to the maximum rate on the N64, thereby allowing the faster
systems to max out the frame rate without it being uncontrollable. :)
I've also heard from one of my beta testers that Pong is running at
near full speed on his P100. And they said it couldn't be done.
Just a quick update...
This weekend was spent optimizing (well, not optimizing, but rather
overhauling) the interrupt system. A binary heap is used to process
interrupts, and checking the heap for an event is very fast. This
alone saves nearly 25-30 cycles (not including possibly uncached
memory accesses) per emulated opcode. But this isn't the best part...
Since the N64 is multitasking, checks have been added to see if the OS
is in an idle state. If it is, it immediately services the next event
(such as a Vertical Retrace interrupt, controller interrupt, audio
interrupt, whatever...), completely eliminating any idle time to have
the emulator "do nothing". Brian and I have spent the entire weekend
working on this and I think you'll be pleased with the result:
Pong now runs at full speed on my lowly P166. :)
It's actually too fast at times, but resizing the window to 640x480
makes it much smoother. I didn't think I'd have to add code to SLOW
DOWN my emulator any time soon. :)
This method will eliminate any idle time from any demo or game and
should speed up emulation a bit. The only places where it won't be
useful at all is if the N64 is spent performing other tasks and not
idling at all. In this case, performance will be soley based upon the
speed of the emulation core.
That's all for today folks... I'm going to have to figure out how to
slow things down... anything faster than a P200 will probably have a
difficult time playing Pong. If anyone has any suggestions they'd
like to offer, I'd like to hear them. Thanks!
YES! The very first commercial game works (well, partially) on
Project UnReality! WaveRace64 shows the beginning N logo before
bombing out with an unhandled opcode. I have captured a shot of it
for all of you to grovel over. :)
I'm currently trying to get fullscreen mode to work well. My display
driver doesn't support 320x240 @ 16bpp, so I'm adding code to init
640x480 @ 16bpp and just upscale it. This hopefully won't take too
I'm also talking with Legerdemain on IRC right now and we're
discussing optimizations. Stay tuned for more news!
Apologies for downing the server this morning. I had tried to do some
remote administration and I goofed up. :)
A while ago, I asked your opinion about the banner located in the
bottom frame. While I still dislike the distraction of a banner from
a page, many of you said that you support my project and you would
continue to visit my sponsors if I added more. Hence, I have added
another banner (located above :) ) per your requests. I'm not allowed
to tell you to visit them, so only go there if you are interested in
the product. I won't be posting any other messages about this... If
you think the banner distracts from the page, or if you'd like to
voice an opinion anyway, I'm still open to suggestions. Feel free to
email me at: email@example.com.
Anyway, enough of that, on to news about the emulator...
As most of you know, February 27th is the official release date for
version 0.3a. Some of you are curious as to what's going on if all
the stuff on the Status page is marked as done. Currently, I'm
working on the following things:
- A new frame buffer dumping method. Currently, Project UnReality
copies a new frame to the window upon vertical retrace. This
isn't exactly accurate as data can change inbetween retrace,
causing stuff that should be updated to not be seen. The
vertical retrace interrupt is bumped up by a factor of five
(which is basically 300hz/sec rather than 60hz/sec on a real
- New DirectSound interface to audio emulation. It turns out not
all implementations of sound drivers for waveOut calls support
variable playback rates. Many systems only support 11khz, 22khz,
or 44khz, and calls to prepare a header with a sample rate of
say, 36021hz will fail. I can work around this problem using
- Analog stick emulation. This won't take me very long... perhaps
a half-day this coming weekend. I won't release 0.3a until
people can play Pong! :)
- Other optimizations. Since the N64 uses a multitasking OS, many
functions "block" the current process and execute other processes
until the original blocked process gets its requested data.
Strangely enough, most of the time is spent in an idle process
simply doing nothing (a jump to the same PC). Emulation can be
vastly sped up by simply detecting the idle process and
immediately processing the next requested interrupt. I'm not
sure how this will affect timing issues, but it might work out
Well, that's about it. If time permits, I will look into some of the
basic registers associated with the COP2 (RCP). I don't know what to
expect just yet, but I might be able to get a few more things working
(such as the Shag-a-delic demo and possibly even MAME64).
Only time will tell. :) Thanks to everyone for their continued
Well now, this isn't something you see every day. :) As most of you
probably know already (from N64.com, more than likely), MAME has been
ported to the N64. Titled 'MAME64', the game selection screen
conveniently runs on Project UnReality, as shown below:
An emulator running an emulator. What will happen next? :)
At any rate, none of the games appear to run... I only tested 5 of
them and just got a black screen. I've been told that MAME64 uses 2D
sprites (which are not emulated yet) to draw the graphics. MAME64 is
also one of the first titles to use high resolution (640x480) mode.
However, on a real N64, MAME takes the entire screen... more stuff to
figure out, I guess.
As for the audio testing on my P2-266 at work, I wasn't very happy.
The audio is still very choppy, so I'm tossing off the possibility of
real audio emulation until the dynamic recompilation is working. The
calls to play audio will still stay in place as there is no
performance penalty (ok, very very small, but negligible) to adding
I have also set an official release date for 0.3a of Project
UnReality. February 27th is the big day, mark it down. :) I have
also updated the status page as a result of this. Get ready to play
Thanks to all of you who continue to support us! You won't be
The basics of audio emulation have just been finished. LaCMod works
on Project UnReality, but my lowly P166 is not capable of emulating
channel mixing in realtime. Playback is a constant on/off... a buffer
gets mixed, plays correctly, but finishes before the next buffer has
been mixed. There is less time spent in the off state than playing,
too, which is a good thing. I think the ratio of time on to off is
I'll try the audio emulation on my P2-266 at work... I think it will
be able to handle it quite well.
I've been lazy on getting the analog stick emulated, so I'll pick that
back up once I get a major bug taken care of. For a reason
not-yet-known, people running both Win95 and Win98 have Project
UnReality freeze in the controller configuration. With NT, this
problem does not exist. I'm looking into this right now...
[-NiRV-] has done some betatesting and has captured screenshots of
numerous demos running on the latest build. Check his page out at
Lots of new stuff today. Emulation of the D-Pad and controller
buttons has been completed. A couple of demos progress farther now
that buttons (ie: Start/A/etc) are emulated. Response time is fairly
decent (taken: usable) on my P166. The analog stick is not emulated
yet as I decided to take a break from all the joystick stuff and work
on the basics of audio emulation.
Yes, you heard right, audio emulation. I was hoping I could post news
today and say that it was already working, but unfortunately,
something strange is happening in LaCMod and I'm getting weird sample
rates (like 1104 Hz?!) when previous runs were reporting 44100 Hz.
I'm too tired to track it down now, but I'm sure it's probably
something simple (most bugs are).
That's all for now folks, come back and see what's new later. :)
Emulation on the controllers is progressing quite well. I was able to
completely design the user interface for customizing all 4 controllers
and begin the basic emulation code for them as well. I would have all
the buttons and the D-Pad emulated now, but it turns out the PIF is
supposed to continually update it's RAM area with new controller data
rather than sending out a poll command and waiting for the data to
Controller emulation currently supports the keyboard and the mouse,
but no joysticks (yet). I'll need to play with DirectInput a little
more before I figure it's joystick enumeration out. Unfortunately,
I'm not able to play Pong yet, so it will take another day before this
I noticed there were quite a few people interested in my sponsor
yesterday. Thanks to all of you who are supporting us and this
It's now 3am, I'm going to bed. :)
I've been able to come up with a decent way to emulate the
controllers. Since I would like to allow all 3 basic input devices
(keyboard, joystick, and mouse), and allow any combination of them to
work, this is going to be a little tricky to pull off. Anyway, here's
- If only a digital input device is requested (ie: keyboard only or
a joystick with no analog input, such as a Gravis Gamepad), then
the standard digital D-Pad will be easily emulated. The analog
stick will be emulated on a simple linear time-to-distance
formula, effectively "pushing" the analog stick farther in a
given direction the longer the digital input is pressed. A
control can be specified (ie: a single key) that allows to toggle
between the analog stick and the D-Pad, or another set of keys
can be set aside to switch between them.
- If only an analog input device is requested (ie: a joystick such
as the MS sidewinder or a mouse), the analog stick will easily be
emulated. The D-Pad will be activated again with a toggle, which
will turn the joystick or mouse's input into digital form.
- If both analog and digital devices are requested (ie: a keyboard
and an analog joystick), then emulation will simply pass the
appropriate data to the emulator.
This is about the best way I've been able to decide on emulation of
the controller. Of course, I'll eventually add support for the N64
Console Cable converter
but not right now.
If anyone has any suggestions they'd like to make about the emulation
above, let me know. firstname.lastname@example.org
Some good stuff came about today, thanks to Brian. The controller
initialization has been implemented and works very nicely. Project
UnReality is capable of attaching/detaching controllers at runtime.
Pong now plays itself too (assuming all controllers are detached)!
The next major step is hacking the controller data block, which
determines what offset the buttons are stored and which bit defines
the A button, which defines B, which defines Z, etc., and the analog
joystick position. Once this gets going, I'll be able to begin
implementation of the controller itself using DirectInput. I'm not
too sure on how I'm going to handle emulation of the analog and
digital pads yet, but it's not too big of a deal to worry about right
At any rate, I suspect I will be *playing* Pong this evening. I'm
going to bed, it's 2am. :)