Commodore 8050 dual disk drive

[SiriusHardware]

Colin, you can also try reading the ROMs in your STAG again as 68764 or 68766, but this time with the CE pin (20) isolated and connected to pin 24 via a resistor. Rather than bend the pin out sideways, you might prefer to put the ROM in a 24-pin socket with the pin 20 contact removed, and drop that into the programmer.

[ortek_service]

Originally Posted by SiriusHardware

If those ROMs do have active-high chip selects then I am afraid we will be robbed of the possibility of using 68764 / 68766 as neat drop in replacements, so let's hope the ROMs are OK after all.

Yes, the same for (TMS)2564's (and also 2764's, with some pin-swaps), that I'd also been suggesting to try to see if programmer could read (or even write, as they can still be bought fairly-cheaply, if required).

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

Originally Posted by ortek_service

Alternatively, you could try to see if your programmer supports the (TMS)2564, which is also designed to be compatible with 2364 ROM's (that are unusual, in being 8KB in a 24pin package) - 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

You could of course always still use all these EPROM's, with the addition of an inverter (May get away with just using a transistor and some resistors, although could always use a single logic-gate SMD Inverter IC on a mall breakout board).

[ortek_service]

Originally Posted by TonyDuell

Looking at the circuit in the service manual, it appears the CS pins on those ROMs are actve _high_ which probably explains why your programmer can't read them.

The ROMs are enabled by the AND gates in UR1. IA15 has to be high, Iphi2 has to be high as well, IA13 selects between the 2 ROMs. IA14 is ignored. so the ROMs appear twice in the interface processor memory map, filling the top 32K. The outputs of UR1 on pins 6 and 11 then go high to select a ROM.

>>

Thanks for confirming this - I hadn't had chance to work through the logic, and Commodore hadn't been very helpful in providing any circuit descriptions etc. in the manual.
But I had also wondered if thee could have been active-high, being as they didn't have the usual 'over-score' bar on the names:

Originally Posted by ortek_service

CS1(Pin20) on these 2364's will most-likely need to be connected to something, rather than leaving it floating as could get some rather random data outputs if device is not held in enabled state.

It shouldn't really matter if it is tied to directly to ground / supply, or whether the Arduino controls it(Just need an extra Output on the Arduino to control it), as it will be the only device being used with the Arduino so nothing to conflict with.

I would assume that CS1(Pin20) is Active-Low, so needs to be grounded to read it. But the Commodore schematics omit the negation over-score bar on this pin on the 2364 symbols and so it's possible it is active-high and needs pulling to +5V
(Mask ROM's often had options to have the chip enables active-low or active-high, to suit the circuitry they were going in. But active-high does make them incompatible with most EPROM's, so means extra circuitry on adaptor boards).

[SiriusHardware]

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

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.

[ScottishColin]

More data available I believe now with the suggestion below - here's the top of the listing attached.

There seems to be a known issue regarding cut and paste of the Serial Monitor in Arduino and the suggestion is to use something like Putty (which I do have installed for other reasons) to capture the full output. I'll try that later.

Colin.

Originally Posted by SiriusHardware

In that case, Colin, try tying the CE pin to +5V with a resistor (1K, 4K7 or whatever) and try again. I had forgotten that those '23' series ROMs had 'programmable' CS pins (programmable in the sense that their 'polarity' can be defined during the mask programming process).

[SiriusHardware]

There seems to be a known issue regarding cut and paste of the Serial Monitor in Arduino

That's quite odd, as that is exactly how I 'converted' the 64K worth of output from Station X's unreadable 27C512 EPROM to an Intel Hex file. I wonder if it depends on the Arduino IDE version? I am very rarely running the latest version.

Anyway, since tying the CE pin high on the Arduino reader has provided proof of concept, now try the same thing on your STAG - read as a 68764 / 68766 but with the CE pin of the ROM isolated and tied via a resistor to +5V.

If that works, you won't need to worry about any cut and paste issues you may be having with the Arduino IDE.

[ScottishColin]

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

Colin.

Originally Posted by SiriusHardware

That's quite odd, as that is exactly how I 'converted' the 64K worth of output from Station X's unreadable 27C512 EPROM to an Intel Hex file. I wonder if it depends on the Arduino IDE version? I am very rarely running the latest version.

Anyway, since tying the CE pin high on the Arduino reader has provided proof of concept, now try the same thing on your STAG - read as a 68764 / 68766 but with the CE pin of the ROM isolated and tied via a resistor to +5V.

If that works, you won't need to worry about any cut and paste issues you may be having with the Arduino IDE.

[SiriusHardware]

OK, was worth a try with the STAG. My 'Dumb' programmer probably would have allowed them to be read by that process, but luckily the Arduino method seems to be working.

I find that area full of AA a bit concerning, if there were any areas filled with large patches of the same value I would expect that they would probably contain 'FF', so -

Find the equivalent file on zimmers and load it into your STAG programmer's editor and look at just the first 16 values in that version and in the code you read out using the Arduino. Are they the same, or different.

Same for the other ROM, compare the first line of values read out from the ROM by the Arduino with the first line of values in the actual file from zimmers.

I'll dig out the 'advanced' Arduino reader code and post it later.

[ScottishColin]

Here's both UL1 and UJ1 for reference.

I have also replaced their sockets and the RRIOT white socket to no avail.

Colin.

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

[ScottishColin]

