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 about finished...

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 function. :)

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. Enjoy!

---

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 behind. :)

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 hang problems...

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 following screenshot:

[Image] 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 optimizations.

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...

[Image] 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:

1. 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 16-bit.
2. 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 :) ].
3. 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.

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.

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 drive.)

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 it...

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 condition.

---

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! :)

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 patient. :)

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 systems.

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 list. :)

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.

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 thought. :)

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!

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 yet.

I'm sure I'll see more of these problems... but hopefully it's not anything serious and they'll just go away. :)

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 http://projunreality.blackbag.org).

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. Sheesh. :)

---

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. :)

[Image]

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 much longer...

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: bpoint@bpoint.ml.org.

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 N64).
• 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 DirectSound.
• 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 pretty well.

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 support!

February 18

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:

[Image]

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 audio emulation.

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 Pong. :)

Thanks to all of you who continue to support us! You won't be disappointed. :)

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 about 1:2.

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 http://members.xoom.com/nEMU/

---

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 come back.

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 happens.

I noticed there were quite a few people interested in my sponsor yesterday. Thanks to all of you who are supporting us and this project!

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 the rundown:

• 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 (http://www.consolecables.com.au), but not right now.

If anyone has any suggestions they'd like to make about the emulation above, let me know. bpoint@projunreality.ml.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 now either.

At any rate, I suspect I will be *playing* Pong this evening. I'm going to bed, it's 2am. :)