I came across this paragraph from the July 1981 Popular Science magazine edition in the article titled “Compute power - pro models at almost home-unit prices.”
“ ‘Personal-computer buffs may buy a machine, bring it home, and then spend the rest of their time looking for things it can do’, said …. ‘In business, it’s the other way around. Here you know the job, you have to find a machine that will do it. More precisely, you have to find software that will do the job. Finding a computer to use the software you’ve selected becomes secondary.”.
Do you guys* think that software drove hardware sales rather than the other way around for businesses in the early days? I recall that computer hardware salespeople would be knocking on businesses office doors rather than software salesmen. Just seeking your opinion now that we are far ahead from 1981.
(*I do wish we have female gender engaged in the classic computing discussions threads as well. Maybe there is.)
Regards,
Tarek Hoteit
AI Consultant, PhD
+1 360-838-3675
Based on what I have read, along with a few discussions I have had with
people involved in the early S-100 "scene" around now is the 50th birthday
(or conception day) of the Altair 8800. Certainly, next year could properly
be called its 50th birthday. Anyway, I'm thinking about "painting the show
blue" with Altairs and IMSAIs for the next few vintage computer festivals.
Anyone else interested?
Bill S.
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
I looked up the Jan. 1975 issue of Popular Electronics in the Copyright Office's Periodicals Digest. It was published on Nov. 19, 1974 if you are looking for an actual anniversary date.
-W
> On Saturday, April 27th, 2024 at 07:14, Bill Gunshannon via cctalk <
> cctalk(a)classiccmp.org> wrote:
>
> > > Magazine cover january, and into 1975 the revolution. So I'd say
> > > all
> >
> > I had that magazine. Wish I hadn't thrown it away oh so many years
> > ago.
>
> This one?
>
> https://urldefense.com/v3/__https://archive.org/details/197511PopularE
> lectronics__;!!AQdq3sQhfUj4q8uUguY!jsVD6bkUUnjpF4d8AeRUKyiCW6qk8LAqFsj
> dYW5cjAK-kOsMp32O4FfrPI5l1lqnTNp6sXQsHpX35FsPAzYDMIHhl-uy-NSC5w$
>
> The Doctor [412/724/301/703/415/510]
> WWW:
> https://urldefense.com/v3/__https://drwho.virtadpt.net/__;!!AQdq3sQhfU
> j4q8uUguY!jsVD6bkUUnjpF4d8AeRUKyiCW6qk8LAqFsjdYW5cjAK-kOsMp32O4FfrPI5l
> 1lqnTNp6sXQsHpX35FsPAzYDMIHhl-u9z1M8kw$
> Don't be mean. You don't have to be mean
>
https://urldefense.com/v3/__https://vintagecomputer.net/altair-poptronics.c…
(Jan and Feb)
I had not realized the IBM 360 was 60 yrs. old this month. I worked on such
a computer in the late 60s in Toronto. What one could do with 8 Kbytes of
ram was remarkable!
Happy computing
Murray 🙂
Hello everyone
I need your help to identify an issue on my Diablo Model 40 Series. I
don't know where to look, it's so vast !
Here's the problem:
When RUN is activated, the drive begins its spin up and simultaneously
deploys the heads (normal) but instead of stabilizing them, the Head
Positioner receives a burst of reverse/forward micro signals. The heads
"vibrate", this creates an audible frequency "BRRRRRRRRRRRRRRRRRR", and
it is infinite, the heads are never loaded and the drive never reaches
READY.
At first I thought that perhaps the track zero sensor was defective or
something of the same order but when I disengage RUN mode, the drive
unloads the heads and they should be in a fixed position, here they
continue to reverse/forward but more slowly than in RUN mode.
Because the heads continues to mess around even in unload mode, this a
priori excludes alignment problems.
Here is a video of that issue:
https://youtu.be/HzzxLnSdEOg
Other information, if I cut the power while the drive is in RUN mode, it
does not do an emergency retraction of the heads, related problem?
I was hoping for a power supply problem but all the voltages and even on
the main board cage seem ok (with a multimeter).
If one of you had already encountered this problem of lack of head
stabilization and continuous reverse/forward on this type of drive?
Thanks !
Dominique
Hi Don !
Good suggestion, these microswitches are used to indicate that the heads
are completely retracted.
Unfortunately, that would have been too simple, both microswitches work
perfectly :-/
On 30/04/2024 19:43, D. Resor wrote:
> What is the purpose of the two microswitches seen in the upper right
> of the video view?
>
> Could one or both of those be intermittent? Have they been tested for
> continuity/intermittence with an analog VOM?
>
> Don Resor
>
> -----Original Message-----
> From: Dominique Carlier via cctalk <cctalk(a)classiccmp.org>
> Sent: Tuesday, April 30, 2024 8:47 AM
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk(a)classiccmp.org>
> Cc: Dominique Carlier <dce(a)skynet.be>
> Subject: [cctalk] Diablo Model 40 Series - Disturbed head positioning
>
> Hello everyone
>
> I need your help to identify an issue on my Diablo Model 40 Series. I
> don't know where to look, it's so vast !
>
> Here's the problem:
> When RUN is activated, the drive begins its spin up and simultaneously
> deploys the heads (normal) but instead of stabilizing them, the Head
> Positioner receives a burst of reverse/forward micro signals. The
> heads "vibrate", this creates an audible frequency
> "BRRRRRRRRRRRRRRRRRR", and it is infinite, the heads are never loaded
> and the drive never reaches READY.
>
> At first I thought that perhaps the track zero sensor was defective or
> something of the same order but when I disengage RUN mode, the drive
> unloads the heads and they should be in a fixed position, here they
> continue to reverse/forward but more slowly than in RUN mode.
> Because the heads continues to mess around even in unload mode, this a
> priori excludes alignment problems.
>
> Here is a video of that issue:
>
> https://youtu.be/HzzxLnSdEOg
>
> Other information, if I cut the power while the drive is in RUN mode,
> it does not do an emergency retraction of the heads, related problem?
> I was hoping for a power supply problem but all the voltages and even
> on the main board cage seem ok (with a multimeter).
>
> If one of you had already encountered this problem of lack of head
> stabilization and continuous reverse/forward on this type of drive?
>
> Thanks !
>
> Dominique
>
All —
I mostly lurk on the list now, but I am looking for a manual for the Lomas LightningOne 8086 CPU board. There doesn’t seem to be a good archive of manuals for the Lomas boards (and what’s out there is only partial). I have a project I’m working on with Lomas boards so looking to collect info, etc.
Thanks!
Rich
--
Rich Cini
http://cini.classiccmp.org
All —
I lurk mostly on the list now, but I’m looking for a copy of the manual for the Lomas LightningOne 8086 CPU card and schematics. It doesn’t seem to be anywhere on-line so if someone has a copy they’d be willing to scan, it’d be greatly appreciated.
Thanks!
Rich
--
Rich Cini
http://cini.classiccmp.org
Hi,
As some of you may recall, a few years ago I asked for assistance
reading a 9 track tape containing IBM S/360 source for Martinus
Veltman's computer algebra program, Schoonschip
(https://en.wikipedia.org/wiki/Schoonschip). With Chuck's assistance,
we recovered all the code from the tape. After working with the
principals involved, I am pleased to announce that the source code is
now publicly available at:
https://vsys.physics.lsa.umich.edu/
Actually, I was always more interested in the original CDC 6600 source
code, as that is the more historically significant code. While that
was not contained on the 9 track tape, I did receive a copy from the
Veltman family, and that is also available from the above website.
I have limited experience with big iron, but I had very good success
getting Schoonschip compiled and running on dtCyber. Veltman also
provided example Schoonschip programs (YNGLING), and as far as I can
tell they run perfectly in CDC Schoonschip on dtCyber. However, I
have not been fully successful in getting IBM Schoonschip to run on
hercules under OS/360 MVT. The main issue I had was that the Fortran
part of Schoonschip uses REAL*16, which apparently requires the H
extended Fortran compiler that does not seem to be freely available.
I did patch the Fortran code to avoid extended precision and managed
to get Schoonschip running, but it would sometimes crash on some input
files. I do not know if that is a problem with my patches or an
actual bug in the original code (as the IBM version of Schoonschip was
still a work in progress at the time development stopped).
In any case, anyone who is interested is welcome to have their own go
at the code. The third evolution of Schoonschip (m68k code, which was
written after Veltman came to the University of Michigan) is also
available at the same website.
- jim
--
James T. Liu, Professor of Physics
3409 Randall Laboratory, 450 Church Street, Ann Arbor, MI 48109-1040
Tel: 734 763-4314 Fax: 734 763-2213 Email: jimliu(a)umich.edu
