This thread is about my recently started long-term project: The construction of a new, enhanced CPC6128 compatible computer that is loosely based on the schematics of the KC compact.
The rationale behind basing the new machine on the KC compact is that it managed to achieve a very high level of compatibility exclusively with standard components from that era.
There is therefore no need to slaughter a CPC for its gate array, nor is there any need to resort to spooky alien technology from the future, such as FPGAs or 32-bit microcontrollers.
My ideas for the for the system's overall specifications are that
- Everything should feel like a well-balanced, natural evolution from the classic CPC product line
- The system should be roughly twice as good in every way, possibly better
I therefore came up with the following goals
- Between 256 KiB and 1024 KiB of RAM, ideally as a pair of SRAM chips
- Two AY-2-8910 PSGs for additional polyphony and additional control lines, on-board Digiblaster
- 16 bit data path for pixel generation and duplication of the relevant logic for twice the color depth
- Bypassable EGA-like latch in the second RAM chip's data path to keep block fill/copy operations fast
- At least one attribute mode, e.g. for colorful high-res pseudo text modes
- The Plus-series' connectivity, but keep the KC compact's SCART port and bi-directional 8-bit printer port
- Ideally some way to optionally double the CPU clock and/or FDC clock, if feasible
- Internal IDE and Serial ports, if it fits
- The CPC6128's form factor: System board should fit inside a German CPC6128 case
- High quality keyboard with n-key rollover
- Design for a laser-cut case, e.g. for a painted plywood case
To maximize the benefit for the broader CPC community, as many parts as possible should also be usable to fix or enhance existing CPCs.
The current state of affairs is that the keyboard assembly for the KCC plus is ready. It will get its own thread, because I reckon that it will be particularly useful for CPC users.
The next step is to design evaluation boards for various parts of the system, such as clock generation, audio, RAM, pixel generation, storage etc.
These will initially connect to a CPC and, where feasible, will be designed to be usable as CPC expansions.
Please share your thoughts!
While I'm not among the potential customers for this kind of things, I love to follow the news on them as after all, they're pretty cool.
So a few months ago, I created a topic on this forum that can be very interesting to you, as it has a lot of ideas from fans like me and true experts:
Amstrad CPCnext: Would you buy one? (https://www.cpcwiki.eu/forum/general-discussion/do-you-wish-there-was-an-amstrad-cpcnext/)
Also, it's great (and unusual) that you're "relatively new to the CPC world (https://www.cpcwiki.eu/forum/general-discussion/hi-there!-21237/msg239596/)". Can you elaborate on that? I mean, you need to really like the CPC to create your project, but you apparently didn't have one in the 80s or 90s. What is exactly your story? What made you interested in Amstrad's machine? What is... the magic of the CPC? 8)
(As a general comment, the Amstrad-related scene is amazing these days: several mdoern games look like Amiga games, one single Spanish guy created a Sensible Soccer clone, a GTA clone and a mode-7 demo, two more Spanish guys have just created a point & click graphic adventure... and now someone "new to the CPC" wants to build a CPC Next... what does the CPC have?).
I love the idea. I'm personally looking forward to the new keyboard.
The expansions should best be compatibly with already existing hardware, like the additional sound chip could e.g. be compatible to the PlayCity expansion.
Oh YES!
Quote from: cwpab on 13:56, 12 May 24While I'm not among the potential customers for this kind of things, I love to follow the news on them as after all, they're pretty cool.
To clarify something that must have gotten lost when I wrote the initial post:
For both, bureaucratic and logistical reasons, I will not be selling any hardware, except for the occasional spare PCB, perhaps.
The goal is a
publicly available, free design that anyone who can hold a soldering iron can build.
The goal is
less that people
admire my work, and
more that people can
replicate my work.
Quote from: cwpab on 13:56, 12 May 24Also, it's great (and unusual) that you're "relatively new to the CPC world (https://www.cpcwiki.eu/forum/general-discussion/hi-there!-21237/msg239596/)". Can you elaborate on that? I mean, you need to really like the CPC to create your project, but you apparently didn't have one in the 80s or 90s. What is exactly your story? What made you interested in Amstrad's machine? What is... the magic of the CPC? 8)
My story is that I was not even around when any of the machines in question hit the market, but learned programing on the PC platform with a then decade-old IDE for MS-DOS.
What makes me interested in the CPC is its simplicity combined with its similarity to the original IBM PC platform, and ironically the
absence of magic.
The engineers in Mühlhausen have shown that a CPC can essentially be built without any special components, as long as you can live with a somewhat larger chip count.
Quote from: eto on 14:39, 12 May 24I love the idea. I'm personally looking forward to the new keyboard.
I have to admit that I still have not made use of your second pair of adapter PCBs, but we will get there. :)
Quote from: eto on 14:39, 12 May 24The expansions should best be compatibly with already existing hardware, like the additional sound chip could e.g. be compatible to the PlayCity expansion.
That is the plan, but admittedly not in the case of the PlayCity expansion:
- The first 320 KiB of RAM will be Dk'Tronics compatible, the first 576 KiB Dobbertin compatible, the full 1024 KiB will use RAM7's technique
- The DAC will be a Digiblaster compatible Bourns SIL R2R resistor network
- The AY-3-8910 PSGs will use the canonical multi-PSG addressing described in the data sheet, using external XOR gates to imitate the mask-programmed chip addresses
- The RTC, if included, will be Dobbertin compatible, because only a single "phantom clock" chip is needed
- The Serial Port, if included, will be Amstrad compatible
- The IDE interface, if included, will be compatible with Yarek's IDE8255, because of that design's simplicity
- The 8-bit bidirectional parallel port will be KC compact compatible, the 7-bit output Amstrad compatible
- The expansion port itself will use the familiar 50-pin micro ribbon connector, i.e. no obscure Robotron part
and still only 64kB for CRTC?
Quote from: McArti0 on 22:13, 12 May 24and still only 64kB for CRTC?
Yes. The plan is to give the CRTC an unmodified address space of 64 KiB.
But I also plan to give the pixel generators a 16 bit wide data path to a pair of 64 KiB pages in RAM, which means that the total size of the frame buffer will be up to 128 KiB.
A 128 KiB frame buffer should be sufficient for a well-balanced CPC-like system without an intelligent GPU.
For instance, an interlaced 4-color mode with 640x400 pixels would use 64000 bytes and expanding it to 832x576 pixels would still only fill 119808 bytes and leave 11 KiB free.
@Benedikt and will it be possible to display something like this?
https://www.cpcwiki.eu/forum/index.php?msg=215472
This sounds like a fascinating project.
Using SRAM in an Amstrad is non-straightforward due to timing issues, but it's not hard to fix. I haven't had a chance yet to publish any details of how I did it, but feel free to ask.
Also, if there's anything in my projects that's of use you're welcome to them. https://github.com/Bread80
The CPC Modular repository is not up to date but may well be useful. I created the project to break out the CPC into parts which I could work on separately. I now have a functioning backplane which breaks out almost all the standard Amstrad signal lines (or they could be repurposed). I'm planning a new version which fixes some layout issues.
I have uploaded the keyboard design to GitHub (https://github.com/roybaer/kcc_plus/blob/master/kcc_plus_keyboard/README.md#pictures) and created a new thread (https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/6128-compatible-mechanical-keyboard-with-n-key-rollover-kcc-plus) for discussions related to the keyboard.
Quote from: McArti0 on 22:54, 12 May 24@Benedikt
and will it be possible to display something like this?
https://www.cpcwiki.eu/forum/index.php?msg=215472
The best answer I can give is that if the KC compact can do it, the KCC plus will be able to do it.
Quote from: Bread80 on 12:49, 13 May 24Using SRAM in an Amstrad is non-straightforward due to timing issues, but it's not hard to fix. I haven't had a chance yet to publish any details of how I did it, but feel free to ask.
Hopefully the absence of Amstrad's gate array makes this one aspect slightly easier. We will see. But thank you for pointing it out.
Quote from: Bread80 on 12:49, 13 May 24Also, if there's anything in my projects that's of use you're welcome to them. https://github.com/Bread80 (https://github.com/Bread80)
The CPC Modular repository is not up to date but may well be useful. I created the project to break out the CPC into parts which I could work on separately. I now have a functioning backplane which breaks out almost all the standard Amstrad signal lines (or they could be repurposed). I'm planning a new version which fixes some layout issues.
Sounds interesting. A bunch of them will definitely end up in my bookmarks.
Hi Benedikt,
some work in this direction has been done in the past. I know I've seen details of a modern KC Compact design using all western 74 Series IC's, complete with a PCB layout. This could save you a lot of the initial groundwork. Maybe someone here knows where it can be found. If not, I can check my archives too.
Bryce.
Quote from: Bryce on 12:18, 14 May 24some work in this direction has been done in the past. I know I've seen details of a modern KC Compact design using all western 74 Series IC's, complete with a PCB layout. This could save you a lot of the initial groundwork. Maybe someone here knows where it can be found. If not, I can check my archives too.
I am only aware of a modern redesign of the expansion unit that contains the floppy disk controller and the upper 64 KiB of RAM.
If there is a redesign of the system board, too, that could indeed be interesting.
I thought there are already replacement gate arrays
Yes there is a commercial available GA alternative. But Benedicts approach is to use "old" 80s technology to achieve the same instead of a microcontroller.
Building the GA in TTL logic like the KC compact did will overcome this topic.
Quote from: Benedikt on 19:27, 14 May 24Quote from: Bryce on 12:18, 14 May 24some work in this direction has been done in the past. I know I've seen details of a modern KC Compact design using all western 74 Series IC's, complete with a PCB layout. This could save you a lot of the initial groundwork. Maybe someone here knows where it can be found. If not, I can check my archives too.
I am only aware of a modern redesign of the expansion unit that contains the floppy disk controller and the upper 64 KiB of RAM.
If there is a redesign of the system board, too, that could indeed be interesting.
You're right. I was mixing it up with the Aleste 520 project. :(
Bryce.
necessarily in the CPC6512 style, i.e. with 41256-70 (or 44256)
Quote from: SerErris on 12:16, 18 May 24Building the GA in TTL logic like the KC compact did will overcome this topic.
And it makes pixel generation (almost) trivially expandable in some ways.
For instance, I would like to give the machine a 256 color hardware palette, and perhaps the possibility to select several variants of that hardware palette.
The KC compact's circuitry can be trivially expanded to 64 colors – it uses two bits per primary color – and most of the pixel generation data path is eight bits wide, already.
Since the KC compact's design uses SRAM chips for the palette entries, we could also add a line counter and implement separate palettes per scan line.
The rationale is that the smallest "modern" parallel SRAM chips have 8 KiB, anyway, and only using the first 16 bytes of 8 KiB would be a huge wasted opportunity.
The addition of video modes with doubled bit depth will be more involved, because the data path to the system RAM has to be widened to 16 bit, but the actual pixel generation should be simple.
All of the above would result in e.g. a "mode 1" variant with 320x200 pixels and 256 colors on screen, namely with a 16 color palette per scan line.
A true 256 color mode would also be possible, namely as "mode 0" that uses two RAM pages in parallel.
I also really want to squeeze in an attribute mode for colorful high-res "text modes", ideally with a backwards compatible RAM page for 1 bpp graphics and another RAM page for color attributes.
We will see how well that integrates with the rest.
Quote from: McArti0 on 18:49, 18 May 24necessarily in the CPC6512 style, i.e. with 41256-70 (or 44256)
A pair of big SRAM chips sounds more practical, these days.
Quote from: Benedikt on 20:04, 18 May 24A pair of big SRAM chips sounds more practical, these days.
What I mean more is two banks of internal memory larger than 64kB
A new KCc - great idea - please implement RAM configuration &C3 like it exists on CPC6128 computers. All 'RAM expansions' before were not made by Amstrad, so they lack the &C3 feature. That's fine for games and simple stuff, but not for serious software. :)
And for ports: Please use these reliable Centronics connectors. PCB just suxx, because of its instability.
Quote from: GUNHED on 17:09, 21 May 24A new KCc - great idea - please implement RAM configuration &C3 like it exists on CPC6128 computers. All 'RAM expansions' before were not made by Amstrad, so they lack the &C3 feature. That's fine for games and simple stuff, but not for serious software. :)
Since the KCc, while modeled after the CPC6128, only had 64 KiB on its system board and the remaining 64 KiB in its external floppy disk controller, I am going to use an ATF16V8 with known-working configuration for RAM banking, i.e. copy this aspect of the CPC6128's design.
Quote from: GUNHED on 17:09, 21 May 24And for ports: Please use these reliable Centronics connectors. PCB just suxx, because of its instability.
As mentioned before, the expansion port will have exactly that 50-pin micro ribbon connector, but I will use a DB25 connector for the printer port.
If the FDC stays on the system board at all, there will only be an IDC pin header for it, because the position where the CPC6128 has its external floppy disk drive connector will already be occupied by the SCART socket.
However, the video logic will need an awful lot of space and has to be on the system board. I might therefore have to kick the FDC off the system board and put it in a KCc-like expansion.
On the bright side, a cartridge port – or a pin header for it – will then probably fit on the system board.
There is one alternative though, namely to switch to SMD logic to squeeze as much functionality as possible on the system board itself.
Quote from: Benedikt on 18:03, 21 May 24I am going to use an ATF16V8 with known-working configuration for RAM banking, i.e. copy this aspect of the CPC6128's design.
But PAL produces CAS0, CAS1 signals for two parts of RAM. If you want to read 16bit from two banks, the CAS0,1 signals must be modified.
Yes, the modern printer port is a good idea of course. :) :) :)
Maybe some Mother MX4 slots? If space available on PCB?
Quote from: McArti0 on 10:06, 22 May 24Quote from: Benedikt on 18:03, 21 May 24I am going to use an ATF16V8 with known-working configuration for RAM banking, i.e. copy this aspect of the CPC6128's design.
But PAL produces CAS0, CAS1 signals for two parts of RAM. If you want to read 16bit from two banks, the CAS0,1 signals must be modified.
Good point!
Quote from: GUNHED on 16:49, 22 May 24Yes, the modern printer port is a good idea of course. :) :) :)
Maybe some Mother MX4 slots? If space available on PCB?
The "modern" printer port... :laugh:
Both, the KCc and the 6128 Plus had DB25, already.
My current projection for the amount of space left on the system board is roughly -50%, so... no. ::)
Quote from: Benedikt on 20:51, 12 May 24The 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 :)
Quote from: Benedikt on 19:11, 22 May 24Both, the KCc and the 6128 Plus had DB25, already.
Exactly! But the 464/664 only had edge pcb connectors. A standard printer cable is just more easy to get. Well, even if I think that printing may not be the main application for CPCs in future...
Quote from: BSC on 20:35, 22 May 24Quote from: Benedikt on 20:51, 12 May 24The 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. :laugh:
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.
Quote from: Benedikt on 10:11, 02 June 24Quote from: BSC on 20:35, 22 May 24Quote from: Benedikt on 20:51, 12 May 24The 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. :laugh:
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.
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.
Quote from: Benedikt on 18:33, 02 June 24The 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.
Actually, 4 MB of RAM would be really nice. :) :) :)
Quote from: SerErris on 12:16, 18 May 24Benedicts approach is to use "old" 80s technology
That eliminates sdcards, m4, goteks etc... gonna get 3" drives from doner CPCs?
Quote from: abalore on 20:14, 02 June 24The 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.
Quote from: abalore on 20:14, 02 June 24Yes, 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.
Quote from: GUNHED on 14:45, 03 June 24Actually, 4 MB of RAM would be really nice. :) :) :)
Err... probably not on the very, very crowded system board.
Quote from: zhulien on 16:53, 03 June 24Quote from: SerErris on 12:16, 18 May 24Benedi[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.
Quote from: Benedikt on 17:24, 03 June 24Which VCC did you pick? It would be kind of awkward if I got that backwards and made it incompatible.
Pin 2
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.
Quote from: abalore on 17:49, 03 June 24Quote from: Benedikt on 17:24, 03 June 24Which 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.
Quote from: abalore on 17:49, 03 June 24Here 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.
Quote from: abalore on 17:49, 03 June 24Quote from: Benedikt on 17:24, 03 June 24Which 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
Quote from: overange on 20:06, 03 June 24Pin 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 (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.
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. :) :) :)
Quote from: GUNHED on 10:59, 05 June 24Well, 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.
Quote from: abalore on 17:49, 03 June 24Here 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? ???
Quote from: Benedikt on 12:04, 09 June 24Quote from: abalore on 17:49, 03 June 24Here 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.
Quote from: abalore on 18:37, 09 June 24The 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. :laugh:
Quote from: abalore on 18:37, 09 June 24Respect to CA14 in the array, you are right, it must be probably Q0 instead.
Yes, that makes a lot more sense.
btw: another KCc just sold in Ebay Germany for 850 Euros.
Quote from: GUNHED on 15:54, 17 June 24btw: 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...
Quote from: eto on 16:51, 17 June 24Quote from: GUNHED on 15:54, 17 June 24btw: 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.
A faithful KCc emulator would be a real gem. There is none yet sadly.
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.
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)
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?
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.