Chilly Willy

Yeah. See that Star Fox demo for a good example of pure 3D polygon-goodness on the MD. Having good math skills can help a lot when programming, but some folks can find it a bit - boring.

Technically speaking, games like Doom ARE "real" 3D. While the level data may be 2D with the 3rd dimension being derived from floor and ceiling values, that doesn't make it not 3D. The rendering is a special form of 3D called "lines of constant z" that makes rendering fast and easy. If you aren't familiar with that, get a good book on 3D graphics programming. Now there are better ways to go 3D that are more realistic, but "not as good or realistic 3D" is not the same thing as "not 3D".

It's fixed height raycasting. Some folks call it 2.5D instead of 3D. Anywho, here's how the Genesis would handle Wolf3D: http://www.sega-16.com/forum/showthread.php?25663-wolfenstein-3d-demo-for-sega-genesis The latest version (b9t) is very nearly complete.

I have the Mosaic 64K expansion in my A400. I have always used it in the default mode - 4 banks of 4K at 0xC000. I hacked a number of bank selected carts to work in the Mosaic banks.

It's an awesome collection of images. Everything looks so nice, too!

Hmm - you need a face-on image of the regular pad like you do the propad. You currently only have an oblique image of the regular pad. Other than that, great looking pics!

Ideally, you want a cart with like 16 to 32 MB of ram (bank selected), and something like an SD card port. Have a small amount of flash to load a menu off the SD card, which would then allow loading homebrew and the like off the SD card. An SD interface would be more reliable than a CD - with enough hardware you could even stream digital audio off the SD card.

You have six megs of space allocated to the cart slot. If you want more, you have to bank select it. That's what the V2/3 Skunkboards do - you have one bank of 6MB of flash, or two banks of 4MB of flash. Most of the time, the Skunkboard operates in the two bank mode, with one bank or the other selected and containing a game. A homebrew game could handle the bank selecting itself, allowing it a full 8MB of storage for the game.

Newlib should be fine for the 68000. As I mentioned, I've never had a problem using it on the Sega Genesis with only 64KB of ram and it's 7.6MHz 68000. However, you probably DO want some things done as optimized assembly that takes into account the Jaguar hardware. Your example of memcpy/memmove is a perfect example. While newlib's memcpy/memset/memmove is good, it couldn't hold a candle to something using the BLITTER, for example. I would probably use newlib for most things, and a special version to take advantage of the Jaguar... say jmemcpy/jmemset/jmemmove, and maybe bmemcpy/bmemset/bmemmove to specify a version that uses the blitter.

There are two reasons for the warning on the 32X box about using it with a CDX - first is the lack of FCC certification; without that, the FCC could (in theory) drive one of their vans up to your house, verify that your CDX+32X is the source of radio interference, and confiscate the equipment and fine you for using uncertified equipment. Never heard of it ever happening, but they have the legal right to do so. And second is the lack of the adapter; without the adapter, the 32X doesn't exactly fit snuggly on the CDX, which means you COULD possibly damage the CDX while trying to insert/remove a cart from the 32X. To avoid that danger, I put both hands on either side of the 32X, and squeeze down of the cart so that all the force is only on your hands through the 32X, with none being transmitted down into the CDX.

My point was that for the 68000, newlib will be a better libc, which was the topic of the OP. A custom C Library is only needed for the GPU/DSP. Unless the OP was badly written... instead of "the Removers C Library and the Jaguar C Library", perhaps he meant "the Removers Library, and the Jaguar Library" which both are in C as that's all this is available, so saying so is kinda redundant as well as misleading. When you say "C Library", you are talking about libc and/or libm. If you mean any old library written in C, you do not call it "the C Library" as that already has a specific meaning to programmers.

That's what I mean - since newlib REQUIRES gcc to compile, you're better off with a hand-written assembler libc for the GPU/DSP. At least for now. Libraries like libc and libm would be one of the candidates for running GPU code from the main ram. You don't need the ultimate in speed, and the space wasted for a full libc/libm is less of an issue for main ram than local ram.

