test-drb December 2002

test-drb@ccmp.vtda.org

250 participants
519 discussions

by foo＠siconic.com

Ok, so far so good. I've got my wire harness all wired up (I basically used a good quality 40-pin DIP socket: the signal lines going into one side and the returns on the other). Nothing fancy required. The reader is putting out TTL signals so all is good. One oddity: before hooking anything up, I measured the voltage between the Apple's ground and the reader's ground. It would start off at a very low amount of microvolts, climb slowly, then all of a sudden it would shoot to +5 and then go back down to 0, where the cycle would repeat. The cycle period was about 5-6 seconds. What the heck is going on? I tested it out with the indicator signals, i.e. BSY (Busy), HCK (Hopper Check), MOCK (Motion Check), Error, etc., and the VIA is getting the signals. I wrote a little program to print out the status bits of the port that is accepting the signal and ran a batch of cards through and everything is as expected. The next step is to wire in the data signals and start to read data. The VIA gives me two 16-bit ports and an additional 4-bit port. The 4-bit port is special in that it can generate interrupts, so it will work quite well for error signals. The problem is I don't know how to access that port through the card I have. It's a custom 6522 card that I built for a class on microcomputer interfacing I took a lifetime ago and I can't find my class notes. Anyway, I'm in the process of figuring it out. Everything on the card is accessed through it's I/O addresses, being C080 + (slot * 16). So I have it in slot 4 which makes all it's I/O available at C0C0-C0CF. I've found the timer locations and some 16-bit registers. I also found by accident a timer that generates a RESET interrupt when it elapses--at least that's the theory I'm going under since the Apple reset itself after I was playing with the registers. I also believe I remember there being this feature on the 6522, but I haven't had a chance to read that part of the docs yet. One thing I'd like to investigate after I'm done with this is to see if there are enough inputs on the Apple itself to forgo the necessity of the 6522. The Game I/O port has 7 inputs, if you count the 4 joystick inputs that can be used as simple TTL inputs, plus the 3 push-button inputs. The other inputs would be the keyboard. It has 10 Y-inputs and 6 X-inputs, plus SHIFT and CONTROL. I'm wondering if there would be a way to hook up the data signals from the reader in a way that the character data from a card column triggers a key input, which can then be cross-referenced to determine what data was actually sent from the reader. Whether this will work depends on how punch card encoding works. From what I can tell so far, there will only ever be one of the 1-9 numbered rows punched per column, but there can be any combination of the 0, 11, and 12 rows. Is this correct? If so, then there should be enough combinations of inputs on the keyboard port to allow the data signals to go through that, and then the GAME I/O has just enough inputs to cover all the status signals (HOPPER CHECK, MOTION CHECK, ERROR, BUSY, INDEX MARK, and READY). Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org * Old computing resources for business and academia at www.VintageTech.com *

21 years, 12 months

Anyone have a Western Digital XT-IDE hard card or ROM image?

by erd_6502＠yahoo.com

I've been trying to extract the data off of a 20MB XT-IDE drive (WD-93024X) that was once part of a hard card. It has the software for my B&C Microsystems UP600 device programmer. Too many swaps and not enough sleep later, I have inserted the card in backwards (no bracket and it's an 8-bit card). It's now DOA. The Compaq Portable II I'm using complains of an I/O ROM error. So... I can check/replace any of the TTL on the card (74LS13, 74LS14, 74LS244, 74LS30, 73LS260), but the contents of the 2764 are possibly lost to me. Does anyone have a ROM image or an old XT-IDE hard card? The P/N on the ROM is 62-000352-031. The assy no. on the PCB is 60-000227-03, the P/N appears to be 61-000347-01. No smoke got out, but it sure is unhappy. Thanks for any assistance. -ethan __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

21 years, 12 months

Anybody need a Telex FC500 keyboard?

by classiccmp＠crash.com

