What's new
By:

Netboot Naomi With EEPROM Presets!

MetalliC said:
have you read powervr2 docs ?
there is no any dedicated texture RAM and display list / frame buffer RAM, there is one unified RAM with 2 access modes (64bit for textures and 32bit for everything else), it will access same physical RAM, but just interleaved if compared one to another mode.
so, yes, you may trash some textures by FB or object lists/buffers, or vice versa, if not taking in account how it works.
Click to expand...
Yep, I am making sure that I put my textures past the point where I allocate all of my TA buffers and such. MAME does not emulate the two RAMs being the same (IIRC there's a comment stating they should be but they keep it separate) which is probably why the problem does not appear there. Clearly I am screwing something up somewhere, however, but I haven't found it yet.
 
Back (mostly) from my holiday break...

Okay, so what was clobbering memory was the command buffer from the TA. Still not sure why, the docs don't mention a minimum buffer size as far as I can recall. However, increasing from 512kb to 1mb (similar to naomi BIOS) for the command buffer caused the distorted textures to go away.

I've also verified that if you write to the cartridge using an upload command while the naomi is running your code, you can read it from the naomi code. You can also write back to the cartridge from naomi code and that can be read using a download command. Neat! Technically this would allow me to do bulk transfers far faster than the current message protocol. I'm not going to revisit that however since its working and I don't want to throw it all away. Homebrew can easily make a message that says "read X bytes from cartridge space please" or "write up to X bytes from a buffer to cartridge space please" if somebody wants faster bulk transfers for a game they're making. I'm going to use it to write a GDB stub so that remote target debugging is possible with homebrew.

I also need to work on a "decompressing and patching" screen to put on the netdimm menu for @chunksin since gunzipping ROMs takes a lot longer than the hardcoded timeout in the menu. I'll give that a poke sometime this week as well.
 
Hope you had a good break! I tried adding a screen in myself in a very noddy way - basically a copy of the Caution screen with different text and inserted it after the animation and before the game is sent and the timing was tricky, some games would load a fraction of a second after the animation finished so it didn't look great, games with longer unzip times looked fine, those that unzipped quickly didn't get to the screen at all - the animation is cool and would be nice to keep, just working out timing for a new screen and not slowing down the game load is a tricky balance (especially for me who hasn't done any C programming in 26 years!)
 
Last edited:
DragonMinded said:
Okay, so what was clobbering memory was the command buffer from the TA. Still not sure why, the docs don't mention a minimum buffer size as far as I can recall. However, increasing from 512kb to 1mb (similar to naomi BIOS) for the command buffer caused the distorted textures to go away.
Click to expand...
make sure to read "Bugs List" section at very end of document, there is a lot of hardware limitations
 
Last edited:
Toolchain update: I've made good progress on the GDB remote stub. GDB can connect to running homebrew and examine stack traces, registers and memory for all running threads. The information about threads such as their ID and name is also integrated with GDB's thread-based debugger. Conneccting to the Naomi will cause the program to halt until you continue it in GDB or stop debugging. I have a lot left to do to make it a truly useful remote debugger but already it is useful for debugging as-is. Sometime later this week or this weekend I'm going to try to button that up and check off the last few TODOs and then I'll work on the decompression screen for @chunksin.
 
Got the GDB stub basically wrapped up, save for breakpoints/code stepping. I'll try to tackle that next week. However, its already a massively useful tool since I was able to use it to debug and fix a race condition in my TA rendering interrupt handler and fix the last showstopper bug. It was softlocking sometimes before and now I've successfully left it running for over 24 hours with no issues! I'm going to try to take a break this weekend (lol) but come Monday its time for me to figure out how to add a decompressing screen so we can put that problem to rest.
 
Okay, a few minor updates that concern basically nobody. But maybe somebody is curious? First, polished up the GDB stub, ported over icache clearing from KOS and implemented breakpoints and single-stepping. Debugging on target just got a whole lot nicer. Its all integrated with the thread system and everything too, its pretty great if you ask me! I'm calling that done for now. I also found another memory corruption issue in the kernel thanks to a report from @chunksin and fixed that. I also fixed the stereo ringbuffer driver which I noticed was broken when I went to release my homebrew game (of course, right then, no sooner!). The base libraries are starting to be stable and useful at last!

Also, I've been working with @chunksin again on the last bit of tidy-up with the netdimm menu software. It looks to be all working just fine now so expect that in the wipi netbooter sometime soon! I still hope to work on the font rendering library and move that over to hardware-assisted instead of software rendering. This should allow me to hit buttery smooth 60fps on all screens since I won't be using a 200MHz processor to do alpha blending anymore. With that out of the way, the extra wiggle room from the processor being left to mostly wait for vblanks means that much more extensive customization and possibly themeing could come down the line. But we'll see!
 
Bit of an update. I got everything lined up to use the hardware (PVR + TA) to display text, got it all sorted out and....it's only marginally faster. I guess transparent sprites are pretty darn expensive on the PowerVR as well. So, bad news is the main menu screen doesn't hit 60fps like I was hoping. Good news is both vertical and horizontal orientations of the menu both hit 30fps now (vertical was 24fps before) so it is still an improvement. And it has bought some extra wiggle room for other customization. I'm gonna sit on this for a night and then try to profile it some tomorrow and figure out if I'm just doing something stupid.

However, the netdimm menu has been updated and should perform better in vertical orientation. CC @chunksin in case you want to pull the latest code and recompile to get a slight speed boost.

EDIT: HAHA JK its my mutex implementation being really slow and context switching every time I load a sprite. If I fix that It'll get to 60fps. @chunksin hold off on updating until I fix that.
 
Last edited:
Okay, NOW it runs at 60fps, both in horizontal and vertical orientation. With a LOT of spare CPU cycles for extra stuff if anyone ever wants to add stuff. I'm calling it, Netdimm Menu 1.0 is officially done! @chunksin you'll want to pull latest code and merge/recompile for a massive graphics performance boost.

EDIT: The lesson here, folks, is ABC. Always Be Cprofiling.
 
Last edited:
Bit of a bookkeeping update for anyone hoping to use my libraries to write homebrew. I've split the homebrew directory out of the https://github.com/DragonMinded/netboot repo and into its own https://github.com/DragonMinded/libnaomi repo just to clean things up. The directory already functioned basically independently of the rest of the netboot repo so it made sense to pull them apart. That means, if you are playing with my tools for net booting, you should still use the tools on https://github.com/DragonMinded/netboot and all of the documentation I've posted in this thread still applies. But, if you are attempting to set up a homebrew toolchain to compile the menu from scratch or make your own games, you want to go to https://github.com/DragonMinded/libnaomi instead now.

Hopefully with these two untangled people who are interested in only one piece or the other don't have to consume bandwidth, disk space and clutter on both projects at once.
 
You have put so much time and effort into documenting and building out a really nice repo, I am for one am both impressed and thankful. I was toying with the idea, that since SMB64 was completely reversed and has already been ported to many systems, including Dreamcast, that Naomi might be the step.
 
dewmansnk said:
You have put so much time and effort into documenting and building out a really nice repo, I am for one am both impressed and thankful. I was toying with the idea, that since SMB64 was completely reversed and has already been ported to many systems, including Dreamcast, that Naomi might be the step.
Click to expand...
DO IT.
 
Please remember the SM64 is a dirty project which uses leaked files. :'(
 
whatnot said:
Please remember the SM64 is a dirty project which uses leaked files. ;(
Click to expand...
I don't mean to sound rude or anything but that's pretty much the arcade scene in a nutshell a good amount of the time. Transfergame.exe wasn't exactly handed out to hobbyists by Sega.
 
I see a difference in RE (example, I don't use transfergame, I use applications made from knowledge gained from it) and flat out distributing stolen code. Search their repo for "UNPUBLISHED PROPRIETARY".
 
whatnot said:
I see a difference in RE (example, I don't use transfergame, I use applications made from knowledge gained from it) and flat out distributing stolen code. Search their repo for "UNPUBLISHED PROPRIETARY".
Click to expand...
"Applications made from knowledge gained from it" still proves the point. Unless you black box it completely.

Anyway, yes, back on topic again this is amazing work and I can't wait to try it out.
 
whatnot said:
I see a difference in RE (example, I don't use transfergame, I use applications made from knowledge gained from it) and flat out distributing stolen code. Search their repo for "UNPUBLISHED PROPRIETARY".
Click to expand...
this is going out of topic, but anyway -
anything disassembled or decompiled are still a property of original owner, still copyrighted, and still can not be distributed.

in the case SM64 decompile project - it doesn't matter if there is any "leaked" or "stolen" parts, because the whole decompiled code are still a Nintendo's property.
 
MetalliC is correct. The only fully legal RE, at least in the United States, is if somebody does all the disassembly or decompilation and produces documentation about how something should work, and then somebody ELSE who is not allowed to ever look at the decompilation or anything implements their own implementation using just the documentation. It is very tedious and difficult because you cannot progressively build your understanding with packet captures, live execution traces or comparing your program to the original when they both run. See https://en.wikipedia.org/wiki/Clean_room_design, but as the article alludes, this doesn't protect you against patents, just copyright of the exact work you are seeking to understand.

It also doesn't really matter for homebrew and hobbyist reverse-engineering that happens 20 years after the fact, since Sega is not attempting to make any money off of this platform anymore and in general do not litigate fan creations or even egregious copyright infringement (see all of the sonic the hedgehog "art" everywhere). However, Nintendo *is* still trying to make money off of SM64. The point of it being "dirty" code just gives their horrendously shitty legal team more teeth when they come after you (which they will because Nintendo is litigious a.f.). My "DO IT" was based around excitement for somebody to take a stab at a difficult port, it would be fun even if it would be quickly scrubbed from the internet. If you are looking for an interesting and less dubious port, maybe something classic like DOOM or Descent would be fun?
 
You must log in or register to reply here.
Back
Top