Microbot TeachMover 6502 based Robot Arm, Memory Map

Dr Jefyll · Post by **Dr Jefyll** » Sat Sep 10, 2011 7:35 pm

falcon5252 wrote:

unless I'm in error here, Reset stays low from the time the power is turned on till the cap charges through the resistor and reaches the gate threshold of the 74LS14 at which time reset goes high and the cpu initializes..

Hmm, yeah.. I was looking at the photo, and I see the cap and resistor-&-diode near the 'LS14. So perhaps the reset circuit is simplified compared with what it really "ought" to be -- or maybe there never was any issue. I admit I'm starting to wonder if this limitation on RST-true time is some sort of misunderstanding, or whether perhaps it applied only to a tiny minority of early chips. The MOS data sheet here says nothing about it; my only info is from Garth's comment here:

Garth Wilson wrote:

The CMOS 6502's reset timing is not critical since it does not have the heating problem that the NMOS 6502 had whereby the uP could be destroyed if you kept the reset line true for too long. IIRC, the maximum recommended reset time on those was 50 or 100 ms.

My curiosity is piqued, since I don't see how RST would alter power dissipation. Can anyone elaborate on this? (I notice that the KIM-1 schematic includes a 556 one-shot IC as part of the RST circuitry. But it is wired in a way that merely effects a debounce for the pushbutton; it does NOT limit the maximum time RST is low.)

falcon5252 wrote:

Just wondering what the original problem was with the stepper code that made them have to invert the signal..

I wonder, too. And I could easily be mistaken. But, until a better theory presents itself, my bet is that they originally planned to use noninverting stepper-driver chips but had to effect a substitution. Yes this means their original design would briefly have had an all-coils-active condition at powerup, and that their '174 reset was ill-conceived, but lots of crazy stuff happens in this world. (I suppose an alternative explanation is that your board is a rare, early prototype. But the 74LS540 is a comparatively new chip -- pretty sure the only option would be an 'LS240 back when this design was developed.)

Thanks for keeping us posted on all this, falcon5252. I am following your project with interest -- and envy! Cheers,

Jeff
[Edit: additional detail re KIM-1 556 circuit: it is for debounce only]

falcon5252 · Post by **falcon5252** » Sun Sep 11, 2011 1:13 am

You may be right that they changed from non inverting to inverting .. But there is a 2 input gate on the input to the driver chip they could have just cut the trace on the paired input and held one input high,, Using it as a enable.. Yea well 6 of this and a 1/2 dozen of that..

I've been browsing all the different datasheets from the various 6502 makers and even the Mostek chip from 1975 mentions no limit on reset time ..
It must have just been the very early chips before they started cross licensing them... Seems most every manufacturer that bought rights to the chip made their own minor improvements over the original design... because mine is a Rockwell R6502AP 2mhz and that's prior to the CMOS version and the datasheet for it says just hold Reset low for at-least 2 clock cycles after the voltage reaches 4.75v,, The old Kim 1 and 2 were no doubt built before cross licensing started..

I think the problem with mine not starting is the reset cap is dried out and only reads 22uf on my meter when its a 47uf cap so its probably coming out of reset to soon.. I'm going to change the cap and add a reset button to short the cap through a 100 ohm resistor to add manual reset capability..

GARTHWILSON · Post by **GARTHWILSON** » Sun Sep 11, 2011 1:58 am

Quote:

I've been browsing all the different datasheets from the various 6502 makers and even the Mostek chip from 1975 mentions no limit on reset time .

It was a bug, and they don't write about those in the data sheet.

falcon5252 · Post by **falcon5252** » Sun Sep 11, 2011 2:12 am

The question is when and who corrected the bug.. Seems once they started putting manual reset buttons them you lose total control of how long reset can be held low.. It would have also probably been a high priority on their to-do list to fix the bug especially if they ever wanted to market to the aviation and military..

Dr Jefyll · Post by **Dr Jefyll** » Sun Sep 11, 2011 3:00 am

Apologies -- I had a closer look at the KIM-1 schematic and, although the RST wiring does include a 556 dual multivibrator IC, it is wired in a way that merely debounces the pushbutton signal. (See pg 26 of The KIM-1 User Manual.) It does NOT limit the maximum RST low time. I powered up my KIM

and verified this. So, we are left with very little info or evidence on the RST time limitation issue.

falcon5252 wrote:

You may be right that they changed from non inverting to inverting .. But there is a 2 input gate on the input to the driver chip they could have just cut the trace on the paired input and held one input high,, Using it as a enable..

