Vintage chip Programmer : " Micropross ROM 3000U "

[pcprogrammer]

You need a small table on wheels to roll stuff in and out

But however big your bench is, there will always come a time that it is to small 

[Vince]

Sadly there is zero space to fit a table, never mind wheel it around. Only place in the house where is space to put stuff and use it is... the bench itself.... and it's gonna stay like that for at least 2 or 3 years, the time to build the garage to I can shift stuff into there and make room in the house.

[Vince]

Geez.... I think I managed to make something that might work we shall see.

I got lucky and foudn my spliced serial cable, woohoo !!
I am so glad I was clever enough to keep it when I was sorting through boxes and boxes of old cables.... most likely thanks to one of you who must have explained to me what these cables were for...

Anyway. so with this cable, plus my previous light blue flat cable (ex RJ45 cable for serial consoles IIRC...) that I sacrificed a few years back so I could cut the connector and strip the wires so I can scope the signal.... plus 3 gender changers..... look what we get as a result !  A spaghetti monster ! But.... it works, then it's gonna be TASTY spaghetti hmmmm !!! 

I am tired of all thyis messing around with cables and gender changers....it's official, I just added another little design project to my list.... I will make myseld a little breakout box so that I can spy serial links  with much less mess, a much more compact and convenient setup..... I could fit ti with both 9 and 25 pin connectors on both the input and the output, so that the worse I might need to do would be a gender changer, that's OK. Then LEDs to see the activity on the various signal, and easy test points on which to hook a DMM or scope probe.. and also some jumpers to easily swap lines where useful. and myabe a small prototyping area as well, you never know what you might need eh !   

Yes, I need that... I want that... I wiiiiil make that thing... one day.


OK so let's try my monster cable see if that works somehow...

[Vince]

OK, we have results here....

I put the programmer back onto the bench with the HP scope sitting atop. The compactness of the HP scope does wonders.




The bad : my spaghetti cable doesn't work, the PC fails to communicate with the programmer... investigations are required.... 

The good : even if the programmer does not talk, the simple act of plugging the other end of the cable to the programmer, made the PC S/W happy : now it DOES send stuff "in the air"... so I was able to capture that and work on it. So that means as I feared, that the MS-DOS program does use H/W control lines, not just RxD / TxD, bummer.

- It sends always the same frame, it's perfectly repeatable.

- Frame lasts about 5.5ms




- Bit time measures at about 103.75us so now we know the baud rate : 9,600 bps.

It was not so accurate when measuring a single bit, because you  have the problem of deciding where to place the cursors on the leading and trailing edges, because you can actually see the slope of them. So in order to minimize this problem, I measured a group of 4 bits to get the figure above.




- That means the frame contains about 53 bits.

- We assume that frame of course must correspond to what we saw on the "terminal" screen of the programmer : " BOOT + <CR> " , so 5 characters.

- So that's about 10 bits per character... it adds up so far.

- So then I converted " BOOT + CR " into binary and scrolled the stream of bits one by one, hoping to find matches and hoping I could figure out how many start/stop/ parity bits we have.

Here is the very first character as an example, so it's a 'B'... was happy so kept going 'til the end 



Well it all went OK and that frame indeed contains " BOOT + <CR> " , and we have one start bit, no parity bit, and an idle time between characters of 2 bit "slots". So I guess that means 2 stop bits. So " 9600 8N2 " 


So now I can configure a terminal and talk directly to the programmer yeah...  but no.
Again, I need to figure out the extra control lines used by the interface, and I know squat about that.
So I will probably never figure that out hence terminal fun is not going to happen.

[pcprogrammer]

Hi Vince,

the hardware handshaking is not that tricky. I vaguely remember having three options for hyperterminal.
No handshaking
Xon / Xoff
Hardware handshaking

Your cable has to have the lines connected because the software for the programmer is able to query the version, so just give it a try 

Edit: Yep checked it in a virtualbox Windows XP setup.

[DC1MC]

To speed up a bit the story, don't forget that the telegram contains at the end the EOT character, that a bit more difficult to send with the usual terminal programs !!!

 Cheers,
 DC1MC

[pcprogrammer]

Depends on which system sends it. It might just be the programmer that sends it to end a query.

[DC1MC]

Depends on which system sends it. It might just be the programmer that sends it to end a query.

Could be, if true, that makes life easier, but still someone needs to hack the PC utility to accept the 3000 as 5000, right now I don't know what is the purpose, to speak with the device or to make it program EPROMS ?

[Vince]

