Register - Login
Views: 99824072
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies 		05-03-22 07:40:14 PM
Jul - NO! GO TO STAR! - Stereoscopic 3D? New poll - New thread - Thread closed
Pages: 1 2Next newer thread | Next older thread
OzOnE_2k10
Random nobody
Level: 6


Posts: 1/5
EXP: 738
For next: 169

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.1 years
Posted on 05-24-10 08:25:12 PM (last edited by OzOnE_2k10 at 05-24-10 05:37 PM) Link
Hi, all,

I tend to type alot, but I'll just throw all the info out there first then see what you guys / gals think?...

Firstly, I'm constantly amazed at the things that are now possible with ROM editing. It's also very nice to see that the N64 scene is still quite busy.

For a bit of an intro (if you want to read my very boring posts), I've also been helping to make a new PCB layout for the N64. This has been going on for many months though, and only one or two people that I know of have ever attempted to make an actual PCB so far (not me, yet)...

http://benheck.com/forum/viewtopic.php?p=324205#p324205

OK, back on topic - For many years now, I've been toying with the idea of using two N64's for producing the Left / Right eye image (and a pair of LCD shutter glasses) for true stereoscopic 3D. (yep, I'm serious)...

EDIT: I realize that you can already use 3D shutter glasses with PJ64 (not Red / Blue glasses - yuck!), but I'd love to use the real hardware...

The idea is that you use two copies of the same game, but one ROM is kept unpatched (use it for the Left eye for example), and the other ROM is patched so that the camera is shifted and rotated very slightly to produce the image for the Right eye.

This will require a bit of electronics to merge the two images together and output either 120Hz (60Hz per Left / Right image), or Left / Right interlaced 3D format.

120Hz would obviously require VGA output or similar, and the ROMs video tables would need patching for progressive. Interlaced 3D wouldn't be too difficult though.

(controlling the glasses is easy, and I've already built a controller for this.)

The main problem of course is keeping both consoles perfectly in sync, and also routing the PIF responses from the "master" N64 to the slave so that only one set of controllers were used.

I've done some testing on this already, and I had a small amount of success with running two N64's from the same PIF and clock signals. This would work randomly at power-up because the phase of one clock would often "flip" polarity.

When it did work though, I could actually use the controller on the "master" N64 for a while in Goldeneye (until it would freeze). This is due to the clocks still being slightly out-of-phase, so it needs an extra circuit to distribute ONE set of master clocks to both consoles.

Anyway, that comes later (if it will work at all). The reason I posted on here is to ask about how I could patch a ROM so that the camera is permanently shifted sideways very slightly, or the world / model view is rotated slightly to mimic the eye parallax effect so the 3D glasses would work??

I've already tried patching the MESS source so that it shifts the viewport to the left when it reads the matrix from DMEM (most of the text stays in the correct place though). The result is like image below (yes, I know the polygons look bad, but that's a WHOLE other topic. lol)...

http://img80.imageshack.us/img80/4466/marioshiftedozone.jpg

This type of "patch" would only work on an emulator though, so what I really need to know is if it's easy enough to patch the actual ROM itself to shift / rotate the camera? (or modelview / "World")?

Oh, I don't know... Maybe use the extended ROM of Mario perhaps?

I know only the basic stuff about 3D matrix manipulations and my knowledge of C coding isn't amazing, but I guess that this would require the projection matrix to be multiplied by a rotation matrix (unless you can tweak the camera values directly?)

So, a lot of this is theory atm, but I'm sure it could be made to work as long as I can get the consoles to keep sync.

Thanks for reading.
OzOnE.
Tanks

360? Yessum.
Level: 121


Posts: 4038/4170
EXP: 19809589
For next: 247107

Since: 07-10-07

From: VA

Since last post: 9.5 years
Last activity: 9.5 years
Posted on 05-24-10 08:29:23 PM Link
I am amazingly intrigued by this. I'd love to see how this turns out for you. Might have to go dig up my old goggles from 8th grade geology.

____________________
Lyskar
12210
-The Chaos within trumps the Chaos without-
Level: 192


Posts: 5597/12211
EXP: 99325943
For next: 547628

Since: 07-03-07

From: 52-2-88-7

Since last post: 7.4 years
Last activity: 7.3 years
Posted on 05-24-10 08:44:16 PM Link
Stats
Time/Date
05-24-10 02:44:16 PM
Posts
5597
Days Here
1056
Level
109
Metal_Man88's Post
Normally I would shunt this off and say 'post in the project thread, then the help one' but this appears to be a strange combination of new way of editing the ROM to make 3D stuff rather than 'OMGZ MARIO IZ GREEN WITH BLOODSHOT EYEZ' so I'll let it stay.

Especially since the idea is kind of intriguing, though I wonder how you avoid desyncs with both ROMs running at once, especially with things that use RNGs.

____________________
Don't let an old saying get in the way of a good idea.
Eisnaught - SSQ² - Mobius Roleplay - SSS
Sukasa

Level: 123


Posts: 2451/4326
EXP: 20936723
For next: 294543

Since: 07-07-07


Since last post: 1.1 years
Last activity: 1.1 years
Posted on 05-24-10 09:08:10 PM Link

Any RNG is just a simple math equation, so assuming the carts have perfectly identical data there'll be no issue with that since the N64 doesn't keep stuff like a clock, etc.

____________________
<@Bitmap> Be completely humble and gentle;
<@Bitmap> And tell them to shut the fuck up
Xkeeper

Level: 263


Posts: 16413/25353
EXP: 297155448
For next: 1805005

Since: 07-03-07

Pronouns: they/them/????????

Since last post: 3 days
Last activity: 12 hours
Posted on 05-24-10 09:15:35 PM Link
Originally posted by Sukasa
Any RNG is just a simple math equation, so assuming the carts have perfectly identical data there'll be no issue with that since the N64 doesn't keep stuff like a clock, etc.

Wrong. Many RNGs use human input as well to help make the output more chaotic.

This is why luck manipulation in TASes exists.

____________________
Sukasa

Level: 123


Posts: 2452/4326
EXP: 20936723
For next: 294543

Since: 07-07-07


Since last post: 1.1 years
Last activity: 1.1 years
Posted on 05-24-10 09:16:35 PM (last edited by Sukasa at 05-24-10 06:16 PM) Link

Seeing as both games would be getting identical controller input in this scenario, I disregarded that.

____________________
<@Bitmap> Be completely humble and gentle;
<@Bitmap> And tell them to shut the fuck up
OzOnE_2k10
Random nobody
Level: 6


Posts: 2/5
EXP: 738
For next: 169

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.1 years
Posted on 05-24-10 09:39:37 PM Link
Hi,

Actually, I never gave proper thought to the randomness factor. Even it's pseudo-random, it might be random in the practical sense?

The main goal is to make sure that one of the N64's doesn't drop frames though (purely because it will be drawing slightly different data / number of polys).

Also, the PIF request have to stay identical, because it will only work assuming that both consoles request the same PIF command at the same time, but only the master N64's PIF will return the data to the slave RCP (and to itself). Again, the PIF clocks will need to stay in sync, but the same applies to the PIF clock as it does to the RCP hopefully.

The problem with keeping the clocks in sync is due to the use of the PLL chips. It would probably have a chance of working if I could take the clocks from the output side of the master N64's PLL chips and route them to the slave. I tried this though, and it's just dies (wrong impedance etc.) So, the clock outputs will need some buffers, then route them directly to the slave's RCP / RDRAM.

Or, just generate the clocks directly from the FPGA and use resistor dividers for the RDRAM clock (it needs to be a certain voltage / offset). The video / audio clock is just TTL (3.3v level).

I'm hoping the RCP uses a simple clock divider internally to produce the main clock from the Rambus clock (ie. 250MHz / 4 = 62.5Mhz) instead of a PLL. I need to check if both consoles have the same startup time too (that they start up after the same number of clocks when they're brought out of reset).

