LocalH

It needs both a switch mod and a slot mod. The Genesis has both a 50/60Hz setting and a domestic/overseas setting (with domestic referring to Japan), which technically gives you four possibilities - 50Hz overseas (Europe), 60Hz overseas (USA), 60Hz domestic (Japan), and 50Hz domestic. As far as I know, there is no actual 50Hz Japanese video, so I would imagine that setting is never used. Games can check these registers and the programmer can handle them however they wish. The newer the game, I've found, the more likely it is not to run outside it's original region. Some earlier games use one ROM for the world, but check the region to introduce language or graphics modifications in one region but not another.

Doesn't look like it to me. If anything, that's an S-Video capture - if that was 1280x720 and it had that much color bleed, then the display hardware used sucks ass and doesn't deserve to be called HD - especially pay attention to the red bleed on Sonic's shoes. I don't see any Y/C crosstalk, so I don't think it's composite (even the best comb filters don't remove all the crosstalk). My guess is that they either took a letterboxed signal and cropped it, or they took an anamorphic signal and vertically shrunk it (were it done this way, I would personally resize to 864x480, but I can't say for sure that they would have done this, so it's up in the air for me). Also, the fact that some of the frames are blended tells me that it is definitely an analog capture that's been deinterlaced - look at this image and notice the stairstepping on the water just left of Sonic, as well as the blending in his shoes. This is definitely not any form of HD, at all, or there wouldn't be any blending between fields, certainly not from a 720p source.

Technically, it's not a split mess. Other than a mid-frame backdrop change, there's no difference between that and any other game that exhibits this.

I would have given anything to play against Michael Larson, with the same knowledge that he had then.

The threshold is 127, as the game uses signed arithmetic to handle lives. If you gain 127 lives, you will have no problems at all. If you gain 128 or more, you will be able to continue playing without problems until you A) die, or B) get enough extra lives to cause the counter to wrap around to 0. The game doesn't check to see if you're out of lives until after you've died, which means you can technically have 0 lives and be fine. Oh, and just for the record, the minus world is technically world 36.

As well as going around to see beta copies of the most popular classic games, and the development of Crazy Otto), I'd also make a trip back to 1984 to play on the CBS game show Press Your Luck. =P

It's not cheating unless it's being passed off as a legitimate realtime run.

Well, I think the SVP only supported rendering flat-shaded polygons, but I'm not sure. There's not much documentation on the SVP anyway, so from a practical standpoint it probably wouldn't be as useful as the Sega CD, which has good documentation available.

That's why I think the Sega CD would be a better platform to attempt such a thing on (and no, I'm not doing it, I've already got a long-term Genesis game project underway), as you have a 12.5MHz 68000 as well as the full graphics mode I mentioned before, which would remove the requirement for doing a lot of bitshifting during rendering, since the screen is represented as a linear bitmap at one byte per pixel. You still might have to use 2x2 pixels, but it should be doable. Although there was Duke3D on the Genesis, I'm not familiar with how it plays. And it took every bit of the Genesis' 4MB of ROM space.

Yes, but the number of colors will depend on how large of a region will be used for rendering. Tile data is stored X-first, one nybble per pixel, so 32 bytes per tile, 16 colors per tile (color 0 is always backdrop/transparent). Plus, you have your nametables which determine X/Y flipping, patterns, pallets, and priorities for each tile, which takes 2 bytes per tile (so pallet selection is tile-granular). Nametables are laid out X-first across the whole scroll layer (which, for 320x224, would have to be 64x32). You have two hardware layers, A and B. So you essentially have four layers of depth but only two layers of actual background graphics. You also have up to 80 sprites at once (20 sprites or 320 pixels of sprite data per scanline), which I will call S, with the same priority, pallet, and X/Y flipping capabilities. Sprites are laid out Y-first. From top to bottom, you have high S, high A, high B, low S, low A, and low B. You also have a hardware shadow/highlight function which can be used in two ways - on a tile-by-tile basis using the priority bits in your nametables, which allows you to denote half or normal intensity, or through sprites using color $3E for half intensity and $3F for double intensity. You also have a total of 64KB of VRAM which holds everything mentioned earlier except the actual color pallets themselves, which go into 64 words of separate CRAM. However you set the nametables up, it will not be a linear pixel map. Since tiles are stored in memory X-first, it might be advantageous to set up your nametable such that successive tiles are placed on the screen Y-first. However you handle this, you'll definitely have to develop an algorithm to convert standard pixel coordinates to tile memory offsets. You also have to consider that VRAM has to be accessed through the VDP, which can be slow unless you disable tile rendering. You do have DMA which can mitigate this somewhat, but this requires building a buffer in 68k RAM and then transferring it during Vblank (potentially truncating the top and bottom of the screen by a few lines to gain more DMA time). As the system has 64K RAM total, this would require dedicating almost half of it to your VRAM buffer, including nametables and sprites. Truth be known, the Sega CD would be much more suitable for such a game. There are two mutually exclusive features, either of which will aid in development. There is a "full graphics mode" where you can use a block of memory on the CD side to access a linear bitmap at one byte per pixel, to gain speed at the expense of memory. You also have scaling and rotation hardware which could be used to handle the sprite scaling, but you can not use this at the same time as the full graphics mode. You also have a much faster 12.5MHz sub CPU in addition to the 7MHz main CPU (which you could use to split up game logic to further enhance speed). I'm pretty sure that a CD version could at least equal the SNES version, if not best it.

