Chilly Willy

I tried repositioning the cart, and things that worked before are working again. Apparently, the GD is rather touchy on some cart connectors. Now I get the yellow screen others report on trying to run OpenLara. Weird how just a tiny bit of jiggling the cart makes things work or fail... especially weird that some things still work at all. You'd think that it was more an all or nothing sort of deal, but even at the same exact rom size, some work, and some don't. So if things start acting weird, I suggest readjusting the cart and seeing if that helps any. It did mine.

I don't get a yellow screen on my GD, it simply doesn't start... like 90% of everything I've tried on my GD. Very few things actually run. Tube 2020 runs, but Tube and Tube SE don't, for example, despite being almost identical from a program point of view. I wonder if it's a matter of the SD card filesystem. I know GD has problems with lots of cards and also with files that are fragmented. Makes me wonder what filesystem the menu uses. I'd recommend moving to Elm-chan's FatFS. I used that for the various Neo Myth menus on a number of platforms, like the Genesis and the N64. A modified version of their PetitFS was used for the Master System and SNES menus. EDIT: To note, I'm using the latest firmware according to the download link page. I do say, however, that the previous firmware worked better. I could run more files than the latest; in fact, many that used to work, like the Bad Apple GD demo, no longer work. They all just hang immediately after loading. I'm tempted to downgrade the firmware.

According to the reference manual, they use B8(), B16(), or B32() to do binary numbers of a specific size. Just put the binary number inside the parenthesis.

It's amazing what a little time does to "common knowledge" about older consoles. Time has not been good to the N64 as described by Nintendo and SGI - most of everything they claimed was marketing nonsense to try to sell idiot bosses while keeping the engineers in the dark. First, what SGI/Nintendo calls "microcode" is nothing of the sort. Gorf was right in saying that microcode inside a CPU controls the decoding and handling of the instructions themselves, but the chipset SGI designed did NOTHING OF THE SORT. The RCP was the combination of a bog-standard GPU (called the RDP) and a stripped down R4000 processor (called the RSP). The RDP was like virtually all GPUs: it had a standard set of drawing commands, and took those commands from a circular buffer in memory. On the RDP, a command byte would be followed by a number of data bytes, depending on the command itself. Certain ranges of the command byte were reserved... reserved for the RSP. What SGI/Nintendo called "microcode" is actually an R4000 library (written in standard R4000 assembly) loaded into the local instruction ram in the RSP (it had two blocks of local ram - instruction ram, and data ram). The RSP was stripped of all 64 bit instructions, a number of other instructions deemed "not essential", and then had a few matrix instructions added. The main processor would send a stream of commands and data to the RCP, where the RSP library routines would go through the stream byte by byte looking at the commands. Regular RDP commands would be passed through, either unchanged, or with some minimal changes to things like the coordinates and lighting (you could apply matrix operations to the coords for rotating and whatnot). Some of those reserved commands were meant to tell the RSP to do things, like update local matrix values, use its built-in DMA to transfer data, and do most of the sound processing and mixing. Yes, the N64 actually had NO sound hardware beyond a DMA driven stereo DAC. The "microcode" told the RSP how to handle processing sound samples and to do mixing into buffers that would then be DMAed to the DAC. At no point were ANY instructions in ANY processor in the N64 changed. You could change the "microcode" library to reinterpret the commands... maybe changing triangle rendering from perspective correct RDP commands to affine RDP commands for better speed (Turbo microcode). Maybe someone wrote a better method of handling poly clipping in software - that change could be worked into the library. Maybe someone introduced a new method of compressing textures, or sound samples. New library routines would allow the RSP to decompress the new data formats. Nintendo and SGI made it all sound like magic when it was actually all smoke and mirrors. They would have been far better off just documenting the hardware as it really existed and let the developers use it as they saw fit. Most devs would have stuck with the normal libraries regardless of what Nintendo called them or how they worked, and devs like Rare would have made their own that did just what they needed instead of what Nintendo felt everyone should use.

Depends on what you mean by 68K. Doom was officially released on the 68K Color Mac... if you had a 68030 or 68040. They coded the game to exit if you tried it on a 68020 based Mac. It ran rather well depending on the processor and the display update method chosen. The Mac version was also the first version to run at >320 wide. You could run at 640x480... that was the slowest mode, but looked really good. Nice sharp edges. I patched my copy of Mac Doom to run on the 68020... which it did! Veeeeerrrrrrrrryyyyyyyy slowly. ? Mac Doom was pretty awesome on a 68060 Mac.

Looks nice. Hope you get to feeling better soon.

