Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 05:42:47 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsMy graphics journey with the N64
Pages: 1 2 3 [4] 5 6
Print
Author Topic: My graphics journey with the N64  (Read 22007 times)
deadcast
Level 0
***



View Profile WWW
« Reply #60 on: April 17, 2015, 11:55:06 PM »

I'm amazed man, this is totally crazy xD. Following for sure

Thanks much! =D

Just a question... what were you doing before? I mean using the RDP without setting it up. I don't think it can run without microcode? Were you just using whatever was there before? (also IIRC real hardware has some firmware, since it can't run code directly from cartridge, but no idea if it does any initialization beyond copying boot code to RAM)

Before I was just directly writing to the RDP via libdragon. The RSP is the only one that deals with microcode that acts on display list data to prepare for the RDP. To be able to render a triangle like I did, I followed the data chart for the non-shaded triangle rendering from one of the Nintendo patents. The patent actually displayed some useful info. Smiley So it's possible to just totally bypass the RSP and communicate directly to the RDP but you'll end up losing performance in the end since the CPU will now be held up by computing data for rendering instead of the RSP. Also the CPU isn't optimized for doing 3D math and can't access that RAM as fast, I believe. Heck you could even write directly to the video output/audio output if you wanted to and just bypass the co-processors all together! lol

I do believe there is some firmware that is loaded onto the DMA controller upon boot that transfers the ROM data into RDRAM to kick things off. I think it utilizes the first 4K bytes(header) in the cart ROM or something. Still learning about all the innards of the system. :p

Posting to follow, will be interesting to see how this progresses.

Thanks! Yeah I'm really interested as well to see where this is going. Smiley

I wanted to say it's awesome you're doing this.

I might jump into experimenting with N64 dev in the future during a weekend or game jam to take a short break from my game.

I worked as a C developer professionally for a few years; so hopefully the ramp-up would be slightly less terrifying, ha.

Also, have you RTFM? Tears of Joy

Thanks! Yeah for sure start messing around with the system. I'm not too sure it's suitable for a game jam just yet since the tools are pretty bare metal'ish and it can take a long time to get a working environment. I guess it depends on what you wanted to build. Having experience in C will definitely make things easier for you. The hard part is getting used to addressing memory and working heavily with hex/bits. I'm more used to working in higher, abstracted languages. Smiley Also yeah I actually have read most of that manual lol. Pretty interesting read!

------------------------------------

Hello once again everyone! Feels like I haven't updated this in awhile. ;-; I've been really busy with work since I got a new contract job. My main job is building web apps. Much different than game stuff. Smiley It's good because I get monies but bad that my side projects get way behind. Oh well I knew this project would take time.....

I'm writing this update on my new setup running Arch Linux. Whoa has that been difficult! It's forced me to get much better at the command line and learn to live there. Everything from installing/compiling/running is done from the terminal. I look at README files much differently now. lol

Anyway, I successfully got my n64 dev environment setup! I was able to finally compile the n64tool-toolchain because I'm running on Linux and didn't have to cross compile! Also got my editor setup which is Emacs. Quite the change from VS in windows but I'm adapting.

I haven't made any progress on the n64 yet but at least tonight I was able to compile the tools to send ROM data once again to my 64 drive. =D I think my first goal will be to get a VERY simple program running on the RSP. Like just loop forever or something. That will be a little tricky since I need to setup a debug tool to spy on what's going on inside the RSP. Luckily I'm going to be using Cen64 which I do believe has a debugger. Sometimes I feel like all of this is so overwhelming but I can't give up yet.

Thanks for all of your support so far and I hope to eventually find time to start doing work on the n64. It just took so dang long to setup my new new env! Sorry no photos this time. Just a text wall. Smiley
Logged
deadcast
Level 0
***



View Profile WWW
« Reply #61 on: May 03, 2015, 11:19:22 PM »



Feels weird being back on here. Been so occupied with other things but I managed to do some work on this project again. Smiley I've been making VERY VERY small baby steps since this stuff has been a little intense. I was able today to actually get a response back from the cen64 emulator saying that the RSP command I was trying to execute was incorrect. Great news!