Well they match (I loaded the .bin files into HxD and those caharacters at the end show up as A), but the wrong way round - either my ROMs are mislabelled or the web site has them mis-named.

Colin.

[SiriusHardware]

Good job finding the files although I am a little bit disappointed at zimmers for not having them there.

Here (I hope) is the slightly more advanced version of the reader sketch you are currently using. The connections between the Arduino Mega and the ROM are exactly the same for this version. I acknowledge Oddbloke (details in the .ino file) as the original author, plus additions by OlivierM, their version was the starting point for this version. .ino is not an allowed file type for the forum so I have wrapped it up in a .zip, attached.

I have left the serial speed at the original 9600 which is also the default speed of the serial monitor, but you can change the value in the serial.Begin statement to a much higher baud rate and change the baud rate setting in the serial monitor to the same rate if you want it to go a bit faster. I've also set the 'bytes to read' value to 8192, for 8K.

The logic state of the Arduino 'A0' input sets the operating mode of the reader.

If input A0 is left open / unconnected the reader outputs the contents of the ROM as human-readable 16-column ASCII Hex with an address column at the left hand side. At the right hand side, the values are shown as the equivalent ASCII characters if they are printable characters, otherwise they are represented by a '.' instead. As the hex values are read out from the ROM they are added together to produce a 16-bit (4 digit) hex checksum which is displayed at the end of the readout. This can be useful if you know what the ROM's checksum should be when it is healthy.

If input A0 is connected (with a male-male jumper) to GND the reader outputs the contents of the ROM as Intel Hex which you can cut and paste into a plain text editor (like Notepad in Windows) and then save it as romfile.hex or whatever. It must be a 'simple' text editor, not a word processor which may add invisible formatting characters and other information to the file.

When you go to load the code into your programmer's editor it may automatically recognise the file as an Intel Hex file or it may query the file type and you will have to tell it that it is an Intel File. There is a small chance that your programmer's editor may not actually load Intel Hex files, in which case the file will need to be converted to say raw binary (.bin) format. We will deal with that if we have to.

[SiriusHardware]

Re: The swapover, I suppose there is an outside chance that some previous fixer has had them out at some point in the past and mixed them up. Try looking for some high-def images of that control PCB online and see if you can see which way around they should be fitted.

My feeling is that if they were the wrong way around it would probably work a lot less than it does now but it is worth ruling out.

[SiriusHardware]

This page from the manual Tony linked to early on appears to show which numbered ROMs should fit in which sockets.

[ScottishColin]

Mine are in the righht sockets then.

Colin.

Originally Posted by SiriusHardware

This page from the manual Tony linked to early on appears to show which numbered ROMs should fit in which sockets.

[ScottishColin]

Arduino 2.1.1 here - it won't comiple:

"Compilation error: redefinition of 'const int kPin_A0'"

Colin.

Originally Posted by SiriusHardware

Good job finding the files although I am a little bit disappointed at zimmers for not having them there.

Here (I hope) is the slightly more advanced version of the reader sketch you are currently using. The connections between the Arduino Mega and the ROM are exactly the same for this version. I acknowledge Oddbloke (details in the .ino file) as the original author, plus additions by OlivierM, their version was the starting point for this version. .ino is not an allowed file type for the forum so I have wrapped it up in a .zip, attached.

I have left the serial speed at the original 9600 which is also the default speed of the serial monitor, but you can change the value in the serial.Begin statement to a much higher baud rate and change the baud rate setting in the serial monitor to the same rate if you want it to go a bit faster. I've also set the 'bytes to read' value to 8192, for 8K.

The logic state of the Arduino 'A0' input sets the operating mode of the reader.

If input A0 is left open / unconnected the reader outputs the contents of the ROM as human-readable 16-column ASCII Hex with an address column at the left hand side. At the right hand side, the values are shown as the equivalent ASCII characters if they are printable characters, otherwise they are represented by a '.' instead. As the hex values are read out from the ROM they are added together to produce a 16-bit (4 digit) hex checksum which is displayed at the end of the readout. This can be useful if you know what the ROM's checksum should be when it is healthy.

If input A0 is connected (with a male-male jumper) to GND the reader outputs the contents of the ROM as Intel Hex which you can cut and paste into a plain text editor (like Notepad in Windows) and then save it as romfile.hex or whatever. It must be a 'simple' text editor, not a word processor which may add invisible formatting characters and other information to the file.

When you go to load the code into your programmer's editor it may automatically recognise the file as an Intel Hex file or it may query the file type and you will have to tell it that it is an Intel File. There is a small chance that your programmer's editor may not actually load Intel Hex files, in which case the file will need to be converted to say raw binary (.bin) format. We will deal with that if we have to.

[SiriusHardware]

Amazing. I compiled that very .ino seconds before I made it into a .zip file. I'll have a quick look.

[ScottishColin]

See post 51 - I'm comfortable that they match the downloaded .bin files if I use HxD to load them.

Colin.

[SiriusHardware]

They match byte for byte, exactly the same all the way through? All 8192 bytes in each ROM? Remember it was a three-flash warning (Faulty ROM) which set us off down this road.

[ScottishColin]

I need to do this manually as the output from Putty is in a different format to the .bin file.

Colin.

Originally Posted by SiriusHardware

They match byte for byte, exactly the same all the way through? All 8192 bytes in each ROM? Remember it was a three-flash warning (Faulty ROM) which set us off down this road.