Converting classic CPC to plus idea (fantasy)

[martin464]

As it's fantasy stuffed in the off topic

It'd work with an expansion containing a + gate array chip (decapped clone) which would operate in sync with the existing GA but access it's own set of external RAM for video

So ya got a PCB with the video and gate running off ram in the expansion
Writes to the first 64k are shadow copied to the 64k in the expansion thus there's always a copy of the inboard 64k externally, meaning existing games will work as the screen ram is inboard for the code and also externally shadowed for the hardware. everyones happy.

the only reason to shadow the 64k is of course so the external gate/video chips can chug their data off it in peace without the original inboard interfering

but how to deal with IO access to GA? doesn't matter - the external one will occupy the same port and mirror the crtc registers. this will work i guess

at the end of it, you get a classic cpc with the + features

warning - the temptation to further improve the video charactistics is best forgotten
only to give the cpc the + features that's the limit
a nice VGA output port would be ok though

would it work? of course it would, it's a fantasty!

[andycadley]

Well, yes, but it's basically the same as gluing a GX 4000 to the back of your CPC. And it's not like Plus ASICs are plentiful parts, so you'd have to figure out how to recreate one to begin with...

[dodogildo]

That reminded me a totally different project by @Piotr on converting GX4000 into a CPC Plus. I don't know how it ended up. That was a long time ago.

[Piotr]

GX ended well

http://eightbitclone.com/cpcw.jpg

I start from scratch

http://eightbitclone.com/base.jpg

[martin464]

kinda, well... the 2 old school gate array chips have been reproduced. the asic would be a more complicated (fun?) project.

the stuff being added would be the asic replacement and 64k ram. possibly a sound chip, not sure about that. rather than seeing it as a gx4000 strap-on its more like adding a graphics card to the cpc which happens to give it + compatibility. there's no Z80 required

challenges would be things like turning the 4mhz clock into 16 and aligning it with the onboard GA.
 

[eto]

Writes to the first 64k are shadow copied to the 64k in the expansion thus there's always a copy of the inboard 64k externally, meaning existing games will work as the screen ram is inboard for the code and also externally shadowed for the hardware. everyones happy.

An external "Super Gate Array". Indeed that could be the start of a Super CPC project.

Stage 1: Replicating the Gate Array features to get perfect VGA/HDMI output

All writes to GateArray and CRTC are also executed by the Super Gate Array Chip. The internal ICs are not replaced and will continue to make sure the CPC works as it should while the Super Gate Array emulates the display features of the original ICs. The output is then directly fed to a VGA or HDMI monitor while the outputs of the internal Gate Array continue to work and would output exactly the same image as the VGA or HDMI but there is no monitor connected. With this, we could finally have a perfect output for LCDs which also supports(emulates) all the CRTC tricks.

Stage 2: Enhancing the features - a Plus compatible graphics card for the CPC

Plus features are of course the natural evolution, giving all CPCs access to sprites and 4096 colours. But of course then we can also discuss about additional screen modes. E.g. 320x200 with 16 or 256 colours. Or a "high res" 640x480x16 mode for development and SymbOS. For those enhanced modes other RAM areas than the internal 64K need to be used and the internal Gate Array output would no longer be the same. So this output could be used as a second monitor (or just not being used at all).

However I am not sure if DMA sound will also be possible with that approach easily.

Stage 3: Taking over the control - The Super CPC

As a next step it could be possible to take over control from outside. Removing the internal Z80 and driving the CPC from the expansion bus. While the internal 64K are accessed, the expansion will behave like a real Z80 and everything is "normal". However when it's doing the work externally (including RAM/ROM) it could switch into a Super CPC mode where the local Super CPC RAM/ROM is accessed as fast as possible. The CPC would mostly be reduced to a keyboard while in Super CPC mode, however in compatibility mode, it's the normal CPC.

Stage 1 and 2 could maybe be achieved with something like a Raspberry Pico but for Stage 3 it requires much more computing power - maybe an approach like the the PiStorm on the Amiga.

A lot of work on software and hardware side.

[martin464]

eto interesting!

it could be worth splitting into 2 projects. 1 that's pure + only compatibility and another for further developments. but i still want my CPC to be 100% a CPC, for me the video limitations are part of the magic! i thought about it and in the end felt the + features are still 'cpc' for real

