Michael Holmes <mholmes10 at hotmail.com> writes:
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.=20
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.
That is/was Camiel Vanderhoeven. He's working with Migration Specialties
Inc. (MSI) these days on a commecial Alpha emulation. I've been actively
working with them (MSI) on a parallel project. If you want, I could ask
him if he'd mind entertaining question from you about the ES40 project.
I'm running AlphaVM-Free from EmuVM on Linux. I suspect that one of the
reasons Artem has not ported it to OSX is that he doesn't have anything
running OSX. You could ask him. His email is: artem.alimarin at gmail.com
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
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
