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.

[Benedikt]

Not much has happened since June, but it has been brought to my attention that the Polish company MATT has apparently resumed production of its late-80s joysticks and joypads:
https://sklep.matt.com.pl/pl/c/Retrojoysticki/75/2
Something like this could be the perfect match for the spiritual successor of an eastern-bloc home computer.

Regarding the computer itself, there is also still the problem that CPC software often expects a proper READY signal from the floppy disk drive.
For the average PC floppy disk drive, we therefore need to get a READY signal, somehow.
However, as far as I know, the READY signal only indicates that two INDEX pulses have passed since MOTE (motor enable).
A single 7474 chip (LS or HCT), wired up as shown in the sketch below, should be sufficient to synthesize that. The diode and pull-up resistor are there to fake an open-collector signal.

[RockRiver]

It would be nice to ask Roland Perry and his team how they thought to improve CPC video and PCW compatibility in the ANT project.

I like the 320x200 16 colour path (similar than AtariST/SAMcoupe/Enterprise)

[Benedikt]

Another design decision, and maybe yet another one:

After much deliberation I have decided, that cartridge interface, IDE controller and serial port will go in a combined expansion unit rather than on the system board itself.
This is largely a logical consequence of the earlier design decision to make the system board's form factor CPC 6128 compatible.
Since a CPC 6128 case would not have any openings for cartridges, CF cards or serial ports, anyway, moving the relevant interface circuitry into an expansion makes perfect sense and leaves more board space for things that absolutely have to be on the system board.

Speaking of which...
Since the KC compact design uses a discrete SRAM chip for its palette and since the smallest suitable "modern" SRAM chips are already 8 KiB large, I have toyed with the concept of a scanline counter for a while.
That would add some four or five logic chips to optionally enable separate palettes for every scanline, or alternatively very fast palette switching via interrupt.
This concept would be particularly interesting for patching existing games, because individual colors could be trivially replaced with vertical color gradients.
It also means that every video mode without exception can have 256 colors on screen without bothering the CPU.

What are your thoughts on the two points above?

[Benedikt]

Considering that the spare address lines in the cartridge interface permit up to 2 MiB of ROM, what about a pair of cartridge ports that each support cartridges with up to 1 MiB?
That would be in line with the overall design goal to make the machine roughly twice as good.
The flow control lines DTR and RTS of the DART's second serial port could be used to switch the cartridge ports on and off and to swap their addresses.
With such a mechanism, the machine could boot from its internal firmware ROM, initialize the hardware, copy code to RAM, enable the cartridge port, scan for known firmware and e.g. skip past its initialization of the keyboard layout tables.
Something like that would be necessary to make language cartridges like Amstrad's BASIC cartridges genuinely useful.

Speaking of cartridges...
Since I do not own any CPC cartridges, I quickly designed my own PCBs for an ACID-less cartridge and called the design *drum roll* "Base Cartridge".
Its main innovation is that it uses a 74AHCT74 dual D flip-flop for the no-ACID solution. One of the D flip-flops is simply wired up as an inverter for the second flip-flop's clock signal to mimic the behavior of a negative-edge triggered toggle flip-flop.