question, would it need a sound chip or could it 'dma' to the inboard one. that's a bit beyond me i'm doubtful it could...

PS the 'asic' could be simplified, not all the asic features are needed like the PPI and printer port

[eto]

it could be worth splitting into 2 projects. 1 that's pure + only compatibility and another for further developments.

Then we have stage 2a and stage 2b ;-) 

2a is "Plus" colours and sprites.

[martin464]

your stage 1 description is perfect btw - that's exactly it

it might be possible to output to the onboard sound chip from this. it was a stock AY chip on the +
maybe it could 'sneak' in outputs to PPI when the GA is active drawing the screen?

there's one boost that could be added to the 2a version...cause it works within the cpc limitations from another direction
that dma romba project... would permit 1us per byte writes to internal vram 
you could then stream video at a far higher rate from a storage device on symbos. its not a games update (i hope) i'd hate to see those goofy cut scenes make their way onto the amstrad. 

[andycadley]

there's one boost that could be added to the 2a version...cause it works within the cpc limitations from another direction
that dma romba project... would permit 1us per byte writes to internal vram
you could then stream video at a far higher rate from a storage device on symbos. its not a games update (i hope) i'd hate to see those goofy cut scenes make their way onto the amstrad.

Honestly, given the choice, I'd use that 1us to read from internal ram and into the ASIC sprite registers. Loading sprite data in fast enough is the absolute #1 pain point in the Plus architecture. I'd have even taken that over the DMA sound given the choice.

[martin464]

just so i understand the "pain point" is changing the ASIC 16k ram fast enough for sprites (eg to animate a walking character) since the 16k isn't enough to contain all your sprites' frames preloaded?

so a hardware based LDIR for fast ram copy?
using that DMA method i think it could copy RAM at 1us for read and another for write. 2us per byte. That's at least twice as quick than the fastest code way (4.5us per byte i thought - pop de: ld (hl), d: dec l: ld (hl), e: dec l)

the cpu is halted during the copy so its like one big long instruction being run and the z80 has a microseconds long tea break

guess the 2us per byte speed limit could be broken in theory with further building out an asic replacement on the expansion where it gets to manage its own access to memory. the limit then is whatever current technology supports or maybe 250ns to keep it appropriate to the 80's!

i'm beginning to wonder if the cpc+ graphics update wasn't so bad after all, i actually sat down and read the specs last night and came away feeling far more impressed than i started. in fact, i was kind of taken aback, maybe these kinds of tweaks could make sense keeping the asic as a base to work from

[andycadley]

just so i understand the "pain point" is changing the ASIC 16k ram fast enough for sprites (eg to animate a walking character) since the 16k isn't enough to contain all your sprites' frames preloaded?

Well the problem is it isn't 16K. Each sprite is stored in 256 registers (that are memory mapped). So even if you wanted every sprite loaded with the same image you have to copy 16*256 bytes. And you can't store different frames in the ASIC, you have to rewrite the bytes in order to change what a specific sprite looks like.

It's not impossible to manage, but it is probably the most awkward bit of the design. It also makes multiplexing sprites difficult, simply because it takes a lot of time to reload each sprite.

i'm beginning to wonder if the cpc+ graphics update wasn't so bad after all, i actually sat down and read the specs last night and came away feeling far more impressed than i started. in fact, i was kind of taken aback, maybe these kinds of tweaks could make sense keeping the asic as a base to work from

Honestly it's really quite well done given the restrictions of not changing the overall timing of the system. It's probably not how you'd want to design a console system from scratch, but as an improvement to the base CPC computer it's not bad. I think if Amstrad had not tried to hide the new functionality and instead provided some RSX to allow BASIC access (ala BANKMAN) the machines might have been a bit better received.

[martin464]

ok (re-read documents) i think i get it now, it's 4k of sprite data which would normally be 2k of mode 0 pixels except it's 1 byte per pixel with the upper nibble ignored. a grand total of 64x64pixel sprite area if all 16 sprites were combined

[martin464]

the showstopper here is there isn't a magic dude to recreate the asic chip. even with the decoding of it, it could take forever. but there's no alternative than to re-create it exactly as designed.
maybe the schematic could be broken into sections and done one small piece at a time.