I'll be able to play with this stuff more in the coming weeks, as I'm buying a much better FPGA kit next week - the same kit as Marshall is using to develop his cool CF card emulator (sorry if this is off-topic, but it might be a news flash for some)...

http://www.youtube.com/watch?v=uYAowmP1OEM

OzOnE.
P.S. Another idea, which WOULD be possible and fairly straightforward: generate four seperate video outputs from one N64 with each output zoomed in to one-quarter of the screen. This would let multiple players use a separate TV for things like Mariokart / Goldeneye etc.
DarkSpacer
Member
Level: 31


Posts: 26/184
EXP: 166009
For next: 19354

Since: 03-23-10


Since last post: 5.7 years
Last activity: 5.0 years
Posted on 05-24-10 10:09:07 PM Link
This would be kind of hard. THe 3D glasses idea I mean, because if you shift the camera over, you MIGHT have one console rendering, say, 30 polygons, and the tilted camera one renders 40 polygons, and 30 polygons, as an example, is the maximum it can render before it slows down. That would mean the 40 polygon camera is moving as a slower frame rate, and it will break the 3D look.

As for the zooming-down-to-1/4-of-the-screen thing...what if you were playing four Mario Karts all with the "All Players Can Be the Same Character" cheat on Vs. on Rainbow Road?

