Chilly Willy

You can't use a modern CD in a SCD without replacing the BIOS. The CD in the SCD is actually a standard audio CD, and the SCD hardware includes a chipset that turns the raw audio stream back into CD data. All the oldest CDROMs worked that way to make use of cheap audio CDs.

I did say "in electronics", and it is. Also, that article says that beat frequencies are related to heterodyning. Gives a link in the related fields list and everything. 🙂 But yes, what you were talking abut here is probably more properly referred to as beat frequencies since you're talking acoustic waves.

In electronics, that's called heterodyning.

As far as I understand it, the 68K always runs at the master clock / 7. The master clock is 53.693175 MHz for NTSC, and 53.203424 MHz for PAL. The Z80 runs at the master clock / 15. The VDP runs at the master clock / 10 for H32 mode. When Sega added H40 mode, they left the timing at H32 speeds, but changed the VDP clock during the active line to the master clock / 8. During the sync, it switches back to / 10.

Once you understand the principles of old-school 3D, you can then read the Jaguar Hardware manual with a new eye toward what the different parts can do to handle each part of the 3D pipeline. Using the GPU to do rotations, projections, and rasterizing the polys, using the BLITTER to do the raster line... but you need a firm grasp of the subject first or the hardware won't make any sense.

A common problem on the A400 was that the serial wasn't buffered, so the POKEY would eventually degrade to where serial no longer worked, and your drives no longer worked. I replaced the POKEY on my A400 twice for that reason before finally retiring it. So while it could be a cold solder joint on the SIO connector, it could also be a worn out POKEY.

Also, many games never expect you to be using the SIO during the game, so they feel free to reuse ram used by the SIO for game data. You may need to back up and restore SIO ram locations when trying to use the SIO. I don't know if Miner does or not, but it seems like something that should be checked.

Very good and comprehensive. If you're just interested in 3D rendering in the old-school manner, Chris Hecker's articles on the subject are a great way to get started. https://www.chrishecker.com/Miscellaneous_Technical_Articles#Perspective_Texture_Mapping

Sigh. Very briefly... Hardware: The Jaguar video has the ability to have a Z buffer. The JRISC processor known as the GPU has some matrix math operations that can be used for 3D calculations. The BLITTER can draw AFFINE mapped textured raster lines with gouraud shading and Z compare. That's pretty much it. Everything else is just software. Perspective correction has nothing to do with the Z buffer. The Z buffer is to avoid overdrawing pixels that are closer to the camera. As mentioned, the BLITTER does affine mapping, not perspective correct mapping.

Well, like I said, that 1536 color palette is kinda 1536-ish... two thirds of those colors cover the same range as the normal 512 colors, just slightly off on the exact analogue voltage. They're also not directly set - the 64 color registers set the actual colors, and shadow/highlight modifies just THOSE colors slightly one way or the other. So it's kinda 192-ish out of 1536-ish... kinda, sorta, in a manner of speaking, but not really. It's just easier to say 64 colors out of 512 and leave the rest to the programmers and artists. Some will take advantage of it, and others won't.

Sega really missed the boat on the SVP. If any cart needed lock-on technology, it was this one. Sell Virtua Racing as the initial SVP game, then carts specifically for lock-on for the SVP. That way only ONE game was $100 instead of every game using the SVP. It's probably why there were no other SVP games... among other reasons.

That MIGHT have been an April Fool's Day joke (check the post date). However, that's exactly the route the Super GrafX took to extend the Turbo GrafX-16 console - add another video chip/vram, and then add a new chip to mix the two video outputs. Basically, this gave the SGX dual plane graphics compared to the TG16's single plane. They felt the number of colors wasn't an issue, merely that they needed more planes/sprites to compete with the MD and SNES. On the Atari. a dual ANTIC/GTIA could give you dual plane "normal" graphics, or be mixed to give more colors.

It is sad, indeed, but given that 40-some years have passed since our beloved Atari first appeared, we must expect more of these to come.

Yes, just like that. 😁 It's quite expensive if you're not using rechargeable batteries.

Easier, certainly, but modifying the existing hardware (sort of) is more interesting, IMHO.

I think the most interesting idea is to start with the existing A8 core for something like MiSTer and then start making improvements as if this were a real Atari in the 80s. Add another POKEY for stereo. Double or quadruple the speed of the chips. Make derivations of the existing graphics to take advantage of the speed. Make the 6502 dual core. What Atari MIGHT have done to improve the A8 instead of just more of the same.

While a Genesis controller might work on the Atari, it's better if you modify it specifically for the Atari. I did this myself some time back. Here's the topic I made on it: Two triggers compatible with the majority of Atari software, a separate jump button, and the ability to read the start button. What more could you want? 😎

Yeah, lots of 68K based computers/consoles (like the Amiga and Genesis) warned against using clr on hardware registers. It's one of those things you learned while programming in assembly on those systems. Jaguar is just another with limitations on instructions like clr.

