VCD Player for PSX (software based)

[nocash]

Just released my VCD Player for PSX, fully software based, without needing extra video/audio hardware. The VCD player is included in my kernel clone (which can be used as BIOS ROM replacement, or as Expansion ROM, ie. with Datel or Xplorer cheat devices). The kernel binaries are in included in no$psx v2.0 (you can extract the raw ROM-images, or installer-files via Utility, Remote Access). For more installation info, see Kernel Clone for details.

The VCD project is inspired on the asian SCPH-5903 console with its hardware based VCD decoder, which made wonder if it wouldn't be possible to make a software based VCD decoder (apart from wondering what VCDs are; if you don't know: VCD are Video CDs, mostly popular in asia, with quality lower than DVDs, but roughly similar to VHS tapes).

If anybody is interested, here's the VCD source code (can be assembled via no$psx v2.0, see Utility, Assemble File):

vcd.a22.txt

I've tried to make best use of the hardware to get everything working fast enough to view movies. And, to some level, I got it working at around 10fps, monochrome, with 11kHz mono audio. VCDs at full quality would be around 30fps, color, 44.1kHz stereo. Nethertheless, the movie is playing at full speed with continous audio, and actually doesn't look too bad.

Screenshots, showing The Fifth Element on SCPH-5903 hardware (color) and Retail PSX console (mono)

5thElementHwDecoder.jpg

5thElementSwDecoder.jpg

Some Making Of notes
The first problem has been finding VCDs which are nearly unknown in western world. I finally got two sample VCDs, and -shortly after - four real movies on pressed discs from TriMesh. Then I've blown up a bunch of weeks on learning how to implement the MP2 audio and MPEG1 video decoding, and first implemented it as 80x86 asm code (which is now also included in no$psx, somewhat emulating the SCPH-5903 hardware; with 30fps/color/stereo).

Next, I've ported the 80x86 code to MIPS, aiming at 10fps/mono, and the first built did actually reach around 5fps, which wasn't too bad, considering that it wasn't yet really optimized for the PSX hardware. So I've blown up some more weeks on optimizations: Using the MDEC hardware. Using DMA transfers. Using some macros for some functions. Squeezing most variables & cpu stack into the 1Kbyte scratchpad (=fast RAM) memory. Changing byte operations to process four bytes at once via 32bit memory access, in some cases also doing multiple 8bit operations via 32bit registers (for color additions & saturations).

The funny part was when I got it working at 10fps, and then TriMesh mentioned that audio decoding might also consume a lot of cpu load. I didn't believe it, and mounted to audio engine the next day - which dropped the frame rate back to around 5fps. Okay, maybe I had underestimated something. But then, reducing the sample rate, dropping stereo, unrolling some loops, and optimizing some stuff helped to reduce the audio load.

Oh, and side note: There's some profiler in no$psx. I don't if anybody has ever used that feature, but it was really useful to figure out which functions did eat up how many clock cycles (and to optimize the code as best as possible).

[CodeAsm]

Ow this sounds cool. Also the general kernel replacement. Should this be supported by all ps1 hardware or on wich did you test this?

[Someone]

Wow, that's quite an achievement. If back in the day somebody has told me that PS1 can do it, I would never believe in it.

[Administrator]

Why did Sony even make a VCD system. Isn't the STR format decent enough? I mean, sure, maybe they were trying to market a whole format (in this case, Video CD's), but I'm sure Sony could have come out with their own movie format for the PlayStation which used the STR format and regular MDEC in the R3000A. Only thing would be you would have to swap discs or if they used a double-sided CD-ROM, turn it over like a Laser Disc.

What's cool though is with PSIO, you can easily swap between multiple ISO's instantly, so it means after 40 odd minutes of playtime from one ISO, the program code would tell PSIO to switch to the next ISO and continue playback of the next 40 odd minutes minutes seamlessly. A whole movie could be played on the PSX without any delays or pauses from the SD Card

I made a "FRIENDS" short which I used as a test about 4 years ago. The quality is really good. Perfectly watchable. Doesn't look good under emulation, but on a real PSX with a CRT it looks fine. Just demonstrates my point

https://drive.google.com/open?id=0B_GAa ... m54SkxnY1E

[nocash]

