Chilly Willy

Slight correction here - the N64 is a 64 bit processor on a 16-bit bus. The bus between the main processor and the coprocessor chips was 16 bits, and passed packets of data. Even the cart is only 16 bits wide. The 16-bit packet nature of the bus is what contributed to the large latency on cache misses for the cpu. Nintendo also didn't want developers running 64-bit code as that unnecessarily expanded the amount of data needed to be passed across the bus. The N64 actually runs faster with 32-bit code, and as the N64 was never going to have more than 4GB of anything to access (max ram of 8MB, max rom of 128MB), 64 bit pointers were a complete waste. Saving and restoring 64 bit registers would double the time on entering and exiting functions. Note that the bus between the RDP and RDRAM was 18 bits. That's the main 16 bits plus the extra two error detection bits that RDRAM had. It could use those extra two bits to increase the levels of alpha in 16 bit rendering. It's only because RDRAM was ridiculously fast (for the time) that the N64 had any kind of real performance. Imagine trying to draw across a 16 bit bus while the processor is trying to run code/data across the same 16 bit bus to the same 16 bit ram. So in one respect, I agree - the N64 was NOT 64-bit where it truly mattered.

The latest commits in the OpenLara repo were for the GBA and 32X. I follow it fairly closely as I make my own builds for the 32X to better advise on issues on that platform. In making the 32X version, he seemed to refine the fixed point branch and migrate some of that back to other fixed point builds like the GBA. I imagine that making a new port teaches him new things that might possibly help other existing ports. So even if he hasn't gotten back to the Jaguar port yet, he's learning lessons that will help it eventually.

I've got a TON of Genesis game music on SD card in VGM format that I play using the VGM player in the NeoMyth menu. Lots of good Sonic music, music from Y's, Earthworm Jim, etc. I really like the music from Echo - Tides of Time. VGM players on the PC have gotten better, but there's just something about playing it on real hardware. ?

Did you read the user manual? https://krikzz.com/pub/support/mega-everdrive/x3x5x7/Mega Everdrive-v2 user manual EN.pdf If you don't know how to unzip a file on the Mac, I'm sure there's plenty of videos on just that on youtube. It doesn't need to be specific to the MED, just how to unzip a file using a Mac.

Of course it was all compiled to begin with... just like the Jaguar port or the 32X port. The fact that he'll be redoing sections in JRISC instead of 68000 just adds to the complexity, but doesn't make it impossible. If he feels it necessary to look at what certain code would look like compiled to JRISC, he can use the old gcc compiler set to output assembly. Just cut and paste the functions he needs into a test file, make certain it's C instead of C++, and run the compiler over it. Being an old version of gcc, the compiled code will be easier to read than modern gcc. Ever look at the assembly generated by the latest gcc for the 68000 or SH2? That be some crazy shit! ?

IIRC, the problem is that the 32X doesn't pass the DTACK line through to its cart port. You might want to google for that - I seem to remember someone making a mod to fix that. The other "solution" would be a flash cart that supports GameGenie cheats. I know the old NeoMyth MD cart menu supported many GG codes while loading games. The MED might as well... you might want to check the MED feature list/user manual.

While I'm on the side of a new JRISC compiler helping the community, I do think it wouldn't help OpenLara much/at all. If you look at the ports of OpenLara for "lesser" platforms, they get most/all their speed from the copious number of assembler optimizations done. So in this case, CJ is right - OpenLara is only going to get better with lots of hand-written GPU/DSP assembly replacing sections of the engine. Just look at the asm directory of the GBA platform - there's THIRTY-SIX files there! ARM has lots of mature compilers, but he still needed to write all-new assembler code to get the GBA port to the state it is.

Not to sound stuck up or anything, but that's why Vic came to me. He was also looking for 32X optimizations and such. I have lots of tricks I've learned while working on various demos and libraries... inline assembly, separate assembly files, using the SH2 internals more effectively, putting data and functions on boundaries and in different parts of memory, how to move things to the MD side and when, etc. Where Vic has really come through is knowing when and how to move a function from the primary sh2 to the secondary sh2. I mainly just used the extra sh2 for completely separate tasks like sound/music. He really knows how to take a group of single threaded C functions and make it run parallel. Things I never even considered.

I don't think they're in touch. They've both got their own priorities on what they want to work on, and they don't match up. I think right now what is needed is a Tomb Raider data editor. Imagine making your own game using OpenLara to drive it.

Oh, so it's actually better than the N64 for interlace. ?

The N64 is the same way. You have to manually change all the settings every vblank. I made the changes in libdragon for proper N64 interlace after trying to use interlace and noticing it didn't work properly. That was (checks calender), damn, almost a decade ago!

