15 Nov
2019
15 Nov
'19
4:42 a.m.
Ok version number or "git commit id" On the version I am using is
178968a, the version I downloaded from the link you sent me is bdc677b7.
They are indeed very different.
Bill
15 Nov
15 Nov
4:48 a.m.
On Thursday, November 14, 2019 at 7:42 PM, Bill Cunningham wrote:
2 things:
1) Don't expect later commands to be even slightly useful until AFTER you get the
earlier commands working as expected (i.e. the proper ATT TQ -F ANSI-VMS command).
2) Either _BUC$MUA0: or simply MUA0: will work once you've gotten far enough along.
If it doesn't then please show us exactly what error messages you are receiving.
You seemed to suggest that you were working on a Linux environment, use cut and paste from
the xterm session you are running under. If that's not what you're using, then
please explain exactly what's going on. Since you don't seem to be that familiar
with working in this environment, how did you manage to get the license file from where
you received the email to the environment you're running simh in?
- Mark
Ok version number or "git commit id" On the
version I am using is 178968a, the
version I downloaded from the link you sent me is bdc677b7.
They are indeed very different.
Well, git commit ids are merely a hash value. There is nothing sequential about them.
178968a is from some 11 days ago and should certainly be more recent enough to perform the
steps I outlined, so you shouldn't need to rebuild the simulator.
$
MOUNT/OVER=ID MUA0:
The above gives me a list of errors. The OS does not like
it at all and IDK how
to copy the errors to a file to post them. It wants
_BUC$MUA0: . Not MUA0: at all.
8:05 p.m.
On 11/14/2019 10:48 PM, Mark Pizzolato wrote:
On Thursday, November 14, 2019 at 7:42 PM, Bill
Cunningham wrote:
2 things:
1) Don't expect later commands to be even slightly useful until AFTER you get the
earlier commands working as expected (i.e. the proper ATT TQ -F ANSI-VMS command).
2) Either _BUC$MUA0: or simply MUA0: will work once you've gotten far enough along.
If it doesn't then please show us exactly what error messages you are receiving.
You seemed to suggest that you were working on a Linux environment, use cut and paste
from the xterm session you are running under. If that's not what you're using,
then please explain exactly what's going on. Since you don't seem to be that
familiar with working in this environment, how did you manage to get the license file from
where you received the email to the environment you're running simh in?
- Mark
One thing I despise generally Mark is GUIs, I have been working from
CLI. But I installed the LDXE desktop environment which I don't know
much about but copy/paste should be simple. LDXE gave me one Hell of a
time with copy/paste, and absolutely whatever I did would not let me
select from xterm or the desktop the errors. So I wrote them down and
will simply copy myself.
sim> att tq -f ansi-vms vmst /* the license file */
Can't open: //mst - no such file or directory.
Can't open tape image.
Of course there might be something I am forgetting and not doing here.
I also type at the prompt in all caps, same result. For example,
ATT -F ANSI-VMS? VMST
Same errors.
Bill
Ok version number or "git commit id" On
the version I am using is 178968a, the
version I downloaded from the link you sent me is bdc677b7.
They are indeed very different.
Well, git commit ids are merely a hash value.
There is nothing sequential about them. 178968a is from some 11 days ago and should
certainly be more recent enough to perform the steps I outlined, so you shouldn't need
to rebuild the simulator.
$
MOUNT/OVER=ID MUA0:
The above gives me a list of errors. The OS does not like
it at all and IDK how
to copy the errors to a file to post them. It wants
_BUC$MUA0: . Not MUA0: at all. 
8:27 p.m.
On Nov 15, 2019, at 2:05 PM, Bill Cunningham
<bill.cu at suddenlink.net> wrote:
...
sim> att tq -f ansi-vms vmst /* the license file */
Can't open: //mst - no such file or directory.
Can't open tape image.
Of course there might be something I am forgetting and not doing here.
I also type at the prompt in all caps, same result. For example,
ATT -F ANSI-VMS VMST
Same errors.
Bill
I wonder if the SIMH command parser gets confused by the hyphen in the file name. The
message makes it look like it's mistaking -v for a switch, so it's parsing it as
if it were:
sim> att tq -f ansi -v ms vmst
which would of course be a problem. Try removing the - or replacing it by an underscore.
paul
16 Nov
16 Nov
9:40 a.m.
On Friday, November 15, 2019 at 11:06 AM, Bill Cunningham wrote:
[...]
sim> att tq -f ansi-vms vmst /* the license file
*/
Can't open: //mst - no such file or directory.
Can't open tape image.
If you look at the very explicit instructions I originally outlined, you really didn't
follow them.
The HELP TQ ATTACH provides several examples of situations that would work.
Meanwhile you typed:
sim> att tq -f ansi-vms vmst /* the license file */
In this command EVERYTHING beyond the ansi-vms token is considered a list of space or
comma delimited file names, or wildcard file names.
In this example, this list would be:
vmst
Everything in the / directory
the
license
file
Everything in the current directory
The / directory file itself.
The auto tape assembly process that is implemented by this command might treat directory
files as binary data, I'm not sure, but trying to pass the / directory and any
directories in it as files on a tape is likely a meaningless operation.
Possibly only one of these would be valid (vmst).
Of course there might be something I am forgetting and
not doing here.
I also type at the prompt in all caps, same result. For example,
ATT -F ANSI-VMS? VMST
You are working on a Linux system which has case sensitive file names, so there is a
distinct difference between vmst and VMST. This command is missing the device name TQ as
well...
The simh commands and many of their arguments (ansi-vms and -f) are case insensitive, but
filenames are whatever the host system supports.
In the latest commit, I've enriched the error messages issued when unrecognized
arguments/files are presented to a tape attach.
- Mark
8:05 p.m.
On 11/16/2019 3:40 AM, Mark Pizzolato wrote:
I will send this. This looks to me like it isn't showing what we want to
see. Meanwhile I will download the latest commit and try again. And a
new license copy and not rename it.
Bill
On Friday, November 15, 2019 at 11:06 AM, Bill
Cunningham wrote:
[...]
Nothing was typed after vmst. The
C style comment was a note.
sim> att tq -f ansi-vms vmst /* the license
file */
Can't open: //mst - no such file or directory.
Can't open tape image.
If you look at the very explicit instructions I
originally outlined, you really didn't follow them.
The HELP TQ ATTACH provides several examples of situations that would work.
Meanwhile you typed:
sim> att tq -f ansi-vms vmst /* the license
file */
In this command EVERYTHING beyond the ansi-vms token is considered a list
of space or comma delimited file names, or wildcard file names.
In this example, this list would be:
vmst
Everything in the / directory
the
license
file
Everything in the current directory
The / directory file itself.
The auto tape assembly process that is implemented by this command might treat directory
files as binary data, I'm not sure, but trying to pass the / directory and any
directories in it as files on a tape is likely a meaningless operation.
Possibly only one of these would be valid (vmst). Of course
there might be something I am forgetting and not doing here.
I also type at the prompt in all caps, same result. For example,
ATT -F ANSI-VMS? VMST
You are working on a Linux system which has case sensitive
file names, so there is a distinct difference between vmst and VMST. This command is
missing the device name TQ as well...
The simh commands and many of their arguments (ansi-vms and -f) are case insensitive, but
filenames are whatever the host system supports.
In the latest commit, I've enriched the error messages issued when unrecognized
arguments/files are presented to a tape attach.
- Mark
8:25 p.m.
On 11/16/2019 3:40 AM, Mark Pizzolato wrote:
You are working on a Linux system which has case sensitive file names, so there is a
distinct difference between vmst and VMST. This command is missing the device name TQ as
well...
The simh commands and many of their arguments (ansi-vms and -f) are case insensitive, but
filenames are whatever the host system supports.
In the latest commit, I've enriched the error messages issued when unrecognized
arguments/files are presented to a tape attach.
- Mark
OK I went to git and downloaded using the "clone" button the latest zip
file. copied to linux's partition and uses "unzip -a simh-master.zip". A
new directory was created. Here's the new log file. I show all I think
is the question.
9:16 p.m.
On Saturday, November 16, 2019 at 11:26 AM, Bill Cunningham wrote:
On 11/16/2019 3:40 AM, Mark Pizzolato wrote:
If you're using git, "git clone" is what you do to get a local
"clone" of a remote repository (including all the git plumbing found in the .git
directory). If you're already working in a directory produced by a previous clone,
you shouldn't be able to clone to that directory.
In any case, cloning produces a working directory with the contents of the repo you just
cloned. It DOES NOT produce a zip file. You can fetch a zip file (also referred to as a
"git archive") of the latest code (without any git plumbing) from
https://github.com/simh/simh/archive/master.zip You can then expand this zip and build.
Either approach works, but they DO NOT mix.
I explained the above since you do not appear to have picked up the latest code, which
has a commit id of 318b0e32.
You are working on a Linux system which has case sensitive file names, so
there is
a distinct difference between vmst and VMST. This command is
missing the device name TQ as well...
The simh commands and many of their arguments (ansi-vms and -f) are case
insensitive, but filenames are whatever the host system supports.
In the latest commit, I've enriched the error messages issued when
unrecognized arguments/files are presented to a tape attach.
- Mark
OK I went to git and downloaded using the "clone" button the latest zip file.
copied to linux's partition and uses "unzip
-a simh-master.zip". A new directory
was created. Here's the new log file. I show all I think is the question.
I just now performed:
mark at Linux:~$ wget https://github.com/simh/simh/archive/master.zip
--2019-11-16 11:53:54-- https://github.com/simh/simh/archive/master.zip
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/simh/simh/zip/master [following]
--2019-11-16 11:54:00-- https://codeload.github.com/simh/simh/zip/master
Resolving codeload.github.com (codeload.github.com)... 192.30.255.121
Connecting to codeload.github.com (codeload.github.com)|192.30.255.121|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: ?master.zip?
master.zip [ <=>
] 18.52M 6.32MB/s in 2.9s
2019-11-16 11:54:07 (6.32 MB/s) - ?master.zip? saved [19415613]
mark at Linux:~$ unzip master.zip
Archive: master.zip
318b0e32bb874207772686e28cd2ffbcf1da083e
creating: simh-master/
[...]
inflating: simh-master/swtp6800/swtp6800/swtp_swtbug_bin.h
mark at Linux:~$ cd simh-master/
mark at Linux:~/simh-master$ make vax
lib paths are: /lib/ /lib/x86_64-linux-gnu/ /lib32/ /usr/lib/ /usr/lib/x86_64-linux-gnu/
/usr/lib/x86_64-linux-gnu/libfakeroot/ /usr/lib32/
include paths are: /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include
using libm: /usr/lib/x86_64-linux-gnu/libm.so
using librt: /usr/lib/x86_64-linux-gnu/librt.so
using libpthread: /usr/lib/x86_64-linux-gnu/libpthread.so /usr/include/pthread.h
using libpcreposix: /usr/lib/x86_64-linux-gnu/libpcreposix.so
/usr/lib/x86_64-linux-gnu/libpcre.so /usr/include/pcreposix.h /usr/include/pcre.h
using semaphore: /usr/include/semaphore.h
using libdl: /usr/lib/x86_64-linux-gnu/libdl.so /usr/include/dlfcn.h
using mman: /usr/include/x86_64-linux-gnu/sys/mman.h
using libSDL2: /usr/include/SDL2/SDL.h
using libpcap: /usr/include/pcap.h
*** Info ***
*** Info *** vax Simulator is being built with
*** Info *** minimal libpcap networking support
*** Info ***
*** Info ***
*** Info *** Simulators on your Linux platform can also be built with
*** Info *** extended LAN Ethernet networking support by using VDE Ethernet.
*** Info ***
*** Info *** To build simulator(s) with extended networking support you
*** Info *** should install the vde2 package to provide this
*** Info *** functionality for your Linux system:
*** Info *** $ sudo apt-get install libvdeplug-dev
*** Info ***
***
*** vax Simulator being built with:
*** - compiler optimizations and no debugging support. GCC Version: 7.4.0.
*** - dynamic networking support using Linux provided libpcap components.
*** - Local LAN packet transports: PCAP TAP NAT(SLiRP)
*** - video capabilities provided by libSDL2 (Simple Directmedia Layer).
*** - Per simulator tests will be run.
***
*** git commit id is 318b0e32bb874207772686e28cd2ffbcf1da083e.
*** git commit time is 2019-11-16T00:39:01-08:00.
***
gcc -std=gnu99 -U__STRICT_ANSI__ -O2 -finline-functions -fgcse-after-reload
-fpredictive-commoning -fipa-cp-clone -fno-unsafe-loop-optimizations -fno-strict-overflow
-Wno-unused-result -Wno-format-truncation
-DSIM_GIT_COMMIT_ID=318b0e32bb874207772686e28cd2ffbcf1da083e
-DSIM_GIT_COMMIT_TIME=2019-11-16T00:39:01-08:00 -DSIM_COMPILER="GCC Version:
7.4.0" -I . -D_GNU_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_PCREPOSIX_H
-DHAVE_SEMAPHORE -DHAVE_SYS_IOCTL -DHAVE_LINUX_CDROM -DHAVE_DLOPEN=so -DHAVE_UTIME
-DHAVE_GLOB -DHAVE_SHM_OPEN VAX/vax_cpu.c VAX/vax_cpu1.c VAX/vax_fpa.c VAX/vax_io.c
VAX/vax_cis.c VAX/vax_octa.c VAX/vax_cmode.c VAX/vax_mmu.c VAX/vax_stddev.c
VAX/vax_sysdev.c VAX/vax_sys.c VAX/vax_syscm.c VAX/vax_syslist.c VAX/vax_vc.c
VAX/vax_lk.c VAX/vax_vs.c VAX/vax_2681.c PDP11/pdp11_rl.c PDP11/pdp11_rq.c
PDP11/pdp11_ts.c PDP11/pdp11_dz.c PDP11/pdp11_lp.c PDP11/pdp11_tq.c PDP11/pdp11_xq.c
PDP11/pdp11_vh.c PDP11/pdp11_cr.c PDP11/pdp11_td.c PDP11/pdp11_io_lib.c scp.c
sim_console.c sim_fio.c sim_timer.c sim_sock.c sim_tmxr.c sim_ether.c sim_tape.c
sim_disk.c sim_serial.c sim_video.c sim_imd.c sim_card.c -DVM_VAX -DUSE_INT64 -DUSE_ADDR64
-DUSE_SIM_VIDEO -I VAX -I PDP11 -DHAVE_PCAP_NETWORK -I/usr/include/ -DBPF_CONST_STRING
-DUSE_SHARED -DHAVE_TAP_NETWORK -Islirp -Islirp_glue -Islirp_glue/qemu
-DHAVE_SLIRP_NETWORK -DUSE_SIMH_SLIRP_DEBUG slirp/*.c slirp_glue/*.c -DHAVE_LIBSDL
-DUSE_SIM_VIDEO `/usr/bin/sdl2-config --cflags` `/usr/bin/sdl2-config --libs` -o
BIN/microvax3900 -lm -lrt -lpthread -lpcreposix -lpcre -ldl
cp BIN/microvax3900 BIN/vax
BIN/microvax3900 /home/mark/simh-master/VAX/tests/vax-diag_test.ini
MicroVAX 3900 simulator V4.0-0 Current git commit id: 318b0e32
Running Hardware Core Test (EHKAA)
*** PASSED - MicroVAX 3900 Hardware Core Instruction test EHKAA
mark at Linux:~/simh-master$ BIN/vax
MicroVAX 3900 simulator V4.0-0 Current git commit id: 318b0e32
sim> att tq -f ansi-vms Hob*
file not found: Hob*
Can't open ANSI-VMS format tape image: Hob*
sim>
Notice that I didn't expect success here. I'm just demonstrating 1) the updated
commit id, and 2) the error messages issued when errors occur.
- Mark
9:43 p.m.
On 11/16/2019 3:16 PM, Mark Pizzolato wrote:
On Saturday, November 16, 2019 at 11:26 AM, Bill
Cunningham wrote:
On 11/16/2019 3:40 AM, Mark Pizzolato wrote:
If you're using git, "git clone" is what you do to
get a local "clone" of a remote repository (including all the git plumbing found
in the .git directory). If you're already working in a directory produced by a
previous clone, you shouldn't be able to clone to that directory.
In any case, cloning produces a working directory with the contents of the repo you just
cloned. It DOES NOT produce a zip file. You can fetch a zip file (also referred to as a
"git archive") of the latest code (without any git plumbing) from
https://github.com/simh/simh/archive/master.zip You can then expand this zip and build.
Either approach works, but they DO NOT mix.
I explained the above since you do not appear to have picked up the latest code, which
has a commit id of 318b0e32. You are working on a Linux system which has case
sensitive file names, so
there is a distinct difference between vmst and VMST.
This command is
missing the device name TQ as well...
The simh commands and many of their arguments
(ansi-vms and -f) are case
insensitive, but filenames are whatever the host system supports.
In the latest commit, I've enriched the error messages issued when
unrecognized arguments/files are presented to a tape attach.
- Mark
OK I went to git and downloaded using the "clone" button the
latest zip file. ...
Ok I went to the link above and downloaded that simh-master.zip The
commit id is the same. There were also quite a few invisible directories
and files. A couple of files or so and a directory called "Travis" and
".git" directories too. I guess it is ok to remove these invisible files
and directories? Is this the "plumbing" you meant? And the nvram code I
use is the "Ka655x.bin" I should mention that too.
Bill
9:53 p.m.
On Saturday, November 16, 2019 at 12:43 PM, Bill Cunningham wrote:
On 11/16/2019 3:16 PM, Mark Pizzolato wrote:
Maybe the commit id for the source you fetched is the same, you currently aren't
running that version (confirm simply by looking at what is displayed when you start the
simulator). After you pick up new source, you have to build a new binary.
On Saturday, November 16, 2019 at 11:26 AM, Bill
Cunningham wrote:
repository (including all the git
plumbing found in the .git directory). If you're
already working in a directory produced by a previous clone, you shouldn't be
able to clone to that directory.
On 11/16/2019 3:40 AM, Mark Pizzolato wrote:
If you're using git, "git clone" is what you do to
get a local "clone" of a remote You are working on a Linux system which has case
sensitive file
names, so
there is a distinct difference between vmst and VMST. This command
is missing the device name TQ as well...
The simh commands and many of their arguments
(ansi-vms and -f) are
case insensitive, but filenames are whatever the host system supports.
In the latest commit, I've enriched the error messages issued when
unrecognized arguments/files are presented to a tape attach.
- Mark
OK I went to git and downloaded using the "clone" button the
latest zip file.
In any case, cloning produces a working directory with the contents of the
repo
you just cloned. It DOES NOT produce a zip file. You can fetch a zip file
(also referred to as a "git archive") of the latest code (without any git
plumbing) from https://github.com/simh/simh/archive/master.zip You can
then expand this zip and build. Either approach works, but they DO NOT mix.
I explained the above since you do not appear to have picked up the latest
code,
which has a commit id of 318b0e32.
...
Ok I went to the link above and downloaded that simh-master.zip The commit
id is the same. There were also quite a few invisible directories and
files. A
couple of files or so and a directory called "Travis" and ".git"
directories too. I
guess it is ok to remove these invisible files and directories?
Leave them there if you are working in that directory. If you want git to fetch the
latest updated code, "git pull https://github.com/simh/simh" should do the
trick.
Is this the "plumbing" you meant?
Yes.
And the nvram code I use is the "Ka655x.bin"
I should mention that too.
You don't need to load a Ka655x.bin. It is built-in and will automatically be used if
you don't explicitly attempt to load a different firmware version. The built-in
version will always work correctly. Other versions may not be 'best'.
17 Nov
17 Nov
1:21 a.m.
New subject: 9600 bps
A terminal running at 9600 baud, 8N1, would display/process one
character approximately every millisecond (1066.6666 characters in 1000
milliseconds).
Is this math correct?
1:33 a.m.
New subject: 9600 bps
Almost.
8N1 means there will be 1 start bit, 8 data bits and 1 stop bit, thus 10 bits per byte.
960 characters in 1000 milliseconds.
Your math below looks like you worked this out with 9 bits per byte.
But in the bigger picture yes ? approximately one character per millisecond.
Cheers, Wiz!!
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Supratim Sanyal
Sent: Sunday, 17 November 2019 11:21 AM
To: hecnet at Update.UU.SE
Subject: [HECnet] 9600 bps
A terminal running at 9600 baud, 8N1, would display/process one character approximately
every millisecond (1066.6666 characters in 1000 milliseconds).
Is this math correct?
2:45 a.m.
New subject: 9600 bps
What context are you doing this in?
If you are driving this output from a simh simulator, connections to the DZ and VH devices
already run at the speeds that the speed each multiplexer line is programmed to run at.
Impatient folks who can?t stand to wait for output at the ?natural? line speed can
configure the multiplexer to deliver data from 2 to 32 times faster than the programmed
speeds.
Simulator console port speeds can also be set to run a specific rates. This is explicitly
controlled in the simulator configuration files since console ports didn?t have
programmable port speeds. SET CONSOLE SPEED=n generally works.
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Supratim Sanyal
Sent: Saturday, November 16, 2019 4:38 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] 9600 bps
On 11/16/2019 07:33 PM, David Moylan wrote:
Cheers, Wiz!!
ah! was wondering :)
thanks. basically trying to write a simple program to filter the old VT100 demo text files
to slow them down (calculate the required usleep()).
3:25 a.m.
New subject: 9600 bps
On 11/16/2019 08:45 PM, Mark Pizzolato wrote:
What context are you doing this in?
Experiencing the wonderful world of 9600bps that I had unfortunately
missed out on. It is so beautiful and relaxing. I am sure my BP is
dropping quickly.
Anyone on HECNET running OVMS 7.3 or later can try to wait for the world
to (a) finish spinning and (b) move across the screen while spinning:
$ P9600BPS="$QCOCAL::DUA2:[FAL$SERVER]9600BPS.EXE"
$ PIPE TYPE QCOCAL::GLOBE.VT | P9600BPS
$ PIPE TYPE QCOCAL::MOVGLOBE.VT | P9600BPS
Granted HECnet delays are added to 9600 BPS.
Best,
Supratim
If you are driving this output from a simh simulator,
connections to
the DZ and VH devices already run at the speeds that the speed each
multiplexer line is programmed to run at.? Impatient folks who can?t
stand to wait for output at the ?natural? line speed can configure the
multiplexer to deliver data from 2 to 32 times faster than the
programmed speeds.
Simulator console port speeds can also be set to run a specific
rates.? This is explicitly controlled in the simulator configuration
files since console ports didn?t have programmable port speeds.? SET
CONSOLE SPEED=n generally works.
*From:*owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
*On Behalf Of *Supratim Sanyal
*Sent:* Saturday, November 16, 2019 4:38 PM
*To:* hecnet at Update.UU.SE
*Subject:* Re: [HECnet] 9600 bps
On 11/16/2019 07:33 PM, David Moylan wrote:
?Cheers, Wiz!!
ah! was wondering :)
thanks. basically trying to write a simple program to filter the old
VT100 demo text files to slow them down (calculate the required usleep()).
--
Sent via Thunderbird/MX-Linux on an overheated Compaq Presario CQ61
10:22 a.m.
New subject: 9600 bps
Back in the day, we had classrooms of PT100s (Plessey VT100 clones with amber displays)
connected via statmuxes at 2400 baud to a VAX 780 cluster. The upgrade to Gandalf terminal
switches at 9600 baud came later.
On 17 Nov 2019, at 02:26, Supratim Sanyal <supratim at riseup.net> wrote:
?
On 11/16/2019 08:45 PM, Mark Pizzolato wrote:
What context are you doing this in?
Experiencing the wonderful world of 9600bps that I had unfortunately missed out on. It is
so beautiful and relaxing. I am sure my BP is dropping quickly.
Anyone on HECNET running OVMS 7.3 or later can try to wait for the world to (a) finish
spinning and (b) move across the screen while spinning:
$ P9600BPS="$QCOCAL::DUA2:[FAL$SERVER]9600BPS.EXE"
$ PIPE TYPE QCOCAL::GLOBE.VT | P9600BPS
$ PIPE TYPE QCOCAL::MOVGLOBE.VT | P9600BPS
Granted HECnet delays are added to 9600 BPS.
Best,
Supratim
If you are driving this output from a simh simulator, connections to the DZ and VH devices
already run at the speeds that the speed each multiplexer line is programmed to run at.
Impatient folks who can?t stand to wait for output at the ?natural? line speed can
configure the multiplexer to deliver data from 2 to 32 times faster than the programmed
speeds.
Simulator console port speeds can also be set to run a specific rates. This is explicitly
controlled in the simulator configuration files since console ports didn?t have
programmable port speeds. SET CONSOLE SPEED=n generally works.
From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Supratim Sanyal
Sent: Saturday, November 16, 2019 4:38 PM
To: hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE>
Subject: Re: [HECnet] 9600 bps
On 11/16/2019 07:33 PM, David Moylan wrote:
Cheers, Wiz!!
ah! was wondering :)
thanks. basically trying to write a simple program to filter the old VT100 demo text files
to slow them down (calculate the required usleep()).
--
Sent via Thunderbird/MX-Linux on an overheated Compaq Presario CQ61
12:04 p.m.
New subject: 9600 bps
Assuming that whatever system you are running on can accurately sleep a
millisecond. This is often not true...
Johnny
On 2019-11-17 03:25, Supratim Sanyal wrote:
On 11/16/2019 08:45 PM, Mark Pizzolato wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
What context are you doing this in?
Experiencing the wonderful world of 9600bps that I had unfortunately
missed out on. It is so beautiful and relaxing. I am sure my BP is
dropping quickly.
Anyone on HECNET running OVMS 7.3 or later can try to wait for the world
to (a) finish spinning and (b) move across the screen while spinning:
$ P9600BPS="$QCOCAL::DUA2:[FAL$SERVER]9600BPS.EXE"
$ PIPE TYPE QCOCAL::GLOBE.VT | P9600BPS
$ PIPE TYPE QCOCAL::MOVGLOBE.VT | P9600BPS
Granted HECnet delays are added to 9600 BPS.
Best,
Supratim
If you are driving this output from a simh
simulator, connections to
the DZ and VH devices already run at the speeds that the speed each
multiplexer line is programmed to run at.? Impatient folks who can?t
stand to wait for output at the ?natural? line speed can configure the
multiplexer to deliver data from 2 to 32 times faster than the
programmed speeds.
Simulator console port speeds can also be set to run a specific
rates.? This is explicitly controlled in the simulator configuration
files since console ports didn?t have programmable port speeds.? SET
CONSOLE SPEED=n generally works.
*From:*owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
*On Behalf Of *Supratim Sanyal
*Sent:* Saturday, November 16, 2019 4:38 PM
*To:* hecnet at Update.UU.SE
*Subject:* Re: [HECnet] 9600 bps
On 11/16/2019 07:33 PM, David Moylan wrote:
?Cheers, Wiz!!
ah! was wondering :)
thanks. basically trying to write a simple program to filter the old
VT100 demo text files to slow them down (calculate the required usleep()).
--
Sent via Thunderbird/MX-Linux on an overheated Compaq Presario CQ61
12:01 p.m.
New subject: 9600 bps
On 2019-11-17 01:21, Supratim Sanyal wrote:
A terminal running at 9600 baud, 8N1, would
display/process one
character approximately every millisecond (1066.6666 characters in 1000
milliseconds).
Is this math correct?
No. But not far off.
9600 *bps*, 8N1 means you'll have 10 bits per character.
1 start bit, 8 data bits, 1 stop bit.
At 9600 bps, that would result in 960 characters per second.
(Baud and bps is not the same thing, although they often are equivalent.
But avoid using the term baud, unless you really know what you are
talking about...)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
16 Nov
16 Nov
8:32 p.m.
On 11/16/2019 3:40 AM, Mark Pizzolato wrote:
You are working on a Linux system which has case sensitive file names, so there is a
distinct difference between vmst and VMST. This command is missing the device name TQ as
well...
The simh commands and many of their arguments (ansi-vms and -f) are case insensitive, but
filenames are whatever the host system supports.
In the latest commit, I've enriched the error messages issued when unrecognized
arguments/files are presented to a tape attach.
- Mark
Let me try this. It might be better.
Logging to file "vax_session.log"
Logging to file "vax_session.log" at Sat Nov 16 14:19:19 2019
sim> set cpu 64m
sim> set rq0 ra92
sim> lo -r k
sim> att nvr n
NVR: buffering file in memory
sim> att rq0 vms
RQ0: 'vms' Contains ODS2 File system
RQ0: Volume Name: OVMSVAXSYS Format: DECFILE11B Sectors In Volume: 2940951
sim> att tq -f ansi-vms Hobby-*
Can't open tape image:
sim> q
Goodbye
NVR: writing buffer to file
Log file closed
8:37 p.m.
Bill,
I believe your problem may be a simple typo.
sim> att tq -f ansi-vms Hobby-*
should be
att tq -f ansi-vms Hobbyist-*
Try that.
Ray
On Sat, Nov 16, 2019, 2:32 PM Bill Cunningham <bill.cu at suddenlink.net>
wrote:
On 11/16/2019 3:40 AM, Mark Pizzolato wrote:
You are working on a Linux system which has case sensitive file names,
so there is
a distinct difference between vmst and VMST. This command is
missing the device name TQ as well...
The simh commands and many of their arguments (ansi-vms and -f) are case
insensitive, but filenames are whatever the host system supports.
In the latest commit, I've enriched the error messages issued when
unrecognized arguments/files are presented to a tape attach.
- Mark
Let me try this. It might be better.
Logging to file "vax_session.log"
Logging to file "vax_session.log" at Sat Nov 16 14:19:19 2019
sim> set cpu 64m
sim> set rq0 ra92
sim> lo -r k
sim> att nvr n
NVR: buffering file in memory
sim> att rq0 vms
RQ0: 'vms' Contains ODS2 File system
RQ0: Volume Name: OVMSVAXSYS Format: DECFILE11B Sectors In Volume:
2940951
sim> att tq -f ansi-vms Hobby-*
Can't open tape image:
sim> q
Goodbye
NVR: writing buffer to file
Log file closed
8:48 p.m.
On 11/16/2019 2:37 PM, Ray Jewhurst wrote:
Bill,
I believe your problem may be a simple typo.
sim> att tq -f ansi-vms Hobby-*
should be
att tq -f ansi-vms Hobbyist-*
Try that.
Ray
Ok.
Logging to file "vax"
Logging to file "vax" at Sat Nov 16 14:43:30 2019
sim> set cpu 64m
sim> set rq0 ra92
sim> lo -r k
sim> att nvr n
NVR: buffering file in memory
sim> att rq0 vms
RQ0: 'vms' Contains ODS2 File system
RQ0: Volume Name: OVMSVAXSYS?? Format: DECFILE11B?? Sectors In Volume:
2940951
sim> att tq -f ansi-vms Hobbyist-*
Can't open tape image:
sim> q
Goodbye
NVR: writing buffer to file
Log file closed
Doesn't seem to be.
Bill
8:53 p.m.
Can you please give us an "ls" of your working directory?
On Sat, Nov 16, 2019, 2:48 PM Bill Cunningham <bill.cu at suddenlink.net>
wrote:
On 11/16/2019 2:37 PM, Ray Jewhurst wrote:
Bill,
I believe your problem may be a simple typo.
sim> att tq -f ansi-vms Hobby-*
should be
att tq -f ansi-vms Hobbyist-*
Try that.
Ray
Ok.
Logging to file "vax"
Logging to file "vax" at Sat Nov 16 14:43:30 2019
sim> set cpu 64m
sim> set rq0 ra92
sim> lo -r k
sim> att nvr n
NVR: buffering file in memory
sim> att rq0 vms
RQ0: 'vms' Contains ODS2 File system
RQ0: Volume Name: OVMSVAXSYS Format: DECFILE11B Sectors In Volume:
2940951
sim> att tq -f ansi-vms Hobbyist-*
Can't open tape image:
sim> q
Goodbye
NVR: writing buffer to file
Log file closed
Doesn't seem to be.
Bill
8:54 p.m.
Your Linux working directory that is.
Ray
On Sat, Nov 16, 2019, 2:53 PM Ray Jewhurst <raywjewhurst at gmail.com> wrote:
Can you please give us an "ls" of your
working directory?
On Sat, Nov 16, 2019, 2:48 PM Bill Cunningham <bill.cu at suddenlink.net>
wrote:
>
> On 11/16/2019 2:37 PM, Ray Jewhurst wrote:
>
> Bill,
>
> I believe your problem may be a simple typo.
> sim> att tq -f ansi-vms Hobby-*
> should be
> att tq -f ansi-vms Hobbyist-*
>
> Try that.
>
> Ray
>
> Ok.
>
> Logging to file "vax"
> Logging to file "vax" at Sat Nov 16 14:43:30 2019
> sim> set cpu 64m
> sim> set rq0 ra92
> sim> lo -r k
> sim> att nvr n
> NVR: buffering file in memory
> sim> att rq0 vms
> RQ0: 'vms' Contains ODS2 File system
> RQ0: Volume Name: OVMSVAXSYS Format: DECFILE11B Sectors In Volume:
> 2940951
> sim> att tq -f ansi-vms Hobbyist-*
> Can't open tape image:
> sim> q
> Goodbye
> NVR: writing buffer to file
> Log file closed
>
>
> Doesn't seem to be.
>
> Bill
>
>
>
9:07 p.m.
On 11/16/2019 2:54 PM, Ray Jewhurst wrote:
Your Linux working directory that is.
Ray
Sure.
a.txt??? // this text
bin
boot
dev
etc
f??? // This 'f' is a 512 byte piece of windows 7 ultimate binary code.
Hobbyist-USE-ONLY-VA.TXT
home
k
lib
lib64
mnt
n
ngrub
openvms73.iso
proc
root
run
sbin
simh-master
simh-master.zip
srv
sys
t
tmp
usr
uv5swre.zip
uv6swre.zip
v
var
vax_session.log
vms
w??? // 'w' is a mount to /dev/sda1 which is a windows OS
wgrub
// ngrub and wgrub are 512 MBRs one with grub one without.
Bill
The // are C++ style comments
The only thing I would think could possibly give any trouble could be
that 512 bytes of code called "f". IMO
9:13 p.m.
The first thing I would do is copy everything simh related over to your
home directory. It may not like reading the files from the root directory.
Then when you are in simh do an ls right at the sim> prompt to make sure it
is in the right place. Then try again.
On Sat, Nov 16, 2019, 3:07 PM Bill Cunningham <bill.cu at suddenlink.net>
wrote:
On 11/16/2019 2:54 PM, Ray Jewhurst wrote:
Your Linux working directory that is.
Ray
Sure.
a.txt // this text
bin
boot
dev
etc
f // This 'f' is a 512 byte piece of windows 7 ultimate binary code.
Hobbyist-USE-ONLY-VA.TXT
home
k
lib
lib64
mnt
n
ngrub
openvms73.iso
proc
root
run
sbin
simh-master
simh-master.zip
srv
sys
t
tmp
usr
uv5swre.zip
uv6swre.zip
v
var
vax_session.log
vms
w // 'w' is a mount to /dev/sda1 which is a windows OS
wgrub
// ngrub and wgrub are 512 MBRs one with grub one without.
Bill
The // are C++ style comments
The only thing I would think could possibly give any trouble could be that
512 bytes of code called "f". IMO
1632
days inactive
1634
days old
24 comments
8 participants
participants (8)
-
bill.cu＠suddenlink.net -
bqt＠softjar.se -
djm＠wiz.net.au -
Keith.Halewood＠pitbulluk.org -
Mark＠infocomm.com -
paulkoning＠comcast.net -
raywjewhurst＠gmail.com -
supratim＠riseup.net