nesdev.com

C++ isn't strictly a superset of C, but the differences are subtle enough that it's not really wrong to say it is.

C++ is much more complicated than C, and yes it has a lot of obscure features, but the primary feature of C++ over C is classes, and specifically the inheritance of virtual functions in derived classes. This feature is used heavily in modern code. You can write C++ without classes, and there are several other useful features of C++ (templates, const, operator overloading, etc.), but really its reason for being is classes.

In general, people who choose to use C instead of C++ do so for a specific purpose. Sometimes it's because they are working on a specific processor that doesn't yet have an effective C++ compiler. Sometimes it's because they specifically want to avoid the complexity of C++ (e.g. the Linux Kernel).

Alternatively, there's Java, which is more focused on classes and that kind of high level feature set that C++ has, but with a lot less complexity than C++ because it's not built on top of a low-level language like C.

The last systems to have ROM banks would be GameBoy/GameBoy Color and SNES. SNES doesn't need a banking controller, though they did exist. But you still have banks in the 65816. GameBoy Color lasted a bit longer than the SNES though. N64 didn't have them as it had a multiplexed bus and didn't actually execute from ROM as far as I've heard. The Cartridge was used more like an attached Disk. And CDs and DVDs are not like rom banks at all. They are just discs. ROM banking responds instantly. Look at Castlevania on NES. Data is accessed as fast as the 6502 can call for it. Then look at Castlevania on Famicom Disk System. It takes time to load and only so much can be loaded at once. Not very alike other than being a method to access more information.

I've heard people say that PS1 games can sort of function like Cartridge games in the way they load memory and then run, but this is more like the old Famicom Disk setup again. Only not as limited obviously.

One last note, I do not know when the NeoGeo Pocket existed but it may have used ROM banks, I don't know though. Also there was the Wonderswan but again I have no idea. As previously stated, cartridge systems that did not use ROM banking or did not do so very much would include Sega Genesis and N64 but probably some other less known ones.

In volume, CD ROMs are much cheaper to manufacture than cartridges, which was the biggest reason for switching to optical media like that. The other is they have huge storage capacity, but that was secondary. The other thing you need to support this is enough RAM to store all the code and data you need to access quickly at any given time. So, once CD-ROM and RAM technology had gotten cheap enough, there was little reason to manufacture cartridges anymore. (Handhelds kept using them for durability, i.e. lack of moving parts.)

I don't understand the statement that PS1 used the CD "like a cartridge" either. Though, many early PS1 games would load most of the game into RAM, and then just use the CD for audio. You could take out the CD after starting your game, and put in your own audio CD to change the soundtrack in some games (until it needs to load a new level).

I think that the comparison was in the sense that with CDs and DVDs you have to copy sections of data to RAM before you can use them, so that block of RAM is somewhat analogous to a ROM bank that's currently selected (i.e. in both cases you don't have immediate access to the complete data). Obviously, selecting a new bank in is much faster than loading data from a CD or DVD.

The Super NES in mode 21 had a big 4 MB linear ROM from $C00000 to $FFFFFF.
The Genesis had a big 4 MB linear ROM from $000000 to $3FFFFF.
The GBA had a big 32 MB linear ROM from $08000000 to $09FFFFFF, but like the N64, it had an interleaved bus so consecutive access were faster.
The DS is like a PS1: the Game Card is read like a disk, well maybe a really fast disk like an SD card, and data must be copied into the 4 MB RAM before it can be used. The PSP Go and PS Vita work the same way. One DS game (Nintendo DS Browser) required an accessory that added an additional 8 MB RAM in the GBA slot.

SNES memory is not truly linear, at least from 65816 and assemblers standpoint, unlike Genesis. It has either 32K or 64K banks. You can easily put, say, 200K of linear data in a Genesis program without any effort, but you'll have to split it into pieces for a SNES program.

As I understand it, Mode 20 data has to be split into 32K banks: $808000-$80FFFF, $818000-$81FFFF, ... Mode 21 data, on the other hand can be accessed linearly. True, the program counter won't cross 64K boundaries, and there's a penalty for 64K boundary crossing in indexed addressing modes analogous to the penalty for 256 byte boundary crossing on the 6502. But what am I not seeing? If it's a problem with the assembler and linker not supporting what used to be called "huge" arrays back in the days of 8086 real mode, that was a problem with some 8086 tools too, and tools can be fixed.

