@whartung: I've no intention of building on the //e To be honest, that's brutal. I have explored the code on the //e to learn how things were done then, and doing that helped to understand how the thing works on basic levels, and it will prove to be a reference later on too.

The plan is to build on PC, with the output being a bootable disk image. Said image can be fed into an emulator, or transferred to real media for use on a real Apple //e. Right now, I plan standard DOS 3.3 16 sector RWTS. That could change.

That's for my own purposes. I think it's worth doing. Once done, it may enable a port to other machines. That's a long way off right now.

@Tempest

Well, with all due respect, I did misunderstand what you wrote. No save operation needed, just build stuff in order and get the desired file. I get it, and it's on the list of options I may pursue. As I mentioned earlier, I do not mean to be difficult, but I also do mean to understand the scope of capability before selecting an option.

This means actually pressing around a little to see what does what, regardless of whether or not "most programmers" find the feature sets useful or not. Frankly, given the nature of the project, looking at something differently, or out of the mainstream however one puts that nicely, makes a fair amount of sense. You may well play it differently, and that's just fine, right? I think so.

If I were to have had a significant investment in one assembler or other, I may be inclined to lean your way on things, but that's not the case, but for a fair amount of programming in MAC/65 years ago. (I liked that one, BTW --still have it on cart)

From what I can tell, there is an ideological difference in play, and I find that interesting! In other assembly language contexts, I've not found how one represents storage to be such an issue.

Not judging here either. Just communicating what I've experienced so far, and I'll add that how things are represented can impact a person considerably, meaning it's a totally fair question. I asked it accordingly. Also, as far as I can tell so far, I get to do that. It's worth noting that at least one programmer understood what I'm asking for and why, even mentioning they requested it for an assembler they use frequently. Clearly, I'm not that far off the farm, though the project clearly is.

So then, I've been told MADS will do what I'm wanting to do, CC65 does too, as65 has some support coded in not tested, and that ACME is capable as well, though I'm also told syntax may be at issue there. DASM "may" do it as well. (A comment or two from elsewhere, brought here.)

You've (Tempest) also told me it can also be done sequentially keeping the PC "in bounds", simply allowing output to accumulate until it's complete, at which point it's written out accordingly. Great! Thanks. Honestly, there may be significant advantages to doing that. Again, thanks. I don't know yet.

This is good info for me. One barrier I had was sorting through the many tools. I now have a short list to explore and I really appreciate it. Thanks all. More later as I proceed on this.

@All: Once again, I do not mean to be difficult. If I ask tough questions, or maybe better put "odd" ones, know I'm just learning as I always do and have, likely no different from any of you, save for the fact that you all have way more time invested than I do. And of course, that leads to precisely the kinds of questions I asked. Know that I will return the favor when I am in a position to do so. (Ask me some Propeller related thing, for example.)

Cheers!

JMO, as long as you keep your thread updated, I would think the postings on your quest are appreciated!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

As far as I understand it, the problem is simply an overlay problem.

There is a section of the code base that has multiple chunks of code that needs to be loaded over into it.

Let's say, for the sake of discussion, that there's a 8K block of RAM that holds logic for the current level of the game. And that there's 10 levels (I'm making these numbers up out of whole cloth). That means that there needs to be "80K" of code, in 8K blocks, all assembled so they can be loaded to the same location. When the "level changes", the disk is hit and the code is for the appropriate level is loaded in to the shared block and then executed.

This code is store on the disk, but it is not store individual files, rather each chunk is allocated to some starting sector on the disk and loaded from there.

Now, back in the day, for MASM, and C, on MS-DOS, and MAYBE CP/M, there were overlay linkers and loaders that would assemble the objects files of your project in to a construct that could handle this overlay process automatically. But I doubt any of them, out of the box, worked off of raw sector reads, but instead relied upon the underly OS to read the files and load them in RAM.

The "RWTS" code cited is "primitive" sector loading code, not file system aware code. That tells me this build process is specialized. But a PC with just random tools should be assemble what you need. You can add filler blocks to your binary output to ensure the proper sizes of the final images, and then simply concatenate them together in to a final image that should match your disk.


Finally, will your system even WORK on a 16 sector disk, since it required 18 sectors (and the implied extra storage of 18 sectors).

I don't have a "system" yet. That's what the feature / function discussion is all about.

Yes, Merlin used a DOS for everything but the output to the disk, which was done on the 18 sector RWTS.

