Menu
What's new
By:
Filters

Announcement: Cycle-accurate N64 development underway.

F

Fanatic 64

Guest
MarathonMan said:
Unfortunately, yes. Wasn't saving $pc to $epc when an interrupt was raised.
Click to expand...
Wow, I don't know a **** about programming and yet I can very well imagine how dumb is that.

Good thing you fixed it, trough. I'm looking forward to see this progress.

(Although I probably wont be able to use it to run Super Mario 64 hacks, since they just give a black screen on the real N64 (M64 ROM Extender's fault I heard)).
 
OP
MarathonMan

MarathonMan

Emulator Developer
Fixed another couple of show-stopping bugs... had to make some major changes to the VR4300 pipeline in order to properly handle faults. Basically, when an exception is raised (external or not), the processor doesn't actually jump to the exception vector until, in some cases, many cycles later. This is largely due to the fact that MIPS promises to deliver precise interrupts. If the RSP throws an interrupt at cycle N, for example, the exception vector jump actually occurs at cycle N+3, and writes from all instructions prior to the interrupt are discarded. Took me awhile to figure out how the processor was actually handling this and implement it correctly.

Lecturing aside, 'pong' by Omar boots and gets all the way up to the title screen. I have confirmed that the VR4300 is writing into the frame buffer, and the PIF is sitting around and waiting for input. :). As soon as I actually make the effort to get an OpenGL window on the screen and dump the framebuffer into a window, ROMs that don't require the RSP to run will produce graphics.

OTOH, commercial games are also booting, but there's some issue with DMA-ing/handshaking between the two cores. SM64 and Zelda (the only two commercials ROMs that I own ATM), boot and start executing, but not long after the RSP is given control for the third or so time, the simulator dies due to a bug in the RSP DMA process. After I get that kicking, and barring how many unimplemented instructions I run into, I should be able to get commercial ROMs doing something soon as well.

Cheers! :n64:
 
Z

Zuzma

New member
Apparently Namco Museum 64 doesn't use the RSP or the RDP either. Might be more interesting to use then some homebrew roms for testing.
 
Last edited:
F

Fanatic 64

Guest
I'll wait to see some actual screenshots, then I'll be impressed. Good job so far!
 
F

Fanatic 64

Guest
Well, congraturations!!!

But... I guess it isn't supposed to have that black pixel grid, right?
 
OP
MarathonMan

MarathonMan

Emulator Developer
Zuzma said:
The ball is invisible silly. You have to use your inner chi to sense where it is on the screen. Or maybe it's the fact that the emulator isn't complete yet and he's just showing us an early work in progress shot. :p
Click to expand...

Nah, just hadn't started the game yet... trolls gonna' troll though.

Cycle-Accurate Emulator Nintendo 64, at least I think.
Click to expand...

This.
 
Quvack

Quvack

Member
Well done MarathonMan :) must be nice to see some video output rather than just the debugging side of things!
 
OP
MarathonMan

MarathonMan

Emulator Developer

Attachments

  • pong.png
    pong.png
    35 KB · Views: 205
  • pongball.png
    pongball.png
    32.3 KB · Views: 216
squall_leonhart

squall_leonhart

The Great Gunblade Wielder
i thought it was 555 with 1bit luminance for each channel.

though i think i asked mudlord that once and he said no...... memory sucks :<

dug it up, im wrong

The "15-bit" mode in the N64 maintains 18 bits in RDRAM. The 2 extra bits RDRAM provides (RDRAM is 9-bit instead of 8-bit, so you have 18 bits instead of 16 when paired) are combined with one bit from the 16 "normal" bits to give 3 alpha bits for the frame buffer. The programmer cannot directly access those bits - you only have 5551 and 4444 textures; the RDP uses the bits itself as it renders to give better transparency effects for 15-bit mode.

That is not the same as the 18-bit palette in VGA cards - 18-bit VGA colors are 666; that is, six bits per color, and no alpha (VGA never had an alpha channel). The N64 15-bit mode is 555 for the RGB; that is, five bits per color. The extra bits are ONLY for computed alpha, not color.
Click to expand...

http://www.sega-16.com/forum/showth...nsole-hardware&p=423451&viewfull=1#post423451

I think Jabo's plugin is the only one that does the computed alpha properly, not even Glide64 does it, and the Nintendo logo's use this to give more sheen ... hence why it looks duller.
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
squall_leonhart said:
i thought it was 555 with 1bit luminance for each channel.

though i think i asked mudlord that once and he said no...... memory sucks :<

dug it up, im wrong



http://www.sega-16.com/forum/showth...nsole-hardware&p=423451&viewfull=1#post423451

I think Jabo's plugin is the only one that does the computed alpha properly, not even Glide64 does it, and the Nintendo logo's use this to give more sheen ... hence why it looks duller.
Click to expand...

Excellent find, much thanks! That makes perfect sense. They really did use every little last piece of the hardware in this thing... back to the drawing board.
 
You must log in or register to reply here.

Top