Development Languages

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
mic_
Posts: 922
Joined: Thu Oct 05, 2006 6:29 am

Re: Development Languages

Post by mic_ »

This is true for most consoles/add-ons actually, they hate CD-Rs
Never had that problem with my japanese Saturn though. But maybe that varies between different units and/or brand of CDs.
Would be cool to have a CD-ROM emulator that reads data from an SD card as a replacement for the drives in these systems when they eventually fail (because the CD-ROM drive is probably one of the first things that will fail).
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Development Languages

Post by tokumaru »

Sik wrote:This is true even for the Dreamcast, which should be relatively new for CD technology.
I have dozens of Dreamcast games and only 2 of them are original. Never had any problems. With CDs at least, the controller port on the other hand has been dead for a while.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Development Languages

Post by thefox »

mic_ wrote:
Would be cool to have a CD-ROM emulator that reads data from an SD card as a replacement for the drives in these systems when they eventually fail (because the CD-ROM drive is probably one of the first things that will fail).
Yeah I had the same idea when I was cursing the CD-ROM drive of my PSX. I briefly thought about attempting to make an emulator like that, but didn't start on it because the connector is probably proprietary and I don't have the skills needed to do reverse engineer the hardware.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
FinalZero
Posts: 152
Joined: Thu Dec 03, 2009 7:27 am
Contact:

Re: Development Languages

Post by FinalZero »

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.
Indeed, Java's more focused on classes and avoids all the baggage that C++ has to carry for backwards-compatibility. But even Java's still stuck in some strange middle-ground by insisting on having static variables and methods. Scala did it right by replacing them with singleton objects (and introducing functional programming concepts). It may sound silly, but many times I've wished to inherit a static method, and singleton objects effectively do just that. Of course there's work-around ways to do these things in Java, but there's work-around ways for having classes in C too, it's what they're compiled down to after all!
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.
For some reason, I was thinking that the SNES had a 65C02.
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.
24 bits lets you address 2 MB of memory. Didn't most games fit in those 2 MB? What is a banking controller? Is that like the memory-mapped inputs that the NES had that you write to to change banks?
mic_
Posts: 922
Joined: Thu Oct 05, 2006 6:29 am

Re: Development Languages

Post by mic_ »

24 bits lets you address 2 MB of memory.
2^24 Bytes = 16 Megabyte.
User avatar
FinalZero
Posts: 152
Joined: Thu Dec 03, 2009 7:27 am
Contact:

Re: Development Languages

Post by FinalZero »

mic_ wrote:
24 bits lets you address 2 MB of memory.
2^24 Bytes = 16 Megabyte.
For some reason I thought bits instead of bytes. Yes, you're right, 16 MB.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Re: Development Languages

Post by MottZilla »

Sik wrote: 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.
While they certainly read a pressed disc better, many CD consoles will read good quality CD-Rs just fine. The PS1 has some interesting issues that some attributed to playing CD-Rs. Early versions had the CD lens assembly close to the power supply where most of the heat was generated. The heat over time would warp the plastic and could cause alignment issues that would cause reading problems. Newer models use different material less vulnerable to this and other later models move the position of the lens further away from the power supply.

I've tried CD-Rs on every system I've had access to and they all worked to some degree. Sometimes they are picky about the type of media you use and your burner matters too. GameCube was pretty picky. PS1 as well wouldn't let you use bargin crap CD-Rs. DreamCast did though. I remember using Office Depot crappy CD-Rs just fine. The Sega Saturn seemed to read anything I threw at it too. PS2 I think was a bit more picky. Sega CD seemed to eat up whatever you threw at it. PC-Engine like PS1 wouldn't let you be cheap. But these are just my observations, I never did any scientific test. So I'm not sure what you mean by hate CD-Rs. The machine can't hate, it's a machine. It may have trouble reading low quality CD-Rs though. But most systems will if you have the right media and burner.
User avatar
Movax12
Posts: 541
Joined: Sun Jan 02, 2011 11:50 am

Re: Development Languages

Post by Movax12 »

Xbox1 will almost never read a CD-R and about half of xbox1 DVD-ROM drives will not read DVD+R. (All will read DVD-R.)
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Development Languages

Post by Bregalad »

The fun thing is, my PS-One read music CD-R perfectly fine without any skipping problems, but game CD-Rs have some problems. They work, it's just there is occasional read errors, which causes some skipping in music and FMVs.

My only guess is that those occasional read errors only happen when reading the CD at 2x speed, because that's the only technical difference between a CD being used for a game and for a music.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Re: Development Languages

Post by MottZilla »

Well it's also a different format. Mode 2/XA I think.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Development Languages

Post by Bregalad »

Yes - but I meant the laser reads the bits the same way no matter what the format actually is - so the format should make no difference, why would games causes problem when a musical CD causes none ?

Reading speed is the only thing that could causes the problem. Perhaps someone could point me to a game which uses 1x CD-ROM speed for streaming it's videos (which is probably very rare - as the quality would suffer) and I could enforce this supposition.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Re: Development Languages

Post by Shiru »

Isn't audio CD players ignore any errors during read, which is may be acceptable for audio, but certainly not for data?
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Development Languages

Post by Bregalad »

Both audio (CD-DA) and XA sectors uses whole sectors of 44100 * 2 * 2 / 70 = 2520 bytes, without correction data. Read errors can be detected, but not corrected, causing some skipping.

However I still have occasional problems with the streamed music in Suikoden, which is not XA, so it is probably stored in sectors with correction errors. Perhaps the Playstation still can't correct the read errors even with the correction data, if there is too much errors in one reading. The game should then retry to read the sector, but when the data can finally be read successfully, it's too late and it caused a glitch in the music.
Just an assumption.

I also have the game crashing sometimes which is very annoying.


EDIT : You are right there is not even a CRC or anything in the audio CDs, so read errors can't even be detected. I wonder how it comes CDs skips when there is read errors instead of playing some kind of white noise... does't make much sense
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: Development Languages

Post by ccovell »

Of course, on CDs the physical pits themselves are encoded, 8 bits -> 14 bits or something like that, so that parity errors can be detected and the misread sample skipped over... that's why there's no white noise coming out of the CD when there's a scratch.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Development Languages

Post by tepples »

The EFM (eight to fourteen modulation) is for clock recovery and speed control, as it guarantees a transition from pit to land or vice versa no faster than every three units and no slower than every fourteen, not for error correction. There are two layers of error correction on a CD. Both audio CDs and CD-ROM have CIRC, or cross-interleaved Reed-Solomon coding. CD-ROM has a second Reed-Solomon ECC layer at the 2K sector level, and audio CD players trigger some sort of DSP waveform interpolation if a burst of errors is so long that CIRC fails to correct it.
Post Reply