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 :)
