ACID chip inside

[nocash]

Hi, updated the ACID page (with the description I had already posted here). And moved the patent info to
http://cpcwiki.eu/index.php/Programming:Unlocking_ASIC that's the stuff you sent to the CRTC index register (it has nothing to do with the ACID, the only relation is that somebody at Amstrad liked to use shift registers).

Oh, and I have no plans to implement an ACID-clone in hardware, I've never used PALs, so I'll leave that part to somebody else.

Doing it with 74xx logic chips would work, too. And, as a prototype, it'd be nice, as one could "see" how it works (unlike a PAL where you don't see what is inside it). Anyways, that'd require a fairly huge circuit with about 10 chips. If anybody wants to make more than one cartridge, a single chip PAL solution would be better.

Using  PICs... aren't that software controlled microprocessors? Not too sure if that could work. The stuff must be processed at 4MHz, to implement that in software, the CPU would need to run at 100MHz or so. Dunno if modern PICs are that fast.

---

So, and cheating around fully implementing the ACID...

I guess one cannot get around implementing the shift-register - but, one could omit the compare/adjust part. The comparision matches are occuring only once every some ten-thousand CLK cycles.

If the CPU and ACID are reset at the same time (no idea if it's like so) then the software could take care not to access EPROM addresses at times that are known to cause matches. The timings would be difficult to implement.

An easier way to cheat would be this: After CCLR, matches occur only on about 131 addresses (eg. addr=00h), so the remaining 125 addresses (eg. addr=01h) can be safely accessed. Hardware would need to implement only the shift register. And software would need to relocate code & data from the "safe" EPROM addresses to RAM. Downside would be that one could use only half of the EPROMs capacity.

Anyways, fully implemented hardware would be more software-friendly.

---

Hmm, no, didn't document anything with photos. It's only an IC with some wires anyways. Though, the wires do actually look a bit funny, maybe it's worth taking a photo... I was visiting my parents when making the circuit, couldn't find a normal 36pin centronics socket, and all I could get my fingers on was an old RS232 cable with 25pin dsub plug, so I had to use that one.

[OCT]

I have no plans to implement an ACID-clone in hardware, I've never used PALs, so I'll leave that part to somebody else.
[...]
Using  PICs... aren't that software controlled microprocessors? Not too sure if that could work. The stuff must be processed at 4MHz, to implement that in software, the CPU would need to run at 100MHz or so. Dunno if modern PICs are that fast.

As Xilinx has been mentioned above, the route to go is probably programmable logic like CPLDs or Flash-FPGAs (the approach self-taught "über-geek girl" Jeri Ellsworth used years ago already to emulate the entire C64 in a joystick that retailed for 29 dollars IIRC, a project also at the core of the C-One) which can be turned into anything from simple gate arrays to microprocessors with network interfaces (since even low-end models are much more powerful than what we need, we could give the "bored" chip real estate other things to do, e.g. so one of several EPROMs could be toggled for the next reboot as inspired by Amstrad's Cartridge Software Demonstrator, or the EEPROM image could even be remote-flashed via bluetooth much like a .DSK file is loaded onto an HxC floppy emulator), with much of it from libraries of code available online.
Since this particular development kit was asked for to describe your discovery, there are folks around here who seem to have much experience with it and find that more intelligible even than x86 assembly.

[spybro]

great news!
really glad to hear that now we can unleash the power of our cpc+
just wanted to thank all the guys involved in this project
keep up the great work

[Nilquader]

À microcontroller is probably too Slow to simulate the ACID, but these few Shift and XOR operations should easily fit into a xilinx 9572xl cpld (or similar). Anyone here able to weite some Lines of vhdl Code?

[arnoldemu]

How about "Base" or "Alkaline" ie: Neutralises Acid.

Bryce.

Simple lets call it "no$acid".

[arnoldemu]

So, and cheating around fully implementing the ACID...

I don't really want to code around having an incomplete ACID implementation so my vote goes for the full version and because you found this info, we don't need a stripped down version?

Ok, my thoughts on enhancement for cartridges now comes to a few ideas:
1. flash ram for part or alll of the rom to make it easy to reprogram. But more specifically for making game saves. If the cart works similar to the existing cpc roms, then reading a memory address could activate part of the flash ram for writing and then writing to the rom area then writes to the ram. Reading is easy of course.
Real saving on cpc+ cart? Yes please.

2. implement a bank switching method so we can go furthur than 512K, maybe by reading specific memory address ranges to switch the banks in and out? e.g. read c000 of bank 31, read c001 of bank 32 to switch in blocks of 512k ram? or if the data is sent with a write, we can perform a write at a specific memory address. it gets my vote for sure.

All depends on if the data lines are active on a write access or not.

[arnoldemu]

Hi, updated the ACID page (with the description I had already posted here). And moved the patent info to
http://cpcwiki.eu/index.php/Programming:Unlocking_ASIC that's the stuff you sent to the CRTC index register (it has nothing to do with the ACID, the only relation is that somebody at Amstrad liked to use shift registers).

Great info. I think it is also important to add the information found on the Spanish forum, because this goes into more details of why the ACID is needed (ram access etc by ASIC).
The current info mentions how it works and a short sentence on why it is needed, but the chronograms etc from the Spanish forum are also important to see.

[Octoate]

À microcontroller is probably too Slow to simulate the ACID, but these few Shift and XOR operations should easily fit into a xilinx 9572xl cpld (or similar).

Hmm, maybe the smaller version - the 9536 - is enough, too. At least it has enough pins, but I am not sure if has enough PLD cells. At Reichelt you pay 1.85 EUR (VQFP package) for such a chip, which is quite cheap (and smaller, of course ).

Anyone here able to weite some Lines of vhdl Code?

Well, I only know the basics and so it is better if somebody who does that all day can convert it to VHDL. It's not that hard, but different from software development (e.g. timings of pin and register assignments). Anyone here ?

[Devilmarkus]

Just a good idea to sell new t-shirts...

[redbox]

Using  PICs... aren't that software controlled microprocessors? Not too sure if that could work. The stuff must be processed at 4MHz, to implement that in software, the CPU would need to run at 100MHz or so. Dunno if modern PICs are that fast.

The 18-pin PICs seem to be 32Mhz at best (but they are only is $0.97).

There is also the Ametel AVR type chips which I know about because the homebrew Uzebox console is designed using one.

[MacDeath]

Just a good idea to sell new t-shirts...

Well, the face of Sir Sugar on an ACID cardboard perhaps
With a smoking pipe aside and a text like "Cracked !"...


I see one of you telling there is no way to make money on Amstrad CPC scene...
Well of course, but the numerous Consoles collectionner possessing a GX4000 just because they are collectionner.

Those guys do play their console sometimes, and would perhaps buy newly made cartridges.

As a result, the "fully multi eprom" solution should be reserved to us, the scener, and finding a cheap mundane "hardwared games" cartridges solutions for all those suckers who made the GX4000/Plus range hard as hell for us to find at a decent price nowadays.
(but of course, no millionnaire will emerge from this...)

Yet when you just see what Fano managed to achieve with only PLUS extra feature and the additionnal +64Ko Ram from a 6128+... using an old time well know game engine unfit for the Plus range to begin with.

Well, having the 256Ko or 512ko ROM unleashed may really give impressive results, even with no additional RAM..

I believe to that RPG games using a 6128+ and Big 512ko Cartridge and Disk drive would be awesomly sweet.


Also Demos...Music...Applications...

Of course those could be achieved with a Rom Box, but the cartridge port is a way to get easy, miniaturised and perhaps cheap Rom boxes with no extra features that nobody cares about.


The only thing : we must establish standards specifications.
Soo this may be used by everyone.


ACID : Amstrad Created Infamous Device.

[Devilmarkus]

Like this?

[dragon]

Yes,good idea is to build and redesign the cartridge.Adding new functions such as record items.Or others.

But that is a standard for all.

Another advantage is now that the cpcfirmware is upgradeable.

Though I suppose nobody would dare to change the roms, to put rumble feature in games.

[Devilmarkus]

Because we use CPC:

[Trebmint]

I know nowt about chips n stuff, and was wondering how somebody like a me a simple coder might write for cart.

Would it not be an idea to keep this almost like a publisher based thing, so anybody that wishes to publish a game has the cart produced and sold through a single place.

[Bryce]

Although I haven't seen the realtime timing of the signals yet, I can't imagine that it's not possible to implement this on a low-cost PIC running at possibly even 20Mhz. The PIC doesn't actually have to be shifting and XORing at all or doing any fancy maths, it can simply sample the input and then use a lookup table to set the outputs, this should be easily possible to do in the time required. I'll wait for all the data, before I commit to this, but if I manage to buy a CPC+ and cartridge in the mean time, I'll certainly try it.

Bryce.

[Nilquader]

Although I haven't seen the realtime timing of the signals yet, I can't imagine that it's not possible to implement this on a low-cost PIC running at possibly even 20Mhz.

If you look at the signal timings, you'll see that the SIN signal is updated shortly after the falling edge of CLOCK, so it's probably sampled by the ASIC at rising edge. So at 4 Mhz you only have 125ns (half clock cycle) to calculate this signal. The PIC16F84A needs 200ns to execute only one instruction (at 20Mhz) and you really need more than one instruction for a dozen of XOR and Shift operations. So a PIC is too slow, even at 40 or 50 Mhz

A cheap CPLD is possibly the best solution - at least it's fast enough (the small Xilinx CPLDs usually have a 15ns pin-to-pin delay).

[Nilquader]

Hmm, maybe the smaller version - the 9536 - is enough, too. At least it has enough pins, but I am not sure if has enough PLD cells. At Reichelt you pay 1.85 EUR (VQFP package) for such a chip, which is quite cheap (and smaller, of course ).

Yes, the smaller CPLD is sufficient. Just using 21 of 36 avaliable PLD cells right now....

We just need a 5V version of the XC9536, Reichelt only offers the 3.3V models.

[Octoate]

Yes, the smaller CPLD is sufficient. Just using 21 of 36 avaliable PLD cells right now....

Are you already working on a VHDL implementation? If so, I will stop working on that. I just wrote the "entity" after I tried to remember what I learned years ago .

We just need a 5V version of the XC9536, Reichelt only offers the 3.3V models.

They also offer the 5V version in PLCC package ("XC 9536-15 PC44"). The 3.3V model accepts 5V on the I/O pins, so you just need a power level converter for the SIN signal. The other problem is, that the maximum voltage for the power supply of this CPLD is 4 V, but that can be provided easily, too.

P.S.: Just found a 9536 in 5 V in my component box, now I just need to find my JTAG cable...

[Nilquader]

Are you already working on a VHDL implementation?

No - Verilog   The simulation already looks promising, i just need to do some more tests on the comparison values and the timing.

If so, I will stop working on that. I just wrote the "entity" after I tried to remember what I learned years ago .

You don't have to. It's a great project for learning VHDL   But i could also send you my half-finished code if you like.

They also offer the 5V version in PLCC package ("XC 9536-15 PC44"). The 3.3V model accepts 5V on the I/O pins, so you just need a power level converter for the SIN signal. The other problem is, that the maximum voltage for the power supply of this CPLD is 4 V, but that can be provided easily, too.

Before adding a voltage regulator and a level shifter for the SIN signal, better take the 5V version. Almost the same price, but less parts and less space on the cartridge board.

[MacDeath]

Because we use CPC

Then you failed Epicly... As if you passed the ACID test, you would use PLUS instead of CPC...

Your Palette don't match your pretentions.
(kidding and trolling, as ever)

[Bryce]

Yup, had a look at the timing last night, a (low-cost) PIC just wouldn't work  Pity.

Using a 3.3V part isn't a major issue if the part can handle 5V i/o. Adding an LM317 and a capacitor (which you'd probably add anyway) doesn't take up very much PCB real-estate and is a minor cost relative to the rest of the board. Of course if the i/o is 3.3v then it's a completely different matter.

Bryce.

[nocash]

Altogether I'd say that logic is better than pic, too. Anyways, with a pic, you'd of course have a full 4MHz cycle time to (pre-)calculate the next bit, not a half 4MHz cycle. Using table wouldn't be a bad idea. Sorts of like so:

read data_table(index), and increment index
mask index to 17bit range
wait for clk (via polling or interrupt)
output bit
read 9bit (oe and address lines)
compare index with old_index_table(9bit value)
if match then set index = new_index_table(9bit value)

The data_table would be fairly huge, especially if it'd need to be stored in 128Kbytes instead 128Kbits (for timing reasons), and with a 20MHz PIC, you'd have only 5 cycles to implement above stuff, which is probably impossible :-) If the processor has a parity function, you could get around the huge data_table, and would need only the 9bit tables:

