Vintage chip Programmer : " Micropross ROM 3000U "

[Vince]

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.

You are assuming it's a straight cable aren't you !    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]

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.

No pigs here ! 

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]

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.

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

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

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.

[m k]

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 !

It's not stone carved.

Back in the day things were a bit different, even that everything were pretty small, compared to what we have now.
It's quite possible that one part is not altered and keeps its old numbers when other part is giving new numbers to all.
So a marketing issue and clearly invisible is actually nothing at all.

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.

Amiga is very different, one easier possibility is ready/change difference.
It's also possible that your read errors are deliberate, for that you need a sector image with some of addendum data.
One used copy protection method was putting up wrong track or sector numbers.
One other was swapping CRC data.
On the other hand, four errors, one after the other is not a good sign.
Flip the diskette door open and check the disk visually, can you see anything alarming.

For what Amiga is very good is exactly these situations.
Since it was a gaming machine first, it has a hard wired copy protection something.
It's case is that it can read something it can't write, the name of the thing is long track(not GCR) and it reads from index to index no matter what and software does the rest.
Against writing the same there is a hard wired timer that is flipping much earlier.

First level of testing is pretty easy.
Just swap drives and check how disks are spinning.
Drive ready, disk change and motor on are what you can test without any actual readings.
Scoping pins 2 and 34 will show something also.

One other thing.
In case you think your data is missing something, try XOR 0xFF everything.
Text is obscured that way yes, but not enough, you'll learn to see its presence.

[Vince]

Amiga is very different, one easier possibility is ready/change difference.
It's also possible that your read errors are deliberate [..]
One used copy protection method was putting up wrong track or sector numbers.
One other was swapping CRC data.

Oh no, that would be very nasty !!

On the other hand, four errors, one after the other is not a good sign.
Flip the diskette door open and check the disk visually, can you see anything alarming.

OK tried that. Removed a few specs of dust from the surface....and tried reading the disk again :

1) All 6 tracks that read bad before, read just fine now ! ... but now I have a new read error, on track 76/1...
... i.e. the track right next to the 77/1 that was bad before, so there must be something wrong in that area of the floppy.

2) So removed one more speck or two of dust..... now 76/1 is good but it's now track 60/1 that's bad. No read error per se, instead if complains that " Could not determine interleave ". Whatever that means... it can't be good anyway, I guess...

3) Seeing as the errors were random, the errors clearly could not be there intentionally, it was just a falky disk, but it seemed to improve the more I read it so... I though maybe if I read 100 times I might get lucky and eventually get a 100% error free read, at least once... I didn't have to wait 100 times though : the very next read attempt was the one ! 100% error free, look at that !!! 




Needles to say I now treasure this disk image... it will let me make good disks.
The original disk looked indeed really bad.. sure the dusty did not help, but the disk surface itself looks very tired : lot of circular marks, as is the drive heads actually were dragging on the surface while operating...  There are also a few "dots" tat look like tiny specks of dust, but aren't : they look like tiny dents in disc, as if the heads impacted/crashed into the disk while it was not rotating. I don't know if that's even technically possible, I am no drive expert... but it does look like that.

So next, I wrote that good image, to a 1.0MB DD disk... using the HD drive in the PC. Disks are NOS so unlikely to have much "data" floating around that would confuse the programmer's DD drive. Worth a shot anyway. So I made that disk, then read it back with IMD... no errors. Then wanted to compare the two images to make sure they are identical, but IMD does not seem to offer this feature, crap 
So I just went ahead and sticked the disk into the programmer to see if it could boot from it or what !
Well... works just fine, it boots on it happily and I can still talk to the programmer using a terminal, still works perfectly !

So that's cool, sanity checked passed with flying colours, we can create and write images now ! 

That's all for now... 00H45 here, going to bed quick. But tomorrow is friday already, so we will have more time to play with this thing ! 

First level of testing is pretty easy.
Just swap drives and check how disks are spinning.
Drive ready, disk change and motor on are what you can test without any actual readings.
Scoping pins 2 and 34 will show something also.

Hmmm, looks to me like you know the H/W part o these old drives quite well... hopefully with your help we can get something working over the week-end...

Oh forgot... one last thing. I found it strange that a DD disk is 1.0MB but all the disk images I was given for the programmer were only 600+ KB i size. Such a waste a precious storage space just didn't make any sense. So I thought hey.. maybe it's formatting problem... 1.0MB might be valid only for PC formatted disks, but since the programmer uses a different format... the total available size might be different as well.

