Tom

If you don't absolutely need to use PICs (for instance, if you need to work with an existing design that uses one), I'd also recommend you to look at Atmel's AVR controllers. They're pretty good, easy to program in assembly and GCC is available for them aswell.

Something like that would probably be reasonable. We could simply bake the rightmost border of a screen into the map/graphics data of its right neighbor screen.

this depends probably on how you render the image. in the original's fake 3d rendering method, only the rightmost tiles of a screen could be seen on the screen to the right. you mean the situation in the screenshot (from pv3) below. each cell of the red grid is what can be seen on the computer screen. from the map data's point of view, the gate is part of the left screen, but only the post can be seen on the left screen. most of the gate can be seen on the right screen only, but the gate is not really part of the right screen. nothing from the right screen is visible on the left screen.

actually this is only necessary on the left side of a screen. there, the rightmost tiles of the screen's left neighbor can be seen. but it's of course also possible on the right side, since you have an additional PF pixel there... i think you also should draw the bottom border of the top screen onto the current screen. there are some places where the upper screen contains a floor with a loose floorplate, which you should see from the screen below (when you hit the ceiling)

How much of the playfield are your kernels using ? PF1 and PF2 ? You see, a screen in Prince consists of 10*3 tiles, so if you want to use the original level data, you'll probably end up with 3 playfield pixels per tile (or 4, if you use the whole playfield).

Oh, this is of course the keyboard scheme i described. The "button" is the shift key. Possibly the joystick worked differently.

PC version 1.0. Poor myself had to grow up with PCs. The first I ever saw was an XT.

Nah, in the original pressing up was jumping, and right/left without button was running. So, to do a running jump you'd press left (or right), then press up while keeping left pressed, and during the jump you'd press the button to hang onto ledges. This needed sometimes careful timing, especially when you had to do several running jumps in sequence, but that was part of the fun.

yep. the same button is also used for climbing down a ledge, but keep hanging, and for hanging onto ledges while jumping in the original. i looked at the princed stuff, btw. i found some neat document describing the different data files, and can probably use code from pv3 to extract the needed information. i'll look closer into it next weekend.

Hereby I repeat my offer to help with level generation tools I suppose it's still too early to do much in that direction, though.

Oh yes, the shadow...how could I forget.

I must say, I can't remember exactly about PoP 1, but in PoP 2 there are indeed situations where you'll decide to run rather than fight. People would need to play the game to actually find out.

You can also put your sword away by yourself, useful if you want to chicken out (if you're too slow, you'll get stabbed in the back then:). This is done by pressing down during a fight.

I could probably also help with level conversion tools...

Btw, it shouldn't be too hard to automate level generation from the original data files. The file format is known, and there are both level editors and prince of persia engines available...

3d looks cool, but how do you make the prince walk between two pillars ?

http://www.atariage.com/forums/viewtopic.php?t=64600

I don't think so. As somebody else said, vertical movement is usually very fast anyway. I only know the PC version. There the enemies behave just like the prince when they're falling: If they fall high enough, they lose energy, and if they fall even higher they die.

the enemies didn't jump or climb by themselves, but it was possible to drop them down ledges (during fights, when they retreat)

If you run the game with z26 and supply the -f switch, the flicker goes completely away. Seems to work in windowed modes only, though.

Do you mean game demos, or demoscene demos ?

more audio channels (3 or 4). this would allow you to have games with cool ingame music and sound effects. extensions you make to the 2600 hardware probably should be somehow "protected", so that old games don't accidentally trigger them... thomas: he plans to support PAL

or flashing lights. that would be cool.

i think the ships with straight legs look better than those with inward bent legs. #1 looks pretty cool, but it is a bit large.

the only thing i could see from the labels when i transcribed the riddle of the sphinx was that the author apparently didn't have an assembler that supported local labels