Commodore 8050 dual disk drive

[SiriusHardware]

Another thing Colin could try is to read the ROMS 'as' Motorola MCM68766 rather than MCM68764 as has already been tried. These devices have the same capacity and pinout and are often both mentioned in the same sentence as suitable substitutes for 'Legacy' 24-pin 8K ROMs, in fact having just quickly looked at the datasheets for both I'm still not sure what the difference between them is.

As mentioned in another EPROM related thread recently, it is a quirk of most device programmers that their ZIF sockets typically make contact only with the narrow edges of the pins of any chips dropped into them, so it may be worth stroking the points of a pair of fine tipped tweezers down the outside edges of each IC pin in order to make sure those surfaces are clean and conductive.

Colin did say that he had the ROMs fitted in DIP sockets which were then dropped into the ZIF socket, so you would expect that to bypass any potential 'edge contact' problem with the DIP sockets most likely making contact with the IC pins on their wide, flat faces.

[ScottishColin]

Evening.

The ROMs will not be read eother as a Motorola 68766 or a 68764 with my Stag.

I've bought one of the Tynemouth boards referred to in post 15 in case the RRIOT chip is indeed the source of the problem.

Couple of questions.

1) Is it worth piggybacking some 2114s in case they're the problem? Is piggy-backing actually successful?

2) I can see the adapters that will allow me to use a 2764 but I'd like to try to read the original ROM first - are there any adapters that will allow me to do that?

Colin.

[ScottishColin]

Alternatively - is there anyone out there who can read these two ROMs and is willing to check them for me via the magic of the postal system?

Colin.

[SiriusHardware]

I can try to read them because I don't think my old programmer cares in the least about whether an device connected or 'identifies' correctly, but did you consider at least trying to do it using your Arduino? At least that way you don't have to risk them in the post.

I know it's a faff getting all of the wires connected up and keeping them connected, but the square ended Dupont type jumpers are a lot better / more stable than the rubbery round ended 'Arduino' type jumper leads.

I now have a version of the Arduino reader sketch which has been improved (that is to say, it was me who 'improved' it, so read that any way you like) as it can now generate human readable output with addresses, data, ASCII and overall device checksum as before, or if you alter one line in the code it will instead generate Intel Hex which can be cut and pasted from the Arduino serial monitor into Notepad or any other plain text editor and saved from there as a file which can be loaded by most EPROM programmers.

Piggybacking - I'm not a fan, as it will only work in certain circumstances. You are so adept now at removing devices that I don't think it is really an issue for you to remove a device properly and substitute it properly.

[ScottishColin]

OK - go on then.

Do you have the list of which pins to connect to which for a 2364?

Colin.

[SiriusHardware]

The sketch, as I recall, states in the comments which Arduino Mega pins have to be connected to which Ax and Dx pins on the device, and assumes that the EN or G pin will be tied to GND. You will also need to wire Arduino +5V to ROM Vcc and Arduino GND to ROM Vss of course.

The pinout of the ROM is on the left hand side of the attachment in #10. You will notice its address pins only go up to A12, just leave the Arduino pins which are meant to be connected to higher address pins on larger devices unconnected.

Wire it up and try using the reader sketch you already have, if it seems to read sensibly I'll post the 'improved' version which expects the Arduino to ROM wiring to be exactly the same as in the original version.

There is a line in the sketch which tells it how many bytes to read from the device, it looks like this: Change the value to 8192 as below.

for (addr = 0; addr < 8192; addr += 16) //65536 32768 choose regarding your EPROM

[ScottishColin]

OK - I have it compiled and running with the change in post 26 to only read 8K.

I had to wrestke with the cut and paste code from here a bit as the Arduino didn't recognise the characters used for quotation marks but we're ok now.

https://victorengineeringreloaded.wo...re-extraction/

It runs but because it's over 8K I need it dumped to a file - does your sketch do that?

Colin.

[arjoll]

Originally Posted by ortek_service

