Electronics > Repair
Vintage chip Programmer : " Micropross ROM 3000U "
<< < (29/38) > >>
Vince:
Thanks for the info, might be looking that because I now fear the DD drive might be bad... the programmer now refuse to boot no matter what. It will seemingly read the disk for a minute, like it always does during a successful boot, execept that now once done reading the disk, it emits one BEEP. At that point I can still talk to it via the Terminal / serial port, however the only command it will accept now is BOOT. If I try to type any other command, it will not even let type the command in full : as soo as I type the first letter, just the first letter (not even hit "Return" to validate).... it will immediately  reply with ERR #1 as it always does when it does not know a command.

So I can type BOOT and that's it, to which it replies with " BOOT 0F " so indeed there is a boot error code... then it tries to boot again, fails again. So I type "BOOT" again, and it returns " BOOT 25 ", another boot error code then.... boots again but this time I remove the disk from the drive to see what it would do. It  BEEPs again, and throws " BOOT 1E ", yet another error code, all by itself this time though = I don't even have to type BOOT for the programmer to return the error code.

I tried two more bot disks, which used to work fine : I get the exact same behaviour. so it's not a disk problem.

The programmer itself seems responsive as I explained... it's just that it's not happy with it gets from the drive apparently... for some reason.

So I am hoping the programmer itself is fine, and it's just a floppy drive problem... or just a bad cable who knows.

At any rate, the programmer is now a door stop so I can't move forward until I fix this boot issue... IF I can fix it that is  :palm:

I must admit I am extremely depressed.... was going so well so far, and now in a split second it all dark and gloomy  :-BROKE

I tried reseating the ribbon cable, no luck.

Will try replacing it.

Will try installing the drive into the PC to see if it still works. MSDOS can't use it of course, but I can use IMD to write and read images to DD disks and see if that still works or not. That should tell me if the drive is still good. If it is then I am in big trouble because that means the problem is in the programmer itself, and I doubt I can find the problem....too complicated, inaccessible boards...  All I could do is replace tantalum and aluminium caps, to rule that out, but other than than  :-\

I must give more details about how it all happened though, in case someone finds a clue in there :

The programmer started misbehaving while I was trying to throw at him every serial command I found last night. So I just tried them one by one methodically, and took note of the result. I had only time to try maybe 70% of the commands before the programmer went kaput. I tried every command but TSPR TSRO TSSR and the FDxx group of commands.

Below is a compilation / cleaned up terminal output, of the successful commands :

BOOT 00

HELO 00 30 00 5.00 5.40 AP

EERD 00 F0/O3870742/CV  / OK/16/11/87

INRE 00

INTR 00

RSLI 00
0001 BINARY
0002 ASCII - BNPF
0003 ASCII - BHLF
0004 ASCII - B10F
0005 ASCII - OCTAL
0006 ASCII - HEXA
0007 MOTOROLA EXORCISER
0008 MOTOROLA EXORMAX
0009 INTEL hexa - MDS
000A INTEL hexa - MCS-86
000B HP 64000 absolute
000C HP 64000 + absolute
000D TEKTRO - S8000
000E TEKTRO - S8002
000F SIGNETICS absolute
0010 TEXAS SDSMAC
0011 MOSTEK
0012 FAIRCHILD
0013 MICROTEK (MICE)
0014 DEC-LDA
0015 RCA COSMAC
0016 Extended TEKHEX
0017 Intel hex MCS86bis

That RSLI command was such a joy... returned lots of data, a full list of al the accepted file formats, x17 of them no less.

Anyway, the problems started when I typed teh MECK command : the programmer did not respond... so I waited... waited.... thinking OK if MECK stands for "Memory Check" it could take any amounts of time... depending on how much RAM there is, and how thourough a test the CPU is doing (various patterns, bit shiffting etc... ) and hell maybe CPU found RAM errors and it's slowing it even more.  But after 10 to 15 minutes I decided it was none the less getting suspiciously loooong...  so I gave up and power cycled the programmer.

It booted fine and I carried on tested more commands. Then when I got to test the TSDR command is when the programmer started losing it for good :

The first time I send it the TSDR command, the programmer took 30 seconds to respond, with " TSDR 00", which in itself is fine. It means it spent 30 seconds doing whatever, then this whatever turned out to give satisfaction hence the 00 return code. So I didn't think too much of it.

BUT.. then I sent him this same command again, just to see...and that's when I lost the poor programmer : again it was not responding for 30 seconds, fine... but after these 30 seconds, instead of returning a 00 code, what it did was access the disk drive for a minute or so, just like would happen during a power up / boot sequence... then it stopped accessing the drive, and would not return anything to the terminal, it had become unresponsive. So I power cycled it and then we get to the point that I described at the beginning : fails to boot. Does read teh disk for a minute as normal, but then BEEP and return error codes at the terminal, over and over again.

Soi it looks like sending him this MECK and TSDR commands killed it, how can that be... 


So that's where I am at now, not looking good eh !!!  :-BROKE

Vince:
EDIT ! forgot, MK (or anyone who wants it) , the ZIP archive I was passed regarding this programmer, is just a tad too big to be attached here : weighs 5.1M but the size limit here is 5,000KB ie 4.88MB.

I tried anyway but yeah, no go.

So just PM me with your e-mail address and I will send it to you.

EDIT #2 : OK I just uploaded the ZIP file to my Google " Drive " file hosting service.  I never used it and don't know if others without a Google / Gmail account can view it though... I did what I could to make it "public" with the options I found....  try this link tell me if that works...


https://drive.google.com/file/d/166ueXaKpcjJgb0fc_IeghnZM3TZEcqET/view?usp=sharing



pcprogrammer:
Hi Vince,

the link works for me, but I do have a google account.

To bad the programmer is out of order now.

About the disk drive there are emulators for it, but don't know if they can do the special format your disks have. If I remember correctly Adrian Black did a video about it.

I bought a Gotek a while back for a Yamaha synthesizer, but instead of emulating DD disks it was doing HD disk and it did not work. Believe there is some open source firmware available for it to emulate all sorts of disk formats, but have not looked into that any further.

Any how just sharing some information  8)
pcprogrammer:
Hi Vince,

one more thought, did you try to write the disk images you have in that zip file with "dd" on linux. It might be that they are just raw disk images made that way.

Cheers,

Peter
Robert763:
Hi Vince,
As you have been working wih at least one dirty disk it would be worth cleaning the heads on the drive. I assume you dont have a head cleaning disc. The alternative is to use a strip of paper. Stiff is good mabe 100-120 gm/sm. Cut a strip, add a couple of drops of isopropyl alcohol. Just moisten the paper, don't soak it. just slide the paper back and forth between the heads. Don't apply any pressure. If there is visible dirt on the paper swap to a new strip.  Make sure the heads have dried completly before putting a disk in.

Robert G8RPI.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod