Cartridge GX4000/PLUS games study.

[MacDeath]

Ok, many actual topics slided into this...
So I think this proper topic would fit better.

As you know, the knowledge to get decent cartridge solution is now available.
ACID chip was properly cracked, and even clever solution such as man in the middle (I would prefer a girl) exist.
To cannibalise some existing cartridge's ACID is also possible (please use common carts such as GX4000 burnin'Rubber to do this...).
Also there is an actual stock of ACID chips to be sold on the internet (will someone remind us where its available and the price?)


Here will be all discussions on the GX4000/Plus cartrides games and softwares (so mostly games...) from a technical point of view.

Share all your experience on the matter.

How is the Memory (RAM and ROM) used, How are the HardSprites used, the various PLUS features or just having the software in ROM.

Perhaps some posts from other topics would need to be imported here too.




Topics with such matters :

Video modes RGB :
http://www.cpcwiki.eu/forum/index.php?topic=2134.0

While this topic wasn't really on the matter, it slided into it because of some questions about the incidence of PLUS features on Video modes (sort of)


Burnin' Rubber's PLUS features used :
http://www.cpcwiki.eu/forum/index.php?topic=2206.0

This one is legit, but why only stay with Burnin' Rubber ? all Cartridge games should be properly studied as many of them as actually Real Amstrad PLUS softwares.

ROM specificities :

Even during the CPC era, "pseudo Cartridges" existed, they were just never really used for games and were not proper cartridge but just a ROM to put on a ROM board or expansion port...
Mostly Applications (machine languages), those are called ROM softwares...


Why Amstrad didn't produced such Apps on PLUS Cartridge is quite a mistery.

We would have love to get Adv.OCP are studio sold as PLUS cartridge with an Analog port mouse...

Anyway the way programs can be turned into a ROM running program is interesting.

The direct disk to cartridge ports are somewhat to be studied in this optic, as we can easily compare the disk version and the ROM version, also perhaps see how some few PLUS features were added or even why some weren't added....

As all GX4000 cartridges are 128K ROM, it would be interesting to see whether this is fully used or not.



Cartridge games may betterly enable to keep the 16K "320x200" screen dimension.
Perhaps even bigger fullscreen too.

As the main code is in ROM, which is some DATA only oriented additionnal RAM, many stuff don't have to use RAM compaired to Disk or Tape game. So you don't have to reduce the screen to get some gain from the 64K RAM as done by so many Tape/Disk Games (designed to run on 464/664 computers).

While existing Cartridge games were limited to 128K, a modern production can count on 512K ROMs.
If few use of actual RAM is needed (= no compressed datas or software transformations) then almost the whole 64K RAM can be considered VideoRAM (sort of).
This could be quite suitable for Arcade/Action games... less with Complex RolePlaying Games or strategy games (which may even need 128K RAM config and keyboard+DiskDrive support = 6128PLUS config)

Example :
=Panza Kick Boxing :
CPC and Best of the Best version has a largely reduced screen, while GX4000 cart use the normal 320x200 screen.


=The only games with reduced screen are most of the Directly/Moded "Disk to cartridge ports".

Because of obvious reason : the codes weren't designed for a Cartridge format to begin with...

===Klax, Barbarian2, Batman, WildStreet, Crazy Car2, Fire and Forget 2, Operation Thunderbolt.
All kept their reduced screen from the CPC version.


HARDWARE Sprites may be faster to use with ROM based program

I don't know the technical facts behind this claim, but this is what Fano and BDC Iron/Ghost told me.





Ok, this is just a start. Now you go !

[redbox]

Why Amstrad didn't produced such Apps on PLUS Cartridge is quite a mistery.

I have tried to do this and found it very difficult.

I wanted to have a cartridge which contained the system ROMs (OS, Basic and Disc OS) and then used the upper 4 slots (4 to 7) on a 128kb cartridge for traditional ROMs (e.g. Maxam, Protext etc).

We all know that in theory the CPC can have 256 expansion ROMs. The problem comes in that all of the Plus OS routines (e.g. KL_ROM_WALK and so on) are the same as for the classic CPC and coded to only search for and initialise the first 0-15.  Cartridge ROMs are allocated the spaces 128 upwards and it appears that the Plus hardware (probably the ASIC) knows this and patches them into the 0-7 spaces on boot-up accordingly.