It won't be pretty.
Lyskar
12210
-The Chaos within trumps the Chaos without-
Level: 192


Posts: 5599/12211
EXP: 99325943
For next: 547628

Since: 07-03-07

From: 52-2-88-7

Since last post: 7.4 years
Last activity: 7.3 years
Posted on 05-24-10 10:14:54 PM Link
Stats
Time/Date
05-24-10 04:14:54 PM
Posts
5599
Days Here
1056
Level
109
Metal_Man88's Post
Hm, yeah, the only way to keep them even would be to, like, force it to render offscreen polygons and always render the same amount of polygons... sounds messy.

____________________
Don't let an old saying get in the way of a good idea.
Eisnaught - SSQ² - Mobius Roleplay - SSS
OzOnE_2k10
Random nobody
Level: 6


Posts: 3/5
EXP: 738
For next: 169

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.1 years
Posted on 05-24-10 10:33:31 PM Link
"All Players Can Be the Same Character". lol

I suppose it wouldn't be much fun, but it would be nice to see, and would at least stop people peeking at your play screen to see where you are. (Damn, I hated that on Perfect Dark back in the day).
Or, you could just use cardboard on the TV instead.

Yep, the slow-down problem is the big show stopper for the 3D idea. Not only will it drop a frame and go out of sync, but the CPU will also halt while it's waiting for the RDP to finish drawing.
That then would mess up the rest of the sync and the slave console would probably crash. The master console should keep on playing, because it would be in full control of the PIF etc.

An easier thing to test is to just convert some homebrew code to output stereo 3D. Although, with only arround 30Hz per eye, it would flicker like hell. Could do interlaced maybe?

I'll keep working on it though. You might tell from my posts on benheck and dextrose that I'm quite determined...

We're getting quite close to building an N64 portable with a built-in CF card slot. Hopefully, it will have some other goodies, like: RGB output from any generic N64 chipset, auto PIF code switching for NTSC / PAL ROMs, and save-game management to and from CF etc.

OzOnE.
Joe
Common spammer
🍬
Level: 111


Posts: 1357/3392
EXP: 14501867
For next: 366493

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 2 sec.
Posted on 05-25-10 12:01:36 AM Link
To heck with RGB output, may as well rig it up to DVI.

Actually, I'd like to do that myself but I have no idea where to begin. I know a decent amount about the various signal protocols that would require, but I have no idea what kind of FPGA to use (or how I would assemble it without access to soldering tools).

____________________
fin
DarkSpacer
Member
Level: 31


Posts: 27/184
EXP: 166009
For next: 19354

Since: 03-23-10


Since last post: 5.7 years
Last activity: 5.0 years
Posted on 05-25-10 12:08:21 AM (last edited by DarkSpacer at 05-24-10 09:14 PM) Link
I meant it would be 16 screens on the same TV, and 16 of the same player, on a course where much of the track looks the same. I'd just hope to God I'll remember who I am

Edit: oopsie I meant to add all the games are in four player mode too. Oh well, It still won't be pretty.
messiaen
Catgirl
Level: 68