I was super excited to see this because I now knew my code had activated the DMA controller to start moving things into the RSP and then it started to complain. :D I'm just happy to see something.

I did run into a totally over looked problem when I attempted to compile some inline assembly using a MIPS r4000 instruction op. The compiler barked back saying the current arch I'm targeting does not support the opcode I was running inline. I'm targeting a VR4300 CPU so obviously RSP opcodes won't compile(I think?). So what I'm researching now is how to compile a custom build of GCC to target a MIPS II R4000 arch. If I can ever get that solved I'll then be back to trying to compile a simple microcode object with which I could then link to the other target's project. Not too sure yet how to access the compiled microcode's function address so I can load it into the RSP's IMEM. Blah so many things and nothing fun to look at. Sad

I hope this made some sense and I need to go to sleep. Thanks for stopping by.
Logged
lithander
Level 3
***


View Profile WWW
« Reply #62 on: May 03, 2015, 11:57:28 PM »


Here's the original source of the "black triangles" idiom: http://rampantgames.com/blog/?p=7745
Logged

gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #63 on: May 04, 2015, 08:46:24 AM »

cool!
Logged

deadcast
Level 0
***



View Profile WWW
« Reply #64 on: May 04, 2015, 11:56:02 AM »


That was really great! Thanks for sharing. Drawing a black triangle on the screen is definitely something I'm looking forward to doing someday. Smiley Maybe print it out even. lol
Logged
Sik
Level 10
*****


View Profile WWW
« Reply #65 on: May 05, 2015, 12:48:48 PM »

I did run into a totally over looked problem when I attempted to compile some inline assembly using a MIPS r4000 instruction op. The compiler barked back saying the current arch I'm targeting does not support the opcode I was running inline. I'm targeting a VR4300 CPU so obviously RSP opcodes won't compile(I think?). So what I'm researching now is how to compile a custom build of GCC to target a MIPS II R4000 arch. If I can ever get that solved I'll then be back to trying to compile a simple microcode object with which I could then link to the other target's project. Not too sure yet how to access the compiled microcode's function address so I can load it into the RSP's IMEM. Blah so many things and nothing fun to look at. Sad

Honestly I imagine a macro to generate the opcode from raw bytes would be probably easier, although I'm not sure how feasible is that (and if GCC would like it).
Logged
Flatgub
Level 0
***


My existence is questionable at best


View Profile
« Reply #66 on: May 06, 2015, 01:02:23 AM »

This is very interesting and exciting, so I definately be following this! Smiley
Logged

Octopus Tophat
Level 1
*



View Profile
« Reply #67 on: July 25, 2015, 04:53:54 PM »

How's things, pal?
Logged

Roguelike platformer: RogueWorld
deadcast
Level 0
***



View Profile WWW
« Reply #68 on: July 27, 2015, 09:14:57 PM »

How's things, pal?

Hey!

Things have not been going well lately in life. Been dealing with bad anxiety/depression problems and other life issues. :/ I think I'm starting to do better now though. Been really distracted and feeling dead. No motivation to do anything. I feel really bad that I haven't been making any progress on this N64 thing. I actually just started thinking about this project again today and getting a little motivation to work on it! :-) Trying to plan out right now what direction to take this project. I love the N64 and still want to make something for it. Thanks for checking in! I hope I can share something new soon and get my life back to normal. Smiley
Logged
Sik
Level 10
*****


View Profile WWW
« Reply #69 on: July 27, 2015, 09:18:24 PM »

If you're afraid that the project may end up dead or something, you may consider writing down as much as possible what you learned from programming the hardware (quirks included, actually especially them) so others can use the documentation (either for homebrew or emulation).
Logged
Octopus Tophat
Level 1
*



View Profile
« Reply #70 on: July 27, 2015, 09:26:47 PM »

How's things, pal?

Hey!