parity = shiftreg and mask
do shift, and add parity
wait for clk (via polling or interrupt)
output bit
read 9bit (oe and address lines)
compare shiftreg with old_shiftreg_table(9bit value)
if match then set shiftreg = new_shiftreg_table(9bit value)

Anyways, that'd reduce only the memory needed for tables, not the 5 cycle problem.

---

With logic chips: I guess you noticed that the xor_value and cmp_values are both more a less the same. So you'd need to compute only the cmp_value, and could re-use its bits as xor_value.

And of course you won't need to deal with the calculations in the pseudo code, ie. you can simply assign them like so:
  cmp_value_bitX = pinZ
  cmp_value_bitY = NOT(pinZ)

---

For the timings. The only thing I know 100% for sure is that SIN is updated at falling edge of CLK. I've verified that myself, and it's also shown on the spanish pictures.

The other important timings would be CCLR and /CE. The pics at
  http://amstradcpc.mforos.com/305097/7723493-que-hace-exactamente-el-chip-acid-de-los-cartuchos/?pag=5
are showing only totally irrelevant signals like RAS and CAS :-) but unfortunately not CCLR and /CE.

I don't have a cpc+, so I can't check when the cpc+ does update CCLR and /CE. Could somebody else check that? Please! Like one picture showing CLK and CCLR (that, without a cartridge inserted, of course), and one picture showing CLK and /CE.

