|
> Not sure why this never makes the front page, as preservation like this should be rewarded with *at least* a nod and a link.
Me neither! :(
> I guess you've been blacklisted because of your *evil* countdown, nevermind that it actually counted down to something worthwhile ;)
Evil countdown? I loved the countdown! :) Is this some immense faux-par in the emulation world?
But yes, the difficulty I find getting them to post would indicate being blacklisted for reasons that escape me. Even when there was apparently no news to post it wasn't being posted...
Oh well.
> Or perhaps once there's a Linux-compatible method of using IPF images in UAE, TkChris will start reporting...
As soon as the WinUAE sources are ported to Linux (or the UAE sources are updated with all the changes done to WinUAE) we will do a port to Linux asap. Apart from not supporting the CAPS plugin, the current version of the base UAE has serious gaps in its emulation of the Amiga's disk and CIA emulation. As-is it would not be able to run most original Amiga games anyway. The situation is exactly the same for a port to the Amiga itself.
Until then, people will have to use WINE on Linux unfortunately. :(
> Keep up the good work, as it is greatly appreciated, even if by a less vocal crowd.
Thank you. :)
> By the way, is there an up-to-date list of wanted games,
Well the games on the wanted list are certainly current, though the rest of items are not really. However, these are games that need a special mention since good versions may be very hard to get, or they have been requested by their authors.
The dump database is what you are after, and unfortunately it still is not ready yet. It shouldn't take much more effort - just time.
There is an exciting development you may be interested in though. I will announce it here when more details are available.
> and/or a list of required hardware/software for DIY dumps (i.e. what specific hardware configuration is necessary to dump a game,
Dumps are generated using our dumping tools. This makes a special raw bit stream of the disk. We are not talking MFM encoded here, we are talking about the actual 0's and 1's stored on the disk. So basically, the encoding (MFM, FM, GCR, MFM2, etc.) does not matter. If it was encoded using anything else (see the previous WIP about the Psygnosis encoding) it would be captured in just the same way.
The dumping tools are sent to anybody that needs them, the only reason they are not on the page is because we need to tell people certain things to make sure any dumps are the best condition possible, For example, people's system and drive is tested first for suitability.
The requirements are:
A 68020 CPU or above. Complicated digital signal processing is done, which requires are relatively powerful CPU. Unfortunately, this was something the Amiga was never designed for, (there was would not have been much use for it then anyway) and thus we cannot make use of any of the Amiga's custom hardware - only raw CPU power.
Minimum of 2Mb of RAM if dumping directly to another computer (using PC2Amiga). However 5Mb of RAM (though 8 or above is recommended) is needed if dumping to HD. We need to turn off DMA to get an accurate read, and then, as all disk based data transfers use the CPU, you need to dump to RAM before it can be copied to the HD. This is done by the dumping tools automatically though.
Kickstart: The actual tool that does the dumping only needs KS 1.3, however, the scripts wrapping the tool need KS2.0+, and do a lot of the admin work for you. So while it is possible to work under KS1.3 it is command line, and not really recommended.
> and is the software you use to generate a raw capture or a "cooked" IPF freely available for use) ?
Raw capture, yes. These are then sent to us so we can check for errors, or modified (!) disks to ensure any release is 100% perfect to how it was originally mastered - how it was meant to be. Indeed, any dump from a disk that is not perfect will not be released. We will just have to hunt for another.
Unfortunately, you cannot generate actual IPF's for several reasons better explained by one of the WIPs, but basically:
You can't create CAPS IPF images without a lot of knowledge about magnetic recording theory, disk formats, and reverse engineering techniques to make IPF files and actually expect them to work. Remember, the game industry tried every trick available to stop people copying disks - and they succeeded to a certain extent (I am not talking about cracking - that changes the game to work on a normal Amiga formatted disk and hence is a different kettle of fish).
You also need to describe the physical layout of the disk, and unless you have any practice with Freeform (the disk description languages used for Trace commercial mastering machines) you don't have much hope. Even then, these people were provided with the details - we need to reverse-engineer them by analysation of the raw dump.
Not easy!
Also, don't forget, IPF images were designed to be mastered to disk, not just played in emulators. Part of what we are doing is what the duplicators had to do to write the disks in the first place. :)
I am not saying I personally have this knowledge. I certainly don't! However, people in CAPS do, and they come from the games industry.
But, it is actually good this way - because you know that every IPF file you see has gone through rigorous testing and is certified by us to be a perfect representation of the original media. We don't really see the point in replicating what has happened with ADF's in that so many of them do not work, or fully work.
In summary, we can't let people do that even if we wanted to - but we don't really want to anyway. :)
Any more questions, just let me know. :)
|
