Anyone got an A4000 with working PAR card?

[AmigaHope]

Originally Posted by Pyromania

@AmigaHope

You may already know this but I’ll mention it just in case. I’ve found that many people don’t know about it. You can load and convert NewTek Flyer video data in an old version of NewTek Aura (TV Paint) without a Flyer card. I believe this is around version 2.0 of Aura (Windows version). Also, hopefully the Amiga Video Flyer Developer Manual that I recently added to Open Video Toaster may help support the format more I hope. Sorry to go a little off topic. Maybe developer manuals exist for the PAR card and Perception card? I’m not sure and DPS got bought out many years ago so they might be hard to find.

Good to know that there's software that can decode VTASC. That's the danger of proprietary formats (even though VTASC was super impressive in performance at the time).

Regarding DPS PAR though, the card uses off-the-shelf LSI JPEG encoders. Theoretically you should be able to just find the JPEG stream and slap a JFIF header on each frame to make it viewable by all software. (The JFIF-APP0 info may be unknown but is pretty easy to infer since all the frames will be encoded the same way given the nature of the card being strictly for encoding NTSC/PAL frames).

[LanceT]

[Starglider 2]

What are we looking at here?

[AmigaHope]

Originally Posted by Starglider 2

What are we looking at here?

Looks like he managed to make a DPS PAR emulation for UAE. It might not actually properly emulate the card, but at least emulate enough of it that it fools the DPS software into thinking it's valid?

Like it might just be a virtual card that reports as a PAR in autoconfig and allocates some address space, and that's all it takes to make the software happy?

[mark_k]

I should have thought of that.

I'm guessing LanceT used Advanced Memory Settings (WinUAE settings window RAM page). By setting board size, manufacturer and product numbers to match those of the PAR, the PAR software will think (at least initially) that a PAR board is present. Of course none of the functions will actually work, and probably if you try it will report a problem with the board. But it seems to be enough to get the PAR and tester initial screens to appear at least.

That's useful for my reverse-engineering effort, since I can relate gadget positions to what a particular gadget is supposed do. I doubt I'll be able to see all program screens though, without some fakery.

(Fakery might involve, for example, writing a program to run in the background, which would repeatedly read memory locations corresponding to PAR registers and put the result the PAR software expects in the appropriate location.)

[LanceT]

Originally Posted by mark_k

I should have thought of that.

Discovered this from comments on a post by Toni and Emufan a few years back
Mark is exactly right. I have been trying random setting with some strange results, one time the PAR program produced 2 errors on screen one being the a board fault and the second I am not sure of now. I should have saved it. Another time I know that I saw hd activity for a short time in the lower right corner of winUAE.
Editing the information icon it can reduce "fails" I wonder if it's an override setting on some sorts?
It would be interesting to see how a real board works under snoopDos and WhichAmiga

[mark_k]

If adding a "fake PAR" memory board, set it so AmigaOS doesn't add the memory to its free list. To do that, check the "Edit Autoconfig data" box and change the first byte in AutoConfig data from e2 to c2.

[Toni Wilen]

Technically interesting board to emulate but:

Board most likely has some (semi)-custom micro controller. Amiga software probably talks to the micro controller via some IO interface and the MCU then talks to other parts of hardware, including harddrives. Only way to emulate it is to emulate the MCU which is not really worth the trouble. (Unless there is some existing emulation module but it still would require full IO space documentation..)

[AmigaHope]

Originally Posted by LanceT

Discovered this from comments on a post by Toni and Emufan a few years back
Mark is exactly right. I have been trying random setting with some strange results, one time the PAR program produced 2 errors on screen one being the a board fault and the second I am not sure of now. I should have saved it. Another time I know that I saw hd activity for a short time in the lower right corner of winUAE.
Editing the information icon it can reduce "fails" I wonder if it's an override setting on some sorts?
It would be interesting to see how a real board works under snoopDos and WhichAmiga

FYI the serial port access is almost certainly for controlling the DPS TBC IV, which was an ISA card that used the Amiga's ISA slots for power only -- actual control from the Amiga was sent via RS232. There was also a ribbon cable that connected it to the DPS PAR so they could exchange data.

