Anyone got an A4000 with working PAR card?

[mark_k]

I have uploaded my work-in-progress PAR technical notes to The Zone (PAR_notes_20191231.zip).

Hopefully the information there should be enough to allow emulation of the PAR
board, at least to the extent of allowing:
- All tests run by PARTest to pass.
- The GUI of the PAR main program to be explored.
- A base for development of programs useful with real hardware. For example,
it should be relatively simple to write a program to dump/restore image
files from/to the PAR-connected drives, without needing to remove them from
the board.
- Given an image file created from a real PAR drive, it should be possible
in emulation to browse and export the files from it using the PAR
software. At least exporting in "PAR-native" format, which does not
require hardware-decoding of images, should work.

Maybe creating a separate thread about this would be better if anyone wants to post related questions.

[AmigaHope]

Originally Posted by mark_k

I have uploaded my work-in-progress PAR technical notes to The Zone (PAR_notes_20191231.zip).

Hopefully the information there should be enough to allow emulation of the PAR
board, at least to the extent of allowing:
- All tests run by PARTest to pass.
- The GUI of the PAR main program to be explored.
- A base for development of programs useful with real hardware. For example,
it should be relatively simple to write a program to dump/restore image
files from/to the PAR-connected drives, without needing to remove them from
the board.
- Given an image file created from a real PAR drive, it should be possible
in emulation to browse and export the files from it using the PAR
software. At least exporting in "PAR-native" format, which does not
require hardware-decoding of images, should work.

Maybe creating a separate thread about this would be better if anyone wants to post related questions.

Excellent work. I do wonder if DPS kept essentially the same filesystem on their drives on later products even as they changed codecs...

[Starglider 2]

Originally Posted by mark_k

I mentioned before about "Digital Domain A4000 Titanic PAR Drive.hdf" being a bad/incomplete dump. I wonder if when Starglider 2 created the image file, he wrote it to a USB stick or memory card, then removed the USB drive without doing the Windows safe-removal procedure? That could explain why the non-zero data ends on an exact 16MB boundary in the image file. In which case, the source drive could actually be OK, just needs re-reading.

I did not, it was a direct export and I did it twice. However I'm working on a DD version.

[Starglider 2]

Hey guys, I have a small update for you. The machine is now back from Paul resendez and unfortunately he too was not able to repair it, just as I could not. he is the designer of the standalone new A4000 motherboard so I think if anybody could have salvaged this it would have been him. Battery damage is just too bad.

He also tried to backup the drives using DD rescue and wasn't able to due to read errors. So it looks like the backup that I took is the only one that we have available. As this was made using win UAE I believe it can be restored using with WinUAE. However perhaps it will not work due to those read errors being in place even when I got off the machine at first.

It may be that if someone can get PAR emulation working that Win UAE backup will then work in tandem with the Win UAE emulation.

The good news is that I was able to save all of the footage as shown in my recent video: [ Show youtube player ] I have also uploaded that to the internet archive so it is preserved forever. I know it isn't the actual zeros and ones of the data, but it is best we have for now.

my plan now is to get a working Amiga 4000 motherboard into this machine so at least the whole package is brought back to life. And for whatever reason the drive still seems to work when it is actually in a real Amiga ¯\_(?)_/¯

Thank you so much for all of your efforts with this project.

Your friend in retro, Perifractic

[mark_k]

How was the PAR drive connected when ddrescue was used? That could make a big difference in how much data can be recovered.

Connecting via a USB-IDE adapter isn't a good idea. The adapter firmware wouldn't have been tested properly with error-giving drives. Connecting directly to a native IDE port, and using ddrescue's direct disk access option could also help. Otherwise the OS read-ahead caching can create problems when bad/error sectors are reached. If I were doing it, I would also use ddpt which can give more visibility into error conditions.

