Commodore 8050 dual disk drive

[SiriusHardware]

I've just updated my Arduino IDE to the same version as yours - don't like it much to be honest, change for the sake of change as usual... downloaded the sketch I posted in #52, loaded it and... compiled it with no problem. Weird.

Which OS are you running your Arduino IDE under? Windows? Linux? When you loaded the sketch, did you still have the other sketch (of the earlier version) open somewhere? It sounds as though when you loaded the new one, it was added to the old sketch rather than being loaded standalone. That would obviously lead to duplication of labels / definitions, of which only the first one would be reported at compilation time.

[ScottishColin]

OK - my Arduino bad. Turns out if you have two sketches open in different tabs with the same variable, it doesn't like it. You probably already knew that - I assumed they were different tabs and not interacting with each other.

Who knew.

See attached.

Colin.

Originally Posted by SiriusHardware

I've just updated my Arduino IDE to the same version as yours - don't like it much to be honest, change for the sake of change as usual... downloaded the sketch I posted in #52, loaded it and... compiled it with no problem. Weird.

Which OS are you running your Arduino IDE under? Windows? Linux? When you loaded the sketch, did you still have the other sketch (of the earlier version) open somewhere? It sounds as though when you loaded the new one, it was added to the old sketch rather than being loaded standalone. That would obviously lead to duplication of labels / definitions, of which only the first one would be reported at compilation time.

[SiriusHardware]

Actually that is not normally an issue. Must be one of the new, 'improved' features of the newer version. In earlier versions whichever one is in focus is the only one which exists as far as the compiler is concerned. I often have two sketches open, usually because I need to remember how on earth I did task X the last time I did it.

Will have to look later, busy just now. In 'Human' mode the reader will tell you the checksum of the code, if you load the matching original ROM file into your STAG's software does the STAG's hex editor give the same checksum?

[ortek_service]

Originally Posted by ScottishColin

OK - that didn't work with my STAG but attached is the output via PUTTY from the Arduino sketch.

Colin.

When you say your Stag didn't work, what exactly was the symptoms?

Did it actually let you read the ROM, or did it give an error message?
- As it was trying to be 'too-clever' and doing some pin-checks etc that you couldn't make it ignore?
(With Dataman's etc. I've just connected, via 10k resistors yo ground, any pins that it is expecting to be connected to the selected-IC (but adapter I'm using isn't connecting these to the IC)

Otherwise, was it just reading all FF's etc?
- I would have expected that if you'd pulled-up (after isolating from programmer socket) the active-high CS1 pin (20) to the IC's Vcc (Pin24), via a suitable resistor (or probably even directly connected), then there shouldn't really be much to stop it outputting the data of the address that is being selected on the address lines.

[SiriusHardware]

You were waiting for me to catch up I see, Colin.

Your 'Human' readout from the 06 ROM gives the exact same checksum as the '07' file from the website does when loaded into a hex editor, and the readout from the 07 ROM gives the exact same checksum as the '06' file from the website does when loaded into a hex editor, so that was a pretty worthwhile exercise as it means the ROMs are almost certainly intact. (There are ways in which the ROM content can be wrong and still give the right 16-bit checksum, but the chances of that are extremely small). I wonder whether you can notify the website owner about the file labelling error? That is bound to mess someone up at some point.

Good spot by Tony noticing that the CE signals were active high, and that was where the ability to read the ROMs with the Arduino really helped, due to its ability to go past all of that and just read the data. That's another useful tool for your PET toolbox, even if it isn't quite as swish as some of the other ones you have.

So now, with everything back in place, are you still consistently getting the three-flash error?

[ortek_service]

Originally Posted by ortek_service

But strangely, Commodore themselves seemed to say that the 2564 EPROM was an alternative to the 2364 ROM's:

>>

Originally Posted by ortek_service

>>
And the 2564 is listed as alternative to the 2364's in the (hand written - some in German!) Commodore 8050 / 8250 System Overview drawing, that is the 3rd page in that pdf on zimmers originally linked to: http://www.zimmers.net/anonftp/pub/c...schematics.pdf

Originally Posted by SiriusHardware

I think it very much depends on the specific location in the specific equipment it is used in. Commodore appear to have made full use of the option to define the 'polarity' of the CS pins on this series of ROMs in other situations as well. I've gone through the address decoding and it looks to be as Tony says with the two ROMs nominally mapped with active-high chip selects at Exxx-Fxxx and Cxxx-Dxxx (which roughly concurs with that slightly mangled information you found in in the manual regarding the mapping of the EPROMs). As Tony suggested there are also 'images' due to incomplete address decoding.

Yes, but as I'd said, in this case it was on what seemed to be an official Commodore drawing covering this drive, that they'd actually put '(EPROM 2564)' underneath each of the UL1 & UH1 2364 ROM headings.
So unless there were links on the PCB to select polarity of the enable (in which case there wouldn't have been much point in having none-standard Active-high CS ROM's!), then it seems they have given some rather misleading info in this case!
- Although this does have on it 'Preliminary' (Also hand-written), and it seems this page didn't make it to the service manual (version that Tony had linked to), and was only being amongst the 'Digital' Schematics' extract Colin had originally found on Zimmers.

[ortek_service]

Originally Posted by ScottishColin

Again for reference, I can't find the files on zimmers but I have them downloaded from here:

https://www.commodore.ca/manuals/fun.../ALLFILES.html

Colin.

It looks like it isn't just the part-number suffixes being swapped-over (So could result in fitting ROM's in the wrong position - Where I wouldn't expect them to do anything if reset vector wasn't correct!) that's incorrect on that zimmers-style collection of firmware.