I have attempted to patch the OS routines so that they search for 0 to 256, but this doesn't work properly, maybe because 128 to 131 are system ROMs and can't be initialised again. I nearly got the Maxam ROM to initialise and could see the init string on boot-up but then the Plus crashes.

I know that there are examples of other devices such as the SYMBiFACE II having 32 ROM slots that are used.  I did ask TFM how he did this with his ROManager but unfortunately he didn't find the time to tell me.  I expect it is just a simple patch of the OS to search for 0-31 instead of 0-15 and this is what lead me to believe that the Plus System ROMs at 128-131 are what is getting in the way.

The only solution I can think of is to write a routine that scans 0-15 and then scans 132-135.  However, this would take precious bytes and I couldn't find any space in the Plus OS ROM to patch in such a routine.

[MacDeath]

I wasn't talking about getting Application alongside the Basic on a same cartridge...
More like the cartridge IS the Application only...

Yep, this means you have to switch down the CPC and change the cartridge, but hey, better than nothing.

And, well, 128K only Application may not be enough.

What are the actual experience with 256K and 512K cartridges ? Have it been tried ?


Proper SymbOS+ and FuturOS+ cartridges, designed to run on stock 6128PLUS would be great...
But also a Really PLUS text based OS... be it a Basic, a CP/M or whatever...

Also a Starkos PLUS (DMA support), OCP art studio... Sprite editor...

I wanted to have a cartridge which contained the system ROMs (OS, Basic and Disc OS) and then used the upper 4 slots (4 to 7) on a 128kb cartridge for traditional ROMs (e.g. Maxam, Protext etc).

The problem in this case is simply that Amstrad didn't even bothered to get a real OS designed especially for the PLUS...
They simply reused the old Locomotive Basic and Amsdos (perhaps even with no actual patches...) which doesn't help.

The proper way may simply be to get rid of those a get a real PLUS new OS... but hey, lots of job I guess... for too few users (as is commonly said)

[redbox]

More like the cartridge IS the Application only...
And, well, 128K only Application may not be enough.

