Greets all!

I'll get right to it and write an introduction in the right place after this post:

Will somebody here point me to an assembler for the 8bit 6502 / 65c02 that can assemble code written for a target address in the 64K address space, say $8000, yet place it in a much higher address above 64K, say $150ff, such that if the code were moved to $8000 it would work just fine?

So far, I've seen some assemblers with banks and zones and such and that's all still confusing for me. Perhaps the functionality is there and I just don't know it. Hoping that's the case. A short example for the assembler would be most appreciated!

Hmm - sounds to be a bit like you want to tell the loader to place the code in a high bank, but you plan to execute by relocating first? If so, the question is how to control or direct the loader to do the right thing. The assembler itself - at least, a simple assembler - just gives you a block of binary and doesn't say anything about where to load it.

Maybe one of these threads will help you:
Beginners cc65
CA65 examples?
- or someone who knows a bit more will speak up!

Cheers
Ed

I'm not sure I understand. Do you have an assembler that won't assemble for certain ranges of memory? They should all be able to do it anywhere in the 16-bit adress range, and if you want to change the program's addresses, changing an ORG directive should be all it takes. There are linkers too, but even though I used one 20+years ago, I would have to admit I still don't really know what it does.

As far as banks go, that's something the 65816 has with its 24-bit address range. Each 64K is called a bank, for example $03:0000-03:FFFF. The 6502 doesn't have that.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Actually, I want an assembler that can assemble 6502 / 65c02 code at any ORG, even when that ORG is outside the 64K address space.

Say the target address space is 128K, $0 - $1fff. I want to be able to assemble in place throughout that range, even though the 6502 can't execute code above $FFFF. And my basic problem is not understanding the various assembler directives enough to know whether or not a given assembler will do this, and secondly how specifically it is done.

I was hoping somebody here might be able to save me some time with one or both of those. Knowing an assembler can do that at all is a huge bonus, in that it leaves me with just the how specifically part of things. Both gets me started building 6502 code!

[edited]

So there would be an ORG, which tells the assembler what the executable address is. Say that's $8000. And there would be another directive that tells the assembler where the object code gets placed, say that's $13000.

Ideally, the output is just a file, 128K in size with either zeroes, or code depending on what got assembled and where it was assembled.

Say that file is placed on EEPROM, or SD CARD, etc... that's my initial goal right there.

ca65 can do that. You can specify the segments in the config file to the linker (ld65). Here's the documentation for the config files. If you're used to linker scripts, this will look familiar. If not, better get your climbing gear for the learning curve

Crap, I made an edit to my post... That won't follow well for others.

Thanks Arlet. I was really hoping to avoid that mess. I'm looking at it now. Can that kind of thing work with a large assembly file?

What I'm attempting to do is just factor hardware out of the equation and use the assembler to write out a usable binary image directly, rather than build in lots of pieces, etc...

Edit: Looks promising. So, the idea is define segments, their attributes, specify them when assembling, then put them in output files, then combine all of those for the image I'm looking for?

(scratch that)

I am going to work with this for a while. Thanks. The gist of it is that I have to define memory areas, and then I can get the assembler to output files, which can be combined. Good enough to start with. Much appreciated.

Most assemblers won't do that, because their authors consider that an error, because such code has no hope of executing. That's not just for the 6502 family - very few assemblers will, without tricks, allow you to assemble code outside the processor address space.

Perhaps a different approach is to ask what the problem you're really trying to solve is. AFAICT, you want to assemble POP as one big file. That in itself is not really a difficulty these days. Does the problem arise from the size of the result? In other words, what to do with it once you've got it?

It sounds like you want to put the result in a memory space outside the normal 6502 range. All right, go ahead and do that by whatever means. But you should stop thinking of what you're doing as moving code around so much as moving data around. Since 6502 code stored outside of its address range won't execute, that's all it really is - data. There's no particular reason to want to "assemble" it for whatever address it will be loaded/stored at. Just tell the OS - or write whatever custom loader you want - to put it there.

In other words, go ahead and write it for its execution address, go ahead and load it to its storage address. Just remember you're going to have to have some scheme to bring the "data" to its execution address before you can use it as "code".

Yes, I do want a means to build PoP, and the one file option is attractive, but not required as I can see now.

Really, part of the attraction of the method is being able to assemble directly to an image, whatever image and that has uses beyond PoP, so it intrigued me.

One way where this has broken down is the whole "code as data" idea. I get linking and why it's important, etc... but I also see significant value in being able to disconnect the address code gets written to, from the address it's being built for. The original PoP was built in whatever memory space was available, then written to the storage device right in the middle of assembly. In a sense, that source code is instructions for how to build "the program", which was larger than 64K and that existed on a disk, sans file system support.

Essentially, "assemble to image" a concept I'm thinking has value.

In any case, I did get some info to move forward. I've been reading the PoP code and have a pretty good handle on how it got done then. Very interesting exercise so far!