So I made the calculation : Two sides, 80 tracks per side, 16 sectors per track, 256 bytes per sector.... 2 x 80 x 16 x 256 is about 650KB ! NOW it does compute !!!   


See you later.....   

[pcprogrammer]

The 1.0MB is unformatted space. The formatting takes away parts to store data for things like error checking.

http://209.68.14.80/ref/fdd/formatCapacity-c.html

[m k]

Hmmm, looks to me like you know the H/W part o these old drives quite well... hopefully with your help we can get something working over the week-end...

Around the board many have been banging their heads with these things through the years, so I'm sure somebody will be around and you'll be fine.

For your floppy stuff,
back in the day many things happened, open environment is open for happenings.
The actual floppy era was even worse, like paper clipping a note to a one and then putting it under a pile of chronological mail.
But for 360k floppy that was most likely just a business as usual.

It's also possible that the reason for your read errors is finally the head and its dirt, those markings on the disk have donated some material.
For that I had a flat plastic made J-hook, it reached behind the spinner part and with a sort of a cotton sock and some freon it did the job.
Cleaner disk is for personal use only, any more than that and it becomes unpractical, J-hook is also much faster.

For your possible drive things,
since you have made a working copy your real problems are none.
If your original drive stops working you can always change it to a PC drive.
Some nuances may remain but you can read and write disks with your programmer.

The earlier link with yellow background picture.
There the bottom HP format, that's probably close to what your programmer is using.

Few copy protections,
one of the nastier one I can remember was where the disk was physically damaged by punching a hole to the data area.
Obviously edges of the hole were not level so it had a possibility to damage the drive.
It didn't help that the disk had to be accessed during every start and data was written over the hole.

One other was for the hard disk, there data was written where normally was nothing.
Means that you can't swap or format the drive because that extra data disappears and then the disk is not accepted anymore.
Luckily it was just a plain text and a hacker nature of an eager repair man revealed that.

[Vince]

OK, I pulled the floppy drive of both the programmer and the computer. Pics below.

First the HD drive in the vintage computer : it's the usual flimsy / cheap style, made by ALPS. First strange/suspicious/ worrying thing I notice, is the total absence of any jumper at the back.
Also, the sticker says it's an IBM part number.... so it ads up. Bloody IBM set the configuration of the drive in stone, to suit its Aptiva machine.



Second, the programmer's DD drive. It's the opposite of the HD drive : weighs at least twice as much, beautiful die cast alloy chassis like the old 5.25" used to have,, cool stepper motor to spin the disc, and a big ass motor to move the head, in contrast with the minuscule ridicule tiny motor at the back of all these flimsy more modern drives.
Also has plenty of jumpers, on the side not at the back, see pic. 6 of them, which read : S0 S1 S2 S3 SH AH 




I understand floppy controllers can address up to 4 drives so drives have jumpers to be set as one out of these 4, so I guess S0 to S3 is meant to tell the controller which drive number it is.
Currently set to S0 which makes sense I guess.  However good luck figuring out what SH and AH mean. 
Drive is from BASF, so German... but "Made in Japan" none the less.

So first I tried plugging the HD drive into the programmer. Since that drive has zero jumpers, I didn't have much to think about.
Programmer didn't like it at all : upon power it up, it beeps / complaigns, and does nothing at all with the drive, it just won't touch it.... no noise, no LED, nothing.

Then more interesting, I plugged the DD drive into the old computer. No go either here : BIOS complains about it at boot and forces me to modify settings.
BIOS offers me only 3 choices, none of which match the drive. I have to choose from :

3.5" 1.44MB
5.25" 360ko
5.25" 1.2MB

At boot the BIOS recognizes it, or default to I should say maybe, 5.25" 1.2MB, as drive B not A !

Whatever. I I booted with that setting. MS-DOS does boot, but when I try to select drive A:, it fails miserably so I have to go back to the hard drive instead.


So it's not looking good at all, the DD drive is too custom and old to work with the custom BIOS of the custom motherboard of this 100% custom old IBM computer.

Too much work figuring out the DD drive and IBM BIOS... too costly to buy a different vintage computer with a standard BIOS that could accommodate any floppy drive type...just so I can try to maybe, with no guarantee whatsoever, manage to make use of the oddball DD drive of the programmer.