Things have not been going well lately in life. Been dealing with bad anxiety/depression problems and other life issues. :/ I think I'm starting to do better now though. Been really distracted and feeling dead. No motivation to do anything. I feel really bad that I haven't been making any progress on this N64 thing. I actually just started thinking about this project again today and getting a little motivation to work on it! :-) Trying to plan out right now what direction to take this project. I love the N64 and still want to make something for it. Thanks for checking in! I hope I can share something new soon and get my life back to normal. Smiley
Sorry to hear you're not doing so well  Sad
But it's good to know you're still thinking about it, and getting your motivation back!
I hope you get better soon!  Beer!
Logged

Roguelike platformer: RogueWorld
deadcast
Level 0
***



View Profile WWW
« Reply #71 on: November 04, 2015, 02:43:23 PM »



Hey everyone!

It has been a long time since I posted any updates about my development journey with the Nintendo 64. I started out with the very naive idea of wanting to build some sort of very primitive graphics engine for the console but I quickly found out how difficult that idea would be to actually carry out. Since I failed to achieve my original goals, I thought that I should write about my process behind my learning about the console and the simple development that I managed to pull off. I hope that maybe this review can help others who are more skilled and are more persistent than I to create new content for the cherished and first truly 64 bit system. Sorry Jaguar (http://www.giantbomb.com/jaguar/3045-28/), I’m not so sure that two 32 bit processors working in tandem counts as 64 bit computations (I could be wrong though!). Also note, I’m not a hardware or emulation expert! What I say is based off of my limited knowledge and I may not end up explaining something correctly. If you spot anything that is wrong please let me know! I want this write up to be as accurate as possible.

When I started my development path for the N64 I first concluded that I needed some sort of device that would allow me to play new programs developed for the console. After some searching I quickly found the 64drive created by Marshall (http://64drive.retroactive.be/index.php). The dev cart works great and is the only true way to know if your new ROM actually works. Don’t just trust emulation. I learned the hard way...



While I was waiting for dev cart to arrive in the mail I thought it would be a good idea to also have a good emulator to test on. I figured I’d do most development on an emulator for speed and then occasionally upload to the actual system. I used the MESS emulator (http://mamedev.org/release.html) and compiled it from source since I desired to do development on a Mac. I wanted to work in a more Linux based environment in case I needed to keep compiling tools found online. I seem to always have difficulty compiling for Windows but I find Linux based OS’s to be much, much easier to build on.

After I got the emulator built, I then started searching for some sort of SDK someone may have created. I knew there was no way I could begin from COMPLETE scratch due to my reverse engineering skills being nil. I came across libdragon (https://github.com/DragonMinded/libdragon) and it was exactly what I was looking for at the time. It can render sprites, play audio (with some patching), handle input but it couldn’t yet draw hardware based triangles. That bummed me a little since my intention from the beginning was to make some sort of 3D application. I could have easily just drawn triangles using only the CPU (Central Processing Unit) and VI (Video Interface) but I wanted to utilize the hardware accelerated capabilities of the N64. So due to this predicament I decided “Hey, why not try and implement hardware rendered triangle support in libdragon!” With that idea I began to seek out knowledge of the internals of the N64 and learn some of its mysteries.

Scouring the web for many, many hours I found patents which contained some very interesting information on how triangle rendering is carried out. One of the patents that was very helpful was patent US 6239810 B1 titled “High performance low cost video game system with coprocessor providing high speed efficient 3D graphics and digital audio signal processing” (https://www.google.com/patents/US6239810?dq=US+6239810+B1&hl=en&sa=X&ved=0CB0Q6AEwAGoVChMI3K_JjPn1yAIVCD6ICh2wRATM)

After reading, well more like skimming, I came across opcodes that are used in the rendering process. There are many ones that the N64 supports but the one that was of most importance to me was the triangle drawing opcodes. Upon discovering those, they didn’t make any sense at all. Everything was very cryptic to me but I thought that things may become more clear if I was to study the libdragon source code and figure out how to translate all of this alien information into something meaningful. To my relief, the author of libdragon had already implemented some functionality that used some of the opcodes I read about. So using the code in libdragon that already implemented some of the opcodes, I used that as a reference for my triangle rendering implementation. Before I go into how data should be prepared and transferred to the hardware renderer I should discuss a little about the how the N64 actually draws things.



The console consist of a VI (Video Interface) and most importantly the RCP or the Reality Co-Processor. The RCP is a very special piece of hardware that consist of two microprocessors: the RDP and the RSP. The RSP (Reality Signal Processor) is responsible for doing graphics and sound processing. It does things like lighting, matrix and perspective calculations among other operations. Once it completes a particular calculation say for example getting ready to draw a rectangle, that information is then transferred to the RDP or the Reality Display Processor. Commands have to be sent in precisely the right way or you'll get garbage on the screen or nothing. Also worth noting, things are transferred between the two microprocessors via DMA or Direct Memory Access. So the RSP once done computing something to draw, transfers that data into the RDRAM (Rambus DRAM) and then tells the RDP to read certain registers with special data ready just for the RDP to read. The memory system also is accessible by all components on the system. Nintendo designed it this way in order to have developers have the most flexibility on how they wanted to utilize the whopping 4k of available memory! If you want to learn further about this, there are some confidential Nintendo documents floating around online that can explain MUCH more in depth. I'll leave that up to you to find it though since it's not entirely legal for me to share. Wink

Back to the RDP. Once the RDP has read in the data prepared by the RSP it then is responsible for preparing the video signal information to be sent to the VI. The RDPs only responsibility is rasterization. The output from the RDP will eventually be converted to analog signals for the TV via the digital to analog converter (DAC) onboard the system. Now since I didn't want to mess with doing things “The Right Way”, like having the RSP prepare the Graphics Binary Interface (GBI) commands for the RDP, I decided to bypass the RSP and just write directly to the RDP. This is what libdragon was already doing. That made things much easier in some way but proved a little difficult when wanting to render a triangle because I had to do calculations normally reserved for the RSP.



Moving forward I studied the patent and began piecing together how to prepare the data that needed to be sent to render a triangle. I eventually after many days of tracing through emulator code and fumbling around with bit packing, wrote the “correct” code in order to achieve this and you can see the finished code here: https://github.com/DragonMinded/libdragon/commit/d9fd4f88cfeba137f981c070148dac71a09707b0.

To my surprise the author of libdragon accepted my new triangle rendering code into the library! So you can begin drawing triangles now and not have to worry about all that RSP/RDP stuff but note however that my code only supports flat colored rendered triangles. I wasn't brave enough to tackle textured triangles just yet.



Once getting some beautiful triangles bouncing around on my little LCD TV (you can see the code I used here https://github.com/calebhc/nEgg/blob/59dd9548c1d9527d1d547c53d6537238bf5cdaf0/nEgg.c
) I started to feel a bit guilty of my implementation. Nintendo had reasons, or more namely Silicon Graphics Inc, for designing the RSP and not using it felt bothersome. I could have easily implemented all of the 3D graphics mathematics using only the CPU, which if you're curious it's a MIPS based NEC VR4300, but that would end to sluggish performance. The CPU was designed to just pass the ROM data around and handle other things such as player input. So from there I set out to do things the correct way and utilize the RSP.

To my surprise, or lack thereof, this turned out to be much more difficult and eventually made me throw in the towel. I learned that the RSP runs little programs written in what they call microcode. Microcode is just fancy marketing speak for programs written in custom MIPS based assembly. The microcode programs sort of remind me of GPU shaders. Nintendo/SGI wrote a bunch of microcode programs that licensed developers could use to draw 3D scenes but figuring out how to construct brand new programs without any documentation was proving to be very difficult. I found the official, compiled Nintendo microcode programs but I wanted to understand and create new ones.

I managed to find an actual microcode program in its uncompiled state but it wasn’t very helpful in figuring out how to write a new one. I wanted to push the triangle preparation code I was doing on the CPU into the RSP where I could take advantage of vector arithmetic operation optimizations since the RSP was designed to handle 3D mathematics quickly.

I later learned about the #n64dev channel on IRC and jumped on to talk to any experienced N64 devs. I met Krom and discovered his wonderful test suite of programs for the N64 (https://github.com/PeterLemon/N64). He even wrote new microcode to render some points in perspective! I enjoyed traversing through all of the assembly code but I really wanted to write new ROMs in C and keep the assembly to a minimum. This is where things got really weird. I knew that you can only write new RSP code in assembly and the opcodes it uses are not actually standard but custom for the microprocessor. So I couldn’t just study some MIPS datasheet available online. Krom got around this by emulating what the custom opcode commands should do via macros. That was great to have the macros available but how was I going to write microcode in assembly and then link it into my C code? It was just too beyond me so I decided to take a break.



Months later the author of the CEN64 emulator (https://github.com/tj90241/cen64) started doing exactly what I sought out to do (https://github.com/tj90241/n64chain)! He is using Krom’s test code (https://github.com/PeterLemon/N64) to actually start writing new RSP code in a C based project. Seeing how he figured out what I was trying to achieve was great! Now only if I had the motivation to build off of his work but alas that’s where my problem lies. No motivation right now to continue further but perhaps someday.

This feels a bit abrupt but that pretty much sums up my journey with the N64. It was a very interesting ride and the most work I’ve ever done with an old system. Getting to spend hours digging around the MESS source code was very humbling. The amount of complexity in emulating integrated circuits is incredible. I’m glad other people can actually figure that stuff out! I’ve attached additional links at the bottom that you can check out if you want to know more about all things N64. Again I’m not an expert on hardware and emulation so sorry if I wrote about something incorrectly.

Thanks for reading and all of the support! Let me know if you have any questions or things I should correct. :-)

Resources

http://n64.icequake.net/
http://www.n64dev.net/
https://github.com/ARM9/n64brew
https://github.com/n64dev/docs
https://github.com/shlomnissan/ultra64demos
https://github.com/mikeryan/n64dev
http://patater.com/gbaguy/n64asm.htm
http://n64dev.org/

Also here are some really interesting articles

http://www.gamasutra.com/view/feature/131449/bringing_dr_jones_to_the_infernal_.php
http://www.gamasutra.com/view/feature/131556/postmortem_angel_studios_.php
http://www.gamasutra.com/view/news/177106/Video_The_humble_beginnings_of_GoldenEye_007_for_the_Nintendo_64.php

Edit - 11/4/15 3:31 PM

I mentioned that I did my development on a Mac but that's not completely true. Smiley I actually started on a Mac just to emulate the the ROMs I was producing but later switched to Windows. I think I mainly switched because the 64drive software only came with Windows executables. I did however later switch to using Arch Linux for development. I found a Linux port (https://github.com/jkbenaim/64drive_usb_2xx) of the 64drive transfer software so I could actually just use a complete Linux environment to do everything.
« Last Edit: November 05, 2015, 12:15:13 PM by deadcast » Logged
gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #72 on: November 04, 2015, 04:49:51 PM »

Awesome journey! congratz!

Quote
Months later the author of the CEN64 emulator (https://github.com/tj90241/cen64) started doing exactly what I sought out to do (https://github.com/tj90241/n64chain)! He is using Krom’s test code (https://github.com/PeterLemon/N64) to actually start writing new RSP code in a C based project. Seeing how he figured out what I was trying to achieve was great! Now only if I had the motivation to build off of his work but alas that’s where my problem lies. No motivation right now to continue further but perhaps someday.

Did his implementation of microcode complete?
Logged

deadcast
Level 0
***



View Profile WWW
« Reply #73 on: November 04, 2015, 07:09:18 PM »

Awesome journey! congratz!

Quote
Months later the author of the CEN64 emulator (https://github.com/tj90241/cen64) started doing exactly what I sought out to do (https://github.com/tj90241/n64chain)! He is using Krom’s test code (https://github.com/PeterLemon/N64) to actually start writing new RSP code in a C based project. Seeing how he figured out what I was trying to achieve was great! Now only if I had the motivation to build off of his work but alas that’s where my problem lies. No motivation right now to continue further but perhaps someday.

Did his implementation of microcode complete?

Thanks! Smiley

I'm not totally sure if all of the opcodes have been implemented yet. I was looking at the opcodes defined here (https://github.com/tj90241/n64chain/blob/master/rspasm/opcodes.h) but I'd have to compare to what the known opcodes are. I believe I have a couple documents someone wrote about all of the opcodes discovered. There's probably enough implemented now to start doing something cool. Maybe I'll attempt triangle rendering again! lol
Logged
deadcast
Level 0
***



View Profile WWW
« Reply #74 on: November 04, 2015, 07:10:41 PM »

How's things, pal?

Hey!

Things have not been going well lately in life. Been dealing with bad anxiety/depression problems and other life issues. :/ I think I'm starting to do better now though. Been really distracted and feeling dead. No motivation to do anything. I feel really bad that I haven't been making any progress on this N64 thing. I actually just started thinking about this project again today and getting a little motivation to work on it! :-) Trying to plan out right now what direction to take this project. I love the N64 and still want to make something for it. Thanks for checking in! I hope I can share something new soon and get my life back to normal. Smiley
Sorry to hear you're not doing so well  Sad
But it's good to know you're still thinking about it, and getting your motivation back!
I hope you get better soon!  Beer!

Thanks so much! I'm still alive Smiley
Logged
gimymblert
Level 10
*****


The archivest master, leader of all documents


View Profile
« Reply #75 on: November 04, 2015, 08:07:58 PM »

I was asking because it seems like the last wall true wall. However all those data where fascinating ... though I guess sound will be equally a problem lol

Take care!

edit:
http://www.zophar.net/fileuploads/2/10655uytsm/N64ops03.txt
from
http://www.zophar.net/documents/n64.html
Logged

oahda
Level 10
*****



View Profile
« Reply #76 on: November 05, 2015, 03:14:36 AM »

While it's a pity that you lack the motivation to continue for now, this has still been very educational and the final writeup was a good summary. And hey, you provided us with more reading and watching! I'll be all over it. Thanks for everything so far. c:
Logged

deadcast
Level 0
***



View Profile WWW
« Reply #77 on: November 08, 2015, 05:07:01 PM »

While it's a pity that you lack the motivation to continue for now, this has still been very educational and the final writeup was a good summary. And hey, you provided us with more reading and watching! I'll be all over it. Thanks for everything so far. c:

No problem and thanks for checking this project out! Ye I wish I would keep going sometimes but I think taking a rest now will be good. I gotta catch up on my other hobbies! :-)
Logged
deadcast
Level 0
***



View Profile WWW
« Reply #78 on: November 08, 2015, 05:07:36 PM »

I was asking because it seems like the last wall true wall. However all those data where fascinating ... though I guess sound will be equally a problem lol

Take care!

edit:
http://www.zophar.net/fileuploads/2/10655uytsm/N64ops03.txt
from
http://www.zophar.net/documents/n64.html

Thanks for the opcodes! Smiley
Logged
deadcast
Level 0
***



View Profile WWW
« Reply #79 on: February 05, 2017, 04:36:17 PM »

Hello everyone! Sorry to resurrect such an old thread but I've actually been working on creating stuff for the N64 again! This time I decided to just use the Nintendo 64 proprietary SDK and actually build something this time. So I'm happy to be able to fully use the hardware correctly like the RSP/RDP and do things the way Nintendo/SGI intended.

Getting a running environment took a little bit of time but I'm all set now and developing in a Windows XP Pro SP3 virtual machine lol! Since the SDK's GNU compiler is so old it's easiest just to run on a 32 bit system. I think the compilers were built for 16bit MSDOS! Smiley Today I made some good progress and got PNG image support working and got a model I made in Blender loaded using a custom file format. All the source is available at https://github.com/deadcast/n64-model-viewer. Sorry that the code is a little messy right now since I'm trying out different things quickly and trying to figure out what the hell I'm doing lol! At this same time, I'm also writing a model loader for the Nintendo DS. I kind of want to write some sort of simple game engine the works both for the NDS and N64.

Here are couple of vids showing the model loader working on the N64 and NDS. I'm rendering a couple models I made in Blender lol.







If you have questions please let me know! I'll be keeping this thread up to date as I make little bits of progress. I'm happy to be developing for both of these systems and I might even do some stuff for the Dreamcast but I need to pace myself lol. Smiley
Logged
Pages: 1 2 3 [4] 5 6
Print
Jump to:  

Theme orange-lt created by panic