Date   : Fri, 12 Jan 2007 00:26:17 +0000
From   : splodge@... (Richard Gellman)
Subject: Domesday players and modern hardware

Jules Richardson wrote:
> Richard Gellman wrote:
>   
>>> No word from the Camelion lot yet as to what they did...
>>>       
>> We* used a PC and a SCSI card to read it, and I believe some sector 
>> reading software.
>>     
>
> Hmm, do you recall which card and which OS? Somewhere I've got an old PAS16 
>   
I think it was an older Adaptec card, of the not-so-picky variety. 
Software-wise I think both DOS and Windows attempts were made, but I 
don't recall which they settled on.
>> Note that speed is not really relevant when it comes to data transfer. 
>> The LV-ROM player is actually incredibly slow at reading data, so you 
>> never really get much more than about 15K/sec at the most.
>>     
>
> Wow - I didn't think it would be quite that slow; I was guessing at somewhere 
> between 100 - 200K/sec or so.
>   
My estimate might not be wholly accurate (it was a guess based on 
experience, and the programs behind it may not have helped matters), but 
certainly 100K/second is optimistic. The trouble with the data layout on 
the discs is that very rarely do sectors get read consecutively due to 
data read speeds and transfer latency. This means the disc spends a lot 
of time spinning idly, which brings down the transfer rate.

Something else that might interest you (and other domesday data 
prodders): if you write a program/use a sector reader to lift the data 
off the disc, take advantage of the free space map. For some reason, the 
"free" spaces on the laserdiscs are actually the holes in the data space 
where video frames lie (data and video cannot exist in the same place on 
the LVROM discs). This has advantages as a) you don't have to bother 
actually reading the "free" space, just fill the image in with zeroes, 
and b) trying to read a video frame as data results in an incredibly 
high time overhead - roughly 1 minute per sector.

The program I wrote to lift the data made use of the free space map to 
speed things up a little.
>> I built an interface to transfer the data to a PC  via a User to 
>> Parallel port link, and it still took around 9 hours to do one disc.
>>     
>
> Hmm, that's sort-of OK. I've run my system for quite a few hours before now 
> without hiccups. Are details of the cable that you used and the software that 
> was run at each end of the link available anywhere?
>   
Both cable and software were home brew. It was a very simple cable that 
used a 4-bit transfer method. The bottom 4 bits of the User Port mapped 
to the bottom 4 bits of the PC parallel port. Two of the remaining bits 
on the PB lines were used as a Request/Acknowledge mechanism. Each byte 
was transmitted as two nybbles.

Unfortunately I don't have the software anymore (I assumed that my 
1-nybble-at-a-time method was why the reading was slow so I then moved 
to a parallel-to-SCSI arrangement to try and improve speed - didnt do a 
thing :( ). It was written in Turbo C for DOS, and just received the 
data in the manner above and dumped it out to a file.

-- Richard