17 Nov
2019
17 Nov
'19
12:04 p.m.
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