As they also state there that the 8050 is 96TPI (When it's actually less-standard 100TPI!)

But hopefully the (hand written - some in German!) Commodore 8050 / 8250 System Overview drawing, that is the 3rd page in that pdf on zimmers originally linked to: http://www.zimmers.net/anonftp/pub/c...schematics.pdf does list the correct RM part numbers against the Upper & Lower positions in the memory map - Although this does have on it 'Preliminary' (Also hand-written), and it seems this page didn't make it to the service manual (version that Tony had linked to)

[ortek_service]

Originally Posted by SiriusHardware

>>
>>
So now, with everything back in place, are you still consistently getting the three-flash error?

Well now the ROM's (particularly the 'lower' $C000-$DFFF one that 3 flashes indicates an issue with, as reset vector in the upper one jumps to an address in the upper one to start with) appear to have been verified OK, then an error-code showing a problem with the lower-ROM is most likely down to:

• The UH1 socket (now changed, so should be OK)
• Tracking to this

(To check both of these, all pins, except pin 20, should measure close to 0R resistance from UH1 to UL1 other ROM)
(And shouldn't need to check for shorts on any of these, to other ones, if UL1 Upper-ROM is verifying itself first, before UH1)

• The Chip-select address decoding logic to UH1 pin20
  So could 'scope this, which should look similar to that on UL1 pin 20.
  - If not, then check relevant gates of UR1 74LS08 (Pins 3, 5 & 6) & UL2 74LS04 (pins 5 & 6)

[ScottishColin]

When I try to read it I get the message "Load failed. Device missing or faulty" and it doesn't attmpt any further action.

Colin.

Originally Posted by ortek_service

When you say your Stag didn't work, what exactly was the symptoms?

Did it actually let you read the ROM, or did it give an error message?
- As it was trying to be 'too-clever' and doing some pin-checks etc that you couldn't make it ignore?
(With Dataman's etc. I've just connected, via 10k resistors yo ground, any pins that it is expecting to be connected to the selected-IC (but adapter I'm using isn't connecting these to the IC)

Otherwise, was it just reading all FF's etc?
- I would have expected that if you'd pulled-up (after isolating from programmer socket) the active-high CS1 pin (20) to the IC's Vcc (Pin24), via a suitable resistor (or probably even directly connected), then there shouldn't really be much to stop it outputting the data of the address that is being selected on the address lines.

[ScottishColin]

Thank you - I was wondering whether a checksum could be carried on on the .bin files; my Stag software doesn't do that but I hadn't thought of loading it into other software.

I enjoyed the Arduino work and learnt a bit more - thanks for the help. I'm always childishly pleased when a technology thing omes together and I could read a 40+ year old ROM.

I'll get in touch with that website owner and let them know. I'll also fire the disk drive unit up again when I have some time today and let you know where we are.

Colin.

Originally Posted by SiriusHardware

You were waiting for me to catch up I see, Colin.

Your 'Human' readout from the 06 ROM gives the exact same checksum as the '07' file from the website does when loaded into a hex editor, and the readout from the 07 ROM gives the exact same checksum as the '06' file from the website does when loaded into a hex editor, so that was a pretty worthwhile exercise as it means the ROMs are almost certainly intact. (There are ways in which the ROM content can be wrong and still give the right 16-bit checksum, but the chances of that are extremely small). I wonder whether you can notify the website owner about the file labelling error? That is bound to mess someone up at some point.

Good spot by Tony noticing that the CE signals were active high, and that was where the ability to read the ROMs with the Arduino really helped, due to its ability to go past all of that and just read the data. That's another useful tool for your PET toolbox, even if it isn't quite as swish as some of the other ones you have.

So now, with everything back in place, are you still consistently getting the three-flash error?

[SiriusHardware]

I'm a little surprised the STAG software does not have the ability to show you the checksum of an inserted device or a loaded file, as it is such a very useful feature (as we have seen).

The standalone Hxd hex editor utility will checksum any loaded .bin file but it doesn't do it automatically.

Start with a freshly opened instance of HxD.

Load the .bin file with 'File / Open', browse to the .bin file and load it. Loading the file also sets the FROM and TO address boundaries which will be used for the checksum, based on the size of the loaded file.

You can also load other file formats such as Intel Hex into HxD but in those cases you would use 'File / Import' ... and choose the file type to be loaded from the selection box before then browsing to the file and loading it. Until recently (recent versions of HxD) this didn't always work too well but I think the issues are fixed in the present version.

To actually get the checksum of a file loaded in HxD, go up to

'Analysis / Checksums'

and choose 'Checksum-16' from the list. The checksum of the file will then be displayed in the narrow box under the main hex display. Note this checksum figure is NOT dynamically updated so if you edit the hex manually or load another file in, the displayed checksum will not change until you repeat the above process.

[ScottishColin]

Yes, well, having now looked at the software there is a Checksum function. Abd it uses the same Checksum you did so all checks out (unsurprisingly).

With everything back in the drive unit, I now get four flashes which isn't valid according to the manual.

Having said that, here's a link to a thread elsewhere where they say (last post) that the 8050 isn't as per the manual (but don't say what it actually is)

http://forum.6502.org/viewtopic.php?f=3&t=4285

I have 2 x 6532s on the way from Cricklewood and will see if that helps. I also have the RRIOT chip replacement PCB coming too so all hope is not lost I think.

In the meantime, I'll do some continuity checking as per post #68.

If there's anything else I can check with any other ICs with my scope or meter, I'm not giving up yet. There's a part of me that thinks the basics are OK - as in something has detected an error at least and is trying to work as designed. I hope.

Colin.

Originally Posted by SiriusHardware

I'm a little surprised the STAG software does not have the ability to show you the checksum of an inserted device or a loaded file, as it is such a very useful feature (as we have seen).

The standalone Hxd hex editor utility will checksum any loaded .bin file but it doesn't do it automatically.

Start with a freshly opened instance of HxD.

Load the .bin file with 'File / Open', browse to the .bin file and load it. Loading the file also sets the FROM and TO address boundaries which will be used for the checksum, based on the size of the loaded file.

You can also load other file formats such as Intel Hex into HxD but in those cases you would use 'File / Import' ... and choose the file type to be loaded from the selection box before then browsing to the file and loading it. Until recently (recent versions of HxD) this didn't always work too well but I think the issues are fixed in the present version.

To actually get the checksum of a file loaded in HxD, go up to

'Analysis / Checksums'

and choose 'Checksum-16' from the list. The checksum of the file will then be displayed in the narrow box under the main hex display. Note this checksum figure is NOT dynamically updated so if you edit the hex manually or load another file in, the displayed checksum will not change until you repeat the above process.

[SiriusHardware]

Nothing worse than an 'undocumented error' is there?

I haven't fully looked into it but it may be possible to use your Arduino reader to read / check the code from the RRIOT as well, if it just 'looks' like a normal ROM when appropriately connected / addressed. We'll have to have a closer look at the data sheet for that IC to determine whether that is the case.

[SiriusHardware]

I took a look at that thread you linked to in #72 - there is an interesting post by NivagSverdna (also of VCFED fame and occasionally here too) pointing out that the code for the .06 and .07 ROMs is swapped in the .bin copies held on zimmers, and it appears that this error was subsequently corrected on the copies they hold there - but I wonder where they are on zimmers if you didn't find them there? I confess I did not look, since you had already found them on that alternative site.

That last post saying that the flash codes don't apply to the 8050 but not explaining how they differ is maddening - you could do worse than join that forum and try to contact that guy to ask him for more info, you seem quite good at chasing people up that way.

[TonyDuell]

I am pretty sure the 6530 can be read as a normal ROM. At least some later versions of the firmware (like in my 8250LP) have a daughterboard in that socket containing, IIRC,a 6532 RIOT, a ROM, and 1 or 2 TTL chips.

However I'd not worry about the 6530 yet. It sits on the controller (formatter?) processor bus. It can't be directly accessed by the interface processor. The only way for the interfacec processor to test it is via the shared RAM, that bank of 8 2114s. And the diagnostics will not surprisingly test those first.

If they're socketed you might try removing the controller processor UH3 (6502),its firmware,etc UK3 (6530) and VIA UM3(6522) and seeing if you get the same flash code. Just in case on of them is doing something odd (on the other hand the interface processor is running well enough to give a flash code so there can't be something holding a data line or similar).

Might also try swapping over the 2 6502 processors if they are socketed. It would be an a odd fault for one to miscount, but...

That said, I'll mention that by far the most common problem with the digital board in these units is failure of one or more of the 2114 RAMs in the shared memory area. Alas those are not normally socketed but you might want to carefully desolder them and fit sockets (18 pin DIL). Either fit a known-good set of RAMs or test the ones you removed, it should be possible to produce a 2114 tester using the Arduino.

[TonyDuell]

I have an older version of the 8050 (only) service manual on paper. I can see what flash codes it gives.

OK, found it and checked, it's no help. Exactly the same flash error codes as the manual on-line we all have.

[SiriusHardware]

Interesting Youtube video here showing the extraction of the ROM code from one variant of the 6530 RRIOT (of which there are many, all with different fixed ROMs for different tasks, distinguished from one another by the two-digit suffix following the main 6530 part number).

https://www.youtube.com/watch?v=M3wrzpf2Lss

The presenter actually does briefly talk about using an Arduino Mega for the purpose and seems to say he managed to do it that way but then goes on to show his preferred method, of using a modern KIM-1 clone to read it, mainly because that system, being 6502 based, generates all of the native signals required by the 6530. If using an Arduino you would need to generate a clock for the 6530 either as a function of the Arduino sketch or with an independent hardware oscillator.

Even though it completely brushes past the part about using an Arduino for the job, it nevertheless does a good job of explaining the process. One problem, for example, is that no two variants of the 6530 will necessarily have their 1K of ROM mapped at the same internal address since this is part of what can be defined at the mask programming stage - therefore the method adopted is to read out the whole address space and try to identify what looks like 1K of ROM code within the data read out.

It should already be the case that someone, zimmers or someone else, already has the code read out from the specific version used in this drive so in this case all we would be looking for in your RRIOT would be a 1K block which exactly matches a known good .bin file from the RRIOT in one of these drives.

Although it would of course be great to use a KIM-1 clone for this purpose if you happen to have one, the most likely reason you would be trying to do this would be if you had a non-working system with one in, so it is always better if the reading method does NOT depend on you having a working retro system to power it, but rather something modern and widely available which you can afford to buy for a one-off use if necessary.

[SiriusHardware]

Either fit a known-good set of RAMs or test the ones you removed, it should be possible to produce a 2114 tester using the Arduino.

It probably won't surprise you to know that there is already a ready-baked 2114 tester 'sketch' (program) for Arduino. Unusually for Arduino it goes straight 'to the metal' (that is, it drives the underlying AVR micro directly for speed reasons) and will probably only run as written on an Arduino UNO.

https://github.com/Danjovic/2114-Tester

However, Colin already has two very good 2114 testers in the form of his two PETs in which the 2114 video RAMs are socketed. That should be quite a good stress test for them.

[TonyDuell]

Considering the 6530 only has 10 address inputs, just enough for 1K of ROM, I would be interested to know how the mask programming can make the ROM appear anywhere in the memory map.

It's a long time since I looked at the Rockwell datasheet for this chip but from what I remember there's a CS/ line for the 'RIOT' functions and an RS/ line for the ROM (the polarity of these may well be mask options). In the 8050 these signals come from the 74LS42 decoder at UA3. Note that only the bottom 13 address lines of the Controller processor are used, so the memory space repeats 8 times. Anyway, the RIOT stuff appears at the bottom of the memory space, the ROM at the very top (as would be requred to get the reset vector from ROM).

[SiriusHardware]

I would be interested to know how the mask programming can make the ROM appear anywhere in the memory map.

I may have phrased that badly -

It is explained in the video I linked to in #77. The 6530 effectively has an onboard, customisable address decoder so that you don't need to provide an offboard address decoder for it. The customisation which determines where it lives in the overall memory map takes place at the mask programming stage.