Discussion:
[Simh] RQ disk formats broken in the latest build?
Robert Armstrong
2018-04-10 16:46:50 UTC
Permalink
In the PDP11 simh from a couple of weeks ago, the disk image files seem to
default to simh format .. That's what I'd expect -



PDP-11 simulator V4.0-0 Current git commit id: 054e8e56

sim> set rq0 rd54

sim> set rq0 enable

sim> attach rq0 foo.rd54

RQ0: creating new file

sim> show rq0

RQ0 159MB, attached to foo.rd54, write enabled

RD54, autosize, SIMH format

sim>



Looks good. But in the latest version, it appears to be stuck in RAW
format!



PDP-11 simulator V4.0-0 Current git commit id: cc7721b9

sim> set rq0 rd54

sim> set rq0 enabled

sim> attach rq0 foo.rd54

sim> show rq0

RQ0 159MB, attached to foo.rd54, write enabled

RD54, autosize, RAW format

sim>



It didn't create an image file, and it's in RAW format now. BTW, I
thought RAW format accessed a physical device. There's no device named
"foo.rd54" - why don't I get an error for that?



Worse, I can't even make it use simh format anymore -



PDP-11 simulator V4.0-0 Current git commit id: cc7721b9

sim> set rq0 rd54

sim> set rq0 format=simh

sim> set rq0 enabled

sim> attach rq0 foo.rd54

sim> show rq0

RQ0 159MB, attached to foo.rd54, write enabled

RD54, autosize, RAW format

sim>



It's still in RAW format??!? Is it supposed to be like this?



Bob
Johnny Billquist
2018-04-10 17:26:33 UTC
Permalink
  In the PDP11 simh from a couple of weeks ago, the disk image files
seem to default to simh format ….  That’s what I’d expect –
PDP-11 simulator V4.0-0 Current */git commit id: 054e8e56/*
sim> set rq0 rd54
sim> set rq0 enable
sim> attach rq0 foo.rd54
RQ0: creating new file
sim> show rq0
RQ0     159MB, attached to foo.rd54, write enabled
        RD54, autosize, SIMH format
sim>
  Looks good…  But in the latest version, it appears to be stuck in RAW
format!
PDP-11 simulator V4.0-0 Current */git commit id: cc7721b9/*
sim> set rq0 rd54
sim> set rq0 enabled
sim> attach rq0 foo.rd54
sim> show rq0
RQ0     159MB, attached to foo.rd54, write enabled
        RD54, autosize, RAW format
sim>
  It didn’t create an image file, and it’s in RAW format now.  BTW, I
thought RAW format accessed a physical device.  There’s no device named
“foo.rd54” – why don’t I get an error for that?
  Worse, I can’t even make it use simh format anymore –
PDP-11 simulator V4.0-0 Current */git commit id: cc7721b9/*
sim> set rq0 rd54
sim> */set rq0 format=simh/*
sim> set rq0 enabled
sim> attach rq0 foo.rd54
sim> show rq0
RQ0     159MB, attached to foo.rd54, write enabled
        RD54, autosize, RAW format
sim>
It’s still in RAW format??!?  Is it supposed to be like this?
I suspect that might be ok. What is simh format, really? I mean, it's
just a bunch of blocks, and no extra information in there, unless
something changed since I last looked.

But it looks like simh might have changed how it presents things?

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Paul Koning
2018-04-10 18:06:01 UTC
Permalink
In the PDP11 simh from a couple of weeks ago, the disk image files seem to default to simh format ...
I suspect that might be ok. What is simh format, really? I mean, it's just a bunch of blocks, and no extra information in there, unless something changed since I last looked.
"Format" is a bit misleading here. It seems more a question of I/O API. "SIMH" means standard C I/O, while "raw" means something else. On Unix the distinction is probably not particularly meaningful; it may matter more on other operating systems.

paul
Robert Armstrong
2018-04-10 18:24:55 UTC
Permalink
Post by Johnny Billquist
I suspect that might be ok.
Well, empirically it doesn't work. The file foo.rd54 is never created and the disk appears offline to any guest OK. Not OK. Sorry.

Bob
Johnny Billquist
2018-04-10 18:38:25 UTC
Permalink
Post by Robert Armstrong
Post by Johnny Billquist
I suspect that might be ok.
Well, empirically it doesn't work. The file foo.rd54 is never created and the disk appears offline to any guest OK. Not OK. Sorry.
That does sound broken. But I wonder how much that has to do with the
"format". But I honestly am just guessing here. But I can't really see
that the format is the source of the problem. Paul's suggestion that
this might reflect on how the underlying storage is accessed seems
reasonable. In which case it might be indicative of some bug in simh
that has been introduced which is related in some way to what format
then means.

I guess we'll see Mark or someone else who knows the itty bitty details
to respond.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Mark Pizzolato
2018-04-10 18:46:21 UTC
Permalink
Post by Robert Armstrong
Post by Johnny Billquist
I suspect that might be ok.
In general reading and writing the data in a file in "RAW" mode vs "SIMH" mode should produce the same result. RAW uses open,read,write and close, while SIMH uses the C RTL fopen,fread,fwrite, and fclose. The C RTL does I/O when it thinks it needs to using buffers (I/O size) that it likes. RAW I/O uses the buffers (and I/O size) explicitly provided by the calling program.

As it turns out, you can successfully open a CDROM drive with either RAW or CRTL APIs, however read I/O to the CDROM generally has sector size and alignment concerns that the aren't well behaved using the CRTL's buffering.

To address this, RQ disk container files are now first opened in RAW mode and if that succeeds, things proceed just fine. If the RAW open fails (for whatever reason) things fall back to using CRTL I/O. So, for most files, you'll see them being accessed in RAW mode going forward, but as Johnny says it shouldn't matter one way or another.
Post by Robert Armstrong
Well, empirically it doesn't work. The file foo.rd54 is never created and the
disk appears offline to any guest OK. Not OK. Sorry.
This is a case I didn't test (attach a non-existing file) on Linux/Unix. What is happening here is that open is being called with mode O_RDONLY and that open succeeds and you see the strange behavior.

This is fixed now.

- Mark

Loading...