Ow this sounds cool. Also the general kernel replacement. Should this be supported by all ps1 hardware or on wich did you test this?

The kernel and vcd player should work anywhere from early psx to late psone. In japan/asia, one would need a modchip as extra hardware for the vcd player.

Wow, that's quite an achievement. If back in the day somebody has told me that PS1 can do it, I would never believe in it.

Thanks, I just made it hoping to surprise somebody, even though I've no idea if anybody will ever have practical use for it these days, especially when living outside of asia. But well, if it's useless... maybe that's making it even more surprising : )

Why did Sony even make a VCD system. Isn't the STR format decent enough?

VCDs are a standard media for movies in asia, so it makes some sense to produce a hybrid console that can be used to watch those movies, as well as playing games.
Apart from that, VCD (mpeg1/mp2) has much better compression ratio, reaching fullscreen including overscan with 72minutes at 30fps per disk. Whilst psx STR files (mdec/adpcm), not sure there... I think it's often something like 36minutes at 15fps and/or with large black screen borders.

This page https://wiki.multimedia.cx/index.php/Pl ... on_Decoder claims that many PSX games use huffman to improve MDEC compression, never heard of that before - is that true?
If yes, then they have adopted that idea from the mpeg/jpeg world. But that alone wouldn't be too much of an improvement. The other important mpeg feature is storing only one or two I frames per second (full pictures, similar as used by mdec), are storing everything else in P and B frames (differences to already decoded pictures, ie. if all pixels are same then those frames would simply contain zero-filled bitmaps, taking up very little memory in compressed form).

[raveracer]

Excellent!

For performance optimization, making use of the GTE's high-speed 16-bit fix-point matrix/vector functions may off-load the main CPU for both motion-picture and audio decompressing. This also eliminates many context switching.

Another, the MIPS has 32 general-purpose registers, 8 times than those of the 80x86! Making fully use of them can save a lot of memory accessing time. So instead of a near direct mapping of 80x86 assemble code to MIPS, using C for some routines with a high level compiling-time optimizing option should worth a try, as modern C/C++ compilers can do quite good register-level optimization for RISC processors,

[nocash]

Hmmmm, I think those modern C/C++ compiler optimizations are a myth originated somewhere in the 1990's. I've haven't yet spotted any such optimized code when disassembling software for PSX/GBA/NDS/DSi consoles, from my experiences, compiler code tends to be at least 10x slower than ASM code, and I would doubt that other/newer compilers could do better any time soon.

For 80x86 I can see 7 general purpose registers (or more when splitting eax to al/ah etc), and 28 general purpose registers for MIPS (without r0,k0,k1,sp). But yeah, when using ASM for the sake of performance, one should avoid using RAM or other slow stuff and take best use of all available registers, which, I think the vcd player is doing that quite well (and the MIPS version is of course matched to the capabilities of the MIPS processor, not to that of 80x86 processors).

One thing that is slightly bugging me about the register usage is that the vcd code is using r30 as base address for main ram variables (when not using kernel functions, one won't need to waste a register for that, and could as well use r0 as zero base address... in most cases it won't make too much of a difference to have a spare extra register though).

Using the GTE to eliminate context switching would be great... or, wait, what the heck is context switching? I don't think that the vcd code is doing such a thing (?) but using the GTE for other things would nice... On the other hand, the video IDCT core is already done using the MDEC hardware, and for the remaing audio/video video maths... most of the GTE stuff is focusing on coordinates, at first glance that doesn't look to suitable for pixel or audio maths, and I didn't spend too much time about thinking about using the GTE for that. But if somebody finds a way to get either audio or video faster via GTE, let me know!

PS. Here are the no$psx compiler stats for the VCD player (the first two lines are nonsense/bugged, but the other lines should give some idea about which functions are most time consuming; the timings don't recurse things like code-cache misses, but the overall result isn't too far from real hardware).

VcdProfilerStats.gif

[Someone]

Hmmmm, I think those modern C/C++ compiler optimizations are a myth originated somewhere in the 1990's.

This is not a myth but reality. 90's are in the past and modern compilers really evolved pretty good. You can see it in action here:
https://www.youtube.com/watch?v=zBkNBP00wJE

[nocash]

This is not a myth but reality. 90's are in the past and modern compilers really evolved pretty good.

