News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

c't memory upgrade for CPC 6128

Started by OCT, 22:44, 07 February 10

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

OCT

Browsing through http://cpcwiki.eu/index.php/Peripherals#Memory_Expansions_.2F_RAM_box I realized there has been another memory upgrade (to 512 MB, or was it even 1024?) back in an 1987 approx. issue of German IT mag c't, which worked (a bit like http://8bit.yarek.pl/upgrade/cpc.cpc4mb/cpc4mb1.jpg) by replacing the memory chips and adding a custom logic array.

Regrettably the issue at my city library at the time had been lost before I could make a copy, and the publisher's indexed online archive only seems to go back to 1990.
c't being a mag well worth keeping (to the detriment of the WAF, but it's them who popularized that term as well), I'm sure though it does still sit on some industry veteran's shelf.

OCT

No one around to find this anymore?
Speaking of c't 1987 A.D., while you're at it, issue 7 of that year also had an article on the various flavours of Shugart bus that might be useful for getting drives to work.

Ygdrazil


OCT

#3
Quote from: Ygdrazil on 18:21, 14 February 10
Please find this issue !! :o
This little piece of information in German says the upgrade was to 512kB, in issue 10/1987: http://de.wikipedia.org/wiki/Amstrad_CPC#Aufr.C3.BCsten_auf_512_KB
The name and number of the beast thus summoned were proposed to be CPC 6512.
Several follow-up articles in 1988 approx. seem to have covered the use of what then was a magnificent amount of memory as a print spooler and pre-populated RAM disk.
It is not known if there would be a way for the 464s and 664s to benefit from an enhanced version of that project.

CPCIak

Why don't you ask heise directly? Maybe they have got the article in their archive.

heise online
Helstorfer Str. 7
30625 Hannover
Postfach 61 04 07
30604 Hannover
Tel.: +49511 5352-0
Fax: +49511 5352-129
E-Mail: webmaster@heise.de

BTW: I've seen a CPC6128 with 576kb here
http://www.family-zeiger.de/cpccom/CPCCOMII.html

OCT

Quote from: CPCIak on 09:45, 15 February 10
Why don't you ask heise directly? Maybe they have got the article in their archive.
I'm sure they do, just wanted to point out there was indeed such a thing (not the April Fool in similar vein that got a French mag sued) and that it might merit some coverage among the memory extensions, probably even from proud owners of the mod around here.
Interestingly the pictures you linked to show there also was some sort of hard disk support for (enhanced) AMSDOS:

- as is much sought after for the SYMBiFACE II in this thread: http://cpcwiki.eu/forum/index.php/topic,559.0.html#msg5397

CPCIak

#6
I think you should contact the people at heise in order to get insider infos.

Quote from: OCT on 20:34, 15 February 10
I'm sure they do, just wanted to point out there was indeed such a thing
You are right OCT, it wasn't a April Fool's joke in the c't. The French publication was one.

Tolkin

There is a C´T Archive DVD where the first years of the Mag as PDF are stored.
I saw it on Emule a few years ago...


CPCIak

OCT, did you get more infos about die memory upgrade by c't???

Devilmarkus

Quote from: CPCIak on 09:45, 15 February 10
BTW: I've seen a CPC6128 with 576kb here
http://www.family-zeiger.de/cpccom/CPCCOMII.html

I can also write in the OS-Rom, what I want.
The showing of amount of memory is not a indicator that the ram also exists in real.
But many people had 64k + 512k ram expansion.
When you put your ear on a hot stove, you can smell how stupid you are ...

Amstrad CPC games in your webbrowser

JavaCPC Desktop Full Release

TFM

#11
Quote from: Devilmarkus on 15:12, 07 March 10
I can also write in the OS-Rom, what I want.
The showing of amount of memory is not a indicator that the ram also exists in real.
But many people had 64k + 512k ram expansion.

Don't be jealous :-)