But still, CGA monitors are supposed to drop the green component partially such that the generated color is closer to brown than dark yellow. This is handled in the monitor, but the signal sent from the CGA card would indeed represent dark yellow if it weren't for the additional monitor circuitry.

I call bullshit. In those emulator screenshots, each one shows a slightly different pallet for the HUD and border elements, something that would NOT happen on a properly coded version - imagine if you were playing and the HUD flickered like hell because the pallet was constantly changing. Any competent coder would be able to split the pallet such that the HUD always uses the same colors, regardless of what pallet trickery you have to use on the main playfield. Hell, I've been coding on the Genesis for about six months and I could do it. Also, the Genesis can only output 61 colors without some sort of raster tricks - there are four pallet lines, and each one has 15 colors plus transparent (there are 64 pallet entries, but $x0 are only usable for the background color, not game graphics). These screenshots show 64 colors total, which is too much even if you deduct black for the background, leaving 63. Also, these screenshots show colors that the Genesis can't generate. There are only three bits per color component, stored like %0000 BBB0 GGG0 RRR0 in binary. The screenshots show colors that, when converted to Genesis color format, would reduce to identical values. Also, the TV screenshots don't mean anything. It wouldn't be too difficult to fake those. Number one, that looks like a stock Genesis, which has horrible video output, yet none of the typical artifacts of stock Genesis output appear on the screenshots (especially around the reds, which exhibit the worst artifacts of any other colors). Until I see a ROM, my proclamation is that it's complete and utter bullshit. All this guy has done is taken some screenshots from another version of DooM, reduced them in size by 1/2 using nearest neighbor resampling, resized them back up to their original size, slapped a HUD around it and then reduced to 64 colors. There is no DooM for the Genesis as of now.

There's also CGA composite, which is what you alluded to with your last two choices. Some games did it by using 640x200x2 but turned the color burst on, essentially forcing the composite monitor/TV to see the high-resolution bit patterns as different colors. Also, "brown" is technically yellow (in that it's generated by enabling R and G only) but monitors have circuitry to detect this yellow and drop the G component partially, leaving you with brown output.

The funny thing about that is they use SNES screenshots to advertise it - the large Bullet Bill is not actually in the NES HKO.

"Super Mario World" for the Genesis is actually a hack of a pirate clone of the NES game "Chip 'n Dale: Rescue Rangers" entitled "Squirrel King". The gameplay is nothing like an actual Mario platformer. There's also an unlicensed Genesis game called "Super 1998 Mario 2" (sometimes incorrectly called "Super Mario 2 1998") which is a bad port of SMB1 that uses SMAS tiles. It plays horribly, such that I've not been able to get past 4-4. There's also a hack of that game called "Sonic Jam 6" or "Super 1998 Sonic 6" which replaces most Mario graphics wih Sonic (but leaving the Mario head in the background of the bonus rooms), which I own on cart. This one is slightly less buggy, such that I can reach world 5 before eating it. One of my long term goals is to make an accurate port of SMB1 to the Genesis, with a possibility of selectable SMB1-SMAS tiles (or, if nothing else, two different ROMs).

This thread sucks about as much as the use of megabits instead of megabytes, simply to make cart sizes seem bigger.

I still say that 2600 E.T. was a good game in and of itself, it was just too damn hard for the target market. I'd imagine that if some of us had been ten or fifteen years older, we'd probably have had more fun with E.T.