Posts: 867/1085
EXP: 2596465
For next: 132335

Since: 11-20-07


Since last post: 8.1 years
Last activity: 7.2 years
Posted on 05-25-10 02:54:06 AM Link
Unfortunately, we don't know that much yet about the camera on SM64. There are multiple camera settings and structs, and sometimes the game shifts between different cameras (each with their particular settings) so a LOT of code would have to be rewritten (which could maybe increase the sync problems?).

My bet is that you should look at some of the gu (Graphical Utilities) UltraLib functions (guPerspective and guPerspectiveF may perhaps give you some control about what you're looking for). I know very little about actual N64 programming, so perhaps Marshall could give you some help on this.

One thing you should definetely check is Nagra's Mario Resource (you can find it at the Dextrose forum), which may help you navigate through the game code. There's also a master.cod file included which lists address for some of the UltraLib gu functions.
OzOnE_2k10
Random nobody
Level: 6


Posts: 4/5
EXP: 738
For next: 169

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.1 years
Posted on 05-25-10 09:23:20 PM (last edited by OzOnE_2k10 at 05-25-10 06:51 PM) Link
Damn it! (sorry). I just clicked on the stupid favorites bar by accident, and wiped out my original post (don't you hate it when that happens - should have used Notepad instead).

I'll try again.

I looked into the Ultra 64 libraries and found the guPerspective / memmove / matrix stuff, but I have no idea how to find these in the actual ROM assembly? I also didn't have much luck trying to find Nagra's resource on the Interweb (is Dextrose dead now? I know it used to be dextrose-forum(s)?). From what I recall, the "master.cod" file worked with IDA Pro... I have a copy of that, so I'll try to find Nagra's resource. I know I downloaded it months ago, so it must be on this PC somewhere (hiding amongst 30,000 files).

As for the 3D sync stuff - I tidied up the wiring a lot last night (using shorter power wires and short sheilded coax for the clocks). I'm now using a PC PSU as well - I didn't realize the N64's need around 2 Amps EACH (with expansion paks), and I was trying to run both console from one N64 PSU originally!!

I managed to get the slave console running from the master console's Rambus clock. The problem is, as soon as you plug the jumper pak into the master console, the slave crashes / won't boot. The reason for this is due to the fussy Rambus voltage levels...

The Rambus RSL signalling protocol uses very small voltage swings for the logic (around 0.6V). The higher voltage level on the N64 is VTERM (around 2.56v). VREF is low level for the logic, and is around 1.9V.
The clock is biased at around 1.7V normally, but when you plug the expansion pak into the master console, the resistances / impedances of both console is paralleled. This halves the resistance, and the clock offset rises to around 2.2V!! This obviously kills the Rambus communication on both consoles.

So, it will need either a simple potentiometer to adjust the offset so the clock bias is around 1.7V when both consoles are connected, or it might require a buffer, which will take a while for me to put together. phew.

I actually tried outputting HDMI from an N64 a few months back. I used an FPGA and wrote some code to convert from the RCP output format to bt.656 (the type of digital video protocol used in most DVD players and sat boxes etc.). The HDMI chip was on a board from a cheap Sumvision HDMI upscaling DVD player (I bought 10 broken players very cheap on eBay and got 6 working)...

It did get some scrambled N64 image on the monitor, but it was kind of garbaged horizontal lines. I'm 99% sure this is because the N64 outputs interlaced, and the HDMI chip expects progressive. I couldn't find a proper datasheet for the chip though, and my crappy FPGA board doesn't have the required SRAM / DRAM for doing the interlaced-to-prog conversion. I might into this again in the coming weeks after I've bought the new Altera kit.

My first mission is to get some new N64 PCBs made though....

http://forums.benheck.com/viewtopic.php?f=5&t=32430&start=420

A more modular concept is a much better idea, and means that I might at least get a small N64 board made first, then get the cart emu done after (with help from Marshall and Kibble hopefully).

OzOnE.
P.S. I will still very much be soldering and testing the 3D stuff too.
messiaen
Catgirl
Level: 68


Posts: 869/1085
EXP: 2596465
For next: 132335

Since: 11-20-07


Since last post: 8.1 years
Last activity: 7.2 years
Posted on 05-25-10 10:57:15 PM Link
Damn, dextrose-forum.com (I think that was the domain after the last move) seems to be down. It would be a real shame if nobody archived the forums/tools there.

If you don't find your master.cod file, you can use this version of IDA PRO (UltraLib signature files included). Just load a savestate of whatever version of Mario 64 you are using and it should find most UltraLib functions.

If you are using the US 1.0 version, here are addresses of gu functions from Nagra's master.cod file:

0x80324c20,guOrthoF
0x80324d74,guFrustum
0x80324de0,guPerspectiveF
0x80325010,guPerspective
0x803258d0,guRotateRPYF
0x80325924,guRotateRPY
0x80329450,guMtxF2L
0x80329550,guMtxIdentF

Nemu can be quite handy if you want to test doing some changes or check how these functions are called.
Joe
Common spammer
🍬
Level: 111


Posts: 1358/3392
EXP: 14501867
For next: 366493

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 2 sec.
Posted on 05-25-10 11:10:01 PM Link
Originally posted by OzOnE_2k10
I actually tried outputting HDMI from an N64 a few months back. I used an FPGA and wrote some code to convert from the RCP output format to bt.656 (the type of digital video protocol used in most DVD players and sat boxes etc.). The HDMI chip was on a board from a cheap Sumvision HDMI upscaling DVD player (I bought 10 broken players very cheap on eBay and got 6 working)...

It did get some scrambled N64 image on the monitor, but it was kind of garbaged horizontal lines. I'm 99% sure this is because the N64 outputs interlaced, and the HDMI chip expects progressive. I couldn't find a proper datasheet for the chip though, and my crappy FPGA board doesn't have the required SRAM / DRAM for doing the interlaced-to-prog conversion. I might into this again in the coming weeks after I've bought the new Altera kit.
Actually, interlacing is an option of the game. Most of the games I own only do progressive, and one of the few that does interlaced (Star Wars Episode 1 Racer) switches to progressive on occasion.

Besides that, I've read through the HDMI specs and both 240p and 288p are legal resolutions. You can look here and see for yourself. (Sections 6.3 and 6.4, on pages 87-88, are of particular interest.)

I'm plenty willing to help you out however I can.

____________________
fin
OzOnE_2k10
Random nobody
Level: 6


Posts: 5/5
EXP: 738
For next: 169

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.1 years
Posted on 05-25-10 11:29:53 PM Link
Thanks for that Messiaen. I should be able to hunt down something with the sig file (gonna be a long night).

It seems that Dextrose has been down for a few weeks now. I hope it's not gone for good.

Joe, I'm a bit confused tbh... AFAIK, the N64 games have only ever output interlaced? By definition, standard composite / RGB outputs are always interlaced.
Do some N64 games have an interlaced option? If so, that would only imply that the framebuffer was updated in a different way, but I've never seen an N64 output progressive before?

I'm sure there are plenty of HDMI chips out there which would take the signal from the N64 (once converted by the FPGA) and output to standard 480p (maybe even upscale for what it's worth).
The huge problem for me has always been 1. Do the PCB layout and Getting proper PCBs made, and 2. Finding the datasheets for the more obscure chips.

Although I'm very fussy when it comes to picture and sound quality (I'm THX certified, and also build audiophile stuff), I think RGB would be fine on the N64 since the resolution isn't exactly high enough to warrant HDMI tbh. It should be easy enough to output VGA though (Horiz and Vert sync is available on the N64), but the ROMs would need patching for progressive.