I think this comes down to game design - remember that you don't REALLY have 64 colors, you have four banks of 16 colors (one of which is/may be transparent). You often use maybe one bank of the palette for the background, then each of the other three banks to make sprites different colors. So much of the screen is just 16 colors, while little sprites flitting around here and there on the screen may or may not be 15 to 45 other colors which may or may not themselves be different from the background. If the game is a port of an ST game, it's often just 16 colors, period. I've read articles on the number of colors in games on the MD, and very often, it's in the range of like 20 to 40 colors! A GOOD game pushing the graphics might be 80 colors or so. There's also the issue of color selections - sometimes, you have no choice in not using a lot of colors. Example: you've got a game set in the forest with lots of trees and not much else. You've got seven shades of pure green on the MD palette. With a touch of red and blue thrown in here and there, you might push that to 16 shades of mostly green. This is a case where being able to use shadow or highlight might help as 7 shades of one color is not that great. Remember that the MD palette consists of three fields of 3 bits each: blue 0 to 2, green 0 to 2, and red 0 to 2. Level 0 is black, and 7 is full brightness. The first VGA used six bits per field, allowing for a much wider range of colors.

For shadow only, you can use the priority bits on the tile name to control shadow/no shadow for the entire tile. That's maybe the easiest way to get large area shadows, but you give up priority control for shadows. Sprite marking allows shadow and highlight, and on single pixels. Also, I think you're confusing palette with colors. The Genesis only has 64 total colors that can be displayed out of a palette of 512 colors. You can change those 64 color registers on the fly, allowing for more unique colors on the screen. Shadow and highlight applies at that 64 color register level, so you can show 64*3 or 192 colors out of (theoretically) 1536 colors; 64 out of 512 BGR colors, 64 out of 512 shadowed colors, and 64 out of 512 highlighted colors. Plenty of games change the colors on the fly to get more unique colors on the screen, like the water level in Sonic games. That's done by changing the color registers right where you switch from air to water. There's a limit to how many color registers you can change on a line without affecting the display. Sonic actually goes a bit beyond that number resulting in noise in the line where the colors change, but the game uses the water tile surface animation to cover the noise.

Shadow/highlight is kinda weird... it's not done on the digital side, it's done on the analogue side. The way it works is you overlay a region of the screen with a sprite set to certain pixel values, and where it overlaps the layers, the layers are either made brighter or darker. Technically, what the Genesis does is divide the analogue RGB signal in half; if you are outputting shadowed pixels, you use that signal; if you are outputting highlighted pixels, it then adds half the full brightness to the cut in half RGB. As this is all analogue, the levels are not quite the same as corresponding levels of the normal RGB signal. So you could think of like 512 colors in the palette from the normal signal (9 bit BGR from the cram), plus 512 more colors at half the brightness (shadow), plus 512 more colors from half the brightness + half full bright (highlight). So demos that use shadow and highlight for more colors often claim 1536 colors. While the analogue nature means this is technically true, half of each is generally going to be very similar to the normal colors, so it's really more like 512 + 256 + 256, or 1024 colors. Remember that these colors are going to be limited as they need sprites to signal where they appear, which means sprites for gaming are going to be limited if you're using them to generate more colors for the layers. In general, this sort of thing is only done for static images. In a real game, shadow would be for things like making shadows of sprites hovering over ground, for example. Highlight would be for like a spotlight affect on the background layer. You'll see that in many MD games. Using these modes to do higher color images is mainly only seen in static image demos.

The Genesis has left and right audio input lines on the cart port. They are used for the 32X audio on the 32X, so you could easily use them for music and sound on a game cart. Example - one of the Yamaha FM chips has four FM channels and five ADPCM channels. You could stick that on a cart and feed the DAC outputs to the cart lines to mix with the Genesis audio. Combined with the internal Yamaha chip, this gives you ten channels of FM and five PCM - plenty for kick-ass music and sounds. So the above quote seems to indicate that at least part of what the Paprium cart does is extra sound for the game. That's relatively simple for a custom part on a Genesis cart. Honestly, if all it added was PCM channels for better digital sound, that would leave a lot more horsepower on the Genesis to do more graphically. Trying to do GOOD PCM on the Genesis with the Z80 and one DAC inside the YM2612 is a pain that consumes more effort than almost anything else, and still sounds not that great. It's one reason why the SCD came with a PCM chip with eight channels and 64KB of sound ram in addition to CDDA. That it says "primarily" means that is has some secondary uses as well. Maybe it's used to decompress tiles on the fly for DMA to VRAM for extra animations for characters and backgrounds. That could make things easier for more detailed backgrounds. Instead of storing all frames of animated tiles in VRAM, you store one frame and reload those tiles on the fly from the cart which decompresses them on the fly. SNES had some accelerator chips that did similar tasks.

Very neat! Thanks for the link.

Nope, and neither has google. 😆 A link or two would be nice... I was thinking about the existing Atari 800 core for MiSTer: https://github.com/MiSTer-devel/Atari800_MiSTer It would be interesting to come up with extensions to the architecture that Atari never made... making the processor twice as fast and adding improved graphics and sound... that sort of thing. Once you have a decent updated Atari, THEN get a SoC made.

Incorrect. The Amiga didn't compare to the ST in MIDI because Commodore didn't include a FIFO on the serial receive register in PAULA. Even with the lack of a FIFO on the serial receive, MIDI worked fine as long as you kept the DMA contention of the video down - for example, running in four color hires mode instead of eight or sixteen color mode. A2000/A3000 people worked around the issue by using one of the many cheap serial cards available for the Amiga. These would use common PC serial controllers with a 16 byte (commonly) FIFO on the receive port. IMHO, the primary reason more people chose the ST for MIDI over the Amiga was that the ST had MIDI ports built in while the Amiga required at least an RS232-to-MIDI adapter, and maybe an extra serial card if you were doing really heavy MIDI traffic.