Re: [Simh] Slightly off topic: UNIX for Alpha?

2020-03-12 Thread Christian Brunschen 
NetBSD?

http://wiki.netbsd.org/ports/alpha/

// Christian

On Thu, 12 Mar 2020 at 16:23, Gary Lee Phillips 
wrote:

> Not precisely on topic here, I know. But this list shares a lot of
> relevant knowledge and experience and I have easy access, so I'm asking.
> Please forgive the distraction.
>
> I am a fairly active user of a Digital Personal Work Station (PWS) and
> generally run OpenVMS on it. I have a body of my own code for amateur radio
> antenna and signal modeling, etc. written primarily in Fortran. Looking at
> this unhappy end-of-life situation for hobbyist OpenVMS, I'm wondering if
> there is a UNIX available for that processor that doesn't require me to
> purchase an expensive license.
>
> Linux would also be acceptable, but the only Linux I found a couple of
> years ago that supported the Alpha was Gentoo, and that one didn't work all
> that well. It had no graphical interface, for one thing. I am familiar with
> UNIX and shell commands, that's not a problem. However, I do make use of
> graphical output and having no working XWindows is an issue. Debian used to
> have an Alpha port, but apparently that is no longer supported. There was a
> Windows NT for Alpha and I even have a copy, but it's very old and limited,
> and I have no Fortran or C compiler for it.
>
> DEC's own Tru64 UNIX would probably be ideal, but I have no idea whether
> it can be obtained any more or will run without an unobtainable license
> key. Any UNIX or UNIX-like system that can run GNU compilers or similar
> will probably work for me.
>
> Any thoughts on this? Comments welcome. Thanks.
>
> Gary, K9NZI
> ___
> 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] More compelling use for web server in SimH

2019-09-20 Thread Christian Brunschen 
in MAME there is actually some web UI support for a few things - I added a
simple SVG / Javascript / Websocket based UI to the "esq5505" emulator for
the Ensoniq VFX/VFX-SD/SD-1 family of synthesizers, though I'm not sure how
much further use that has as yet. Have a look in src/emu/http.cpp
,
src/mame/drivers/esq5505.cpp
,
src/mame/machine/esqpanel.cpp

 and web/esqpanel/vfx
.

Build it, run it something like

mame64 -w -rp *[rom path]* -http -http_port 8080 vfx -midiin *[MIDI input
port]*


and then point your web browser at http://localhost:8080 for an emulated
front panel. The MAME window will show the contents of the display as well,
but the emulated display in the browser window will look much more like the
real thing, react to button presses (including the occasional multi-touch
ones if you browse from a touch-enabled device) like the real thing, etc.

// Christian



On Fri, 20 Sep 2019 at 03:07, Al Kossow  wrote:

>
>
> On 9/19/19 6:01 PM, Phil Budne wrote:
> > The ideas didn't get a lot of traction
> >
>
> I proposed the same idea for MAME for the debugger panes
> to try to get around the problem of platform-independent
> graphics libraries being bloated POS, and it also got no
> traction.
>
> ___
> 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] PDP11 on Simh for public access

2018-01-23 Thread Christian Brunschen 
On 23 January 2018 at 21:34, Mark Abene  wrote:

> I remember Columbia had an ASCII-encoded kermit binary which you could
> either print/load as paper tape, or copy/paste into an editor.
>

The correct tense actually seems to be "has":

http://www.columbia.edu/kermit/pdp11.html

> Digital Equipment Corporation's PDP-11 was (and is) a 16-bit mini- or
> microcomputer used in applications ranging from embedded device control to
> general-purpose timesharing. Several different Kermit programs are
> available for the PDP-11.
>
> *Kermit-11* is the Kermit software for Digital Equipment Corporation
> PDP-11 operating systems: RT-11, RSX-11, RSTS/E, IAS, P/OS, and (not a DEC
> OS) TSX+. Kermit-11 was written by Brian Nelson of the University of
> Toledo, Ohio, circa 1984-89, in PDP-11 assembly language, Macro-11.
> Separate programs, listed below, are available for other PDP-11 operating
> systems like UNIX and MUMPS.
>
> The Kermit-11 source code is available at our ftp site
>  in the kermit/b
>  subdirectory as k11*.mac, and you
> can find prebuilt-binaries for various operating systems and configurations
> inkermit/bin/ , as k11*.tsk or
> k11*.sav. If you are unfamiliar with FTP, or have problems with it, READ
> THIS . There are also various
> utilities -- hex encoders and decoders, etc -- written Macro-11, Fortran,
> and Basic in the kermit/b directory, along with all the Kermit-11 text
> files, whose names all start with "k11".
>
:)