In the case of PoP, the idea of "code as data" makes perfect sense. Back then, it got assembled in the address space, because that was the only option. Back then, the assembler had options for user code to be executed based on successful assembly too, and in PoP that user code would then write the finished block of code to a track and sector of the disk directly, no filenames, etc...

Of course that brings me to another question: What exactly did Miles use, or were those fiction or representative examples? (and that links both threads together now... drat!)

Oh, and if there are tricks, what tricks?

Can't you just assemble it like any other bit of code, then write a simple program to convert the assembled data into a bunch of .BYTE statements (or whatever), then include that file in to your master at any point you want.

As others have said, what you really want is some kind of configurable loader/linker. But this scheme is simple enough to be hacked together readily, and it's all easily automated via scripting (mind I have no idea what dev environment you're using).

Ok, yes. I see I can do variations on that now.

I just spent the day peering at every single 6502 related cross assembler I could find. There are quite a number of them!

None do what Miles put here. None. So, now I'm curious. Was that fiction, his own creation, or what?

What I want is an assembler that can simply put 6502 code into a binary image directly. What he outlined made me understand what needed to happen. It's that clear, and of course that compelling now. And there isn't any technical reason why that can't happen either. All that is needed is a program counter for the code, and a second one for where the code is going. This isn't a big deal, yet every assembler I found wanted to use all sorts of convoluted means and methods for representing larger programs. Weird.

I found that ca65, and others can build the code with a fair amount of juggling segments, banks, etc... and I think those tools are needed and excellent for bank switch / cartridge / ROM based storage schemes too. They are not so good for making a disk image without also writing other tools, or at the least scripts, etc...

The original author assembled in Apple RAM, chunk by chunk, then wrote those chunks out to disk sectors, thus building the "executable." Stuff it into an Apple, power up and see what it does.

It was done that way then, because the computer needed to hold the development tools and code, and Merlin allowed the programmer to call a user routine on successful assembly, which was used to unload the code after it's built. The tools I saw today kind of continue that idea and they have many different representations of it with banks, segments, etc...

So I get it. Those things can be used to do this, and I'm inclined to start laying out a map of segments that equals a disk, then go through all the code and get that sorted. And for targeting many real hardware systems it makes sense to do that.

...but, it also makes one hell of a lot of sense to just assemble a disk image instead of a bunch of object chunks that then need to be combined into a disk image too. One layer of abstractions goes away, and that's compelling.

All that said, my curiosity is piqued now. I really want to know whether or not that was fiction now. Makes a lot of sense, yet doesn't seem to be out there anywhere. That's hard to let go.

The thing is, a cross assembler is not writing it's output (the code) to memory - it's writing to a file. A sophisticated toolchain writes to a file which is not the final file, because linking is usefully made a separate step. Loading is not even part of the story, but the final file does need to be loaded, and the loader will need both an address to place the binary and a start address to jump to. If you're making a system ROM, both of those are implicit, but if you will be loading using something like S-records, it's explicit.

The model you're thinking of is something like the model in the BBC Micro's native assembler: there's the P% value which is the virtual program counter during assembly, and the O% value which is the destination address for the bytes. It's possible to assemble for say 0x8000 final destination but place the bytes at say 0x4000 - to be saved to file or copied to the destination later. While the BBC Micro only had 32k RAM, there may be platforms with more than 16bits of address which will run the 6502 assembler - John Kortink's for example (he has a patched BBC BASIC running on a 65816 - but I don't know if the assembler allows an O% to point outside Bank 0)

Hope this helps
Ed

Maybe I'm not following, but M.Kowalski's assembler does this. You type in your assembly, assemble it, then do a 'Save code'. You then choose from intel HEX, Motorola s-record, binary image, or binary program. Then under options, you set the beginning and end and length. For a pure binary image, with no header, it uses .65b extension. I renamed it to .bin for other programs to recognize the image, like an eeprom programmer or a .coe file converter for programming FPGAs.

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

Well as I understand it, and I have not been following this too closely, one of the issues with PoP is simply that he has overlay code stored at different parts of the disk, and that the disk is just a group sectors, rather than an actual file system. The simple fact when complete, the PoP build will be a disk image, not necessarily a runtime file. So, whatever the build process involves, it's likely more than simply an assembler, and may well involve custom tools to place the assorted binary images in their respective locations at Sectors 123, 234, and 345. I think a disk map is necessary, then it should be straightforward to create such an image from component pieces, and simply treat each piece as an isolated binary.

@Electric_Eye: Can you link me to, or write up a rough example?

Something really simple, like one or two instructions set to run at a 64K friendly address, say $2000, but assembled to $13000 and saved. It doesn't need to be complete, just that one capability highlighted would be great!

@All: Thank you for entertaining me. To be very clear, I mean no bad toward Miles. I am just very interested in understanding what tool was used, if one was used at all. Laying out disk images as linear RAM is very compelling for this project because a number of things to manage goes away, "assemble to disk image" essentially. When it comes time to sort out the tracks, sectors and such the program needs to fetch, having that done will make things a lot easier.