Like the Sanyo just yesterday, I have a Compaq SLT/286 portable computer
taking up space. Very nice condition, with power unit, dock, and bag. Any
interest CHEAP? I am located in New York, zip 10512.
Unlike the Sanyo, if there is no interest, I suppose I will just chop this
up.
I am desperately trying to clear out a bedroom to work on it - the bedroom
that ends up being the junk overflow containment chamber. It would
actually be nice to sleep in it sometime.
William Donzelli
aw288 at osfn.org
Jerome and Jon opined:
>> I normally use OLD (very rare and have been unable to find
>> them any longer) wooden Q-tips.
>
>
>In the US, try McMaster-Carr: http://www.mcmaster.com/#cotton-swabs/=o9xphz
And Scott drivels:
Or somewhere that does medical/dental supply. They're used in dental hygiene and surgery (the cardboard-shafted swabs go weak when they get wet).
>Does anyone know if Apple really manufactured the Widget HDD (circa 1983)
>used on the Lisa or did they purchase the HDA from a supplier and add to it
>their electronics?
>
>Tom
Your first link is broken. ;)
I thought the same thing until two things happened:
1: I got ahold of two Widgets and found that no, they are NOT similar to any
other HDA assembly out there unlike that found in the Profile which uses the
ST506 and ST412 assemblies from Seagate.
2: Digging through Apple's patents there's paperwork outlining the design of
the drive which was voice coil and not stepper motor MFM like everyone else.
It /might/ of been assembled in-house (there's no markings saying another
factory did it so they might of actually run a clean room for HDA assembly)
but it was obvious they designed the drive.
-John
Hello there to the list,
can any of the DEC-enthusiasts help me out in identifying what seems to be a front panel / door from DEC?
It was part of a lot with RK07 drives, but this panel does not fit into any of the RK07 cabinets.
http://classic-computing.dyndns.org/DEC_doorpanel/
Thanks alot for your help,
Pierre
?
-------------------------------------------------------------------------------
Pierre's collection of classic computers : http://classic-computing.dyndns.org/
>
> >
> > I need to get a microphone for my podcast, and I've been advised that the Blue Yeti is what I need. So to come up with the $130 or so, I've got a lot of five Toshiba 610CT laptops for sale.
> > Or trade if you have that mic.
> >
> > The lot is five laptops, four work, one does not. They are Pentium 90s, with 40 MB of RAM. Couple of different drive sizes, 1.2 GB, 800 MB, etc.
> > Lot comes with one docking station, couple external floppy drives, an external CD-ROM, 7 or 8 power bricks, a couple of VGA adapters. Some spare parts like keyboards and keycaps and spare RAMs. Also included are PCMCIA modems and Ethernet combo cards.
> >
> > If anyone is interested I can give more detail.
>
> What's the type of display?
Toshiba says they are 9.5 inch "True Color" TFT screens.
Hi! There are some XT-IDE V2 PCBs available if anyone would like some.
They will cost the same as before ($12 each). However due to unforeseen
extreme price increases in shipping by USPS I am forced to change shipping
costs.
Shipping in the US will be $3 for a single PCB and $2 for each additional
PCB. Shipping internationally will be $10 for a single PCB and $3 for each
additional PCB. This is for the bare basics USPS first class postage with
no tracking or insurance. The builder assumes all risk of delivery as per
usual arrangement.
I apologize for the large price increase on shipping but this is out of my
hands. The USPS is in dire financial trouble and is raising prices on
shipping. It affects us all and is most unfortunate. These boards are
provided "at cost" so there is no margin to absorb any shipping price
increases. I have to pass them along.
If you would like one or more XT-IDE V2 PCBs please send a PayPal to
LYNCHAJ at YAHOO.COMhttp://www.vintage-computer.com/vcforum/showwiki.php?title=XTIDE+Rev2
There are about 10 XT-IDE V2 PCBs left.
Thanks and have a nice day!
Andrew Lynch
I need to get a microphone for my podcast, and I've been advised that the Blue Yeti is what I need. So to come up with the $130 or so, I've got a lot of five Toshiba 610CT laptops for sale.
Or trade if you have that mic.
The lot is five laptops, four work, one does not. They are Pentium 90s, with 40 MB of RAM. Couple of different drive sizes, 1.2 GB, 800 MB, etc.
Lot comes with one docking station, couple external floppy drives, an external CD-ROM, 7 or 8 power bricks, a couple of VGA adapters. Some spare parts like keyboards and keycaps and spare RAMs. Also included are PCMCIA modems and Ethernet combo cards.
If anyone is interested I can give more detail.
Thanks,
Brad Arnold
President & Cofounder, Atlanta Historical Computing Society
http://www.ATLHCS.orghttp://www.AtariPodcast.com
I know of only one example of a debugger which supports
a Program Counter History Log.
I am in the process of adding a Program Counter History Log
to the System Debugger in RT-11 on a PDP-11. I would
appreciate a few suggestions from anyone who has any
experience with a debugger program which supports
Program Counter History Logging.
For users who are not familiar with PDP-11 hardware,
the primary interface is a serial terminal, usually with
9600 baud these days (don't laugh - I first started on
a PDP-11 around 1975 over a 300 baud modem), with
a screen of 24 lines by 80 columns. There are a probably
a VERY, VERY few systems which use VT420 terminals
which can support 48 lines, but which are probably rarely,
if ever used with other than 24 lines by 80 columns. From
my point of view, the primary considerations are the lack
of both speed (9600 baud takes seconds to fill a full screen)
and available screen space to display more than about 200
addresses from the History Log Buffer (at 10 addresses
per line). While I normally use the Ersatz-11 Emulator for
the PDP-11 which provides me the possibility of using
screens of 50 lines, I suspect that I am presently the ONLY
person to interact with RT-11 using a screen of this many
lines, let alone the speed of the screen which is so fast that
the time between SCROLL and NOSCROLL is usually
a dozen lines of output to the screen. At 9600 baud, the
SCROLL vs NOSCROLL time delay is only a few
dozen characters at most, certainly less than one line
of output to the screen in almost all cases.
The only experience I have with a debugger which has a
History Log is with a 64 word buffer of addresses for
the 64 immediately previous instructions. While this is
often sufficient to at least pinpoint the general location of
where the program stopped, it was often insufficient to
locate where the problem started.
For those who have direct PDP-11 experience, the
following information might also be useful. At present,
there are two buffers which can be displayed:
(a) A buffer with 40 of the last interrupt entries to SD:
which are composed of 5 words each:
- Program Counter Address from the Stack
- Program Status Word from the Stack
- Word (instruction?) at that Address
- Word (instruction?) at the Previous Address
- Control Word which is used by SD: (PROSNG)
(b) A buffer with the last 1000 Addresses of the last
1000 instructions that have been executed
The current logic in the code to save each instruction
address in the 1000 word buffer ONCE and ONLY
once uses all five of the above values.
There seems no point in displaying all 1000 addresses
since only about 200 can stay on the screen and it takes
too long in any case. However, just how useful are the
past 1000 addresses as an aid in debugging? Since it
takes no additional time for a larger circular buffer over
a smaller circular buffer (in fact maybe a larger buffer
is insignificantly faster) and there is memory available,
I opted for the largest buffer that was reasonable
The other buffer with the 5 word entries entries for
the last 40 interrupts will be used when there are any
questions about the exact details of any interrupt with
respect to a user having set a Breakpoint or any other
logic errors in the debugger in general and specifically
when adding addresses to the 1000 word history log.
NOW finally, here are my questions.
Are there any suggestions as to how many previous
instructions are needed to usually be helpful to have a
log for when a program has a problem? Also, would
it be useful to have the first word (two bytes) of the
instruction as well as the address in order to identify
the actual instruction or is the address almost always
sufficient? On the PDP-11 with instructions being
1, 2 or 3 words, it is totally unlikely that having the
addresses of the previous instructions would ever
allow a user to confuse which code was previously
executed unless two variants of almost identical code
had been purposely constructed so as to confuse the
user. This could occur when two overlays use the
same addresses to execute that code, but it is almost
impossible to happen by chance and even it it did,
an extra NOP could simply shift the code for one
of the variants so as to avoid the confusion.
Jerome Fine
At 12:00 -0500 8/27/13, Jerome Fine wrote:
>Are there any suggestions as to how many previous
>instructions are needed to usually be helpful to have a
>log for when a program has a problem?
Jerome,
hopefully you'll get much better-qualified answers than mine;
I have little to no experience programming assembly or PDP-11. That
said, I can think of a few possible answers:
1) enough instructions that any timing-critical loop will be captured
when an external interrupt dropping into the debugger is generated.
This might be relatively short - 200 instructions or so? User
(not necessarily programmer?) would set up and start a long
calculation (mandelbrot set, whatever) and then hit "break", and be
able to look back far enough to verify that the correct sequence of
instructions is repeating over and over.
For actual number, maybe look at the longest loop in RT-11
that repeats many times successively?
2) enough instructions that any timing-critical *subroutine" will be
captured when dropping into the debugger.
This would be a *lot* more, depending on application. In this
case, the programmer would add a break point to the code right after
the timing-critical routine (disk access, real-time control interrupt
service routine, whatever) and then look back at the buffer to verify
that the whole routine took the correct execution path. For disk
access, that might be a *lot* of loops, though, so maybe you are only
capable of writing a buffer to hold the last few iterations?
For actual number, look at the longest single executable code
unit in RT-11?
3) Configurable depth, configured at launch time for debugger
Programmer gets to make the trade between debugger buffer
depth and available memory for his program.
Not sure any of this is helpful, and you probably have
thought of it anyway.
--
- Mark 210-379-4635
-----------------------------------------------------------------------
Large Asteroids headed toward planets
inhabited by beings that don't have
technology adequate to stop them:
Think of it as Evolution in Fast-Forward.