If you can switch CDs on the Jaguar without it rebooting (or by controlling the reboot to avoid the affects of a reboot), then all the more reason to have the ability to read standard ISO CDs. You could make a small app that loaded somehow (normal Jag CD/cart/BJL/whatever) and then allowed you to browse ISO CDs.

Newlib is one of the most popular implementations of the C libs. It gives full libc and libm on almost any processor or platform. https://sourceware.org/newlib/ On the 68000, libm uses software floating point, so it's not going to be super fast, but it's not too bad. Just keep the floats out of the main loop. On many processors, things like memset and memcpy have been optimized to be as fast as possible. Anywho, you get all those nice things, like vsprintf() that most hand-coded libc implementations don't have. Having used the 68000 compile of newlib on the Sega Genesis, I can say that using newlib is not a problem on a low-end console. My toolchains always compile a full C/C++ compiler with newlib libs. Now, making a compile of newlib for the JRISCs... that would be a challenge.

It would probably be easier/cheaper to make an adapter with something like a PIC chip that converted from one (or more) controller(s) to the Jag Pad Pro, like those converters that go from N64/NGC/PS1 to USB.

If I ever get a JagCD, I'll work on it. My thought was a small launcher that you run via skunkboard or similar - it would init the CD and allow you to browse regular ISO CDs... look at images, play music, run homebrew, that sorta thing. And yes, rebooting the console because the CD was switched was a BIG bug! I guess they were concerned about people switching in pirated games after booting an authentic game. The PS1 and Saturn had a similar security, but there were posts on how to bypass the CD switch protection.

Any particular reason not to use newlib for libc? That's what I do in all my toolchains for other consoles. Yes, a specific libc for a console will be smaller and faster, but if you're using a libc function in a place in your code where the size or speed makes ANY difference at all, you're doing it wrong. Hand-coded libc is for 8-bit consoles.

The position is part of the header, which is part of the raw sector data. What the SEGA CD BIOS does is take the requested sector number, subtract two seconds, and start reading the data until it hits the sector requested, ignoring data up to then. That's pretty standard on old CDs like that. Once you've found the proper sector, you can actually start doing a full error correction decode of the raw data instead of just looking at the headers. Naturally, if you just read one sector at a time, this will be pretty slow and wasteful. You want to read a number of sectors so that you only have to do the whole look for the first sector business once.

Herobrine on the A8? That would be cool, especially if you support four players on the A400/800.

If I can find my box of Atari stuff, I'll at least scan and post the Percom schematics. I'll have to look through the box to see if there's anything else worth scanning.

For just a demo, this ROCKS! Anywho, I'm betting we see the finished GUI long before ProjectM. I have no worries that the GUI won't be released (as more than a simple demo). I'm already thinking about the kinds of stuff we'll see using it afterwards. A quick update on the best word processor is almost a given. I'd like to see a devkit with editor based around this. I suppose a simple filemanager will be seen quickly as well. Imagine this OS as the top layer to DOS instead of the plain menu most DOSes use now...

I'd guess, with his computer.

I'd really like to figure out TrueMotion. The source code had been released for that, but it's such bad spaghetti code that it's almost impossible to make heads or tails of what it does. Better support for music/photo/video/whatever discs. Say you want to make a JagCD program that displays a slide-show of user photos while playing user-chosen music. Do you require the user to generate a custom format CD that may require burning several times until an error-free disc is finally generated, or do you just have them make a bog-standard ISO9660 CD (optional Joliet names) with the normal error correction so that only one disc ever need be burned? I think the choice is obvious. The only advantage to the raw format the JagCD normally uses is higher storage capacity, and that's rarely an issue with CD-based homebrew.

Dogecoin! =D How about live chickens?

This. MJPEG (or any format without delta frames of some kind) requires you to restrict the resolution in some way - dimensionally (smaller screen size), visually (higher compression with more artifacts), and/or temporally (lower frame rate).