The good thing about the ct'RAM expansion is that you can use ALL 512KB as screen memory!!! (But you have to solder it in your CPC).
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

arnoldemu

Quote from: TFM/FS on 23:47, 08 March 10
Don't be jealous :-)

The good thing about the ct'RAM expansion is that you can use ALL 512KB as screen memory!!! (But you have to solder it in your CPC).
Yes of course. This would be the only way for the crtc to access the ram and you would have to connect it to IC134,IC133, IC132, IC131, IC130, IC129, IC128, IC127 in a CPC6128 OR plug it into the gate-array socket and put the gate-array into the expansion (same way as Vortex ram expansion) for the Gate-Array to see the data from the RAM and to use it as screen memory.

The extra 64k ram is not connected up to the gate-array's databus.

Is this expansion similar to vortex? does the ram expansion have a socket for the gate-array to be put in and does it plug into the gate-array?


BTW, it would be great to see photos of the hardware you have.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

TFM

#13
No pics at the moment...

How they did it? The 6128 has 8 KB DRAMs. These 8 KB DRAMs have been repleced by 32 KB DRAMs. Thats the trick. This way the CRTC can access 8*32 KB (instead of 8*8 KB). So 256 KB are accessible by the CRTC finally. You switch the screen RAM by swtching the RAM! This way you can display 16 pictures of 16 KB with full frame-rate. Seen such demos in the 90ies. Nice!

Edit: Well, the good thing is (in contrast to Vortex) the c't RAM expansion is compatible to dk'tronics, Dobbertin and Inicron. However it provides 512 KB instead of 576 KB (so c't lacks the E-RAM blocks &7FFE and &7FFF).

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

nocash

Uh, what are you saying there... &7FFE and &7FFF ? I guess you mean "addresses" used in context with OUT [BC],C opcodes? Eg. writing Port [7Fxxh]=FEh, where FEh is data, not the address LSB.

And I don't understand the overall banking mechanism. Can one disable the VRAM bank switching effect? Or does it apply only for one half of memory?

Otherwise it wouldn't be dk'tronics compatible - okay, software for dk'tronics expansions WOULD work without crashing, but the screen would show garbage - which could be called by BIG compatibility problem.

What I have (maybe) understood is: One replaces all 16 chips. The first 8 chips extend the 64K "VRAM" to 256K. And the other 8 chips extend the CPC6128's "Extra" memory from 64K to 256K. The latter would be equivalent to a dk'tronics 256K expansion, right?

TFM

Quote from: nocash on 23:00, 10 March 10
Uh, what are you saying there... &7FFE and &7FFF ? I guess you mean "addresses" used in context with OUT [BC],C opcodes? Eg. writing Port [7Fxxh]=FEh, where FEh is data, not the address LSB.

Right &7FC4 for example means LD BC,&7FC4:OUT (C),C
Since low and highbyte can be different, depending on the amount of E-RAM you have, it's the easiest way (at least for me) to talk about it.
However, the highbyte &7F will only be different if you add more than 512 KB expansion RAM.

Quote from: nocash on 23:00, 10 March 10
And I don't understand the overall banking mechanism. Can one disable the VRAM bank switching effect? Or does it apply only for one half of memory?

Well, in the CPC 6128 the CRTC is physically connected to the first 64 KB, in detail it is connected to eight sockets of 8 KB.
Now, if these 8 KB RAMs are replaced by 32 KB RAMs (that's what the c't expansion is doing), then the CRTC is connected to all the 256 KB.
So the banking of the expansion RAM does (in THIS case) select the Video-RAM in addition.

Quote from: nocash on 23:00, 10 March 10
Otherwise it wouldn't be dk'tronics compatible - okay, software for dk'tronics expansions WOULD work without crashing, but the screen would show garbage - which could be called by BIG compatibility problem.

It is d'k tronics compatible. The thing with the CRTC is a kind of bonus, an additional feature.

Quote from: nocash on 23:00, 10 March 10
What I have (maybe) understood is: One replaces all 16 chips. The first 8 chips extend the 64K "VRAM" to 256K. And the other 8 chips extend the CPC6128's "Extra" memory from 64K to 256K. The latter would be equivalent to a dk'tronics 256K expansion, right?

Yes, exactly! Or let's say it's like a 512KB-64KB = 448 KB dk tronics expansion ;-)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