> That's how I loaded KERMIT on my old RSTS/E V7 system.
>

So that should all be still doable in much the same way now as it was then!


> -Mark
>

// Christian


>
>
> On Tue, Jan 23, 2018 at 12:18 PM, Bryan Davies 
> wrote:
>
>> But I've always wondered - how do you get Kermit onto the target machine?
>>
>> On 23 January 2018 at 20:16, Jordi Guillaumes Pons <
>> j...@jordi.guillaumes.name> wrote:
>>
>>>
>>> Jordi Guillaumes i Pons
>>> j...@jordi.guillaumes.name
>>> HECnet: BITXOW::JGUILLAUMES
>>>
>>>
>>>
>>> On 23 Jan 2018, at 21:13, Paul Koning  wrote:
>>>
>>> SAV files would be binaries (RT11 format).  BAS are source files.
>>>
>>> There are a number of solutions.  Text files you could load via paper
>>> tape, with the text file attached to the SIMH tape reader.  That's not as
>>> good an answer for binaries though it could be made to work.
>>>
>>> Magtape or disk are better solutions.  Disk works well if you have a
>>> program that can write disk images in a format the target OS knows.  That's
>>> easy in this case; you can use my "flx" (RSTS File Exchange) program to do
>>> this.  There's an older version written in C, a newer one written in Python
>>> 3.  For the former, look in svn://akdesign.dyndns.org/flx/branches/V2.6,
>>> for the latter, in svn://akdesign.dyndns.org/flx/trunk.  There's
>>> documentation for both in those respective directories.  (Commments and bug
>>> reports, especially for the new version, would be appreciated.)
>>>
>>>
>>> There’s always kermit…
>>>
>>
>>
>> ___
>> 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 mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Pdp8 terminals

2016-09-07 Thread Christian Brunschen 
An SMP Implementation - A Retrospective by James M. Flemming
and Christopher A. Beute
 may be interesting in
the context.

// Christian

On 7 September 2016 at 17:45, Johnny Billquist  wrote:

