Hi,
I am trying to get my 9825A to exchange programs, data with the
outside world
and I am not making any progress.
The 9825A has a working tape drive, but as I only have Series 80 stuff
here
(which use the same tapes, but different formats), this only allows me
to
save/restore my own stuff.
The 9825A also has an HP-IB interface (thats the only interface I've got
for it), but I have trouble connecting a floppy drive to it as the mass
storage ROM that supports HP-IB drives only works with the 9825T.
Bummer!
I have the System ROM which allows ASCII programs to be"typed"
>from an external device, but I would like to be able to have access to
the program collections available on floppy images (e.g. the files on
the diagnostic tape).
So any ideas - suggestions?
Thanks
**vp
www.series80.org
...and tricking the computer into thinking it's a 5.25" hard sectored
disk...in an H8..
[This is from the sehbc Heathkit list - I figured there may be some
interested in what he's done]
-------------------
On Friday (04/17/2009 at 07:12PM -0700), dwight elvey wrote:
>
> Hi Chris
> How did you solve the problem of the speed changes
> while the disk is spinning? Several people have tried
> to do this so we are all wondering.
> Also, have you checked several different drive
> manufactures. Each has a little different quality
> of speed control. Most all 3.5s are crystal or resonator
> controlled so the average speed is usually right on
> but the speed caqn drift from revolution to revolution
> around that value.
Hi Dwight...
I will admit that this little project took a lot more effort than I
initially expected-- and Carroll W can confirm that!! We were both
working on the problem from different directions. He provided a lot of
info in the beginning which laid the ground work for me.
I use an ATMEL ATTiny2313 microcontroller and make heavy use of one of the
timer/counter units. I have the counter running at 8 MHz/64 = 8uS period.
Then, each time MOTOR ON goes true, I waste two revs of the media
"figuring things out". The first rev is completely ignored as I assume
the media is probably not up to speed yet. The second rev is used to
calculate the speed of the media. I count the total number of 8uS ticks
that occurred over that rev, divide by 200 (one rev should take 200mS)
and the result is the number of ticks per mS in "floppy time".
I then use this value to stage the pseudo pulses starting at the next
real index pulse.
The code is as simple then as,
PulseAt00();
PulseAt10();
PulseAt10();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
where each of those is a simple delay that counts the number of ticks
of the timer/counter to equal the required number of milliseconds and
then it generates an index pulse. The timing is done in the hardware
by the timer/counter unit and I am simply clearing and then polling that
counter to determine when its the right time to move on.
I have tested with three different brands of floppy drives. Two were
a success and one was an abysmal failure. Sony MPF920 work real nice.
Teac FD-235F also work great and Samsung SFD-321B are useless-- because
they have made them so cheap that they do not even support 720K media
any more. The density sense switch is completely missing from the drive,
and they are forced to always run in 1.44M (500kbps MFM) mode. That's a
show stopper since for the H-17/H-88-1 we need 250Kbps MFM mode which is
what 720K 3.5" media uses. I use 1.44M floppies but then cover up the
high-density hole with a piece of tape, which makes them 720K media then.
Anyway, I did a lot of testing... a lot of scoping-- with my digital
scope and logic analyzer and I'm pretty confident this is a reliable
solution. The success with "TEST17" on HDOS was the final sign-off and
that is consistent now with either of the good drives and exchanging the
media between them.
I make no attempt to support multiple drives with one microcontroller--
because they are so cheap, I just put one per drive and then I don't
have to manage state tables for more than one, etc.
I just use the RC oscillator as the clock for the micro too-- so there's
no crystals or osc to wire up. Since it recomputes the tick counter
each time the motor turns on, if the processor clock has drifted, that
gets accounted for in the recalculation-- but my experience is that
these AVRs are pretty stable across typical room temp conditions anyway.
I think the thing that stumped me the longest was that I was not
disabling my INDEX output fast enough when the drive was deselected.
I ended up with a 74LS38 external to the micro to solve this problem--
which then also gives me lots of drive back to the controller and a true
open collector output which can be bussed on the floppy cable just like
any other drive.
Chris
--
Chris Elmquist
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To post to this group, send email to sebhc at googlegroups.com
To unsubscribe from this group, send email to sebhc+unsubscribe at googlegroups.com
For more options, visit this group at http://groups.google.com/group/sebhc?hl=en
-~----------~----~----~----~------~----~------~--~---
Hi All,
Just put my IBM 5150 w/ 286 accelerator on eBay if anyone is
interested in one.
Item # 300309315276
Rob
Rob Borsuk
email: rborsuk at colourfull.com
Colourfull Creations
Web: http://www.colourfull.com
Queen Bohemian Rhapsody Old School Computer Remix
Atari 800XL was used for the lead piano/organ sound
Texas Instruments TI-99/4a as lead guitar
8 Inch Floppy Disk as Bass
3.5 inch Harddrive as the gong
HP ScanJet 3C was used for all vocals.
http://www.youtube.com/watch?v=Ht96HJ01SE4
"Rik Bos" <hp-fix at xs4all.nl> wrote:
> It's fun to look at the HP-IB(us) the display flickers nice, but is
there
> realy meaning full use for these analyzers ?
I have one of these as well. Mine is in excellent condition.
I did use it to debug an HP 59309A Digital Clock and it was quite
useful (although without the service manual for the 59309A I
wouldn't have gone far).
I also used the HP 59401A to help me understand the
Amigo protocol for a floppy emulator.
So its useful, but its slow and cumbersome (its fun
entering HP-IB commands using the switches on the
front when playing around, but for recurrent and complex
tasks you'd rather use a computer).
You can't even leave it connected to the HP-IB bus
all the time, because it slows it down and causes
some devices to complain.
Nevertheless its a great addition to any "blinkenlights"
display.
**vp
www.series80.org
For Rik and anyone else who's still folling the saga of the HP120
keyboard, I've now hacked an HP150 keyboard to make it HP120-compatible.
Here are some details...
As we all know by now, the HP150 keyboard has the right interface to
plug into an HP120, it's just that the keys are sent in the wrong order.
The scanning is done by a 4024 7 bit counter inside the keyboard, my idea
was to replace with with a circuit that was essentially a counter with a
non-standard count sequence to select the keys in the order needed by the
HP120. And the obvious way of doing that is simply a 7 bit counter
followed by a ROM acting as a lookup table to do the code conversion.
Of course it's not quite as simple as that (things never are!). The main
problem is that HP120 keyboard runs at 12V internally (it's all
4000-series CMOS logic chips). And most common EPROMs run at 5V.
I ended up with a board containing 5 chips and a 7805 voltage regulator.
This links by a short length of ribbon cable and a 14 pin DIL header to a
socket which I fitted in place of the scan counter chip (a 4024 at
location M2) on the HP150 keyboard PCB. All the new chips run off the 5V
output of that 7805. Here's a brief circuit description :
2 sections of a 4050 hex buffer takes the clock and reset signals from the
HP150 keyboard PCB (these are the signals that would have controlled that
4024). It doesn't seem to be generally known (but it's in all the data
sheets I've looked at) that the 4050 (and its inverting brother the 4049)
can take inputs up to 15V even when run off a lower supply voltage. They
are intended for level-shifting from CMOS voltages to TTL. And unlike the
older 4009 and 4010 (which they replace) they only need the 5V power line,
not a second power line corresponding to the input voltage.
The outputs of that buffer go to a 4024 7 bit counter in the obvious way.
The outputs of that go to the bottom 7 address lines (A0...A6) of a 27C64
EPROM. A7 goes to a switch and pull-up resistor so I can select between 2
key mappings (HP120 and HP150 mode). The remaining address lines, CE/ and
OE/ are all grounded. Why use such a large EPROM? It was the first CMOS
one I found in the junk box :-).
The outputs of the EPROM are, of course at TTL levels, and need to be
level-shifted back to 12V to drive the CMOS logic in the keyboard. I used
7 sections of 74LS07 (so 2 packages total) with 3k3 pull-up resistors to
+12V
The EPROM cotnains 2 128-byte tables. The first one (locations 00-7f)
gives the remapping for the HP120 mode. The second one (locations 80-ff)
cotnains the values 00-7f in order, thus keeping the keys in the original
sequence for the HP150 mode.
Anyway, I soldered it up. I worked out the correct data for the first
half of the EPROM, I programmed the EPROM. And I tried it out.
Most of the keys worked correctly, but some, including f8 did nothing.
While fiddling around, I found f8 _sometimes_ worked. Oh great, I've got
an intermittant fault.
So I grabbed the LogicDart. While looking at the scan drive signals (the
outputs of the 74ls07s), I noticed some glitches on some of them,
doubtless due to the fact that the 4024 is a fairly slow ripple counter.
Thinking that was the problem, I decied that maybe a 74HCT4024 would
help. Alas my junk box doesn't contain much in the way of HCT chips, but
I did find a 74HCT4040 which is a 12 bit ripple counter of a totally
different pinout.
One header plug, One DIL socket, and lots of wire later and I'd kludged
up an adapter. Plugged it in. No change. Glitches still there, f8 works
intermittantly. I did discover (by comparison with the HP262x keybaord
I'd already got working) that the effects of some keys are not noticeable
in 'Local' mode unless you turn 'Display Functions' on (this displays
control codes on the screen rather than executing them). I did this and
found that essentially only 2 keys on the HP150 keybaord were dodgy. Hmmm
Finally I put the LogicDart on the signal I should have looked at in the
first place -- namely the data line back to the HP120. And I found that
when the key didn't work, there was nothing on that line. No glitches,
just nothing.
The output of the scan decoder (4028) in the HP150 keyboard was hehaving
correctly, as far as I could tell, all the time. The input to the row
multiplexer (4051) wasn't. Between them, of coruse, are the key switches
and their diodes.]
And yes, you guessed it. The dodgy keys had dodgy keyswitches. All my
hackery was working find. Dismantling the keyboard assembly (lots of
little screws), a squirt of contact cleaner, and it seems OK now.
All I have to do is box it up. The new board will have to go in a plastic
box screwed to the top of the keyboard. But I want to get things just
right before I start drilling holes.
-tony
> -----Original Message-----
> From: Andrew Lynch [mailto:lynchaj at yahoo.com]
> Sent: Friday, April 17, 2009 10:29 AM
> To: 'cctalk at classiccmp.org'
> Subject: home brew S-100 backplane project
>
> Hi!? I've been working on a home brew S-100 backplane as a side project
[snip]
Hi! The experimental prototype S-100 backplanes will be available in about
3 weeks. They will cost $32 each plus shipping which should be $2 in the US
and $5 overseas. All the parts are common and available from the usual
suppliers such as Mouser, Digikey, etc.
Thanks and have a nice day!
Andrew Lynch
I'm looking for install CD images for HP-UX 10.30, 10.20, and 9.X (series
700), and also Digital Unix 4.0X. If anybody has one of these and is
interested in getting CD images for Tru64 5.1A or HP-UX 11i v1 in trade,
please email me off list. Please note that 5.1A won't install on DEC 3000,
as far as I know (certainly won't on my 3000 model 300).
Thanks,
John
I'm doing some classic Mac development and one of the projects I'm trying
to update requires at least MetroWorks CodeWarrior Pro 4 or higher (I
presume 5 or 6 would also work for Classic MacOS). Anyone out there getting
rid of this, would be willing to sell theirs, or know where I can purchase
it? Metroworks seems to have been bought out by Freescale and they don't
offer any of their old MacOS development tools anymore.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Roger Waters to moving crew: "Hey! Careful with those racks, Eugene!" ------
--- On Sat, 4/18/09, Gordon JC Pearce MM3YEQ <gordonjcp at gjcp.net> wrote:
> Bit of an odd one this, rescued along
> with a Seiko graphics tablet (but
> no puck) and a 15" rather nice Sony monitor that needs
> 110V.
>
Certainly would be unusual. IIRC, Shima Seiki made their name in CNC circular knitting machines (that is, CNC machines that could knit tubular shapes like socks and gloves) and were in that field for many years, and according to their web site they still are around.
The machine you have could have been a fabric design workstation although by the time of the 286 and 68000's Shima had branched out into more general purpose 2D CAD and paint systems. The company I worked for in the late 80's had 14 HDTV versions of the Shima Seiki paint system in the UK and Germany, and one low-res version which I think may be similar what you have found. I looked after them for a couple of years. They were certainly multi-processor in nature. I believe these were among the first NHK (analog) HDTV systems installed in Europe, using Sony HDTV monitors, and we established quite a close relationship with Sony Europe as a result. We were all terribly excited because Industrial Light and Magic also had a couple of Shima Seiki systems. These days of course they'd be old hat but in 89/90 they were quite something.
-Dave