nocash

#16
Found somebody having the original c't articles, both (hardware schematic, and software driver) are now on http://cpcwiki.eu/index.php/C't_512_KB_internal_RAM_expansion

One unexpected thing is that it is not dk'tronics compatible, not even trying to do so. The 512K are accessed by writing C0h..DFh (on dk'tronics it'd be C0h..FFh). Some of the values do overlap, so there's some (unintended) compatibility.

The schematic has been confusing me: An obscure drawing with a LOT of odds & ends, bundled with a short notice saying that 4 of these odds & ends need to be connected to special locations, without further details on which ones to which locations. Took me some time to figure out what they meant. I've made a colorized schematic, which should be clearer on that part.

The article doesn't mention a hardware-based VRAM swapping feature (only a software-based example that copies RAM to VRAM via LDIR). Not sure if there's such a hardware feature at all - depends on the PAL logic...

Does somebody understand the syntax for the PAL chip? For example,

  IF (VCC) X = A * B +
               C * D

My current conclusions (may be wrong):
"IF (VCC)" means nothing, can be ignored.
"*" means AND
"*" has priority above "+"
"+" means ...what? xor? or?

Another example,

  IF (GND) /Y = /Y

I guess that doesn't mean anything at all (?) and can be ignored, too.

Bryce

Hmmm, not quite right:
VCC enables the Output buffers.
GND disables the Output buffers.

Other Symbols:
* = AND
+ = OR
/ = NOT
;+; = XOR
;*; = XNOR

Lots more, but I'm not going to list them all here :)

The a,b,c,d refers to chip pins (either inputs or outputs, defined in the header)
Priorities are defined by the sequence of the commands and brackets () can be used as in standard boolean syntax.

Bryce.

nocash

> VCC enables the Output buffers.
> GND disables the Output buffers.
Uh, what does that mean in practice?
In english/basic language "IF VCC X" would mean "If output buffer is enabled then X". But, that doesn't make any sense.
So, then, "IF VCC X" must mean "Assign X as output" ?

> Other Symbols:
> * = AND
> + = OR
> Lots more, but I'm not going to list them all here :)
Please not! Needed only the "+" (thanks!). I wonder what crazy person invented that syntax, using "+" when meaning OR, but not Plus! Must have been Louis XIV or somebody else where it'd be unwise to say that the idea is bullshit :-) and now we have to live with it :-/

> The a,b,c,d refers to chip pins ... defined in the header
Yup, got that. It's sometimes confusing,
  signal /X in schematic
  defined as X in header,
  and used as /X in formula
There seem to be double-triple-negations, hard to understand what they meant :-)

> Priorities are defined by the sequence of the commands
Okay. In this case, it seems to be the operations inside of a line having priority. And then the separate lines are merged with each other, right?

Bryce

#19
I always found the notation (+ = OR etc) to be very confusing too. No idea who came up with it. I think it was originally a computer-friendly version of Boolean, but because the Boolean symbols aren't on a keyboard, they chose other symbols.

I'd have to see the whole program to see what the IF (VCC) X actually does (as far as I can remember: IF (VCC) X in English means "If the output of Pin X is enabled then...."). I haven't used that language for almost 20 years, so I'm a bit out of practise :)

Signal /X in the schematic means the signal is active low, just like normal logic notation. The header cant use / in the name, so it's just called Pin X. In the formula the / is there because it's checking whether the pin is low. Yeah, confusing :)