Although I presume 100TPI was used on systems other than Commodore, for several drive manufacturers to make these

Sord used them for their "mk III" disk systems, most notably (in NZ) with the M23 mk III, which included an FD20 enclosure with 2x Teac SSQD 100tpi drives, 320k per disk. I have a couple of M23 mk III systems here, and a couple of extra drives (look like they're out of an M243 or similar) that I picked up on Trademe from a recycling place. I spent some time during our 2020 lockdown trying to make them with an HxC2001 floppy emulator (after having great success with an M68 mk41 which used DSHD 5.25" floppies based on an IBM 8" format) but there's something non-standard about the interface, and I haven't had a chance to get back to it.

I also have an 8050 that came with an 8032, the latter is dead and another item in my "to do" pile.

Edit: some info about the M23 is from my website (which was never completed and long overdue for an update) here.

[ScottishColin]

That looks like a proper piece of kit.

Very nice.

Colin.

Originally Posted by arjoll

Sord used them for their "mk III" disk systems, most notably (in NZ) with the M23 mk III, which included an FD20 enclosure with 2x Teac SSQD 100tpi drives, 320k per disk. I have a couple of M23 mk III systems here, and a couple of extra drives (look like they're out of an M243 or similar) that I picked up on Trademe from a recycling place. I spent some time during our 2020 lockdown trying to make them with an HxC2001 floppy emulator (after having great success with an M68 mk41 which used DSHD 5.25" floppies based on an IBM 8" format) but there's something non-standard about the interface, and I haven't had a chance to get back to it.

I also have an 8050 that came with an 8032, the latter is dead and another item in my "to do" pile.

Edit: some info about the M23 is from my website (which was never completed and long overdue for an update) here.

[SiriusHardware]

I need it dumped to a file - does your sketch do that?

It dumps it to Intel Hex format which is still an ASCII format but you can cut it from the serial monitor screen, paste it into a plain text editor and save it and it is then an 'Intel Hex' format file which can be loaded by the editor software of most programmers, I'll try to post it here later tonight if possible - but I've just been annexed by SWMBO for a while, sorry.

The version you have there outputs a representation of the code as address, data, data as characters, all in human readable ASCII format which is why the resulting file is much bigger than the raw 8K binary of the original ROM content.

Does what you are getting out that way look in any way sensible? Post a screen shot of the first page of output from the version you are currently using.

[ScottishColin]

It starts with a lot of zeros, but there's text in there - I attach a screenprint.

For some reason, I can't cut and paste the whole serial monitor output, only that which is on the screen at the same time as I cut and paste so it's going to be easier if it outputs to a file.

Question: does the CE pin (pin 20) need to be connnected to the Arduino?

Colin.

Originally Posted by SiriusHardware

It dumps it to Intel Hex format which is still an ASCII format but you can cut it from the serial monitor screen, paste it into a plain text editor and save it and it is then an 'Intel Hex' format file which can be loaded by the editor software of most programmers, I'll try to post it here later tonight if possible - but I've just been annexed by SWMBO for a while, sorry.

The version you have there outputs a representation of the code as address, data, data as characters, all in human readable ASCII format which is why the resulting file is much bigger than the raw 8K binary of the original ROM content.

Does what you are getting out that way look in any way sensible? Post a screen shot of the first page of output from the version you are currently using.

[ScottishColin]

I'll check the wiring one more time and also try the other ROM tomorrow and report back.

Colin.

[ortek_service]

Originally Posted by ScottishColin

Evening.

The ROMs will not be read eother as a Motorola 68766 or a 68764 with my Stag.
>>
>>

2) I can see the adapters that will allow me to use a 2764 but I'd like to try to read the original ROM first - are there any adapters that will allow me to do that?

Colin.

Did you try seeing if your programmer supports the (TMS)2564, I'd previously suggested in an earlier post? - Copied below (where I'd also given some info about wiring it as a 2764 (which all programmers should support).

If your programmer does support the (TMS)2564, then these can still be bought at not too bad prices, and saves needing a slight pinout converter to use 2764's if you do need to replace either of the originals.

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

The TMS2564 is in a 28pin package, but has a second Vcc pin(24) for compatibility, with 2364's: https://www.jrok.com/datasheet/TMS2564.pdf
Where it seems you just bend the top 2 pins on each side, up and are OK to leave nCS1 and nCS2 n.c. (Presumably they have internal pull-downs?), as at: https://www.mutant-caterpillar.co.uk...oducts_id=5247

Otherwise, you could try making an adapter to a more-standard 2764, with some stacked IC sockets and the odd pin-swap as most are the usual JEDEC standard.
http://mhv.bplaced.net/cbmroms/2364.htm
https://forums.atariage.com/topic/30...rd-2764-eprom/

[ortek_service]

Originally Posted by ScottishColin

>>
Question: does the CE pin (pin 20) need to be connnected to the Arduino?

Colin.

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

[ortek_service]

Yes, I've not heard about the Sord M23 before (And not sure if there was one at the recent Japanese-systems weekend event at the CfCH museum in Cambridge in the UK over here) / not sure many made it to the UK.
- I only remember the Sord M5 (which I was tempted to buy back then, but have more-recently discovered it's major shortcomings with lack of memory and 3 different BASIC cartridges)

That Sord M23 disk drive data transfer rate of 250Kbits/sec is very-good (I think the BBC Computer was 2.5KBytes /sec) when you compare it with the Commodore 8050/8250 drive's specified transfer rate of only 400 Bytes / Sec (I thought it was much faster than the notoriously-flawed Serial-IEEE 1541 drive for the VIC-20/PET, but have read that is also 400Bytes/sec (max) / 300Bytes/sec (sustained).
And only a C64 + an LS-120 drive interface and LS-120 disc gets near:
http://singularcrew.hu/idedos/perf.php

Originally Posted by ScottishColin

That looks like a proper piece of kit.

Very nice.

Colin.

[ortek_service]

Originally Posted by SiriusHardware

Thanks for that info, Tony - with the 2364s fitted the 'error flash' system seems to be working after a fashion, which makes it seem unlikely that the ROMs are so faulty as to be unreadable.
>>

Well it's possible for UH1 2364 to still be faulty, if UL1 2364 is actually $E000 - $FFFF (as Tony later confirmed) - So would normally be the one that would be accessed first by a Power-On-Reset.
This top-of-memory ROM will have to jump to the other $C000 - $DFFF ROM at some point, but I'd expect the diagnostics to run before this, for it to checksum itself and the other one.

Although if a flashing LED sequence that indicates failure of either of these hasn't been seen, then most-likely OK (Unless something else is failing before the checksum test for these is reached in the code)

Originally Posted by ortek_service

>>

It would seem that Commodore 'DOS' is held in these two 2364 ROM's, as the Service Manual states (But seem to have an extra F on end-addresses!)
UH1: $C000 - $DFFFF?
UL1: $E000 - $EFFFF? (Not sure if this is EFFF (So 2KB), or FFFF (So 4KB)?

>>
>>

[SiriusHardware]

Question: does the CE pin (pin 20) need to be connnected to the Arduino?

It needs to be connected to 0V because the reader project does not provide a drive signal for that pin.

I've only just been allowed off the lead so I'm going to have to go straight to bed and I won't be able to look at what you got so far or post that improved reader until sometime tomorrow evening, apologies.

To select all of the output in the serial monitor output buffer have you tried CTRL-A?

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

Note that on the circuit diagram, signals for the 'interface' processor are prefixed by 'I', ones for the 'controller' processor by 'F' (formatter?) The data bus is common to everything, UA6c means that Iphi0 and Fphi0 are inverses of each other so the processors each get the data bus on alternate halves of the clock cycle.

[SiriusHardware]

it appears the CS pins on those ROMs are active _high_ which probably explains why your programmer can't read them.

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]

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.