The doc on these UDN5700 chips is faintly confusing, and I wonder if you've been mislead. Unfortunately there is no possible manipulation of the inputs that will change an inverting driver to operate as a noninverting driver, or vice versa. If you need to make such a change, your only options are to patch in an inverter somewhere or else switch to using the other type of driver. (It would be a different story if the input gate were an Exclusive-OR... )

Speaking of drivers, I still wonder if there's an inexpensive chip that's a reasonable match for the original pinout. Last time I checked (years ago!) there was a wide selection of 8-pin dual driver ICs available. I suspect that, with only minor jumpering of connections, a pair of these 8-pin duals could sit in the footprint of the original 16-pin quad driver .

-- Jeff
[Edit 1: sentence structure. Edit 2: link to KIM-1 schematic]

GARTHWILSON · Post by **GARTHWILSON** » Sun Sep 11, 2011 3:01 am

Just because you have a button does not mean you can't time the pulse to keep if from being low too long. There are plenty of ways to time it. One is what I suggested to Ritesh recently for his manual EEPROM programmer, because the PGM pulse has to be around 350ns long (in spite of the pushbutton):

The Commodore 64 used a 555 timer for this reason (actually half a 556) to make sure the RST\ line did not stay down too long. I seem to remember the Apple II did also, but my Apple II books are not very accessible to check. The Apple II had a reset button, but the C64 did not. The reset circuit I used in my first home-made computer in 1985 used a 555 timer and I think I got the circuit from the Aim-65. Because of the known bug, all these timed it so that the RST\ pulse would be quick even if you hold the button down a long time. On the CMOS 6502 it doesn't matter though. You can hold it down as long as you want.

Dr Jefyll · Post by **Dr Jefyll** » Sun Sep 11, 2011 3:47 am

GARTHWILSON wrote:

Just because you have a button does not mean you can't time the pulse to keep if from being low too long.

Agreed. In fact I wondered at first whether the 'LS14 in the Microbot implemented a clever little pulse generator more or less like the one in your diagram.

Back to the RST limitation/bug: I just discovered that I was guilty of leaping to an erroneous conclusion.

555 means pulse, right? Not necessarily! You have to examine the circuit to find out for sure. (See my previous post, which passed yours in transit it seems). The presence of a 555 (or 556) multivibrator, aka "one-shot," doesn't always mean a one-shot pulse is being generated. It's easy to imagine that other people might've made the same mistaken assumption I made.

So, meaning no offense, Garth, but are we sure the Commodore's 555 circuit (and others) actually do limit the RST pulse width? The KIM 556 circuit doesn't. Is there anything else to support this notion of a 6502 CPU bug? If not, I can't help wondering if the RST limitation is some sort of myth or urban legend that has sprung up somehow. Of course I won't mind if I'm proven wrong about that; mainly I just want my curiosity satisfied!

cheers,

Jeff
ps- the 556 in the Commodore 64 schematic here is configured as a one-shot. But there's no manual pushbutton. In this case I don't see grounds to infer that the one-shot is meant to protect the CPU from excessive pulse width on RST.

GARTHWILSON · Post by **GARTHWILSON** » Sun Sep 11, 2011 7:30 am

At viewtopic.php?t=1759&start=4 , or the fifth post of the topic General Discussions-->Beginner in digital circuitry which is at viewtopic.php?t=1759 , after I mentioned the NMOS RST chip-heating bug, ioncannon wrote on Feb 1 of this year, "Ahh so it wasn't just me, whenever RST was grounded, the chip would heat up significantly." So far I have not found anything more on it though. My possibly inadequate search line was "6502 NMOS RST bug".

Making new masks for a design change was very expensive. It would not make sense for them to fix this bug without fixing several others; but those were never fixed on the NMOS 6502.

falcon5252 · Post by **falcon5252** » Sun Sep 11, 2011 11:12 am

Your right on the Kim One circuit as long as the reset button is pushed pin 40 will be held low.. But the commodore 64 is definitely a pulse output with the 2 caps.. There may have been a problem in early FAB's or some particular manufacturers.. And being they weren't advertising which devices had the bug and which didn't.. Many product makers just played it safe.. Once the idea there is a bug like this gets out in the wild with no one actually involved in early production to clarify it, Were stuck with allot of assumptions.. The FAB's were no doubt changed over the years by the original designer and many of the cross-licensed producers..

