[Simh] TOPS-20 Source with KMC11 Driver Code?

[Timothe Litt]

> ...but not unconditionally, right? 
Valid concern, but the devil is in the details.  My note was carefully 
phrased.

The disable bit only effects NPR reads; it replaces the two high bits as 
they are transferred to the Unibus.

This is because on a normal (16-bit) unibus, these are PA and PB (byte 
parity).  If they were were transfered, they could cause Unibus parity 
errors in some 16-bit devices.

This is mostly ignored in simh.  The tape errors if DISABLE is set, as 
it knows it's an 18-bit device.  (pdp10_ty.c:282) This isn't faithful to 
the hardware. (The RH has no visibility to the UBA paging RAM, so it 
would just write zeros to where those bits get swizzled on the tape.)  
But it would catch an OS programming error.

The disable bit can be ignored by 16-bit device emulations since they 
don't get or check unibus parity.  (And if you're tempted to implement 
some error, note that TOPS-20 doesn't set it for the KDP even though it 
should.)

NPR writes are rather more involved per the spec I cited. Basically, the 
UBA tries to minimize KS bus transactions by avoiding RPW when 
possible.  It takes advantage of the fact that NPR transfers are to 
increasing (or with read reverse, decreasing) addresses & caches half 
words.   So writing word 0 (high 1/2 word) will save the data, allowing 
the next NPR write to merge with the saved data, allowing a KS write 
cycle (rather than RPW). For read reverse, same idea but backwards.  The 
data comes from the Unibus; 16-bt devices drive or default PA & PB as 
zero unless they implement parity.  Aside from memory, very few do. 
18-bit devices are unique to the KS10; IIRC, only the RH11-C uses PA & 
PB for data.  (At one point I considered creating an 18-bit UDA50 
variant, but never did.)  The disk and tape versions differ slightly in 
that the disk controller uses bus hog mode. See P 5-94 - 5-100.  Note 
that in figure 5-47, NPR byte writes (which the KMC does) write 0s in 
the high bits.  This is what's not being emulated.  NPR word writes 
could be 16 or 18 bits; the high 2 bits come from the Unibus, but as 
16-bit IO devices don't drive them, they default to zero.

Simh devices need to treat the high bits as the real devices would.  The 
Map_WriteW routine probably should be taking 18 bit data, with the 
caller deciding what to put in the high two bits. But that's 
inconvenient, because C has a 16-bit datatype.  So it could use a void * 
with a mode flag, or have two routines, or... But since the only known 
18-bit devices are the RH11s and they don't use this routine, simh could 
get by with simply clearing the bits.  Or as I suggested, the KMC would 
be better served doing what the RH emulators do & writing memory 
directly.  This would save many redundant UBA page translations when 
long messages are transferred, as well as avoid this bug.

As I pointed out, pdp10_tu.c (and pdp10_rp.c) don't use the routine in 
question; they directly map unibus addresses to/from PDP-10 memory & 
write the full 360bt word.  (e.g pdp10_tu.c:906 in the loop starting at 
:896).

I was the last maintainer of the DECSYSTEM-2020, and haven't forgotten 
everything...yet :-)

This communication may not represent my employer's views,
if any, on the matters discussed.

On 26-May-13 12:01, Rob Doyle wrote:
> On 5/26/2013 3:25 AM, Timothe Litt wrote:
>
>> Second: The Map_WriteW routine (in pdp10_ksio.c) is preserving bits 0,1,
>> 18 & 19, but this is a 16-bit device.  The real UBA would clear them in
>> this case.  This is a bug in simh.
>
> ...but not unconditionally, right?
>
> The KS10 needs to do 18-bit IO for the disk interfaces.   The UBA 
> bridge can be configured to do 18-bit IO or 16-bit IO.
>
> See DISABLE bit in the UBA paging RAM in the technical spec that you 
> referenced on page 5-105.
>
> (I didn't look to see if that was implemented correctly in SIMH)
>
> Rob Doyle


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130526/f5839d02/attachment-0002.bin>