| Electronics > Repair |
| Vintage chip Programmer : " Micropross ROM 3000U " |
| << < (26/38) > >> |
| Vince:
--- Quote from: TERRA Operative on January 01, 2023, 04:09:22 am ---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. :) --- End quote --- You are assuming it's a straight cable aren't you ! ;D But we don't know that... I did get the service manual back then, to try to figure it out. I don't remember I managed to get an answer to that question. All I remember is that the manual was so thick and overwhelming, it discouraged me from going any further with this instrument, I just didn't feel smart enough to make use of it, frankly. But I guess I could reconsider the situation... maybe it's a straight cable. If it is, I will price the parts and if it's affordable, might make a cable and see if we can have some fun with that analyser... |
| Vince:
--- Quote from: m k on January 01, 2023, 08:34:22 am --- --- Quote from: Vince on December 31, 2022, 08:15:53 pm ---Oh ! Now I think of it, I got the perfect tool for the job.... an HP 4951C Protocol analyzer !! --- End quote --- 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. --- End quote --- No pigs here ! >:D I will just buy a ready made analyzer, these affordable compact USB thingies every one buys. It's good bang for buck, and smart enough to do the basic stuff I need it to do. It's on my ToBuy list, with another millions things of course. |
| Vince:
--- Quote from: pcprogrammer on December 31, 2022, 08:23:12 pm --- --- Quote from: Vince on December 31, 2022, 06:36:14 pm ---55minutes wow ! Will be watching it for sure but not right now.... ... so I guess it starts by watching this video.... --- End quote --- 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. --- End quote --- OK I have watched his video !!! Wow... it was Shariar grade : fast paced, speaks at the speed of light, barely the time to breathe, and packed with interesting and relevant stuff... so much so that the 55 minutes feel like 5 minutes. Excellent video, thanks for the pointer ! :-+ I am the perfect audience for this video... this Adrian really looks like he knows his business with all the old machines he worked on... All I need now is a video that's slower paced, calm, and targeted specifically and entirely on how to operate that IMD S/W, concretely. But I feel confident enough to start messing with disks and drives and IMD now.... The only mistake I can't afford to make, is to wipe or damage or mess with my precious system disk.... sure, but OTOH how could I possibly damage it, since I will enable the write protect thingy on the disk, and of course will only ever ask IMD to make read operations on that disk, no write operations whatsoever.... so what could go wrong ? OK I am motivated, I will soon start playing with all that, stay tuned.... 8) |
| m k:
Me too. I'll pack a bit for those who don't. Starting from the top. Topmost is a track, one round starting and ending with an index hole, green floppy of the video still has it. First important parameter is here, the rotation speed. The drive is pretty much just a spinner, the controller does practically everything. So the rotation speed must be so slow that all data can be written before the index hole appears again. On the other hand the speed, writing or rotation, can't be too fast or the head can't flip those bits of ferro magnetic material on the disk. It must also obviously match with the other drive that occupies the other end of the information exchange. Next are sectors, just partial of a round track, like the name says. This is the level where software operates. Only special thing here is interleave, it's just an order of those sectors. Early day operations were so slow that interleave was sector count. So in practice sectors were against the rotation direction and only one sector was read during one round. Here only meaningful parameter is minimal interleave, but even that can't really be solid. There is always a possibility that operation is interrupted and later is too late. So interleave is specified by a formatter and controller does what it can with it. Back in the day it wasn't unusual that reading a disk was slower than expected, then one possibility was that the disk was formatted as 1:1 interleave and the puter couldn't match it. At this level there are two kind of operations. Sector operation and track operation, format is a track operation and the rest can be either. Track operation means that even if your goal is just a sector the whole track is actually operated, means also that writing is slower since all must be read first. Next level down is addendum data that the track and its sectors have. It can be used by some low level software, but even if that is the case it's usually for internal use only. Also, all that data is still just regular data, it's just outside of the data area the upper level uses as data. Early days Shugart and IBM were the main parts of the industry and their addendum data was very much enough so nobody really disagreed. Later some nuances appeared but basics are still there. The yellow background picture https://hp9845.net/9845_backup/projects/fdio/ A bit below that picture there are white background pictures of Shugart industry standard interfaces. As you can see there's only one pin for read and write, and when you continue you'll see it's actually very low level interface. The level is actually so low that you're hooked to the head directly, the drive does some level shiftings but that is all. So now we are at the lowest level that possibly is less known. A bit above yellow background picture is a white background picture that explains it quite well. Those bits and timings are what you're finally coding with your drive emulator. Means also that your emulator file is much bigger than what is the actual data content of higher level. Nowadays new emulator construction could easily use a byte or more for a single disk bit. One thing the video didn't cover, but it didn't do much with crackers either. Drive interface is not so standard that you can always expect it to be a correct one. One irritable difference is drive ready and disk change, pins 2 and 34. One extra, the red stick Adrian is poking his puter parts is actually an adjustment tool. And end of a pointer is a hex key for stuff like adjustable coil with ferrite heart, usually used in CRTs. |
| Vince:
OK we got progress this evening ! But it's 00H45 here and I am exhausted and really must go to bed so I will be quick sorry. I started playing with IMD / ImageDisk to get some practice operating it. Using the HD drive in the vintage machine to begin with. so I first messed with some random HD floppies. I eventually was successful in reading one (stumbled upon the first install disk for Windows 3.11 , that will do), analyzing it, make an IMD image file from it, and using the image to write it to a blank HD floppy. That floppy would then work.... woohoo. So then I moved on to reading the precious boot disk that came with the programmer. Yes, it's an SD disk but if I understood well what Robert and Adrian said... the smaller heads of the HD drive should be able to read the SD disk just fine, and reading that disk is all I want / need to do. I made sure the disk was write protected just in case, and it was. So off I went, I analyzed that disk with IMD, it detected it as I expected it to : 16 sectors of 256 bytes rather than the usual 512byes sectors on a regular computer disk. Then I read the disk to make an image of it... and sadly it found 6 tracks it failed to read : #37, 61 to 64, and 77, all only bad on one side of the disk, not both. So the first half of the disk is good, might be why it manages to boot regardless, I guess. So then I installed that " HxC floppy simulator S/W " that Adrian showed in his video, so that I can see the contents of the disk. I wanted to see if it was full of garbage or if the read was indeed successful and there were some meaningful stuff in there. Meaning I easily found : found an awful lot of ASCII text in there, as I had hoped ! :-+ I found at a glance : 1) The version number displayed during boot on the video output : " 5.40AP ", so that adds up. T 2) Found evidence that this boot disk is most likely for a 5000 model not a 3000 one ! :o So the label on th disk is 100% wrong then. It's not just the revision number they got wrong (it says v5.5ARP) but they alos got the model number wrong ! 3) Strings showing a list of PAL/GAL chips, and EPROM 27XXX chips hmmm !!! :D 4) tons of strings that make up the countless menus and messages in this thing, related to programming, data transfer etc... So it's all very interesting ! I have a programmer whose F/W thinks it's a 5000 model, with a boot disk that also is meant for a 5000 ! Weird, but super cool. No wonder why the MSDOS S/W was not happy seeing a 5000 model when it was only designed for the 3000B model ! It's also clear that the list of chips the programmer can handle, and the definition for all the menus / UI, are stored on the disk, not in the programmer's F/W. SO now the next step is to write a few different boot images to a DD disk and try them on the programmer. But that will require to remove the SD drive from the programmer and put it in the Vintage PC. From what I read on the French forum, it's not quite clear if that drive can even work on a PC. It may or may not. It may only work on Amiga systems. HxC detected the image disk as using either Amiga or ISO MFM or ISO FM standards, which confirms the Amiga thing at the least, but does not tell me if it might work on a regular PC machine... That will be for tomorrow ! EDIT : suddenly I realize : I don't think I came across strings describing all the 4 letter commands used to control the programmer via the serial port... so either they were written in the sectors that IMD failed to read, or it's implemented in the programmer's F/W. Can't wait to have one of those cheap USB chip programmers to read the programmers EPROM, to see if the serial commands are in there, and what else might be there as well. My gut feeling is that the F/W mostly contains only the stuff to handle the remote operation via serial port and GPIB, and also the // port (3 choices, how luxurious...), and not much else. The EPROM is not a big one IIRC. |
| Navigation |
| Message Index |
| Next page |
| Previous page |