I also found several games that are unbearably slow due to graphics compilation: Battle Tanks, Wizardry: Legacy of Llygamyn (or something), Starship Hector.
I have no plans to fix these, just letting it be known that they're problematic.
I now use triple buffering for the video, which fixed the flickersomeness in Final Fantasy.
I added an option to disable the DMC, as it was really irritating me in Final Fantasy 3 (which is an incredible game, get the translation at The Whirlpool!)
So at long last here's the release... I'm going to have all the source code available just as soon as I put the files together.
I don't plan to work on this again any time soon.
I made a set of batch files and utilities (which will be included with the release) which can be used to make a set of NES ROMs into N64 ROMs for backup units without proper emulator support (like CD64 and, I think, Z64).
I've out together v1.1, I'm just going to wait until the 25th to release it. If you want it now I'll send it to you, I'm just now ready for the full-blown release yet.
I also switched to 16-bit sound and made the volume a bit lower to prevent any sound overflows (which was happening in Kirby) but still maintain all of the detail of the sound. You'll just have to turn up the volume a bit.
Im currently in the process of compiling a readme for v1.1. Again I beg for the help of people with backup devices to help me write a section for their devices.
I'm aiming right now for a Christmas release date.
So what's left to do? :)
I also fixed that evil clicking problem in the triangle wave by just stopping oscillation when the wave is disabled, not setting the output to zero (while that may work for square waves or the noise channel which are either on or off, the tri wave has different output levels and suddenly switching it on or off will produce a click.)
There was also a slight bug introduced into the SMB underworld music, this was fixed (a problem with the linear counter.)
Loading message now shows for entire duration of loading.
I tried to implement mapper 66 (Mega Man, SMB Duck Hunt) but it seemed to fail totally at making either game work, so I went back to making Mega Man just use mapper 2, which it works perfectly with.
I added partial mapper 71 support (Big Nose the Caveman). Solstice is also supposed to use this mapper, but it works better with mapper 7 so I have it use that. Big Nose Freaks Out works until the game itself starts, then it freezes. it does some pretty weird things with scrolling so I think I'll just leave it be . I don't know of any other mapper 71 games that are working.
I had a bug in the MMC3 SRAM enable/disable loops, they were overwriting registers in use by the CPU emulator. Now Startropics works perfectly, the intro music plays, there is no longer a graphics problem upon entering the "test of island courage", and the jumping sound always works right. I fixed a similar issue in the Arkanoid paddle handler, but it didn't seem to affect anything.
Tested 3D Block (3D Tetris) and Startropics 2 for the first time in a while, both work. Rad Racer no longer looks as good as it used to.
 |  |