Anybody need an old Telex keyboard? The closest I could come to a model number was "FC 500" from a label on the underside. More or less normal pre-PC QWERTY keyboard, with a bunch of editing keys in the cursor cluster to the right. It's on a discount table at the MicroCenter in Cambridge, MA. If you really want this and will pay shipping, I'd be willing to go back for it. Probably $1.99, but I don't recall seeing it marked. I picked up a couple of Sun type 5c keyboards while I was there, since they have the control key where g*d and nature intended (just left of the "A" key). If you want such a beast for $1.99, check your local MicroCenter (www.microcenter.com) - matching Sun mice for $0.99, optical or mechanical. Dunno where they're coming from, but they've been there since before Thanksgiving. --S.

21 years, 12 months

Restoration Question

by dwightk.elvey＠amd.com

>From: "J.C.Wren" <jcwren(a)jcwren.com> > I have recently acquired a couple of build PC boards that are not solder >masked. There is some oxidation, ranging from minimal to mild (mild being >the not quite green, but a very hard oxide, as if the tin had reacted with >something else). Anyone got any good ideas on cleaning these? I'd like >something non-submersible, since one of the boards contains keyswitches. > > I have plenty of experience cleaning unbuilt boards. Normally, I'd just >hit them with some super fine steel wool, or buff them with 20lb paper. And >I've repaired boards, but usually to get them working, not to restore their >aesthetic appeal. > > I've considered using a baking soda solution and a stiff bristle brush. >This should neutralize any corrisive elements, and the baking soda might be >abrasive enough to remove the oxides without damaging the board. It would >wash off easily enough with water, and I could protect the switches during >that process. Hi Baking soda assumes that it is acid that caused the corrosion. If it was caused by leakage from NiCads, you'll need to use something like vinegar to neutralize it. You might try getting a fiber glass brush from a welding shop. These are sometimes used to clean aluminum. Sometimes it isn't the copper that is oxidized. They put a layer of nickel between the copper and solder on most PC boards. It may be nickel oxides ( bluish green ). If there is any kind of salts ( neutral ) you'll still have electrolytic corrosion. You need to make sure that it is well cleaned before you are done, regardless of what you use. Dwight > > Anyone got any ideas or standard procedures for this kind of thing? > > --JOhn > > >

21 years, 12 months

6522 weirdity

by foo＠siconic.com

Ok, I've kinda figured out the control lines on the 6522. First of all, I've got them triggering a flag in the IFR whenever there is a state change on any control pin from a ground to either floating or +5V. For example, CB1 is plugged into ground. I reset the IFR (so no flags are set). I remove the ground from CB1. CB1's flag in the IFR gets set. I reset that flag. If I plug CB1 into +5V, I get no flag. If I unplug CB1 from +5V, I get no flag. If I plug CB1 back into ground, I get a flag. Why are the flags being set only when one of the control lines no longer senses ground? I tried playing with the PCR to see if setting whether the control pins are active positive edge or active negative edge changes this behavior but it doesn't. I can work with this the way it is: I'm basically tracking state changes on the control pins, which is fine for my purposes since the reader will go from TTL false to TTL true if there is an error, and back to TTL false when the error gets cleared. But I want to know how the behavior of the control lines is set. Now, I seem to have a problem with CA1. If I have CA1 connected to ground, it's stable. As soon as I remove it from ground and it's floating, CA1's state starts to fluctuate wildly for a little over 2 seconds. It's flag in the IFR keeps triggering over and over. If, right after I remove it from ground and it starts fluctuation, I plug it back into ground, it stabalizes (it stops changing states). As soon as I remove it again, it fluctuates wildly. Is CA1 tied to one of the 16-bit timers? It sure seems like it. The docs say something about being able to make one of the control lines trigger off a timer. Am I triggering the shift register somehow? What in tarnations is going on? Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org * Old computing resources for business and academia at www.VintageTech.com *

21 years, 12 months

6522 weirdity

by dwightk.elvey＠amd.com