If you still have the drive and didn't do anything silly like write to it, some or most of the missing data could still be recoverable. The problem with the existing image file is that all file/project metadata is missing. The PAR stores that near the end of the drive. Even if some sectors of the drive are not readable, it could be that all the metadata is actually intact.

It may be possible to recover individual frames from the existing image file without the metadata, I hope to look into that at some point.

[AmigaHope]

Originally Posted by Starglider 2

Hey guys, I have a small update for you. The machine is now back from Paul resendez and unfortunately he too was not able to repair it, just as I could not. he is the designer of the standalone new A4000 motherboard so I think if anybody could have salvaged this it would have been him. Battery damage is just too bad.

He also tried to backup the drives using DD rescue and wasn't able to due to read errors. So it looks like the backup that I took is the only one that we have available. As this was made using win UAE I believe it can be restored using with WinUAE. However perhaps it will not work due to those read errors being in place even when I got off the machine at first.

It may be that if someone can get PAR emulation working that Win UAE backup will then work in tandem with the Win UAE emulation.

The good news is that I was able to save all of the footage as shown in my recent video: [ Show youtube player ] I have also uploaded that to the internet archive so it is preserved forever. I know it isn't the actual zeros and ones of the data, but it is best we have for now.

my plan now is to get a working Amiga 4000 motherboard into this machine so at least the whole package is brought back to life. And for whatever reason the drive still seems to work when it is actually in a real Amiga ¯\_(?)_/¯

Thank you so much for all of your efforts with this project.

Your friend in retro, Perifractic

Well, as long as the silicon is fine you have a nice supply of chips to populate one of those new motherboards. =)

Since there are read errors, a dd will of course fail at a certain point. What you can do though is use some more extensive forensic software to read around the errors and extract what data is still there after the errors (as well as attempt retries on some marginal errors). If the important stuff for the project files is at the end of the disk, that information might still be extractable.

[Hewitson]

Originally Posted by AmigaHope

What you can do though is use some more extensive forensic software to read around the errors and extract what data is still there after the errors (as well as attempt retries on some marginal errors). If the important stuff for the project files is at the end of the disk, that information might still be extractable.

This is exactly what ddrescue does...

[slaapliedje]

Originally Posted by Hewitson

This is exactly what ddrescue does...

Yeah, dd just does a byte by byte copy, but I think ddrescue gives more effort to it.

I will say this, not all USB to IDE adapters are created equally. I had one for a long time that worked great, then it randomly died. Then when I was trying to replace it, I tried I think 3 before I found another one that worked well, and that was only because the one I'd bought previously had stopped being made.

[AmigaHope]

Originally Posted by slaapliedje

Yeah, dd just does a byte by byte copy, but I think ddrescue gives more effort to it.

I will say this, not all USB to IDE adapters are created equally. I had one for a long time that worked great, then it randomly died. Then when I was trying to replace it, I tried I think 3 before I found another one that worked well, and that was only because the one I'd bought previously had stopped being made.

You shouldn't use a USB->IDE adapter at all for stuff like this, because then you're at the mercy of the crappy microcontroller in the adapter -- they do NOT handle error conditions well. You want a real IDE controller that the kernel can talk directly to. Best to pull out an old motherboard that has an IDE controller onboard.

[Hewitson]

Originally Posted by AmigaHope

You shouldn't use a USB->IDE adapter at all for stuff like this, because then you're at the mercy of the crappy microcontroller in the adapter -- they do NOT handle error conditions well. You want a real IDE controller that the kernel can talk directly to. Best to pull out an old motherboard that has an IDE controller onboard.

Exactly. I'm sure we've all got old PC's laying around, why risk a bad dump with a dodgy USB-IDE converter?

[slaapliedje]

Originally Posted by Hewitson

Exactly. I'm sure we've all got old PC's laying around, why risk a bad dump with a dodgy USB-IDE converter?

1) I have imaged and restored many drives without issue.
2) never use front USB ports, always use ones directly on the motherboard.
3) use USB 3.x

