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
Some may find this interesting. Microsoft has released the source for MS-DOS versions 1.25, 2, and 4.
https://github.com/microsoft/MS-DOS
Will
Grownups never understand anything by themselves and it is tiresome for children to be always and forever explaining things to them,
Antoine de Saint-Exupery in The Little Prince
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
Well, if you are into this kind of stuff (I am)... Stross is an s-f
author, formerly a programmer (ages ago but I think it still shows -
perhaps he secretly writes his own tools in Perl) and he has a
blog. This time, he explores the idea that internet "bub" delivered on
its promises, rather than sucking investors up.
http www.antipope.org charlie/blog-static/2024/04/the-radiant-future-of-1995.html
Of course, readers make comments, so it gets a bit more interesting.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
In case anyone is interested in poking their cg14/sx in new and
exciting ways :-p
---------- Forwarded message ---------
From: Michael <macallan1888(a)gmail.com>
Date: Tue, 23 Apr 2024 at 07:55
Subject: CG14 and 16bit colour
To: <port-sparc(a)netbsd.org>
Hello,
I did a lot of work on the cgfourteen, sx and xf86-video-suncg14
drivers, one thing I didn't expect was people asking for 8bit
acceleration in X, mostly because with a 4MB cg14 you're limited to
1152x900 in 24bit colour, in 8bit you could go all the way to
1920x1200. So I wrote code for that.
Looking at the headers files, it looks like at least the DAC supports
16bit colour as well, which would allow 1600x1200 in more than 8bit
colour.
Getting SX to deal with 16bit quantities is not difficult, at least for
basic stuff like copy, fill and ROP operations. Xrender would be more
difficult since there is no easy way to separate / re-unite the colour
channels of a 16bit pixel. For 32bit it's trivial, SX has instructions
to split 32bit accesses to four registers, even lets you pick which
byte to take. So we wouldn't get xrender acceleration.
Then again, we don't have that in 8bit either.
The DAC is an Analog Devices ADV7152, and I just found the datasheet -
in 16bit mode we get R5G5B5, nothing unusual here.
That said, cg14 seems to use the DAC only for gamma correction, we
don't mess with it at all even when switching to 8bit, so who knows
what exactly cg14 feeds it when we set pixel mode to 16bit.
Shouldn't be difficult to figure out though.
I guess what I'm getting at is - does anyone particularly care about
this? I don't mind doing this as yet another Just Because I Can(tm)
project but if anyone cares I'd welcome their input.
have fun
Michael