> The 11/782 are no more asynchronous than any multiprocessor system.
>
> The A in ASMP stands for assymetric. As in, the second processor did not
> run any kernel code, but is a slave processor to the primary processor. It
> gets scheduled with user-land code to run, but any trapping to the OS means
> it interrupts the main processor, who do all the work.
>
> Johnny
>
> On 2016-09-07 18:23, Ray Jewhurst wrote:
>
>> I think you are like I am. I would like to see every DEC simulator
>> possible. Right now I am doing some preliminary research into the
>> feasibility of a VAX 11/782 which is an asynchronous dual processor
>> 11/780.  I will need help because I am not a real experienced coder.
>>
>>
>> On Sep 6, 2016 8:21 PM, "khandy21yo" > > wrote:
>>
>> Just curious,. Is there any thought about emulating any of the Dec
>> mate Line? I used to deal with them, mostly as wps8. I don't know
>> what the hardware differences are, but I saw a large number of Dec
>> mates and only a few pdp8s. How compatible were they?
>>
>>
>>
>> Sent from my Galaxy Tab® A
>>
>>  Original message 
>> From: Ethan Dicks > >
>> Date: 9/6/16 5:00 PM (GMT-07:00)
>> To: simh@trailing-edge.com 
>> Subject: Re: [Simh] Pdp8 terminals
>>
>> On Tue, Sep 6, 2016 at 1:03 PM, Johnny Billquist > > wrote:
>> > Hi.
>> >
>> > On 2016-09-06 18:55, Bob Supnik wrote:
>> >>
>> >> The PDP8 simulator is more or less a PDP8/A, and its terminal
>> >> "multiplexor" is a KL8-JA, which implements four discrete KL8A
>> style
>> >> interfaces. These are superset compatible with the PDP8/I's PT08
>> >> discrete interfaces, and thus TSS/8 will work. Note that TSS/8
>> supports
>> >> only four discrete terminal interfaces. To get more than four
>> lines, the
>> >> configuration must have a DC08(A), a multiplexor for the PDP8/I.
>> The
>> >> DC08(A) is not implemented at the moment.
>> >
>> >
>> > This can't be correct.
>> >
>> > The KL8JA is a single line interface, compatible with the KL8E,
>> but using
>> > different hardware. You can add lots of KL8E or KL8JA interfaces
>> to a PDP8,
>> > if you wanted to. Each have a different device code, and that's
>> all there is
>> > to it. (Talking about the actual hardware here.) In addition, as
>> far as I am
>> > aware, the programming of these interfaces are pretty much the
>> same as the
>> > console interface on all other PDP-8 models as well.
>> >
>> > The KL8A was a very late device for Omnibus, which require a hex
>> wide box.
>> > It is a 4 line multiplexor, but the programming interface is
>> nothing like
>> > the KL8JA or KL8E. In addition, not all lines are the same. And
>> again, you
>> > can add several of these multiplexers to a machine, if you want to.
>>
>> Agreed... here are the handle numbers to help clarify what we are all
>> talking about...
>>
>> M8319 KL8A PDP-8/A 4 channel serial I/O
>>
>> M8650 KL8E Asynchronous Data Control (current loop or RS232)
>> M8655 KL8JA Terminal Control (UART based substitute for M8650)
>>
>>
>> The KL8E and KL8JA are, AFAIK, not easy (or not possible?) to tell
>> apart in software.  The KL8A is entirely different - the only time
>> I've ever used my KL8A was with RTS-8.  I'm not sure I have any OS/8
>> code that knows how to talk to it.  If it's out there, I'd love to
>> read it.
>>
>> >> There was a significant evolution in the PDP8 family's IO
>> controllers
>> >> from the original 8 and 8/I to the Omnibus-based 8/E and 8/A.
>>
>> Very true.  I have a bunch of the real hardware spanning the entire
>> era and, yeah, Omnibus devices and pre-Omnibus devices are commonly
>> different (I think the console 03/04 interface is, up to the DECmate
>> era, the most compatible across the spectrum).
>>
>> -ethan
>> ___
>> 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] PDP-11 DZ11 ports route to physical RS232s ?

2016-07-09 Thread Christian Brunschen 
In the current github sources, the DZ implementation

seems
to be using the general Terminal Multiplexer Library
,
which supports hardware serial ports, as documented for example here

.

Without testing anything (I have nothing to test with), perhaps commands
like

  sim>attach dz Line=1,Connect=/dev/ttyS1
  sim>attach dz Line=2,Connect=/dev/ttyS4
...

would work?

// Christian


On 9 July 2016 at 07:46, Jörg Hoppe  wrote:

> Hi,
>
> Here's a BeagleBone micro Linux system with 4 physical RS232s ports made
> available (BlinkenCape).
>
> Is it possible to connect individual PDP-11 DZ11 ports to those RS232
> ports "/dev/ttyS[1-4]" instead of telnet ports?
>
> I heard rumors about it, but documentation doesn't indicate.
> And the syntax of
> sim>set dz lines=n
> sim>attach dz 
> allows only a whole block of DZ11 ports to connect to a consecutive range
> of telnet ports, not individual assignment. Or did I miss something?
>
> Background: on VCF Mid West we want to show a multi-user RSX11
> installation with Blinkenlight panel (BlinkenBone) and several terminals
> attached.
>
> thanks,
>
> Joerg
>
> ___
> 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] vector images

2015-07-17 Thread Christian Brunschen 
From the link I posted
http://superuser.com/questions/307678/how-to-extract-files-from-msi-package,
Lessmsi http://lessmsi.activescott.com/ seems to be a good solution.
Requires a Windows system to run, but isn't going to be overwriting
anything.

// Christian



