Designing and building the KCC plus, a new, enhanced CPC6128 compatible computer

[Benedikt]

The goal is a publicly available, free design that anyone who can hold a soldering iron can build.

That sounds like a really cool DIY project for me and Junior

Unless I have to resort to using SMD logic chips. Well, junior might have better eyes and smaller fingers, actually.

Meanwhile, I have taken a closer look at @abalore's Plus2CPC design for the cartridge port.
As far as I can tell, the attached reconstructed schematic is complete. It also contains an additional connector, namely for a flash ROM socket.
I figured that a ZIF socket for flash ROM chips makes more sense for firmware prototyping than an actual cartridge.

One potential problem that I noticed with the overall cartridge approach is that a KCc-based system design obviously has to initialize the CIO and palette RAM somehow.
If the cartridge replaces all internal ROMs, keeping things compatible might require some trickery on power-up and reset.
The cartridge port would have to be initially disabled, so that the internal firmware ROM can initialize the CIO and palette RAM and then enable the cartridge port and trigger a warm reset that must not loop even if there is no cartridge.

[abalore]

The goal is a publicly available, free design that anyone who can hold a soldering iron can build.

That sounds like a really cool DIY project for me and Junior

Unless I have to resort to using SMD logic chips. Well, junior might have better eyes and smaller fingers, actually.

Meanwhile, I have taken a closer look at @abalore's Plus2CPC design for the cartridge port.
As far as I can tell, the attached reconstructed schematic is complete. It also contains an additional connector, namely for a flash ROM socket.
I figured that a ZIF socket for flash ROM chips makes more sense for firmware prototyping than an actual cartridge.

One potential problem that I noticed with the overall cartridge approach is that a KCc-based system design obviously has to initialize the CIO and palette RAM somehow.
If the cartridge replaces all internal ROMs, keeping things compatible might require some trickery on power-up and reset.
The cartridge port would have to be initially disabled, so that the internal firmware ROM can initialize the CIO and palette RAM and then enable the cartridge port and trigger a warm reset that must not loop even if there is no cartridge.

Hello, that reverse engineering looks very accurate, but it's not the last version and it's missing some stuff to make the C4CPC fully compatible. The flash socket addition looks good, better in a ZIF socket.

[Benedikt]

The only oddity I noticed about the design (Plus2CPC v. 4.1, IIRC) was that the ACID clock is not connected to anything.
Is it that or does the C4CPC need other modifications?

To be honest, C4CPC support is not the biggest priority for me, because I ultimately want to build a machine with an IDE interface and a megabyte of RAM, but better compatibility is always "nice to have".
For my purposes, i.e. firmware prototyping and software development, I will probably split the cartridge interface into two pieces: A cartridge ROM interface with ZIF socket for the CPC and a matching cartridge-to-DIP adapter.
The rationale for splitting the design is that (A) no cartridges are needed, and (B) appropriately designed cartridges (that e.g. replace one of the two VCC connections with /WR) can then be reprogrammed with an ordinary programming device.
Besides that, it also avoids creating direct competition for your cartridge interfaces. The ultimate goal is still to put everything on a system board, but initial modular prototyping will be necessary.

[abalore]

The only oddity I noticed about the design (Plus2CPC v. 4.1, IIRC) was that the ACID clock is not connected to anything.
Is it that or does the C4CPC need other modifications?

To be honest, C4CPC support is not the biggest priority for me, because I ultimately want to build a machine with an IDE interface and a megabyte of RAM, but better compatibility is always "nice to have".
For my purposes, i.e. firmware prototyping and software development, I will probably split the cartridge interface into two pieces: A cartridge ROM interface with ZIF socket for the CPC and a matching cartridge-to-DIP adapter.
The rationale for splitting the design is that (A) no cartridges are needed, and (B) appropriately designed cartridges (that e.g. replace one of the two VCC connections with /WR) can then be reprogrammed with an ordinary programming device.
Besides that, it also avoids creating direct competition for your cartridge interfaces. The ultimate goal is still to put everything on a system board, but initial modular prototyping will be necessary.

The C4CPC needs both the CLK and the RESET signals (RESET to CCLR), not mandatory but a quality of life addition to not have to turn off/on the power to change the game. The rest of ACID stuff is not needed.

