Does anybody have a source or replacement for LA120 DECwriter III ribbons?
I've actually got about 8 "new old stock" ones, still shrink wrapped, but
all that I've tried are pretty much dried out despite the shrink wrap. They
barely make a mark on the paper, even with the little print impression lever
cranked all the way up.
I recently acquired 3 RK05j's that seem to have spent time in a barn as
well as having been used by a heavy smoker. I thoroughly cleaned and
de-gray-foamed them as well as putting in new absolute filters.
The first one came up after cleaning with no issues. Works great.
Number two spins up but the initial seek emits a sickening "klang" as the
voice coil drives hard to the limit (yes, the graticule lamp is working).
The third drive initially had really ugly heads that never cleaned up to my
liking. I loaded a disk anyway and for about 5 seconds after the initial
head load all was okay. Then I heard the sound of the top head scouring
So I'm thinking of buying replacement heads off of eBay. Apparently these
are the heads but not the steel tongues that they mount on.
So I have some questions for anyone on the list who may have changed their
1. How hard is it to mount the head in the tongue? Looks like just 2
2. How hard is it to remove/replace the tongue assembly? Looks like it
mounts with a couple of allen screws.
3. How hard is it to align the heads? I don't have a CE pack so I'll just
have to use a pack that works okay on the other drive.
4. Any sage advice or whatever?
Thanks for any and all help.
The Apple Lisa is complete, does not appear to be screen burned.
Includes hard drive and floppy drive and keyboard.
Somewhat yellowed due to age.
Does NOT power on, no repairs attempted.
(Is there someplace else to turn it on, besides the white square button
above the keyboard jack?)
1613 Water Street
Kerrville, TX 78028
(830)792-3400 phone (830)792-3404 fax
AOL IM elcpls
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2805 / Virus Database: 2634/5952 - Release Date: 12/11/12
It always suprised me that hre BBC micro used the 6502 rather than the
6809. By the time the Beeb was designed, Acorn had made a 6809 processor
board for their System machines, so they must have had experience with
the chip. THe Beeb is nice, but a Beeb with a 6809 processor would have
been something else :-)
Hi! When I designed the N8VEM 6809 host processor it is loosely based on an
article I read for the BBC computer called "Dragon in the tube". I am not
very familiar with the UK microcomputers but apparently 6809 "coprocessors"
were fairly common peripherals on their Z80 and 6502 designs. I used a
similar concept for the N8VEM to allow its Z80 SBC to access the 6809 as a
"host processor" peripheral on the ECB.
One of the builders was able to get CUBIX running on the N8VEM 6809 host
processor using the Z80 as its "IO processor". However, I can see how the
implementation can get confusing because it is either a Z80 based system
with a 6809 coprocessor or a 6809 based system with a Z80 IO processor. In
reality it doesn't really matter but it's a matter of perspective.
The N8VEM 6809 CUBIX implementation allows the use of ECB peripherals like
IDE, video, floppy, serial, parallel, etc but it requires the Z80 to serve
all the IO based on 6809 commands. I added the 6809 IO mezzanine board
(power, ACIA, PTM, 2 VIAs, expansion bus) to give builders the option of
using the 6809 host processor as a stand alone computer or to add separate
IO to the N8VEM system when connected to the bus. The idea being to let the
6809 host processor interact with the outside world using its own IO and
only involve the Z80 when absolutely necessary.
The hardware seems to work OK but we'll see where the software goes. I
think with CUBIX the 6809 N8VEM system becomes a lot more practical. The IO
mezzanine fits on top of the 6809 host processor. You can see some photos
here. These are out of date but give a good idea. Recently I fitted an
improved serial cable and the nylon standoff hardware. Also the PTM seems
to be working and that's good.
I have many 6809 host processor and IO mezzanine PCBs so if anyone is
interested please let me know. This would be a great opportunity for anyone
who would like to do some 6809 hardware and software hacking.
I think the N8VEM 6809 host processor is the only system I am aware of other
than Dave's homebrew that is running CUBIX. There maybe some other homebrew
systems out there too I can't find them after some searching.
Thanks and have nice day!
I'm trying to get my hands on a 5.25in double-sided 40 tracks per side
"360K" floppy drive with the Shugart or IBM PC 34-pin connector (either
edge connector or pin header is fine). Does anyone have a spare they'd
like to part with? Slight preference for Teac or Mitsubishi, but
anything will do at this point.
I've checked Ebay, there are tons in the US (complete with "seller does
not ship internationally, don't even ask"), but the only ones I've seen
>from UK sellers are parts scalpers wanting stupid money for them (?149
"sold untested with no guarantee"? really?).
A BBC Micro 40-track drive would also be fine -- as long as it's native
40-track, not 40/80 track switchable or double-stepping (an 80-track
drive mated to a PCB which double-steps the head). Cumana, Viglen and a
few other companies made these, they were extremely common a few years ago.
I'm on the verge of getting DiscFerret write support working (at least
for UNIX PC disks) but the sodding thing won't read anything my 80-track
drives have written!
I'd rather not borrow the 3B1's drive - the DiscFerret is experimental
and a benchtop lashup is hardly an ideal scenario.
classiccmp at philpem.me.uk
I'm picking up a Data General Nova 3 system with a removable-pack hard disk drive this weekend, and I would like to learn whether there are any shipping locks that should be engaged before I move the drive.
I have some limited experience with DEC RL02 disk drives, which use the same style of removable cartridge and look very similar overall. The RL02 drives have a little metal plate which is supposed to be rotated to lock the heads in the parked position before moving the drive. It seems logical to me that the Data General drives may have a similar locking mechanism.
I have posted a few pictures of the system over in a VCF thread:
I'm pretty much rescuing the system the way a crazy cat lady takes in stray kittens. If somebody in the Los Angeles area is really lusting for a Nova 3 system, I'm willing to put you in contact with the seller so you can make him a better offer. I have way too many projects already... ;)
The same seller also has a PDP-11/03 in a DEC cabinet along with an RX02 that I'm picking up as part of the package. Same offer applies: If somebody wants it more than I do, I'm willing to step aside and hook you up with the seller.
My offer to the seller is pretty low, and I've told him how much more money he might make if he's willing to go to the effort of listing it on eBay, dealing with packing and shipping, etc. (i.e., I'm really not trying to take advantage of him). He accepted my offer because he wants them gone, and he wants them to go to somebody who will appreciate them and not tear them apart for parts and scrap value. So, somebody who lusts after one of these systems probably wouldn't need to sell too many kidneys to outbid me on them. :)
Mark J. Blair, NF6X <nf6x at nf6x.net>
I'm hoping that someone here has some experience with PDP 8/e with the
RK8E disk controller for RK05 disk drives.
The 8/e passes all of the CPU diagnostics with flying colors. Memory
also checks out good. There are two fields of 4K core, and 4 fields of
solid state memory.
The core fields are field 0 & 1. Memory testing on both of the core
memory fields shows no faults. The system runs very cleanly...I've got
OS8 V3D on floppy and it can run for hours on end with no problems.
I have a known good RK05 drive and a number of 16-sector packs for it
that are good. RK8E and drive were tested in another 8/e system
recently, and worked fine.
Cable between RK8E and drive has been ohmed out, and it's good. Signals
going across the cable look good and clean on the scope.
The RK8E does not pass the Diskless Controller test in my system.
This is the test that uses the maintenance mode features of the RK8E to
test the controller without actually touching the RK05 drive (drive is
powered on, but in LOAD (offline) state). It goes though most of the
test, but fails in the data break tests. In these tests, the data break
is only active for one cycle, where one word is transferred to/from the
controller and main memory. All of the tests of the RK8E data buffer
test out fine. So, it appears that something is amiss in the
single-cycle data break handing...either in the RK8E, or the CPU's
handing of data break requests.
All data transfers between the RK8E and the PDP 8 are done via single
cycle data break (DMA) operations.
If I use RKLFMT to format a pack, it goes completely through the "write"
portion of the formatting without a hitch, and gets through a lot of
reads, but fails partway through the verification pass. The formatter
writes the block number of each sector as the first two words of each
sector, and fills the rest of the words with zeroes. The verification
pass just checks these two words to make sure they match. If fails when
the first word (high order disk address) changes from "0000" to "0001".
Through all of the tests, there are NO CRC errors. Seeking cylinders
and sectors work fine. It's just the "data" part of disk blocks that
gets messed up.
Using the FUTIL utility, I can successfully read and write blocks all
over the disk. I can use the "SCAN" function of FUTIL to scan the entire
disk, and it completes successfully. Thus, every sector on the disk can
be "found" by the controller without problem.
The problem symptom is that the first word of every block is duplicated
across all of the blocks. All of the rest of the words in the blocks
Using FUTIL, I can read in a block, change any but the first word in the
block, and write it out, then read it back, and it's fine. I can do
this with words 1 through 255 of any of the blocks on the disk.
However, if I read in a block, change the first word (word 0) of the
block, and write it out, then read it back, the first word is as I set
it to be -- but, if I read any other block, the first word is always the
same as what I wrote out.
For example, if I read in block 7, and change word 0 of the block to be
"4567", then write it out, then read any other disk block, word zero
will ALWAYS be "4567". If I then read in block 275, and modify word 0
to be "1234", and write it out, and then read back ANY (including block
7) disk block, the first word will always be "1234". I've tried this
with all different bit patterns for in word zero, and it's always
To verify that this isn't an issue with FUTIL, I wrote some little
routines to read and write disk blocks, and the behavior is the same.
The other disk test that uses the drive goes through all of the seek
tests and writes out its test patterns, but fails on the read-back
I'm very stumped. The RK8E uses single-cycle data break (DMA) to take
data to/from the disk and transfer it directly to/from main memory
without processor intervention (other than initiating the conditions for
the DMA cycle). The RK8E signals the processor that it needs to do a
data transfer, the processor relinquishes control of the memory system,
and lets the RK8E place address and data on the memory address bus and
memory data bus to read/write the data from/to main memory. Each word
of the transfer of a 256 word disk block is done as a separate DMA
One might thing that there is a problem with the RK8E, but that is not
likely, as this RK8E was recently tested in another system and worked
fine, passing all of the diags.
It's more likely that there is something amiss in the data break logic
in the CPU, however, it seems odd that it would affect only the first
word of a DMA transfer, as the CPU doesn't really know whether a DMA
transfer is the first word or the last word. It just responds to DMA
requests asserted by the peripheral.
Does anyone out there have any ideas what I could do to track this down
further? The RK8E is the only data break device I have in the system,
everything else uses programmed data transfers, so I can't try with
another data break device and see if the behavior is consistent.
Thanks in advance for any ideas as to what to do/try next,