Eternal Light project

[mr_lou]

As a JavaME developer, I quickly learned a golden rule: Never ever trust emulators when developing. ALWAYS test on the real device(s).

The same is true for CPC development, when developing games and composing music.

Well, let's see if anyone else knows the answer to the question: Is there a version of the game Eternal Light out there, that works on a real CPC?

[AMSDOS]

I got some weird results with this on the Winape emulator, probably because I was loading code into the main area of memory and not the extra 64k, though it continued to persist with it even after I reset the emulator, though closing that and opening it again corrected the fault. As I seem to recall the Extra 64k has a way of keeping stuff there (even after a soft reset).


I made this one to work for BASIC 1.0, though I suspect the real machine will have trouble with it, let me know.

[mr_lou]

Tested on my CPC464 with 128k

I got as far as the start screen where the main character is surrounded by the 10 lanterns, and it says PRESS FIRE TO BEGIN.

Pressing whatever does nothing.

[AMSDOS]

Tested on my CPC464 with 128k

I got as far as the start screen where the main character is surrounded by the 10 lanterns, and it says PRESS FIRE TO BEGIN.

Pressing whatever does nothing.

Hmm, during that screen did you pick up any little pixelated bleeps, when the game was crashing for me it these glitches showed up. I was even ESCing to BASIC and listing the BASIC and they were coming up on that too before the system froze.


The original code in the game was using a Clear Input followed by WHILE INKEY$="X":WEND for the game to begin or when you need to press fire to continue with the messages. I've changed this to "WHILE INKEY$<>"":WEND" which I think is the 464 Equivalent of "Clear Input", cause the theory is the Loop will continue until there is nothing in the Keyboard Buffer, which is what Clear Input Does. For the Fire Sequencing I've changed it to INKEY(76)<>0. According to my 6128 Manual it's supposed to be Fire Button 2 and Fire Button 1 is 77, but I think this is a misprint cause Winape is using Fire Button 1 as 76.

[mr_lou]

Bringing back this old thread to ask: Did anyone ever fix this game so it runs on a real CPC? I would really like that.

[AMSDOS]

Bringing back this old thread to ask: Did anyone ever fix this game so it runs on a real CPC? I would really like that.

I remember having a good look at the game at the time, though I found a lot of memory seems to be occupied, I thought the game might of had a better chance of running on a real CPC if it was 64k, though large volumes of memory seems to be taken up by Sprites Alive (Sprites1.pck) - &5C00 -> &A8E6? The Sprites file is also huge, it appears it's overwriting Sprites Alive &266B -> &5F6A?, I maybe wrong about that. Next there's the "player" file which sits in the &C4 Memory area occupying &4000 -> &49FA & the "forge" file which sits in &C5 Memory area at &5000 -> &5B51. I'm not quite sure what those files do though.

Has the author thought about writing it in something else, perhaps the game might stand a better chance and more likely  be 64k if it's done in SDCC, CCZ80 or CPC BASIC 3 perhaps?

[mr_lou]

I remember having a good look at the game at the time, though I found a lot of memory seems to be occupied, I thought the game might of had a better chance of running on a real CPC if it was 64k, though large volumes of memory seems to be taken up by Sprites Alive (Sprites1.pck) - &5C00 -> &A8E6? The Sprites file is also huge, it appears it's overwriting Sprites Alive &266B -> &5F6A?, I maybe wrong about that. Next there's the "player" file which sits in the &C4 Memory area occupying &4000 -> &49FA & the "forge" file which sits in &C5 Memory area at &5000 -> &5B51. I'm not quite sure what those files do though.

Has the author thought about writing it in something else, perhaps the game might stand a better chance and more likely  be 64k if it's done in SDCC, CCZ80 or CPC BASIC 3 perhaps?

I think it's fine that it's for 128k CPC only. My only problem is that it won't run on a real CPC.
I can tell you that the "Forge" file is the title music, composed in STarKos. I know, because I'm the one who composed it.
So the "Player" file is most likely the STarKos playback code.
These two files can be moved anywhere we like, if it will help get the game running?

[AMSDOS]

I think it's fine that it's for 128k CPC only. My only problem is that it won't run on a real CPC.
I can tell you that the "Forge" file is the title music, composed in STarKos. I know, because I'm the one who composed it.
So the "Player" file is most likely the STarKos playback code.
These two files can be moved anywhere we like, if it will help get the game running?