[eto]

the showstopper here is there isn't a magic dude to recreate the asic chip. even with the decoding of it, it could take forever. but there's no alternative than to re-create it exactly as designed.
maybe the schematic could be broken into sections and done one small piece at a time.

Instead of recreating the logic it might be easier to make a Plus-compatible graphics adapter for the CPC range which is based on a micro controller and emulates the GateArray/CRTC/ASIC. 

This can be attached to the expansion bus. It reacts to all CRTC/GateArray commands and outputs to a DVI/HDMI port. The CPCs GateArray works in parallel and outputs the exact same picture. 

You cannot view this attachment.
This step obviously has only few advantages, e.g. to attach a DVI/HDMI screen directly to the CPC without the hassle of scan doublers and (potentially) the full (emulated) support of all CRTC tricks. 

Once this works, it should also be possible to add more features. E.g. the ASIC emulation. In addition to a simple shadowing ASIC emulation then also requires to prevent writes to the internal RAM, when the ASIC is paged in:
You cannot view this attachment.

Here, the GateArray output will still be identical, as long as no ASIC features are being used - but as soon as this is activated, the monitor output will be more or less garbage. 

From there, additional features like further resolution or DMA access is then "just" a matter of software.

[martin464]

heck that would do it!

i'm fairly a noob on microcontrollers. i wonder what speed would be needed to pull this off
i'd have thought it depends on if the essential code were in assembler or compiled, the extra work to write in assembler would probably reduce the spec of the microcontroller needed maybe to something like 50mhz? or perhaps this isn't worth it and they're just powerful enough and cheap that it doesn't matter

[andycadley]

The ASIC itself is 40MHz and doing it entirely in hardware. I'd expect a microcontroller would need to be significantly faster to achieve the same in software.

[martin464]

yes that's what i thought, except i didn't know the ASIC was 40mhz I assumed it was 16 like the gate array. hmmm
i think the spec could be worked out from the angle that we know we need to generate the raster quick enough which is 250ns

if our z80's can start to do useful stuff around the 4us per byte range approaching 40mhz seems to be where it starts to look fast enough to do things in the low 100's of ns. doubling it for luck a 100mhz device might do it, but only in pure assembler. given the logic maybe that would end up a few hundred mhz

as a luddite i doubt even low level languages come anything close to assembler, i think at least 1ghz would be needed for compiled code to keep up
the ideal thing would be to find a processor family with the same instruction set at various speeds and price points rather than committing up front to a single solution then finding out it isn't quick enough, or worse that it was too fast

[McArti0]

Milk-V 1GHz 64MB

[robcfg]

So you get a picture of what it's inside the ASIC, check these decap pictures:

https://k3pi.chickenkiller.com/dzi/acid2.html

https://k3pi.chickenkiller.com/dzi/metal3.html

As bonus here's also a deep zoom image of the PreASIC chip:

https://k3pi.chickenkiller.com/dzi/preasic_metal20x.html

[martin464]

Milk-V 1GHz 64MB

that seems about right for a compiled code
for assembler maybe a PIC32MZ2048EFH064 could do it, 16 bit 250mhz, 512k ram built in and flash store for code
an older school minimalist approach might be more fun?

[andycadley]

So you get a picture of what it's inside the ASIC, check these decap pictures:

https://k3pi.chickenkiller.com/dzi/acid2.html

https://k3pi.chickenkiller.com/dzi/metal3.html

As bonus here's also a deep zoom image of the PreASIC chip:

https://k3pi.chickenkiller.com/dzi/preasic_metal20x.html

Those links flag up all the warnings in my browser. I don't suppose there's a chance of putting any decapped images on the wiki?

[robcfg]

I think it's because of the subdomain, but I can assure you that they're safe as I'm hosting that myself on a trusty Raspberry Pi.

Regarding uploading them to the wiki, you need to talk to @Gryzor about that as they are around 2GB all together .

[Gryzor]

2GB? What on earth 😂 Now I'm intrigued... 

[megachur]

it's big RAW picture ;-) !

But if @gerald can see them we can have a better emulation of this 2 chipset in the futur !!!

Thank you for sharing!