From: Dwight Elvey <elvey(a)hal.com>
> There was no standard port used for serial I/O. and even if
>there was, the device could have been a AY-3-1015, a 8251 or
>a 8250. All of these would have different handshake and
>setup information. I don't know how you'd be able to have
>anything that you'd call standard.
Wrong. The standard devices were usually AY-3-1015/COM2502
based and tended to use the MITS status bits and IO addresses.
Mits never used the 8251, and the 8250 was later to the scene.
MITS set a standard in as much as there were very few then
by sticking to the 2sio standard or the SIOB standard for serial
ports with the SIOB being a uart like ay-3-1015 and the 2sio
using 6850s.
Expereince says, the common usart like the 1015/com2502
was most widely use with the 8251(9551/2651) the 6850 running
follow on. The only S100 board I've seen the 8250 on was the CCS.
The 8250 was not a widely used part in the late 70s on S100.
I'd be quick to point out that the mits era was 1975-1977ish with
other players already emerging as new leaders (NS* horizon
and friends) by late 1977 in the S100 space. From 77-80 that
would again undergo major changes going from the MITS/IMASI
front pannel style machines to the Northstar*, CCS, Compupro
turnkey style front pannel less and disk based systems.
It was also simple enough at the time to fix IO in most code as
it was trivial in construction and easy to find in binaries.
allison
Does anybody have the specs for an IBM POWERdisplay 20, p/n 09G3821?
I searched all over IBM's website. It's like it is yesterday's model
(which it is) and they only wanna tell you about the latest and greatest.
TIA
Mike
From: John Allain <John.Allain(a)donnelley.infousa.com>
>The HWID I speak of is a Unique ID per individual CPU.
True. And it identifies the basic hardware and CPU.
>Think relicence.
Keep in mind the basic "kits" carry no license or other
machine locked stuff. The license is applied during or
after the install. Even then I've built and installed systems
on my MVII and then carried the media to the MV2000
as both bootable and complete (even licensed if that
is within the written license terms). That was how we
cloned VMS sustems at DEC as it was faster than
using TK50 tapes.
I've put the VMS 7.2kit (cdrom) on everythingt from
MVII and VS2000 through 3100m76 and would expect
it to load and run on most any other VAX as well.
The biggest problem of installing on older hardware
is the minimum system (ram and disk) has grown
during the years and early version coulld fit on 30mb
disk and 1mb ram that has grown to over 150mb
disk and 4mb ram. Though it is possible to shoehorn
the latest version is to less than the specified disk
and ram it is a exercise fort the experienced and will
produce a system of limited utility.
>So, Any old copy of VMS can be relicenced for a
>matching or nearly matching architecture machine?
Well since all VAX are by definition matching hardware
there is little issue. However there are exceptions
like the RTVAX which is not totally cpu compatable
VAX and differs in the translate tables, it never ran VMS.
>Tell me, is that through Montagar?
The VMS7.2 Hobbiest version is available there. Note
HOBBIEST version does not mean stripped or limited.
It means it's packaged with many hobbiest desireable
packages besides VMS itself.
>P.S. Can users fo VMSbuilds?
VMSbuild is a standard utility and is used often to configure
custom installs once you have a configureation you want
to standardize on. Anotehr useful VMS utility for small
systems is VMStailor which allows trimming off or adding in
libraries, fonts and other peices to tailor a system.
Allison
I am not familiar with this model. Many GAs used the PICK operating system.
I had a GA 5000 at one time and it was a Multibus machine with a 68000 CPU,
32 user ports, 150 Meg 14" Priam HD, 1/4" tape, 1/2" Cipher tape, all in a 5'
high case. Top of the line in it's day.
I may have some of the PICK manuals around if anyone is running one of these.
I recommend trying to save it.
Paxton
Portland, OR, USA
From: Dwight Elvey <elvey(a)hal.com>
>Hi
> One of the other problems was that even which bits were use
>to handshake the transmit and receive could change depending
>on how one wired the board, so just knowing the port is still
>no enough. Any commercial software that didn't go through
>the BIOS was asking for troubles since there was no way
>to determine how the console was done. On some systems it
>went through a video board and not serial, at all.
>Dwight
Therein lies the problem, as back then the average MITS or IMSAI
did not have any rom and no concept of a BIOS, it would be CP/M
that originated that concept for small systems and called it that.
Even then the CPM bios only hid the underlying IO with standard
interface and the IO could litterally be anything on the map (often was).
If anything the idea of canned IO was something unique to systems
like the SOL and a few others and rare in the s100 world.
Allison
From: healyzh(a)aracnet.com <healyzh(a)aracnet.com>
>It *might* run, however, V6.2 was the last version of VMS to support an
>11/750. Just like V7.2 will be the last version to support the MV2
family.
First a word from... When DEC says Support they mean assitance not
it will not work. Support is a service they provided and if it's
supported
you could under your support contract call and expect help. If it was
not supported it will likely run but don't call DEC support if it
doesn't.
So that means prior to MV2 is not "supported" but the drivers are
likely there and work.
I'd expect a 750 with RA81 and 8mb ram would run V7.2 just fine.
But if you ask around older 6.2 and V5.5 kits arent that hard to
find. Their owners will likely let you borrow them as it's up to you
to get your own license pak which is not tied to the media.
I have it on good word that V7.3 does still run on MVIIs.
Allison
>>Dwight wrote
>There was no standard port used for serial I/O. and even if
>there was, the device could have been a AY-3-1015, a 8251 or
>a 8250. All of these would have different handshake and
>setup information. I don't know how you'd be able to have
>anything that you'd call standard.
>Dwight
I guess that my question was partially answered by Jim. Using Altair BASIC,
BASIC polled the switches (at port FF) in order to determine which ports to
use for various I/O. Disk BASIC was the choice (running over CP/M), the BIOS
would have to be recompiled with the proper port locations for the hardware
one was using.
What I was kind of getting at was as follows. If I wanted to provide
emulated console I/O, what port would I virtualize so that any software I
loaded would run? I guess that my PeeCee-centricity was showing a bit in
that in the PeeCee certain hardware ports were always at the same location.
So, the conclusion is that if I want to emulate a single console port, I
have to select which serial board to emulate (the 2-SIO for example) and
virtualize ports 20Q and 21Q.
It also sounds like that I need to trap input port 0xff as the "sense
switch" port. This may be done in the emulator already; I have to check.
Rich
-----Original Message-----
From: Dwight Elvey [mailto:elvey@hal.com]
Sent: Tuesday, September 12, 2000 12:35 PM
To: classiccmp(a)classiccmp.org
Subject: Re: Altair Emulator enhancements - progress report - questions
"Cini, Richard" <RCini(a)congressfinancial.com> wrote:
>
> I also have some questions of actual users of the Altair. I wanted
> to use a copy of Palo Alto Tiny BASIC on the emulator (because that's the
> BASIC that I have), but TB relies on CP/M for console I/O. Regarding the
> original Altair BASIC, did the BASIC code provide its own I/O services or
> did it use CP/M also? What port locations were generally used to service
> serial ports used for console I/O? Does anyone have a working set of CP/M
> binaries that I can load into the emulator?
Hi
There was no standard port used for serial I/O. and even if
there was, the device could have been a AY-3-1015, a 8251 or
a 8250. All of these would have different handshake and
setup information. I don't know how you'd be able to have
anything that you'd call standard.
Dwight
In einer eMail vom 8/9/100 3:17:33AM, schreiben Sie:
<<
I've used it since the early '80's but my work has hovered over the low-end
capabilities of the language. Now that it's obsolete, I'm trying to make up
for all the stuff I didn't learn when it was mainstream. I've had people
tell me about features I've never even read about, and there are plenty of
them that I haven't used and HAVE read about. It's pretty simple if not
compact, to do everything with logic equations, and that's what I've always
done. Now I'm trying to catch up on the built-in state-machine dialects.
They use several constructs which have carried forward, somewhat, into
Verilog and VHDL, but not in the same way or with the same syntax as PALASM.
>>
It occured to me that the quite modern and today mainstream language Abel
has somewhat similar constructs, and is part of most modern electronic CAD
systems. While having retained quite some similarity with PALASM, it may be
closer to today's tools like VHDL.
Regards
John G. Zabolitzky
As Zane mentioned, he's getting a used Metcal SP-200 station to
play with. I also know this because he got it from me.....
For those of you who don't know, these are professional-grade
induction-heating systems with extremely light handpieces and
dozens of interchangeable tips. Heat is practically instantaneous,
and they are also static-free. They also run about $400 new.
The surplus shop where I work during a goodly portion of my free
time has a limited number of power supplies and handpieces
available, unfortunately, no tips or stands. We got them from an
electronics plant that shut down. Tips range from about $15 up to
$30 new, I think, depending on the tip.
If you're interested in one, email me off-list and I'll let you know
what we have. These are great irons -- I have two (one at home and
one at work) and absolutely love both of 'em. I hung up my Weller
and my Ungar when I got the Metcal.
Thanks.
Paul Braun WD9GCO
Cygnus Productions
nerdware_nospam(a)laidbak.com
Hello, all:
Just a quick update on my progress with enhancing the Altair
Emulator. I also have an activity log on my Web site which all can view.
Most of what will go on over the next few weeks is code testing as a
complete recompiled "altair.exe".
A few notes:
- The emulated paper tape punch code works on a standalone basis and
has been integrated into the overall emulator. This is the code I need to
bang on.
- I wrote a bus I/O emulation Windows DLL to handle actual I/O
through the PeeCee's parallel port. I still have to build a little test jig
to connect to the port (an inverter, a latch, and a bus transceiver). This
gives the emulator 8-bits of external address space and 8-bits of I/O with
*ALE (latch control) and *R/*W signals. The way this is setup, the parallel
port is still shared with other Win32 processes. If this doesn't work for
the emulator, I'll have to write a dynamic virtual device driver to gain
exclusive access to the port so long as the Altair is "on."
- In a few weeks, I'm going to tinker with console emulation either
through capturing a physical communications port that has no underlying
hardware (like COM5:) so that a Windows terminal program can "connect" to
the Altair Emulator. Alternately, I may try just building a virtual-VDT into
the emulator.
- Other enhancements will hopefully include a virtual floppy drive
and the ability to "install" ROM.
One I have the base code stable (it now compiles/links with no
errors), I plan to make the binary available for testing and the source
available for review. Some of the punch code could benefit from
optimization, no doubt.
I also have some questions of actual users of the Altair. I wanted
to use a copy of Palo Alto Tiny BASIC on the emulator (because that's the
BASIC that I have), but TB relies on CP/M for console I/O. Regarding the
original Altair BASIC, did the BASIC code provide its own I/O services or
did it use CP/M also? What port locations were generally used to service
serial ports used for console I/O? Does anyone have a working set of CP/M
binaries that I can load into the emulator?
Again, any help is greatly appreciated.
Rich
http://highgate.comm.sfu.ca/~rcini/classiccmp/