Re: [Simh] Disk encoding

[Larry Stewart]

This sounds vaguely like FM or MFM encoding or one of its relatives.
The wikipedia article is informative: 
https://en.wikipedia.org/wiki/Modified_Frequency_Modulation 


MFM was instroduced in 1970 for the IBM 3330, which might be too late.
Or it could be FM, which has a transition in the middle of a bit cell for 1’s 
and a transition at the end of a bit cell for a 0 if it is followed by another 
0.

FM has 1.5 average transtions per bit, which seems right.

The rew encoding mode might generate the data for the write head directly, at 
double the bit cell frequency.

-L


> On 2019, Jul 6, at 2:35 AM, Lars Brinkhoff  > wrote:
> 
> Hello,
> 
> I'm looking into simulating a disk controller used with the MIT AI lab
> PDP-10: a Systems Concepts DC-10.  It looks like it's a custom made
> channel interfacing to IBM disks.  (It has been claimed those are 2311
> or 2314, but the geometry doesn't match.)
> 
> Formatting a disk pack uses a WRITE IMAGE command, which I believe
> writes raw bits directly onto the disk surface.  I'd like to decode
> these to the data bits as seen by a normal READ or READ HEADER command.
> I wonder if anyone recognizes the kind of encoding used?
> 
> For every track, it goes like this:
> 
> 1. Wait for the physical start of the track.
> 2. Write 125460 bits of ones to cover the entire track.
>   These will be overwritten by the following data.
> 3. Write a 108-bit header preamble:
>   11
>   101010110101101011010110101101011010110101
>   The preamble signals a header with with a zero, and then eight
>   10101 words.
> 4. Write a 108-bit header, converted to the on-disk encoding.
> 5. Write a 252-bit postamble:
>   11
>   11
>   11
>   11
>   1101
> 6. Write 55620 bits of alternating ones and zeroes.  This is the data
>   and checksum.  These will come out as all 37080 zeroes with a normal
>   READ command.  Note the ratio between raw bits and data is exactly 1.5.
> 7. Write N bits of ones for the sector gap.  N is computed from the
>   length of the track minus the data fields, divided by the number of
>   sectors.
> 8. Write next sector, go back to step 3.
> 
> Now, in particular I'm curious about what encoding will transform a zero
> bit to, on average, 1.5 "10" (or "01") bits?
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com 
> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Fwd: [TUHS] An abandoned piece of K C

[Larry Stewart]

I took the liberty of cross posting this earlier to TUHS and I got 
an authoritative answer :)
-Larry


> Begin forwarded message:
> 
> From: Ken Thompson 
> Subject: Re: [TUHS] Fwd: [Simh] An abandoned piece of K C
> Date: 2017, November 3 at 2:30:08 PM EDT
> To: Lawrence Stewart 
> 
> it's news to me.
> 
> 
> On Fri, Nov 3, 2017 at 5:53 AM, Lawrence Stewart  wrote:
>> This caught my attention.  Did early C really have min and max?  Were they
>> used for anything?  In those days I was a BCPL user, which IIRC, did not
>> have such things.
>> 
>> -Larry
>> 
>> Begin forwarded message:
>> 
>> From: Leo Broukhis 
>> Subject: [Simh] An abandoned piece of K C
>> Date: 2017, November 3 at 1:14:42 AM EDT
>> To: "simh@trailing-edge.com" 
>> 
>> https://retrocomputing.stackexchange.com/q/4965/4025
>> 
>> 
>> In the UNIX V7 version of the C language, there were the /\ (min) and the \/
>> (max) operators. In the source of the scanner part of the compiler,
>> 
>> case BSLASH:
>>if (subseq('/', 0, 1))
>>return(MAX);
>>goto unkn;
>> 
>> case DIVIDE:
>>if (subseq('\\', 0, 1))
>>return(MIN);
>> ...
>> 
>> However, attempting to use them reveals that the corresponding part in the
>> code generator is missing. Trying to compile
>> 
>> foo(a, b) { return a \/ b; }
>> 
>> results in
>> 
>> 1: No code table for op: \/
>> 
>> The scanner piece survived in the copies of the compiler for various systems
>> for several years. I tried to look for copies of the code generator table
>> which would contain an implementation, but failed. Has anyone ever seen a
>> working MIN/MAX operator in K C?
>> 
>> Thanks,Leo
>> 
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>> 
>> 

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Thoughts on combining individual scanned pages

[Larry Stewart]