You can build the C/C++ compilers fairly easily in linux. I build gcc for 68K and SH2 for my Sega Genesis/CD/32X/Saturn programming. I modified that to just 68000 targeted compilers to use with a Jaguar devkit: https://pastebin.com/UUTEwppM You also need a link map file for the architecture you are targeting. There would be two for the Jaguar - one that ran from cart, and one that ran from a loader like BJL. I made a couple you can check out here: https://pastebin.com/nMPppfm0 and here: https://pastebin.com/rijygrT1 Well, there could also be a third targeting CD, but I have yet to work on that. Of course, then you need a gcc compatible Jaguar system include file. Here's the H file I made: https://pastebin.com/BAz68AYm Then you need a makefile for the project. Here's one for a simple example I am working on for this toolchain (not complete yet): https://pastebin.com/tprpnGd5 And of course, a compatible crt0.s file to start up your C/C++ program: https://pastebin.com/Cv5gvBUC And if it's C++, you need this for the constructors/destructors: https://pastebin.com/2cy4xZLn

The 32X field manual talks about MD motherboards that need the EDCLK capacitors clipped to get a clean EDCLK for the 32X to be stable. It's one of the most frequent things Sega repair facilities did for people who had trouble with their 32X. It's possible your Model 2 VA4 was one of those. Good to hear your Model 1 is working fine. I have no idea what revision my Model 2 is... I bought it in 1992 along with a Sega CD Model 2. It works great with the 32X - well, other than the standard Model 2 shitty sound. One of these days, I'll make Tiido's CCAM for my Model 2 and get some decent audio out of it.

Lots of good info about the PSX version there. Kinda funny that Sony avoided affine mapping artifacts by rendering with hardware a line at a time. I always wondered how they got around the normal affine fish-eye problem. Also of note, the PSX display is only 256 wide, not 320 like the PC. So the highest resolution on D32XR pretty much matches the PSX resolution. It's just not stretched over the whole display like on the PSX.

I know what you mean. I keep a directory of Genesis VGM files on my SD card that I like playing with the NeoMyth menu. Some games just have such awesome synth music it can give me chills. If you put some work into it, the YM2612 can do some really great instruments. Sega needed a top musician to put some work into it and then had a database of settings for good instruments for games to use for their music. Seriously, some games sound like they're barely more than sine waves. ?

There is an arc that made the rounds that is a combined Sega CD, 32X, and Saturn devkit with libraries (for the Saturn) and examples. That's where the various 32X demos like the tie-dye Sonic 3D model and the 32X hardware test came from. There's a smaller arc with just the 32X stuff. They've been floating around the net for at least a decade. People don't talk about it today because it's so old. We just kind forget about it, but newbies should probably get it, at least for the documentation and old examples. I think they've got copies of the arcs over at Assembler, and maybe at SegaXtreme. It really is amazing, but I think FM percussion suffers a little. I certainly like PCM drums better. The current player in D32XR doesn't handle PCM as it uses lzss archived VGMs, decompressing the music on the fly. Decompressing the PCM from an archive on the fly would be a big pain, so it wasn't implemented. The original player for D32XR does handle PCM, but doesn't handle compressed VGMs, which means the music takes more space. Too much space for 4MB, which is why we compressed the music. So it's just as well spoony's music used FM percussion.

Yeah, I didn't really expect anyone to switch CDs while the game is running. I'll have to make some changes for that. The next thing for CD is to add support for ISO9660 data discs with PCM/ADPCM to stream through the CD's PCM chip. That will allow more tracks, as well as longer ones, with only slightly less quality than the CDDA audio. And you forgot to flip the switch in the secret room (as well as get the backpack) before going after the red key. Look for the part of the wall that doesn't match the rest.

I do have to say, the Checkered Flag code is MUCH cleaner and well commented. The FFL code is a huge mess... absolutely everything in the same directory with cryptic names and few comments. You'd have a much easier time working from the CF code.

I've gotten a lot of messages of a similar (over)reach over the years. They usually go like this... "Hi! I've just taken a beginner class on C++ and now I'm going to write a PS5 emulator! Can you give me any tips on where to start?" ? Me: Yes, take some more classes. Look at current open source emulators. When you don't need tips on where to start, you might be ready to start.

If you aren't already registered at SpritesMind, I'd suggest doing so. It's the main hang-out for Sega developers, especially for MD/Genesis. Lots of good technical threads and help there. ? http://gendev.spritesmind.net/forum/index.php

Install dosemu2. It replaced dosemu in newer Ubuntu versions: https://launchpad.net/~dosemu2/+archive/ubuntu/ppa

Thanks, glad you like it. Vic, in particular, put a lot of work into it. He's the driving force behind D32XR. We're currently getting Sega Mapper support worked in so that we can go with roms bigger than 4MB. Seems to be going well so far. That will allow us to do things like improve levels and sprites, and add back in code to allow for missing levels and Doom 2+. It's pretty well set for the first release version - took a few revisions to work out most of the kinks, but it's going good now. It's not perfect (yet), but it's good enough for now. We'll see where it goes from here.

That certainly was insane. You could see points where the sprites per line limit were hit, but in a normal game, I don't think it would come up.