[AmigaHope]

Originally Posted by Toni Wilen

Technically interesting board to emulate but:

Board most likely has some (semi)-custom micro controller. Amiga software probably talks to the micro controller via some IO interface and the MCU then talks to other parts of hardware, including harddrives. Only way to emulate it is to emulate the MCU which is not really worth the trouble. (Unless there is some existing emulation module but it still would require full IO space documentation..)

The important bits of the board seem to be commodity parts. The microcontroller used is a Zilog Z8 (which is different from a Z80) with an EPROM for firmware and 64k of SRAM (the video chips use other ram). Video data codec and processing is via three off-the-shelf LSI chips. Rest of board is a ton of Altera PLDs which I think were mostly for interfacing/glue, but I'm also afraid that the IDE interface might actually be part of those as PIO PATA is pretty easy to implement so I think DPS might have just rolled their own controller.

Best approach would probably be to get a dump of the EPROM and reverse engineer from there. My best guess is DPS rolled their own Z2 interface, which lets you talk to the Z8, and the Z8's firmware directs DPS's IDE controller to record from or spit data onto the bus, as well as directs the LSI video processors to do their thing. Since Z8 code is relatively well-understood, figuring out how that works and what data it expects is probably enough without needing to truly understand what the rest of the board is doing, at least in terms of getting it to interact properly with the software on the Amiga side.

i.e. it's enough for it to simulate storing and loading of frames, and controlling some sort of video capture and playback (that could just talk to ffmpeg in mjpeg mode or whatever).

[LanceT]

Originally Posted by AmigaHope

FYI the serial port access is almost certainly for controlling the DPS TBC IV

Thanks, that was just me trying out different ".device"s to see if the PAR would react differently.
Did the same with the TBC-IV VPC program by changing the "PAR" in the icon information to "serial.device" the program was able to startup. I can't do much more with it. Just play with sliders and buttons with no results.

[mark_k]

Originally Posted by Toni Wilen

Technically interesting board to emulate but:

Board most likely has some (semi)-custom micro controller. Amiga software probably talks to the micro controller via some IO interface and the MCU then talks to other parts of hardware, including harddrives. Only way to emulate it is to emulate the MCU which is not really worth the trouble. (Unless there is some existing emulation module but it still would require full IO space documentation..)

I don't think you'd need to emulate the microcontroller, similar to how you don't need to emulate the Z80 on an A2090. Emulating the command protocol could be enough to get the PAR software working. Of course actually working, being able to encoded/decode/display images, would be a little more work...

As a taster, here's some info about the command protocol.

To send a command to the board:
- Wait until board+2 bit 1 is clear. Then board is ready to accept command.
- Write (command number) byte to board+8
- If the command expects to receive more data, send each byte by waiting until board+2 bit 1 is clear, then write the byte to board+2.

To receive a byte from the board, repeat for each byte:
- Wait until board+2 bit 0 is set. (To avoid hanging on a hardware problem, the PAR code uses a timeout of 6 seconds.)
- Read board+0

Checking status:
After issuing various commands, the PAR program does this:
- Receive byte from board
- $2A = 42 means success. Anything else indicates an error.


Command $04: Issues IDENTIFY DEVICE to the current drive.
Issue command, receive 512 bytes (IDENTIFY DEVICE data), check status. Note: the data returned may be byte-swapped, that is e.g. "ATA strings" appear as normal ASCII strings.

Command $05: Set LBA used for subsequent drive read or write commands.
When drive is idle, issue command, send three bytes, check status. LBA is sent MSB first. It is recommended to use command $36 to read back the LBA to confirm it matches prior to issuing read or write commands.

Command $09: Check whether disk is idle.
Issue command, receive byte. Zero means drive is idle.

Command $20: Select component video levels (M-II or Betacam)
Issue command, send byte to board (0 for M-II, 1 for Betacam), check status.

Command $29: Write single sector
(Select the drive and set LBA prior to issuing this command $29.)
Issue command, receive byte. If byte is not $3E, report error. Else send 512 bytes to board. Check status.

