test-drb February 2014

test-drb@ccmp.vtda.org

191 participants
208 discussions

by bob＠jfcl.com

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. Thanks, Bob

9 years, 10 months

Replacing head on a Rk05j

by cramcram＠gmail.com

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). Any ideas? 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 the disk. 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 heads. 1. How hard is it to mount the head in the tongue? Looks like just 2 screws. 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. Marc

9 years, 10 months

altair tapes

by tdk.knight＠gmail.com

apears a vtr machean has come up with tapes on programes ur altair anyone interested in it noticed it on my local buy and sell site http://www.kijiji.ca/v-electronics/winnipeg/panasonic-vtr-nv-3020-with-15-r…

9 years, 12 months

Apple Lisa, for those that asked

by sales＠elecplus.com

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?) Cindy Croxton Electronics Plus 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

10 years

6809 SBC

by lynchaj＠yahoo.com

http://classiccmp.org/pipermail/cctalk/2010-January/282022.html 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 :-) -tony 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. http://n8vem-sbc.pbworks.com/browse/#view=ViewFolder&param=m6809 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! Andrew Lynch

10 years

WTD - 40-track (360K) 5.25in floppy drive

by classiccmp＠philpem.me.uk

Hi guys, 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. Thanks, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

10 years, 1 month

Transporting a Data General Nova 3 System

by nf6x＠nf6x.net

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: http://www.vintage-computer.com/vcforum/showthread.php?41477-Transporting-a… 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> http://www.nf6x.net/

10 years, 1 month

TI-99/4A acquisition

by terry＠webweavers.co.nz

I'm not sure how many on this list are interested in cheap home computers of the early 1980's but anyway...my crowded collection space is now even more challenged! Nice to have an example of this one though. Here is how I got it: http://www.classic-computers.org.nz/blog/2014-02-22-ti99_4a-reconstituting.… and here is how I've described it on the collections page: http://www.classic-computers.org.nz/collection/ti99-4a.htm Terry (Tez)

10 years, 2 months

PDP 8/e, RK8E Weirdness

by rickb＠bensene.com

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 behave properly. 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 consistent. 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 tests. 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 request. 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, Rick Bensene

10 years, 2 months

FYI: Battle of Bletchley Park: TNMOC chief calls for review of museums' Mexican standoff

by woyciesjes＠sbcglobal.net

Battle of Bletchley Park: TNMOC chief calls for review of museums' Mexican standoff - Iraq dossier MI6 chief's 'Disneyland' plans blasted http://www.theregister.co.uk/2014/02/24/national_museum_of_computing_calls_… -- --- Dave Woyciesjes --- ICQ# 905818 --- CompTIA A+ Certified IT Tech - http://certification.comptia.org/ --- HDI Certified Support Center Analyst - http://www.ThinkHDI.com/ Registered Linux user number 464583 "Computers have lots of memory but no imagination." "The problem with troubleshooting is that trouble shoots back." - from some guy on the internet.

10 years, 2 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb February 2014