Optimising CD32 Boot Times

Amigajay · 02 March 2016, 16:41

..

Amiga1992 · 02 March 2016, 17:05

There are CLI module players that will be smaller than Hippoplayer.

jayminer · 02 March 2016, 17:30

A few things that will help is to keep as few commands in the startup-sequence as possible, seek times on a real CD32 are really slow so each new file that needs to be read will take quite some time. Always use direct paths, if you have Assign in C: type C:Assign in Startup-Sequence instead of just Assign (less seek on the CD). Sorting the file order in ISOCD can also help a bit, put often accessed files close together on the CD. To reorder the files, start creating a CD using ISOCD as normal but when you've done everything and are ready to build the .iso - save the layout-file, open it with a text-editor and edit the last part of it (it contains 3 lists) by just reordering the lines - save it and load the edited layout-file back into ISOCD.

On our CD we have all rootdirs: C/, S/, Devs/, Games/ ... and so on first and then S/Startup-Sequence, C/SetPatch, C/Assign, C/Execute, C/CD32Load, C/WHDLoadCD32 and such stuff. Then all game stuff in the order ISOCD put them in.

demolition · 02 March 2016, 18:05

Depending on what programs you need to be able to run afterwards, then perhaps you could put some of the small, commonly used tools into RAM:? You could also just delete everything in RAM: when you need to boot some memory-hungry piece of software and then copy the files back on exit.

If seek times on the CD is a very big bottleneck, then perhaps those tools could simply be put in a single LHA file which is then copied to RAM:, extracted, and the LHA file deleted again. Then the CD will be read at 100% speed without any seeking. I have done something similar on a floppy once and it did reduce the overall loading time significantly (although I extracted directly from floppy to RAM). Even on a plain 68k, the CPU could more or less keep up extracting the file with the max sustained reading speed of the floppy drive. Not sure how that compares to the 020 and a CD since I never had a CD32.

jayminer · 02 March 2016, 18:17

Not a bad idea, lha files can always be stored without compression if read-speed is faster than decoding speed. If I recall correctly, lzx is actually faster to decompress than lha but I could be totally wrong here.

jayminer · 02 March 2016, 19:08

@demolition
Oh and I just noticed, you typed copy the file to RAM: and then extract it, why copy it to RAM: ? Just feels like like a totally unnecessary extra step, especially if we're trying to win time here

Toni Wilen · 02 March 2016, 19:21

Most optimal way would be to have all needed files in single big file that is read sequentially and is also located in sequential physical CD sectors. Even if it means duplicating files. Seeks kill the performance. Pausing or stopping reading and then restarting also means seeking. CD keeps rotating and laser keeps tracking the CD's "track" even when not reading.

As long as sectors are sequential, CD32 can keep reading it at full 300kb/s speed without any pauses or seeks.

demolition · 02 March 2016, 19:22

Quote:

Originally Posted by jayminer

@demolition
Oh and I just noticed, you typed copy the file to RAM: and then extract it, why copy it to RAM: ? Just feels like like a totally unnecessary extra step, especially if we're trying to win time here

Question was how much time it takes to continue reading after stopping, even if it does not require movement of the head. If that can be done fast, then extracting directly from the CD should be ok.

spiff · 03 March 2016, 17:02

Depending on if the cd32 is CAV or CLV, placing files closer to the edge should give a slight read speedup (if seeking can be avoided)

Cylon · 03 March 2016, 23:01

You can perhaps place a single big (empty) space-filling file in root to make sure the rest of the data is on the outside of the CD, taking advantage of the above mentioned. So there would be only one (big) seek to the outer rim.;-)
The cd2speed (afaik, doublespeed enabler) for the cd drive is already enabled (by standard, perhaps)?

patrik · 04 March 2016, 09:52

CLV, it is not a "MAX" drive.

Regarding optimal disk layout for low boot time, as jayminer said, order the dirs and files exactly as they are accessed during boot with help of the ISOCD layout file.

xArtx · 05 March 2016, 13:30

They used to put a large dummy file at the beginning of Playstation CDs to bring
files to toward the edge of the CD to supposedly help wearing CD drives which can apparently read the outside easier.
I assume this is because most of the wear on the sled was done toward the inside
where most games would stick the first data.

02 March 2016, 16:41	#1
Amigajay Registered User Join Date: Jan 2010 Location: > Posts: 2,889	Optimising CD32 Boot Times .. Last edited by Amigajay; 08 April 2019 at 22:02.

