On 11/10/2013 20:54, Cory Smelosky wrote:
On Fri, 11 Oct 2013, Dave McGuire wrote:
On 10/11/2013 02:13 AM, Mark Benson wrote:
http://www.artmix.com/SATA_SCSI_AZMN_II_1.html
This adapter is available on ebay for $149 and he says they work well
in Vaxstations. He also has some which take CF flash cards.
Which is great, but again you run in to the snag that I've never seen a
SATA disk smaller than 40GB and the upper size limit on a VAXstation is
typically 18GB. Somewhat problematic.
I have 2 20G laptop SCSI drives...
WHY does this keep coming up? There is no such limitation!
I'm easily confused...
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On Fri, 11 Oct 2013, Dave McGuire wrote:
On 10/11/2013 02:13 AM, Mark Benson wrote:
http://www.artmix.com/SATA_SCSI_AZMN_II_1.html
This adapter is available on ebay for $149 and he says they work well
in Vaxstations. He also has some which take CF flash cards.
Which is great, but again you run in to the snag that I've never seen a
SATA disk smaller than 40GB and the upper size limit on a VAXstation is
typically 18GB. Somewhat problematic.
I have 2 20G laptop SCSI drives...
WHY does this keep coming up? There is no such limitation!
Lack of determination.
-Dave
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 10/11/2013 02:13 AM, Mark Benson wrote:
http://www.artmix.com/SATA_SCSI_AZMN_II_1.html
This adapter is available on ebay for $149 and he says they work well
in Vaxstations. He also has some which take CF flash cards.
Which is great, but again you run in to the snag that I've never seen a
SATA disk smaller than 40GB and the upper size limit on a VAXstation is
typically 18GB. Somewhat problematic.
WHY does this keep coming up? There is no such limitation!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
No, that would not be legal (and in fact the DEC FDDI chips contain specific machinery to detect and remove duplicate tokens should any show up). Sridhar was talking about a switch (bridge), so each port is a separate LAN and as such has its own circulating token.
paul
On Oct 11, 2013, at 2:04 PM, Hans Vlems <hvlems at zonnet.nl<mailto:hvlems at zonnet.nl>> wrote:
Wouldn't that mean more than one token on a ring?
Van: Sridhar Ayengar
Verzonden: vrijdag 11 oktober 2013 19:55
Aan: hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE>
Beantwoorden: hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE>
Onderwerp: Re: [HECnet] FDDI advice
Paul_Koning at Dell.com<mailto:Paul_Koning at Dell.com> wrote:
Half duplex Ethernet slows down when there are collisions, but there
is no wait to transmit whenever the link is idle. With FDDI, there
is (you wait for the token). So at high load, half duplex Ethernet
might be a little slower than FDDI, but at modest load, it will
definitely be faster (lower latency).
But, doesn't the GIGAswitch get around that by generating a token for
each port? Isn't that how switched-FDDI works?
Peace... Sridhar
Wouldn't that mean more than one token on a ring?
Van: Sridhar Ayengar
Verzonden: vrijdag 11 oktober 2013 19:55
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] FDDI advice
Paul_Koning at Dell.com wrote:
> Half duplex Ethernet slows down when there are collisions, but there
> is no wait to transmit whenever the link is idle. With FDDI, there
> is (you wait for the token). So at high load, half duplex Ethernet
> might be a little slower than FDDI, but at modest load, it will
> definitely be faster (lower latency).
But, doesn't the GIGAswitch get around that by generating a token for
each port? Isn't that how switched-FDDI works?
Peace... Sridhar
On Oct 11, 2013, at 1:55 PM, Sridhar Ayengar <ploopster at gmail.com> wrote:
Paul_Koning at Dell.com wrote:
Half duplex Ethernet slows down when there are collisions, but there
is no wait to transmit whenever the link is idle. With FDDI, there
is (you wait for the token). So at high load, half duplex Ethernet
might be a little slower than FDDI, but at modest load, it will
definitely be faster (lower latency).
But, doesn't the GIGAswitch get around that by generating a token for each port? Isn't that how switched-FDDI works?
On token LANs there's a token per LAN. Yes, if you bridge token LANs, each LAN has its own token. That's true for all bridges, it's a consequence of what a bridge is.
But still, on any one LAN, the stations have to wait for the token. That is, unless you have exactly two MACs, and they are DEC stations that support the DEC full duplex mode. If so, you have no token, and the link operates essentially the same as Ethernet in full duplex mode (except for header format and min/max packet sizes).
paul
Paul_Koning at Dell.com wrote:
Half duplex Ethernet slows down when there are collisions, but there
is no wait to transmit whenever the link is idle. With FDDI, there
is (you wait for the token). So at high load, half duplex Ethernet
might be a little slower than FDDI, but at modest load, it will
definitely be faster (lower latency).
But, doesn't the GIGAswitch get around that by generating a token for each port? Isn't that how switched-FDDI works?
Peace... Sridhar
On Oct 11, 2013, at 1:25 PM, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
Thanks Paul for the detailed clarification!
On 11.10.2013 17:23, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 2:28 AM, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
...
Yes, that would be the one when converting between FDDI and 100BaseT Ethernet.
The best effort it can produce is about what 100BaseT can, because it is the lowest common nominator. FDDI performs better due to the larger packet size (which is usable only between FDDI nodes) and the lower overhead.
Larger packet size, yes. Lower overhead, no. Token systems of any kind are guaranteed to be less efficient than Ethernet, because you have to wait for the token. At best, they will be slightly better under very high load than half duplex Ethernet, but full duplex Ethernet will outperform any token network under all conditions.
It's very clear that FDDI will outperform half duplex Ethernet, because there will not occur any collisions in FDDI.
But if we think about a FDDI-to-100BaseT (Full duplex) topology and the traffic flows with as large packets as possible, doesn't FDDI be able to carry about three times more payload in each packet than Ethernet? In that case one FDDI packet payload will need to be split into three Ethernet packets and three Ethernet packet payloads will fit into one FDDI packet.
Yes, the smaller packet size of Ethernet means the CPU does per-packet processing 3 times as often, which has a performance impact. (Pretty small, if the CPU is fast.) And three headers instead of one makes a difference, but only a bit over 1%.
Half duplex Ethernet slows down when there are collisions, but there is no wait to transmit whenever the link is idle. With FDDI, there is (you wait for the token). So at high load, half duplex Ethernet might be a little slower than FDDI, but at modest load, it will definitely be faster (lower latency).
paul
Thanks Paul for the detailed clarification!
On 11.10.2013 17:23, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 2:28 AM, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
...
Yes, that would be the one when converting between FDDI and 100BaseT Ethernet.
The best effort it can produce is about what 100BaseT can, because it is the lowest common nominator. FDDI performs better due to the larger packet size (which is usable only between FDDI nodes) and the lower overhead.
Larger packet size, yes. Lower overhead, no. Token systems of any kind are guaranteed to be less efficient than Ethernet, because you have to wait for the token. At best, they will be slightly better under very high load than half duplex Ethernet, but full duplex Ethernet will outperform any token network under all conditions.
It's very clear that FDDI will outperform half duplex Ethernet, because there will not occur any collisions in FDDI.
But if we think about a FDDI-to-100BaseT (Full duplex) topology and the traffic flows with as large packets as possible, doesn't FDDI be able to carry about three times more payload in each packet than Ethernet? In that case one FDDI packet payload will need to be split into three Ethernet packets and three Ethernet packet payloads will fit into one FDDI packet.
Btw. Many of the FDDI principles was used when developing FibreChannel.
Not really. The two were done at the same time (in different subgroups of ANSI X3T9) but with no significant connection between them. FDDI was 100 Mb/s, Fibre Channel was initially 800 Mb/s (not 1 Gb/s -- FC has always committed false advertising by reporting the baud rate of the encoded signal rather than the payload rate -- if Ethernet had done things in FC terms then 10 Mb/s Ethernet would have been called 20 Mb/s Ethernet). And even the PHY is completely different: 4b/5b coding for FDDI, 8b/10b for F
C.
I see, my memory didn't serve me right then. I thought FC was developed later than FDDI and that FC had adopted the similarities from FDDI.
Sorry about the confusion. I should dust off my bookshelf and reread the books about FDDI and FC to refresh my memory.
As I mentioned before, FDDI was based on 802.4 (token bus) MAC layer algorithms ("timed token protocol"), with vast quantities of complexity added on top. (Partly that was done by some of the participants to delay the standard by a couple of years.) Fast Ethernet adopted the 4b/5b encoding from FDDI, but apart from that it was a technological dead end.
paul
.
Kari
On 2013-10-11 17:22, Mark Darvill wrote:
It would be worth looking at v2.5 and 3 as I seem to remember that the graphics did improve but it was wire line but was neat for a late 80's internal project.....
Well, I worked at DEC back in 86, and it worked pretty well back then. I don't think even the 3100 had been introduced yet. We had VAXstation I and VAXstation II machines around, and that was it.
Johnny
We did run it on Vaxstations of various types including 4000/60's but also used to X out of big vaxes such as the 9000 we had in my last stint at DEC.
Mark
On 11 Oct 2013, at 17:15, Mark Wickens <mark at wickensonline.co.uk> wrote:
On 11/10/2013 15:59, Johnny Billquist wrote:
On 2013-10-11 16:25, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
I remember it from when I worked at DEC. As far as I know, it was not a derivative of anything else.
It was pretty cool, but back when I played with it, all airplanes were just wire frames, as was the world.
It ran pretty ok on a uVAX II, though (with GPX).
I didn't know it had been released out from DEC. I played it with people over Easynet.
Johnny
Definitely all wire frame in the one, so it's probably what you've played. I don't even remember any hidden line removal, but I could be wrong...
Mark
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
That's odd, my VS 4000/60 and /90A also show non Dec branded disks on the >>> sho dev command.
Must check that owing to failing organic memory...
Van: Mark Wickens
Verzonden: vrijdag 11 oktober 2013 09:17
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] SSD for Vax
On 11/10/2013 01:52, Daniel Soderstrom wrote:
> http://www.artmix.com/SATA_SCSI_AZMN_II_1.html
>
> This adapter is available on ebay for $149 and he says they work well in Vaxstations. He also has some which take CF flash cards.
>
> Regards,
>
> Daniel,
>
>
Thanks for the link Daniel. This is great news. I know that there have
been various incarnations of adapters that have come and gone and been
niche enough that there hasn't been reliable evidence of their
functionality computers with older scsi implementations. Typically they
are built to support equipment in the music industry.
Anything that provides us a way forward is definitely a good thing! I
don't like noisy hard drives any more than the next person.
I will have to explore my theory of the 18GB limit on the VAXstation
4000/60 and /90 and I thought that was a hard rule, but I'm happy to be
proved wrong. It may be that I was using an earlier version of VMS where
it definitely is the case that only certain models of drive are
supported. I had to root around to find a supported drive for OpenVMS
6.1 - even generic Seagate 50 pin SCSI 2.1GB drives weren't recognised
because they aren't RZ* tagged in the firmware.
Regards, Mark.
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
It would be worth looking at v2.5 and 3 as I seem to remember that the graphics did improve but it was wire line but was neat for a late 80's internal project.....
We did run it on Vaxstations of various types including 4000/60's but also used to X out of big vaxes such as the 9000 we had in my last stint at DEC.
Mark
On 11 Oct 2013, at 17:15, Mark Wickens <mark at wickensonline.co.uk> wrote:
On 11/10/2013 15:59, Johnny Billquist wrote:
On 2013-10-11 16:25, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
I remember it from when I worked at DEC. As far as I know, it was not a derivative of anything else.
It was pretty cool, but back when I played with it, all airplanes were just wire frames, as was the world.
It ran pretty ok on a uVAX II, though (with GPX).
I didn't know it had been released out from DEC. I played it with people over Easynet.
Johnny
Definitely all wire frame in the one, so it's probably what you've played. I don't even remember any hidden line removal, but I could be wrong...
Mark
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On 11/10/2013 15:59, Johnny Billquist wrote:
On 2013-10-11 16:25, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
I remember it from when I worked at DEC. As far as I know, it was not a derivative of anything else.
It was pretty cool, but back when I played with it, all airplanes were just wire frames, as was the world.
It ran pretty ok on a uVAX II, though (with GPX).
I didn't know it had been released out from DEC. I played it with people over Easynet.
Johnny
Definitely all wire frame in the one, so it's probably what you've played. I don't even remember any hidden line removal, but I could be wrong...
Mark
--
http://www.wickensonline.co.ukhttp://hecnet.euhttp://declegacy.org.ukhttp://retrochallenge.nethttps://twitter.com/#!/%40urbancamo
On 2013-10-11 16:25, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
I remember it from when I worked at DEC. As far as I know, it was not a derivative of anything else.
It was pretty cool, but back when I played with it, all airplanes were just wire frames, as was the world.
It ran pretty ok on a uVAX II, though (with GPX).
I didn't know it had been released out from DEC. I played it with people over Easynet.
Johnny
On Oct 11, 2013, at 10:50 AM, Cory Smelosky <b4 at gewt.net> wrote:
On Fri, 11 Oct 2013, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 3:21 AM, Mark Benson <md.benson at gmail.com<mailto:md.benson at gmail.com>> wrote:
On 11 Oct 2013, at 07:47, Daniel Soderstrom <snaggs at mac.com<mailto:snaggs at mac.com>> wrote:
I'm not familiar with (S)ATA to SD converters. Such a beast would be fairly complex, similar in difficulty to an ATA to SCSI (SATA to SAS) converter.
SAS or SATA or SATA to SAS? SATA can run on SAS easily so I assume you do mean SAS to SATA.
Depends on what direction you look. Yes, SAS controllers can talk to SATA disks, with some level of success. (This is actually rather hard and strange bugs show up in this area.) I meant the protocol translation, for example for a SATA controller to talk to a SAS disk.
paul
Back when I had RSX 11M+ on a 11/44 with massbus, I looked and looked for a ML-11 to try out. Never did find one. The application was electron-beam lithography, we were trying to write holograms, and under certain conditions the hardware was always waiting around for the pattern data from the disk. We also ended up doing on-the-fly data decompression to reduce the size of the pattern on the disk, which made the throughput situation *worse*. (That's when I discovered "fast-mapping" under M+, which is by the way very cool.) The ML-11, had I been able to find one, might have helped significantly.
--Mike
On Oct 11, 2013, at 10:27 AM, Cory Smelosky <b4 at gewt.net> wrote:
On Fri, 11 Oct 2013, Johnny Billquist wrote:
On 2013-10-10 18:39, Hans Vlems wrote:
DEC had solid state disks, all das iirc
DEC had solid state disks already in the 70s. It was called the ML-11. Massbus interface even...
Now THAT is neat.
Johnny
On 2013-10-10 09:46, Mark Wickens wrote:
On 10/10/2013 08:17, Daniel Soderstrom wrote:
Has anyone tries this? Running my Vaxstation non-stop reminds me how
much noise these old drives make.
Has anyone tried SSD drives? Must be good for the PSU it terms of heat
and current draw.
Daniel
There has been very little success with IDE to SCSI converters on this
age of machine.
Hmm. bad IDE to SCSI converters?
Remember also that even 4000/90 vintage VAXstations generally have an
upper limit of 18GB.
Uh? That got to be a limit in VMS in that case. I can't see how the
hardware would have that limit.
I don't recall anyone even getting an IDE drive to work, let alone an
SSD.
IDE and SSD are two completely unrelated things as such. However, if the
SSD have an IDE interface, then you obviously need the IDE to SCSI
converter.
Would love to be proved wrong however! I'm surprised someone hasn't
written a software based SCSI drive emulator the same way that you get
floppy emulators.
Probably mostly because of speed issues. You have some very tight timing
requirements, and a SCSI interface runs way faster than a floppy.
Consider running the machine diskless, booted off the network with
off-node disks.
That definitely also works.
Johnny
--
Cory Smelosky
Michael Young
young at ecn.purdue.edu
On Fri, 11 Oct 2013, Paul_Koning at Dell.com wrote:
On Oct 11, 2013, at 3:21 AM, Mark Benson <md.benson at gmail.com<mailto:md.benson at gmail.com>> wrote:
On 11 Oct 2013, at 07:47, Daniel Soderstrom <snaggs at mac.com<mailto:snaggs at mac.com>> wrote:
I'm not familiar with (S)ATA to SD converters. Such a beast would be fairly complex, similar in difficulty to an ATA to SCSI (SATA to SAS) converter.
SAS or SATA or SATA to SAS? SATA can run on SAS easily so I assume you do mean SAS to SATA.
paul
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Oct 11, 2013, at 3:21 AM, Mark Benson <md.benson at gmail.com<mailto:md.benson at gmail.com>> wrote:
On 11 Oct 2013, at 07:47, Daniel Soderstrom <snaggs at mac.com<mailto:snaggs at mac.com>> wrote:
There are plenty of CF or SD cards under 18gb. Also, there must be some way of only using part of a drive, as these cards are used extensively in old Macs which have a 170mb boot drive limit.
I'm fully aware of that, in fact I plan to try using a 4GB CF card on my 4000/60 at some stage to see what it does. You linked to a *SATA* to SCSI adapter intended for use on hard drives?
I'm aware that SATA to CF/SD adapters are available, I used one for a while with a CF card. That may be an option but like others have said the reliability can be variable. Also some companies that offer embedded micro-PC stuff also sell 8GB and 16GB SATA SSDs that might be an option too, maybe? I am fairly sure I have a 16GB one spare somewhere.
CF and SD are both flash storage cards, but they have completely different interfaces.
CF is SATA with a different connector. A CF to SATA adapter is nothing more than a pair of connectors and some wires.
SD uses a serial packet protocol, a generalization of the one used by MMC devices. It's not SCSI, but it feels a bit like it because of that packet and command/response style of doing things. Also, SD has an extremely complex and strange initialization sequence.
I'm not familiar with (S)ATA to SD converters. Such a beast would be fairly complex, similar in difficulty to an ATA to SCSI (SATA to SAS) converter.
paul
On Fri, 11 Oct 2013, Johnny Billquist wrote:
On 2013-10-10 18:39, Hans Vlems wrote:
DEC had solid state disks, all das iirc
DEC had solid state disks already in the 70s. It was called the ML-11. Massbus interface even...
Now THAT is neat.
Johnny
*Van: *Johnny Billquist
*Verzonden: *donderdag 10 oktober 2013 11:29
*Aan: *hecnet at Update.UU.SE
*Beantwoorden: *hecnet at Update.UU.SE
*Cc: *Mark Wickens
*Onderwerp: *Re: [HECnet] SSD for Vax
On 2013-10-10 09:46, Mark Wickens wrote:
> On 10/10/2013 08:17, Daniel Soderstrom wrote:
>> Has anyone tries this? Running my Vaxstation non-stop reminds me how
>> much noise these old drives make.
>>
>> Has anyone tried SSD drives? Must be good for the PSU it terms of heat
>> and current draw.
>>
>> Daniel
>>
>> Sent from my iPhone
> There has been very little success with IDE to SCSI converters on this
> age of machine.
Hmm. bad IDE to SCSI converters?
> Remember also that even 4000/90 vintage VAXstations generally have an
> upper limit of 18GB.
Uh? That got to be a limit in VMS in that case. I can't see how the
hardware would have that limit.
> I don't recall anyone even getting an IDE drive to work, let alone an
SSD.
IDE and SSD are two completely unrelated things as such. However, if the
SSD have an IDE interface, then you obviously need the IDE to SCSI
converter.
> Would love to be proved wrong however! I'm surprised someone hasn't
> written a software based SCSI drive emulator the same way that you get
> floppy emulators.
Probably mostly because of speed issues. You have some very tight timing
requirements, and a SCSI interface runs way faster than a floppy.
> Consider running the machine diskless, booted off the network with
> off-node disks.
That definitely also works.
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
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Oct 11, 2013, at 4:36 AM, Mark Darvill <mark.darvill at mac.com> wrote:
Flight was the "game" we played when we could get access to suitable hardware in DEC, i do remember playing it on a new vax9000 in multi user mode and it was hot! For those who have not come across the program, it was a multi user simulation with many planes and airfields which also ran over computers connected via decnet. There was also a toolkit to create your own planes and airfields.
http://www.tmk.com/ftp/vms-freeware/decwindows/
Found a copy above. Maybe another use for hecnet....
Mark
I should take a look; I've never seen it. I wonder if it's a derivative of the PLATO game "airfight". That was written around 1974, by Brand Fortner at the University of Illinois. Same sort of description: multi user, several airplane types. No user defined airplanes or fields, though.
PLATO "airfight" was the inspiration for Microsoft Flight Simulator.
paul
On Oct 11, 2013, at 2:28 AM, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
...
Yes, that would be the one when converting between FDDI and 100BaseT Ethernet.
The best effort it can produce is about what 100BaseT can, because it is the lowest common nominator. FDDI performs better due to the larger packet size (which is usable only between FDDI nodes) and the lower overhead.
Larger packet size, yes. Lower overhead, no. Token systems of any kind are guaranteed to be less efficient than Ethernet, because you have to wait for the token. At best, they will be slightly better under very high load than half duplex Ethernet, but full duplex Ethernet will outperform any token network under all conditions.
Btw. Many of the FDDI principles was used when developing FibreChannel.
Not really. The two were done at the same time (in different subgroups of ANSI X3T9) but with no significant connection between them. FDDI was 100 Mb/s, Fibre Channel was initially 800 Mb/s (not 1 Gb/s -- FC has always committed false advertising by reporting the baud rate of the encoded signal rather than the payload rate -- if Ethernet had done things in FC terms then 10 Mb/s Ethernet would have been called 20 Mb/s Ethernet). And even the PHY is completely different: 4b/5b coding for FDDI, 8b/10b for FC.
As I mentioned before, FDDI was based on 802.4 (token bus) MAC layer algorithms ("timed token protocol"), with vast quantities of complexity added on top. (Partly that was done by some of the participants to delay the standard by a couple of years.) Fast Ethernet adopted the 4b/5b encoding from FDDI, but apart from that it was a technological dead end.
paul
On Fri, Oct 11, 2013 at 02:12:13PM +0200, Johnny Billquist wrote:
On 2013-10-11 08:13, Mark Benson wrote:
On 11 Oct 2013, at 01:52, Daniel Soderstrom <snaggs at mac.com
<mailto:snaggs at mac.com>> wrote:
http://www.artmix.com/SATA_SCSI_AZMN_II_1.html
This adapter is available on ebay for $149 and he says they work well
in Vaxstations. He also has some which take CF flash cards.
Which is great, but again you run in to the snag that I've never seen a
SATA disk smaller than 40GB and the upper size limit on a VAXstation is
typically 18GB. Somewhat problematic.
Uh? What 18GB limit? I thought we had already established that there
is no such limit.
We did. I even offered my 4000/90 with 146GB disks as evidence. :)
-brian
Hi Sampsa,
I've cleaned up, and added a sixel of you. It works, although it
might take some time to download the 2 Mb file of course :)
Erik
On Fri, Oct 11, 2013 at 02:21:16AM +0200, Sampsa Laine wrote:
Next challenge is to use JS to turn ReGIS into SVG and draw that :)
On 2013-10-11 08:13, Mark Benson wrote:
On 11 Oct 2013, at 01:52, Daniel Soderstrom <snaggs at mac.com
<mailto:snaggs at mac.com>> wrote:
http://www.artmix.com/SATA_SCSI_AZMN_II_1.html
This adapter is available on ebay for $149 and he says they work well
in Vaxstations. He also has some which take CF flash cards.
Which is great, but again you run in to the snag that I've never seen a
SATA disk smaller than 40GB and the upper size limit on a VAXstation is
typically 18GB. Somewhat problematic.
Uh? What 18GB limit? I thought we had already established that there is no such limit.
There is a 1GB limit (approx) for the booting device on some older VAXstations, but that's the only limit I'm aware of. (And the limit is somewhat more complicated than that, but anyway...)
Johnny
On 2013-10-10 18:39, Hans Vlems wrote:
DEC had solid state disks, all das iirc
DEC had solid state disks already in the 70s. It was called the ML-11. Massbus interface even...
Johnny
*Van: *Johnny Billquist
*Verzonden: *donderdag 10 oktober 2013 11:29
*Aan: *hecnet at Update.UU.SE
*Beantwoorden: *hecnet at Update.UU.SE
*Cc: *Mark Wickens
*Onderwerp: *Re: [HECnet] SSD for Vax
On 2013-10-10 09:46, Mark Wickens wrote:
> On 10/10/2013 08:17, Daniel Soderstrom wrote:
>> Has anyone tries this? Running my Vaxstation non-stop reminds me how
>> much noise these old drives make.
>>
>> Has anyone tried SSD drives? Must be good for the PSU it terms of heat
>> and current draw.
>>
>> Daniel
>>
>> Sent from my iPhone
> There has been very little success with IDE to SCSI converters on this
> age of machine.
Hmm. bad IDE to SCSI converters?
> Remember also that even 4000/90 vintage VAXstations generally have an
> upper limit of 18GB.
Uh? That got to be a limit in VMS in that case. I can't see how the
hardware would have that limit.
> I don't recall anyone even getting an IDE drive to work, let alone an
SSD.
IDE and SSD are two completely unrelated things as such. However, if the
SSD have an IDE interface, then you obviously need the IDE to SCSI
converter.
> Would love to be proved wrong however! I'm surprised someone hasn't
> written a software based SCSI drive emulator the same way that you get
> floppy emulators.
Probably mostly because of speed issues. You have some very tight timing
requirements, and a SCSI interface runs way faster than a floppy.
> Consider running the machine diskless, booted off the network with
> off-node disks.
That definitely also works.
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