>From: "Sellam Ismail" <foo(a)siconic.com> > >Ok, I've kinda figured out the control lines on the 6522. > >First of all, I've got them triggering a flag in the IFR whenever there >is a state change on any control pin from a ground to either floating or >+5V. > >For example, CB1 is plugged into ground. I reset the IFR (so no flags >are set). I remove the ground from CB1. CB1's flag in the IFR gets set. >I reset that flag. If I plug CB1 into +5V, I get no flag. If I unplug >CB1 from +5V, I get no flag. If I plug CB1 back into ground, I get a >flag. > >Why are the flags being set only when one of the control lines no longer >senses ground? I tried playing with the PCR to see if setting whether the >control pins are active positive edge or active negative edge changes this >behavior but it doesn't. I can work with this the way it is: I'm >basically tracking state changes on the control pins, which is fine for >my purposes since the reader will go from TTL false to TTL true if there >is an error, and back to TTL false when the error gets cleared. But I >want to know how the behavior of the control lines is set. > >Now, I seem to have a problem with CA1. If I have CA1 connected to >ground, it's stable. As soon as I remove it from ground and it's >floating, CA1's state starts to fluctuate wildly for a little over 2 >seconds. It's flag in the IFR keeps triggering over and over. If, right >after I remove it from ground and it starts fluctuation, I plug it back >into ground, it stabalizes (it stops changing states). As soon as I >remove it again, it fluctuates wildly. > >Is CA1 tied to one of the 16-bit timers? It sure seems like it. The docs >say something about being able to make one of the control lines trigger >off a timer. Am I triggering the shift register somehow? Hi What is the weird behavior? I haven't seen anything I wouldn't have expected. Dwight > >What in tarnations is going on? > >Sellam Ismail Vintage Computer Festival >------------------------------------------------------------------------------ >International Man of Intrigue and Danger http://www.vintage.org > > * Old computing resources for business and academia at www.VintageTech.com * > >

21 years, 12 months

M200 interfacing

by fmc＠reanimators.org

Sellam Ismail <foo(a)siconic.com> wrote: > 80 characters x 11 bits = 880 bits / 9600 bps = .092 seconds. Should be > no problem. I'll see what the manual says about timing between card > reads. Except that, if you want to read binary cards (trust me, you will -- those binary cards are contain boot and other code for these machines), you need to do all 12 rows. 80 columns x 12 rows = 960 bits / 8 bits per byte = 120 bytes per record. OK, now as for sending that over a serial line, remember that serial I/O adds framing information , so it becomes 10 bits per byte supposing 8 data bits, no parity, 1 start and 1 stop bit. So 1200 bits at 9600 bps = 0.125 second. You probably want to do at least a simple checksum of the data for each record and send that too (so the receiver can verify, send ack or nak, and the sender can retransmit on receipt of nak or just non-receipt of ack). You've got RAM in the Apple, use it as a buffer between the card reader and the serial port. 16KB would hold 136 full card images, which you might think would be more than enough time to tell the reader to stop picking cards and actually have it stop. So, when the buffer's fullness gets above some threshold, stop picking cards until it gets below some lower threshold. You may be able to do some cheap buffer- and serial-time savings by either run-length encoding or just keeping a record length and not storing or sending trailing blank (unpunched) columns. Depends on your data. I think I would go for this last. -Frank McConnell

21 years, 12 months

6522 weirdity

by pete＠dunnington.u-net.com

