Unicorns season: Prince of Persia for the A8!

[rensoup]

I decided to try porting PoP in early 2019.

 

-This port is based on the BBC Master port by Bitshifters https://bitshifters.github.io/posts/prods/bs-pop-beeb.html (Props to them!)

-Based on the original Apple2 code by Jordan Mechner https://github.com/jmechner/Prince-of-Persia-Apple-II (Props to him!).

 

The background graphics also comes from the BBC port.

 

-On the art side:

• The character art remastered by @TIX
• @miker music + sfx bank 1
• @VinsCool music
• @emkay sfx bank 2
• @makary sfx bank 1

 

-On the tech side:    

• Soundplayer: @dmsc's LZ4 SAPR player.
• Disk loading: Xbios by @xxl.
• Dev+ Testing: Altirra by @phaeron.
• Assembler: Beebasm(!) by Rich Talbot-Watkins.
• aplib depacker: @elmer

 

Requires Altirra 3.90

                                                                                                                                                            

2021/06/19 BUGFIX release

2 SD disks:

PoP_SD_20210619_bugfix.rar

1 DD disk:

PoP_DD_20210619_bugfix.rar

Megacart:

PoP_Megacart_20210619_bugfix.rar

Atarimax:

PoP_Atarimax_20210619_bugfix.rar

SIC:

PoP_SIC_20210619_bugfix.rar

 

While the game worked fine in emulation, it had a few issues with more exotic real HW configs, this version should improve stability for many of those.
 

 

2021/06/10 release

Disk Versions:

2 SD disks:

PoP_SD_20210610.rar

1 DD disk:

PoP_DD_20210610.rar

Cart Versions:

Megacart:

PoP_Megacart_20210610.rar

Atarimax:

PoP_Atarimax_20210610.rar

SIC:

PoP_SIC_20210610.rar

 

9 levels demo.

 

-The focus for this release was on the attract mode & cutscenes which are now fully reenabled!  

 (some assets may possibly not be final) 

 TIX, our favourite overstretched artist drew all the princess/vizier frames required for the cutscenes!

 Miker added a bunch more tunes for the attract mode!

-Added a bunch of cart versions for faster loading and a SD disk version for maximum compatibility with stock hardware.

-Fixed an old bug where the game would freeze if the prince landed on the edge of a floor tile.

-NTSC should be as stable as PAL now.

 

 

2020/05/14 release pop20200514.zip

7 levels demo, all features implemented!

-Vest color
-PMG masking
-non crashing gameflow (finishing a level brings the next one until level8 where it crashes)
-customization menu

-new skeleton & fat guard by TIX

-more tunes by Miker

-new SFX bank by Emkay
 

 

 

 

 

 

20/04/06 release   pop20200405.zip pop20200406NTSCfix.zip

 

-TIX's fully redone Prince animations with the sword and the main guard fully animated in 5 colors!

-new tunes by Vinscool and Miker

-sfx by Miker and Makary

-fixed slide bug by XXL

-5 levels, including 2 palace levels. Each level is fully playable but the game stops once you take the exit door (still need to make some space for the cutscene code!)

-improved frame rate

- *UPDATE*: fixes for NSTC

 

 

Spread the news but please don't make local copies of the ATR on other websites but rather link to the 1st post of the thread on AtariAge

 

 

 

20/01/13  releasepop20200113.zip

 

-one playable level (L2)
-PMG overlays with repositioning for the player (not for the enemy yet)
-preliminary music by Vinscool
-a lot more animation frames redone by TIX
-fix: random button presses during fights
-bug: running to the right then left, still keeps running to the right

                            

 

 

the very first release was posted here

 

test release for modern SIO devices (unplayable)

pop_DDfastestmouse_notplayable2.zip

 

test release without a full directory for better loading speed (unplayable)

pop_DD_NoDir_Unplayable.zip

 

 

Edited July 15 by rensoup
2021 06 version

[rensoup]

I was hoping to have this project completed for the A800's 40th birthday but I spent a little too long learning 6502 asm and the A8 architecture on demo projects. The game is already playable but not quite complete. The most optmistic deadline for a full version is early 2020.

 

