DjayBee

This is true, but does not contradict what I was saying. Deutsche Post transports all parcels by DHL, except for small-sized ones with a max. weight of 2kg and without tracking. But even these get delivered reliably within a week. Another problem in the US are the ridiculous high prices for transportation by these private carriers. DHL takes € 8.5 for 10kg nationwide and €21 EU-wide. Delivery within Germny is usually max. two business days. From my listening to various podcast, I guess that in the US this will be more than twince these prices.

DHL is a subsidiary of Deutsche Post which still is partially state owned. Here in Germany DHL is not the cheapest, but among the best parcel services around. They are fast, their drivers know where to go to and they don't just drop items at the front door and run. They even are able to read names correctly. All of which cannot be taken for granted with other services. Some support from the government plus a working regulation of ex-monoplists (which Deutsch Post was) works quite well. There only must be the necessary will...

Do you really need separate input and output buffers? If you can get rid of one, you immediately get back 128 bytes.

Where is the additional value of needing old RAMs which eventually will fail to populate the board instead of a dirt-cheap SRAM chip? There the additional value would be an out-of-the-box 512 KB RAM extension.

http://www.64kib.com/

And as the to-be-developed database archives by hash instead of filename, nothing which is different will be overwritten; and if it's the same, nothing will be overwritten because it's already there (except maybe for some added metadata about "your" upload). Now we must only find somebody to code it...

For a long time I have that dream ... Somebody (not me - I am no coder) writes an application with a database. You throw any Atari 8-bit artifact at it, it hashes the data and stores hash and data. As our 8-bits do not have huge files, the pure amount of data should not be a challenge for today's systems. In further steps, it: analyses the file (disk image, a COM/XEX, a picture, you name it) converts it if needed (i.e. ATX -> ATR) normalizes what it has found (ATR vs. XFD or MAC/65 multi-segment-binary vs. contiguous binary, pictures to i.e. PNG, and so on) hashes and stores these as well extracts all sectors from disk images, hashes and stores (would be great for repairing bad disks) analyses disk images for their DOS (like atr_image_explorer.html does it), extracts all files and does the above for any of these files and keeps links to the disk images containing them finally you can query it with strings or hex-sequences or hashes or even "your" file and it will tell you if it is already in the database and what it is (and perhaps where you can find it on the net) Any volunteers around? ?

No, it is not. Incidentally I yesterday reconfigured my Altirra with 4.00-test27 and was also surprised. Perhaps rev 11 with CRC32 1A1D7B1B is no longer the "official" dump of rev 11, but it is the one mentioned in Freddy Offenga's list of OSs. Oh, btw - completely unrelated: Where can I find dumps of "exotic" releases? Encounter and Rainbow Walker verify the OS and allow any official one up to XL-OS rev 2 and one more which is not part of Freddy's list of official releases. I wopuld like to find out what it is.

I just tried the a8preservation dump of the 1987 cart release in Altirra. I does not work with 16k. It (at least seemed to) work in 400/800 emulation starting with 32k. Nope, it needs 64k inside the machine.

Yes, but filenames also improve over time. A default set becomes [a]lternate, sets get [!]verified, typos are corrected, additional information is found like [BASIC] or [OS-B], ... Also the hash of a file can change if a better dump is found. You should be prepared.

I guess you know this thread:

Over the weekend I started to verify that some 430 images work on real hardware. I did this the last time at the beginning of 2018, and these images have change since. When I am done with that, I keep my fingers crossed that the preparation scripts I wrote some two years ago in Python work well, and will start uploading. Yes, there will be a combined ZIP.

Sonix used a decrunching loader. So far I have found these titles using it: Deimos, Humanoid, Tactic

I have good experiences with NAPS2 https://www.naps2.com/, but it is Windows-only. It handles rather big jobs. I scanned documents up to 580 pages with a raw TIF-size of over 1 GB. It is OpenSource, generates multipage TIF and PDF, has OCR, can use TWAIN and WIA drivers and allows certain image manipulations. A nice feature for owners of automatic sheet feeders is the ability to scan double sided documents in two batches (first all front sides then all back sides) and automatically sort them into the correct sequence. But I also have to admit that I only scanned a fraction of what Allan did.

The source I linked to is the original source code of the Atari 8-bit version from Roklan/Atari including the 1982 release mentioned by @NamcoPlayer

Why don't you start from the source code? https://atariwiki.org/wiki/Wiki.jsp?page=PAC-MAN

The next confused one who did read only partially :

I tried in Altirra with emulation set to a standard 800XL with 64k and PAL. Nothing crashed for me. The only error is that verifying disks always fails. THis is true for menu secltion J and also as part of a disk copy. The disk copy itself works. I only entered the disk editor, but did not actually edit anything because I do not know how to do that.

What did not work with the other dump? Both are identical except for a deleted STARTUP.EXC and what it seems a few bit-rotten sectors in the second half of the disk. Particularly the DOS and AiDE itself do not differ at all. I cannot rule out that the files also have some bit-rot, but at least all sectors are correctly chained together. Severe bit-rot usually does not flip only single bytes but starts from somewhere mid-sector till the end and then crashes the chaining information. There are no suspicious disk accesses during load. Thereofre I guess that there is/was no copy protection. And while toying around I did not have to push RESET to exit from anywhere like vitoco did. "X" is the magic key to exit back to the main menu.

Try to avoid PRO, they are much inferior than ATX and can stress both the drive and the medium quite a lot. This is particularly true for disks with bad sectors where each bad sector is retried five times on top of the drive's own retries.

sag ich doch Did you also need to patch Frogger to work from disk, or did yours not have the protection?

Yes, seems so. DOS20S.atr from post #8 contains such a tool which I used to create the ATR.

Why the heck do you at all costs create a XEX which needs a DOS instead of writing out a bootdisk? This can be done with COPY.XEX on your disk. Because it tries to read a sector from disk and crashes if this succeeds, you must patch it in two places to run. Have fun Frogger 16k.atr

"shut down" sounds like it would afterwards not draw any/much power. Correct? This sounds like the opposite of what I believe to observe. After the power supply gets "dark" it will not deliver any power until I replug it in the wall socket. My interpretation is therefore that it gets overloaded (or short-circuited) and the dimming and shutdown is the result of a saveguarding mechanism. At the beginning I supected a dried out capacitor which (as far as I understood) can result in a short circuit. But all caps visually look good - no bulges, no leakage - so I meanwhile doubt this. Also if a cap in the power distribution part of the mainboard would be the problem, then (also from my very limited understanding) it would always short-circuit and not only when another board has been plugged on top. The inverter board has two caps which also do visually look good. (Not knowing if this is a valid test) I measured the resistance of them with a multimeter and got 20-40 kOhm.

There is no visible damage on the boards. All caps have flat tops (no swelling) and none shows signs of leakage.