Well I've come up with this nuts & bolts (464) edit, I've taken the tune stuff out (sorry), and edited the program (disc.bas which was originally eternal.bas), the game is still 128k because the file code.bin needs to reside in banked area &c4. I cannot test it on real machine, but it was working when I tested it on an expanded 464 in Winape, however was getting a different story when I tested it on an expanded 464 in Marco Vieth's CPCEMU v1.5 with the game getting to the opening screen and then crashing back to BASIC as soon as pressing the Fire Button (Numeric pad 5). However if I load DISC.BAS and  then write this patch:

Code Select Expand

openout"d":memory &2671:out &7f00,&c4:load"code.bin":call &4f80:out &7f00,&c0:load"sprite1.pck":call &a640:call &7000:mode 0:run 210

the game works in CPCEMU, so may be worth a try on a Real Expanded 464, if the crash in CPCEMU is the same as what's happening on the actual machine.

[mr_lou]

Nope. Not working.

"Memory full in 200" after the loading picture has been loaded.
Running on my CPC6128.

[AMSDOS]

Nope. Not working.

"Memory full in 200" after the loading picture has been loaded.
Running on my CPC6128.

It would have to be tested on a 464 if that's not a hassle, cause I haven't tested it on a 6128. On the first line I noticed a poke to turn on the Caps Lock which is a 464 Poke - don't know what it'll do on a 6128. Otherwise "LOAD" (not RUN) "DISC.BAS" and use that Code I posted above to load the other components followed by "RUN 210".

[mr_lou]

It would have to be tested on a 464 if that's not a hassle, cause I haven't tested it on a 6128. On the first line I noticed a poke to turn on the Caps Lock which is a 464 Poke - don't know what it'll do on a 6128. Otherwise "LOAD" (not RUN) "DISC.BAS" and use that Code I posted above to load the other components followed by "RUN 210".

My CPC464 isn't hooked up at the moment.
But I really think the game should work on a standard CPC6128.

The developer said from the start that it's a 128k game. So logically it wouldn't work on a standard CPC464, even if the music has been removed.

[AMSDOS]

My CPC464 isn't hooked up at the moment.
But I really think the game should work on a standard CPC6128.

The developer said from the start that it's a 128k game. So logically it wouldn't work on a standard CPC464, even if the music has been removed.

I modified that 6128 game to work on a 464 (BASIC 1.0), though I have given it 128k which, I assumed you had for your 464. If it hasn't got it, then I can see why it won't work.

Understand the game is 128k even without the music because code.bin is loaded into Memory Bank C4, if you follow my loading code you will see that. Originally I thought if I could remove some of the components such as the Music which appears to be interrupt driven, it might work on a Real CPC.

I'm unsure why the Real 6128 is returning a memory full in 200 error. The DISC.BAS file I made is only 8k, so MEMORY &2671 should be legitimate, I even did a OPENOUT"d" which should prevent it. OUT &7F00,&C4 will take me to the extended memory area where I should be able to LOAD CODE.BIN which starts at &4BFF, calling the execution address will unpack that file so it sits between &4000 & &5D4F, OUT &7F00,&C0 will take me back to the main Bank where I should be able to LOAD Sprite1.PCK which when unpacked sits at &5C00 & &A8E6, I can then execute Sprites alive at &7000 go into MODE 0 and run 210. If you get a Memory Full error by trying that I don't know what's happening, perhaps if there are other ROMs installed on your 6128 then it would be better to disable those, I'm not sure how friendly 128k programs are when ROMs are installed.

[mr_lou]

I modified that 6128 game to work on a 464 (BASIC 1.0), though I have given it 128k which, I assumed you had for your 464. If it hasn't got it, then I can see why it won't work.

I do have a 64kb expansion for it.
I'll try to remember to check out your mod next time I hook it up then.

I'm unsure why the Real 6128 is returning a memory full in 200 error. The DISC.BAS file I made is only 8k, so MEMORY &2671 should be legitimate, I even did a OPENOUT"d" which should prevent it. OUT &7F00,&C4 will take me to the extended memory area where I should be able to LOAD CODE.BIN which starts at &4BFF, calling the execution address will unpack that file so it sits between &4000 & &5D4F, OUT &7F00,&C0 will take me back to the main Bank where I should be able to LOAD Sprite1.PCK which when unpacked sits at &5C00 & &A8E6, I can then execute Sprites alive at &7000 go into MODE 0 and run 210. If you get a Memory Full error by trying that I don't know what's happening, perhaps if there are other ROMs installed on your 6128 then it would be better to disable those, I'm not sure how friendly 128k programs are when ROMs are installed.