No... in the short term, the quickest and cheapest way out is to keep doing what I have just done yesterday : write the SD floppies with the HD drive, knowing my box of DD floppies is NOS so blank, no old data on them to mess things up when reading t back after having written an image on it. Worked just fine with the first boot disk yesterday, so although it's not reliable 100%, it appears to work well enough to let me go further with this programmer.... so that's what we will do.


It's frustrating because as far as I understand it, that guy on the French forum who restored hi 5000 model, DID put the programmer's DD drive in his computer to write the image, and it worked just fine.... HOWEVER the drive in his programmer is NOT at like mine ! Look below, he took a pic of it : it looks very different to mine, and very very similar to your cheap HD drive, similar construction, and setting jumpers at the back, with different marking than mine, notably  an " MM " jumper, a " READY " one and a " TTL / CMOS " one.

Made in Japan by " CHINON ", model FZ-354.



He did say that eventually this drive was faulty (would give errors towards the end of the disk) so he replaced it with bog standard DD drive which modified a little bit IIRC.

So I guess his programmer was a bit more recent than mine.


Anyway, so now the next step is to write a DD boot disk (with the HD drive then) for the ROM3000B image that I was given, which matches what the MS-DOS remote control S/W expects and is meant to work with exclusively.

But before that, I must figure out how to convert the image file into the IMD file format so IMD can make use of it. I saw a few convert utilities that came with IMD. There is one called " BIN2IMD " for example. Trouble is, I don't know what is the file format of the image files I was given... I don't know what formats exist out there. Is there any to find out ? Maybe read the image file with a HEX editor to see if there are some metadata at the beginning of the file with some ASCII text telling us what format is being used ?!

I don't know... 

[m k]

Your DD drive booted using your HD drive made disk.
Your DD drive can't read HD contents.
So your new disk is DD.

SH/AH seems to be head load.
AH is automatic, so no need to worry.
It's an old thing and hardly any new drive has any.

Alps DF354H has both densities.
So it can do currant DD disks.

Both 3.5" drives are 80 track machines.
80 and 40 track differences are 5.25" stuff.
3.5" DD and HD differences are writing density, not track density and disk quality or capacity.
3.5" DD has 9 sectors when HD has 18, that's PC's 512 byte sectors.
So your 16*256 is bit less than PC's 720k formatted DD disk.

Connect HD drive to programmer using connector after twisted section.
Connect DD drive to PC using straight cable but swap short from S0 to S1.

HD drive knows that DD disks are available but programmer doesn't know that HD exists.
If HD drive behaves the programmer is completely happy.

Now that you have that new boot disk, try reading it with Linux, nothing special needed.
At least old PC controller has 256 byte sectors but Widows is not supporting it.

[Vince]

OK !!!


Thanks MK for the help, we now have results here at Vince's Lab, I am pleased to report !

1) Programmer's DD drive now works in the old PC
2) I was able to use IMD to successfully write the system disk image to a DD disk
3) Then tried that disk : plugged the DD drive back into the programmer : it can boot from it just fine and I can talk to the programmer with the Terminal just fine... it works !

So that's super cool ! I can now WRITE proper DD disks, making progress here !

4) No joy with using the HD drive in the programmer though, it just beeps at it in a very condescending way that I dislike...
I think the controller board in the programmer just is not modern or sophisticaed enough, or simply not setup to handle an HD drive and that's it.

So I will keep having to swap the DD drive from the programmer to the PC, and back... or just keep writing them with the HD drive since the DD disks are blank/NOS and it appears to read back just fine on the DD drive.... that will make my life easier for now. Anyway, I don't have to write a millions disks anyway... I have only 3 or 4 disk images to try out, so I will just make these 3/4 four DD disks then I am done, I will be able t leave that DD drive in the programmer for good, where it belongs.

Would be cool if I could find a DD drive to buy somewhere... if someone in the Euro zone (i.e. no customs and cheap shipping...) has one gathering dust.....

OK so now I need to write the images I was passed, using IMD... so first I need to figure out what format these images are using, so I can try to cnvert them into the IMD format.  Lightbulb moment = maybe I could just use that HxC S/W ? As adrian said it can handle lots of image files format... maybe it will auto detect my images, and then rewrite them in the IMD format.... that would be cool wouldn'it...

OK that's some more to play with.


