Jump to content

Recommended Posts

Hi all,

 

After 20 years since I last coded anything on 8bit Atari, I decided to try again to play with some 6502 assembly.

 

The result you will find in attachment - a WIP of Great Escape game ported to Atari 8bit from C64. Game seems to be quite playable, but there are still various issues, so it is considered "alpha" now.

 

I am going to work on this port to finish it someday, but I need some help.

 

1. I need sound effects for the game. It looks that there are not many, but roll call is definitely required. Since I am not musician or sfx composer, I need somebody with proper skills to get the job done.

2. Music for the game. The problem is that there is only 4KB of RAM free and there is not much time in frame left for player (actually there is no time, as game is pretty slow, but still faster than on C64) but music may improve the gameplay.

3. Loading picture. C64 picture would be probably easy to convert, but it doesn't look good in my opinion. ZX-Spectrum title screen is much better, but my preferred one is here: http://speccy-live.untergrund.net/2013/02/the-great-escape-new-loading-screen-by-craig-stevenson/. Not sure if it is possible on Atari.

4. Hints on possible optimizations and bugfixes are also welcome!

 

Game screen will be also improved to follow C64 look. Hopefully PMG coloring on inverse hires will do the job. If you have some better ideas, please let me know.

 

Attached ge.obx will work only on Altirra, as it loads directly under OS ROM in current form, so it will not work on real Atari. This issue will be addressed later.

 

Enjoy Great Escape!

 

Mariusz.

ge.obx

  • Like 15
Link to comment
https://forums.atariage.com/topic/239167-new-game-great-escape/
Share on other sites

Thank you, if its the game I think it is its one game I really enjoyed on the C64

 

If its not then its still a thank you for adding to our games :)

 

EDIT:

 

Yup its that game..

 

Thank you so much...

Edited by Mclaneinc

Superb! This is one of those games that I always wished was on the Atari as I've admired it from afar.

 

The one thing that gets me with this game though is that I've never had a clue what I was doing. On release, would an overview guide be possible?

 

Which compiler are you using? Could you produce two binaries? One binary with illegal opcodes if required to speed the game up. And the other (slower) version which maintains 6502 compatibility. This should keep everyone happy. Please everyone else, lets not start an endless discussion on this.

 

I'd avoid music if you have no CPU time left. Perhaps you could have a separately loaded title screen which has music? I'd worry about that later though, the game being most important.

As for optimisations, it's hard to comment when we haven't got access to the code. But could there be some compression within the game, maybe loading the individual "levels" as required?

 

That would then give you more space for other things.

 

Code for Atari version is attached - see ge.asm. To build it, MADS is required and memmory dump of original C64 game. I also attached disassembly of C64 version done with Infltrator. Disassembly is partially commented, but only in areas I needed to make changes for Atari (so accessing video registers and video bitmap, reading I/O).

 

About the structure: C64 version maintains internal framebuffer at $CF40-$DBFF where all drawing takes place. (I had to move this on Atari to $C200 to avoid collision with I/O registers). Every frame game is copying this internal framebuffer to screen. You may check "blitter" subroutine which performs this task. There is one more case with scrolling - game performs soft scrolling when hero is moving. This is "blitter_scrolled" subroutine. These are now faster than C64 counterparts because of linear screen organization on Atari.

 

The other slow subroutines seem to be sprites - these were not touched by me at all in Atari version. The perform all drawing on internal framebuffer at $CF40.

 

Mariusz.

ge.asm

gec64.asm

  • Like 1

Hi and thanks for your work.

I am right now seeing C64's and A8 and because of the software scrolling it is a little bit slow like you said.

But if you want my opinion, even with the linear bitmap of A8 you can even speed it up/more available cycles/cpu and probably have more free RAM to use, for example, on music and sound fxs:

-> On A8 you don't need all the 200scanlines of the C64 version. I think they are about 184 in use (including playing area field borders and text) soo put all others as blank;