Well, obviously we can't test it on every bit of hardware out. No one has every bit of hardware out. The point about the integrated YM3438 flag could affect the FM music, but shouldn't crash the game. It should be easy enough to test... turn off the FM music. The sound effects are played on the 32X. We don't use TAS on the Genesis side... no one should since how TAS is handled varies from model to model, with model 3 Genesis being utterly different - enough that some official games don't work on it. You might want to contact myself or Vic via email. This may turn into something that could help others we haven't heard from. Like I said, no one has every bit of hardware, but when you run across someone with an issue, that can help others. In the meantime, do you still have the older patch files? Maybe try some older versions and see if the problem is better or worse. That could help narrow down the problem. Certain versions have particular changes, and maybe one of those is badly reacting with your system.

It's been tested on lots of real hardware without issue. We even support the buggy SH2 processors. There may be an issue with your system. You might get the 32X Service Manuals off the net and check the trouble shooting sections. Certain models require certain caps to be clipped to make the system stable.

Yeah, it's getting harder to find a 32X at a decent price... you just have to keep an eye on the auctions and leap into action when you get a chance. And we added mouse support to it. I'm not aware of any of the console ports supporting a mouse. Playing a first person shooter with a mouse allows for far better control compared to just a pad, especially if the pad has no analog sticks. You need a programmable pad with shoulder triggers to really be able to effectively control Doom with a pad, otherwise circle strafing is too difficult. I've seen people finish Doom on pads without circle strafing, but it's painful to watch. I wouldn't want to do it.

Yes, I have accounts on many boards... too many. ? It runs perfectly fine on Kega Fusion 3.64. I tend to use that for quick testing before checking my real hardware. Setup port 1 for a keyboard driven 6-button pad, and set port 2 to mouse. Fire it up and hit F12 to activate the mouse. If you map the pad to the proper keys, it'll be just like DOS Doom mouse+keyboard, and very easy to control. Even just getting people to play the rom means we may get feedback that can help, like the person who suggested having the names of the maps in the new game menu.

It can be. On my NTSC Genesis/CD/32X, it tends to hover in the upper 20s for FPS. I get 30 FPS quite often, and on some occasions it may drop to the low 20s. As Vic keeps optimizing the rendering to use both SH2 processors the FPS has gotten better, so my average has been getting higher more often as the project goes on. However, remember that the PS1 is drawing at a higher resolution, with far more color depth, and with effects like transparency. I'm also not sure of how much strain more enemies puts on D32XR compared to the PS1. I'll have to find some levels that max out the baddies and check how it affects the current build. You can check things yourself - D32XR has some performance checking built in. Press START during game play to pause. While paused, press MODE once and you'll activate the FPS meter. Press it again to get a timing chart of various parts of the logic/rendering. There are also some test modes that can be activated. Press MODE enough times and you cycle back to normal play.

All console Dooms (except for SNES Doom and GBA Doom 2) are derived from the Jaguar source. D32XR is derived from Calico. Calico is a port of the Jaguar Doom to the PC - it features the render phases re-engineered back into C code (partly from looking at the Jaguar asm, and partly from the 3DO code released by Rebecca Heineman). Calico was modified to build for the 32X, and then parts were redone to make the 32X faster, notably, splitting some of the rendering between the two SH2 cpus. Some of the lowest rendering code (drawing columns and spans) have been done in SH2 assembly for best speed. D32XR also takes advantage of the 64-bit divider unit in the SH2 where it makes sense. Once it was working, some fixes were made, and features added. There's a pretty long list of fixes and features on the rom patch page and the github page. It is still under work, and more fixes and features are being added constantly. Being an open project (everything is in the github repository), we get plenty of help from interested parties. Wavy has helped quite a bit with fixes to levels. Spoony Bard did a great job on updating the FM music. If you have an interest, and some ideas, feel free to contribute to the project.

Note that I'm not an expert on the Jaguar, but I can throw in my two cent's worth in an attempt to help make sense of things. A different viewpoint sometimes makes a difference. 1. From the text on the bug, a completed external read is necessary before every external write. The first key term here being COMPLETED, with the examples showing using an OR on the register targeted so the scoreboard locks the write until the read completes; the second key term being EVERY. They make no examples showing one completed read and two or more writes. 2. External is outside Jerry; for example, to Tom or main memory. The joy ports are internal, but Jerry can do some internal locations as words and others as longs. If you read through the manual on Jerry, it specifically tells you when registers MUST be read as 32 bits, even if only 16 bits are valid. An example here would be the I2S ports. But other parts of Jerry have 16 bit registers one after another and no mention of accessing only as 32 bits. An example of that would be the async serial ports, or the joy ports. All I2S ports are on long boundaries and the manual specifically tells you to access as 32 bits. The async serial ports are NOT all on long boundaries and make no mention of accessing as 32 bits. The joy ports are the same, being at 0xF14000 and 0xF14002, and all examples access as 16 bits. All of the Jerry code I've looked at avoids the external write bug by never doing external writes. I've yet to see any Jerry code accessing anything other than internal registers and local ram.