For what its worth, if you have pdf files from a scanner, you can combine them
with command line tools on the Mac.

See 
http://gotofritz.net/blog/howto/joining-pdf-files-in-os-x-from-the-command-line/

This recipe works well for me.

-L

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

[Larry Stewart]

You step away from the computer for a day and your inbox is full!

We want to transfer files back and forth between guest file systems and host 
file systems, preferably while the guest is running.

The mechanism should be as generic as possible, rather than be wildly different 
for each environment.  (It probably can’t be identical always, because some 
guest environments have unusual encodings, or unusual file semantics, and so 
forth.)

The mechanism should require minimum code for the guest environment, since each 
one is different, and most of us are not skilled at more than one or two 
environments.

I think unless you shutdown the guest, add files to its filesystem, and 
restart, it is going to be hard to avoid writing at least some guest code.  How 
minimal can it be?

Let’s try a thought experiment, of implementing the simh commands 

hosttoguest  
and 
guesttohost  

Taking hosttoguest first.

simh itself could obviously read from a host file, in a generic way.
Only a guest program can really deal with  and write to the 
guest file system while it is live, so I think there has to be a guest program, 
called, say
magictoguest  which reads from some magic data path and writes 
to the guest filesystem.

When you type “hosttoguest” at the simh prompt, simh opens the host file, and 
somehow (by stuffing a command into the console?) activates the magictoguest 
utility.

The magic datapath is up for discussion for the most generic possible solution, 
but it could be anything.  simh is a simulator and controls the horizontal and 
the vertical, so
the magic datapath could be previously illegal instructions that have new 
powers, or magic I/O addresses, or even just an attention grabbing  
of memory references.  For historical reasons, I would recommend Up, Up, Down, 
Down, Left, Right, Left, Right, B, A, Start.  simh would notice the sequence, 
and that would identify the memory location(s) in use for data transfer.

The magic datapath could be minimal and would be simulator specific, co-written 
with the magictoguest utility program.


guesttohost, similarly, is broken into a generic part in simh for writing host 
files, and a minimal utility on the guest for reading guest files, connected by 
pretty much any magic datapath.

This is a considerably more minimal idea than a filesystem, but when you want 
to transfer a bunch of files, you can write a script.

The SIMH and System Verilog simulators for the SiCortex ICE9 (sort of a MIPS) 
had some magic extra instructions to provide communications (putchar, getchar, 
test PASS and test FAIL) for programs running in simulation, and fancier 
functions (zeroing memory regions) intended to greatly speed up otherwise 
boring parts of simulations.

If you don’t want to initiate transfers from the simh side, then the guest 
utility can pass the host filespec up to simh with only slightly more 
complexity.


magictoguest.c
===

#include 
#include 

int mailbox;

#define EOFBIT 0x100
#define DATAAVAILABLE 0x400

int magiceof()
{
 return (mailbox & EOFBIT);
}

char magicgetchar()
{
 char c;
 while ((mailbox & DATAAVAILABLE) == 0);
 c = mailbox;
 mailbox &= ~DATAAVAILABLE;
 return(c);
}

int main(int argc, char *argv[])
{
 int fd;
 if (argc != 2) return(1);
 fd = creat(argv[1], 0666);

 mailbox = 'H';
 mailbox = 'e';
 mailbox = 'l';
 mailbox = 'l';
 mailbox = 'o';
 mailbox = ' ';
 mailbox = 'W';
 mailbox = 'o';
 mailbox = 'r';
 mailbox = 'l';
 mailbox = 'd';
 /* that sequence of writes to  wakes up simh and identifies the 
mailbox */

 while(!magiceof()) {
   char c;
   magicgetchar();
   write(fd, , 1);
 }

 close(fd);
 return(0);
}


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] KS10 IMP documentation

[Larry Stewart]

As Clem notes, the 1822 report defines three types of Host to IMP interfaces, 
Local Host, Distant Host, and Very Distant Host.

The Local host uses TTL levels to signal, with per-bit handshaking.  The 
Distant Host
uses, IIRC, differential signalling aomewhat like RS422 electrically, but uses 
the per-bit handshaking.
The VDH, on the other hand, is more like the IMP to IMP protocol which is 
actually BISYNC at the wire level.
This can be done with any synchronous serial line adapter on the host (no start 
and stop bits!). So if there are any SIMH synchronous serial controllers, they 
would work for VDH.  The DU-11 maybe ?

At SU-ISL we ran VDH from an 11 to the IMP at the Stanford Medical School 
(SUMEX-AIM).

