On 06/04/2014 05:34 PM, John Dohn wrote:
Hi, guys!
Do anyone have archive of conferences mentioned at
http://www.buschdorf.eu/vaxnotes/ ?
I sure hope so. It looks like the suits got to it!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Sunday, May 25, 2014 at 10:14 AM, Johnny Billquist wrote:
On 2014-05-25 19:04, Hans Vlems wrote:
Huh? With ethernet, communication with adjacent nodes works without
involving any routers anyway. And if you need to talk with anything beyond,
you're going to go through the router on the way there anyway.
Really, unless you actually have several interfaces, there is no gain in running
a router compared to an endnode. However, running a router definitely use
up more resources, which is a disadvantage.
Anyway, i'd stop using the same 08-00-2B address on two nodes, shutdown
the simulators the VM host and the real iron.
Would still not make any difference, which I have pointed out several times
now, and also what Jean-Yves have been observing the last two days.
Really. There is no black magic here. I can explain every bit of it if someone
needs more convincing.
Essentially, the MAC address in the actual ethernet controller (or the MAC
address set before boot in simh) is irrelevant. Once DECnet starts running,
that MAC address is not used anymore. It is just a trivia piece of information
so that you can know what the hardware MAC address from the factory is. It
is not used by anything, especially not anything related to network
communication.
The VM host in turn cares even less, since whatever MAC address simh plays
around with is fully local to simh, and does not affect the VM host.
Any questions?
Actually depending on the timing, having multiple nodes on the same LAN with the same hardware MAC address WILL cause an error in a simh configuration.
A little background here is appropriate:
VMS (and presumably other DECnet capable DEC Operating Systems) have logic in the network device driver which attempts to assure that no other node on the LAN has the same MAC address whenever an application or protocol stack attempts to set the Physical Address on the network card. The validation step uses the Loopback protocol to send a packet to (and from) the MAC address which the software is trying to set the Physical Address to and if a response is actually received, the attempt to set the Physical Address is rejected. This is intended to detect duplicate DECnet addresses on a LAN segment.
The process of sending loopback packets like this (and correctly getting answers when the problems they are designed to detect were there) caused some interesting structural design issues in the sim_ether layer way back when the XQ device was first being developed.
As it turns out, the process described above was designed BEFORE learning bridges and other switches which are fundamentally part of networks today were in use. The initial simh Ethernet device implementations reflected the hardware behavior. The hardware behavior first set the Physical MAC address to the new value and then sent the loopback packet, but on switched networks this didn't actually detect the problem it was originally designed to detect. The detection problem is due to the fact that learning bridges AND most switches running some form of spanning tree protocol generally don't forward the first packet they see from a particular address. They may not forward packets from a particular address for a good number of seconds while they potentially learn about changing topologies. The 'right' approach to implement this test would be for the loopback packet to be sent from the current Physical MAC address BEFORE it is changed. This approach works on learning networks (presuming that the current Physical MAC address had already been learned on that LAN due to other traffic).
The current simulated approach to this problem does several things: 1) it detects the send to self loopback attempt and before actually transmitting anything changes the source address of the loopback packet to be the current physical address of the host system's lan interface. 2) it temporarily enables capture of a potential loopback response to the host system's MAC address in the pcap filter in effect. 3) it then sends the packet. If a response is received, it is reformatted to look like what the original hardware response would have been if a duplicate MAC address had been found and then passes that up into the simulated system.
This approach effectively detects duplicate DECnet addresses on today's LANs.
As I mentioned above, the VMS driver actually performs this loopback test ANY time the Physical MAC address is changed, not just by DECnet or cluster software. The original logic in sim_ether only had examples with DECnet addresses so it the tests to detect this presumed DECnet format MAC addresses. Once I realized that a complete solution involved any address, I generalized the check. After I generalized the check, I realized that DECnet Phase V systems don't change their LAN interface MAC addresses. Given the potential of multiple simulated systems existing on the same LAN with potentially conflicting MAC addresses, I leveraged the already existing logic to verify that the Hardware MAC address wasn't already in use on the LAN by executing the above mentioned loopback test when a simh LAN device is attached to a network segment.
So, if you've got 2 simh VAX systems on the same LAN segment and you don't change the MAC address of the LAN interface:
System 1:
sim> show xq
XQ address=20001920-2000192F, no vector, MAC=08:00:2B:AA:BB:CC
type=DELQA-T, mode=DELQA, polling=disabled, sanity=OFF
DEQNALock=OFF, leds=(ON,ON,ON)
not attached
sim> attach xq eth0
WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008)
Eth: opened OS device \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38}
sim>
System 2:
sim> show xq
XQ address=20001920-2000192F, no vector, MAC=08:00:2B:AA:BB:CC
type=DELQA-T, mode=DELQA, polling=disabled, sanity=OFF
DEQNALock=OFF, leds=(ON,ON,ON)
not attached sim> attach xq eth0
WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008)
Eth: opened OS device \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38}
XQ: MAC Address Conflict on LAN for address 08:00:2B:AA:BB:CC, change the MAC address to a unique value
Eth: closed \Device\NPF_{A6F81789-B849-4220-B09B-19760D401A38}
Unit not attachable
sim>
This functionality exists for all LAN devices on the supported simulators (XQ and XU in the Qbus and VAX family simulators) in the latest simh codebase.
Depending on the timing of various actions, the above collision wouldn't be detected if one of the nodes is running a network stack which changes the physical address. It will then be up to the simulated OS to potentially detect address collisions.
- Mark
On Saturday, May 24, 2014 at 3:12 AM, Jean-Yves Bernier wrote:
Node 10.1
Line = QNA-0
Controller = Normal
Counter timer = Off
Protocol = ETHERNET
Hardware address = 08-00-2B-AA-BB-CC
Controller CSR = 174440, Vector = 120
Priority = 5
Node 10.2
Line = QNA-0
Controller = Normal
Counter timer = Off
Protocol = ETHERNET
Hardware address = 08-00-2B-AA-BB-CC
Controller CSR = 174440, Vector = 120
Priority = 5
Shouldn't be AA-00-04-00-01-28 and AA-00-04-00-02-28 ?
Both nodes under simh.
The network is working, however.
Is it required to SET XQ MAC to match node address?
Without regard to how you happen to use a particular simulated Ethernet device, you should choose a unique hardware MAC address for that card. This would reflect how hardware manufacturers assign unique, but persistent, MAC addresses to each network device that they manufacture. Simh can't know if you've done this, and since you haven't explicitly changed the MAC address both of these simulated devices have the same hardware MAC address.
As it turns out, since you're using these Ethernet devices for DECnet hosts, due to how Phase IV DECnet was designed, the operating system changes the running MAC address to reflect the current DECnet address (or SCSSYSTEMID) that the system is running with. Since you've got more than one simulator running on your LAN, you should set the MAC addresses uniquely in the simulator configuration files before you attempt to attach the Ethernet device to a network. If you don't, there are timing situations which will cause the second simulators attach attempt to fail since it might detect that there is a MAC address conflict. This could happen if both simulators are connected to the LAN but haven't yet gotten far enough along in the VMS boot for the operating system to uniquely set the MAC addresses.
- Mark
- Mark
On Monday, May 26, 2014 at 7:09 AM, Jean-Yves Bernier wrote:
[ Summary : File transfers between two simh PDP hang, DECnet reports Data
overruns and Response timeouts ]
At 2:14 AM +0200 26/5/14, Johnny Billquist wrote:
This is a problem inside of DECnet on the simulated host. It gets
packets faster than it can process them, so some packets are dropped.
Unfortunately DECnet deals very bad with systematic packet loss like this.
You get retransmissions, and after a while the retransmission
timeout backs off until you have more than a minute between
retransmission attempts.
Anyway, if you can get simh to throttle the ethernet interface, that
might help you.
(I don't remember offhand if it do support such functionality.)
The service polling timer can be adjusted
SET XQ POLL={DEFAULT|4..2500}
Set to 100 by default.
Changing the polling timer makes a huge difference. Have a look at:
http://pastebin.com/AZ1U6bh3
Although it still hangs sometimes, reliability has vastly improved upon the
erratic behavior of the beginning. Remember, the completion time was
about 3 minutes.
We're almost there :)
This turns into an interesting challenge : optimize XQ service timer to make
overruns the lowest possible. This depends on many factors, among them is
the data sink bandwidth.
You may have flawless copy to TI:, but it will fail to disk. The terminal is
actually throttling the transfer. Disks are faster, and emulated disks are order
of magnitude faster than the original ones.
Emulation is pushing DECnet to speeds it was never designed for.
I'm running here as low as 10 polls/sec. Maybe 50 would be optimal, and
what about 500? I need a metrics. And tools. Here, I am using AT.
to time a 100. blocks file transfer. Overruns and timeouts still raise slowly, but
DECnet recovers happily most of the time.
If you're going to drive this deeply into testing it would really be best if you ran with the latest code since your results may ultimately suggest code changes, AND the latest code may behave significantly different than the older versions.
Independent of which codebase you're running, and since you're now tweaking the behavior of the simulated hardware, you may want to look at sim> SHOW XQ STATS and try to analyze the relationship between these stats and the ones the OS sees.
Also, you may want to explore what happens if:
NCP> DEFINE LINE QNA-0 RECEIVE BUFFER 32
Is done prior to starting your network... The limit of 32 may be different on different Operating Systems...
Once again the latest code is available from: https://github.com/simh/simh/archive/master.zip
Good Luck,
- Mark
On Tue, Jun 03, 2014 at 07:47:56PM +0000, Paul_Koning at Dell.com wrote:
It s worth doing the experiment to see whether (and
when) this is a problem in practice. Flash storage
devices like SD cards do wear leveling , and if that s
Do they? It took a while for the SSD industry to get it
right and I don't expect that the tech has trickled down
to SD cards yet. At least not on the cheap end. I'd like
to be proven wron though.
/P
I've put a couple of test SIXELs (I _THINK_ they're sixels, they display fine in DTTERM) in CHIMPY::[.SIXELS] in case your friend wants something to test.
I created them by converting a PNG to PBM using ImageMagick and then pbmtoln03 to go from PBM -> SIXEL.
Sampsa
On 1 Jun 2014, at 14:46, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-31 11:31, Sampsa Laine wrote:
Anybody know of a terminal program that'll do Sixels?
A friend of mine have added it to xterm. He's also working on ReGIS. I don't know if he's release it yet, but you could search around...
Johnny
Sampsa
On 31 May 2014, at 11:50, Cory Smelosky <b4 at gewt.net> wrote:
On Sat, 31 May 2014, Erik Olofsen wrote:
At RULLFS::[.SEM] I typed in some of the code; sem3 doesn't work yet,
but sem2 does and is available at the task server.
Instead of using the graphics library the output is done in... sixels.
An example can be viewed with the sem button at
Looks like I need to fix up that VT340. ;)
http://rullf2.xs4all.nl/sg/sg.html
Erik
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
--
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
On Wed, Jun 4, 2014 at 8:05 AM, Peter Lothberg <roll at stupi.se> wrote:
> My tunnels to you have been administratively shutdown as they have never
> been up before.
Why are there tunnels that are shutdown?
I shut them down as the tunnels were configured, but your end never came up. It has been mentioned a few times on the list, but nothing seemed to change. So, rather than put the configuration in a note somewhere (and lose it) I just shut them down.
(I can't grasp the concept, it's either up and working, or not at all?)
> shutdown". Here is the configuration in my router for the tunnels to you:
When I do something like "show decnet interfaces" those tunnels that are not working show up as 2 lines, rather than several. There are other reasons too, but this is what works for me :-)
> tunnel source FastEthernet0/0
You can put an IP address here, the same way as destination, and I
could check if I had teh corresponding tunnel.
I don't use the IP as my Cisco 1841 (previously a DECbrouter90) is behind a Cisco 800. However, my static IP is: 120.146.225.243.
> tunnel path-mtu-discovery
This does *NOT* work on the boxes I have, they are to small to run the
newer SW. (This is a no_op anyway, as there is no fragmentation code,
if the path_mtu is smaller than 576+gre+ip, packet is lost...)
I had the same issue when I was originally running my DECbrouter90 (before the power supply gave up). I have switched this option off.
Regards, Tim.
My tunnels to you have been administratively shutdown as they have never
been up before.
Why are there tunnels that are shutdown?
(I can't grasp the concept, it's either up and working, or not at all?)
shutdown". Here is the configuration in my router for the tunnels to you:
tunnel source FastEthernet0/0
You can put an IP address here, the same way as destination, and I
could check if I had teh corresponding tunnel.
tunnel path-mtu-discovery
This does *NOT* work on the boxes I have, they are to small to run the
newer SW. (This is a no_op anyway, as there is no fragmentation code,
if the path_mtu is smaller than 576+gre+ip, packet is lost...)
--P
On Wed, Jun 4, 2014 at 6:50 AM, Peter Lothberg <roll at stupi.se> wrote:
Out of the configured tunnels from the Cisco in Uppsala, there is only one
active tunnel not to area59....
interface Tunnel1099
description tunnel to Mark G Thomas <mark at misty.com> (Area 23)
no ip address
logging event subif-link-status
decnet cost 10
tunnel source Ethernet0
tunnel destination 71.246.8.102
is it safe to remove the rest, assuming they are "historical"?
Hi Peter,
The other tunnels are all up:
a12rtr>show decnet neigh
Net Node Interface MAC address Flags
0 9.1023 Tunnel52 0000.0000.0000 A
0 23.1023 Tunnel59 0000.0000.0000 A
0 42.1022 Tunnel51 0000.0000.0000 A
0 52.1023 Tunnel50 0000.0000.0000 A
0 61.1023 Tunnel53 0000.0000.0000 A
0 12.2 FastEthernet0/0 aa00.0400.0230
0 12.3 FastEthernet0/0 aa00.0400.0330
My tunnels to you have been administratively shutdown as they have never been up before. The tunnel to Mark Darvill does not appear to be working correctly at the moment, he likely sorting out his network or configuration.
For interests sake I have just set all the tunnel interfaces to you to "no shutdown". Here is the configuration in my router for the tunnels to you:
interface Tunnel54
description HECnet tunnel for Peter Lothberg Reston VA (Area 59) [Version:218]
no ip address
decnet cost 20
tunnel source FastEthernet0/0
tunnel destination 199.0.131.2
tunnel path-mtu-discovery
!
interface Tunnel55
description HECnet tunnel for Peter Lothberg Stockholm Sweden (Area 59) [Version:218]
no ip address
decnet cost 20
tunnel source FastEthernet0/0
tunnel destination 192.108.200.213
tunnel path-mtu-discovery
!
interface Tunnel56
description HECnet tunnel for Peter Lothberg Uppsala (Area 59) [Version:218]
no ip address
decnet cost 20
tunnel source FastEthernet0/0
tunnel destination 130.238.19.60
tunnel path-mtu-discovery
!
Regards, Tim.
Out of the configured tunnels from the Cisco in Uppsala, there is only one
active tunnel not to area59....
interface Tunnel1099
description tunnel to Mark G Thomas <mark at misty.com> (Area 23)
no ip address
logging event subif-link-status
decnet cost 10
tunnel source Ethernet0
tunnel destination 71.246.8.102
is it safe to remove the rest, assuming they are "historical"?
-P
On 4 Jun 2014, at 00:58, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
My personal experience with the RaspPi and the SD cards is the card slot in the Pi brokes with ease, so I avoid switching the cards as much as posible. Any minimal lost of contact between the card and the slot leads to a corrupted and (usually) unrecoverable filesystem, so my VAXen are in a real HD, and my cards are really microSDs inserted into an adapter, which is inserted into the Pi and is never moved out.
Hmm, never actually changed the SD card in my Pi, it's sort of a fire-and-forget device for me, seems very reliable though (uptime = 334 days, and the last reboot was due to a power outage) - aside from the physical problems you pointed out..
El 03/06/2014, a les 23.30, Sampsa Laine <sampsa at mac.com> va escriure:
I can second that, HPIVAX has been up for like 18 months, no problems whatsoever.
Sampsa
My personal experience with the RaspPi and the SD cards is the card slot in the Pi brokes with ease, so I avoid switching the cards as much as posible. Any minimal lost of contact between the card and the slot leads to a corrupted and (usually) unrecoverable filesystem, so my VAXen are in a real HD, and my cards are really microSDs inserted into an adapter, which is inserted into the Pi and is never moved out.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
On 3 Jun 2014, at 22:54, Vern Brownell <vern at brownell.com> wrote:
Hi Fred,
I ve been running SIMH with OpenVMS 7.3 on a Pi for over a year now and it has been rock solid. Just checked with SH SYS, it s been up for 224 days straight with a fair amount of daily activity and no noticeable degradation in performance. Runs more reliably than my AXP hardware. FWIW YMMV.
And 8GB SD cards are now about $5 on AMZN.
Best of luck,
I can second that, HPIVAX has been up for like 18 months, no problems whatsoever.
Sampsa
El 03/06/2014, a les 21.38, Fred <fcoffey at misernet.net> va escriure:
For those of you who are running SIMH on Raspberry Pi, how are you getting around the fact that lots of writes on your SD card will eventually trash it? I am considering moving my VAX instance to my Raspi, but didn't want to eat an SD card ... ;)
Is it as simple as perhaps mounting the VAX .dsk via NFS and letting SIMH use that, instead of the card?
I'm using an USB disk for the emulators (actually, all my rootfs is in that disk). On my "testing" raspi I mount an NFS partition, just as you said.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
Hi Fred,
I ve been running SIMH with OpenVMS 7.3 on a Pi for over a year now and it has been rock solid. Just checked with SH SYS, it s been up for 224 days straight with a fair amount of daily activity and no noticeable degradation in performance. Runs more reliably than my AXP hardware. FWIW YMMV.
And 8GB SD cards are now about $5 on AMZN.
Best of luck,
Vern
On Jun 3, 2014, at 12:38 PM, Fred <fcoffey at misernet.net> wrote:
Hi all,
For those of you who are running SIMH on Raspberry Pi, how are you getting around the fact that lots of writes on your SD card will eventually trash it? I am considering moving my VAX instance to my Raspi, but didn't want to eat an SD card ... ;)
Is it as simple as perhaps mounting the VAX .dsk via NFS and letting SIMH use that, instead of the card?
Thanks,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
On Jun 3, 2014, at 3:38 PM, Fred <fcoffey at misernet.net> wrote:
Hi all,
For those of you who are running SIMH on Raspberry Pi, how are you getting around the fact that lots of writes on your SD card will eventually trash it? I am considering moving my VAX instance to my Raspi, but didn't want to eat an SD card ... ;)
It s worth doing the experiment to see whether (and when) this is a problem in practice. Flash storage devices like SD cards do wear leveling , and if that s implemented reasonably well, you can get a lot of life out of a card. The other consideration is that they only cost a couple of dollars, so why worry about it (given adequate backup)?
paul
Hi all,
For those of you who are running SIMH on Raspberry Pi, how are you getting around the fact that lots of writes on your SD card will eventually trash it? I am considering moving my VAX instance to my Raspi, but didn't want to eat an SD card ... ;)
Is it as simple as perhaps mounting the VAX .dsk via NFS and letting SIMH use that, instead of the card?
Thanks,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
>John Wilson wrote:
V7.1 of Ersatz-11 is done. New features include:
- DMP11/DMV11 network ports.
- DDCMP over TCP and UDP (as well as serial lines).
- Kermit client for transferring files in and out of the PDP-11 over any
emulated serial line (KERMIT command and KERMIT: pseudo-driver).
- "MOUNT ddcu: BAD: /LIST:badblks.txt ..." adds fake bad blocks (from a
list in a file) to any disk (for testing PDP-11 utilities).
- "MOUNT ddcu: ... {/NOPAD | /PAD:NULL | /PAD:RAM}" selects how to handle
emulating disks with an image file (or physical drive) that's smaller
than the drive being emulated. (/PAD:RAM is currently an experimental
feature and may have bugs -- it's intended for systems that use the tail
end of the drive as swap space.)
- DPDISK: and DPTAPE: (BOTH UNSUPPORTED) set up dual-ported disks and tapes.
Any disk or tape type can be mounted on one of these pseudo-devices, after
which units 0 and 1 of the pseudo-device represent the two ports which may
in turn each be mounted on different PDP-11 controllers, presumably on
different processors of a multi-processor system.
- "SET TTu: DL11A" (needed by DOS/BATCH for TT0:).
Impressive list of new features!! As usual, congratulations for a
job well done.
- "SET PCLOG n" enlarges the number of logged PC values that can be shown
with SHOW PCLOG.
This will be the big one for me as I want to be able to check it against
a similar (NEWLY added) feature in SDHX.SYS for RT-11. Of course,
your PCLOG adds only about 8% to 10% additional time. In SD:,
my initial benchmark suggests at least a HUNDRED times longer.
In addition, for SDHX.SYS, the current size of the PC Address
circular buffer is only 3000 PC Addresses which, although much
larger than the original 64, can't compete against a VERY large "n".
- New native "SYS" utilities for Linux, OS/2, and Windows, for making disks
(or flash drives) boot the stand-alone version of E11. The Linux and
Windows versions try to notice if a drive (e.g. USB flash card that came
pre-partitioned) hasn't been made "active" and/or is missing the MBR
bootstrap, and fixes it (may require privs). If anyone can please tell
me what sys calls in OS/2 will find out which physical drive owns a FAT
volume given the drive letter, I'd appreciate it!
- The stand-alone version's bootstrap supports USB drives (including flash).
Also there's a bootable CD, but since there's currently no ATAPI dev
driver or ISO9660 FS driver, it can't install E11 onto a hard drive, and
it requires a FAT volume to hold .DSK files etc. So it's more of a proof
of concept than something useful (but it's an easy way to try out the
stand-alone version of E11).
Bug fixes and tweaks as usual (sorry about that .TAP seeking thing in V7.0!).
As usual, the Demo version can be downloaded from:
http://www.dbit.com/demo.html
Jerome Fine
Hello!
In fact Brian, much as I find this discussion both amusing and
informative, he's right. I have practically all the versions here that
he's written. Exceptions are this version, soon to resolved, and the
one before it. I think I have the 0.8 one and the 0.9 and the 1s also
the 2s. '
But as I said, I've got most of them.
Great stuff there John, I'll do that one RSN.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Mon, Jun 2, 2014 at 8:40 PM, John Wilson <wilson at dbit.com> wrote:
From: Brian Hechinger <wonko at 4amlunch.net>
I'll never forget you (John) telling me about E11 in your kitchen all those
years ago.
Some things never change ... in fact as far as I can tell *nothing* ever
changes. I've been writing the same program for over 20 years and I still
haven't cleaned up that kitchen (or sold the ramshackle hovel it's in,
since I haven't lived there in ages). I hope things are good with you!
John
From: Brian Hechinger <wonko at 4amlunch.net>
I'll never forget you (John) telling me about E11 in your kitchen all those
years ago.
Some things never change ... in fact as far as I can tell *nothing* ever
changes. I've been writing the same program for over 20 years and I still
haven't cleaned up that kitchen (or sold the ramshackle hovel it's in,
since I haven't lived there in ages). I hope things are good with you!
John
That is one hell of a list of features. Especially for a point release!
I'll never forget you (John) telling me about E11 in your kitchen all those years ago. You continually impress me with this thing. :)
-brian
On Jun 2, 2014, at 19:19, Dave McGuire <mcguire at neurotica.com> wrote:
SuhWEET!!
On 06/02/2014 07:16 PM, John Wilson wrote:
V7.1 of Ersatz-11 is done. New features include:
- DMP11/DMV11 network ports.
- DDCMP over TCP and UDP (as well as serial lines).
- Kermit client for transferring files in and out of the PDP-11 over any
emulated serial line (KERMIT command and KERMIT: pseudo-driver).
- "MOUNT ddcu: BAD: /LIST:badblks.txt ..." adds fake bad blocks (from a
list in a file) to any disk (for testing PDP-11 utilities).
- "MOUNT ddcu: ... {/NOPAD | /PAD:NULL | /PAD:RAM}" selects how to handle
emulating disks with an image file (or physical drive) that's smaller
than the drive being emulated. (/PAD:RAM is currently an experimental
feature and may have bugs -- it's intended for systems that use the tail
end of the drive as swap space.)
- DPDISK: and DPTAPE: (BOTH UNSUPPORTED) set up dual-ported disks and tapes.
Any disk or tape type can be mounted on one of these pseudo-devices, after
which units 0 and 1 of the pseudo-device represent the two ports which may
in turn each be mounted on different PDP-11 controllers, presumably on
different processors of a multi-processor system.
- "SET TTu: DL11A" (needed by DOS/BATCH for TT0:).
- "SET PCLOG n" enlarges the number of logged PC values that can be shown
with SHOW PCLOG.
- New native "SYS" utilities for Linux, OS/2, and Windows, for making disks
(or flash drives) boot the stand-alone version of E11. The Linux and
Windows versions try to notice if a drive (e.g. USB flash card that came
pre-partitioned) hasn't been made "active" and/or is missing the MBR
bootstrap, and fixes it (may require privs). If anyone can please tell
me what sys calls in OS/2 will find out which physical drive owns a FAT
volume given the drive letter, I'd appreciate it!
- The stand-alone version's bootstrap supports USB drives (including flash).
Also there's a bootable CD, but since there's currently no ATAPI dev
driver or ISO9660 FS driver, it can't install E11 onto a hard drive, and
it requires a FAT volume to hold .DSK files etc. So it's more of a proof
of concept than something useful (but it's an easy way to try out the
stand-alone version of E11).
Bug fixes and tweaks as usual (sorry about that .TAP seeking thing in V7.0!).
As usual, the Demo version can be downloaded from:
http://www.dbit.com/demo.html
John Wilson
D Bit
--
Dave McGuire, AK4HZ
New Kensington, PA
SuhWEET!!
On 06/02/2014 07:16 PM, John Wilson wrote:
V7.1 of Ersatz-11 is done. New features include:
- DMP11/DMV11 network ports.
- DDCMP over TCP and UDP (as well as serial lines).
- Kermit client for transferring files in and out of the PDP-11 over any
emulated serial line (KERMIT command and KERMIT: pseudo-driver).
- "MOUNT ddcu: BAD: /LIST:badblks.txt ..." adds fake bad blocks (from a
list in a file) to any disk (for testing PDP-11 utilities).
- "MOUNT ddcu: ... {/NOPAD | /PAD:NULL | /PAD:RAM}" selects how to handle
emulating disks with an image file (or physical drive) that's smaller
than the drive being emulated. (/PAD:RAM is currently an experimental
feature and may have bugs -- it's intended for systems that use the tail
end of the drive as swap space.)
- DPDISK: and DPTAPE: (BOTH UNSUPPORTED) set up dual-ported disks and tapes.
Any disk or tape type can be mounted on one of these pseudo-devices, after
which units 0 and 1 of the pseudo-device represent the two ports which may
in turn each be mounted on different PDP-11 controllers, presumably on
different processors of a multi-processor system.
- "SET TTu: DL11A" (needed by DOS/BATCH for TT0:).
- "SET PCLOG n" enlarges the number of logged PC values that can be shown
with SHOW PCLOG.
- New native "SYS" utilities for Linux, OS/2, and Windows, for making disks
(or flash drives) boot the stand-alone version of E11. The Linux and
Windows versions try to notice if a drive (e.g. USB flash card that came
pre-partitioned) hasn't been made "active" and/or is missing the MBR
bootstrap, and fixes it (may require privs). If anyone can please tell
me what sys calls in OS/2 will find out which physical drive owns a FAT
volume given the drive letter, I'd appreciate it!
- The stand-alone version's bootstrap supports USB drives (including flash).
Also there's a bootable CD, but since there's currently no ATAPI dev
driver or ISO9660 FS driver, it can't install E11 onto a hard drive, and
it requires a FAT volume to hold .DSK files etc. So it's more of a proof
of concept than something useful (but it's an easy way to try out the
stand-alone version of E11).
Bug fixes and tweaks as usual (sorry about that .TAP seeking thing in V7.0!).
As usual, the Demo version can be downloaded from:
http://www.dbit.com/demo.html
John Wilson
D Bit
--
Dave McGuire, AK4HZ
New Kensington, PA
V7.1 of Ersatz-11 is done. New features include:
- DMP11/DMV11 network ports.
- DDCMP over TCP and UDP (as well as serial lines).
- Kermit client for transferring files in and out of the PDP-11 over any
emulated serial line (KERMIT command and KERMIT: pseudo-driver).
- "MOUNT ddcu: BAD: /LIST:badblks.txt ..." adds fake bad blocks (from a
list in a file) to any disk (for testing PDP-11 utilities).
- "MOUNT ddcu: ... {/NOPAD | /PAD:NULL | /PAD:RAM}" selects how to handle
emulating disks with an image file (or physical drive) that's smaller
than the drive being emulated. (/PAD:RAM is currently an experimental
feature and may have bugs -- it's intended for systems that use the tail
end of the drive as swap space.)
- DPDISK: and DPTAPE: (BOTH UNSUPPORTED) set up dual-ported disks and tapes.
Any disk or tape type can be mounted on one of these pseudo-devices, after
which units 0 and 1 of the pseudo-device represent the two ports which may
in turn each be mounted on different PDP-11 controllers, presumably on
different processors of a multi-processor system.
- "SET TTu: DL11A" (needed by DOS/BATCH for TT0:).
- "SET PCLOG n" enlarges the number of logged PC values that can be shown
with SHOW PCLOG.
- New native "SYS" utilities for Linux, OS/2, and Windows, for making disks
(or flash drives) boot the stand-alone version of E11. The Linux and
Windows versions try to notice if a drive (e.g. USB flash card that came
pre-partitioned) hasn't been made "active" and/or is missing the MBR
bootstrap, and fixes it (may require privs). If anyone can please tell
me what sys calls in OS/2 will find out which physical drive owns a FAT
volume given the drive letter, I'd appreciate it!
- The stand-alone version's bootstrap supports USB drives (including flash).
Also there's a bootable CD, but since there's currently no ATAPI dev
driver or ISO9660 FS driver, it can't install E11 onto a hard drive, and
it requires a FAT volume to hold .DSK files etc. So it's more of a proof
of concept than something useful (but it's an easy way to try out the
stand-alone version of E11).
Bug fixes and tweaks as usual (sorry about that .TAP seeking thing in V7.0!).
As usual, the Demo version can be downloaded from:
http://www.dbit.com/demo.html
John Wilson
D Bit
Kudos to your friend!
Erik
On Sun, Jun 01, 2014 at 01:46:20PM +0200, Johnny Billquist wrote:
On 2014-05-31 11:31, Sampsa Laine wrote:
Anybody know of a terminal program that'll do Sixels?
A friend of mine have added it to xterm. He's also working on ReGIS.
I don't know if he's release it yet, but you could search around...
Johnny
Sampsa
On 31 May 2014, at 11:50, Cory Smelosky <b4 at gewt.net> wrote:
On Sat, 31 May 2014, Erik Olofsen wrote:
At RULLFS::[.SEM] I typed in some of the code; sem3 doesn't work yet,
but sem2 does and is available at the task server.
Instead of using the graphics library the output is done in... sixels.
An example can be viewed with the sem button at
Looks like I need to fix up that VT340. ;)
http://rullf2.xs4all.nl/sg/sg.html
Erik
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
--
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