Just adding a cartridte-to-DIP adapter only does the trick if the base ROM decoding follows the RMR / RMR2 decoding according to the Arnold V specifications, not if the ZIF slot is treated as a normal ROM expansion. I guess you take that into account already.

Yes, replacing a VCC pin with WR is a feature in the Play2CPC that allows writing the cartridge (or flash IC) directly from the CPC. Depending on the flash IC used (A29040, 28SF040, 39SF040) you need different wirings for OE and CE, but there is an universal wiring that works for all, the only difference is the size of the page you can erase in a single operation (256 bytes, 16K or 4K respectively). If you want to use a external programming device, you still can do it, but being able to write cartridges from the CPC is an interesting feature, for instance to create 512K flash disc drives in cartridges (I already do it but not published)

I find very interesting to have cartridge support directly in the motherboard, not needing my expansions.

[GUNHED]

Actually, 4 MB of RAM would be really nice. 

[zhulien]

Benedicts approach is to use "old" 80s technology

That eliminates sdcards, m4, goteks etc... gonna get 3" drives from doner CPCs?

[Benedikt]

The C4CPC needs both the CLK and the RESET signals (RESET to CCLR), not mandatory but a quality of life addition to not have to turn off/on the power to change the game. The rest of ACID stuff is not needed.

Alright. I will add the additional trace, then. Additional logic would have been a different story.

Yes, replacing a VCC pin with WR is a feature in the Play2CPC that allows writing the cartridge (or flash IC) directly from the CPC

Which VCC did you pick? It would be kind of awkward if I got that backwards and made it incompatible.

Actually, 4 MB of RAM would be really nice. 

Err... probably not on the very, very crowded system board.

Benedi[k]ts approach is to use "old" 80s technology

That eliminates sdcards, m4, goteks etc... gonna get 3" drives from doner CPCs?

Not really. I will try to do without "spooky alien technology from the future" on the system board itself, because adding e.g. a microcontroller that could single-handedly emulate the entire system would make the whole endeavor utterly pointless.
It was and is however perfectly normal to connect a newer FDD, HDD or whatever else to an older system.
An IDE interface (80s enough) on the system board gives people plenty of options, i.e. HDDs, DOMs, CF card adapters, SD card adapters, CF card adapters with CF-to-SD card adapters etc.

[abalore]

Which VCC did you pick? It would be kind of awkward if I got that backwards and made it incompatible.

Pin 2

[abalore]

Here is the Plus2CPC schematic

But nowadays I would use a single CPLD for all decoding (and pull-downs) and also do full RMR2 decoding.

The pull-down function is a bit hard to understand, it's used to activate LOWER ROM (slot 0) when latch output is disabled, by setting the CA address to all zeroes.

[Benedikt]

Which VCC did you pick? It would be kind of awkward if I got that backwards and made it incompatible.

Pin 2

That is indeed the pin I would have picked, but you never know. The odds are 50:50, after all.

Here is the Plus2CPC schematic

But nowadays I would use a single CPLD for all decoding (and pull-downs) and also do full RMR2 decoding.

The pull-down function is a bit hard to understand, it's used to activate LOWER ROM (slot 0) when latch output is disabled, by setting the CA address to all zeroes.

Thank you very much!
I actually found the purpose of the pull-down resistors quite intuitive to understand, but that might have been thanks to the individual logic gates in my version of the schematic.

[overange]

Which VCC did you pick? It would be kind of awkward if I got that backwards and made it incompatible.

Pin 2

Pin 2 is the pin that I use the allow the CPC flash cartridge to be written to.

https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-gx4000-cpc-464-6128-plus-reflashable-flash-cartridge/msg236052/#msg236052

[Benedikt]

Pin 2 is the pin that I use the allow the CPC flash cartridge to be written to.

https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-gx4000-cpc-464-6128-plus-reflashable-flash-cartridge/msg236052/#msg236052

That is also how I would have built a flash cartridge, but I would have omitted the ACID footprint altogether and would have used a 74AHCT74 for the NOACID version.
The 74AHCT74 is very fast and reasonably cheap and I believe that one of the two flip-flops can simply be wired up as an inverter for the other flip-flop's clock line.