Oh forgot : I also added a floppy drive to my main / Linux computer ! 
Will help me work on disks directly from my main computer rather than having to transfer stuff via the network to the vintage PC so I can use its drive.
Also, I have been meaning to add a USB attached floppy drive for some time now, to read screen captures from my Tektronix TDS544A scope ! Well, no need for a USB anything now, I have an actual drive available !

Forgot #2 : MK, yes that would be super cool to be able to read the DD disks on my main Linux machine indeed !
However I don't know how to do that. I guess I need to use the MOUNT command and tell it what file system to use... but since it's a custom file system, I don't know how to tell Linux the parameters to use for that to work... Need to do some googling / reading and forum asking I guess... but yes if we can do that, imagine how marvelous that would be to actually be able to see all the files in these, open them, write to them without causing CRC errors.... FANTASTIC !!! 


ON ANOTHER NOTE !

Changing subject now... I spent an hour looking at the MSDOS S/W on a HEX Editor, I just can't help. It was interesting. Here is a summary of my findings, looking at all the ASCII strings I could find :

1) The first 75% of the file are binary, not one string. Probabyl the "packed" executable that DC1MC found in that file.

2) I see mention of a " ULIS " compiler... does that ring a bell DC1MC ??

3) The S/W can

- Read/write chips, set start and end addresses, set programming voltages, and detect a good variety of electrical fault conditions (shorts of all kinds...), check if the part is blank, verify / rad back the chip, check CRC.

- Modify the settings of the UART

- Use the DD drive to format disks, and copy them : "insert source disk... remove it, insert target disk " etc...

- Checks that the programmer booted properly.  My programmer returns "00" when asked about that, and a return value of 00 IIRC is a kinda standard value to mean that everything went well eh ?  So that's good.