Ah I see... I would think that 128kb would be enough (a 3" disc is only 178kb) but only if the application doesn't require the OS (i.e. doesn't use any firmware routines etc), otherwise I expect it would be 256kb.

Only one I think remember seeing is a photograph at a meeting of maybe a music tracker program on a custom Plus cartridge... maybe it was on Kangeroo's Plus?

Proper SymbOS+ and FuturOS+ cartridges, designed to run on stock 6128PLUS would be great...

I think to do this you would unfourtunately need to overcome the problem I had above.

The problem in this case is simply that Amstrad didn't even bothered to get a real OS designed especially for the PLUS...They simply reused the old Locomotive Basic and Amsdos (perhaps even with no actual patches...) which doesn't help.
The proper way may simply be to get rid of those a get a real PLUS new OS... but hey, lots of job I guess... for too few users (as is commonly said)

I agree, but they did this so that the Plus would be backwards compatible.  It's quite a neat idea to have the cartridges at ROM slots 128 upwards because it didn't require a redesign of the classic CPC hardware.  On the other hand, they then need to hard code the ASIC to account for moving the cartridge OS ROMs back to slots 0-3 which means we can't easily alter it.

I would love to re-write the Plus OS ROM so that it works with cartridge ROMs and I do think it's possible, but it would require a lot of work and checking to ensure it remains backwards compatible.  Also, there really is no room left in the 16kb and every byte has pretty much been used.

[TFM]

Proper SymbOS+ and FuturOS+ cartridges, designed to run on stock 6128PLUS would be great...

Again you are ahead of time    As soon as I will be able to produce Carts there will be a FutureOS Cart (using the Plus version) with some additional stuff. You actually can put a lot of software into 512 KB of ROM. I'm thinking of either doing some patches to access software or to integrate a kind of ROM disc system. Let's see... it will not happen this year

[arnoldemu]

ROM specificities :

Why Amstrad didn't produced such Apps on PLUS Cartridge is quite a mistery.

We need to remember that the OS/firmware/BASIC/AMSDOS exist on cartridge only in Plus (not on main PCB).

If you want an APP to load/save data you need to including these on the cartridge or write your own functions to save in a compatible way - not an easy task to write code to read/write files to amsdos based disc formats - it's possible, but a lot of work.

If you did use basic/firmware/amsdos you would probably need to licence it at extra cost (think in the 1990 timeframe).

And the cartridge doesn't have any official or easy way to read/write data, so if you tried to implement some EEPROM or battery protected ram then the hardware doesn't support it easily.

So that is a few things to consider here....

[MacDeath]

So you need to re-write the core of the Firmware, but keep a good pack of "drivers/routines" anyway...

I knew a Game cartridge, like a good RPG... would need to support things such as Disk Drive (6128PLUS...to save or even load/keep track of extra Datas such a new custom campaign...), even mundane voice synthetisers, Audio extensions, ROM boards/Symbiface/etc... or even mouses : AMX, exotic version (Symb...) or even newly created Standard using the Analog port... my dream... may be a simple PC mouse (old serial one) with the 9/15pin serial adapter then managed by software...Is this even possible ?

But hey, a good usable "Drivers pack" would need what ? 64 k ? perhaps 80K max ? (if you want to add some stuffs...)

Ok, let say 128 from 512K... more than enough isn't it ?

If you simply want to run CPC programs, you just need to use the normal Locomotive Basic cartridge (the one with burnin'Rubber is just fine too).
Or a real CPC, as I know most of us here have one a least... (be it CPC464...)

Example :
why the locomotive basic doesnt have some additionnaltext modes ? I mean a reduced letters mode in mode1 and0 ? and even in mode 2...
Those were used in games (mode0 letters in 4 pixels wides...)
Or even different characters "fonts" ? (multi coloured ones ?)
the 320x200 display could greatly be enhanced into a more proper "text mode" to be fair.

Normal locomotive BASIC only enlarge the letters...

Anyway.

I don't see why Symb... erhg... FuturOS! (hallo mein frund)  couldn't be in PLUS-cartridge-friendly version yet...

I mean.
I have some spare BurninRubber carts to cannibalize but I am only waiting the good occasion to do it... which is... the "futurymbOS PLUS cartridge-port-friendly ROM".

And the elegant "Man in the Middle" solution doesn't even need a plastique casing to work well...


Don't even know how the hell no production yet made... just need a good supplier(sub contractor) and a proper Chip socket (Flash version would be fine).


Anyway, concerning the "firmwre and basic OS"...
A complete Assembly made application would need the whole system... just like a game.
8bit old machine, why bother doing real multitask...

And yep, a fit for all "drivers pack" to manage a good 6128PLUS or even 464PLUS keyboard, common extensions, mouses and disk/Tape drives... is quite needed.

Just to enable "Saves" for games...


Concerning mouses...
Well... While it was kind of messy on CPC... PLUS had the advantage of a good "Analog" port...

Analog can easily be turned into Digital... is it not ?
This should be the norm to use this port for mouse on PLUS' as it has a +5V too... and a proper mouse is somewhat analog... to begin with.

the amstrad PLUS are machines of the 90's... (very early, I must aggree).

So why no mouse ? simply because Amstrad didn't even had time to do it... (like many other things as it was a late era machine)

We should do it to.

And the cartridge doesn't have any official or easy way to read/write data, so if you tried to implement some EEPROM or battery protected ram then the hardware doesn't support it easily.

Well, just to read those is good enough provided the design of the program is made for, which is the basis of this topic. If you need RAM, you have the machine's one (64K/128K)... if you want to save it, then just use the DiskDrive... As 6128PLUS is THE config to deal with.
464PLUS may use MP3 audio devices...
Both having a proper extension port to deal with Demanding customers/users/coders.

GX4000 well... it's a console... not a computer, you don't bother with such concepts and just run (arcade) games on those... not OS. (we all know it is unfit to computer extensions, as it has no such port...)



Back to topic.


Do some of you had some insight of the existing cartridges codes ?
What have you seen ?

Are the Hardwired sprites (when used) stored in left & right version or is this done in software/RAM ?

What is the method to check for those ROM/RAM relation ? How to use Emulators to analyse those ?



I would like some teachings on the matter...



(also, it's saturday night... I drank some champaign because a friend of mine is now a proud uncle...lol... cheers...)

[arnoldemu]

ACID chip was properly cracked, and even clever solution such as man in the middle (I would prefer a girl) exist.

BTW, it's not a sexual naming thing as you think it is

In security terms, a man in the middle attack is one where neither side know they have been attacked and information goes to a 3rd person before it reaches the destination.

[Bryce]

@MacDeath: Are you suggesting that I was having gay fantasies while deciding how to name the device!!?

Just for you, I might call my next device the "Girl on girl mud-wrestling wet T-shirt action interface". No matter what it actually does.

Bryce.

[arnoldemu]

@MacDeath: You should try the no$cart utility
Unlimited "Direct Disk to Cartridge" ports

[andycadley]

Just for you, I might call my next device the "Girl on girl mud-wrestling wet T-shirt action interface". No matter what it actually does.

I'll take two. 

[sigh]

In regards to scrolling, if a CPC needs 32k to perform this action, how much is needed on a GX/PLUS?

[andycadley]

In regards to scrolling, if a CPC needs 32k to perform this action, how much is needed on a GX/PLUS?

16K, since you have hardware pixel scrolling and the ability to mask off a column on the screen to give horizontal buffering space.

[TFM]

... the ability to mask off a column on the screen to give horizontal buffering space.

Is there an extra mask register on the Plus I missed. Or is it like using a CPC old generation?

[redbox]

Is there an extra mask register on the Plus I missed. Or is it like using a CPC old generation?

It's Plus only and at address &6804 when the ASIC is paged-in.  Load &80 into the address and the first vertical character line on the left is masked so you don't see it (but can still write to it like normal screen RAM).  Therefore you can write one byte at a time there and still use the Plus hardware pixel scrolling without the user seeing any background being drawn.


One thing I wondered about this is when using this whether coders put up with having a 39 char width screen or if they extended the screen to 41 characters, masked the first char line and then centered it to make it still look like a normal sized 40 char screen?  I think the CPC still has enough RAM left at the end of the video memory to accomodate one more character line - afaik there are two horizontal lines free so this should be enough for one vertical one...?

[arnoldemu]

Navy Seals uses this.
R0 = 63, R1 = 40, R2 = 46, R3 = 14, R4 = 38, R5 = 0, R6 = 29, R7 = 32

Robocop 2 uses this:
R0 = 63, R1 = 40, R2 = 45, R3 = 14, R4 = 38, R5 = 0., R6 = 29, R7 = 33

NOTE: The Plus display is shifted compared to the CPCs.
So, it may not be so obvious

[redbox]

Navy Seals uses this.
R0 = 63, R1 = 40, R2 = 46, R3 = 14, R4 = 38, R5 = 0, R6 = 29, R7 = 32
Robocop 2 uses this:
R0 = 63, R1 = 40, R2 = 45, R3 = 14, R4 = 38, R5 = 0., R6 = 29, R7 = 33

Would be nice if we could patch the CPR so the hidden column is shown to see how they do it.


Had a search for 08 64 but couldn't find anything that appears to LD into that register on either game...?

NOTE: The Plus display is shifted compared to the CPCs.

How is it different on the Plus?

[fano]

Would be nice if we could patch the CPR so the hidden column is shown to see how they do it.

You can use Winape graphic editor to see vram instead.

[MacDeath]

This.
The picture looks like a step aside on the right.

Is this normal ? or were just the screencap screwed ?

(I should re-play my original game one of these days)

[arnoldemu]

This.
The picture looks like a step aside on the right.

Is this normal ? or were just the screencap screwed ?

(I should re-play my original game one of these days)

is that from a real cpc+ and monitor?

There are 2 things that are going on.

1. The plus screen is shifted by 1 char to the right I think (but then it may be compensated for using the plus monitor).
2. they are using soft scroll so the first column is masked.

That could explain why it is shifted a little bit more.

[arnoldemu]

Had a search for 08 64 but couldn't find anything that appears to LD into that register on either game...?

navyseals:

offset 25e5/25e6 is a "or &80" followed by a write to 6804.
offset 2626, 2628 is a "ld a,&80" followed by a write to 6804.
So get the bin version, modify it and make a cpr out of it.

robocop 2:

offset a39 has a "ld a,&80" followed by a write to 6804.
offset acc is the same as a39.

can't find it for robocop2, so I'll need to add *more* debugging features to arnold to trap the write

[redbox]

navyseals:

Yes, I patched it and could see the masked column.


And you're right, they didn't bother to shift the screen or anything.


Didn't realise the screen was shifted by 1 char on the Plus - maybe this is why you don't notice the masking column so much?

[MacDeath]

This is a picture from CPCpower so i guess it come from emulation.