OK !

So..... let's see.

@PCprogrammer :

- H/W flow control : XON/XOFF appears to be S/W not H/W. So that leaves us with only one single possibility for H/W control.... great.

- Cable : what I will do is... not even bother trying to fix my spaghetti cable ! Waste of time because I only needed it to figure out the data format... now that we know what it is, I can remove my spaghetti and just use the cable I was using before.... which already know works fine.

@DC1MC

but still someone needs to hack the PC utility

Wow good luck with that ! I am not a magician.... if you are, you are welcome ! 
That said, the program is all contained in that single EXE file, and weighs only 100KB.. .it's not an awful lot. So I think I won't resist the temptation to load it into a HEX editor to see what I can find in there...

to accept the 3000 as 5000,

No you do'nt understand. The S/W is not made for the upper class 5000 model, it's made for the little brother the 3000.
More precisely the 3000B.... the best I could ever dream about is for the S/W to one day work with my programmer which is a 3000U not a 3000B.

The small size of the EXE file I think kinda makes it obvious that it's not featureful enough to handle a 5000.
I understand it's an old program, at a time where (human) programmers were good/skilled and could get a lot done with very few lines of code..... plus that S/W uses a text bases UI so doesn't require a lot of code for the UI.... I understand all that, but I still think that 100KB is not a lot compared to everything a 5000 can do.

Needless to say, I would love to be proven wrong.

right now I don't know what is the purpose, to speak with the device or to make it program EPROMS ?

Eh ? Cheeky !! 
It means you are taking this fligh in mid air.... you missed the very first episode of Season #1 !

Can't believe I need to reiterate the obvious but, here we go 

---> > > I bought this programmer knowing ZERO about it, just on a whim. Once I started Googling a bout it I found ZERO on it... so from day one, as fa as I am concerned it was a hopeless case and the thing was just a big door stop !

It's just a pretext for reverse engineering and tinkering with vintage stuff, that's all.

I would never have ever dreamed of achieving everything we managed so far, it's a miracle.

I have no reason to believe, nor the right to expect, that this thing will ever be able to program an EPROM, because I just don't have the S/W for it, nor the documentation.

If we can manage it then... it's a miracle, I would be overjoyed... but I am realistic and hardly count on it....the fun is in the journey. Reaching the destination is just the icing on the cake.

To speed up a bit the story, don't forget that the telegram contains at the end the EOT character, that a bit more difficult to send with the usual terminal programs !!!

I don't understand the issue... as we have seen, and as PCprogrammer said... the S/W does not send that EOT code, only the programmer does.
Regardless, sending non-printable characters is obviously a common problem when using terminals, so there must exist somewhere a terminal program that let's you send arbitrary characters by specifying a binary or HEX value.
At any rate, any terminal program can send a file, so you can just make one using a HEX editor which will make it easy to type both readable text as well as any control codes. Then you can just send that file.

[DC1MC]

OK, please zip the program and the associated files, if any, post it here and I'll give it the IDA Pro treatment, no promises, but we may be able to find what is expecting form the device to start sending commands, I have no idea what is the difference between U and B versions, but at least I may be able tell you what it expects to get from the machine.

 Cheers,
 DC1MC
 

[pcprogrammer]

Hi Vince,

I peaked at the executable with a hex editor and it indeed shows the commands near the end of the file. A lot of 4 letter commands so a bit of a guess which means what 

Not sure what your software skills are but with Ghidra it might be possible to gain some insight in the code. It can most likely also be used on the 6502 code, but for that to make more sense you would need a memory map of the programmer.

You wrote about someone having the original 6502 source code. That could make life a lot easier.

[Vince]

OK, please zip the program and the associated files, if any, post it here and I'll give it the IDA Pro treatment, no promises, but we may be able to find what is expecting form the device to start sending commands, I have no idea what is the difference between U and B versions, but at least I may be able tell you what it expects to get from the machine.

 Cheers,
 DC1MC

I don't know that IDA Pro thing you are talking about, but it looks like you are much more capable than I a for sure, so have a go yeah  !

I have already posted the program here yesterday, it's a single EXE file, nothing else. 100KB or so.
OK I am nice... I attached it here again, to save you some scrolling back ;-)
Don't forget to rename the file to replace the PDF extension back to EXE.....

Ideally it would be cool to crack it so as to bypass the revision test, so it doesn't even asks the programmer for its identity.
This way the S/W would let us past the gates and we might actually see what the user interface loos like, what it can do for us....

[Vince]