Well, I did get a MegaFlash installed internally not long ago. So that might explain it.
Will try to remove a few ROMs and then try again.
But it'll be later, because we're in the middle of some home re-arrangements at the moment.

[AMSDOS]

I tried my Disk Image with the no$cpc and got the memory full in 200 error. Once I was able to eliminate that I've been getting errors associated with the Sprites Alive |SCENERY commands that begin in Line 750. So I haven't been able to get this game working in with that Emulator, though I'm unsure if has issues similar to what happens on a Real CPC.

[AMSDOS]

I've been doing some more tests with Sprites Alive on Winape & no$cpc and I've been getting different results with these emulators. Again I'm not sure if this relates to why this game won't work on a Real CPC, but it would be worthwhile testing it (using Sprites Alive) on the real thing to see what the outcome is.

I was simply loading the Sprites Alive in and executing it:

Code Select Expand


memory &2671:load"sprite1.pck"
call &a640:call &7000


which will setup the screen inks, load in the sprites using Sprites Alive

Code Select Expand

|draw,"sprites"

then setup a screen to draw the sprites to:

Code Select Expand


mode 0:locate 1,8


you can now use the Sprites Alive Scenery command to display those sprites.

Code Select Expand

|scenery,0,0,99

0-15 seem to relate to the main character in the game which goes through a whole animation process.

What's interesting though about this Scenery command is it's doing different things depending on the emulator, in Winape the Sprite Appears as normal, but with no$cpc there are two horizontal gaps breaking up the main character for example, this seems to be happening with all the sprites in no$cpc using that command, I'm not sure if it's a flaw in no$cpc, or it's just something else to do with the sprite file.
Also those errors which have been occurring in no$cpc seem to be a result of an out-of-range error in this case the sprite is simply being displayed off the screen resulting in an Error 11 which is the error I mentioned in my last post.
Upon testing in no$cpc I found numbers greater than 99 would be displayed off the top of the screen, the reason for that error, however in Winape it simply showed the sprite to be displayed half way down the screen, I could go as high as 199 on the y-axis which is considered legitimate in Winape, but not no$cpc.

So perhaps to work out what's legitimate and what's not, it would be best to test this on a real CPC by simply loading up Sprites Alive, Loading the Sprites (using Sprites Alive), and testing their scenery command, that command I have above posts Sprite 0 which is the start of the main character and working out where it goes on the screen on a Real CPC (it will be on the Left hand site regardless), but if it's only part of the way up the screen instead of up the top, then we should know (maybe) where the problem is I guess.

[AMSDOS]

I've attached the latest Disk Image which now works in the no$cpc emulator.

To make this game work in no$cpc I've thrown out the old Sprite Alive sprites1.pck which was compressed and I think it was this compressed program which was causing all the issues from Sprites broken up, to Sprites Alive Error Messages from legitimate commands.
I've gone back to the original Sprites Alive program and used "sprite.1" file there, so now everything looks fine with no$cpc. The game looks a bit different now though because I was playing around with the Windows and Stuff earlier and I've extended the Black Line across the screen to the Black Blobs or your Bullet Doesn't go into that area and the Tune is still out, unfortunately I don't have any way of testing it on no$cpc because my computer I'm using doesn't have a Sound card.

I suggest testing this on a Real CPC if anyone has any time and can do it. I'm not sure if the Compression of Sprites Alive is the problem, I mentioned this because I tried to get Scooby & Scrappy Doo working on my 6128 years ago from a hacked Disk Image and it just wouldn't work, so I'm not a big fan of Compressing Actual Programs. The compressed "code.bin" seems to work fine though.

[mr_lou]

Doesn't work on my CPC+
Freezes on the sprites alive text screen.

[AMSDOS]

Doesn't work on my CPC+
Freezes on the sprites alive text screen.

Unfortunately I can only test this with Winape with the settings on CPC6128 with Parados, on reset I'm getting V4 in the opening text, though I'm unsure if I'm using this beast correctly & my Disk Image also works under those settings.

A couple of things could be occurring:-

* Is the CPC+ crashing when Sprites Alive is being executed?

Code Select Expand


memory &3fff
load"sprite.1",&7000
call &7000


