I recently bought a Microbot TeachMover Robot Arm, It has a 6502A processor running at 1.8432 mhz, I guessing that clock was chosen for proper baud rate on the serial chips..

It has:

2- 1k x 4 static ram, 1k of ram, expandable to 2k by piggybacking,
1 - 4K Eprom, Offset plugged into a 28 pin socket, guessing expandable to 8k or 16k
2 - 6850B, Serial chips
1 - 6522A VIA,
6 - UDN-5707A Quad protected drivers, Used as Stepper motor drivers,

I want to do a little modification to this board, But it seams Microbot has kept all info on the controller proprietary.. Hard to believe being the robot has been in production for 30+ years with almost the same controller board..

I spent many hours with 6809B 6800A 6802B years ago so I fairly familiar with the circuitry, And the glue chips. But just now getting up to speed on the 6502 variants..

DOES anyone have a Memory Map for one of these.. I would like to build a adaptor board to plug into the cpu socket with a 128k of static ram and some flash memory in some paged format, Minus IO addresses, And copy the eprom into the ram so I can disassemble it .. Plus I want to add EhBasic or similar, And utility programs in flash, And add a bluetooth serial link to my laptop..

But I can't do anything till I have Memory Map to work from, And I'm concerned about incomplete address decoding causing problems as I try to expand ram and rom.. Hope someone can help so I don't have to reverse engineer this thing at the logic level.. Hoping they based on KIM1, I should be so lucky..

Any Help, Ideas or Web links to make this thing more functional is welcome..

_________________
When falling from a high place, You might as well try to fly

I'm not at all familiar with the product but I can offer that the EPROM will be mapped into high addresses, since the 6502 reset vector is at $FFFC-$FFFD. Since you indicate the EPROM is socketed, you should be able to install on an EPROM burner and dump it to a file, from which disassembly should be possible.

Surely there must be some glue logic on the board. Can you tell use what you see in that regard, or perhaps take a hi-res photo of the PCB that you can post?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Welcome!

That's a nice-looking robot arm!

There's a picture of the PCB and some description in this pdf - see page 19. (Mark McCrate's MSc thesis.)

Tracing that visually would be a challenge, and I note you don't really want to reverse at the logic level:


My best guess then is to swap out the EPROM - as BDD says, one thing you can be sure of is the reset vector - and put in a series of replacements which contain some primitive memory tests which aim to feel out the memory map. For communicating the result, you'd use the trick of terminating into one of several tight loops, and the final address bus would indicate which of the code branches you'd ended up in. You know that high memory will be ROM, and that low memory will be RAM (because zero page and stack have to be there) so working down from high memory until you find a location which accepts a write and reads back the same value will probably give you a peripheral. You know that there's a couple of UARTs and a VIA to find: once you've found the right UART you could write yet another replacement ROM which uses that for I/O.

Once you're running your own code and can communicate a result, figuring out the aliasing on the control registers or the RAM shouldn't be impossibly difficult: for the RAM, writing some known value to location 0 and then looking for that value in successively higher addresses might well be enough.

Although, the total difficulty of that task might be more than tracing the PCB?

There's a robotics FAQ which says this robot is also known as UMI Microbot, design by John Hill. That led me to US Patent number: 4806066 - there's another but no insight on the controller.

Edit to add: As BDD says, pulling and dumping the present ROM will allow for a dissassembly. That doesn't give you all the aliasing, but it does give you some addresses for the peripherals. So your first replacement can immediately communicate over serial. And it knows where the UARTs are supposed to be, which makes it easier to check for the aliased addresses.

Cheers
Ed

Thanks for the response..

I had found that pdf file and copied the photo but it was a 8 meg bitmap and a bit to big to post and jpg'ing it just blured out the chip numbers.. didn't think to link to the pdf.. DUH..

