Sunday 9 June 2024

MOS 6550 RAM Chips - An interesting (if flawed) idea

This is the MOS MPS 6550, a 1K x 4 static RAM chip.

It seems like a normal static RAM chip as you would expect in the late 1970s.

However, as you can see it is different to other chips.

Don't worry, I am not going to do the "I know my place" class / status joke again.

Comparing it to a 2114 and a 6116, you can see it is not the normal 300mil narrow DIP package, or the standard 600mil DIP package. It is 22 pin 400mil spacing. I don't think I have seen another 22pin chip, or one with 400mil spacing (other than a Sony CCD chip).

The other way it is unusual is that it has 4 chip select lines. CS1 and CS2 have to be high, and /CS3 and /CS4 have to be low to enable the chip. What is the point of that you might ask? well, it can simplify address decoding.

The actual selection is triggered by the PHI2 clock input, with nothing happening until the clock is high.

Take for example the Commodore PET 2001. This had 18 of them. 16 to give 8K x 8main RAM, and another two as 1K x 8 video RAM (giving 1024 characters, 25 rows of 40 characters with a few to spare). Someone has clearly had fun marking the failed ones on this board.

I think this was the first and last use of the 6550 chip, and indeed by the end of the life of the PET 2001, even that had switched to more normal 2114 RAM chips.

For simplicity, I have only shown the 4K version, and have bussed most of the signals which are wired in parallel. These are 4 bit chips (like the 2114), so a pair of chips is required for 1K, with D0-D3 wired to one chip, and D4-D7 to the other.

The PET has its memory split into sixteen 4K blocks, and a 74154 4 to 16 line decoder is used to decode A12-A15 to generate sixteen block select lines. Here /SEL0 is used, which is low when addresses in the range 0000-0FFF are accessed. (/SEL1 is 1000-1FFF, /SEL2 is 2000-2FFF and so on up to /SELF as F000-FFFF)

Starting on the left with J4, this needs to be placed in RAM at 0C00-0FFF. The top byte of the address is 0000 11xx. A15 to A12 are handled by the /SEL0 line and A0 to A9 are handled by the 6550 RAM chip, so it is only A10 and A11 which need to be decoded. In this case, both are high.

You're got four enable lines, so BA10 and BA11 need to be high, and /SEL0 needs to be low. The spare one is just connected to 0V. OK, that works.

J3 is 0800-0BFF, the top bits are 0000 10xx, so BA11 is high, and BA10 is low. /SEL0 again is low, and the spare CS1 is tied to 5V.

No problem, the 6550 has got that covered.

J2 is 0400-07FF, 0000 01xx, so BA11 is low, and BA10 is high. /SEL0 again is low, and the spare CS1 is tied to 5V.

Hey this is easy.

Finally J1 covers 0000-03FF, 0000 00xx. So BA10 and BA11 and /SEL0 are low. Ah, oh dear. We don't have enough inputs. We need three active low inputs and we have only two.

To get around that, they created a /BA11, an inverted version of BA11, so all is good, but is that cheating? 

That was J1-4, which are wired to D4-D7. The other 4 bits were provided by I1-4.

All of the decoding here is identical, and all the other lines are wired in parallel apart from the four data pins, which are connected instead to D0-3.

There was a planned base model PET 2001-4, with only 4K, but I don't think that was ever released.

I think they were all sold as PET 2001-8 with 8K.

Another 8 chips wired identically, other than all the /SEL0 lines were instead connected to /SEL1 and covered the address range 1000-1FFF.

So is this a good idea? I guess it saved some external decoding logic. Maybe.

The great thing about 6550 RAM is they had multiple chip select lines so they could effectively be wired in parallel without additional decoding logic.

The awful thing about 6550 RAM is they had multiple chip select lines so they could effectively be wired in parallel without additional decoding logic.

This decoding turned out to be an Achilles heel, and seemed to fail in a way that left the RAM enabled when it shouldn't have been.

The result is multiple chips being enabled at the same time, all trying to write to the bus at the same time.

Bus conflict.

Heat.

A war of attrition.

The chips with the beefiest transistors wins out in the end. If you have 6550 RAM chips (or indeed 6540 ROMs) that are getting very hot. They don't just need a heatsink, they needs to be removed, as they slowly destroy more and more of the working ones.

The main RAM can be replaced with a PET ROM/RAM and the video RAM with a 6550 Video RAM replacement board (see end of the post for links).

Towards the end of the production life of the PET 2001, they changed to using 2114 SRAM and standard mask ROMs, and I don't think the 6540s or 6550s were seen again anywhere else.

There is a schematic set for a PET 2001 with 2114 RAM and mask ROMs, but I have never actually seen one. Only the 6550/6540 and 2114/6540 versions.

As we saw earlier, the 2114 is a smaller chip, 18 pin and 300mil wide. It has only one /CS line, and no need for the clock signal.

It is interesting to look at the changes they made to the PET 2001 to use 2114 RAM chips instead of 6550s. 

How much extra decoding logic did they actually need?

With only one /CS line, they had to use some additional decoding to select the RAM chips.

This is the whole 8K RAM composed of 8 pairs of 2114 chips, and it is still pretty minimal.

All they added was a single 74LS139 dual 2 to 4 line decoder. And as they no longer needed the /BA11 signal, they would save a gate elsewhere, so not a major difference in the end.

I say 2114s, although one board I had in for repair had TMS4045 chips instead, but they are compatible.

I have seen others with actual 2114 chips, although this one was quite a pick and mix of makes and part numbers.

The RS and the Tesla (not that one) chips were presumably later repairs, with the soldered ones being factory fit and still a mix of types.