On Dec 30, 13:57, John Lawson wrote: > On Mon, 30 Dec 2002, Sellam Ismail wrote: > > > Now, I seem to have a problem with CA1. If I have CA1 connected to > > ground, it's stable. As soon as I remove it from ground and it's > > floating, CA1's state starts to fluctuate wildly for a little over 2 > > seconds. > > Try tieing it to +5 via a 10K resistor, so it's either solidly a 0 or > solidly a 1. Many digital chips get cranky when their pins 'float'. Yes. Worst example I came across was a CMOS circuit which was designed by an "expert". It worked on a breadboard, but when transferred to the final PCB it misbehaved and eventually died of "dead chip". It turned out that a couple of unused inputs were left unconnected and floating. On the breadboard, that wasn't a problem, because it was dirty and there was enough leakage (a hundred megohms or so) to keep them in a reasonable and constant state. But the PCB was waterproofed, and they really did float, eventually leading to excess dissipation in the chip, and destruction of one of the gates. The reason is that a CMOS gate is basically two MOS transistor switches, one connecting the output to the power rail, and the other connecting it to ground. If the input floats halfway between logic levels, both turn on (at least, in older devices), and the current destroys one of the MOS transistors. Another example was a TTL circuit that ran fine at low to medium frequencies, but not at several megahertz. Floating input again; that sort of thing has a drastic effect on the speed of the gate. -- Pete Peter Turnbull Network Manager University of York

21 years, 12 months

Selling my Transputer collection.

by tim.myers＠sunplan.com

A shameless plug for my Transputer collection that's now for sale on Ebay - hope nobody minds :) http://www.andale.com/gallery?cid=10192480&mid=1 Tim.

21 years, 12 months

6522 weirdity

by pete＠dunnington.u-net.com

On Dec 30, 10:30, Sellam Ismail wrote: > > Ok, I've kinda figured out the control lines on the 6522. > > First of all, I've got them triggering a flag in the IFR whenever there > is a state change on any control pin from a ground to either floating or > +5V. > > For example, CB1 is plugged into ground. I reset the IFR (so no flags > are set). I remove the ground from CB1. CB1's flag in the IFR gets set. > I reset that flag. If I plug CB1 into +5V, I get no flag. If I unplug > CB1 from +5V, I get no flag. If I plug CB1 back into ground, I get a > flag. You're sensing noise. The inputs are not level-sensitive, they're edge-triggered. If you have the PCR set to zero (which is the default after a reset), CB1's flag will set whenever CB1 sees a falling edge. You're probably generating small noise spikes when you remove the ground (this is a bit like key bounce) or picking up stray current (the inside of an Apple is a pretty noisy place, electrically speaking). This would explain why the flag gets set when you initially remove the ground from CB1, and then again when you ground it again. Without the noise, it wouldn't set the flag when you remove the ground, only when you restore it. > Why are the flags being set only when one of the control lines no longer > senses ground? I tried playing with the PCR to see if setting whether the > control pins are active positive edge or active negative edge changes this > behavior but it doesn't. Actually it does, but I bet you've not got pullups or pulldowns on the pins, and you're seeing noise. These pins are fairly high impedance. And because the inputs are edge-sensitive, the flag gets set not just because it's low (otherwise it would get set if it were low when you configure it, and you'd not be able to clear the flag) but because it *changes state* to become low. > I can work with this the way it is: I'm > basically tracking state changes on the control pins, which is fine for > my purposes since the reader will go from TTL false to TTL true if there > is an error, and back to TTL false when the error gets cleared. But I > want to know how the behavior of the control lines is set. See my post from a few minutes ago. > Now, I seem to have a problem with CA1. If I have CA1 connected to > ground, it's stable. As soon as I remove it from ground and it's > floating, CA1's state starts to fluctuate wildly for a little over 2 > seconds. It's flag in the IFR keeps triggering over and over. If, right > after I remove it from ground and it starts fluctuation, I plug it back > into ground, it stabalizes (it stops changing states). As soon as I > remove it again, it fluctuates wildly. Noise. Floating inputs are A Bad Thing. > Is CA1 tied to one of the 16-bit timers? It sure seems like it. The docs > say something about being able to make one of the control lines trigger > off a timer. Am I triggering the shift register somehow? > > What in tarnations is going on? Did I mention noise? :-) -- Pete Peter Turnbull Network Manager University of York

21 years, 12 months

← Newer
1
2
3
4
5
6
7
8
...
52
Older →

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 December 2002