Prince of Persia

[The Usotsuki]

Correct. Only the attract screen is DHGR, and you'd probably want to redo that from scratch anyway.

[MEtalGuy66]

I was not aware that the game action screens were not DHR.. But for sure, the entire cinematic sequence (demo/intro) art is all DHR.. and thats quite a few screens, if I remember correctly..

[potatohead]

IMHO, reaching a point where those matter is a nice problem to have

 

I have started looking at the PoP code on apple to form a memory map and understand what can be loaded to test things out on an Atari.

[potatohead]

Ahh much better on phone with mobile site. Sorry for poor format above.

[The Usotsuki]

The actual cinematics are in the 280x192 mode (the first one, for example, only uses white/blue/orange/black). The title and narration screens are in DHGR.

 

That basically means 2 screens of text, plus the title/credit page. Everything else could theoretically be done on a ][+ if it had more RAM.

[potatohead]

Next step for me personally is to get the PoP code to assemble in emulation. I'll be a while on that front. Don't care whether it's all there or not. Do care to see how it builds and what goes where. Maybe trim it down to a subset for further work / proof of concept testing.

[MEtalGuy66]

Nothing is 280x192 when the chroma signal is on.. The only time youll ever see 280x192 on an apple IIe/IIc is when the monitor is in mono mode, or you are looking at a text only screen (in which case the computer turns off the chroma signal and the pixels that make up the text font actually do have 280 or 560 visible points across the screen horizontally, depending on whether or not you are in 80 column mode). This is why when you have a text window at the bottom of a hires screen, the text has that color-blur look to it.. And on a pure textmode screen, it does not.

 

Any time you are looking at a color graphics screen, there are 140 discernable horizontal color pixels. period.. (potatohead pointed this out much earlier in the thread). Applesoft BASIC confuses people by letting you plot colored pixels to any horizontal location (0 to 279) but what it is in fact doing is either setting or clearing a 2bit pattern of monochrome pixels at the closest corresponding location in order to produce a screen artifact of the color you are plotting with. When you use hi res graphics in assembler, you quickly realize that there are not 280 colored pixels horizontally.. only 280 mono ones..

Edited February 20, 2013 by MEtalGuy66

[potatohead]

Got the components all collected. I need some help with an Apple hard disk image.

 

Anyone have a bootable PRODOS hard disk image I can mooch? Or, educate me on how to make one? From what I can tell, I should be able to drop Merlin onto the HD, along with the code and start from there. Could do floppies, but that's a PITA.

 

And this is emulation. The real deal would be slower, and it's at home. Maybe run test on that when I get the thing to build and can cut it down to a test image for Atari.

[MEtalGuy66]

You should be able to do that with CiderPress.

[potatohead]

How to make it bootable? I've just never used a hard disk image on an Apple 2 before.

 

Cider Press will make a new, empty disk. I can tell the emulator where that is, and will check it on my Apple too, once it's created.

 

But, what makes it bootable?

[potatohead]

http://apple2.callapple.org/begin/articles/proboot.html

 

[The Usotsuki]

All a ProDOS disk image needs to be bootable is a standard bootsector - which CiderPress uses - and the PRODOS kernel file.

[potatohead]

Yeah, got it sorted out. Disk boots and the code is on it.

[potatohead]

 

Now editing a lot of broken file types...

[potatohead]

Merlin assembled the (edit) a top level file... which isn't much, but a nice check.

[potatohead]

Learned a bunch of stuff this evening. Got work next week, so I'll just put it here for revisiting later.

 

Merlin has a save function that can write out object code to a file. It also has a "put" function that basically inserts a text file in line. This can be used to centralize equates and such due to the fact that the "put" file just gets assembled as if it were typed right into the file it is put into. Include basically, with the ability to still direct the assembler in various ways while it's happening.

 

Finally, and this is the tough part about this code archive, Merlin offers a way to call a "usr" routine that can be resident in memory and executed on successful assembly of some code. This is used to build PoP onto disks in little pieces all over the place. First move would be to get the disk routines working, and that's real apple territory, IMHO.

 

Spent quite a while looking at those and how the Apple memory is used. There are some funky chunks of code that build 18 sector, copy resistant disks. Those get loaded into memory along with various support routines. A new working disk is bootstrapped with those called from Applesoft, and after assembling or BLOADing other things.

 

There are a set of steps that one did to get the development environment operating basically. That's like "make" today, but manual, not really scripted as much as modular to prevent having to rebuild all. Oh, it took about 5 minutes for some of the files I assembled too.

 

Once all the rights bits are stuffed into memory, other things can be assembled, or moved onto working disks and then those can be run, tested, etc... with assembly happening in "main" memory, for the most part, followed by a call to the "put it on the disk" routines that the assembler would call once it got done, and the cool part there is the labels and such can provide the size values needed, etc... Neat!

 

Given that, it's gonna take real disks on a real Apple to actually build this, unless there are changes. I don't know whether or not a single disk, which is what I have, is possible. I think it probably is. All one needs is a //e to build successfully from what I can see. Might need two disks though. In my case, I've got the CFFA and one 5 1/4 inch drive...

 

From there, various bits are assembled so that they can be loaded into RAM, then moved to where they need to be to run, and Merlin writes them onto the disk where they live. The program is modular in this way, with centralized equates and jump tables used to manage the components and the use of the disk drive. Once a lot of things are built, they stay built. If a level is changed, then only that level file needs to be rewritten. If a control file gets changed, only that file, and perhaps a table or two gets written. There are key locations that the various pieces know about, and jump tables that might need an edit, depending on how big things got, etc...

 

I now understand a lot more about the technical reference JM wrote to the other teams. This is impressive too! Lots of planning and "live" development needed to happen on the Apple way back when, tools to support tools. Given what I read on JM's blog, it's a wonder he got this done without forgetting key things, or just getting bogged down.

 

That archive does include the level editor, which is spiffy! I also see some of the trouble the guys had over at 6502.org. They were not sure how Merlin referenced the different files, and I think they were unaware of the build process. (something I don't really understand very well yet myself)

 

Interestingly, I think a real PoP disk might help! I've yet to go looking for disk images, etc... It's possible to go and compare bits and pieces on the production disk to verify the boot and build process. I do know some things I would want to look for now.

 

In any case, building up a memory map of what lives where would be necessary too. Pretty fun evening! Learned a batch, and it sure was interesting poking around at how really big programs got developed on small machines. Those steps are lost to time and are difficult to piece together now.

[potatohead]

I might need another real disk drive. I've got one. Maybe it can just be drive 2. My version of Merlin is disk based. Not sure how to run it, or set it up for the hard disk. Had some success booting the Apple off it's hard disk, switching to the 80 column display, then just booting off the floppy, which puts the machine right into Merlin where it was able to read and assemble lots of things. That's not optimal though, because I now know I need some time in Applesoft to establish the usr routines needed for Merlin to assemble larger programs and write them to disk as it goes.

[potatohead]

Ok, I just re-read this thread: (slipped in one more session before I get slammed for work next week)

 

http://forum.6502.or...t=2223&start=15

 

Some damn good info in there! I was doing the work to understand the original environment. That work was worth doing, because I got to look at a lot of the code and understand some of what goes where and how, and the important idea of bootstrapping onto some custom disk format. Apple having software disks really is interesting that way.

 

Anyway, there is an example of a boot able disk image there for Apple, and the same technique could be used on Atari. Pieces are all there in that thread and I didn't really grok that until doing this exercise. Now I think I need to get that setup on my hobby machine.

 

http://www.atariage....in-for-eclipse/

 

I'm thinking it makes a lot of sense to setup Apple as a target and get that setup to build the boot able disk example. From there, POP can be bootstrapped onto a standard 16 sector disk, stripped of the 18 sector stuff and dealt with as one big file. A key thing in that thread was the idea of one big file with offsets per disk image! Assemble for target RAM address, store on host disk in file at virtual address, with that address being the actual bytes on the disk! Technically, the product of that boots on a real machine, and that's the test to do with the sample given there. Break that file into the various images required and stuff 'em into the emulator, or write 'em to physical media. I think I get it. Do I? Do tell...

 

(Read that emkay? Of course you didn't. Pity.)

 

Honestly guys, THIS is the kind of stuff that needs to get out there more. Much of that really wasn't clear to me. So as you check in on this mess, and you read this post from me, please feel free to drop some pointers to HOW modern development for these emulators and such is really done. It's helpful.

 

With the machines of the day, one either had a fancy VAX or something that could actually hold a disk image, or it was done hard core with an assembler, building in chunks and writing the tools needed to get "the program" onto media.

 

I'm still going to target an Apple build just because that's the path of least change and one that boot straps the whole thing into a modern environment. Fun to bang around in PRODOS, but sheesh! Stones and chisels. If that sees any real progress, an Atari version can be started far more easily than is the case right now.

 

Edit: Need this piece too: http://www.txbobsc.c...#a5 That's a commented RWTS from DOS 3.3. Needed to replace the one that isn't included with PoP.

[peteym5]

So what is the status on the Atari Prince of Persia port? Going through the posts, seems like no one decided which Antic Modes to use. If I were doing it, I would use Antic 4, possibly SuperIRG alternating between 2 fonts. You can make most of the onscreen stuff like the bricks, floors, background windows, Pillars with sets of graphic characters and just repeat them. Antic4 (graphics 12) does not hog as much RAM. With 2 alternating fonts for the screen and another for text display, all can be done around 4K. Another 2K for PM memory. I would do the animated characters multicolored missiles & players, overlay for 3rd color. 2 Missiles + 2 Players, 10 pixel wide. Not sure what the resolution of the Apple II characters are.

[potatohead]

Well, the Apple has no relocatable / redefinable characters, only 40 byte wide, 7 pixel per byte (yes, fricking 7) bitmap graphics. Artifact colors are the only color the machine has, and the high bit of each byte impacts the colors seen for a 6 color bitmap screen 192 scanlines high.

 

280x192 monochrome, 140x192 color graphics, 2 bits / color.

 

I'm working on assembling the Apple source code, with the intent of enabling a port to Atari using modern tools. Not sure what anyone else is doing.

[+Stephen]

I'm working on assembling the Apple source code, with the intent of enabling a port to Atari using modern tools. Not sure what anyone else is doing.

Discussing ad nauseum in the best Judean People's Front vs. People's Front of Judea style

[MEtalGuy66]

Yeah, Merlin is a pretty nice/full-featured assembler package.. I have it on my IIe hardisk, but I was thinking of making a 3.5" prodos disk for use on my 10mhz IIc+.. cut those assembly times down a bunch.. only bad thing is, Im still stuck with using 5.25" floppies to transfer between the two systems..

[potatohead]

IMHO, it's better to leave Merlin behind, unless you want to code directly on the machine. I don't have it on hard disk, just floppy. How do you do that?

 

In that 6502.org thread above, user "Miles" posted up a bootable disk image example. It's assembly language, and the object code product of the assembly is the disk one boots to run the program. IMHO, doing that gets you onto modern environments where it's possible to be productive. The time I spent tracing back through JM's build environment was highly educational, but not something I would want to do a project on. Stones and chisels compared to what we can use today.

 

Back then, a second machine to quickly boot that floppy was the way to go. Now, it's the build environment that feeds right to emulation. When something real gets done, convert disk image to real floppy, or transfer it via CFFA, ADT, etc... and go run it on the real box.

 

It is good to have a reference Merlin though. Helps to understand what the source code actually did in my case. If I were doing something new, I really wouldn't bother.

[potatohead]

I don't know what assembler user "Miles" was referring to in that 6502.org post. Does anyone? I've been playing with the Eclipse IDE package linked here and have yet to figure out how to implement the directives he was writing about.

 

Hoping this is just me not really understanding what the more popular assemblers really do.

[potatohead]

Update:

 

I've been reading the code, sorting out how things got built, and what connects to what. That's been fruitful. But, the information user Miles gave on how to build directly to a disk image has proven difficult to replicate. It's been quite the rabbit hole!

 

Anyone here have some help? I see how it can be done mapping segments and such, but before I start down that road, I really want to know whether or not any of you are aware of an assembler that can do the following:

 

Build code at one ORG, while writing it to another one above the 64K address space. Say assemble to work at $2000, with object code written to $13000.

 

The assumption here is that a disk is represented as just a long string of bytes in the PC RAM. The code gets assembled directly to it's location on the disk just as it was done on the Apple, the difference being it's a virtual disk image. Saving that image as a binary equals a file that an emulator can boot from directly.

 

Anyone see that capability out there in any 6502 capable assembler you've seen? Do tell. Please and thanks!

 

It's important for me to know if that option is available to me or not because it impacts the work required to build the code significantly, and I don't want to start down that road using clumsy segments and memory models largely intended for bank switching and carts and such only to find out it was there for me, but I missed it somehow.

 

Got a great handle on how it's built now, and I understand a lot about the program. Really needing to vet this piece before jumping in so that time is maximized.