03 March 2016, 17:02	#9
spiff Oh noes! Join Date: Mar 2003 Location: Neverland Posts: 766	Depending on if the cd32 is CAV or CLV, placing files closer to the edge should give a slight read speedup (if seeking can be avoided) Last edited by spiff; 03 March 2016 at 20:32.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Is it possible to softkick a CD32 into 1.3 and boot from CD?	fisken uno	support.Hardware	20	30 April 2023 15:58
Optimising ILBM decode	pmc	Coders. Asm / Hardware	21	12 October 2011 20:24
help optimising a section of code	h0ffman	Coders. General	15	02 March 2011 13:19
CD32+Sx32 ->How to boot with CD32 mode	Rochabian	support.Hardware	10	04 February 2007 14:33
A1200 Loooooooong boot times!	Mick_AKA	support.Hardware	7	29 May 2005 12:59

02 March 2016, 17:05	#2
Amiga1992 Registered User Join Date: May 2001 Location: ? Posts: 19,645	There are CLI module players that will be smaller than Hippoplayer.

02 March 2016, 17:30	#3
jayminer Registered User Join Date: Jun 2015 Location: Umeå / Sweden Posts: 266	A few things that will help is to keep as few commands in the startup-sequence as possible, seek times on a real CD32 are really slow so each new file that needs to be read will take quite some time. Always use direct paths, if you have Assign in C: type C:Assign in Startup-Sequence instead of just Assign (less seek on the CD). Sorting the file order in ISOCD can also help a bit, put often accessed files close together on the CD. To reorder the files, start creating a CD using ISOCD as normal but when you've done everything and are ready to build the .iso - save the layout-file, open it with a text-editor and edit the last part of it (it contains 3 lists) by just reordering the lines - save it and load the edited layout-file back into ISOCD. On our CD we have all rootdirs: C/, S/, Devs/, Games/ ... and so on first and then S/Startup-Sequence, C/SetPatch, C/Assign, C/Execute, C/CD32Load, C/WHDLoadCD32 and such stuff. Then all game stuff in the order ISOCD put them in.

02 March 2016, 18:05	#4
demolition Unregistered User Join Date: Sep 2012 Location: Copenhagen / DK Age: 43 Posts: 4,190	Depending on what programs you need to be able to run afterwards, then perhaps you could put some of the small, commonly used tools into RAM:? You could also just delete everything in RAM: when you need to boot some memory-hungry piece of software and then copy the files back on exit. If seek times on the CD is a very big bottleneck, then perhaps those tools could simply be put in a single LHA file which is then copied to RAM:, extracted, and the LHA file deleted again. Then the CD will be read at 100% speed without any seeking. I have done something similar on a floppy once and it did reduce the overall loading time significantly (although I extracted directly from floppy to RAM). Even on a plain 68k, the CPU could more or less keep up extracting the file with the max sustained reading speed of the floppy drive. Not sure how that compares to the 020 and a CD since I never had a CD32.

02 March 2016, 18:17	#5
jayminer Registered User Join Date: Jun 2015 Location: Umeå / Sweden Posts: 266	Not a bad idea, lha files can always be stored without compression if read-speed is faster than decoding speed. If I recall correctly, lzx is actually faster to decompress than lha but I could be totally wrong here.

02 March 2016, 19:08	#6
jayminer Registered User Join Date: Jun 2015 Location: Umeå / Sweden Posts: 266	@demolition Oh and I just noticed, you typed copy the file to RAM: and then extract it, why copy it to RAM: ? Just feels like like a totally unnecessary extra step, especially if we're trying to win time here

02 March 2016, 19:21	#7
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,515	Most optimal way would be to have all needed files in single big file that is read sequentially and is also located in sequential physical CD sectors. Even if it means duplicating files. Seeks kill the performance. Pausing or stopping reading and then restarting also means seeking. CD keeps rotating and laser keeps tracking the CD's "track" even when not reading. As long as sectors are sequential, CD32 can keep reading it at full 300kb/s speed without any pauses or seeks.

03 March 2016, 23:01	#10
Cylon Registered User Join Date: Oct 2014 Location: Europe Posts: 471	You can perhaps place a single big (empty) space-filling file in root to make sure the rest of the data is on the outside of the CD, taking advantage of the above mentioned. So there would be only one (big) seek to the outer rim.;-) The cd2speed (afaik, doublespeed enabler) for the cd drive is already enabled (by standard, perhaps)?

04 March 2016, 09:52	#11
patrik Registered User Join Date: Jan 2005 Location: Umeå Age: 43 Posts: 924	CLV, it is not a "MAX" drive. Regarding optimal disk layout for low boot time, as jayminer said, order the dirs and files exactly as they are accessed during boot with help of the ISOCD layout file.

05 March 2016, 13:30	#12
xArtx Registered User Join Date: Jun 2013 Location: Australia Posts: 685	They used to put a large dummy file at the beginning of Playstation CDs to bring files to toward the edge of the CD to supposedly help wearing CD drives which can apparently read the outside easier. I assume this is because most of the wear on the sled was done toward the inside where most games would stick the first data.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)