I bought some 64k x 8 15ns SRAM to make battery backed up virtual roms, They draws 10ma at => 2 volts to retain data.. It will be easier to work with and save me buying a eprom burner, Will buy some flash memory when I'm ready to make things permanant, And it will handle a 65802 at any clock speed, If I choose to go that route.. I can program one of my Picaxe 40X2 MCU's to load the ram chips from files on my laptop

It's going to be fun mapping it, There's allot of address space between the 1k at the bottom and a 4 k rom at the top, But being the rom socket is 28 pins the top 16k is probably mapped to the rom..

Do you think pulling the 6502 and programming a Picaxe to slow sequence all the address lines and monitor all the boards chip select lines will work to map the board .. Other than setting W/R set to read, Are there any other signals I need to generate for this idea to work. I'm not up to speed on how all the clock signals interact with the I/O and Memory access.. Or is this idea a dead end.. Ive done this before 20+ years ago but its all kind of fuzzy now..

I had a Heathkit Hero running a 6802B at 4 mhz with paged memory and stepped the clock down to 1mhz on slow I/O access.. I used to take it to the local bar and programmed it to take drinks, And say stupid pickup phrases, I met allot of girls that way..

_________________
When falling from a high place, You might as well try to fly

Replacing the cpu and driving the address pins sounds like a good tactic. I'd first check that the phi0 (in) is private to the CPU and not used elsewhere, which should normally be the case. You'll probably find that some of the address decoding uses phi2(out) and maybe phi1(out) so you may need to drive those too.

What kinds of lab equipment do you have to hand?

Cheers
Ed

Edit: extracted the full size jpg from the pdf:

On another thought I can pop the eprom and program the picaxe to read the eprom to my laptop..
Once I get the bin file loaded into my laptop , What would be the best PC based software to disassemble the 6502's Rom code, In a fairly understandable Opcode format.. Noting that not all dissemblers are created equal..
My laptop is a dell studio 1737s with dual boot Vista and XP.. I have a old win98 laptop floating around here if I have to digress that far to run the disassembler app..

_________________
When falling from a high place, You might as well try to fly

I've only used the most unsophisticated disassembly tactics, I'm afraid, involving compiling run6502 from source... might be better to start from a google search or wait for an answer from someone more experienced.

Lab equipment is pretty sparse.. 4 1/2 digit exaltech meter lots of bench supply's, And a flaky 100mhz Techtronics scope.. I generally just program my picaxe's to monitor data, address, freq count or generation, decode serial streams. and anything else I can think of .. I have 40 and 60 mhz versions with usb.. And with their program editor you can bang out any kind of test program in minutes...

I had all my good equipment in storage while I was moving to a new house and one night dead tired I forgot to lock it .. and someone relieved me of my stuff.. I lost a couple thousand dollar worth.. I sense retired and can't really justify replacing it all..

_________________
When falling from a high place, You might as well try to fly

One topic on disassemblers is here.


Fortunately, it's 10uA max (ie, only 1/1000 of 10mA), and typically way below that. I had one set up with battery backing 25 years ago and a 10uF capacitor kept the data on it for 16 hours (and it may have been able to go a lot longer, but I powered up the circuit again the next day at work). IOW, it was taking no more than a couple hundred pA, a fraction of a nA.

I had it wrong on SRAM current draw, The chips I have are not low power versions .. But it is lower than I stated, I had the numbers crossed with a different SRAM I was looking at buying.. ones I bought are 5ma standby and 200ua data retention at => 2v

_________________
When falling from a high place, You might as well try to fly

Hello, falcon5252. Your oscilloscope is one possible tool to determine the address decoding (assuming your old Tektronix is up to the job). For example, you could burn an EPROM with a simple loop:


With the loop running, you use the R/W line to trigger the sweeps on the 'scope. Then you observe what the various Chip Selects (ram, rom, IO) are doing. Every fourth CPU cycle will be one of your memory/IO accesses.

Of course I've simplified the code example; really you'll want a longer loop with a more fine-grained pattern of accesses. But the simple loop would be a good place to start. I admit this technique may be a bit challenging if your oscilloscope skills are rusty.