32K or 64K, banks are still banks. Not much difference, actually. I'm not interested in digging into technical details, I'm just telling as a programmer that worked with Genesis and SNES: handling large amounts of data is way easier on the Genesis, just like on modern PC, and on the SNES it is quite similar to the NES.

Using CD-DA instead of ADPCM (either VAG or XA) would be a pretty bad design choice (even if several games did it) :
- You can't loop a song without having it stop then restart
- Takes 4 times more space on the CD

The only pro is that you can listen to the music with a regular CD player.


I just wanted to add that this is totally true. It's in fact the opposite of ROM banks : Instead of switching the data in several clock cycles or so, you need to load it off the disc which is much, MUCH slower, and can't be done many times a frame like bank switching does.


Some opcodes allows you to use 24-bit addressing, removing the overhead of bankswitching.


Yes, this should be especially interesting for homebrew. Distributing burned CDs is like 100 times easier (and cheper, which is important if you don't make profit, as the end product will also be cheaper) than manufacturing cartridges.

The TurboGrafix-16 / PC-Engine indeed looks like an interesting platform for homebrew as it can support CDs. Unfortunatly it wasn't released in Europe, so almost nobody has this console except collectors.

Yeah, I didn't say it was a good idea. It was done in many games though (and that list isn't complete by any means).

Many games on that list (and not on that list) just contains 1 single "trivia" track which is not actually used in the game.

They're quite easy to find though. Consolegoods are selling unused/boxed PAL versions of the TurboGrafx for around 80 EUR.
If you want a TurboDuo (HuCard and CD-support all in one unit) the price will probably double, and you'll most likely have to settle for a used NTSC unit (not that NTSC/PAL matters that much unless you plan on using it with a very old CRT TV).

It should be noted that some TurboGrafx 16/PC-Engine CD systems do not like CD-Rs. Some will end up getting the laser sled *stuck* at the outter end of the track. I had a PC-Engine DUO that would have that happen with particular burned games. However atleast one homebrew game has been Factory Pressed. And a second one they are trying to get pressed.

The second game is already pressed and done, but they are doing the bonus material on CDR IIRC. It should be noted that Nero has been found to do some weird things when the game is in ISO/WAV/CUE format. On some setups, it seems to ignore the 'MODE' assigned to the data track and instead burns it using a newer mode and really gives problems for some TGCD systems. The trick is to analyze the CDR and make sure it's not burned as MODE 2 data (I forget which form off hand), but as MODE 1. If you give Nero a BIN/CUE, the sector format is preformed and Nero will burn it as MODE 1. None of my versions of Nero have done this, but others have confirmed this problem. The current solution was to mount the IUSE/WAV/CUE in a virtual drive then rip it as a BIN/CUE, then burn it. It's amazing the Duo units can even read MODE 2 form 1 (or form 2, I forgot).

It's not recommended to use a PAL Turbografx with a CD unit. For one, I know of no one that has one so your base will be null and two - PAL TGs have different timings and some CD games will be effected by this (possibly a few hucards as well). The PAL units are a collector/novelty thing; stick with NTSC/J machines. Turbo Duo or PC-Engine Duo units (all in one CD unit) are the best option. There are plenty of info on the system about caps and repairs and plenty of experienced people that offer services for repair. The laser modules are replaceable too.

If you buy a US TG16 and then later decide you want a CD unit, then the original US CD addon will run you quite a bit of money. You can use a japanese cd addon but you'll have to make your own cable for as the connector shape is slightly different and it'll look terrible as combo. A white PC-Engine or grey Core Grafx unit would be a good choice for a first initial Hucard only investment, then a SuperCDROM^2 unit can be purchased later (it already has the system card built into it and is able to use the Arcade Card Duo which is cheaper of the arcade cards). I personally think the SuperCDROM unit has a better laser unit than the Duo's. I've never heard of or seen one get the 'parked laser' issue like some original Duo units (the Duo R and Duo RX are white model Duo units and are the last revision hardware to be made, thus supposedly the best laser units too) that haven't had a replacement laser module. Stay away from the 'breifcase' japanese CD addon; it's the original CD addon unit and probably well worn/has issues reading CDRs.

This is true for most consoles/add-ons actually, they hate CD-Rs by general rule as the laser barely has enough power to read pressed discs and more often than not will have trouble reading CD-Rs as the laser needs to be stronger (and CD-RWs outright aren't recognized). This is true even for the Dreamcast, which should be relatively new for CD technology.