Date   : Fri, 12 Jan 2007 07:03:43 -0600
From   : julesrichardsonuk@... (Jules Richardson)
Subject: Domesday players and modern hardware

Richard Gellman wrote:
> 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. 

Hmm, I *might* have such a beast... I used to have a ROM-less Adaptec board 
which was bundled with my scanner, but I have a horrible feeling I tossed it 
out because the scanner worked fine with the BIOS-based cards anyway.

> Software-wise I think both DOS and Windows attempts were made, but I 
> don't recall which they settled on.

I suppose DOS gets you closest to the bare hardware...

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

See other comment to Ian though - is that just because a beeb is "in the way", 
or is that 15K/sec even to more modern equipment clocked at something more 
than the 5MHz-ish of SCSI-1? I just wonder if the beeb's the bottleneck, not 
the player.

If the player really will only manage that sort of speed even to a more modern 
SCSI controller then I'm probably better off forgetting trying to couple it to 
modern hardware anyway. I'm confident that a beeb will run for a few days 
solid - the only reason for wanting to hook the player direct to a newer 
machine is to minimise the time that the player's operating for.

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

Hmm, good point.

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

Now that's interesting, and rather surprising!

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

I could certainly wire something up and write the software on the PC side, but 
unfortunately I wouldn't have a clue as to how to do the BBC side of it :-(

Having talked to Adrian@... a bit more, he just used Xfer to 
drag the data across rather than putting together anything specialist to do 
the job. Largest file took about 3 days solid to transfer apparently :-)

cheers

Jules