Tom

I tried to compile that stuff with Borland Pascal, with debug information enabled. Well, the compiler chokes on pcae.pas, because it generates more debug info than the compiler can handle

Yeah, that's it . Any chance the source for version 2.5 for DOS (seems to be the last DOS version) is around there aswell ? I said I had it earlier, but what I have is actually v. 2.4.

Wouldn't buying a set of playing cards be an option ?

The windows version uses Delphi, but I cannot find the source code. The DOS versions I found (apparently up to version 2.4, hard to tell, the archives are all named pcaesrc.zip, and the version numbers spilled in the source files contradict themselves !) used no object oriented extensions, just shitloads of inline assembler even in places where it probably wouldn't have been necessary. Much of the code is DOS / hardware specific. Now, there is Freepascal, and there are SDL-Bindings for Freepascal, so lots of this code could be simply kicked. But the inline assembly that remains would either have to be reworked to account for the different memory model, or translated back to Pascal.

That's version 2.5, which is easy to find. Googling for pcaewrsc.zip yields nothing. Adding a debugger to z26 might make more sense anyway.

A lot of dead links for 2.6 point to http://pcae.vg-network.com

Interestingly enough, I have an archive with PCAE 2.6, which contains a copy of the GPL. This is already a good thing, since it would allow for further development - if the source was actually available.

Did anybody ever get his hands on the *source* for PCAE 2.6 for windows ?

Question of taste Personally I'd prefer testing all banks extensively, before I even suspect there's an error (or the other way around, I assume I did a mistake). I wouldn't want to wait until the random number generator picks by chance the faulty bank. The sooner you can find and fix a bug, the less trouble it causes you.

With the bankswitching experiments I had done in the past I simply reorganized the different bank images in the rom itself for testing purposes, but this is awkward. And you always have to remember wether z26 starts in the first or the last bank. A start in bank x switch would be very useful (so you can test wether your rom starts correctly from every bank), but i don't think there's much use for a random switch. Well, probably this isn't going to be implemented anytime soon unless somebody who really wants it implements it himself

Afaik z26 doesn't start in random banks.

Heaven: you're the Atari 800 coder here I only recently got an 800XL, but haven't got around to do much with it yet. Of course it would be possible...

Additionally I'd like to point out that vcs.h and macro.h are very well documented and you shouldn't just use them, you should actually *read* them whenever new versions come out

Before you include vcs.h, as vcs.h will define the symbol with a default value if it's undefined. vcs.h: ; TIA_BASE_ADDRESS ; The TIA_BASE_ADDRESS defines the base address of access to TIA registers. ; Normally 0, the base address should (externally, before including this file) ; be set to $40 when creating 3F-bankswitched (and other?) cartridges. ; The reason is that this bankswitching scheme treats any access to locations ; < $40 as a bankswitch. IFNCONST TIA_BASE_ADDRESS TIA_BASE_ADDRESS = 0 ENDIF

And how does the bankswitching mechanism work ? I'm asking as I'm working on a 32k project at the moment, which might or might not evolve to 64k. If I already knew the bs mechanism, I might plan ahead a bit more.

This will not be an issue soon. ..Al Any more information on that ?

Cross development is definitely the way to go...

That would be http://www.atariarchives.org =) I'm looking at that stuff at the moment aswell, as I got an 800XL last week. I'll probably end up using cc65.

Using PR (I posted a link somewhere in this thread), it's possible to unpack all data files, so one can easily get the prince/enemy animations. No idea how useful they are to base artwork on, though. I find it funny how people are already thinking about easter eggs, when all there is for now are two kernel protos, prince graphics and a bunch of lousy coded Ruby scripts to read PoP 1.0 level resources

No, not yet. It's on the todo list.

Here are the numbers of screens: Level 1 : 21 Level 2 : 24 Level 3 : 22 Level 4 : 24 Level 5 : 19 Level 6 : 14 Level 7 : 24 Level 8 : 21 Level 9 : 24 Level 10 : 19 Level 11 : 23 Level 12 : 24 Level 13 : 11 Level 14 : 6 Total : 276 The # of rooms *really* needed might be slightly smaller. For instance, level 14 has 6 rooms, but the last room is never shown, because as soon as you enter it, the endgame sequence is shown. The actual sixth room is never used, but it's there. That's quite a lot of space needed. The original data files use 60 bytes per screen + additional data for guard positions, room and door linking. (triggers are linked to doors using separate data structures. a trigger can open or close several doors) A lot of the screen data is eyecandy only, though. Things like cracked or darkened stones. I'll look at the other stats Thomas has requested and update the results as I get them.

I haven't looked at the animations yet. PR from the princed project might help here. This is a resource (graphics, music etc) editor. kid.dat (the prince) alone contains over 200 resources, most of them being animation frames. The enemies use less resources, after all all they do is standing around, advance, retreat, block and occasionally die I can look closer at this later, I'm working on some level reading code now. http://www.princed.com.ar/sfiles/pr1.0b.win.bin.zip

I'm not as far with the level import / statistics stuff as I intended, but I'm still working on it. I got a new job which required me to read quit a lot to actually get started, which used much of my time. The PoP level format doesn't make things simple neither: for instance, the only way to really tell wether a screen in a level is used is by trying to find a way from the start screen to the screen in question (the screens basically form a directed graph. just looking at the screen data won't help, because the screen data apparently often contains leftovers from level-editing)

Best thing would be to SDL-ize the code.

Since you put it under the GPL, where can one get the source code ?