Subject: Re: PDP 8 emulator standards

From: [email-masked] (Greg Ewing)
Date: Wed, 1 Dec 1993 01:15:53 GMT

In article <[email-masked]>, jones@pyrite (Douglas
W. Jones,201H MLH,3193350740,3193382879) writes:
|>     | | | | | | | | |
|>     |1|0|  1  |  0  |
|>     |_|_|_____|_____|
|>     marks data data

Alternatively it could be packed

| | | | | | | | |
|1|  1  |0|  0  |
|_|_____|_|_____|
 m data  m data

which could be argued to be a more logical layout, since it keeps
each mark bit next to its associated data. On the other hand, it
would require more shifting and masking to assemble and disassemble.

If you're going to do it that way, then it might be better if it 
were big-endian:

| | | | | | | | |
|0|  0  |1|  1  |
|_|_____|_|_____|
 m data  m data

Then you could read the digits of a hex dump left to right and they
would correspond to successive lines.

|> Of course, reverse reads and reverse writes are a bit messier, because you
|> end up reading the lines in the wrong order, with all the bits inverted,
|> but that's a problem any DECtape emulator will have to deal with anyway!

A real DECtape must have had an interesting time of it, too!

I don't understand what you mean by the bits being inverted, though.
Won't it just be a matter of assembling the 3-bit nybbles in the
opposite order?

|> This won't work very well except for tapes with standard format.  A good
|> emulator should be able to work with tapes formatted in nonstandard
|> block lengths,

It depends on what the internal format is like. You should be able to
scan the tape, parse it into blocks and build and index of block
numbers & lengths with pointers to the data, which would be
preconverted to something compatible with your memory so you could
just copy straight in and out.

|> or if you let users run tape formatting
|> software on the emulated machine.

Er, yes, well... that could cause a few headaches. You might have to
switch into slow mode and then reconvert the tape when it was all
over - if you could tell when it was over. Perhaps by sensing the
switch that enables writing on the mark track?

|> 
|> To summarize, the first bytes of an emulated DECtape ought to be DECtape,
|> and after that, you'd want to start right in with a string of end-zone
|> data formatted as above.
|> 
|> 				Doug Jones
|> 				[email-masked]

---

From: [email-masked]
Date: Wed, 1 Dec 1993 15:54:30 GMT

>From article <[email-masked]>,

So who wants to use hex dumps of the contents of DECtape for anything?
Ugh!

> Won't it just be a matter of assembling the 3-bit nybbles in the

The encoding used on DECtape is such that if a bit read in one
direction is seen as a 1, the hardware will sense a 0 in the
other direction!  No extra hardware is included in the interface
to compensate for this, so you've got to compensate in software.
In addition, 3 bit lines are assembled into words in the order
received, with no attention to the direction of tape motion.
The net result is that if you write the word 000 001 010 011
and then read it in the opposite direction, you get 100 101 110 111.

				Doug Jones
				[email-masked]