On 17 July 2015 at 15:41, Armistead, Jason BIS jason.armist...@otis.com
wrote:

  Surely it is possible to extract files from SETUP.MSI without running
 the installer.  Someone must have the tools to do this (either commercial
 or freeware perhaps ?).



 Another alternative is to run a virtual Windows OS image inside something
 like VirtualBox, thus avoiding any problems “destroying” your day-to-day
 Windows host system (if you even have one).  I you didn’t specify what
 Windows version the rimh altairz80 emulator requires, so this may or may
 not be possible.  Other alternatives to VirtualBox might be something like
 the Bochs IA-32 emulator.



 *From:* Simh [mailto:simh-boun...@trailing-edge.com] *On Behalf Of *Kevin
 Handy
 *Sent:* Thursday, 16 July 2015 8:50 PM
 *To:* Dennis Boone
 *Cc:* simh@trailing-edge.com
 *Subject:* Re: [Simh] vector images



 Yes, they are there, in a file called setup.msi, and nowhere else.

 So, as long as you ahve a windows machine that you don;t care if it
 installs older file on top of newer ones,  I had to re-install too many
 windows systems because of this, and finding all of the right install
 pckges, and figuring out the proprt order to reinstall them to get a
 working system was always a pain. msi is the old install format that
 comonly had this problem.

 However, I think I have come up with a painful, roundabout way to extract
 the files, maybe. If not, I was just curious about its memory mapped video,
 ans if the flexwriter emulation was useful enough to bother with. If this
 doesn't work, I'll just have to give up on it.



 On Thu, Jul 16, 2015 at 8:44 PM, Dennis Boone d...@msu.edu wrote:

   Many companies builf computers that  used this operating system, like
   the altair, imsai, osborne, kaypro, and vector graPhics to name a
   few.  Many years later, the rimh altairz80 emulator was written with
   the abiliry ro emulate the vector graphic machines, but the only copy
   of the necessary config and disk images was wrapped up in a miceosoft
   install file called setup.msi.

 1. Vector Graphic, no s.

 2. Most of the stuff in the altairz80 kits is probably available from
 vector-archive.org.

 De

 ___
 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 mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] cdecl

2015-06-30 Thread Christian Brunschen 
There is also http://www.cdecl.org/ ...

// Christian

On 30 June 2015 at 16:19, R P Herrold herr...@owlriver.com wrote:

 On Mon, 29 Jun 2015, Bill Cunningham wrote:

  I guess cdecl was removed from my distro of linux;
  fedora because of copyright concerns. I have read the
  project was long dead.

 There is less there than meets the eye, but it was formerly in
 CentOS, and PUIAS

 the SRPM rebuilds trivially on C 6 -- I placed a copy, after
 rebuild, out at:
 ftp://ftp.owlriver.com/pub/local/ORC/cdecl/

 -- Russ herrold


 --
 --
 end
 ==
  .-- -... ---.. ... -.- -.--
 Copyright (C) 2015 R P Herrold
   herr...@owlriver.com
My words are not deathless prose,
   but they are mine.
 ___
 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] cdecl

2015-06-30 Thread Christian Brunschen 
My point was more that you can ask http://www.cdecl.org directly, without
having to install anything anywhere.

// Christian

On 30 June 2015 at 16:42, R P Herrold herr...@owlriver.com wrote:

 On Tue, 30 Jun 2015, Christian Brunschen wrote:

  There is also http://www.cdecl.org/ ...

 noted -- but that is a (the same, actually) tarball; for
 people using the RPM package namagement system, the SRPM
 simplifies matters

 -- Russ herrold

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

Re: [Simh] PDP7 DECtapes

2015-06-07 Thread Christian Brunschen 
I wonder if it would be worth putting together something like the Kryoflux
http://www.kryoflux.com/?page=kf_features for tape drives (the Kryoflux a
device that connects directly to the floppy drive instead of through a
floppy controller, and records the timings of the magnetic transitions at a
low level, so that they can be used to extract data, or duplicate a floppy,
in almost any format).

// Christian