Good luck! Keep us posted

-- Jeff

Worst comes to worst, ever thought of trying to reverse engineer it to make a working schematic? This method I use and it just uses paper, time and a meter set to continuity.

1. note down the layout of all the chips and connectors. The reason is that you will want to remove the connectors to lift the board out to inspect.

2. Note down the chips and their notations. Get datasheets on all the chips.

3. Certain things will remain identical. the power feeds will remain the same. Use the meter to verify those.

4. another thing to remain fairly identical would be the data bus. Verify it goes to all chips using a data bus.

5. the inputs and outputs will go to buffer chips.

6. The other lines such as clocking can be traced out from the crystal oscillator to the various clock inputs.

7. This should leave you with the control logic as the pins left over. Your memory map will derive from here.

AS A RULE, the RAM will begin at $0000 and move upwards and the ROM will end at $FFFF and move downwards.

It will help to notate into a schematic as you go along. Put it down on paper or I recommend Kicad which is an open source full suite.





Good luck!

_________________
"My biggest dream in life? Building black plywood Habitrails"

In fact, didnt realize the picture expanded. He3re are some thoughts of mine.

U14 the 74LS14 would be used for the clocking oscillator and the power up reset. C17, R5 and CR3 should comprise your standard reset into there.

Out by the bottom, the MC1488 are line recievers or transmitters to outputs or inputs. The 74LS251 and the other may also be part of that circuit.

U17 and the chip under are 2114s. This gives you a known RAM memory size, but you knew that.

U8 is most likely the gold you seek, the 74LS138 is a 3 to 8 line decoder. Pins 1,2,3 should connect to the 6502 address bus and the outputs will go to the various periperals. there may be some gating logic to split up those addresses to a finer grain, though.


Hope this helps.

_________________
"My biggest dream in life? Building black plywood Habitrails"

Hmmmm... just re-thinking the issue of aliases (multiple addresses which, due to a hardware quirk, all activate a single device). If the Microbot circuitry exhibits aliases then the oscilloscope technique I mentioned will reveal them, leaving you with too much information. If there are aliases, what you need to know is this: of the multiple addresses, which is the one that existing program code uses to address the device? (Your goal is to modify the decode circuitry without being forced to modify the program.)

So, here's an alternative suggestion. Instead of running a special diagnostic loop, you could run the original application code instead, and use the scope to detect when accesses to the various devices occur. Using an analog scope, this may or may not be easy. But if you can view those events then it remains only to look at the bus to determine which addresses the program has invoked. It saves you having to disassemble the code.


Ahem! Well, yes. We here at 6502.org are always interested in new applications for technology!

-- Jeff
ps- Despite the extra effort, Nightmaretony's suggestion (previous 2 posts) has the advantage of increasing your overall knowledge of the Microbot. The same can be said for time spent disassembling the code.

Thanks for the Ideas

After looking at the Op-Code generated from the various decompiller's and the number of errors that can occur by interleaved data, I decided I'm not quite up to that right now, I think thats better done in a 6502 environment rather than on a PC ..

I think the best idea and easiest way to start is with continuity trace of which address lines are driving the 74ls138, If its a13, a14, a15.. Then the eight outputs will divide the board into eight 8k blocks ... If its driven by lower order address lines then its not the primary decoder and will have to ferret out what chip is doing high order addresses...

My gut just turned, I'm not seeing enough chips types that would be used in address decoding, The thought that they could have went no further than the 138 and put each I/O chip on a 8 k boundary. Causing thousands of mirrored addresses.. UGH!!

Well I guess the only way to find out is to start tearing into this thing ... I'll let everyone know what I find out as I ferret out its secrets..

Oh and I still have not found a complete user manual on this thing.. I guess its divided into sections because I only seem to be finding the first part of the manual that references other sections that I can't seem to find.. Such as the instructions on piggybacking the 1k ram chips which is a no-brainer but may give in-site into addressing...

_________________
When falling from a high place, You might as well try to fly