WIP: internal 512K expansion

[eto]

Do you sell them? Or is somebody going to build a batch?

Not really.

I made 4 PCBs that I will sell on Ebay to cover the development costs. A few people on the classic computing forum asked if they can get one so I ordered another batch of 10 PCBs + all components but I will only offer them as DIY packages and only with shipping in Germany, maybe EU (but shipping then adds at least 50% to the price).

I guess once it is released that it will be picked up from some sellers and as the components are dirt cheap (if bought in quantities) it should be feasible to sell it between 25 and 30€ and still make a profit. One guy from the UK already contacted me on Facebook and wants to build a few and sell them at Retcon 25.

[eto]

Good news regarding the 464 version:

It seems it runs stable now and I even managed to add the option to switch between C3 support (512K of total RAM) or non-C3 support (576K of total RAM). In the picture below the switch is simulated by the orange wire which I connect either to GND or VCC to turn it on/off.

With C3 (and the 6128 firmware) the 464 can properly load the Amstrad CP/M discs.

I ordered a batch of updated PCBs and then it's hopefully finished. I tried to find a design that fits into all 464 and 664 versions. I had to rely on the mainboard version pictures on the Wiki as I unfortunately only have a single version of the 464 here.

[GUNHED]

Now it's time for a 4 MB internal expansion for the CPC6128. One of mine has that already, but it did need soldering on the main PCB sadly.

[eto]

Now it's time for a 4 MB internal expansion for the CPC6128. One of mine has that already, but it did need soldering on the main PCB sadly.

I looked into it when I started development and in theory it's possible but one of my key aspects is DIY friendlyness - and a 2MB/4MB expansion is not DIY friendly.

• Soldering should be easy: Due to the available space it needs to be SMD components. They won't be easy to solder for everyone.
• No special equipment/skills needed: if you have SMD components or use more complex CPLDs you also need special equipment to program them.
• Cheap: Also everything is immediately no longer "cheap" and easy to source. The things on this board can all be found easily and for a few bucks. In theory the 2MB SRAMs are not too expensive but they are usually only available from distributors where you either need to order a lot or you have to pay a lot for shipping.
• Long term availability: The ICs on this board have been available for ages and are probably available for ages.

[McArti0]

DS1270Y-70 and knife

[eto]

DS1270Y-70

Is that a suggestion? If yes, where can we buy that reliably in small and big quantities for the next 5 years and for less than - let's say €50?

[d_kef]

DS1270Y-70

Is that a suggestion? If yes, where can we buy that reliably in small and big quantities for the next 5 years and for less than - let's say €50?

For €50 you can get 1/5th of it...
https://www.digikey.de/short/53q0q89f

d_kef

[eto]

Update:

New PCBs for the 464 version arrived.

Seems I still have an issue with the C3 mode.

CP/M plus: works fine in C3 mode
Phortem/PHX/Pac-Man emulator: work in C3 mode

FutureOs: weird mouse sprite in both C3/non C3 mode
Dandanator: only properly loads snapshots in non-C3 mode

@GUNHED maybe you can support here with some insights. attached you can see what happens. Seems like it retrieves the background from the wrong area in RAM or ROM. Can you please explain wht is happpening in FutureOS when the sprite is drawn? That might help to identify what I have missed in the C3 implementation.

[GUNHED]

Yes, this happens if RAM mode &C3 does not work properly. 
In detail, the Video-RAM was not successfully moved from &C000 to &4000.

Please refer to Revaldhinos RAM expansion, he got it working on CPC464 too. 

However, there won't be much CPC464 users being interested in FutureOS anyway.

[eto]

Please refer to Revaldhinos RAM expansion, he got it working on CPC464 too. 

Same idea but totally different implementation.

The question was more like what exactly you are doing. Copy from ROM to RAM? Which address (range) to which address (range)?

But I can also just drop FutureOS support.

[GUNHED]

Please refer to Revaldhinos RAM expansion, he got it working on CPC464 too.

Same idea but totally different implementation.

The question was more like what exactly you are doing. Copy from ROM to RAM? Which address (range) to which address (range)?

But I can also just drop FutureOS support.

Feel free to do what you want. Your choice! 