-The goal is to make a great 8bit home computer version with as few compromises as possible.

 

-The target is a stock Atari 130XE (128KB of RAM) on a single 128KB floppy.

 

-Keep in mind when comparing the A8 version to the other ones:

 

    .The original Apple2 version by Jordan Mechner runs in 128KB at a funky resolution of 140x192 pixels 6 colors with restrictions.

 

    .The C64 version runs at 160x192 4 colors + sprites but uses a 512KB cart (not sure exactly what's in there but MrSid, its author, said on his blog that the sprites were premirrored). It's a great looking version which was started by reverse engineering the Apple2 code (That must have hurt...).

 

    .The BBCM version runs at 160x192 8 colors (but with a horrendous predefined palette) with 128KB of RAM. The 6512 (6502 variant) is clocked at 2Mhz. The sprites are stored at half the vertical resolution though, because the coder ran out of memory (to be fair the 2 screen buffers are twice bigger than the Atari ones)
    
    .The CPC port wasn't very good and I doubt it really shows the machine's power. This is potentially the most powerful 8bit computer (but it's really halfway between 8 and 16 bits)
        
    .The spectrum port, I've seen it. Unfortunately.

 

-More technical details:

    .For Graphics, I'm using modeE (bitmap 160x192 4 colors + sprites) for the main area. modeF for text line. mode4 for the status line.
    The main software sprite function does shifting, mirroring and clipping on the fly. It is slow indeed.
    PMGs are used for extra colors.

    .Xbios... Yes I know it's a touchy subject. It works pretty well in Altirra (but will load slowly on actual  1050 drives). It also means it will not work with some carts but should be ok with SIO devices which connect to a PC ? I don't really know... Once the game is complete I may revisit and make another build for cart based storage devices using the OS ROM SIO code.
        
    .Why Beebasm? That's the assembler used for the BBCM port. MADS is nice but why change something that works? I use MADS for the initial loader and a bunch of other surprises.
    

This week, I'll be sprinkling the thread with updates at various stages (and the latest version around november 30), so stay tuned!

 

 

[Gunstar]

Can't wait!

[+cjherr]

I think this will be great!

[Tezz]

Excellent news, I'll look forward to seeing that. I wasn't aware of the BBC Micro release, what a great job they did with it.

Edited November 26, 2019 by Tezz

[Goochman]

Checks to see if its April 1st.................looking forward to updates!

[rensoup]

Could be real, you never know 😁

 

So just for reference, here's a gif of the BBCM version:

 

 

 

This is what you get once the main loop ticks (a few months of work)  and the first block copy function is implemented (half an hour):

 

 

the 2nd block copy function (10 minutes!)

 

 

and the 3rd one (few more minutes)

 

 

The copy functions are STA - ORA - AND respectively. Differences between the 2nd and 3rd gif can be seen at the bottom of the orange wall on the left, near the floor (no more overlapping)

 

This is the full game running in Altirra btw (wish it would output animated gifs directly 😃)

 

[E474]

Hi,

 

   Looks very nice, is there any way you can separate out the program and level data, so you get two 90K images (sides ?), so it can run on 810 drives as well?

[+Philsan]

Thank you! Can't wait to play POP on A8.

[emkay]

Ofcourse linear graphics will be faster for the game.

2MHz (BBC) vs. 1.3MHz (Atari) .

It will be a challenge. Particular if masking comes into play

 

Best wishes .

[+Philsan]

Considered the fact there are now many cheap multicarts around, have you considered to make a CAR/ROM version?

Instant loads and no memory limits!

[Franco Catrin]

If you need faster graphics may be you can borrow some of my code for this game. It relies in precalculated tables

 

https://github.com/fcatrin/a8pop

https://www.youtube.com/watch?v=6QGc7zjj660

 

 

[+CharlieChaplin]

Good luck! I would love to see an A8 version of PoP...

 

Alas, if you're gonna use XBIOS you should know that all hell will break lose and the spanish inqusition will come over you... see the topic about SCR:

 

 

[rensoup]

Good to see there is still interest for unicorn projects!

 

1 hour ago, E474 said:

Looks very nice, is there any way you can separate out the program and level data, so you get two 90K images (sides ?), so it can run on 810 drives as well?

Really ? you have a 128KB computer with 90KB drive ? Good you're mentioning that now 😀. I'll keep it in mind. Hopefully I can just have a retry button if Xbios doesn't find the file, which would allow the disk to be swapped.

 

1 hour ago, emkay said:

Ofcourse linear graphics will be faster for the game.

2MHz (BBC) vs. 1.3MHz (Atari) .

It will be a challenge. Particular if masking comes into play

Surprisingly it worked out ok even though the function is slow, 1 sprite taking a full frame at 50hz.

 

When fighting there are 4 sprites: player + enemy and 2 swords but I think the gameplay was tweaked so that around 12.5-15 fps was the sweetspot, any faster and it doesn't feel right (I tried changing the CPU model in Altirra)

 

Btw, there's a frame limiter so that it plays at 17fps minimum so overclocked CPUs will never go faster (nor slower) and I avoided extended opcodes too...

1 hour ago, Philsan said:

Considered the fact there are now many cheap multicarts around, have you considered to make a CAR/ROM version?

Instant loads and no memory limits!

Yeah but that wouldn't be stock Atari then (plus the original was 128KB)

 

1 hour ago, Franco Catrin said:

If you need faster graphics may be you can borrow some of my code for this game. It relies in precalculated tables

When I said shifted on the fly I meant using tables of course (not having all 4 shifted versions of the sprite in memory)

 

48 minutes ago, CharlieChaplin said:

Alas, if you're gonna use XBIOS you should know that all hell will break lose and the spanish inqusition will come over you... see the topic about SCR:

Yes I mentioned it in the 2nd post, I may do a version that supports standard SIO later.

[Franco Catrin]

1 minute ago, rensoup said:

When I said shifted on the fly I meant using tables of course (not having all 4 shifted versions of the sprite in memory)

 

Oh no, there is no such a thing, the sprite is once in memory.

The precalculated tables are at the byte level, but it seems you already got it.

 

Also, the animations are done at 15fps, you don't need to go higher than that.

[xrbrevin]

great news!

i sometimes forget how blessed we are to have a decent pallette. spare a thought for those poor C64 and BBC micro owners

[Wrathchild]

2 hours ago, rensoup said:

4 hours ago, Philsan said:

Considered the fact there are now many cheap multicarts around, have you considered to make a CAR/ROM version?

Instant loads and no memory limits!

Yeah but that wouldn't be stock Atari then (plus the original was 128KB)

A bit harsh, there were of course 128KB XEGS ROM titles (examples) and latterly the XEGS switchable, AtariMax & MegaCart type carts that gave better capacity.

The advantage of a such a cart version is that you could actually target 64K, even 48K, as the 'stock' model.

 

If Philsan is more referring to the more recent AVG & UNO, Ultimate and The!Cart cartridges which themselves can emulate the above bank switching models, then that kinda defeats the point as these (maybe with the exception of the Ultimate Cart) can run ATR images and sector load times, yes, aren't as fast as switched bank but still fast enough. But again, being able to use a cart image instead means the 48K/64K RAM target instead of 128K.

 

As you are already employing a form of bank switching for the 130XE's extra memory in the $4000->$7FFF window then a build for a MegaCart image with its window at $8000->$BFFF should pose too many problems.

[darwinmac]

As someone who owns a 64K XEGS, I’m hoping that he’ll reconsider releasing a cartridge version. 
 

Bob C

[ilmenit]

Looking at the discussion around Stunt Car Racer and xbios I hope the angry mob will understand how much time consuming it is to support all the "out of default" hardware or OS implants and modifications. As programmers we have limited time and do retro as a hobby, not asking money for our productions. Mob probably have no clue how much energy it takes to finish game and release. It's easy to get burn-out and leave project on 80% as a "tech demo". When I released His Dark Majesty years back I also got a lot of negative discouraging feedback "why you don't support QMEG, why don't it work on XYZ or ABC" and "WHEN ARE YOU GOING TO FIX THIS! IT'S NOT WORKING ON MY SUPERB ATARI HARDWARE FROM 21st CENTURY!".

I'm crossing my fingers for success of this project and hope that toxic people will stay away from it.

[fantômas]

Damn!
I had my own Pop conversion project: https://github.com/fa8ntomas/pop-a8
Well, my project is much less advanced: It seems I'm a little late at the party 😉.

Anyway, well done 👍

 

However, my idea was to make a 128KB cartridge. Why 128Kb: because I think it's the maximum that can manage the Uno cart.... 

At the point where I was, it seemed feasible to me... but I hadn't really integrated the sprites yet...

[Jacques]

Fantastic news, I'm sooooooo happy to hear we're going to have PoP on 8-bit Atari in the end.

Just a question regarding coulour-scheme, will the first levels stay green(?) or maybe there would be chance to make them Amiga/Atari ST/PC/CPC-like - in the PoP-classic shades of blue?

 

Fingers crossed for finished game!

Edited November 27, 2019 by Jacques

[mrsid]

@rensoup

Wow, great achievement so far!

Good luck with finishing it. Let me know if I can be of any help...

 

[rensoup]

11 hours ago, Franco Catrin said:

Oh no, there is no such a thing, the sprite is once in memory.

The precalculated tables are at the byte level, but it seems you already got it.

 

Also, the animations are done at 15fps, you don't need to go higher than that.

Wait, I just had another look... seems like you're using 1.5KB of tables while I'm using 3KB, that could be interesting 😉

 

Thanks for that !

 

 

[rensoup]

8 hours ago, Wrathchild said:

A bit harsh, there were of course 128KB XEGS ROM titles (examples) and latterly the XEGS switchable, AtariMax & MegaCart type carts that gave better capacity.

The advantage of a such a cart version is that you could actually target 64K, even 48K, as the 'stock' model.

 

If Philsan is more referring to the more recent AVG & UNO, Ultimate and The!Cart cartridges which themselves can emulate the above bank switching models, then that kinda defeats the point as these (maybe with the exception of the Ultimate Cart) can run ATR images and sector load times, yes, aren't as fast as switched bank but still fast enough. But again, being able to use a cart image instead means the 48K/64K RAM target instead of 128K.

 

As you are already employing a form of bank switching for the 130XE's extra memory in the $4000->$7FFF window then a build for a MegaCart image with its window at $8000->$BFFF should pose too many problems.

 

I didn't know 128KB carts were released during the 80's...

 

Now you guys made me think that perhaps there could be a cart version instead of a OS SIO version...because frankly i don't fancy hotswapping the OS 😛

 

Btw, when I said a 128KB disk I meant compressed with deflate, so surely I would have to keep everything uncompressed and use a 256KB cart if I targeted 64KB machines ?

 

I would probably have to store some game code into ROM which could be a problem as it uses selfmod code (sparingly though)

 

1 hour ago, fantômas said:

Damn!
I had my own Pop conversion project: https://github.com/fa8ntomas/pop-a8
Well, my project is much less advanced: It seems I'm a little late at the party 😉.

Anyway, well done 👍

 

However, my idea was to make a 128KB cartridge. Why 128Kb: because I think it's the maximum that can manage the Uno cart.... 

 

Well your expertise may still be useful 😀

[rensoup]

 

1 hour ago, mrsid said:

@rensoup

Wow, great achievement so far!

Good luck with finishing it. Let me know if I can be of any help...

 

Thanks, it's all your fault 😁

 

Actually I have a bunch of questions just out of interest...

 

-What's in the 512KB ? premirrored sprites of course but that's about 40KB or something ? sound samples ?

 

-Why did you use a mask buffer for masking the sprites, instead of masking the sprites directly with the object in front of it ?

I'm currently using software sprites only but will eventually add skin color with hardware sprites which will require masking them and I figured I could just take the front objects that the game flags for redrawing and apply them as masks (the generic pillar for instance is a plain rectangle drawn with STA mode so that would be fast, the gates would require proper masking of course)