Official PSIO Development Thread

I believe karsten is referring to FLAC: Free Lossless Audio Codec

 

Well, I don't know how PSIO is related to FLAC.
Theoretically 33MHz MIPS can be enough to decode FLAC. Practically you need to port libflac there, optimize few parts, and see how fast it will be. FLAC compression is not heavy at all.

 

Has anybody actually watched the videos uploaded by Retro Junkie ?



Because that windows taskbar everytime the PSX starts is just hilarious

 

what the hell is this? i just watched the video on youtube and i can confirm the same windows taskbar appears at 1:09 too.

EDIT: now i am not so sure that it is windows task bar. it might be something related to monitor settings too.

 

A poorly modified emulator perhaps ?

 

yeah, psio is emulator..... of ps1 cdrom drive))))))))))

win-app selects a game by usb, after he run game, he can close win-app, and de-attach usb cable...

now we are making simple menu , so no need pc at all.

 

Yeah, I figured as much.. The question is, why is there a taskbar displayed for a second or so on the TV screen ? In other videos you can clearly see that it really is the windows taskbar not some monitor settings menu or something.

 

Doesnt look like windows taskbar at all. Other than its a bar at the bottom of the screen, other than that - it has nothing that looks like windows about it.

It also seems to happen on resolution changes. I would go with something the TV displays. Probably the channel and which display type (NTSC or PAL etc)



No clock, no systray, no start menu button, no running apps.

Just what looks like 2 text entries and only happens on a resolution change.

 

If this was about "faking a PSX's bootup" or something, why would there be this "taskbar" when booting up a Mega Drive?



Have no opinion on the whole PSIO business, but really, those conspiracy theories sometimes -.-

 

True, I haven't seen other videos (I'm only interested in PSIO) and that looked like a taskbar for me.

 

Hahaha, yep that's just my TV telling me what settings it is running (NTSC, PAL) and which input it's currently on.
It's a good old mass imported never before heard of brand.
I know my Samsung has a much nicer interface and shows it up the top left, this one just does a grey bar down the bottom

 

Well it sure has been a while since I've done anymore testing with the prototype (and now outdated) hardware.
I'll give the following a play with a little later on this weekend with a bit of luck;
- Mega Man Legends
- Philosoma
- Ridge Racer / Ridge Racer Revolution
- Wipeout / Wipeout XL / Wipeout 3
- Soul Edge / Soul Blade
- Gran Turismo / Gran Turismo 2 Arcade and Simulation Disc
- Twisted Metal
- Grandia
- Chrono Cross / Chrono Trigger

Just remember, it's all still in prototype stages. I'll get some YouTube videos up as well in due time of course.

 

You can't say unless you try it. The cpu has no data cache and the memory is slow.

 

That's why I have here "Theoretically" .

 

By saying theoretically you are asserting that you have a theory about how it can be enough. What is your theory based on?

It sounds like you meant "I wish 33MHz MIPS can be enough to decode FLAC."

 

Did you came to this thread just to resurrect half-year old post and show everybody that you have a lot of expertise in console development?
My theory is based on fact that I used libflac before and I am familiar with FLAC encoding algorithm.
Also my theory is based on a fact, that I've spend several years debugging and reverse-engineering PSX game, writing and injecting MIPS assembly, and rewriting parts of game engine in C++.
And "theoretically" means that I just didn't bother to write PSX application which decodes and plays FLAC, because I really don't see a point why anyone will need this.
If you have some objections on that, send me a PM, don't pollute this thread.

 

No, I hadn't paid attention to it being an old post because the thread had already been brought back to life. We appear to differ on what constitutes a theory, so questioning your assertion has more to do with use of the English language than software development experience.

I am interested in whether a PS1 can decode flac in real time and what bitrate restrictions there might be. You would need to trick the SPU into playing the data as if it had come from the CD though as that appears to be the only uncompressed audio that the PS1 can play. If you can't do that then you would have to compress it using the PS1 lossy compression to play it back.

I'm more interested in mpeg layer ii audio though, but you're right that is going further off topic.

 

I often notice that when there is nothing to say the one just switch discussion to my English skills. Because it's so easy to make fun of somebody if you're a native speaker and your opponent is not.

That person asked a simple question about FLAC and PSX I responded non-technically because that's what most people expect. It may be a speculation, but I think he asked that question about FLAC because a lot of people keep perfect disc dumps in BIN/ECM/FLAC format and it would be cool if that would be supported without re-encoding. But in this case PSX CPU doesn't have anything to do with FLAC. Track should be recoded on the fly and emulated as CDDA sector data using only PSIO CPU. And from what I know, cybdyn is going to use ARM in final hardware and not 8051 controller as it is now, which should be faster.
Personally I would be more interested in ECM support first, because it's sector-aligned and such implementation will be simple and straightforward. But first we need 100% PSIO compatibility and final hardware.

SPU has very small buffer for CDDA, and this buffer is reserved by SPU, so I don't know if you can hook there. If I would write dedicate FLAC player for PSX, I would do this:
1. Precache as much audio data as you can (~2Mb of system ram + ~512Kb SPU ADPCM buffer). Show "caching" screen to user until your buffers are full
2. Play ADPCM from SPU buffer. While it's playing, recode next 512Kb chunk to RAM, and so on
3. In-between DMA copy decoded data from RAM to SPU creating circular buffer
4. Everything should be stored as ADPCM in RAM, it takes 4x less space comparing to RAW PCM from what I recall. 1 second of such audio data will take (44100[frequency]*2[signed 16-bit sample]*2[stereo]) / 4[adpcm compression] ~= 40Kb. Which means you can precache up to ~45 seconds of decoded audio in 2Mb of RAM. Taking into account that most audio tracks are around 3 minutes, even if CPU will not be fast enough to fill buffer runtime, most likely such big cache will compensate smooth track playback. SPU will play it's ADPCM buffer entirely in hardware which means your CPU will be ~95% available for decoding.
I never talked about it being runtime, the question was if PSX can play FLAC file.
Take this with a grain of salt, because the one and only way to prove this will work is to write such player. But based on my experience I would say there are high chances of success.

 

I wasn't making fun of it, I was just pointing out where the disagreement seemed to be coming from.

ADPCM is lossy and the only reason for using FLAC is because it's not lossy. I don't believe there is a documented way to play raw pcm on the PS1 though, so it might be a moot point. However if raw pcm can be hacked by overwriting the CD mixing buffer then that would be pretty cool (it's unlikely to be possible on emulators though as they generally don't emulate the SPU that well.

Back on topic to PSIO, there is a digital sound input on the parallel port but that is also not documented. How it gets mixed is currently a mystery (at least publicly)

You mentioned the PS1 clock speed so I was assuming you meant you thought that it could realtime decode and play it. If realtime is not an issue then speed is not relevant, just the amount of ram. You could for example decode FLAC on a 1mhz c64 with a 16mb REU.

 

It's just an I2S port - the only slightly strange thing is that it's running in "master receiver" mode (I.E. the PSX generates BCLK and LRCLK, and the external device just provides the data). From a software point of view, it's controlled via a single register in the audio DSP (0x1f801db4) - right channel volume in the upper 16 bits and left channel volume in the lower, IIRC.