What happens with CPC6128?
- &C3 moves V-RAM from &C000 to &4000
- data is written from &C000 (ROM) into RAM at &4000-&7FFF (depending on pointer position)
- to restore V-RAM: V-RAM data is read from &4000-&7FFF into a buffer, this step seems to fail. Instead to read from V-RAM it seems to read from ROM

You see, FutureOS is the 'real' &C3 test suite 

[eto]

- to restore V-RAM: V-RAM data is read from &4000-&7FFF into a buffer, this step seems to fail. Instead to read from V-RAM it seems to read from ROM

ROM should never be at &4000-&7FFF, so I don't think that's it. But it could be the buffer. Where is the buffer located? Somewhere in 0-3fff? And from there it is copied back to VRAM when you update the mouse pointer?

[andycadley]

ROM should never be at &4000-&7FFF, so I don't think that's it.

Unless it's a Plus...

[eto]

ROM should never be at &4000-&7FFF, so I don't think that's it.

Unless it's a Plus.

Sure, but as this is a CPC 464, ROM can't be at &4000

[GUNHED]

- to restore V-RAM: V-RAM data is read from &4000-&7FFF into a buffer, this step seems to fail. Instead to read from V-RAM it seems to read from ROM

ROM should never be at &4000-&7FFF, so I don't think that's it. But it could be the buffer. Where is the buffer located? Somewhere in 0-3fff? And from there it is copied back to VRAM when you update the mouse pointer?

The buffer is between &B000 and &B7FF.

The problem is probably at the stage where the function read the data from &4000-&7FFF, and that shall be V-RAM (upper block banked down in &C3 mode)

Just try if you can write to block 1 in C3 mode, is shall be on the screen.

[eto]

The problem is probably at the stage where the function read the data from &4000-&7FFF

yes, that's where I have the bug: while in C3 mode when the CPU reads from VRAM at &4000-&7FFF I need to activate A15, so the physical address range is converted to C000-FFFF. This access should go to the SRAM only and must not be passed through to the motherboard but for reasons I still do not understand that's happening - and since the ROM is active, it then reads data from ROM.



 

[McArti0]

Is your A15-z80 gated?

When you set C3 in basic, does CTRL+SHIFT+COPY work for you?

[McArti0]

I think that for C3 you need to add ROMDIS for z80-A14=1, z80-A15=0, because GA gets CPC-A15,A14=11, Hrom=Enable and will always enable /ROMEN.
Or you must gated Z80-MREQ and disable CPC-MREQ.

[eto]

Or you must gated Z80-MREQ and disable CPC-MREQ.

That's how it's done.

It also perfectly works as long as C3 access is triggered from RAM. Then there is no conflict But as soon as the upper ROM is active I get the data from the ROM.

I first thought I have to have some error in my equations but I'm currently wondering if the GateArray maybe does not evaluate MREQ to set ROMEN. It might also check IORQ=1, RD=0. 

That could explain why there is no issue when I access it from RAM (MREQ is evaluated and GateArray does not activate base RAM) but there is an issue when I access it from ROM (MREQ is not evaluated and GateArray sets ROMEN). 

I'll do a test for that as soon as I have time. 

[McArti0]

Do you have 40007, 08, 10? 

In addition to MREQ, also gate to RD=1, there is no force for the ROM to turn on.

[eto]

Do you have 40007, 08, 10?

10

In addition to MREQ, also gate to RD=1, there is no force for the ROM to turn on.

That's exactly what I meant when I wrote "I'll do a test for that as soon as I have time. " - sorry, that was not clear. I need to cut a few lanes on the PCB, make new connections and free up a pin on one of the PALs. No big issue but I don't have time over the next couple of days.

[McArti0]

I would suggest first writing a tight loop and viewing it on the oscilloscope.

I can't believe your 40010 isn't reading MREQ to enable ROM

[McArti0]

https://www.cpcwiki.eu/index.php/File:40010-simplified_V03.pdf

[eto]

https://www.cpcwiki.eu/index.php/File:40010-simplified_V03.pdf

That's why I expected that MREQ is sufficient. As it says "not verified against real 40010" I can't rely on it and it might still be different. 

I would suggest first writing a tight loop and viewing it on the oscilloscope.

I don't have one here at the moment. 

[McArti0]

You can do a hardware stop, ROMEN join to WAIT/READY.