Yeah, possible, maybe compilers are getting better over time. Or, to be pessimistic, maybe they will require more and more resources, ending up with code that is "faster" than from some recent era, but without being able to run on computers from that era.
The video with the Pong compiler for C64 does actually show support for old hardware, but then, moving three sprites isn't that impressive - and doesn't mean that it could be used for "real" C64 projects with bigger arrays & bitmap graphics & such stuff.
Apart from the compiler, the source code from compiler users can be also a problem. I've seen some open source mp2 audio decoders, and they all used divide/modulo operations, almost as if they've never heard about clock cycles (or they believed that they could do what they want, and that the compiler would then optimize it for them).
To me, handcoded ASM remains faster (unless somebody takes the time to compile existing mpeg1/mp2 source code for the PSX and actually archives faster decompression with it, that would somewhat break my heart - but I'd still like to see that).

[RetroGamer]

Can I assembly this code to EXE in no$psx program and burn to CD and boot on real-PSone and watch VCD video?

[nocash]

Yes, that should work. Rename the EXE to PSX.EXE and add the usual licence sector with PSX logo in it. And you'll need a modchip to get the CD booted.

[RetroGamer]

I tested this program and it works as it should. Can I schwitch video mode to PAL? Default VCD player starts in NTSC mode.
Would it be possible in an assembler to write an MP3 player as another challenge?

[nocash]

Why PAL, what for? It's currently NTSC only, the main issue I could think of would be wrong aspect ratio for PAL videos, but I guess that 99.5% of all VCDs are NTSC videos. And the color encoding, the video output is monochrome only, so colors shouldn't matter, unless you get some unexpected NTSC artifacts on PAL monitors?

I've peeked at MP3 source code some weeks ago. It's looking more complex than MP2 audio, but it shouldn't be more complex than MP2 plus MPEG1 video, so it should be doable (and the PSX might be fast enough for it). Pro would be that MP3 is much more popular than VCD in western world, but in practice there's probably little interest in burning MP3's to CDROM instead of using modern SD card based MP3 players. So it would be just a fun project for the sake of coolness, without practial use. But yeah, somebody should really do that someday : )

[RetroGamer]

I asked for PAL mode because I have VCD movies recorded in PAL and the image looks like it was stretched vertically down the display area.

[LameGuy64]

I remember seeing a post in this forum of a MP3 player demo for the PSX which read an MP3 file from the PC using PCDRV commands, decoding a few seconds of it, converting the decoded audio data to ADPCM which is then uploaded to the SPU for playback. Clearly not real-time playback but I thought it would do great as a base of sorts.

[nocash]

Ah, okay, if it's a PAL disc then the aspect ratio will be wrong/stretched. I don't have a PAL disc myself (apart from the demovcd which is more focusing on VCD2.0 menues than on actual movie viewing). If you could upload some small freeware PAL VCD disc image would be cool. But it might be a bit difficult to squeeze the higher resolution picture into VRAM (or a dirty solution would be to crop it to 256 scanlines with small black borders at upper/lower screen edges).

Yup, I've seen that MP3 player, too. http://www.psxdev.net/forum/viewtopic.p ... t=92&p=517 going by the readme it doesn't support realtime decoding, nor cdrom loading, nor playing songs longer than a few minutes. But yeah, it's really the first PSX MP3 player that doesn't work ; )

[likeabaus]

I tested this program and it works as it should. Can I schwitch video mode to PAL? Default VCD player starts in NTSC mode.
Would it be possible in an assembler to write an MP3 player as another challenge?

Any chance you could upload you're working iso somewhere, so others could just burn and go?

[RetroGamer]

I uploaded VCD PAL ISO (.nrg extension from Nero)-TestCard and short movie. Have fun!
https://www.easypaste.org/file/2AQCxbnq/VCD.nrg?lang=pl

[RetroGamer]

Nocash, can You add PBC support to this VCD player?

[nocash]

Why, what for???
From what I've gathered, the Playback Conrol feature is almost always useless & often containing corrupt/bugged data.
I think the best way to support PBC discs is to leave PBC unimplemented, isn't it?

PS. here are my findings on PBC: http://problemkaputt.de/psx-spx.htm#vcd ... otitemnnnn