I peaked at the executable with a hex editor and it indeed shows the commands near the end of the file. A lot of 4 letter commands so a bit of a guess which means what 

All the commands are documented in the 5000 manuals 

Not sure what your software skills are but with Ghidra it might be possible to gain some insight in the code. It can most likely also be used on the 6502 code, but for that to make more sense you would need a memory map of the programmer.

Skills ? What skills 

A bit of embedded C and a bit of 8051 and PIC assembly language 15/25 years ago... that's about it.

You wrote about someone having the original 6502 source code. That could make life a lot easier.

Yes, he posted only once on that forum, 2 years ago, to offer his help

https://forum.system-cfg.com/viewtopic.php?p=176555#p176555

... but then he disappeared.... maybe he is dead. I will try pinging him anyway...
The source code, if it is well commented, would give us I hope the details of what the parameters mean in the message that the programmers sends back to the PC S/W. This way we could maybe crack the programmer's code, overwrite these parameters so that it returns a 3000B parameters instead of 3000U.... that would be cool.

[Vince]

OK, I did as I said...  got rid of the scope and spaghetti cable, and used the previous cable that worked.

Fired up Windows HyperTerminal.... configured it with my findings, 9600 8N2, H/W  handshaking.... and what do you know ?

IT WORKS !!!! 

For a change, it all went according to plan ! 

I can talk to the programmer and it replies to me.

If I send a wrong command, or some garbage, or no command at all really.. the programmer replies with : " ERR #01 ".

So then I sent the same commands as the S/W does : BOOT and the HELO, and the programmer replies exactly the same thing as it did before... VICTORY !!! 

See for yourself :




So that's it !  My programmer works ! It's not a door stop anymore !!!

All the commands are documented in the 5000 manuals, so just need to spend the next 6 months studying all that to understand what I need to type to get it to do anything useful...

Then I can write a script to automate that, or better yet write my own little C program to replace the one we have now which is not cooperating very much, is it...

Wow... the grin on my face does not show, but it is there 

So now, it's just a matter of time, and effort, before I can eventually program a chip with this thing, YES ! There is HOPE now !!! 

What I don't understand though is.... this programmer can do so many things, and program so many different chips (can even program MCU's  like the 8051 and 68705 at least, I remember from the documentation)... it must take a lot of data space to store all the various parameters that tell the programmer how to work with X or Y chip, no ?
The MSDOS S/W weighs barely 100KB, no way in hell it contains that data.... it can't be in the 6502 EPROM either, too small. So it must be in the system disk ??
There is more space in there for sure. It's also the easiest way for customers, to add more chips as they come to the market.

Oh, EDIT !!! ==> the programmer replies with its ID to the PC S/W only once it's booted from the system disk... so the ID we need to modify must be on that disk, not in the 6502 EPROM... so no need to mess with that EPROM 

So in 2023 for season #2, we will focus on studying all the serial commands, and writing some little script or C program to help us hopefully..... program an EPROM !!!!   

[Vince]

I peaked at the executable with a hex editor and it indeed shows the commands near the end of the file. A lot of 4 letter commands so a bit of a guess which means what 

Hmmm.... that must explain the " HELO " command instead of " HELLO ".... it's not a typo, it's just that they must have decided on a fixed 4 letter format for all their commands.... OK my bad, I was being a bad mouth... I apologize to all Micropross engineers....

[DC1MC]

The "little" PC executable is packed (literally) with an EXE packer and with a lot of anti-reversing measures  , after unpacking the decompiler doesn't load it but the program still runs. I've remembered the programs of that era, everyone and his brother were doing anti-reversing shite, not that it helped them too much with the young dedicated crackers  .
Anyway, I'll try to reverse it just for lolz and out of boredom.

 Cheers,
 DC1MC

[Vince]

Thanks for that ! 

So that's interesting.... means the program might be much larger than 100KB.... so now there is hope that it might have decent features and user interface, great ! 

[m k]

The communication sniffer part can be only unidirectional.
So with one sniffer port you can sniff only one side at the time.

The cable itself is not very long so the driver should be able to serve two receivers.
On the other hand, 1488 driver's capability is bad, or worse.

Am I remembering correctly that your chips had some 75-series stuff.
Those are many times non TTL level drivers and receivers.

Since it's a programmer and moves more data it needs some controls, both directions.
The cable is,
TxD - RxD
RxD - TxD
GND - GND
RTS - CTS
CTS - RTS
DTR - DSR
DSR - DTR
DCD
RI