On 7 June 2015 at 03:47, Bob Supnik b...@supnik.org wrote:

 Yeah, PDP-7 (and earlier) DECtapes are different. They use different
 checksum algorithms, for one thing, and some early PDP-4 and -7 DECtape
 controllers used four-word headers instead of five. The checksum is
 probably key; only five four word header DECtape controllers escaped the
 factory.

 /* Checksum routine */

 int32 dt_csum (UNIT *uptr, int32 blk)
 {
 int32 *fbuf = (int32 *) uptr-filebuf;
 int32 ba = blk * DTU_BSIZE (uptr);
 int32 i, csum, wrd;

 #if defined (TC02)  /* TC02/TC15 */
 csum = 077; /* init csum */
 for (i = 0; i  DTU_BSIZE (uptr); i++) {/* loop thru buf */
 wrd = fbuf[ba + i] ^ DMASK; /* get ~word */
 csum = csum ^ (wrd  12) ^ (wrd  6) ^ wrd;
 }
 return (csum  077);
 #else   /* Type 550 */
 csum = 077;
 for (i = 0; i  DTU_BSIZE (uptr); i++) {/* loop thru buf */
 wrd = fbuf[ba + i]; /* get word */
 csum = csum + wrd;  /* 1's comp add */
 if (csum  DMASK)
 csum = (csum + 1)  DMASK;
 }
 return (csum ^ DMASK);  /* 1's comp res */
 #endif
 }

 This is documented in the 18b PDP DECtape controller, based on sources I
 have for PDP-7 DECtape code from the late 60s; but for some reason, I never
 published a paper on it.

 This is one reason why recovering DECsys required reading the DECtape on
 the last working PDP-7 in the world.

 /Bob
 ___
 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] Musings on potential SIMH candidate systems

2015-04-11 Thread Christian Brunschen 
You're aware there's an emulator of sorts already in progress?

  http://rottedbits.blogspot.co.uk/2013/05/imlac-emulator-progress.html

// Christian

On 11 April 2015 at 23:20, Alan Frisbie fris...@flying-disk.com wrote:

 I am only just getting started with SIMH, so perhaps I'm getting
 a bit ahead of myself, but here goes...

 A classic graphics system of the early 1970s was the Imlac PDS-1.
 The display was a vector-stroke type, driven by a display list in
 memory and continuously refreshed.   It had a CPU for
 communicating with a host (typically a PDP-10) and local
 calculations, and a GPU (Graphics Processing Unit) for executing
 the elements of the graphics display list, both running out of
 the same memory.   Peripherals were generally limited to a serial
 line, the light pen, and a single switch (often a foot switch).

 The CPU looked very much like a 16-bit PDP-8, which should be
 almost trivial to simulate.   The GPU would be a bit trickier,
 as it would have to draw lines on the host's display.   The real
 problem, as I see it, would be how to have *two* simulated
 computers operating simultaneously from the same memory.   I seem
 to recall a discussion on this list about how that would be
 difficult, but can't recall the details.

 Does anyone have any ideas on how this might be done?

 I would be interested in doing it, as I just happen to have an
 Imlac PDS-1D here, and would like have a simulator before I sell
 the actual unit.   I also have a complete set of documentation
 with all schematics, plus some software.


 A second system of interest is the CDC 6600.   Again, the problem
 as I see it is combination of a CPU and multiple PPUs (Peripheral
 Processing Units).   It also used ones-complement arithmetic,
 which might cause difficulties.   Does anyone have any thoughts
 on these matters?

 Alan Frisbie
 ___
 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] DEC floppy disk interleave questions

2015-03-09 Thread Christian Brunschen 
I hope it can be useful to you!

A related interesting device, which does pretty much the opposite, is the HxC
Floppy Emulator http://hxc2001.free.fr/floppy_drive_emulator/ - which
emulates a physical floppy drive using an SD card to store floppy disk
images. Also, people are starting to use Raspberry Pis to emulate floppy
drives for the Amiga http://amigadrive.blogspot.co.uk/.

// Christian



