Best practice - Putting data on a CD-ROM

[Jaberwocky]

Heyho x3

again... I have a question about well... a best practice? I hope I use that term correctly. I'm still a beginner with the PsyQ, haven't even loaded a texture yet but also I have never worked with a CD based console yet. I collected some expierence with the SEGA MasterSystem, so you can say... All I'm used to are cartridges. I belive this leads to some natrual question so I wanted to ask the experts here x3

When I was working with the SMS I created tilemaps to render my backgrounds. Those information were stored in the ROM of course and then read on demand. But with the CD-ROM things seem to be a bit different. I noticed that I could store all my game relevant information in my programm, but if I get it correctly, this means that they are loaded into my 2MB RAM at boot time, which... might be a waste of memory. So wouldn't it be better to store it on the disk and read it into memory?
If so, would I create one file for each map I have? Containing tilemap, information and so on, or would I do a larger file and then partially load it into memory?

Because of the SMS I'm used to 2D games and would like to start doing that with the PSX as well. But I worry about the textures. 1MB is not sooo much (more as the SMS has ofc ). For the SMS I was told to not load my sprite sheets into VRAM, but instead only load the needed frame - they called that sprite streaming. Because of the cartridges this was quick, but how about the "slow" CD-ROM? If I think about 2D games like Castlevania or Legend Of Mana, they use very complex sprites and enemies. How to pull that off? My gut feeling teels me, that the 2MB could not hold the entire sprite sheets for the hero and the enemies, plus backgrounds. So is there a form of sprite streaming? What is the best practice for that? Creating one TIM file for each frame and reading it from disk? This would be the SMS approach and also be really slow I guess. So maybe a hybrid way? Having TIM files with multiple frames, but not the entire sheet and loading them? But wouldn't that be to slow as well?

My last question is about burning games. I plan on running my "game" on my PSX at one point and wanted to use a Swapdisk for that. But is there anything I should keep in mind about the disk I use? I read a PSX disk contains 624MB - should I use a disk with that size or can I use a bigger one?

I hope my questions make sense :'D (And are somewhat good questions xO)

[ArthCarvalho]

As you know already, you have 2MB of main RAM, 1MB including frame buffers (so suppose you're using 320x240x2 (double buffer) you'll actually have 70% of that for textures). Plus 512kb of SPU RAM (that is used for storing sound data).

The read speeds on the PS1 are, according to the docs:
Single Speed Mode: 150KB/s
Double Speed Mode: 300KB/s
Of course there's latency since the laser needs to seek the track of data you want, also there can be read failures that can cause further slowdowns.

Storing data into consecutive sectors is the fastest way to read CD data. But the rule of thumb is:
->Reading data from the CD-ROM is SLOW, so you need to load them in the background (using threads) or load in advance.

Also sometimes it is preferable to store duplicated data on the CD-ROM than storing it into separate files.
As the CD will read 2kb sectors at once, so too many small files = at minimum 2kb reads per file which will build up the load times. So you're better off storing them into a single file and loading that file directly to RAM. (it will also cut down the seek time, since it's stored consecutively)

You will not want to stream sprites from the disc, I don't think that that would work properly. What you can do, if you need it, is to store your sprite data on RAM and copy them to the VRAM as you need it. Preferably you want to work with 4bit images, that allows for 16 colors like on 16bit consoles. You can easily transfer a fews (small) sprites per frame from the CPU, but there's a limit of how much you can transfer without impacting the rendering speed.

[Jaberwocky]

Thank you ArthCarvalho! This helped a lot!

However, I don't use 320x240x2 - I use 320x256x2 because of the PAL region. I know that this cuts off some VRAM for the CLUTs, but seems like I have more VRAM left then I was aware of. However, in case I really need any bit of VRAM I can get, couldn't I swap to a single buffer interlaced mode? I know that I have to finish my rendering in 1/50 seconds (for PAL) to get this running, but would this be a possibility for a pure 2D game? I still feel more comfortable with a double buffer progressive way however, but... Well I'm curious.

How can I make sure I store the data on the CD into consecutive sectors? Is this something I adjust in the CTI files?

[ArthCarvalho]

You lose CPU time by using a single buffer, since the GPU does draw things in parallel to the CPU, so while the GPU is busy drawing to another buffer you can use the CPU to process more stuff. If you lock down with a single buffer you're wasting the CPU time idling while the GPU finishes.

I believe the order files will be placed on disc is the same order you set in the layout.
if you place files fileA, fileB, fileC sequentially, that's the order they will be recorded in.
What most people did when developing for the PS1, and still do, is to create a pack/archive file format for your stuff so you just load this file to memory and process it there. Similar to a .zip file. You can even add compression to reduce load times.

[Jaberwocky]

Thank you once more!
Your answer really helped me! I'm not skilled enough for tackling any form of compression yet, but I at least have some form of feeling how I should arrange my files now.

Thank you x3

[ArthCarvalho]

Leaving this here for reference:

[1.1. ]: CD Hardware

[1.1.1.]: What is the arm movement track to track stepping time for the CD?

A seeking action is not repeat of single track seek. The specification
of a CD-ROM drive is described by "minimal access time".
A minimal access time is as follows:

minimal access time = 1/3 seek + settling time = 300msec.

short seek (5min) + settling time = 300 msec.
long seek (60min) + settling time = 1000 - 1300msec.

If the seeking distance is very short ( less than 30 sec), the stepping
action will be very fast. Because it goes without a pick-up unit
moving. (only moving the lens).

Also, by using the equation above you can determine how many megabytes
you can seek per second on a cd.

[MrQuetch]

I'm enjoying this read - it's very educational. Since I'm learning how the CD works too, what would be the best function to at least put binary data onto the 'disc'?