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