And yeah get a decent drive duplication one. This is the one I currently use. https://www.amazon.com/dp/B01790511Q..._fOkfEb1RQVJYF

[KillaByte]

I'm currently digging into the PAR / PVR images on archive.org. I figured out the basic file system structure of the PVR image (I think) but haven't tried decoding the actual JPEG data yet (the used chipset supports loadable quantization and Huffman tables, so these will have to be figured out / extracted / guessed as well).

As others have already pointed out the PAR drive is missing its last 261120 sectors. So to get a feeling for what was originally supposed to be there, could someone with a PAR card maybe dump their card's IDE disk and upload the image somewhere for comparison?

[slaapliedje]

I believe I dumped mine, will have to check when I get home.

[KillaByte]

Making progress here as well. I've located the quantization tables in the firmware images for both the PAR and PVR cards. Now locating the Huffman tables is the biggest issue. Without those there's almost no chance of decoding the JPEG image data.


The firmware seems to be written for a Zilog Super8 (the one that was spotted on the PAL version of the PAR card). I guess part of the firmware sits on a (E)PROM on the card while another part is loaded in by the driver / software (to make sure that it's software updateable). Maybe digging through the firmware (if I can get my hands on a suitable disassembler) can help digging up the missing Huffman tables.

[KillaByte]

Now we're getting somewhere. The PVR drive definitely also originated from Digital Domain. It seems to have been used for LightWave rendering. While I couldn't figure out the original JPEG format completely, I used the DPS conversion tools in a Windows 2000 VM to first convert them to dpsReality .DPS files which are then playable (and readable by e.g. VirtualDub) using their AVI codec.

Here are some examples (already resized to give square pixels). I can recognize "X-Men" and "How the Grinch Stole Christmas". Can anyone recognize the shower picture? Later in the clip half the face melts off.

The rest of the stuff is from the movie Supernova and some commercials (Dodge, Taco Bell Mario Kart, American Express). Haven't checked everything yet, though.

[KillaByte]

Getting even warmer

I can now confirm that both the PAR and the PVR cards use the default Huffman tables that are given in the annex of the JPEG standard.

Funnily enough looking at the actual JPEG data it seems that the NTSC field sizes really are 800x240 (PAR) and 768x240 (PVR) instead of 752x240 and 720x240 respectively.

This sample picture was generated by extracting the non 0xFF field data from the PAR HDD image (offset 0x40000-0x4FFFF), byte swapping it (flipping both bytes of every 16 bit word), applying byte stuffing (replace all occurrences of 0xFF with 0xFF00) and pasting it into an existing JPEG that uses the default Huffman tables. The brightness / hue is off since probably the wrong quantization tables have been used (the missing part of the HDD image would probably have told us which one to use for each field) but it's good enough as a proof of concept.

[Pyromania]

@KilaByte

It’s awesome that you’re getting even warmer.

[slaapliedje]

So I have some disks that came with my PAR card, version 2.55, but I haven't found any ADFs to make it easier to put on a gotek card. Are these floating around anywhere? I can make some off my floppies, but after having to move around a bunch of stuff, I don't yet have a real floppy hooked up to a system where it'd be easy to make them and then get them to a place where I can drop them onto a USB stick.

So if someone has them (I have three disks for it), then that'd be useful. If not, I'll make some images and maybe I can put them somewhere.

Thanks.

[KillaByte]

@slaapliedje:
Didn't you yourself post those ADFs yet?
http://eab.abime.net/showpost.php?p=...3&postcount=21

There are also some disks here:
http://amiga.resource.cx/exp/par

[slaapliedje]

Originally Posted by KillaByte

@slaapliedje:
Didn't you yourself post those ADFs yet?
http://eab.abime.net/showpost.php?p=...3&postcount=21

There are also some disks here:
http://amiga.resource.cx/exp/par

Ha, indeed I did! Thanks!