On Sunday 21 January 2001 20:37, you wrote:
> > 3. Compression
> >
> > TRD said storage capacity is cheap nowadays, so we don't have to use
> > compression. I don't agree, for a couple of reasons. For one thing, not
> > every file is a 16K ROM. MegaROMs are often 128K or 256K, some as large
> > as 2MB. If we include disk games as well, games of several megabytes
> > exist. Having a couple of hunderd games on your harddisk, the space does
> > add up. And on a real MSX storage size matters a lot more. The second
> > reason is that network capacity is not nearly as large as storage
> > capacity, so we should also think about download times and bandwidth use.
>
> Download times? Are the ROM / DSK etc. not already packed with
> zip/lha/lzh/pma when you download from internet today?
True, that point isn't as strong as I thought it was. Although not having to
unpack manually is a bonus. There were several people asking me "what do I do
with a .zip file?" after they downloaded Solid Snake.
> Well if we are
> talking of implementing this standard for DSK images/ other file based
> games too I agree that the compression would save some space. But this
> will only apply to emulators.
The main target for the format is emulators. Making it possible to be used on
real MSX is a bonus.
> I agree on the fact that the 128K/256K ROMs take MUCH space on msx´s floppy
> disks / harddisk but decompression speed on msx is too low for such
> operation (unless you don´t care about the speed). It would take ages to
> load anything. How do you imagine to decompress 128K/256K ROMs on msx?
It depends on the compression algorithm. The SQueeZe algorithm I made is very
fast, when loading from floppy it's actually faster than uncompressed (the
time saved loading is more than the time needed to unpack). Ofcourse, SQueeZe
doesn't compress as tightly as ZIP or LZH. SQueeZe is similar to the
algorithm used by POPCOM.
The current SQueeZe implementation uses 16K of extra memory to unpack, but
the algorithm can be modified to not need any extra memory at all.
> An individual decompression routine for MSX would be enough, to manually
> decomress / extract the files.
This is probably a good compromise. To allow this, we should limit the
filename length to 8.3 characters.
> > Although the PAC SRAM can be shared by many games, this is not a good
> > idea. The user must remember which blocks are in use by which games, and
> > many games don't even allow to user to choose the SRAM block but use a
> > fixed block instead. It's a lot easier to use a separate PAC SRAM for
> > every game.
>
> Just a question:
> Is there a difference between the SRAM in PAC /and FM-PAC cartridge????
AFAIK, FM-PAC is just PAC + FM. Although I have an FM-PAC, I never saw a
FM-less PAC, so I cannot be certain. But it would make sense that both SRAMs
are the same, otherwise games that save in PAC SRAM would no longer work with
the FM-PAC.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