Re: 16 sector. There isn't as much space. Right now, two sides are required at 18 sectors. This will require analysis to determine what savings can happen / needs to happen.

But is it missing? There's code in /02 POP Disk Routines/RW1835/ written by Roland Gustafsson, the guy behind Broderbund's 18-sector RWTS software. And in /04 Support/MakeDisk/ there's more code, files like INSTALL18.S, FORMAT18.S, USR18.S, all written by RG. I just had a very brief look (two minutes), but it looks like it's as low level as necessary.

EDIT: Ok there seems to be references to a function 'rw18' which is maybe not there.. that's the one missing?
EDIT2: On the other hand RW1835.S and RW1835.POP.S (the //e variant) have RW18 (in capitals so I missed it). That looks very sector-handling like to me.

I've learned a lot by this thread btw - I wasn't aware of how PoP was built and exectuted, now I've got a pretty good overview.

-Tor

I tried the following in my assembler and it seems to work. The source defines common data areas on zero page and page two then creates code for the main memory at $C000 and two overlays at $2000.

You assemble this with the command

Whic produces

You can then run the linker three times to create binary images of each code region into a seperate file.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

@Bitwise: Which assembler is that? as65?

@Tor: I saw that code too. You might be right about it. If somebody wants to attempt the Apple native build... I setup with Merlin in D1, a PRODOS hard disk to hold the code, and D2 is the drive used to hold the finished program. I only have one drive, and would have moved Merlin to the hard disk, but I realized I was not going to build there, just use it as a reference.

Perhaps that set of code was not there when the original thread was started, or the people then just missed it. Who knows?

Its my portable assembler As65 - its coded in Java so it will run on most modern platforms.
http://www.obelisk.demon.co.uk/dev65/index.html
It supports the 6501, 6502, 65C02, 65SC02 and 65816 (plus the never made 65832) with relocatable code, macros and built in structured programming.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

The /04 Support/ directory (with the 'MakeDisk' directory) was not there originally, but the /02 POP Disk Routines/RW1835/ directory (with rw18 aka RW18) was there from the start.

-Tor

Well then it was likely just missed. To build that on anything but a real Apple would require a real disk drive emulation. There is a small demo program there that will load a picture. One could build up the core routines, init a disk and give it a shot. I'll pass, but it's good to know anyway.

I have spent some time looking at the https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/master/02%20POP%20Disk%20Routines/RW1835/POPBOOT35.S and https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/master/02%20POP%20Disk%20Routines/RW1835/RW1835.POP.S source files.

I think the two together do provide all of the code necessary to boot Prince of Persia up from 3.5" disks. The 3.5" disk contains a standard ProDOS file system in the first 16 blocks of the disk. The ProDOS file system contains one file in the root directory, the PRODOS system file, which is loaded at boot into page $20. On the Prince of Persia disk, this PRODOS file actually contains the object code for POPBOOT35.S and RW1835.POP.S. POPBOOT35 will move the RW1835.POP object code following it up to its final destination of $D0 page, loads HIRES.S and MASTER.S object code into memory starting at page $EE, and then jumps to the game code entry point at $EE00.

Welcome aboard, Adam, and thanks for that information.
Cheers
Ed

Hi Adam,

I agree with you. Tor got me to look at it all again. IMHO, the simplest build would be the demo spinning cube program.

The USR routine for Merlin is there too. A complete Apple native build is possible, assuming one has a real floppy drive.

An update: I've studied DOS and have been working on a map of what is where on the PoP disk. I was not successful in finding an assembler that would "build to disk" without mapping segments, etc... then linking. Oh well.

It can be done that way, and so I'm proceeding with a modern tool build. Not optimal though. And maybe Miles will show up and let us all know what tool chain he used. That is the optimal approach IMHO.

BigEd, thanks for the welcome.

potatohead, I spent some time a few weeks ago mapping out the contents of the PoP disk. I will try to clean up my notes and post them later today. They might be of some help.

I should also have mentioned that on the 3.5" disk, the included RW18 routines do nothing more than map the multiple sided 18 sectors per track format used by the Prince of Persia code to the blocks exposed by Apple's SmartPort API. There is no real special formatting utilized...just a simple mapping layer since a 3.5" disk has more room than that required for all of PoP's data and code.

I don't know how useful it is but here it is anyway, a link to my Prince of Persia 3.5" disk layout notes: https://github.com/adamgreen/Prince-of-Persia-Apple-II/blob/working/Notes/pop-disklayout.creole