On 8 March 2015 at 19:39, Howard M. Harte hha...@hartetechnologies.com
wrote:

 Thanks Christian, very interesting.  I just ordered one.



 *From:* Christian Brunschen [mailto:christ...@brunschen.com]
 *Sent:* Sunday, March 8, 2015 3:14 AM
 *To:* Howard M. Harte
 *Cc:* Alan Frisbie; SIMH@trailing-edge.com

 *Subject:* Re: [Simh] DEC floppy disk interleave questions



 Potentially interesting for reading floppy disks at a low level: Kryoflyx
 http://kryoflux.com/.



 // Christian



 On 8 March 2015 at 02:14, Howard M. Harte hha...@hartetechnologies.com
 wrote:

 Dave Dunfield's ImageDisk (.IMD) format can preserve the floppy disk
 metadata.  He has some DEC disk images in this format on his site:
 http://www.classiccmp.org/dunfield/img/index.htm

 When I implemented several floppy disk controllers for the SIMH/AltairZ80
 simulator several years ago, I wrote a module for SIMH called sim_imd which
 can utilize the ImageDisk format within SIMH.  At that time, I had a patch
 to make it work as an alternate to the flat file format that is normally
 used for SIMH for the pdp_rx disk controller.  I tested sim_imd with the
 PDP-11 RT11 disk image from Dave's site, and it worked fine.

 I may be incorrect, but if I remember correctly, the RX02 disks have the
 sector header in single-density and the data field in double-density.  In
 that case, I don't think ImageDisk will be able to handle it.  If you hook
 up an 8 floppy drive to a semi-modern PC motherboard with the right disk
 controller, then you may be able to read at least RX01 disks with
 ImageDisk.  Last time I tried this was around 2008, and I believe I used an
 Intel Desktop Board with Pentium 4 CPU and Shugart 800 drives.

 Only certain PC floppy controllers can read single-density, and even fewer
 can write it.

 Preserving the sector headers is fairly important in my opinion.  It
 allows the image to be written back to a physical disk and used on real
 hardware.  That said, just getting the data off the disk in a flat file is
 still very useful for most purposes.

 -Howard


 -Original Message-
 From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny
 Billquist
 Sent: Saturday, March 7, 2015 4:52 PM
 To: Alan Frisbie; SIMH@trailing-edge.com
 Subject: Re: [Simh] DEC floppy disk interleave questions

 Hi, Alan.

 On 2015-03-08 00:47, Alan Frisbie wrote:
  I have a large quantity of disks that I wish to copy to files that can
  be directly used by the SIMH PDP-11 emulator and by the
  E11 emulator.   They include 8 floppies (both RX01 and RX02),
  RL01, and RL02.
 
  The issue is that the disks have sector sizes that differ from the
  usual 512 bytes, as well as having interesting interleave
  and stagger factors.   RX50 (and RX33?) disks have (I think)
  512-byte sectors, but some odd track usage.   I also believe
  that RX02 disks have the first track in single-density mode, just to
  complicate things, but it isn't used by most DEC O/S
  software.   RL01 and RL02 disks also have bad-block sectors
  at the end of the disk.
 
  I am assuming that SIMH and E11 emulate the device faithfully enough
  that programs which are aware of the interleaving and
  small sector sizes will work properly.   If this assumption is
  wrong, please enlighten me.
 
  If my assumption is correct, what is the best way to copy the raw
  disks (which are in a variety of O/S formats) to files which the
  emulators will be happy with.   I can bring up a real PDP-11 with
  RX02, but will probably be using a microVAX-II with an Andromeda
  FDC11-B controller and Shugart 800 drives.   I don't mind writing
  my own code with QIOs.
 
  I have a bunch more questions related to this, but this will
  do for now.   :-)
 
  All of this is related to cleaning out my storage units and
  de-cluttering my life.

 Hmm, I believe this is not absolutely straight forward. The problem is
 that simh (or E11) do not emulate the physical layer, but the logical one.
 As such, the image files of disks are assumed to always be containing
 sequential blocks, and no block headers are in the image file.
 So, it will work, in that, if you can dump out an image from a disk, where
 block #1 is block #1 on the image file, then things will just work fine.
 If you dump out the physical blocks raw, including block headers, then
 they are not usable by the emulators.
 Logical rearranging of blocks will work fine, though. So, the trick you
 normally see with RX01/RX02, where they remap block numbers to other blocks
 numbers in the device driver, is just fine. You just want the actual
 physical

Re: [Simh] DEC floppy disk interleave questions

2015-03-08 Thread Christian Brunschen 
Potentially interesting for reading floppy disks at a low level: Kryoflyx
http://kryoflux.com/.

// Christian