One of the factory fitted ones shows they even got MOS to make 2114 chips, so they still kept the in-house savings.

I think they had some good ideas with the decoding, but maybe would have been better to have maybe gone for a 28 pin package and added the other 4 data lines, making it a byte wide. They would still have 2 extra pins, maybe extra /CS lines to avoid needed /BA11 or extra address lines to make a 2K or 4K chip.

Or go for a more standard 24 pin and lose chip select lines and still be able to go byte wide and 2K.

Oh wait, that's a 6116.

Why didn't they make a 6116 then you would only need 4 of them for an 8K PET and could have left space for 16K or even 32K.

(they were around a few years later for the VIC20 CR and the ZX81 / TS1000, maybe earlier, but maybe they didn't have the silicon wafer size to do it? or yield problems?)

And a 62256, 32K on a single 28 pin chip would have been even better, but they were several years away from those. This is the RAM arrangement on the Mini PET.

One chip, decoded on A15 being low (0000-7FFF) for the maximum 32K RAM.

It is interesting to note that they did not move to larger static RAMs on later boards. They went to dynamic RAM, 8 or 16 4116 chips, giving 16K or 32K. They must have been significantly cheaper as their use required a change to the transformer to add an extra winding, and the appropriate components to make the additional +12V and -5V supplies required by these chips. Plus a page of schematics worth of extra parts to handle DRAM refresh.



Advertisements

I have an assortment of PET repair parts available from my SellMyRetro store, many of which are shown here.

These are the links for US and UK customers (I can ship worldwide, contact me if elsewhere)

Or if you would rather a whole PET made from modern parts, the full range of Minstrel and Mini PET kits and accessories are available form my SellMyRetro store.

All the links can be found here:

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts (they also got an extra post covering the history of my 6550 video RAM board). This also includes access to my Patreon only Discord server for even more regular updates.

Sunday 2 June 2024

Building a divIDE Spectrum IDE interface

As part of something I was working on, I was looking into the ZX Spectrum divIDE, quite an old project, but a way of getting a disk interface for the Spectrum before the days of the divMMC.

The project this was for will probably not happen now (#Z80RIP) but I would still like to get this working.

I remembered seeing an all through hole version, and indeed I thought I had one at one point, but I couldn't find it. (Ed: I now remember it came in with a ZX Spectrum repair a long time ago and went back to the owner with the repaired Spectrum)

So, I had a look around for built units or kits, but all I found was someone selling bare PCBs on ebay. The divIDE 5.7C seemed to be the version everyone was using, so I ordered one of those.

I wasn't too impressed with the PCB. Just personal preference, but I don't like the way the PCB was marked out, quite difficult to follow. It may be ebay seller was just using a random set of gerber files they found online?

How on earth are you meant to work out what goes where?

Luckily, there is a schematic........

Oh dear, that's even worse.

All of the versions online seem to be variations of that. Some in colour, some not.

I finally found a better one thanks to Nightfall Crew.

Comparing that to what I could read from the PCB and the schematic it seemed right, and various photos online show built units with two missing parts (C8 and RN1) not fitted.

The only issue I had with parts was the BF199 transistor. I didn't have one of those and couldn't see any in stock at my usual suppliers. I instead used a BC548 which had similar (but slightly better) specs, but unfortunately a different pinout.

Fingers (and legs) crossed this minor bodge will work.

Looks fine, you would likely not spot it if you were not looking for it.

All populated and ready to go.

There is a 28C64B EEPROM on the board which needs to be programmed with the appropriate firmware using a program on the Spectrum.

You load up the program, then remove jumper JP2 (which is marked behind the jumper where you can't see it)

Lots of flashing bright colours as usual, seems to be going well.

And there it is flashed.

So I switch off, refit JP2 and turn the power back on but I don't get a boot screen, all I get is a copyright Sinclair screen?

OK, let's try that again.

No, same.

Hmm, there should have been a boot screen just like the divMMC.

Speaking of which, just to check, I tried going through the same process with a divMMC future, and that worked correctly.

I also tried FATware, an older firmware which should support the same hardware, that appeared to program correctly, but again did not work. I later retried it and at least got an error this time. Not sure what it means though.

I grabbed another Spectrum from the pile, in case the problem was with the two Spectrums I had been testing with. I was pretty sure it wasn't, since the divMMC worked, so I don't think it was a bad M1 line for example.

Trust me to pick one I hadn't updated.

Just needed a quick composite mod and a switching regulator replacement.

Lets retest with that.

Did it make a difference? No.

OK, lets' reprogram the GALs, and lets's also try a set of Atmel ATF22V10C as well as the Lattice 22V10B.

No, that hasn't helped.

OK, maybe my substitute transistor is not suitable?

I had to turn to ebay again I am afraid, but I got a pack of BF199s.

Being the correct part, that could be installed without the need for the twisted legs this time.

Did that fix it? No.

I have revisited this a few more times, trying different EEPROM and GAL chips and trying to program the EEPROM directly, but not getting anywhere.

I don't know what is going on there. It is possibly my build is bad, but I have checked over all the solder joints etc. and I can't see anything.

It is possible the PCB is bad, given the silkscreen mess, it is possible there are also errors with the traces.

It is possible I have the wrong GAL files, or my GALs are all bad, or my programmer is somehow not programming them correctly. (although I use the same chips and the same programmer for other things.)

Anyone got any ideas?

Anyone had any success building this version of the PCB recently?

Anyone got a working version of this I could borrow and compare?


Advertisements

The full range of Minstrel and Mini PET kits and accessories are available form my SellMyRetro store.

All the links can be found here:

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.