OzOnE.
Joe
Common spammer
🍬
Level: 111


Posts: 1359/3392
EXP: 14501867
For next: 366493

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 2 sec.
Posted on 05-26-10 02:43:19 AM Link
Originally posted by OzOnE_2k10
Joe, I'm a bit confused tbh... AFAIK, the N64 games have only ever output interlaced? By definition, standard composite / RGB outputs are always interlaced.
By definition, yes, but Nintendo still built the NES, SNES, and N64 to output progressive video.
Originally posted by OzOnE_2k10
Do some N64 games have an interlaced option? If so, that would only imply that the framebuffer was updated in a different way, but I've never seen an N64 output progressive before?
More likely you've never seen a N64 output interlaced before. Of the 19 games I have, two output interlaced: Pokemon Stadium 2 and Star Wars Episode 1 Racer. (The Star Wars game is not always interlaced; it will often switch to progressive.)
Originally posted by OzOnE_2k10
I'm sure there are plenty of HDMI chips out there which would take the signal from the N64 (once converted by the FPGA) and output to standard 480p (maybe even upscale for what it's worth).
Isn't 480i a standard too? HDMI allows the video signals from the N64 to be passed through directly, with nothing more than a pixel doubler. The N64's digital signal could be converted to HDMI on the FPGA and then passed off to an output amplifier.
Originally posted by OzOnE_2k10
The huge problem for me has always been 1. Do the PCB layout and Getting proper PCBs made, and 2. Finding the datasheets for the more obscure chips.
If the HDMI processing is done on the FPGA, you could probably simplify your PCB design. For that to work, it would be best to check if your FPGA is fast enough for HDMI at 480i. (That will also cover the more common 240p.)
Originally posted by OzOnE_2k10
Although I'm very fussy when it comes to picture and sound quality (I'm THX certified, and also build audiophile stuff), I think RGB would be fine on the N64 since the resolution isn't exactly high enough to warrant HDMI tbh. It should be easy enough to output VGA though (Horiz and Vert sync is available on the N64), but the ROMs would need patching for progressive.
- Digital displays frequently assume "standard" RGB/composite/what-have-you is always interlaced, and postprocess to that effect. Said postprocessing destroys progressive video.
- RGB isn't even an option here in North America.
- HDMI directly supports the resolutions the N64 is capable of. VGA would require scan rate conversion.
- Any games that use interlaced video do so because it allows for higher-resolution graphics. Patching games for progressive display completely defeats that.
- There are chips that will convert the digital audio signals from the N64 directly to S/PDIF.