The software for VDH is messier than for LH or DH though, because there is a 
BISYNC layer for framing and a link ARQ scheme for error detection and 
retransmission of packet fragments across the (not assumed error free) VDH link.

So there were 11’s with VDH.  I don’t know if any 10’s used them, so that the 
VDH software would exist.

-Larry

> On 2016, Feb 29, at 3:48 PM, Clem Cole > 
> wrote:
> 
> Tim I'm going to guess that the AN22 implements the PDP-10 side of the BBN 
> 1822 IMP interface. Is that a correct belief?
> 
> Bit Savers has the BBN 1822 document from 1976 (the original I think was '72 
> - I had a xerox of that one).  I think I saw it about a week ago at home, so 
> I'm nearly 100% sure I have very clean copy of the actual published in it's 
> Yellow Cover from BBN, the later edition - which would have been the one when 
> the IP transition was taking place or at least planned (i.e. post Arpanet - 
> when IP was being created).  If so, I'll look into getting it scanned and 
> send an update to Al.   I'm pretty sure there was changes when BBN 
> implemented their own mini for the IMP (the C30 - which later got 
> re-microcoded to be  general purpose computer - the C70 "C Machine").
> 
>  
> 
> I do not remember how CMU interfaced the 10's and C.mmp to their (Honeywell) 
> IMP.  I suspect it was either something like the AN22 or be a Jim "Tetter 
> Toy" that he cooked up (I never knew).   However, IIRC @ UCB Ingres 11/70s a 
> DR-11B with a little logic  (??Bob Kriddle hack maybe?? - at one time I had 
> my hand in it).  That was the UCB Arpanet interface for many, many years --- 
> until CSRG finally got a C30 IMP in Evans in the early 1980s.   Ing70 had a 
> "very long host" interface from a Honeywell IMP that was "up the hill" at 
> LBL.Again, IIRC the C30 could do Ethernet to the Vaxen.   Or maybe it was 
> connected to the Ethernet via a C70 which was connected the C30 (I've 
> forgotten). But until the C30 showed up, the UCB Arpanet/Internet connection 
> was fairly shallow; unlike CMU, MIT or Stanford.
> 
> Clem
> 
> On Mon, Feb 29, 2016 at 12:33 PM, Timothe Litt  > wrote:
> On 29-Feb-16 12:34, b...@gewt.net  wrote:
>> Hello,
>> 
>> Can anyone point me at IMP documentation for the KS10? I'm only seeing AN10 
>> maintenance printsets up on Bitsavers...I'd love documentation that isn't 
>> KLH10's KS10-ITS implementation!
>> 
>> Alternatively, were any of the experimental Ethernet interfaces ever 
>> supported in TOPS-10/20 on the KS10? (I don't have access to my SRI-NIC 
>> packs due to the VM being down at present)
>> 
>> Alternatively too...the userland ANF-10 bridge could prove useful for this...
>> 
> Not clear what you want to do.
> 
> The KS does have an ARPA interface, the AN22.  I have not tracked down a spec 
> for it.  It is KMC-11 based, not simulated by SimH at present.  The TOPS-20 
> monitor sources for 4.1 are a resource.  One day I'll get access to my stuff 
> at CHM and will look for a spec.  It's on my list to see if it's worth 
> emulating.
> 
> The DEUNA is simulated in SimH.  Neither the released TOPS-10 nor TOPS-20 
> support it.  There is some TCP code floating around that does.
> 
> If you're trying to move files in and out:
>   DECnet does work (phase II on TOPS-20, Phase III or IV on TOPS-20), and 
> will talk to VAX/RSX.  You can move files by stopping on or PMR thru) one of 
> them.
> 
>   ANF-10 on the KS does work, KS-KS.  It should be possible to build the -11 
> nodes on the KS & boot them on a SimH -11.  I've been meaning to get around 
> to that, but haven't.  With ANF, besides the peripherals and terminals, you 
> get DCP.
> 
>Networking on the KS is supported on both OSs by the KDP emulator.  The 
> DMR should work, though I think there's a monitor bug in 7.04 where my 
> colleagues changed AC definitions and didn't update the DMR driver.  Also on 
> my list.
> 
> You can also move files in and out with Kermit (serial lines), cards, 
> magtape, printer.
> 
> I don't know what you mean by 'anf-10 userland bridge'.  Of course, FAL on 
> the -10 listens to both DECnet and ANF.
> 
> 
> ___
>