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
Mike, any tips or guidelines for running an emulated PDP on a Raspberry Pi ?
Regards,
Tarek Hoteit
> On Apr 21, 2024, at 08:08, Mike Katz via cctalk <cctalk(a)classiccmp.org> wrote:
>
> Well my PDP-8 was built in 1974 and is still running (with careful maintenance). My PiDP-8/I has been up and running continuously with a Raspberry PI 3B running it for about 5 years now. My PiDP-11 has been up and running with a PI-4B for more than 4 years continuously.
>
> Though I agree with your comment that the PDP-8 was built to last (just ignore the disintegrated foam used between the motherboard and the case or on the case top) I have PCs that are more than 10 years old that are still running.
>
> As for the RP2040 being cheap crap, I beg to differ with you. It is a solid chip, produced in 10s of millions at least. And, I would bet, a better quality chip than your Z-80, if due only to improved IC manufacturing technologies.
>
> Just because it's old doesn't make it good. I worked on a 32KHz 4 Bit CPU (about 20 years ago) where the development hardware was very unstable and the tool chain not a whole lot better.
>
> Early Microsoft and Lattice C compilers for the PC were buggy as hell. If you want I can list a few bugs from each of them in another thread.
>
> One of the biggest features of the Z-80, the extra register set, was rarely used in open source software in order to maintain compatibility with the 8080.
>
> Some of the early Z-80 CP/M tools did not work because they were derived from 8080 tools. After time the tools got better. That is the case with any piece of software. If it doesn't become obsolete and if maintained it will get better over time.
>
>
>
>> On 4/21/2024 1:09 AM, ben via cctalk wrote:
>>> On 2024-04-20 8:33 p.m., Mike Katz via cctalk wrote:
>>> For anything more sophisticated than your coffee pot the RP2040 from Raspberry Pie is a fantastic little chip, dual core 133 MHz Cortex M0+ with 8 PIO engines, 264K of RAM, ADC, UART, SPI, I2C all for under a dollar. I designed a fully functional RP2040 with 16 Mb flash for under $2.00. In large enough quantities that's encroaching on 8 bit PIC territory at over 1000 times the memory and CPU power.
>>
>> I am wishing for a Quality Product, cheap crap is not always better.
>> USB comes to mind.
>> 256Kb ram is only 32K 64 bit words. Cache memory never works.
>> My $5 internet toaster, just exploded after 3 days.
>> So what? Just buy the new model that works with windows 12.
>> Download a buggy new tool chain. The Z80 tools worked.
>>
>>
>> The PDP8 was built to last. 50+ years and going strong.
>> NOT the crappy PI PDP-8 or PDP-10. I give it 2 years max.
>> Now a PI style computer with compact FLASH x 2, NO USB
>> and 2 MEG ram , real serial and printer ports that will work
>> in a noisy industrial setting, would be quite usefull.
>> I'd pay even $3 for it. :)
>>
>>
>>
>>
>
Mostly to Bill, but also anyone else hanging out here who's got a surfeit
of 8-bit Apple stuff:
If you're planning on selling the Apple II, and it's not a ][+, I'd be
interested in buying. Not, perhaps, at optimistic eBay prices, but I have
a lot of ][+s and //es, most of them in working shape, some of which are
parts machines; however, I don't have either a II or a //c .
Also happy to trade if I've got things you want. I don't have anything
super-exotic, but feel free to HMU and ask.
Adam
Was reading the Wikipedia article on Drum memories:
https://en.wikipedia.org/wiki/Drum_memory#External_links
And came across this tidbit.
As late as 1980, PDP-11/45 machines using magnetic core main memory
and drums for swapping were still in use at many of the original UNIX
sites.
Any thoughts on what they are talking about? I could see running the
RS03/RS04 on a 11/45 with the dual Unibus configured so the RS03's talk
to memory directly instead of the Unibus, but that's not quite the same
as true drum memory.
Closest thing I remember was the DF32 on a pdp8 which could be addressed
by word as opposed to track/sector.
Thoughts?
C