MegaSD for all those awesome SCD games on the go. Everdrive/NeoMyth for SMS and Genesis games. There's a post over at Sega16 somewhere where I did a test of how long different flash carts ran on the Nomad with the battery pack (spoiler - it's less than a real cart, for obvious reasons). Playing SMS games on the Nomad is like having a better GG. Bigger screen, bigger game resolution (the GG really cut down the resolution of the games), bigger handheld (you could kill a mugger with your Nomad - let's see you do THAT with a GG!)...

Some are really easy, like connecting the SMS line or DTACK. You just solder a line from a point on the board to a connector pin. The backlight and screen are a bit more complex. I had Tiido do the mods on mine as I'm getting a bit old for delicate soldering... family arthritis is starting to creep in my hands. As to the MegaSD, I don't have one, so I haven't looked at mods related to it. I probably should (get one and check on mods). Anywho, here's a good link for Nomad mods in general. Here's a link that covers the MegaSD audio mod.

I have a Nomad. It's got the SMS cart mod for playing SMS games, LED backlight mod, NTSC/PAL switch, and the START+MODE = Reset mod. I'm looking at replacing the LCD screen next. With the original LCD, quite a few games are a little problematic as it becomes hard to read the score/time/etc. Quite a few are great! If it has tiny characters for the score/time/whatever, it will probably be tough to see. This should be better if you've replaced the LCD. As mentioned, it eats batteries, so I mainly play it connected to AC (it will use the "standard" Sega AC adapter used with Genesis 2, 32X, etc). I save the batteries for if/when I take it on the road... which is almost never.

I've gotten in contact with him, and pointed him towards the newer code. He seems rather nice. He also provided me with an initial build to try: works pretty well - no sound yet, around 4 FPS on real hardware with no optimizations (plain fixed point C++ codebase). Runs at 8 to 10 FPS on Fusion 3.64 (emulators always run 32X games fast as they neglect things like bus delays and cpu contention). This guy deserves a medal for his work on OpenLara. ?

If it gets Jaguar support, it will be worth it. I needed a "new" N64 the other day, and while ordering one from eBay, I looked over the selection of Jaguars... they START at like $500 and go up from there. ?

I ought to point him toward the D32XR github repo. It has the latest support code for unified int handling as well as how to do int driven DMA and timing. He seems to be working from some of my older support code, which isn't too surprising.

No idea how Matthias did it in his port, but it sounds like the best thing for you to do in yours is to disable all but the VBL and set a critical flag that tells the VBL handler to just repair the OP list and exit without doing the normal vblank routines. When the SR is restored and ints are enabled, you can clear the critical flag so the vblank runs like normal.

I generally look at the error message when the compile fails to see what is needed to add. For example, if it says something like it couldn't find sdl2gfx.h, you know you need to add the dev package for sdl2gfx. It usually fairly clear what was missing, and if it isn't, a quick google usually turns up which package has the missing thing in question. Often, you can do a make distclean and then rerun configure. Configure will nearly always tell you when required packages are missing. But yes, dependencies for compiling SHOULD be in the readme or the wiki or wherever the build instructions are.

Sega CDs are just plain ISO9660 discs, with optional CDDA tracks after the first (data) track. There's no protection of any sort on these discs... something Sega changed for the Saturn.

I use the current VJ Rx from github. It has support for debug info in the form of dwarf entries when you use elf format.

Very weird, but glad your problem is fixed. Happy gaming!

It think it's more that the newer 68k code generation is geared towards 32-bit chips, particularly the ColdFire cores. The older gcc when targeting the 68000 would produce faster code as it concentrated on keeping as much of the code as possible using 16-bit constants and offsets and such. The newer compilers produce better code, but not faster as it barely pays any concern to the faster speed word size of the 68000. There's a lot more about this over at SpritesMind since the Genesis/MD used the 68000. People benchmarked the old gcc verses newer versions. I don't think anyone has benchmarked it against anything really new, like 10.x or 11.x.

Given the speed on the GBA, an N64 version should run rather nicely, even with software rendering. A 32X version using one SH2 and plain C should be slow, but not a slideshow - it's basically how my yeti3d demo on the 32X works. If you made the same kind of optimizations to the 32X version as the GBA version, it should should be at least as fast, and faster if you can pull some dual processor stunts like Vic did for D32XR. The main thing going for the 32X version is you can have all the game logic and everything running on the SH2 rather than the 68000. The SH2 has a mature and stable C/C++ compiler, unlike the JRISC, so acting like the main SH2 is the only processor, and all the MD stuff is just a support chip to be initialized and forgotten about is a valid way of programming on it. So I wouldn't be surprised if an initial build on the 32X ran better than the current build on the Jaguar. In the end, the Jaguar version should be better, but it will take more work to get there.

Latest works here. Very nice for a slide show. ? I can actually run around as long as I'm patient. Seems stable, and the rendering looks good.