Comand $2D: Select drive
Issue command, send byte (0 for master or 1 for slave). Receive byte. The value of byte received seems to be ignored.

Command $32: Write multiple sectors. Presumably this issues an ATA WRITE MULTIPLE or WRITE DMA command?
After setting LBA, issue command. Receive byte. If not $3E, report error. Else send bytes to board. (The PAR software sends a maximum of 16 sectors' data at once.) Check status.

Command $36: Read current LBA
Issue command, receive three bytes. Those are the current LBA, MSB first. It is recommended to issue this command after setting the LBA with command $05, to make sure any subsequent drive read or write affects the intended sectors. (A communication error while setting LBA could result in the wrong sectors being written to.)

[Toni Wilen]

Does everything use same interface or is there other IO regions? For example to access other chips directly?

[AmigaHope]

Originally Posted by mark_k

Command $32: Write multiple sectors. Presumably this issues an ATA WRITE MULTIPLE or WRITE DMA command?
After setting LBA, issue command. Receive byte. If not $3E, report error. Else send bytes to board. (The PAR software sends a maximum of 16 sectors' data at once.) Check status.

The PAR seems to implement a very specific ATA PIO mode, and doesn't seem to use DMA. As I said before, there doesn't appear to be any off-the-shelf ATA controller onboard so I'm pretty sure it's just done with the Altera PLDs. i.e. DPS rolled their own PIO ATA interface much the same way Elbox did with their FastATA cards using Mach PLDs.

ATA DMA is *WAY* more expensive in logic than PIO, so I am almost certain no DMA commands are used.

[mark_k]

A couple of error strings in the PAR program:
"Read DMA timeout."
"Write DMA failed."
I think it's quite likely the PAR board can use READ DMA & WRITE DMA IDE commands, it needed to be capable of at 5MB/s+ sustained transfers. Of course the Amiga never sees that, DMA would be between drive and RAM on the PAR board.

Toni: It seems to be that very simple "interface". I'm guessing the ISA version of the PAR contains much the same hardware. Next step for me is to find the Windows 3.1/NT software for the ISA PAR, in the hope that those contain symbols or function names.

I'll try to upload a more detailed command set description in a couple of days.

[LanceT]

Originally Posted by mark_k

Next step for me....

At Mark I did find these files at various websites <pic> They are PVR and DPS programs for WinNT 4.0 and win95/98. I created a virtual NT OS but as I don't have a working PAR Drive Image or DPS files I can't get anything to work.

DPS Software Player

DPS Software Player is a DirectShow source filter that allows Windows Media Player to playback DPS and DVA files on a computer whether or not it has DPS Hardware. This package also installs the codec for using DPS files with software only versions of DPS Plugins.

Files:
------
1. dpsplay2.dll - DirectShow source filter. It is a self-registerable COM DLL.
2. dpsplay.cpl - Control Panel Application to configure playback resolution.
3. dpsplay5.dll - AVIStream Wrapper used with software only DPS plugins.
4. readme.txt - this file.

Installation:
-------------
Double click on the "DPS Software Player.exe" file.

During the installation you will be asked for your CPU type (P1, P2, P3, P4, etc.). This is to get the best preformance from the Intel JPEG Library version 1.5 that is used by the codec.

Configuration:
--------------

1. Open "Start > Settings > Control Panel" and double click the dpsPlayer icon.

2. Select Full for full resolution playback or CIF for 50% resolution.


Playback:
---------

1. DPS file only (video only):

The DPS file can be on a system drive or a media drive.

Open Windows Media Player and use the menu to select "File > Open".

2. DVA file (audio with associated video):

Open the DVA file as you do a DPS file.

The DPS file indicated in the DVA file will automatically be opened.

3. DPS file and WAV audio (video with unassociated audio):

The audio file (*.wav) and the video file (*.dps) must have the same name
and must be in the same folder on a on a system drive.

When you open the DPS file the WAV file will automatically be played as well
if there is one that meets the criteria.

Software Plugins
----------------
These Plugins allow you to read from and to write to DPS files from 3rd party software on machines that do not have DPS hardware installed. You will find plugins for After Effects and for 3DStudio Max on this CD. Other plugins will be developed as time permits.

Changes since version 1.5
-All RGB <-> YUV conversions are done using the same functionality as the Quattrus and Reality drivers as of Version 1.6. This fixes a luma shift problem with imported and exported footage.

Changes since version 1.0
-Added support for 32 bit files reading, writing, and playback.
-Added option for forcing playback to RGB24 for some systems where video would not play properly.
-Added support for YUV import and export.

dps_avi_codec15

DPS AVI Codec version 1.5 - Software Only Version
------------------------------------------------------------------------------------------------

The DPS Avi Codec is a reference codec that uses the DPS Software Codec to generate AVI files that can be used by any program that can accept AVI's. This is similar to the original DPS Perception AVI Codec, and allows users to make "Virtual AVI files" that can be used in applications that cannot use DPS files.

The AVI codec is a reference codec, which means that it is actually creating a DPS file, and pointing the Video section of the AVI to the correct frames of the DPS file; the video frames are not stored in the AVI file itself. The audio is kept in the AVI file.

Since this release uses our DPS Software Codec, you can use it on a system without the hardware installed. To use the codec, you must have DPS_Software_Player 1.5 or later (also available on the Leitch web site at "LINK REMOVED") installed.

INSTRUCTIONS FOR USE:

Once you have installed the DPS AVI codec you can configure it by opening the Windows Control Panel, double clicking on the Multimedia icon, selecting the Devices tab, expanding Video Compression Codecs and double clicking the DPS AVI Codec. This will open the "DPS AVI Codec Properties" window. Click the Settings button to configure the codec.

Any program that accepts AVI's should be able to read and write DPS AVI's. Just select the DPS AVI Codec as the compression codec.

To create an AVI wrapper for an existing DPS file, right click on the DPS or DVA file in Windows Explorer. Select “Convert to AVI File”. An interface will appear. Select the destination for the AVI file, then click the convert button. You will now have a reference AVI that can be used by other applications.

LIMITATIONS:

-This is a software-only codec. With previous codecs there was the ability to preview the video on the external monitor. With this codec, preview will only be displayed on the VGA.

-You cannot write the DPS file to the P disk. Since this codec has no interaction with the Hardware, it is not possible at this time to write the DPS files directly to the dedicated media drive. You can write the files to a system drive, then copy them to the P drive.

- If access to the hardware is necessary and you are using the Reality hardware, you can download the older version of the codec which has access to the hardware. This file is also available on the Leitch web site (under the software downloads for Velocity or Reality), and is called AVI_Codec.zip.

- This version of the DPS AVI codec is not intended to playback a DPS media file at 30/25fps. Instead it is designed to seek to a frame for the purpose of previewing or processing in an external application. Typically, when multiple seeks are preformed successively it has the effect of playback. However, when using this method smooth playback cannot be guaranteed. This will become especially apparent as the DPS file's data rate increases or when the AVI file links to multiple DPS files. Thus, the DPS AVI codec should only be used in a preview capacity. Applications will not be able to perform “full playback” of the DPS AVI files. This does not have an effect on any separate plug-ins that enable applications (such as After Effects) to directly access DPS files, as they do not require the use of this AVI codec.

Changes since version 1.3
-Fixed problems with certain software packages not recognizing DPS AVI files

pvr261nine (in short)

RELEASE NOTES
DPS PERCEPTION VIDEO RECORDER (PVR)
VERSION 2.61
Release Date: March 30, 1999
_________________________________________

NOTE: An Adobe Acrobat version of this "readme" is provided with the PVR software. It is on Disk 1 of the setup diskettes, and is installed in the DPS\PVR\Help directory. If you have the Adobe Acrobat reader installed, we recommend that you view the Acrobat version of this file.
_________________________________________

Thank you for choosing DPS! We believe that our products are the best available, but we know that there is always room for improvement. If you have an idea or a suggestion that you'd like us to consider, please send it to <suggestionbox@dps.com>. We would be glad to hear from you.

NOTE: If you are using the CD-ROM to install this software on a DEC Alpha system, the CD-ROM Autorun feature will not operate correctly. Simply run the Setup.exe program in the folder <PVR\Alpha\Disk1>.


Contents
1. What's New in PVR 2.61
2. System Requirements
3. How to use the RS-422 Deck (VTR) Emulation Mode
4. How to use A4V Timecode Support
5. Previously Released Information Not Available in the Manual

In short I am not sure if any of these files would be of any use to you?

[mark_k]

Thanks. It's possible/probable that those tools are for later DPS products, not the PC PAR board.

I looked at the old DPS web site via the Internet Archive. That gave some PC software filenames, unfortunately the Wayback Machine didn't capture the actual archives:
ppnt205n.zip
ppnt205p.zip
parw123.zip
par163.zip

[LanceT]

Mark I did find what appears to be interesting files I use googlesearch "par163.zip" only problem is that it's @driverguide my malwarebytes wont let me anywhere near it except for the first screen.
Was able to view file contents by clicking on the cache in the search engine.

Files within the zip apparently are.

Driver Contents File List
The following files are found inside the driver download file.

Name Size Date
INSTALL.EXE 46.1 KB 11 Oct 1994
PAR_ALL.ZIP 815.4 KB 18 Jun 1996
PAR_ALL.ZIP/BITMAP.LST 97.5 KB 28 Jan 1996
PAR_ALL.ZIP/DPSPAR_I.PXP 27.9 KB 21 Apr 1994
PAR_ALL.ZIP/HELP.LST 38.4 KB 18 Jan 1996
PAR_ALL.ZIP/LOGO.LST 33.7 KB 13 Jan 1996
PAR_ALL.ZIP/PAR.EXE 1.1 MB 18 Jun 1996
PAR_ALL.ZIP/PAR.HEX 26.6 KB 11 Jul 1995
PAR_ALL.ZIP/PAR.INI 1.0 KB 17 Jul 1995
PAR_ALL.ZIP/PARDRV.EXE 56.4 KB 1 Feb 1995
PAR_ALL.ZIP/PARDRVP.EXE 57.0 KB 1 Feb 1995
PAR_ALL.ZIP/PARINIT.EXE 63.8 KB 18 Jun 1996
PAR_ALL.ZIP/PARSET.EXE 128.6 KB 10 May 1994
PAR_ALL.ZIP/PARTEST.EXE 123.6 KB 18 Jun 1996
PAR_ALL.ZIP/PAR_INI.TXT 5.9 KB 16 Feb 1996
PAR_ALL.ZIP/PAR_PAL.HEX 27.2 KB 12 Jul 1995
PAR_ALL.ZIP/REQUEST1.LST 508.2 KB 15 Dec 1995
PAR_ALL.ZIP/REQUEST2.LST 584.5 KB 15 Feb 1996
PAR_ALL.ZIP/REQUEST3.LST 132.8 KB 15 Feb 1996
PAR_ALL.ZIP/SWITCH.INI 290 bytes 26 May 1993
PAR_ALL.ZIP/TBC.STR 1.3 KB 31 May 1994
PAR_ALL.ZIP/TBCIV.INI 3.0 KB 28 Nov 1994
PAR_ALL.ZIP/VGAFIX.FON 5.4 KB 10 Mar 1992
PAR_ALL.ZIP/VIDCAP.INI 1.6 KB 10 Jan 1995
PAR_ALL.ZIP/WINTBCIV.EXE 196.6 KB 26 May 1994
PCREADME.TXT 31.8 KB 18 Jun 1996
PKUNZIP.EXE 29.4 KB 1 Feb 1993

I'll try and download it from a duplicate virtual system.


On looking at the link you just provided, I was able to find what files did get captured.
http://web.archive.org/web/*/http://www.dps.com/files/*

[mark_k]

Maybe driverguide recently removed the par163.zip file from their site? I did manage to download some other (unrelated) files from there.

[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.