The language is called PALASM and I think the latest compiler was called FusionPLD, but I'm not 100% certain. You might still find some documentation about it on the web, if you really want to know exactly what the program does.

Bryce.

nocash

Glad that it's not just me being confused :-) after thinking more of it, I think, + * was intended for "normal" people who were trained only in basic maths:
  1+1+1 = 3
  1*0*0 = 0
everybody could do that. And then you'd tell them "zero means false, and nonzero means true". Some way to teach logic in two minutes.

The IF part, I guess I figured out how it works:
  IF (condition) X = A + B
means to set X=A+B when condition=true, and otherwise set X=HighZ.
condition could be OutEnable signal or so. Using IF (VCC) just means "always" without condition.

The PAL source code is on page 4 of the scanned c't article (see above link).

> The language is called PALASM... You might still find some documentation
Good to know. I guess, now I can go on without it. The latching is done outside of the PAL. And the PAL itself is using only + and *.

Cu, Martin

TFM

Quote from: nocash on 12:22, 07 May 10
One unexpected thing is that it is not dk'tronics compatible, not even trying to do so. The 512K are accessed by writing C0h..DFh (on dk'tronics it'd be C0h..FFh). Some of the values do overlap, so there's some (unintended) compatibility.

I disagree. The dk'tronics provides 576 KB (including the first 64 KB of the CPC itself), while the c't provides 512 KB in total, therefore some of the values &C0..&FF can't be used for the c't. But the others are compatible. At least from the software side.

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

nocash

#22
The circuit doesn't connect to D5, no way it could handle values E0h..FFh.
That values will be simply mirrors of C0h..DFh.

I've "disassembled" the source code (added some comments which parts belong to which bank bits)...

Bank bits2-4 seem to be set only on /CPU access (not CRTC access) (so, the extra RAM cannot be used as VRAM).

However, there seems to be a small glitch that does affect VRAM mapping: The selection for CPU address 4000h..7FFFh does also reach the CRTC (though with bit2-4 stripped). So the CRTC may see bank 0-3 at 4000h..7FFFh, which should be wrong (as far as I know, on a normal CPC6128 it should always see bank 1, no matter of RAM banking).

And, one big issue that blows even "semi-compatibility" with dk'tronics: values C8h..DFh do map bank 8-1Fh to 4000h..7FFFh, but they do also map bank 7 to C000h..FFFFh. The mapping to 4000h..7FFFh does resemble (some of) the dk'tronics settings, but as far as I know, dk'tronics should put bank 3 to C000h..FFFFh, not bank 7.

I hope I didn't make mistakes there, please correct me if I am wrong!

EDIT: PS. The "disassembly" is on http://cpcwiki.eu/index.php/C't_512_KB_internal_RAM_expansion

nocash

#23
Updated the cpcwiki article. It should be now all correct, with the old info & questions removed.

Only one problem: The above VRAM glitch doesn't match to well - There's a small sample program (see last 2 pages of the first scanned article). As how I understand it, it does the following (a bit simplified):
  map VRAM to 4000h..7FFFh (intended to display RAM bank 1)
  map expansion bank 8 to 4000h..7FFFh (intended to LDIR it to a buffer at 8xxxh, and from there to C000h..FFFFh)
this method should work okay on a dk'tronics expansion. But, if the c't expansion does really have the VRAM glitch, then bank 0 would be displayed during the LDIR (bank 8 ANDed with 03h). And thus one would see nasty garbage on screen.

Now it's a bit unlikely that the c't sample program is incompatible with the c't hardware :-[ does somebody see a mistake in my description? Please also check the source/schematic in the original german article (no promises that I've typed-up or commented the PAL source code correctly).

Cu, Martin

EDIT: Ignore above. Just had a look at the CPC6128 schematic. The VRAM base (A14,A15) goes directly to IC109, without being passed through the PAL at all. So, there is no VRAM glitch.

Powered by SMFPacks Menu Editor Mod