-> Set screen into Narrow 32Bytes wide mode (from the C64 version you only have to move the left side text 2 or 3chars to the right;

Maybe something more can be done but as you all know I'm not a coder and justed wanted to say what at a first looking seems a 'way to' :).

Greetings.

Edited by José Pereira

In the soft sprites I don't know much about but maybe C64 have the frames in chars boundaries and more chars for the shifting then maybe on A8 linear bitmap GR.8 and at least for their up and down movement you only need one scanline more for the shifting may help...

Hi and thanks for your work.

I am right now seeing C64's and A8 and because of the software scrolling it is a little bit slow like you said.

But if you want my opinion, even with the linear bitmap of A8 you can even speed it up/more available cycles/cpu and probably have more free RAM to use, for example, on music and sound fxs:

-> On A8 you don't need all the 200scanlines of the C64 version. I think they are about 184 in use (including playing area field borders and text) soo put all others as blank;

-> Set screen into Narrow 32Bytes wide mode (from the C64 version you only have to move the left side text 2 or 3chars to the right;

Maybe something more can be done but as you all know I'm not a coder and justed wanted to say what at a first looking seems a 'way to' :).

Greetings.

 

C64 version of the game is a port from Spectrum, so it actually uses 256 x 192 pixels screen. I am using the same screen size in Atari version.

 

Mariusz.

I was only saying that because C64 has always a screen size of 320x200 and ZXs a 256x192.

Yes I understand that what moves here in software is what is inside and that is the same size on the two but because A8 has three possible screen widths: 32, 40 and 48 set the screen to 32Bytes frees cycles and Screen RAM, what I don't know and was asking is if this will help in anything 'speed related' when the inside the field is the same size on the three versions.

But have you already put it in 32Bytes wide? At least for the screen you have about 8KBs for a 40Bytes wide screen that would decrease to an about 6KBs one, isn't it?

 

 

P.s.- Do you see any techinal explanation other than maybe the guy(s) behind the C64's version taste to didn't include the flag on the left side?

I was only saying that because C64 has always a screen size of 320x200 and ZXs a 256x192.

Yes I understand that what moves here in software is what is inside and that is the same size on the two but because A8 has three possible screen widths: 32, 40 and 48 set the screen to 32Bytes frees cycles and Screen RAM, what I don't know and was asking is if this will help in anything 'speed related' when the inside the field is the same size on the three versions.

But have you already put it in 32Bytes wide? At least for the screen you have about 8KBs for a 40Bytes wide screen that would decrease to an about 6KBs one, isn't it?

 

 

P.s.- Do you see any techinal explanation other than maybe the guy(s) behind the C64's version taste to didn't include the flag on the left side?

 

Yes, the screen is 32 bytes wide. And it needs 6KB RAM for display.

 

I am not sure why flag is missing. It is not missing RAM, as C64 version still has some free RAM left. I think either it made game even slower so they didn't accept it, or just author missed the deadline for delivering the game, so he had to cut some features. "Score" in Spectrum version appears to be expressed in medals and not simple numerical value like C64 version does.

 

BTW: I know you are doing lots of graphics for Atari, could you please make left and right ornament for playfield (vertical bars in yellow in C64 version) as PM/G graphics for Atari? This would allow me to have yellow for whole ornament like C64 has.

 

Mariusz.

 

3. Loading picture. C64 picture would be probably easy to convert, but it doesn't look good in my opinion. ZX-Spectrum title screen is much better, but my preferred one is here: http://speccy-live.untergrund.net/2013/02/the-great-escape-new-loading-screen-by-craig-stevenson/. Not sure if it is possible on Atari.

If you like that image, I think Rastaconverter could make a good conversion.

The best result theoretically achievable is something like that:

post-12528-0-36042700-1433789756_thumb.png

I will try the conversion in a few days; my netbook have not the necessary power and I am away from home.

  • Like 1

Philsan great you can take it because I'm not a good one with pictures.

Could you, if Mariuszw agree and because it's out of the main game file to add a nice logo letters into the top of that picture.

In my opinion is what is missing there, maybe with the A8 possibility to have more scanlines available...

If you like that image, I think Rastaconverter could make a good conversion.

The best result theoretically achievable is something like that:

attachicon.gifoutput.png-dst.png

I will try the conversion in a few days; my netbook have not the necessary power and I am away from home.

Philsan - if you send me the parameters you usually use, I can run the conversion. I have an i7 4770k with 16GB RAM and I run it 24/7.

4. Hints on possible optimizations and bugfixes are also welcome!

 

Might be counter productive regarding your memory footprint, but there is some potential by

loop unrolling, loop unrolling and loop unrolling...:

 

(Examined only the hot-spots)

$6C26  LDX #$A0
$6C28  LDA #$FF
$6C2A  STA $035F, X
$6C2D  DEX

=>

$6C26  LDX #$50
$6C28  LDA #$FF
$6C2A  STA $035F, X
       STA $03AF, X
       DEX

---

Blitter functions for the 4 directions:
($89A5, $8A07, $8A61, $8AAE) like

$8A04  LDX #$0C
$8A06  DEY
$8A07  LDA $CF40,Y     ; OK
$8A0A  STA $CF41,Y
$8A0D  DEY
$8A0E  BNE L_BRS_($8A07)_($8A0E) OK
$8A10  DEY
$8A11  LDA $CF40         ; OK
$8A14  STA $CF41
$8A17  DEC $8A09
$8A1A  DEC $8A13
$8A1D  DEC $8A0C
$8A20  DEC $8A16

=>

$8A04  LDX #$0C
$8A06  DEY
SMCA:  LDA $CF40,Y     ; (here is some potential left, if you can avoid the page boundary crossing
SMCB:  STA $CF41,Y      ; for the load - by start address/init adaptations...)
       DEY    
SMCC:  LDA $CF40,Y
SMCD:  STA $CF41,Y
       DEY
       BNE SMCA
       DEY
SMCE:  LDA $CF40
SMCF:  STA $CF41
       DEC SMCA+2
       LDA SMCA+2
       STA SMCB+2
       STA SMCC+2
       STA SMCD+2
       STA SMCE+2
       STA SMCF+2
---

Of course you could create a version for memory upgraded machines where you fully unroll the 4 moves with absolute addressing... ;)

 

I also notice sometimes the following corruption of the graphics (seems to be self-healing):

post-7778-0-17132000-1433959250_thumb.png

Edited by Irgendwer
  • Like 1

 

Might be counter productive regarding your memory footprint, but there is some potential by

loop unrolling, loop unrolling and loop unrolling...:

 

(Examined only the hot-spots)

$6C26  LDX #$A0
$6C28  LDA #$FF
$6C2A  STA $035F, X
$6C2D  DEX

=>

$6C26  LDX #$50
$6C28  LDA #$FF
$6C2A  STA $035F, X
       STA $03AF, X
       DEX

---

Blitter functions for the 4 directions:
($89A5, $8A07, $8A61, $8AAE) like

$8A04  LDX #$0C
$8A06  DEY
$8A07  LDA $CF40,Y     ; OK
$8A0A  STA $CF41,Y
$8A0D  DEY
$8A0E  BNE L_BRS_($8A07)_($8A0E) OK
$8A10  DEY
$8A11  LDA $CF40         ; OK
$8A14  STA $CF41
$8A17  DEC $8A09
$8A1A  DEC $8A13
$8A1D  DEC $8A0C
$8A20  DEC $8A16

=>

$8A04  LDX #$0C
$8A06  DEY
SMCA:  LDA $CF40,Y     ; (here is some potential left, if you can avoid the page boundary crossing
SMCB:  STA $CF41,Y      ; for the load - by start address/init adaptations...)
       DEY    
SMCC:  LDA $CF40,Y
SMCD:  STA $CF41,Y
       DEY
       BNE SMCA
       DEY
SMCE:  LDA $CF40
SMCF:  STA $CF41
       DEC SMCA+2
       LDA SMCA+2
       STA SMCB+2
       STA SMCC+2
       STA SMCD+2
       STA SMCE+2
       STA SMCF+2
---

Of course you could create a version for memory upgraded machines where you fully unroll the 4 moves with absolute addressing... ;)

 

I also notice sometimes the following corruption of the graphics (seems to be self-healing):

 

Thanks for the hints about performance. I discovered Altirra awesome profiler in the meantime and found all that wisdom ;). There is still some space left for the code, so I may try to unroll most expensive loops.

 

The problem you mentioned turned out to be a bug in patching C64 routines, now fixed, thanks for report.

 

Mariusz.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...