That will give the opening message.

* Is the CPC+ crashing because system becomes unstable when loading code into extra 64k?

This follows the loading of Sprites Alive. Is 'out &7f00,&c4' from BASIC not allowed, or it's allowed, but it needs some machine code in the extra 64k to get it back to area &c0 or order to resume, thus the problem of getting information from the extra 64k into a BASIC variable. It's being so long, I cannot remember if 'out &7f00,&c4' takes one away from command line and the program making it appear as if it's crashed. So you type something but you cannot see it onscreen, however if you type in 'out &7f00,&c0' you're back with the command prompt? I think I've only noticed that with 'out &7f00,&c1', but command inputs can still be entered. On the emulators typing 'out &7f00,&c4' just lets the emulator carry on typing in commands, but the area &4000-&7fff is now 16Kb into the extra 64k. The basic program is only 8kb and won't be occupying any area &4000 onwards. I'm just wondering if a Plus Machine handles extra 64k differently from an old CPC?

[AMSDOS]

I've managed to revise the program again and have uncompressed the CODE.BIN file and saved it as a straight DATA file. I disassembled the CODE.BIN in it's packed format and found it was Disabling Interrupts at the execution address &4F80.

I was looking up some Issues of AA and found that using the specified OUT &7F00,&C4 to access the extra 64k is legitimate from BASIC and that PEEK & POKE can be used as well, they (AA) don't mention LOAD"<filename>",&4000 though and the Manual doesn't say anything about only using it for the first 64k of main memory, if it turned out that LOAD only loads programs to Bank Area C0 - main memory, then it could easily be loaded first into high memory, move to area C4 & move the code there.

[mr_lou]

hehe, I see that you have one or two of the same illnesses as myself: Either the Don't-Know-How-To-Quit decease, or the Can't-Give-Up illness. The two are strongly related.

Thanks. The DSK is downloaded. Will test it when I find the time. :-)

[AMSDOS]

Hmmm.. good work to find this. Maybe "sprites alive" is using interrupts?
Maybe it is possible to move the initialisation of the music and then setup a new function to call the music.

Sprites Alive is using a bit of firmware called "KL NEW FRAME FLY" (&BCD7), to setup a New Frame Flyback Event Block, but I suspect it's the event routine which DE points to which is the problem because that routine disables some Interrupts, I'm unsure where that is now, but if you start disassembling Sprites Alive while it's at &7000, you don't have to go very far into that before you see &BCD7. If you:


poke &7011,0
poke &7012,0
poke &7013,0


to remove that call &BCD7, I got the program to work on my Real 6128. I've attached a patched version, though I've been playing around with this program so much, I don't know why I couldn't get to the last lantern, so perhaps someone can download an earlier disk image that doesn't have the memory issues and apply the patch - just don't call &7000 before doing the patch, though you'll need to call &a640 to uncompress Sprites Alive.

[mr_lou]

I got the program to work on my Real 6128.

Sadly I'm too hung up at the moment to test, but if you really got the game working on a real CPC, you deserve a reward.

[AMSDOS]

Sadly I'm too hung up at the moment to test, but if you really got the game working on a real CPC, you deserve a reward.

No Worries. I've gone back to the "eternal102.dsk" download, applied the patch, and got it up and running on my CPC6128. The game does become a little bit faster as a result of removing the event block, though it's still playable and perhaps better off without the event block.

[mr_lou]

Works fine on my CPC+ now yes!

Thanks a lot! 

Damn, those black bastards are tricky.
(I haven't played the game before now. Have been saving it to play on a real CPC)

[Morri]

WOW!!! Thanks AMSDOS for all your work in getting my game going on a real CPC. Who would have known how much grief I would give poor Mr Lou in trying to get this thing going. I hope it isn't a big let down after all this anticipation 

Sprites Alive is using a bit of firmware called "KL NEW FRAME FLY" (&BCD7), to setup a New Frame Flyback Event Block, but I suspect it's the event routine which DE points to which is the problem because that routine disables some Interrupts

With my limited knowledge on interrupts,  am I right in thinking that using starkos was causing the conflict and crash?

I don't know why I couldn't get to the last lantern

Was this because of memory or because you couldn't work it out?  I know I designed 2 of them to be event related in order to get them. (Clue - They both have to do with the boy / girl characters in the game helping you). I would have loved to have made more event based collections but I just ran out of memory.