I would love to build an HDMI converter myself, but I have no experience and no idea where to start. (And no soldering tools. And no money.)

____________________
fin
Rena
I had one (1) message in Discord deleted and proceeded to make a huge, huge mess about how it was a violation of free speech and how moderators are supposed to be spam janitors and nobody should have the right to tell me not to talk about school shootings
Level: 135


Posts: 3287/5390
EXP: 29076970
For next: 258035

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 342 days
Last activity: 342 days
Posted on 06-01-10 05:51:38 AM Link
06-01-10 12:51:38 AM
Post #3287
Hm, instead of trying to keep two different scenes precisely in sync, could you overclock one console to squeeze 120hz out of it? Then you'd probably just need to hack the main game loop to render each frame twice, with the second's camera adjusted slightly. There was a Chinese N64 (official, but very different) that ran at double speed and the games just went faster with no issues.

BTW I'm very interested in building an N64 cartridge emulator and getting VGA/HDMI output from one. (Digital sound would be neat too. )

____________________


[loading witty comment...]
why not?
Joe
Common spammer
🍬
Level: 111


Posts: 1370/3392
EXP: 14501867
For next: 366493

Since: 08-02-07

From: Pororoca

Since last post: 12 days
Last activity: 2 sec.
Posted on 06-03-10 12:55:04 AM Link
Originally posted by HyperHacker
There was a Chinese N64 (official, but very different) that ran at double speed and the games just went faster with no issues.
I find that to be a rather dubious claim, although the best I have to go off of is a promotional video from the official website.
Originally posted by HyperHacker
BTW I'm very interested in building an N64 cartridge emulator and getting VGA/HDMI output from one. (Digital sound would be neat too. )
I'd be glad to help you with that, although I'd much rather build them myself.

____________________
fin
Pages: 1 2Next newer thread | Next older thread
Jul - NO! GO TO STAR! - Stereoscopic 3D? New poll - New thread - Thread closed


Rusted Logic

Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

33 database queries, 10 query cache hits.
Query execution time: 0.099984 seconds
Script execution time: 0.045911 seconds
Total render time: 0.145895 seconds