| with PAL mode active | without |
For the longest time I thought that was my fault... then I finally got around to testing it in FCE Ultra. Same results.
I found that the Star Wars problem was an MMC3 IRQ timing issue and not something fundamentally wrong with scrolling. I fiddled the timing a bit to fix that problem, but it caused some other very minor problems. I don't know if it is worth striving for total accuracy in this area, as the errors are very small and in no way affect gameplay.
I also removed an erroneous optimization I had made to the CHRRAM pattern table compiler, I was only compiling when the second bitplane had been written now I compile upon the writing of either, this fixes the reversed colors in the Wizards and Warriors 3 intro and made Princess Tomato in Salad Kingdom playable (you can see text now!)
I fixed a bug I had introduced in MMC1 when I fixed Dragon Warrior 3 and 4, Monster Party now works again. I had to adjust the number of cycles before NMI significantly before I could get both Big Foot and Dragon Warrior 3 working properly in the same version. Unfortunately the optimum arrangement involves a small amount of status text bouncing in Battletoads.
I now have only minor graphical or sound errors in every licensed USA game I know of (with a mapper I support).
I changed the ROM detection system to be able to find the ROM at the very end of the code and not just at 2MB, this is for an experimental method to allow creation of a ROM CD with the CD64. By the way, if anyone has a CD64 and would like to test it let me know!
Wrote all of the December log entries online. A lot of work, no?
Several games that did nothing but crash before (Solstice and Big Foot) are now working. I attribute this to the fact that i just removed a stupid irritating debugging tool I've had sitting around for months, which checks for stack oveflow constantly. This had been left in because for some reason removing it slowed emulation down considerably. Removing it now has not changed speed at all that I can tell, but its certainly saved the processor some work and the program some space. I know this directly fixed flickering in Marble Madness, which works quite well. It also fixed a slight flickering in the "door opening"/"door closing" effect when entering/leaving a town in FF.
I fixed a graphics corruption issue with the backup unit version's reset function (most noticeable in SMB3).
I now clip the top and bottom 8 lines of the screen (all the work is actually done by the RDP, I just changed the "scissor" value), as I think the NES is supposed to do. Now games with one-screen vertical scrolling (like Final Fantasy) no longer have a line of garbage at the bottom.
Bomberman shows a blank screen after the stage number, though the music still plays.
I figured out an odd slowdown that was happening after loading a new ROM in the GS version, by doing so I found the ultimate source of the cache problems that had plagued me for so long and fixed them (it involved initialization, I would set the screen buffer to 0 and then draw there, but this would overwrite code!)
Implemented a full save system, with three saves per controller pack and name entry so you know what saves there are (and which to delete when out of space).
By waiting 4 cycles instead of 35 between setting the vblank flag and triggering the NMI I now have Deadly Towers working properly. The change in values was between two version of the FCEU sorce I had looked at.
Added a PAL mode which simply extends the vblank period by 50 lines, doesn't change the audio generation rate though. Elite and Asterix work nearly perfectly in this mode.
For some reason Double Dragons does not get past the start screen.
Deadly Towers only works until you go into the first room, then the controller stops working. It looks like the NMI is called while still in the NMI handler.
- if they'll work in the current dev version
- if they might work before the release
- if I'll never support them (within the forseeable future)
Bugs fixed today:
The issue of Dragon Warrior 3 and 4 not working was solved, I had not realized that the 1st/2nd 256K PRGROM switch applied to the hardwired bank as well.
This also enabled FF1+2 to run, however when I tried to play FF1 it crashed when I attempted to strike up a conversation with anyone. This is only with the FF1+2 combined cart, FF1 by itself works fine. I didn't notice any problems in the FF2 portion.
I removed the irritating sound from Bubble Bobble by extending the "if wavelength < 8 disable channel" thing to the triangle channel. Now isn't that nice.
I still need to remember to go back in and optimize (ever so slightly) the sp0 hit detection, I don't need to cycle through each pixel of the sprite now that I'm just checking for any active pixels at all, I can just or the bitplanes together and check if it is nonzero.
Additionally I just recently found Wizards & Warriors 2 (it is called Ironsword) and noted that the following happens when you enter a store without any money:
For whatever reason the break flag is supposed to be set by PHP. I implemented this and it fixed the R/W SR and BRK flags tests in NEStress.
For some reason Wizards & Warriors reads from $4006. I return 0 for unknown registers...
I combined the Arkanoid paddle data into the second player controller so that both two player games and Arkanoid work without modification.
I fixed two problems with sound. SMB2 sets the sweep shift amount to 0 to stop the sweep of square channel 1, but I did not detect this. The other fix was with the sweep end conditions, where the channel would be disabled with a wavelength over $7ff or under 8. I didn't have this properly disabling the channel. The two problems this fixed were in Dr. Mario and SMB3, and both situations involved a thud sound.
After fixing these problems the program ran noticeably slower, but not because of an increased workload. The ordering of the various included files greatly affects the speed of the program, due, I expect, to cacheing issues. I managed to get everything to a very nice speed by putting all includes except the read and write handlers at the very start of the code, and I left the read and write handlers at the end (just before the logo data).
I also noticed a new sound problem: Startropics doesn't have any sound at all (except for an occasional bizarre glitchy squeal) until you talk to the island chief. The sound cuts off again just when you enter the "Test of Island Courage", but quickly returns. When the music is active it sounds perfect... I tried reenabling frame IRQs, but that was not helpful. The sound registers are all zeroed until sound is activated.
I also found a problem which may go a long way towards fixing some other issues. The Dropoff 7 demo is essentially just a DMC demo, but it is supposed to have a title screen. The title screen does not appear in Neon64, though the sound works "perfectly". Since the graphics setup is likely very simple it should be easy to disassemble this code and see how it works, and from there I can find my problem.
On a positive note, the To-Do list fits on a single screen for the first time ever!
I also discovered that the frame IRQ causes Wizards & Warriors 3 to crash, so I left the IRQ itself out, though I left in the rest of the logic for it. I see no reason to leave it in, it doesn't help anything.
Began to implement support for the Zapper, but a complete lack of success in actually hitting anything (the trigger worked fine) made me pause. I did successfully implement the Arkanoid paddle, though it seems to me to be a great deal harder to use. Its nice to have some true "analog" control in there, though. In order to allow the user to select this feature I intend to implement a menu for configuration.
I also added support for sound frame IRQs, but no game yet seems improved by them (I have it to the point where it doesn't break anything, either).
I also implemented color deemphasis (the three high bits of $2001). The programs I know the behavior of seem to work properly with this, Chris Covell's Wall Demo, Super Spy Hunter (when paused), and Final Fantasy (upon entering a battle).
I also doubled the size of the pattern cache. Teenage Mutant Ninja Turtles 2 and 3, as well as Xenophobe, run at a good speed as a result.
Fixed by proper formatting of $4016.
This used to crash at various points but is now at least playable in the first level (a slight graphical glitch in the intro is the only problem I've seen).
Quite an incredible little unlicensed game...
FF2: This used to have scroll problems, but not anymore. The translation intro is messed up, but I'm told it doesn't work on the hardware anyway.
And a little note from Wizards & Warriors 3
When the game starts the one-screen mirroring is set up wrong, and the screen is set to a blank screen until an sp0 hit is detected. Of course with a blank screen there is nothing for sp0 to hit, so nothing happens. The only reason I was getting any results at all is that on skipped frames the faster sp0 hit detection will always find a hit, because it is set in the first detection of sp0 regardless of background. I don't yet know how to get this to toggle right.
Made sp0 hit on frames with gfx disabled (for speed) more accurate by recording what line the hit was triggered on on the prvious line.
By puttin v=t (see loopy's docs) after the junk scanline for loading line 0 sprites I was able to fix W&W without any hacks, as well as get Battletoads to work almost perfectly (except that sp0 hit thing), all with the 512 cycle SPRDMA latency so that Castlevania works. Yay! The only remaining issue with 'vania is the "C" on the title screen flickers. There was a similar problem when I first implemented the new SPR DMA method...
I had fiddled with sp0 timing quite a bit, and the Solar Wars title scroll is now off by a line or two. Drat. And I must find out why sp0 doesn't work for Battletoads, I'd rather not have any stupid hacks in there.
Wizards and Warriors 3 works perfectly, and Castlevania 2 now runs at a good speed (before it was unplayably slow).
And now, just so you know this isn't one big lie, here are some screen shots.
Battletoads
Wizards & Warriors
Wizards & Warriors 3, the great abuser of graphics
And I just recently discovered an Easter Egg in Kirby's Adventure, so I loaded it in Neon64 to see if it worked:
I currently do not know the cause of the black block on the top, but there was a similar issue in Mike Tyson's Punch-Out.
Also, the dialogs in Final Fantasy now cut off at the right point! Yay! I'll have to test Battle of Olympus...
Zelda intro scroll and Wizards and Warriors worked when I cleared the 8 sprite and sp0 flag when the vblank flag is set instead of waiting until the end of vblank.
There was quite a nasty bug in the DMC IRQ, which would have messed with frame toggling and mmc1 reg0, but fixing it doesn't help anything. Oh well. Bomberman 2 now works, but I'm not sure if I can attribute this to this fix. Probably not.
The games which were previously quite slow seem to be running at a good speed, such as SMB3, Journey to Silius, and Zelda, I'm not really sure what to attribute this to.
I messed with SPRDMA timing a bit, and to that end I made the 6502 emualtor check if the cycle counter is > 0 before it executes a single instruction, but again this messed things up a bit so I left the 512 cycle delay out.
I played around with the name table bits int he VRAM address register, but in the end I decided to leave it alone and stick with a strict interpretation of loopy's docs.
I got Battletoads working decently by triggering a sp0 hit at the end of a sprite, whether it has hit the bg or not. This is not perfect, and is in fact a dirty hack, but I don't yet know what aspect of sp0 hit I am emulating incorrectly.
I've noticed that Castlevania no longer works right, but will work very well with an SPRDMA latency of 512, but this destroys Wizards & Warriors and messes up Battletoads a lot. I'm just going to leave it for now and be happy with W&W and BT working.
The glitches on the VS screen and on the intro to the Mike Tyson version are the only ones I know of, they would require mid-scanline bank-switching to work corretly and that ain't gonna happen.
I also fiddled with Battletoads a bit, but with no success.
I've a nice Zelda 2 screenshot I never bothered to upload, demonstrating that it does indeed work:
Also, I've noticed some bizarre status bar problems with Ys and Princess Tomato in Salad Kingdom. Xenophobe has been tested and is really slow.
Notes: make sure sprite checker increments pointer to SPRRAM. Also, SPRRAM DMA maybe take 512 CPU cycles, not 256.
It should be noted that even FCE Ultra doesn't do MMC3 IRQs right.
Tried to work out the problems with Final Fantasy 1&2 (a combo cart). A lot of my possible solutions involved initial values for the for the MMC1 registers, but I only succeeded in confusing myself.
SMB3 still a bit glitchy just above the status text...
Zelda 2 status text now works right.
Implemented a system where sprite DMA is done directly by the RSP instead of intermediately by the CPU first, had to write back the values from cache first.
Sprite 0 flag is now set at (approximately) the correct point on the line. Zelda status text cuts off a bit late, Mach Rider is horrible. Solar Wars title is slow.
VRAM status is now only updated when it is changed, so I don't have to be continuously accessing the RSP.
I made TLUT (palette) load only when the palette actually changes. Interestingly, when I disabled changing it the palette remained in TMEM even after N64 power had been turned off.
I moved the MMC3 IRQ to before hblank, this seems to fix the jumpiness in Kirby (start screen) and Crystalis (message boxes), but I suspect it may be triggered a line too late (early?) Plus I don't have it properly react to the effect of changing the VRAM addr. Fiddling the timing by a line seems to mess it up in certain situations, so I'll just leave it be for now. I don't have any mechanism for triggering it during a scanline anyway.
Removed PC "optimization", W&W works. Very, very rarely I see a line out of place. The flaw would likely be invisible to the untrained eye. Both times I noticed it on the W&W title screen, where the knight is facing off two bad guys.
The status text in W&W bounces a lot. I'm not sure if this is new.
Maybe if the RSP DMAs the sprite data directly from the address specified by the DMA command we can save costly CPU overhead in the matter? Writes to SPRRAM via $2004 (which I'm told no game uses) could be made directly to the RAM in the RSP. Something to consider... Because it seems like sprite DMA efficiency is very important in some of the slower games (Sprite demo).
I think the slight MMC3 rearrangement has caused an unwanted line in SMB3 (world select screen)
In addition to the music being slow, Solar Wars also occasionally freezes after the planet select screen (waiting for music to end?)
Big Foot runs super slow, as well as having the zelda 2/die hard glitches. I've heard it has multi-split-screen scrolling, maybe it is too big for the cache?
SMB sp0 is not flickering, but rather bouncing. Zelda status text does the same thing. Happens no matter how much DMA protection and what parts of sprite rendering I take out. Doesn't happen when paused (with SELECT).
Journey to Silius had major scroll issues, it was a problem with the new VRAM_V DMA. This was fixed by caching VRAM_V, VRAM_X, and VRAM_T. I also had to perform a cache op (#25) each time I use VRAM_V or VRAM_X .
Put gfxless PPU in a seperate loop, didn't help with the occasional crash on start but may have made it a little faster.
Wizards & Warriors is broken, probably because of PC optimization.
I've found out some information as to why Bill & Ted doesn't work, apparently instructions which read from memory, modify the value, and then write the result, first write back the original value. This, combined with the fact that when writes are made quickly only the first one is detected by the MMC1, should enable Neon64 to run Bill & Ted. Also, only the address to which the last (fifth) bit is written determines the MMC1 register which the value is written to. This information, by the way, came mostly from a thread on Memblers' NESemDev forum about FCEU, with some comments by Xodnizel himself.
I also got an updated version of Brad Taylor's PPU doc, hopefully to help me with th scroll bug and some other issues.
I also found a description of how monochrome mode and the various color emphasis bits work from Chris Covell.
An idea that I had simmering for a while came to life today, I figured out how to pipeline sprite pattern DMAs like I did with BG patterns. This did make things a bit faster. There is some serious flickering.
I figured out why the fadeout wouldn't work sometimes, it was simply that the double buffering was switching the screen, and so half of the time the fadeout would be on the other screen.
Zelda crashed, seemingly at random because I haven't been able to reproduce it. Crystalis had done the same thing...
I also fixed a problem with CHRROM corruption involving that blasted cache issue again, the ROM is now once more uncached (I think I changed this because of GS). This fixes at least Mega Man 4, Mega Man 6, and Final Fantasy 3.
I also invalidate any cache overlapping the ROM, which fixes some crashes, most notably Crystalis.
I fixed the Solar Wars title flickering problem by only updating VRAM_X at the end of a scanline. Graphics are only scanline-accurate in Neon64 anyway (which mean it'll never be able to run certain games), so this doesn't change anything (other than fixing that problem, but I'm not sure why that wasn't a problem in the old version) I listened to the Solar Wars intro the first time while testing this, and it seemed abnormally slow, not that the tones were downshifted, just the tempo was off.
There are issues with the noise channel in NES Test (of course I've issues with the noise channel everywhere anyway.)
I stabilized the sprites (Kirby sprites jumped around a lot) by inserting a tile sync at the end of the display list. I also implemented a slightly better sprite 0 hit detection (when I reivsed the PPU for the RDP I made it just do the hit on the first line of the sp0), which sets the flag on the first line of the sprite with any set pixels in it. I don't know of any game that this isn't currently working for, though it is a bit of a cheat.
Solar Wars seems to drop lines out of its scrolling flame effect at random.
There are also some problems with saving and reseting (part of the same system), problems of the "it doesn't work" variety.
Also, Mega Man 6 has developed the same pattern corruption issue that Zelda 2 and Final Fantasy 3 already had.
It also seems that there are some instances where sprites seem not to flicker properly, like in Castlevania (lines drop out in an odd way).
I had to implement double buffering for the video, because there was quite a bit of flicker caused by the sequentiality of drawing, I also synced the screen updates to the vertical retrace so it looks considerably smoother now.
The sprite priority problems in SMB3 and Castlevania were fixed by the new RDP useage, as that was the main point of doing it anyway. I have the suspicion that some games run a little slower (like Journey to Silius) but I haven't done a side-by-side comparison yet, and they actually seem to run smoother anyway from the double buffering. I should also note that when I press reset in Journey to Silius the fade to red routine which I have inside the reset interrupt handler is not run. I have not noticed this in any other game, perhaps it is a clue as to the game's extraordinary slowness?
Expect an update to both the backup unit and gameshark versions soon, after I implement a few more optimizations I'd like to try.
Back on the subject of resets, I've found that a reset can be delayed by constantly issuing SI DMA requests, i.e. if you press the reset button but the N64 program is constantly issuing DMA requests the N64 will not reset, until, that is, the DMAs stop. Another issue is the freeze at boot. For some reason every N64 program must write a certain value to a certain place in PIFRAM (IIRC) or the N64 will freeze. It turns out that constantly issuing SI DMAs will also prevent this freeze from occuring. I have not yet done any quantitative experiments to find out exactly how frequent the DMAs must be to prevent a reset or freeze. Also, since the freeze on boot can be prevented either by writing to PIFRAM or by issuing DMAs, I thought that maybe reset might be stopped in the same way. It didn't work, though, when I tried it. When I had my reset handler write the value it didn't reset, but merely froze. Maybe the interrupt line was never cleared?
I also merged the two versions of Neon64 into a single pile of code so they can both be updated at once.
It turns out that RDP control from the RSP is almost exactly the same as from the CPU, in fact the way I was doing it was correct, there was just so much else wrong with my test program that it wouldn't work.
I did learn that it is apparently impossible for the RDP to read textures or palettes from RSP DMEM (or IMEM, I tried), even with the fully qualified addres (0xa4000000). This means I'll have to use another SP DMA to get my rendered sprites out of DMEM and into RAM where the RDP can get to it.
I also have a fairly solid system for sprite/bg priority set up, which should fix the SMB3 and Castlevania sprite priority glitches. It turns out that things are a tad more complex than they appear.
I also made several modifications to U64ASM:
- support for parenthesis and commas in macro parameters
- trapping divide by zero errors
- fixed a problem with multiline macros with 10 or more parameters
I also fixed a bug in the controller strobe code, but it didn't fix anything.
I implemented a frame rate monitor, accessible with the L button. It tells me that most games run around 40 to 50 FPS.
I doubled the horizontal screen resolution at the intro/loading screen, which allowed me to fit an old extended ASCII art logo there.
Of course on a TV the aspect ratio works right, it almost looks like normal text mode.
It should be pointed out that the GS version is abysmally slow when it comes to sprites, in Journey to Silius with many sprites on screen I have seen the framerate drop to about 2 FPS. The frameskip is just about perfect, though, I have yet to hear the music skip.
You might ask why the Gameshark version of Neon64 has just been released while the normal version remains unupdated. The reason is that my v64jr has been very unreliable as of late and I've rarely gotten more than a few seconds of use out of it before it fails. The next big release, which will include the sprite speedup (which is NOT in either version right now) will update both versions and will be called v1.1. By then I may have worked out a general purpose loader for the GS and seperate versions may not be needed, who knows.
To clear up a bit of confusion, the GS version is indeed different from the normal version. It has better frameskipping, bugs in the DMC (a sound channel) have been worked out, and mapper 7 support (Wizards & Warriors) has been improved. The GS version does not "enable use of the GameShark", it is an entirely seperate version which can be used with the GameShark. The two versions are not interchangable.
FF3 has significant sprite corruption in the GS version.
Some of the slowdown (most noticable on SMB, which slowed to a crawl) was because I hadn't written back the NES ROM to RAM, it was all in cache. This also caused some sprite corruption. Neon64 is still a bit slower on the Gameshark, though, mostly when a lot of sprites are on screen the music will break up under the strain. Interestingly enough, I just happen to be working on a sprite speedup now.
I've successfully run Neon64 using only a GameShark! Go out and buy one if you know what's good for you.
Once I figured out how to send code to the N64's RAM, all I had to do was find some space in RAM to store the emulator and NES ROM and make some small changes to the Neon64 initialization. I believe this is the first time the Gameshark has ever been used in this way...
I'm still in the debugging process, but I have played Super Mario Brothers for quite a while. Awesome!
Note to self: have seperate function for bg and fg sprites, just execute straight through?
Added Delta Modulation Channel (aka DMC or DPCM).
There are still issues, the sound of breaking blocks in SMB and Samus' footfalls aren't right. I stopped the linear counter from automatically switching to load mode on terminal count, this fixed several situations where the triangle wave was playing too long (Castlevania pause, SMB underworld).
Made several changes that resulted in stopping the buzzing in Mega Man 2 before the intro music starts.
Found the cause of a Zelda problem (on name entry screen), came up with a good solution which might also be applicable to the noise channel. The issue involved audio resolution.
Here's samples of sounds... Mega Man 3 intro Metroid intro ...recorded from my N64.
Everything up through the noise channel is working pretty well. And by pretty well I mean it kicks ass. I love game music.
It's going to take a lot more work, my overall audio generation engine is crap.
CPYABS was set up to use rRAM_A6502, which can only (correctly) access the zero page. Thus essentially every use of CPYABS was broken, because any time you might want to use the zero page you'd use CPYIMM for speed and size savings. I found the same problem in CPXABS. This warrants a closer scrutiny of the CPU for this kind of error.
Super Mario Brothers 3 is now continuously playable!
Dragon Warrior is now playable!
Wizardry is now playable!
You have done well in defeating the Bug.
Thy Experience increases by 1.
Interestingly, when I removed my debugging code Neon64 actually ran slower... so I put it back in.
By removing the MMC3 IRQ count reload from latch (on disable) I was able to make the moving-ceiling room of the world 1 castle (MMC3) have proper status text.
I implemented mapper #7 (AOROM), which is used on many Rare games, but when I tried it with Wizards & Warriors it was pretty much unplayable.
I've been trying to implement sound scheduling and so on, but I've been running into some trouble. Quite a bit actually.
It seems that when IRQs are disabled SMB3 runs fine, but that's as far as I've gotten.
I fixed the bg clipping so that it actually works with scrolling, SMB3 and Stars SE work much better now.
I found several problems preventing SMB3 from running. First, I needed to disable MMC3 IRQs when the background is turned off. This allowed most of the game to run correctly. However then, upon exiting Toad's "line up the pictures" game, the game crashed. I found that it was due to an error in the CPU core, improper behavior when the stack overflowed. However, even upon fixing this, the stack still overflowed, thus the game would freeze for several seconds and then crash. I do not currently know why, but I suspect the CPU. Here are some SMB3 screenshots:
I also added a much more efficient tracer (no more bullet time while debugging) and found out more about the Zelda 2 and Die Hard bugs (which increasingly seem to be the same bug.)
Tested, no improvements.
I found a nice image conversion program called pic2pic, it let me make a bunch of screenshots (JPEG compressed) for ya:
There was an issue wherein the last entry in the compiled graphics pointer table was not being transferred to the RSP, this is what cause the Mega Man 3 (et al) problem. This was introduced by accident on 6/2/03.
Another issue involved speed. Neon64 has been running slow since I changed the ROM pointer to uncached. When I changed it to cached it sped up but several games displayed sprite glitches. I reached a solution by making two pointers, one cached and one uncached. The cached version is used to access PRGROM, and the uncached version is used to access CHRROM. I may do something similar with the VRAM pointers, which need to be written uncached so the RSP can read them, but they are read much more often than written. Some well-placed cache instructions should solve this and boost speed.
All Mega Man games, as well as SMB2 and FF3, now run without visible flaws.
Quick story:
To find the first issue mentioned above I went to the Media Center (computer lab with some books and a copy machine). Usually I can set up my N64, V64jr, and laptop, connect the N64 to a monitor (via the N64->VGA adaptor I finally got) and code away, but today they wouldn't let me use a monitor (despite the fact that there were a dozen free). So how does one debug a video game without video?
Screenshots!
I loaded the ROM, pressed buttons on the controller from memory, took a screen shot, then saved it as a BMP on the laptop, viewed it in MS Paint. And that's how I found my bug. Good timing, eh?
This suggested the possibility of taking many screen shots rapidly and displaying them instead of saving them. Video over parallel port...
It turns out that JrGrab sucked, so I wrote my own version. It supports any resolution and color depth and I intend to release it, with full source code, when I get it into a more final form. (Here it is in case you're really interested.)
Here's a screenshot from MM6, dumped with my screen capture utility.
- The ROM was being treated as if it were in cache (which may have been what crashed SMB3). This helped me to catch #2.
- The 1K CHRROM switch was writing two pointers to the VRAM page table, which was writing over name table pointers, so effectively pattern tables were being used as name & attribute tables.
- The mirroring register was backwards (I think this was goroh's mistake [edit: no, it was my misreading]).
I'm trying to add MMC3 support...
I also noticed an interesting phenomenon: when the debugger is waiting for a button to be pressed and the reset button on the N64 is pressed nothing happens. The reset only occurs after a button is pressed and the wait loop is exited. The ability to delay the reset could be most interestingly exploited...
I also changed the controller access to work properly (DMA command to PI, DMA result back) with the PI driver I wrote for accessing the controller pack. This seems to be a bit faster. Thanks to LaC for clearing up any confusion as to how the PI works.
Neon64 has a section of memory reserved for what I call "bgline", which is just the background color repeated 320 times. This is loaded by the RSP via DMA in order to clear out its internal buffer at the beginning of a line. This means that I never have to explicitly write a background color, which in all cases gives me a speed advantage.
Several versions ago I was running Neon64 in 256x240 mode, and recently I switched to 320 or so. As such, I had to increase the size of the bgline from 256*2=512 (2 bytes per pixel) to 320*2=640. I changed the code which writes and reads the bgline, but not the actual size of the memory region itself. The next area in memory was the compiled pattern table array. Whenever bgline was being updated, the pattern table would be overwritten with pixels from bgline. It just so happens that the primary background colors I'd been testing with (black and Super Mario Brothers' blue) were valid instructions, so this never became a problem unitl Final Fantasy's map screen used a different color for background. This color was written over the compiled pattern table and read into the RSP, but when it was executed the RSP simply gave up and crashed.
Thanks to LaC and lemmy for this great debugging tool!
And in response to the message someone left in the guestbook, if you'd like to beta test the latest version just ask.
LaC sent me a corrected version of Nemu. I'll see if I can speed it up at all past the 3 FPS I'm getting now...
I'll work on that bug in Mach Rider (and possibly the same one in Final Fantasy) some other time.
By the way, Mach Rider runs at about the same accuracy level as in loopy's NES emulator (loopyNES), and its his documentation that I'm basing my work on, so maybe...
The problem is more likely that we both decided not to bother with writes to the VRAM address register mid-frame for speed considerations. At least I'm pretty sure that's my problem.
I took a bit of a speed hit in this, though, so speed was then at 80%.
Then I fixed some glitches with the new sprite loading routine and finally got the graphics compiler to work when only one byte needs to be recompiled, rather than the whole tile, which led to much nicer speed on games like A Boy and his Blob and Alfred Chicken.
Then I modified attribute byte loading to only load each byte once, for a new speed of 83%.
Then I made the RSP start before checking the sprite 0 hit stuff in the CPU and made some sprite VRAM table lookup changes to get rid of a problem I would have when using some higher mappers. I also made the sprite 0 hit check not take place if its been found already, and no effort is expended if the sprite is blank, because then no hit can take place (that check is really cheap anyway) . After that speed was back up to 85% again!
I also made some attempts at rearranging the background drawing function, as it still does plenty of redundant things (such as looking up addresses in the VRAM page table, which will only change on a name table change), but I messed something up and had to scrap that. I did get some good ideas for when I'll finally implement the pipelining that I've always wanted, mostly involving loops. I think a lot of inspiration for this came indirectly from Brad Taylor's NES Emulation Discussion document.
So effectively I got no speed increase but greater compatibility. Not a bad day's work.
I think I'll just revert to the 2/8/03 version, remove the stuff with the cache (which at best causes no improvement and at worst is slow and glitchy), and try to optimize the PPU there. I will keep the concept of loading the sprite patterns when loading the sprite, instead of while drawing as in previous versions, as this will allow me to avoid having to wait for the DMA to complete.
The new strategy will be to only do sprites on the CPU... we'll see how that works out.
 |
 |
| The best part of the game... | Um, should I laugh or scream? |
In the running for best intro on the NES.
What SMB really looks like on the NES. The NES' video output isn't quite at the same quality level as the N64's, is it?
I also finally got an AC adapter for my NES (at Radio Shack on sale for $5 apparently they've devalued from the $16 it was in my catalog) so I now have an accurate layout for the video output. I'll be changing my output to reflect this sometime soon.
I did a huge amount of work on the sprite cache, getting it to work with various games and 8x16 sprites, but I still have bugs in it. Given the small if anything performance boost, I wonder if it is worth all of the effort I'm putting into it.
On a positive note, Total Recall and Alfred Chicken have been tested and work splendidly, despite the fact that Total Recall does not deserve to exist.
I also got the sprite 0 hit working reliably in both SMB and Solar Wars at last.
This caused the Final Fantasy battle scenes to work, as well as the enemies in Metroid.
I fixed the annoying line of garbage at the top of the screen. I also fixed the interpretation of the MMC1 CHRROM switch registers, all 5 bits are used (contrary to Firebug's mapper doc). This made Teenage Mutant Ninja Turtles and A Boy and His Blob work correctly.
This section wasn't working before.
I noticed some random crashes in Zelda and TMNT, but this could be because of a hardware problem, as the N64 died in a way it never has before each crash.
Fixed Mighty Bomb Jack (I wasn't clearing unsupported registers like controller 2, it was reading both controllers and ORing the results together). Fixed some MMC1 graphical glitches (skipped CHRROM switching for games without CHRROM).
The Real Thing!
Yeah, they're slow and still have plenty of glitches, but at least they run!
In other news I ran Mighty Bomb Jack again, it still seems to confuse the right arrow button with the start button, another case to look into.
- MMC1 working (though not on games with PRGROM switch, like Zelda, Metroid, Final Fantasy, etc)
- Increased performance on games that change the pattern tables frequently from "abysmally slow" to "annoyingly slow" by limiting graphics recompiles to one per frame and making graphics compiler a macro instead of a subroutine.
- Made debugger accessible at run time by pressing L and R.
Ah, the sweet smell of failure.
A little glitchy, but most of it works.
This is a cool game, how come I've never heard of it before?
Those crazy Russians and their Mind Games
Blame ATI for the horible image quality. Do any of these games look familiar, Gavin?
Oh, and Stars now works.
This doesn't hurt my speed a bit, as it is all done internally by the VI.
I do lose a few pixels on the left, but this may just be my video capture card misbehaving. It doesn't affect gameplay, anyway.
By the way, I'm planning to add zip decompression to the ROM loading routine, so that one can cram more games onto a single CD (for those who have backup units with CD-ROM drives). The entire GoodNES set is about 400 MB... wouldn't it be neat to play any NES game you want on your N64 from one disk?
It'll also cut out that extra step in loading a ROM. Many PC NES emulators support this and I figure its about time Neon64 did, too.
I'm also planning to implement pipelined DMAs, so that I can load one tile while the previous one is drawing, as I had wanted to do from the start.
Started to work on MMC1 but so far I've been thwarted, I want to fix the CPU bug first now.
I reinstituted drawing the top 8 lines of the screen, it turns out that my TV is nonstandard and shows more at the top than others.
Chris Covell's Stars demo crashes after a few seconds (but the scrolling works!) with a bad opcode. CPU debugging, ahoy!
I fixed the bug, which was caused not by the CPU not being fast enough but by my new PPU code being too fast for even the mighty SP DMA , so I had to put a wait in there. I should have known this when I noticed that if I put a delay in the attribute table secion (which is between this particular DMA and where the DMAed data is used) the problem went away, but not if I put it elsewhere, but I didn't. The breakthrough came when I ran my favorite debugging buddy, Arkanoid, and noticed that the glitches were not with the attribute table (the flickersomeness was with actual patterns, not colors) but rather with the pattern or name table. As the attribute and name table calculations work exactly the same way, based on the PPU V register, the allowed me to free V from suspicion, as I had been examining it before. I knew that it must be a problem with the pattern table access.
AND INDEED IT WAS!
I was trying to run my compiled pattern table tiles occasionally before they were fully loaded into the RSP, thus it would be drawing the previous tile, thus the screen would appear to be shifted right.
Using the new highly scientific "SMB Timeout Test", in which I start a Super Mario Brothers game in both Neon64 64 and a full speed PU NES emu at the same time, then read how much time is left on the clock on the slower emulator (mine) when the time on the other runs out, I determined that Neon64 runs at 78% of full speed. Again, as the CPU runs at about 600%, this is all due to the PPU, which is eight pages of total nonsense at the moment. Total unoptimized nonsense.
Solar Wars still has... issues with the title screen, minor ones but still annoying, considering that this was one of the strongest points of the early PPU. Bah, humbug.
NES Test runs almost perfectly, if "perfectly" can be used to describe the behavior of a program running at an estimated 2 FPS. Let's call it bullet-time.
It's no longer physically painful to play this game.
Yeah, that's right, it runs.
Wow, its 2 AM. Time to celebrate... let's write a Physics lab report! Yay!
That problem was quickly dispatched, let's note the structure of the SP DMA length register for posterity:
bits 11-00: length to transfer -8, lower three bits are ignored
bits 19-12: number of times to transfer that length -1
bits 31-20: bytes to skip between each transfer (skipping only occurs in DRAM for either RSP->RAM or RAM->RSP), probably lower three bits ignored
Fixed mapper 2 games by compiling the entire tile each time a write was made to VRAM, I'm still not quite sure what the problem was.
Made sprites draw backwards but load forwards, in order to properly emulate the 8-sprites-on-a-line behavior.
Added attribute table speedup, really nice speed now, but it seems that now it is unwilling to wait for the CPU to catch up, we somehow occasionally start at the end of the current line, so the screen flickers a lot. A problem with too much speed is a welcome one :-)
There's a problem with the scrolling on the Solar Wars title screen, I'll be looking into it shortly.
Started to implement the speedup for name tables today, but other real life things came up so I didn't have the time to finish.
Eliminated drawing of top eight lines of screen, apparently this is the way things should be, which fixed the "Mario going off screen" problem.
And away we go!
WOW! The mushroom is behind the other graphics! HOW DID HE DO THAT?!?!?
Um, jumping ...
I noticed that when Mario jumps off the top of the screen his head disappears before he gets there. Apparently it is possible to have a negative screen position for sprites or something, I'll have to look into it.
Hammered at mapper 2 some more, problem still not solved.
It turns out that sltiu will clear the result if it doesn't set it, rather than leave it alone. I knew this but didn't compensate for it. So I added an or and that seems to have fixed it all up.
I'd have screenshots, but I'm away at my father's house and have no screen capture capability.
Fixed problem with sprites occasionally becoming background by accident, it turns out that I was checking bit 5 of the tile index, not sprite property, byte. It was another case of confusion between ones and twos.
THE CASE IS SOLVE-ED!
I didn't clear the carry flag for LSR (logical shift right). This appears to make Solar Wars behave splendidly, I have yet to test other games. YAY!
MARIO WORKS! But since my sprite 0 hit is a bit cheap the status text cuts off a little early...
Seems to fix the terrain problem with Solar Wars and the sprite corruption problem with Arkanoid, which now has a few other visible problems but I think I'll leave them alone for now and concentrate on the graphics generation.
Got pseudo-color graphics compiler working. Some problems still exist, namely that the Arkanoid screen still doesn't clear entirely, Solar Wars arithmetic is messed up, Arkanoid demo levels are wrong, but I'll examine that further tomorrow. It looks great!
Took a chance without backing up the last version, luckily it paid off. For a while there was a single line of the wrong name table at the top of the screen. I set off into the code to find the reason and discovered that I have made the $2000/$2001 mistake again when resetting v=t, which only happens if the bg or sprites are active. This also solved the incomplete clearence problem in Arkanoid! There is still a sprite/bg misalignment problem, though. (Solved!)
Captain! Three screenshots off the starboard bow!
(slightly old)
All of the background is drawn by code running on the RSP which was dynamically generated by the CPU.
AHA! In read.inc the read 2002 function loaded the clear vblank flag constant with an li, while the constant was greater in size than could be loaded with an li, so I changed it to an la. But that seemed not to have solved anything.
It works in two parts: one draws air (blank space) from the top of the screen and the other places a surface tile below that. This works column by column. Initially the entire screen is an array of ground tiles. I determine that even when the air drawing section is changed to fill the enitre column there are occasional places where it stops partway down the column (and before it has reached the surface), so either it does not make the change completely or the change does not get completely put to the screen. I am more or less sure that the code to make the change executes, so next I'll check if that is reflected in the local pattern table and then in the RSP (which accesses the CPU's pattern table to actually do the drawing, but I strongly doubt that it is responsible.)
I've found that Arkanoid's failure to clear the screen is because it does not have enough time in vblank to do so, the VRAM address gets reset as drawing begins and thus accidental writes are made to the CHRROM (which I shouldn't allow). I'm sticking with 20*113 cycles per vblank for now, which helps a little but does not solve the problem. Maybe the instructions take too many cycles, or maybe something is running in error that takes too long, sort of like an emulation cancer. On second thought, I had partially solved this problem before and I didn't do anything with instruction timing...
What's that? You want screenshots? Alright, but just remember you brought this on yourself.
Title screen, notice newly working blue arrow.
Planet selection screen (also newly working).
Eh?
Fixed a bug in the pause routine of the debugger.
In true "Idiotic Programmer" fashion, I fixed a bg problem with Arkanoid, then promptly lost the change and forgot what I did.
Fixed CHRROM loading, both initially and for mapper #3 (CNROM, helped Solar Wars a lot). Before pattern table #1 wasn't being loaded into the RSP, and it wasn't updated on either the RSP or the CPU on a CNROM switch.
If you change byte 0x3900 (0xb8f0 in PROM) to 0x00 the next level warp will always be there, except while the level is just starting.
I should be getting my real development computer back in about a week, 'till then I'm using my new laptop.
I've been toying with the idea of replacing the CPU emulator with the version from beta 1 and then swapping back in bits of the beta 2 emulator until I find the segment that causes a problem, but again I'll have to wait until I have access to the computer.
I figured out that the background in Arkanoid, along with some other problems, was not being cleared before drawn on. Since most everything else in Arkanoid works, this should enable me to pinpoint the problem. I've diassembled the program and I'll be searching for the loop that clears the name tables. When that is found, I should be able to see if it is executing, why if not, and what its doing wrong if it is.
Also found a rather major flaw in U64ASM, a label can be defines in terms of itself successfully, but it won't have any meaning whatsoever. This should generate an error, but I can't think of a quick way to do that, so I'm leaving it as is for now.
My preliminary work on the PPU has been to read the name tables. I made a lot of progress today, fixed a lot of long-standing bugs, and possibly identified the CPU emulation problem. I ran Pac-Man, and the ghosts just kept bouncing around in a small sqaure. This might imply an error in an addressing mode.
The PPU still needs a lot of work, and it seems like whenever I make a change the sprites get messed up. I'll be working on locating the source of this problem.
And here's a view of Headless Mario, all that is displayed when I try to run Super Mario Brothers:
I've also had problems with Solar Wars, Space Invaders, and the PD NES Test, but I'm not going to work on fixing the CPU right away. First I'm going to finish up the graphics, and as of now the next step in that is the background. My idea for speeding this up, graphics compilation, is now well developed and I have the compiler itself written in only 16 instructions. I hope that the burden of loading name table, attribute table, and compiled patterns won't slow down the emulator enough to take it sub-realtime, while its at about 2x-ish now. At some point I'll put together an FPS counter...
When I do, however, get around to the CPU part, I'll probably use Nintendulator or some other PC NES emulator with a debugger to step through a game and see what differences in execution arise.
Later that day...
I take back all of the bad stuff I've said about the RSP, it's all my fault. I keep getting my "make a string of x data type" instruction confused, the first parameter is how many and the second is what they should all be. I kept doing this in reverse, so I'd be defining 0 bytes each containing 32 instead of 32 bytes containing 0. I'm going to put a safeguard into U64ASM to remind me next time I try to make zero of something.
Anyway, this was causing the primary problem with the program, namely that my sprite buffer was size 0 so other variables were writing over it. The sprites now look as pretty as can be! Note that I don't have flipping, priority, or even color working yet so all you see is a shadow of the true sprite, thus Vaus looks a bit odd.
You can see a brick shining here, very nice.
I'd also like to note that this is the exact opposite order that I wrote beta 1 in. For it I did the background first, then the sprites.
Never use any other data size but a word on the RSP. It just doesn't work. I might get to do some experiments later to confirm exactly what doesn't work, why and how, but right now suffice it to say that sb does nothing but cause the RSP to overwrite nearby data. Eeew.
I replaced my fake sprite renderer with the skeleton of the real one, now it shows lines instead of dots where the sprites should be (a step in the right direction, the next will be colored blocks!) This new version more closely mimicks the NES's internal "temporary sprite buffer" with one of its own that is loaded with the next scanline's sprites. It's also at least twice as fast, despite doing 8 times as much work. Yay!
Set up palette so I can charge right into actual graphics. The coin color in SMB is seen to be blinking. I have the background drawing done (I had it done by default a while ago, but now it has the right color.) SMB currrntly looks like this:
The vertical bars on the left are the palette. You can't see them against the bright background, but there are a few white lines for sprites on the screen. SMB still doesn't run, though...
No, it isn't much as it stands, but when you realize that only the positions of sprites are shown, and that the PPU is running seperately from the CPU in custon ucode on the RSP, maybe it'll mean a little more. This is actually fully playable, you just can't see where the blocks are yet. In case you can't figure it out, here's an explanation:
An interesting side effect (well, something I needed to do to make this work but not really a goal) is that I made the PPU status bits show up in the RSP's signal bits, so it's really easy to set and clear them from either processor. I also used a signal bit (there are 8 of them, so I have 2 left) to indicate when the RSP's copy of the SPRRAM is out of date, so it can know when to DMA the CPU's copy. The CPU does an SPRRAM DMA with the ld and sd instructions (moving 8 bytes at a time is faster) from the RAM location to its local copy of SPRRAM.
My problem was that, when I made any change to the PPU emulator (even just adding a NOP), it wouldn't run or would run erratically. I expect that this was because I was just lucky enough with the old version that the timing was just right and the DMAs were nonconflicting. Now that problem seems to be gone, and I can finally get some more actual emulation done.
On the assembler front, I made a new instruction, watch, that displays a warning when an instruction is assembled at the given PC. This allows me to take the EPC given to me by the excpetion handler and match it up with its assembly source. Before I had to use my really slow debug version, which outputs every line with its PC and offset.
I found out how to hook the pre-NMI from when you press the reset button, (the general exception vector (0x180) is called with bit 12 (0x1000) of the Cause COP0 register set) so I could have some neat effect there later, but right now all I do is break the RSP so that the reset can proceed normally. Actually, now I found that, if I use a breakpoint, the RSP won't restart on reset. If I halt it, however, everything works nicely.
I made use of the RSP's signal bits for the first time today, so I can use them to tell the PPU emulator to start, and report back to the CPU when it is done, for much more accurate synchonization.
I started work on the palette, using BMF's RGB palette ('The only palette slow-roasted to perfection'), yesterday, and I got a nice display of all of the colors, but when I tried to implement it fully I got all sorts of weird problems, which led me to the DMA revision that I mentioned above. It was still giving me trouble today, so I performed a complete palette-ectomy.
On another topic, I have 4 MB of space free on this hard drive. Now that my assembler outputs a 2 MB ROM, I run out of space really quickly. It turns out that I didn't check if there was actually enough space for the finished ROM, so now if there isn't an error is generated.
On yet another topic, I discovered that there is a rather large difference between the sp_wr_len_reg (which gives, approximately, the number of bytes to DMA out of the RSP into DRAM) as seen from the CPU (at 0x0404000c) and as seen from the RSP (at register 3, entrylo1 by my incorrect notation). From the CPU, the actual number of bytes is the value in sp_wr_len_reg, with the low 3 bits masked out, plus 8. On the RSP the low three bits are also masked out, but the 8 is not added. This is probably true for sp_rd_len_reg, too, but I haven't tested it.
I've also been doing more RSP research, and I've now found what the rest of the length DMA register is for...
As I mentioned before, you can have two simultaneous SP DMAs going on (one active, one queued). That's what the DMA_FULL register is for, it tells you when you can't schedule another DMA. When this came into doubt today I performed several experiments that appear to prove that point.
I ported over a ROM loader I wrote for another assembler, and in doing so I fixed an error in my two-part addressing macro, because I didn't realize that the offset was sign extended when I wrote it. This loader doesn't actually setup all of the pointers like it should just yet, but it gets the CHR and PRG-ROM page counts and displays them onscreen, along with the mapper and mirroring types (as text, not just numbers).
I incorporated the exception handler into Neon64, which helped with debugging the above. I also tested the emulator with Arkanoid, which, unlike Solar Wars and SMB, performed perfectly. I'll be starting on the graphics now, so I'll probably be using Arkanoid for that and I'll come back to the others later.
I also found that the write to PPU control register 2 was a load instead of a store. Oops.
I wrote a new 'main emulation loop' and PPU emulator skeleton for Neon64, using a more structured format that I actually planned out first, based roughly on FCEU's main loop. After the change none of my test programs appeared to run any better or worse. SMB loads two sprites and just runs aimlessly, and in Solar Wars everything works pretty well except the projectile jumps around the screen.
FCEU counts three cycles for every one on the 6502, this helps to make its count more accurate since there are 12 PPU cycles to a CPU cycle and a lot of my timing is off by 1/3 or 2/3 or a cycle, which can add up. I might incorporate this into Neon64.
I also may have fixed that register math error that I kept getting in U64ASM.
I also moved a lot of the older news off of this main page, since it's gotten rather large.
I got some info on interrupts from LaC, I think that this will help schedule the audio emulation.
PPU emulation was the main speed problem in the first version of Neon64, so hopefully this will help a lot.
I made a fake sprite renderer that just shows a vertical line where a sprite is, this allowed me to see that Solar Wars is indeed progressing well. There just seems to be a problem with the projectile, it jumps around a lot, I'm not sure if this is normal behavior or not.
I'm going to be away for two weeks, and my computer isn't coming with me. I'll try to write out some plans for the PPU renderer when I find the time.
- That the CPU can only access RSP data in 1 word chunks, reading or writing
- That all word access must be word aligned.
When I did the VRAM page array, I found that you can have at least two simultaneous DMAs to the RSP, something I had previously only suspected.
Well, not truly simultaneous, but I can queue one while the other is still in progress.
I got the 2005/2006 registers emulated, as well as their accompanying V,T, and X registers (as described by loopy).
By the way, the "Backup Often" mantra protects not only against natural disaster, but also your own stupidity. After I wrote the above and got it all working, I stormed ahead to all sorts of other stuff and got myself confused, so I had to revert to my last backed-up working version from last night. That meant that I had to rewrite all of the stuff that I had already done. Oh well.
On another note, I made the $2007 (VRAM I/O) register work, after beating the bugs out of it with a big stick. I still have to get my hands on a good palette...
Solar Wars and SMB are running without graphics, I can select different planets in Solar Wars and so on.
I wrote the skeleton of the PPU emulator and the routines needed to load it to the RSP and reboot it once per frame.
I wrote a lot of the PPU register handlers. I have a basic PPU emulator (without any actual graphical output) working. I got the vblank interrupt working.
My tests with Super Mario Brothers run until a loop that waits for the sprite 0 hit flag to be set, which is good. But Solar Wars crashes, possibly because VRAM isn't properly emulated yet...
I also found out how to detect a reset, so that the N64 doesn't lock up when you press the reset button, waiting for the RSP to break. I might make a cool transition on reset, like Mario 64 has.
Wrote NMI and IRQ interrupts, tested with square root program.
Wrote controller 1 handler, might be a bit different in the final version.
JSR increments the PC, then pushes the PC and loads the new one, then RTS pulls/pops the PC and increments it again, so the PC points to the instruction after the JSR.
There was also an error in the day of week calculation test program, since TASM will assume that LSR without an operand is pointing to zero, while this program used that to mean LSR A.
I made an option to not export a label into a header file (for U64ASM), so I don't have to keep editing codes.h whenever I assemble codes.asm, which contains the opcodes. I assemble this seperately from the rest of the program because it contains the opcodes, which use macros heavily, slowing down assembly by A LOT.
After I test the emulator a little more thoroughly, I will move on to actually loading NES ROM images, the registers, the controller, video, sound, and eventually mappers.
I found several glaring errors in Neon64. The emulated RAM overlapped part of the executable code because of a misplaced 0. The sign and zero flags were frequently not cleared before setting them. These errors were corrected.
I can now use this text routine to start debugging the PPU emulator that I will be writing for the RSP, since I think it would be too complicated to have both the text writer and the PPU emulator running on the RSP, plus I'd probably run out of IMEM to work with (there's only 4K).
I also dumped the DOS extended character set, because I want to use the line characters to draw windows and boxes. I only had the ASCII set before.
No direct work on Neon64 was done during this time.
There are 743 lines of code, not including the opcodes or test programs.
I assembled the opcodes seperately so I just need to include their assembled form rather than reassemble them each time I build Neon64. This and a change I made to U64ASM's binary inclusion means that assembly speed has increased fourfold. That's not terribly important to you, but I felt that I should mention it anyway.
I fixed a problem with my text macros that caused the CPU to try to make the RSP draw a new string before it was done with the old one. The busy flag isn't set fast enough by the RSP, so the CPU now waits for the busy flag to be set before finishing with a text string.
I also got to run some test programs, assembled with TASM. From observing the operation of these programs with my stopwatch, I determined that the emulator is currently running at about 10 Mhz, approximately 6 times faster than the NES's 6502, approximately twice as fast as the last version of Neon64's 6502 emulator.
I fixed an error in the jump table, opcode 0x8E (STX absolute) was listed as STY zero page, a rather large error since those two instructions are different sizes and the high byte of the absolute address will be read as the next opcode, plus it would write to the wrong register.
I added cycle counting to each and every opcode, by hand, today. I also made the jump table but I haven't gotten it to work right yet. There are 1,537 lines in Neon64 so far. I deleted a lot of blank lines in the opcodes, so this number is a little deceptive.
I also edited the drjr send program so it says "Uploading" instead of "Downloading". That had always gotten on my nerves.
I'll be away for the rest of the weekend, so there won't be any more work for a few days.
This evening I also did some work with sound generation on the N64. I expect this will be my weakest point, since the furthest I've ever come in sound programming has been my PC Speaker Zelda Theme. So I wrote a little program that makes a two-tone siren sound (two different frequency sawtooths), and fiddled with it until the clicking went away. It wound up being 90 lines long.
I've already been able to improve the program, the old version of the ADC macro had 19 instructions, some of them branch and load instructions. The n
The new version will have nothing in common with the old one, I am starting from scratch. There are currently 164 lines of code, not counting the I/O functions, which are preassembled. None of this code actually does any emulation yet, but at least it's a start. I wanted to wait until I got my N64 to VGA adaptor box, but its been months since I ordered it and it seems like it will never arrive. Oh well.