Simple. NES-style slowdown actually causes the game itself to slow down, usually at a rate of half (example: in a game that scrolls the screen one pixel per frame, with slowdown the game will scroll one pixel every two frames). Frame rate drops refer to the game display showing less frames per second, but the game itself will not slow down in the same way that the NES will - generally, gameplay speed is fairly consistent regardless of the frame rate. Both are a manifestation of the same problem (system doesn't have enough processing time to do what it needs to do), but since today's systems have a sort of disconnect between the CPU and GPU, one usually doesn't affect the other.

I'm pretty sure those carts are for the PCjr, as I don't ever remember a 5150 PC that took carts of any form.

HAM is an interesting mode that basically compresses 12-bit data (4096 colours) down to 6 planes. You have a base pallet of 16 colors that can be used anywhere on the screen, or you also have the capability, for any pixel, to "hold" two of the RGB values from the pixel to the left, and "modify" the remaining one. Most HAM images will contain black and white in the base pallet, because otherwise it would take four pixels to transition from one to the other (the base color, then one pixel to modify each of the RGB values). AGA also offers HAM in an upgraded fashion - instead of using 6 planes, it uses 8, allowing up to 262144 colors with a base pallet of 64 colors. AGA also includes EHB for compatibility purposes, but there is also a bit that will disable EHB (as there are more than enough pallet entries available to replicate EHB functionality, it's only needed for OCS/ECS compatibility). HAM is only useful for still images or precalculated animation due to the aforementioned "fringing" - it would take too much CPU time to try to do the necessary calculations to minimize fringing each frame. At most, I could see using HAM as the background for a flick-screen game, as you wouldn't have to worry about the scrolling causing fringing.

Well, remember, there are more than just "games". I myself am more of a demo coder (see classic C64 or Amiga demos for reference), and it wouldn't be too hard for a demo to take 128KB or 256KB. (matter of fact, with padding I have a demo project that is already 128KB, although without padding it's much closer to 64KB).

I use both. I use real hardware when I can, and I use emulation in situations where it's not so easy to get code onto hardware. For example, for PAL C64 demos and games, I use emulation, but for NTSC and NTSC-compatible demos and games, I transfer them to a disk and run them on my C128D. With my Genesis, I can run ROMs of up to 2MB, so it's great for running homebrew code. Anything larger and I have to use emulation. Real hardware is also a requirement for proper homebrew development, somewhere along the line. If your code breaks on hardware then it's not good code, even if it happens to work on an emulator.

The register you speak of is $D030. You could also double the 8502 speed even during the visible screen, but the VIC-II will not be able to fetch the data necessary to display the screen, and instead will show pixel and color data based on the data currently on the bus. Of course, you could also disable the screen and get rid of this garbage, and use full 2MHz in C64 mode. This was most useful for operations that required lots of calculation but didn't require output until it was finished (for example, compressing or decompressing a large amount of data). In the same register as the 2MHz toggle, there is also a "TEST" bit which seems to disable the display when set - at least on PAL C128s, it's been discovered that when the bit is set, the raster counter increases at a rate of one per cycle. I don't think there's been much done with this bit on NTSC 128s, but it probably serves a similar function. Here's a page which goes into more detail. Also, some programs will fail on a C128 due to them writing to $D030 and either tripping 2MHz and screwing the screen, or tripping TEST and disabling the screen completely. Scrolls of Abadon is one game that I've found trips 2MHz.

They probably didn't have time. As you may know, the C64 was quite a rushed product. And, seeing as the slow serial actually has it's root in the VIC-20's VIA (broken shift register, thus all bits had to be clocked in software), I just don't think there was much they could do before releasing the 64. The only reason the C64 is slower than the VIC-20concerning stock KERNAL disk access is because the VIC-II eats 40 cycles every 8 lines, thus breaking the VIC-20 serial routines and requiring even more slowdown. It's also the reason why disabling the screen (or otherwise disabling badlines) suddenly makes the C64 compatible with the 1540. They finally got things right with the 128, however - fast serial and burst mode when using a 1571 in 128 mode, and 1541 compatibility elsewhere (in fact, the 1571 even starts up in 1541 mode by default, and automatically switches at the first fast serial access). And yes, it's well known that C64 BASIC V2 was complete shit - IMO, this is the biggest thing that led to the demoscene's creation on the C64 as opposed to some other machine - so many people hated the BASIC, that they learned ML in droves, and consequently some people got really, really, really good with it.

It covers both some of the information that Chris Senn has released, as well as information on the auction of the 7/18 proto.