At the ACID side, I haven't checked /OE timings yet. But tested CCLR today. If I didn't do something wrong:
It seems that reset occurs only if CCLR=LOW at Falling-Edge of CLK.
That'd imply that CCLR is updated a Rising-Edge of CLK. Anyways, if somebody could confirm that would be great.

The info at
  http://groups.google.com/group/comp.sys.amstrad.8bit/browse_thread/thread/00621273fbd0f8f4
only says that CCLR is low for a "whole" CLK period, but not if that period starts on rising or falling edge :-/

[Octoate]

Are you already working on a VHDL implementation?

No - Verilog . The simulation already looks promising, i just need to do some more tests on the comparison values and the timing.

Hey, we are in europe - that means you have to use VHDL, that's more commonly used here .

If so, I will stop working on that. I just wrote the "entity" after I tried to remember what I learned years ago .

You don't have to. It's a great project for learning VHDL   But i could also send you my half-finished code if you like.

You are right and that's a good idea, because I will receive my personal FPGA development board in two months (old product from the company where I am working). I will work on my VHDL implementation when I have some time - maybe we will find different ways and can see what timings we need for the implementation. What program do you use for timing simulation? MultiSIM?
Btw, when do you set the SIN pin? After the falling edge of the clock signal? (ok, nocash just wrote it before my posting )

They also offer the 5V version in PLCC package ("XC 9536-15 PC44"). The 3.3V model accepts 5V on the I/O pins, so you just need a power level converter for the SIN signal. The other problem is, that the maximum voltage for the power supply of this CPLD is 4 V, but that can be provided easily, too.

Before adding a voltage regulator and a level shifter for the SIN signal, better take the 5V version. Almost the same price, but less parts and less space on the cartridge board.

As long as we are able to get 5V types, we should use them, because that will save components on the circuit board and more space equals higher price - on the other hand: I don't like PLCC packages (anymore), because you always have to use a socket on the board.

@Bryce: There are a lot of 5V variants of the XC 9536. You can get them e.g. from Segor or Digikey, so that shouldn't be a problem.

[Bryce]

The PIC frequencies are a little misleading, because commands aren't processed on each clock cycle, but on every fourth clock cycle, so a PIC running at 20Mhz is actually only able to keep up with 5Mhz systems. A downside for PICs, but because I used to get them for free, I still tend to use them quite often.

Obviously a 5V part would be preferable, I just thought (from Nilquaders post) that 5V parts were difficult to source or more expensive. Although I use Reichelt myself quite often, their products are reasonably priced, but their selection is still quite limited (it's slowly getting better though).

Bryce.