Only one pair of controls is needed, DTR/DSR or RTS/CTS.
The other pair can be looped to its counterpart.

DTR is Data Terminal Ready, so it's not really for flow control, or at least wasn't meant to be so.
DSR is Data Set Ready, Data Set is a modem and its connections have opposite directions, so straight through cable was used.
Together they were meant to tell that the device on the other end is ready, so signals were meant to be pretty steady.
RTS/CTS pair was meant to be the flow control, their names are Request To Send and Clear To Send.

Three and four letter commands are a norm.
There the interpreter reads up to a next whitespace and then checks the beginning.
So for "start" you can also give just "sta" for three letter system.
For four letter system "hello" is an exception.

[pcprogrammer]

Hey Vince,

as if Adrian knows about your project 

[Vince]

Thanks ! 

55minutes wow ! Will be watching it for sure but not right now....

Making disks for the EPROM programmer is indeed high on my priority list.

I have already installed that " ImageDisk " S/W on the vintage PC, but it seems so complicated and it's actualy a collection of many programs.
It's overwhelming and I just don't know what file(s) to run, then what menus to go to, for what, in what order.....I just have no clue what I am doing ! 

I definitely need a lot of hand holding to make sure I don't ruin my precious boot disk !

... so I guess it starts by watching this video....

Then I will have to make baby steps... I think I will first get some hands on experience with some old random 1.44MB HD disks I don't care about, using the original HD drive in the vintage computer.
Then once I am successful with that and start building confidence... I will install the programmer's DD drive into the vintage computer, and do experiments with that, on my NOS DD disks.... trying to write the image file I got for the ROM 3000B system disk. Then read my original 3000U system disk and make 25 copies of it to be safe....

Anyway, I am glad I made so much progress on this programmer during my week off, because it's over... tomorrow and Monday, I am away visiting my dad. Then Tuesday back to work....
Need to make progress on my other long overdue repairs as well....

[m k]

Maybe you can sniff both serial comm directions with one port.
If communication is half duplex you can hook trannystors to both lines as open collector receivers and 3rd as a needed inverter.
You can also use unused control pins for power and since you're not changing levels everything is naturally correct.

Then you just start receiving.
Everything obviously comes to same screen but if it's half duplex and own lines the whole thing should be quite understandable.

Disk stuff,
in case you need to shuffle with hardware.

With HD stuff you're mostly always fine.
You can do all DD stuff just fine if you read them back with that HD drive.

Drives will have settings and some are important.
I found two.
Mitsumi D359T5, importer labeled Feb-95 and all settings packed away.
Panasonic JU-257A606P, labeled 23/97 and settings
SW1 RY/DC ready/disk change pins
SW2 OUT/NC/IN density mode
SW3 D0/D1 drive number
SW4 IN/OUT density mode
SW5 PC/AT/P2/SE speed
SW6 MS/MO motor on style

[Vince]

It's not half duplex.

Oh ! Now I think of it, I got the perfect tool for the job.... an HP 4951C Protocol analyzer !!
Mine came with the pod to work with RS-232C, so that's perfect. Problem is that it's missing the big cable that connects the pod with the analyzer, so it's useless.

Plus it's so versatile / complicated, and the manual so thick... it takes a PhD and 6 months of training to get it to do what I did in a few minutes with a scope.....
I am sure it does fancy things that I will never need, but for the basic stuff I need, it's way overkill and way too complicated.

But I find it cute so I  can't get myself to get rid of it....

[pcprogrammer]

55minutes wow ! Will be watching it for sure but not right now....

... so I guess it starts by watching this video....

Yes his videos are almost all 45 to 60 minutes long. I tend to skip to the bits I'm interested in 

Make sure to write protect your master disk. Open the slide on the small hole. https://electronicstechnician.tpub.com/14091/css/Write-Protect-Write-Enable-Slide-262.htm

Edit: You do have nice toys  A shame that the cable for it is missing.

[TERRA Operative]

Surely a cable isn't toooo hard to make, beyond the tedium of soldering so many connections?

Or just use IDC connectors and do them all in one go.

[m k]

Oh ! Now I think of it, I got the perfect tool for the job.... an HP 4951C Protocol analyzer !!

I've once made a Windows bit banging analyzer for parallel and serial port but can't remember how fast it was.
Today's free alternative should be available.

Nowadays new construction should include an embedded MCU as a source connection.
It could send blocks that the receiving computer rearranges.
Shouldn't be overly complicated project, I can do the software if you're a hardware guinea pig.