@EgoTrip I have a question.
I can get the Prelude to Chaos and Chaos Rising part 2 dsk images to run on a real CPC through the M4 board, but Chaos Rising won't run. Why?
I can run it fine on an emulator (Caprice32), but on a real CPC it refuses to run correctly.
On my CPC, the screen is jumbled and all sprites are overlaid on top of each other in the top left corner.
The game is "running". I hear music and sounds and controller and key presses are doing stuff, but the graphics are all messed up.
What is it that is different about Chaos Rising v1.1 that is changed in Prelude and part 2? Those both run fine, but not CR 1.1
(these are dsk image files downloaded from cpc-power site)
My CPC is a 6128. It has a CRTC type 00
I have absolutely no idea, sorry :(
The engine on 1.1 and Part 2 are mostly the same, so I don't get why it does that. Prelude is a completely different engine that I wasn't happy with.
I know it works on a 464 as Novabug has had it working on his. But I don't have real hardware to test on and to be perfectly honest its way above my abilities. I have encountered some bugs in the final game in the series and am close to abandoning it as I can't fix them.
Hm, found this online. The filename states that it is an M4 version of the same game. Unfortunately, I don't have the means to check it myself on the M4, ATM.
Would you like to give it a try?
Quote from: MaV on 14:18, 07 May 22Hm, found this online. The filename states that it is an M4 version of the same game.
Thank you
@MaV Where did you find this? It works.
There is an additional file added to the .dsk image -- "CR-M4.BAS"
The game works when it is launched from that file.
I don't know the contents of that new file. It just gives a "memory full" error when I try to load it.
Good to know. :)
The supposed BASIC file seems to be a binary after all, so it's machine code that's started not BASIC.
Who made the M4 patch? Can anyone shed some light on to what went wrong please?
I've no idea who did this. The CR-M4.BAS checks for the drive letter, resets the ROMs, loads the screen, then loads part of the code into screen memory, then copies the code to &A000 and starts the game. It's how a typical cassette game in the 80s was cracked and copied to disk because cassette games usually used RAM reserved for disk routines (because they could).
So, this problem has to do with himem on his CPC. Everytime a ROM is initialised a little bit of memory is reserved for the ROM, sometimes more than a little, like with the M4 board. If someone wants to support the M4 board they need to make sure that the game does not write over these memory parts. Games written before the M4 board was released would, by default, not support the M4. If it still works it's good, but don't count on it.
This might be a relatively easy patch, but then no one should expect that a game that has been developed in someone's spare time is running with a piece of hardware that isn't quite standard. It's a bonus and very welcome if the M4 is supported, for sure. (Just my 2 cents, but it had to be said, and I love the M4 board).
Also, if someone has a whole bunch of ROMs initialised, they should be aware that most of the software will have problems because games ESPECIALLY expect a lot of free memory.
@blackdalek : Can you tell us what himem says after a reset? -> print hex$(himem)
Quote from: MaV on 10:32, 08 May 22@blackdalek : Can you tell us what himem says after a reset? -> print hex$(himem)
Sure,
It says A5F7 on mine.
Thanks for the info. Just as I expected.
The game loads close to &A700, so it writes over part of the memory of the M4 card.
So, the game as such is not really to blame. It's never really intended to be more than a tape game, AFAIK. Nevertheless a small patch made it work. :)