On 8 March 2015 at 02:14, Howard M. Harte hha...@hartetechnologies.com
wrote:

 Dave Dunfield's ImageDisk (.IMD) format can preserve the floppy disk
 metadata.  He has some DEC disk images in this format on his site:
 http://www.classiccmp.org/dunfield/img/index.htm

 When I implemented several floppy disk controllers for the SIMH/AltairZ80
 simulator several years ago, I wrote a module for SIMH called sim_imd which
 can utilize the ImageDisk format within SIMH.  At that time, I had a patch
 to make it work as an alternate to the flat file format that is normally
 used for SIMH for the pdp_rx disk controller.  I tested sim_imd with the
 PDP-11 RT11 disk image from Dave's site, and it worked fine.

 I may be incorrect, but if I remember correctly, the RX02 disks have the
 sector header in single-density and the data field in double-density.  In
 that case, I don't think ImageDisk will be able to handle it.  If you hook
 up an 8 floppy drive to a semi-modern PC motherboard with the right disk
 controller, then you may be able to read at least RX01 disks with
 ImageDisk.  Last time I tried this was around 2008, and I believe I used an
 Intel Desktop Board with Pentium 4 CPU and Shugart 800 drives.

 Only certain PC floppy controllers can read single-density, and even fewer
 can write it.

 Preserving the sector headers is fairly important in my opinion.  It
 allows the image to be written back to a physical disk and used on real
 hardware.  That said, just getting the data off the disk in a flat file is
 still very useful for most purposes.

 -Howard

 -Original Message-
 From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny
 Billquist
 Sent: Saturday, March 7, 2015 4:52 PM
 To: Alan Frisbie; SIMH@trailing-edge.com
 Subject: Re: [Simh] DEC floppy disk interleave questions

 Hi, Alan.

 On 2015-03-08 00:47, Alan Frisbie wrote:
  I have a large quantity of disks that I wish to copy to files that can
  be directly used by the SIMH PDP-11 emulator and by the
  E11 emulator.   They include 8 floppies (both RX01 and RX02),
  RL01, and RL02.
 
  The issue is that the disks have sector sizes that differ from the
  usual 512 bytes, as well as having interesting interleave
  and stagger factors.   RX50 (and RX33?) disks have (I think)
  512-byte sectors, but some odd track usage.   I also believe
  that RX02 disks have the first track in single-density mode, just to
  complicate things, but it isn't used by most DEC O/S
  software.   RL01 and RL02 disks also have bad-block sectors
  at the end of the disk.
 
  I am assuming that SIMH and E11 emulate the device faithfully enough
  that programs which are aware of the interleaving and
  small sector sizes will work properly.   If this assumption is
  wrong, please enlighten me.
 
  If my assumption is correct, what is the best way to copy the raw
  disks (which are in a variety of O/S formats) to files which the
  emulators will be happy with.   I can bring up a real PDP-11 with
  RX02, but will probably be using a microVAX-II with an Andromeda
  FDC11-B controller and Shugart 800 drives.   I don't mind writing
  my own code with QIOs.
 
  I have a bunch more questions related to this, but this will
  do for now.   :-)
 
  All of this is related to cleaning out my storage units and
  de-cluttering my life.

 Hmm, I believe this is not absolutely straight forward. The problem is
 that simh (or E11) do not emulate the physical layer, but the logical one.
 As such, the image files of disks are assumed to always be containing
 sequential blocks, and no block headers are in the image file.
 So, it will work, in that, if you can dump out an image from a disk, where
 block #1 is block #1 on the image file, then things will just work fine.
 If you dump out the physical blocks raw, including block headers, then
 they are not usable by the emulators.
 Logical rearranging of blocks will work fine, though. So, the trick you
 normally see with RX01/RX02, where they remap block numbers to other blocks
 numbers in the device driver, is just fine. You just want the actual
 physical blocks, in the order they are on the disk. )As indicated by the
 disk block headers.) The actual layout, as created when formatting the
 disk, will not carry over, but it is also not important.
 (I hope I'm making sense here, I feel I might be overcomplicating my
 text...)

 Bad blocks, as described by the RL01/RL02 bad block tables, are totally
 under the device drivers and system software, so that is just fine.
 Systems will avoid those blocks, even on a dumped image of the disk,
 assuming you copy all blocks, including the bad block list.

 Johnny

 --
 Johnny Billquist  || I'm on a bus
||  on a psychedelic trip
 email: b...@softjar.se ||  Reading murder books
 pdp is alive! ||