Look at project's page at www.es40.org.
Sadly they stopped working on it before finishing.
Sent from my iPhone
On Feb 16, 2013, at 10:47 AM, "Gregg Levine" <gregg.drwho8 at gmail.com> wrote:
On Sat, Feb 16, 2013 at 10:43 AM, Michael Holmes <mholmes10 at hotmail.com> wrote:
Anyone know of a good Alpha emulator that runs on OS X?
I had Personal Alpha on my WinXP laptop, but haven't touched it since I got my MacBookPro couple years ago.
Would like to run something like person alpha on OSX, cuz running it on WinXP under VM Fusion on OSX is kinda slow (and decnet doesn't seem to be able to talk the real boxes due to all the virtual networking).
I found articles about ES40 project for OSX, but looks like it ran out of steam.
Any suggestions?
Mike
Sent from my iPhone
Hello!
An ES40 project for OS/X? Where? And just for OS/X?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Sat, Feb 16, 2013 at 10:43 AM, Michael Holmes <mholmes10 at hotmail.com> wrote:
Anyone know of a good Alpha emulator that runs on OS X?
I had Personal Alpha on my WinXP laptop, but haven't touched it since I got my MacBookPro couple years ago.
Would like to run something like person alpha on OSX, cuz running it on WinXP under VM Fusion on OSX is kinda slow (and decnet doesn't seem to be able to talk the real boxes due to all the virtual networking).
I found articles about ES40 project for OSX, but looks like it ran out of steam.
Any suggestions?
Mike
Sent from my iPhone
Hello!
An ES40 project for OS/X? Where? And just for OS/X?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
Anyone know of a good Alpha emulator that runs on OS X?
I had Personal Alpha on my WinXP laptop, but haven't touched it since I got my MacBookPro couple years ago.
Would like to run something like person alpha on OSX, cuz running it on WinXP under VM Fusion on OSX is kinda slow (and decnet doesn't seem to be able to talk the real boxes due to all the virtual networking).
I found articles about ES40 project for OSX, but looks like it ran out of steam.
Any suggestions?
Mike
Sent from my iPhone
Apparently something was wrong with the configuration file for cde.
So I did a find / -name Xconfig
and that pointed me to /usr/dt/config/Xconfig, which in turn is a link to
/usr/var/dt/Xconfig.
The file contents told me not to modify that file, which probably happened.
So I copied it to /etc/dt/config, rebooted and all was well.
Why it went worng in the first place, no idea at all...
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Kari Uusim ki
Verzonden: vrijdag, februari 2013 7:15
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
Quite right, Hans. Finland is at UTC+2.
On 15.2.2013 0:15, hvlems at zonnet.nl wrote:
Same for me Kari, on both topics!
You're one hour ahead, right?
We're at UTC+1.
Hans
------Origineel bericht------
Van: Kari Uusim ki
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
Verzonden: 14 februari 2013 23:03
Well, have to test myself. It's so long a time since I've been working
with Tru64 that I've forgotten many details. It's late now so I have to
test tomorrow.
Kari
On 14.2.2013 23:58, H Vlems wrote:
The session options give me Failsafe and another one (name forgotten),
but that last one was selected.
I end up in a single xterm window whether logged on as root or as hans,
makes no difference.
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Kari Uusim ki
Verzonden: donderdag, februari 2013 22:54
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
There is probably the last used desktop selection "xterm".
Try to select from the session options the CDE desktop before you log in.
Kari
On 14.2.2013 19:27, H Vlems wrote:
Logging in on the console of a Tru64 V5.0 machine
I ended up in an xterm terminal and nothing else.
The usual "new DECwindows" desktop was gone.
Any ideas where to look for a fix?
The system is an AlphaServer 800 that had been power
off for a year now.
Hans
.
.
On 2013-02-16 03:03, Paul_Koning at Dell.com wrote:
The thing to do would be to see what happens if you load some multicast address (such as broadcast) into slot 0 of the 16-entry address match table, and the station address into slot 1. For a QNA, that's perfectly fine because all slots are equivalent and the device doesn't do any MOP. It may be that this was a later restriction that RSTS didn't obey. Or it may be a bad assumption in the real LQA that wasn't documented -- or maybe it's just a bad assumption in the SIMH emulation. I haven't yet looked for LQA manuals to give more clues.
Ah. I thought you had already checked documentation.
Well, I did now, and simh is right. Page 3-31 of the DELQA manual states that the first address is used as the source address for system ID messages.
So I guess RSTS/E just sets it up wrong.
Johnny
paul
On Feb 15, 2013, at 8:53 PM, Johnny Billquist wrote:
On 2013-01-24 20:29, Paul_Koning at Dell.com wrote:
I was watching the MOP Console system ID messages from DECnet/E on simh, with an emulated LQA. Noticed something odd: the source address was broadcast. That's not valid, of course. The question is why that happened.
The answer is that the emulation uses the address in slot 0 of the address filter as the source address. The hardware doesn't care what order the addresses go in as far as filtering is concerned; DECnet/E puts broadcast in slot 0 and the physical address in slot 1, followed by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an interesting DECnet/E bug if so... Or does a real LQA just use the physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I did mark this for some later investigation. However, I now realize that it's not trivial for me to test, as it would appear a RSTS/E system would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more, since he have been digging into these kind of questions way more than most people I know...
Or else if you have some realistic suggestion on how I would test this on my machine, as I do have a 11/93 with a real LQA here (although an LQA plus).
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
--
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
The thing to do would be to see what happens if you load some multicast address (such as broadcast) into slot 0 of the 16-entry address match table, and the station address into slot 1. For a QNA, that's perfectly fine because all slots are equivalent and the device doesn't do any MOP. It may be that this was a later restriction that RSTS didn't obey. Or it may be a bad assumption in the real LQA that wasn't documented -- or maybe it's just a bad assumption in the SIMH emulation. I haven't yet looked for LQA manuals to give more clues.
paul
On Feb 15, 2013, at 8:53 PM, Johnny Billquist wrote:
On 2013-01-24 20:29, Paul_Koning at Dell.com wrote:
I was watching the MOP Console system ID messages from DECnet/E on simh, with an emulated LQA. Noticed something odd: the source address was broadcast. That's not valid, of course. The question is why that happened.
The answer is that the emulation uses the address in slot 0 of the address filter as the source address. The hardware doesn't care what order the addresses go in as far as filtering is concerned; DECnet/E puts broadcast in slot 0 and the physical address in slot 1, followed by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an interesting DECnet/E bug if so... Or does a real LQA just use the physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I did mark this for some later investigation. However, I now realize that it's not trivial for me to test, as it would appear a RSTS/E system would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more, since he have been digging into these kind of questions way more than most people I know...
Or else if you have some realistic suggestion on how I would test this on my machine, as I do have a 11/93 with a real LQA here (although an LQA plus).
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
On 2013-01-24 20:29, Paul_Koning at Dell.com wrote:
I was watching the MOP Console system ID messages from DECnet/E on simh, with an emulated LQA. Noticed something odd: the source address was broadcast. That's not valid, of course. The question is why that happened.
The answer is that the emulation uses the address in slot 0 of the address filter as the source address. The hardware doesn't care what order the addresses go in as far as filtering is concerned; DECnet/E puts broadcast in slot 0 and the physical address in slot 1, followed by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an interesting DECnet/E bug if so... Or does a real LQA just use the physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I did mark this for some later investigation. However, I now realize that it's not trivial for me to test, as it would appear a RSTS/E system would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more, since he have been digging into these kind of questions way more than most people I know...
Or else if you have some realistic suggestion on how I would test this on my machine, as I do have a 11/93 with a real LQA here (although an LQA plus).
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
On 2013-02-16 02:15, John Wilson wrote:
From: Johnny Billquist <bqt at softjar.se>
But is there any sane reason
why Linux would SYN-ACK twice, and the second one more than a second
after the first.
Completely stupid theory: last time I did any testing with Linux, it seemed
that it would *always* lose the very first packet sent to a given local
IP address, because it would send an ARP request instead and then forget
why it asked (i.e. drop the outgoing frame since it depended, IMHO wrongly,
on the higher-level protocol to time out and resend). Maybe they fixed
that bug twice? I.e. did a workaround to send the SYN+ACK twice, and then
later did the *real* bug fix to maintain a queue of packets waiting for an
ARP reply, so now you get two? Seems silly but this would be the result.
Ha! Thanks for reminding me about that one. Many Unix systems have a variant of that bug. Many will only keep one packet around when they need to do an ARP request, so if you for example do a ping with a large packet size (that gets fragmented), the first packet always fail if there isn't an entry in the arp cache. (Only one fragment makes it across.)
(Of course my TCP/IP for RSX tries do to better than that... :-) )
But yeah, you could be right on that one. Ugly as hell if you are right, but I cannot rule it out. But it would be nice if someone had something more substantial than guesses as well. Anyone?
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
To continue my night ramblings about TCP/IP, I think I now have all aspect of my rewritten TCP/IP for RSX working right.
And to give you something of a live example from a real PDP-11/93, here is a tcpdump of a short session, which also gives you a little idea of response times for real hardware.
iMac is a pretty quick Mac. Pondus is my home 11/93. DELQA-YM, and also a VSV-21 which keeps the bus a little busy, but otherwise a farily idle machine when the test was run.
02:08:51.963513 IP iMac.61712 > Pondus.http: Flags [S], seq 1430632358, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 2339561691 ecr 0,sackOK,eol], length 0
02:08:52.041339 IP Pondus.http > iMac.61712: Flags [S.], seq 3396663417, ack 1430632359, win 5840, options [mss 1460], length 0
02:08:52.041397 IP iMac.61712 > Pondus.http: Flags [.], ack 1, win 65535, length 0
02:09:14.525188 IP iMac.61712 > Pondus.http: Flags [P.], seq 1:17, ack 1, win 65535, length 16
02:09:14.729046 IP Pondus.http > iMac.61712: Flags [.], ack 17, win 5840, length 0
02:09:14.964597 IP iMac.61712 > Pondus.http: Flags [P.], seq 17:19, ack 1, win 65535, length 2
02:09:15.169279 IP Pondus.http > iMac.61712: Flags [.], ack 19, win 5840, length 0
02:09:16.372880 IP Pondus.http > iMac.61712: Flags [F.], seq 1:1272, ack 19, win 5840, length 1271
02:09:16.372949 IP iMac.61712 > Pondus.http: Flags [.], ack 1273, win 65535, length 0
02:09:16.373569 IP iMac.61712 > Pondus.http: Flags [F.], seq 19, ack 1273, win 65535, length 0
02:09:16.389006 IP Pondus.http > iMac.61712: Flags [.], ack 20, win 5840, length 0
So, for the initial SYN-ACK response to the SYN is about 8/100s, which I think is pretty ok (that would include the startup of the web server task). It takes a little time to serve the data requested in the HTTP session. Not surprising since the web server needs to be started, it needs to read in the request from the net, parse it, log it to a couple of different logs, access the mapping between URL and filenames, access the mime content mapping, read the requested file, and send the stuff back over the network.
(And I typed in the http request by hand.)
All in all, the session took 25 seconds.
Time to maybe twiddle some HLL libraries a little more, and start thinking of getting this onto some more machines than mine...
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