[GUNHED]

Well, if the KCc-new will ever see the light of day, then please put me on the order list. I would love to have one to port my OS and software to it. 

[Benedikt]

Well, if the KCc-new will ever see the light of day, then please put me on the order list. I would love to have one to port my OS and software to it. 

I am reasonably confident that it will. However, as mentioned earlier, I am not going to turn this into a commercially available product.
I can reserve a set of spare prototype PCBs for you, though.

If we shift our focus back to the system board and its core functionality, there is still the problem that the video logic is getting way too big.
Some of the initial design decisions therefore have to be adjusted a bit.

Firstly, I will have to scrap the attribute mode, because it adds too much hardware complexity for too little gain.
As a substitute, the video mode can be made configurable for both bit planes separately, which is much cheaper.
The resulting combined video modes are not quite as good for pseudo text modes, but even more versatile for game graphics.
You would e.g. get a 320x200 pixel mode with 64 colors, where two bits can be set per pixel and another four bits can be set per pixel pair.
The matching high-res mode with color clashing per pixel pair would have 640x200 pixels and eight colors.
A high-res 32-color mode would also be possible, namely by combining mode 2 and mode 0.

Secondly, I noticed that a single ATF22V10 GAL is then big enough for the entire palette index generation logic that sits between the shift registers and the palette RAM.
If we need GALs, anyway, we might as well use more than one, rather than limiting ourselves to a single GAL for memory mapping.
The goal to create a THT-based system board with the desired feature set is much more realistic with maybe half a dozen GALs.

[Benedikt]

Here is the Plus2CPC schematic

But nowadays I would use a single CPLD for all decoding (and pull-downs) and also do full RMR2 decoding.

The pull-down function is a bit hard to understand, it's used to activate LOWER ROM (slot 0) when latch output is disabled, by setting the CA address to all zeroes.

Wait a minute...

Why does your schematic connect CA14, the push-pull output of the fourth inverter, to the pull-down network?
And most importantly, why does the "pull-down" network pull to VCC if it is supposed to turn open circuits into zeroes?

[abalore]

Here is the Plus2CPC schematic

But nowadays I would use a single CPLD for all decoding (and pull-downs) and also do full RMR2 decoding.

The pull-down function is a bit hard to understand, it's used to activate LOWER ROM (slot 0) when latch output is disabled, by setting the CA address to all zeroes.

Wait a minute...

Why does your schematic connect CA14, the push-pull output of the fourth inverter, to the pull-down network?
And most importantly, why does the "pull-down" network pull to VCC if it is supposed to turn open circuits into zeroes?

The pull-down network is connecting to GND, look twice!

Respect to CA14 in the array, you are right, it must be probably Q0 instead.

[Benedikt]

The pull-down network is connecting to GND, look twice!

Thank you for confirming that pull-down does indeed pull down. That is what I derived from both, your board layout and common sense.
And yes, looking at it downloading it again, the resistor network in your schematic is now indeed connected to GND rather than VCC, but still in a funny way.

Respect to CA14 in the array, you are right, it must be probably Q0 instead.

Yes, that makes a lot more sense.

[GUNHED]

btw: another KCc just sold in Ebay Germany for 850 Euros.

[eto]

btw: another KCc just sold in Ebay Germany for 850 Euros.

who would have thought in 1989 that the KCC will at some point be the most sought-after CPC...

[Benedikt]

btw: another KCc just sold in Ebay Germany for 850 Euros.

who would have thought in 1989 that the KCC will at some point be the most sought-after CPC...

Personally, I believe that not even the engineers who built that machine feel nostalgic about it.
The ridiculous price can therefore only be explained with that machine's rarity.

When it comes to building its successor, though, I am considering to start off with the following:

• Write a bitmap converter that demonstrates the overall look of the planned video modes
• Fork and extend the Arnold emulator to create a KCC+ emulator for evaluation purposes

With that approach we can see whether certain mechanisms have the desired effect and are worth implementing in hardware.

[GUNHED]

A faithful KCc emulator would be a real gem. There is none yet sadly.