On the 57xx I was not inferring they could make it inverting by separating the inputs.. My thought was that if the power draw was the sole reason they changed the circuit to inverting.. The problem could have been remedied more easily by by separating the inputs and tying one side of all inputs together and holding them high during reset.. Which would prevent the outputs from turning on.. Non-inverting driver L+L = L transistor is on, L+H or H+H = H transistor off..
I'm thinking they switched to inverting for more reasons than alleviating the power draw...
Might have been ringing on the buss or a coding problem.. Hard to say for sure their reasons.. But they did solve the power draw with the change, But like I said their reasons may go beyond that... You have to remember steppers are noisy devices with large variations in current draw and tend to ring the power buss just by their nature, As each step causes a wobble in the armature creating oscillations which can sometimes get fed back and modulate the driver,, Inverting the input can mitigate feedback in allot if instances.. And if you look at the TeachMover board,, There is not a abundance of Cap's to suck up the noise and fluctuations.. In both in size and number its anemic..

falcon5252 · Post by **falcon5252** » Sun Sep 11, 2011 4:00 pm

Garth.... All I know is this robot has been running 29 years in a School or University with a Rockwell R6502AP with a simple rest circuit without smoking the CPU..

And If you read the history of the 6502 they changed the FAB hundreds of times to get the yield up and improve reliability.. In the first production runs, I don't remember the exact number but the yield was insainly bad..

Its not that costly to change the FAB, It was just photo lithography back then you drew out the circuit on a huge layout and then photo reduced it to the wafer size, Back when light wavelength was still small enough for the size of the traces and transistors you needed to create.. All they did was grab one of the master layouts and mod the section that needed changing and put it in the reducer to create the mask.. Besides they owned their own chip company.. And most company's that cross licensed the 6502 owned their own clean-rooms.. The cost only gets prohibitive when you have to pay another company to change the FAB for you.. Pay the employee $20 per man hour but charge the customer a $1000

Dr Jefyll · Post by **Dr Jefyll** » Sun Sep 11, 2011 4:56 pm

I have opened a new topic, for discussion of the NMOS 6502 reset bug. Mebbe should've done this sooner, but hey. Please address your posts regarding the bug to the new thread.
-- Jeff

leeeeee · Post by **leeeeee** » Mon Sep 12, 2011 5:07 am

A description of all the Teachmover serial commands can be found in this document.

Lee.

Dr Jefyll · Post by **Dr Jefyll** » Mon Sep 12, 2011 6:45 am

falcon5252 wrote:

On the 57xx I was not inferring they could make it inverting by separating the inputs.. My thought was that if the power draw was the sole reason they changed the circuit to inverting.. The problem could have been remedied more easily by by separating the inputs and tying one side of all inputs together and holding them high during reset.. Which would prevent the outputs from turning on..

Oh! Okay, sorry; I misunderstood you, then.

falcon5252 wrote:

I'm thinking they switched to inverting for more reasons than alleviating the power draw...
Might have been ringing on the buss or a coding problem.. Hard to say for sure their reasons.. But they did solve the power draw with the change, But like I said their reasons may go beyond that...

It certainly is a puzzle, trying to infer what motivated them to tack in that 74LS540. But the reasons may be unimportant if you're comfortable with just leaving it there.

On the other hand, maybe you'd prefer to remove the added chip (because of the fragile nature of the wire mod's that connect to it). You could restore the original traces that were cut, and (as I see it) you'd install OR type stepper drivers equivalent to UDN5703 and use your idea for taking one input from each gate to solve the excess-power-on-reset problem.

BTW I did a quick scan for drivers and found the Texas Instruments 75453. This is a dual (not quad) device but the pinout seems to be such that you could locate two of these in the site previously occupied by a single UDN57xx and most of the connections would end up in the right place. Better double-check all the details; I did this in a hurry

-- Jeff
ps- can you post some photos of your board?

Edit:
change "NOR type stepper drivers equivalent to UDN5703" to "OR type drivers equivalent to UDN5703"
change "Texas Instruments 75454" to "Texas Instruments 75453"

falcon5252 · Post by **falcon5252** » Mon Sep 12, 2011 4:47 pm

Jeff....I will post photo's eventually,, But right now I'm upgrading the CPU to a Quad core and going from XP to Win7 Pro on my desktop computer and my hi-Res 10mp Logitech is on that computer.. My Laptop has a 2mp webcam but the captured photos are really noisy and not worth posting...

Lee.... Thanks for bringing up that Link on the control codes for the Robot,, I had downloaded it but it ended up mixed in with about 75 other pdf's on the robot I downloaded and hadn't looked at yet.. As most of them contained junk info..