- Can check if the H/W of the programmer is OK : "System ROM " (The 6502 CPU's EPROM I guess), as well DRAM and SRAM and also "Hardware"... I guess that refers to the 3 analog I/O boards.

- A string that says : "Insert PC S/W Disk #3"  that's bad... means I might be asked to insert a disk I don't have, in order to be able this or that...

- A string that says :  "Requires Board IO2_5" : so that's bad as well, means some stuff can only be done with this board. Either they mean a different board than the one I have, or they mean just a newer revision of a board that's already there. I guess "IO2_5 means " second analog  I./O board (there are 3 of them), version 5 ? something like that... I could pull the boards to see what markings  are on them to help suss this out, I guess...

- A string that says : "Function not implemented in programmer " . Now that's interesting... the S/W seemed to be meant to interact strictly with a ROM300B model, so it should be able to take for granted what features the programmer can or cannot handle... This maybe means that it CAN handle more than just the ROM3000B model ? That's interesting....

It can handle the following input file formats, most of which I have never heard of, because well, I am not that old I guess... Note the three Tektronix formats, cool but weird / surprising ! 


Binary
ASCII - BNPF
ASCII - BHLF
ASCII - B10F
ASCII - Octal
ASCII - Hex
MOTOROLA Exormacs
INTEL HEX - MCS 86
HP 64000 absolute
TEKTRO S8000
TEKTRO S8002
Extended TEKHEX
SIGNETICS absolute
TEXAS SDSMAC
MOSTEK
FAIRCHILD
RCA COSMAC

- There seems to be this concept of a "Board" file. I see strings like

"No Board file ! "
"Storing Board file"
"Restoring Board file"
"Transmit Board file".

So I am thinking maybe this refers to a set of parameters sent to the programmer to tell it how to configure all of its I/O board in order to work with this or that particular chip.
Just a shot in the dark...

- Found two blocks of text that list 4 letter commands (what PCprogrammer must have seen the other day).



I rewrote them and ordered them alphabetically, 49 of them. This makes it easier to see that there are some lone commands (like BOOT and HELO that we already knew about) but that the bulk of them are spread into a few groups of related commands, which all start with the same two letters. Here it is.


BDBL
BDCK
BDIL
BDLO
BDPR
BDPS
BDVE
BDVF

BOOT

CFPR
CFPS
CFRS
CFTC
CFVP

CLOS
CLTP

DFPA

FDDD
FDDI
FDFR
FDL2
FDLB
FDLD
FDLO
FDW2
FDWB
FDWD
FDWR

HELO

INRE
INTR

MECK
MEFI
MEMO

OPEN
OPTP

PRFU

RSFR
RSPA
RSRB
RSRE
RSTR
RSTY
RSVE

TIWC

TSBD
TSDR
TSRO
TSSR


So I guess they decided to use the first two letters to designate the subject/object being worked on, and the last two letters code the type of action that's going to be applied to that object. Sounds like a reasonable / plausible assumption.

Anyway, we can see that one of the group starts with "BDxx" .... BD like... BoarD eh ? !
So we have a set of commands to work with these "board" thingies.

One group starts with "FDxx", so that could mean "Floppy Drive/Disk" I guess...

Then "RSxx "group could mean "Receive Stream" ? So the "TS" group would be for Transmitting then.

The "MExx" group maybe has to do with MEmory.. maybe commands to test the programmers RAM at power up.

At this point I think it's time to look at the 5000 manuals I was passed, to see if the commands listed there, matches the ones I found here, how to use them, and if there are more commands than what I see here.


So you see ? We can learn a lot of things, and gather clues, just by having a quick look with a HEX editor... I just love HEX editors !!!   

[m k]

Would be cool if I could find a DD drive to buy somewhere... if someone in the Euro zone (i.e. no customs and cheap shipping...) has one gathering dust.....

Your BASF drive with its head load setting is so old that it's archaic.
If programmer's controller is equally old it's poking in the dark with possibly any drive you may find.
One info was that some BASF drives have RDY to pin 6, PC drive is missing that.

Is the programmer equally upset if you try it without any drive?

There are not very many possibilities and if you have a spare cable to destroy you can start doing some connections.
You can also remove the cover of HD drive, there should be at least a place for jumpers, try to find drive select 0 or first or 1st of 4.
People have modified Alps DF354H to work with Amiga so it's not that different.

I guess I need to use the MOUNT command and tell it what file system to use... but since it's a custom file system,

It may not finally be that custom.
I wouldn't be very surprised if it's recognized right away.

You can also try some live distros.
Some years ago Knoppix had a very capable H/W sniffer.

[Vince]

Would be cool if I could find a DD drive to buy somewhere... if someone in the Euro zone (i.e. no customs and cheap shipping...) has one gathering dust.....

Your BASF drive with its head load setting is so old that it's archaic.
If programmer's controller is equally old it's poking in the dark with possibly any drive you may find.
One info was that some BASF drives have RDY to pin 6, PC drive is missing that.

Oh you misunderstood I think ! 

I am looking for more MODERN DD drive, to install in the vintage PC not the programmer !
So the PC should be able to handle that.
The goal is to have a "modern" DD drive in the PC so that I can leave the ancient DD drive in the programmer where it belooooongs.
This way I would not have to swap the programmers all the time between the PC and the programmer, because it's a pain !!!

Is the programmer equally upset if you try it without any drive?

Well I don't have the video output (not possible, too much mess on the bench atm), but as far as the sound track is concerned then yes, it behaves exactly the same : one loud BEEP and that's all....

There are not very many possibilities and if you have a spare cable to destroy you can start doing some connections.

Oh hell no, no reason to waste time and effort messing with that, given that I do not HAVE to...
Again I think it's just that the floppy controller in the programmer is just not capable of handling that HD drive.

You can also remove the cover of HD drive, there should be at least a place for jumpers, try to find drive select 0 or first or 1st of 4.

Hmmm.. clever, didn't think of that. Alas I cracked it open no jumpers to be found, there is no room for that inside, the mechanical stuff takes all the space.

People have modified Alps DF354H to work with Amiga so it's not that different.

Interesting....

I guess I need to use the MOUNT command and tell it what file system to use... but since it's a custom file system,

It may not finally be that custom.
I wouldn't be very surprised if it's recognized right away.

Alas no luck. I checked /etc/fstab to see if it was set to use a predefined file system, but no, it looks like it's in " AUTO " mode :

/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0

... which sounds promising. Unfortunately it fails to mount the disk, MOUNT returns an error code #32 which means " Failed to read superblock ", whatever is a " super block "....


OK I have some bad news : I stilll don't know how to convert the few disk image SI have to the IMD format, but what I thought I could try to do at least, right now real quick... is to have a look at these images with a HEX editor. Turns out it works just fine. So I loaded the image that supposedly is for the ROM3000B, as it was shipped in the same directory as the PC S/W that requires, and the latter requires a ROM3000B model as we all know by now....  So the bad news is that the ASCII strings in that image look more like.... a 5000 model, version 7.0AP ..... 

So I am doomed, I have ZERO 3000B images !


Anyway, while I was in there, I checked for a slit of commands, and found one :



It's not 100% the same as what I found in the PC S/W  EXE file : the system disk is missing some commands, but also has some that the PC S/W does not...

Here it is summarized :

Absent from the disk :

BDPS
CLOS
CLTP
OPEN
OPTP

Absent from the PC S/W

CFAI
EEWR
EERD
RSLI 
TSPR


It's getting late already, 23H30, that's all for today, satuday is already over, time flies when I am working on this programmer   

More to come tomorrow hopefully...

[m k]

Oh you misunderstood I think ! 

I am looking for more MODERN DD drive, to install in the vintage PC not the programmer !
So the PC should be able to handle that.
The goal is to have a "modern" DD drive in the PC so that I can leave the ancient DD drive in the programmer where it belooooongs.
This way I would not have to swap the programmers all the time between the PC and the programmer, because it's a pain !!!

Good for me, but even better for you.

You don't need to do that, your HD drive will do authentic DD disks, it's a dual mode machine.
It's a bit rate, a length of a bit, that is different between those formats, your HD drive can do it.
It's clocking bits in, not rotation speed that is the factor.

Inside the drive,
close to pin 1 of the interface connector are 3 solder spot jumpers, round pads with a cut in the middle, now DS1 is shorted there.
Front side, the corner opposite to write protect hole, there are small push buttons, or maybe one and the other corner has two.
Buttons are write protect, disk present and DD/HD disk.
Force that DD/HD button down and you have a permanent DD drive, no matter what disks you are using.

Is the programmer equally upset if you try it without any drive?

Well I don't have the video output (not possible, too much mess on the bench atm), but as far as the sound track is concerned then yes, it behaves exactly the same : one loud BEEP and that's all....

...
Again I think it's just that the floppy controller in the programmer is just not capable of handling that HD drive.

I wouldn't be so sure.
Possibly the HD drive is just not present, that's a good sign.
You can change that DS1/DS0 selection permanently and continue using the drive in PC with the 2nd connector of the cable.
With some luck that's all you need to do.

Generally I would be more concerned about the well being of that BASF drive than anything else.
If you can't find a replacement your programmer's days are numbered.
On the other hand, those drives are extremely reliable, maybe something else breaks first.
I read that some drives have some leaking caps.

If you want to check the initial state of the drive in the programmer check levels of pins 2, 4, 6 and 34.
You can also check the same with interface cable disconnected, those low side pins are not very standard so their direction can change.
Newer interfaces have much more differences but I guess those cases can be left aside.

Is the earlier mentioned big zip file available somewhere?

[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 

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

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

[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 

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

[m k]

File came just fine without account logged in.
ROM3000.img is a standard raw image, HxC will read it and then you can export it to imd format and write using ImageDisk.
You could do that with linux dd since it's an exact dd output file, but for that you need a correctly formatted disk.

TSDR,
maybe it's a TeSt DRive and includes a write test.

[Vince]

OK, been trying to troubleshoot this for the past 3 hours now...

First tried to check if the DD drive was at fault or not, so :

- I transfered it to the PC along with is original ribbon cable, so as to test the complete setup.
- IMD chocked on it : when I tried to run an analysis, it simply froze immediately, had to reboot the PC.
- Then I tried writing an image to the disk. This time IMD did not freeze, but it didn't try to spin the disk, it immediately showed an error : " Failed to receive interrupt from FDC ".. something along those lines.
- So I thought hey, maybe a duff cable. So instead I used the cable from the PC, then swithced the DD drive to S1 instead of S0 because somehow the cable in the PC is twisted even though it can only connect one drive not two, go figure.
- Well that did it : IMD is now happy with the drive. I wrote an image file to the disk, and rad it back , with success. Zero errors or anything out of the ordinary.

So the drive looks good and it's just a bad cable, I was overjoyed.

So I pulled another cable from my stock.... but it would not plug into the FDC board somehow.... then I eventually realized that was because... well I am sure MK and PCprogrammer know why... this old cable had one of its pins FILLED with a plastic plug. So çof course it could not plug properly....
So I tried yet another cable, this time with no plug in it... but it too would not go in.
Access to the header on the board is next to impossible : the rear panel of the programmer is so close to the connector, you can't see what you are doing and can barely manoeuvre your fingers in there, it's a total nightmare. So I could not get the freaking connector in, no matter what. Pulled an inspection mirror out of my toolbox, a flash light, and inspected the pins... one was bent. Used an angle dentist pick to straighten it... was a pin but worked.
Now I could plug the cable.... but the programmer still beeps just 3 seconds after power up and does not even try to do anything with the drive : no spinning, no LEDs no nothing.

So I unplug it and inspect the pins again with a mirror.... there see that somehow one of them is PUSHED IN quite a bit, so of course not making a reliable contact, or no contact at all.
I guess this was due to me trying to plug that cable that had a plug in one of the pins... the plug just pushed the corresponding pin on the socket on the board.

So only way to fix this is to take the FDC board out, which is no fun at all.
Once the board was extracted, I could push the pin back into place. Put the board back in, plug the ribbon cable... no joy, programmer still beeps immediately and ignores the drive.

Now throw a BOOT error code #26 at the terminal... that's new, yet another code.... so we have so far 4 BOOT error codes then : 1E, OF, 25 and 26. Great.....

So I am not happy.... I just don't know what to do... which is not good. It means I will button it back up in agner, put it aside for several years then evnetually scrapit, which would be a shame given how close we were to getting something done with this thing, pfff...

So I will try to concentrate on the bright sides :

- preicous programemrs DD drive appears to still work just fine
- We have made severa good, error free copies of the boot disk.
- Despite all these boot problems, the CPU / programmers remains alive and responsive at all times : it still talks to me via the terminal.

This project is getting really messy.... the vintage PC and programmer in bits all over the bench, and that's without a monitor attached to the programmer's video output.

So since it looks like this is gonna stay on my bench for a while... I need to make this mess. less messy.
I need to be able to monitor the video output with the programmer's "lid" in place, no big breadboard anymore, and no external power supply powering the GBS video converter board, and no huge 30+ inch monitor.
I need to make as I said before, a tiny PCB to replace the brad board. I need to shove the GBS bvoard inside the programmer, I think it might fit, and power it via the programmers 5V supply. I need to get a tiny VGA monitor that takes no space. Either an old 14/15" , early LCD computer monitor, or even better, may be cheap modern tiny 10" or something, LCD screen, after all the built-in CRT monitor of the 5000 model is tiny as well, so hey...

I need to button up the vintage PC and get a 15" LCD for it as well, to gain space on the bench.
I was thinking maybe just the one PC monitor and share it with the programmer with a switch... but I really want to be able to see both video output at the same time.
Then I need to make space on the bench generally... so that's easier said than done. But I have at least a couple square feet of components to sort on the left side of the bench... need to get cracking sorting them. I really need to get some gear out of this house to gain space, it's getting critical...  my big haul the other day really put me in trouble in this regard 


OK so the plan now...

1) Need to be able to monitor the video output at all times while trying to debug this thing. So need to order a selection of small and tiny proto boards to replace my boards.
2) Look in the 5000 documentation to see if I can find what the BOOT error codes mean.
3) No more playing with disk images for now.We have a good known to work boot disk(s), we don't need any more disks to work on our boot problem...
4) I am well pissed.

[Vince]

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.

Hi Robert,

Oops our posts collided... my bad fr taking so long to write my messages.

Sadly no easy way out for me, it's not a cleaning problem... as I just posted, the programmer doe snot even TRY to rad the disk, doe snot even spin it.  That, plus the fact that I tested the drive on the PC and it reads and writes images flawlessly. So looks I have an actual problem 

[Vince]

File came just fine without account logged in.

Good to know ! So now I know I can use this Google Drive thing to share files with people with people without them having to create an account to any website. PLus, since it is MY drive... the link will not time out / disappear in a week or a month or 6 like it does on third party hosting websites... nope. As long as I don't delete it myself from Google Drive thing, it will still be there in years.

ROM3000.img is a standard raw image, HxC will read it and then you can export it to imd format and write using ImageDisk.

Yep I did actually just that last night ! 
But I have not tried writing that file using IMD because... well, shit happened last night as you now know, so I had much bigger problems to think about ! 

You could do that with linux dd since it's an exact dd output file, but for that you need a correctly formatted disk.

I don't understand... I thought the whole point of dd was to make a binary image of a disk, just like IMD does, so there was no need to format the disk. Image would contain whatever formatting was there originally... just like I was able to make boot disk using IMD on DD disks that were blank, or maybe pre-formatted but definitely not with the format the programmer uses...

TSDR, maybe it's a TeSt DRive and includes a write test.

That's an idea ! 

[m k]

And you have a correctly positioned drive select jumper?