On another thought has digging through the code given you any SBC project ideas.. Like maybe a multitasking kernal and Ehbasic.. Looks like there's 28k of the upper 32 to play with.. If the I/O was better decoded you could get another 16 k at the bottom, But all the I/O addresses would have to be moved in code.. But with this Prom code you could build a multitude of 6 axis 6502 based robotic devices.. And the code covers all the major points of stepper motion .. Multi-axis concurrent axis movement,, Acel & Decel ramps, And a Pre-written interface programs, Stepper drive modes could easily be expanded by adding different stepping tables, Or converted to step and direction output.. The only thing you don't have is pulse modulated current control, But that is now built into the newer stepper driver chips like the Allegro A4988.. Add a few stepper commands to Ehbasic and have it access the proper parts of robot code.. The possibilities are endless .. Hint ,Hint.. Wish I could do it myself but the only language I'm proficient in is Basic..

As for the outputs I'm still leaning toward using the ULN2803's cross wired on dip headers by paring two Darlingtons for each motor coil I get 4 outputs per chip at 1 amp per coil.. As most other options get quite expensive..
Also when they cut the traces and added the LS540 the may have not only inverted the signal but also changed the wiring pattern to the LS174's , So I'm very hesitant to restore the non inverted traces.. Besides I'm finding almost all DIP package protected driver chips among all the various manufacturers have been discontinued, And bring outrageous prices.. And changing from one discontinued chip to another makes no sense,, Not to mention the 300ma current sinking ability is under rated for the steppers which draw 377ma.. I prefer to have at-least 1 Amp if not more per coil driving capability with any modification I do.. Maybe when I get my circuit board CNC machine finished I'll make a daughter board for it .. But So far I only have 2 of the 3 axis drive finished..

falcon5252 · Post by **falcon5252** » Tue Sep 13, 2011 3:07 pm

I just fixed the addressing and clock inputs to the 68B50 on the page 3 wiring charts,, I had CS2\ connected to pin 21 = VSS on the cpu corrected to pin22 = A12,, And added RX & TX Clock pins 03 & 04 paired on both ACIA chips to pin 19 = CB2 on the 6522 VIA..

NOTE: All schematic fixes or additions will be done on page 3 of this thread to keep it all in one place..

Question: They are changing baud by reading 4 dip switches which allows 16 possible baud rate settings,, It's attached to PB0, 1, 2, 3 inputs on the VIA and generating RX & TX clock on the VIA CB2 output..
The various dip switch combination's provide a range is 110 to 9600 Baud stated as the highest in the manual although there may be undocumented bit-rates in the code in which case this the following may not be necessary..
Now 9600 was fast in 1982 but Its snail mail by today's standards..

I would like to modify the Prom code removing a few of the lower bit rates and try to modify it to produce all or some in this range, 2400, 4800, 9600, 14400, 19200, 38400, 57600 and 115200, Or at-least 19200, 38400, 57600 if the capability is there.. What I don't know is if the 6522 VIA can generate correct clock signals for RX & TX to produce the various bit rates.. And what is the max reliable bit rate the 68B50 can handle.. On the TeachVAL arm control software default is 9600 so setting the available rates from 2400 or 4800 on up would not affect its operation but 110,300,600,1200 are useless now days... I also would like to move the code to a 8k or 16k x 8 Flash prom to allow room for code changes and add-ons actually the prom will be larger but upper addresses will be selected by dip sw either in 8k or 16k blocks... So has anyone discovered anything in Lee's disassembly of the code that would shed light on what minor mods could be done to acheive more usable bit rates.. I can see where changing the 6850 clock divider to 1x and using the CB2 1200, 2400 & 4800 ? clock settings would give 19200 & 38400 that's would help allot... 1x on the 9600 at 153600 way overshoots so not usable.. Remember this board has the 68B50 max data clock at x16 & x64 = 1.5Mhz and at x1 its 1.0Mhz..

Or would it be better to make a hardware clock and separate it from CPU control being it still uses dip sw to set baud anyways.. Going to external clock control would make it independent of CPU crystal, And allow faster CPU's providing you fixed the code for the stepper speed timing loops... Also the original dip switches could be re-purposed for other functions..

Any good links for 68B50 clock circuits.. 1.8432MHz divided by 16 gives 115200Hz that plus a binary ripple counter maybe.. But the data sheet for the 68B50 max clock is 1.5mhz at x16, So I guess 115200 is beyond the chips limits... So 57600 would probably be max at-least for the standard baud rates.. I can't seem to find any baud clock chips that haven't passed into history, And few that I found went past 9600..

Another question.. I have been reading the 6522 datasheet and I don't see any mode that would put out a programmable clock signal on CB2.. Can someone enlighten me as to what mode their using..

This is all fuzzy logic, Trying to remember circuits and chips I haven't used in 20+ years...