This is a topic i didn't really found being discussed a lot on here (or i'm blind), which i think is a shame because the concept is cool and PIC (= Position Independent Code) is pretty much required for something like a Multitasking OS on a system without true Virtual Memory.

So lets's talk about it!
I would say there are 2 flavors of PIC on the 65816, and i'm just just gonna make up some names for them.

"Bank Aligned" and "Bank Confined"

"Bank Aligned" Programs are the easiest to write, it's almost exactly like writing a program for the 65c02 where you only care about 16-bit addresses. so you simply ignore and never touch the Data/Program Bank Registers and only use long addressing modes for known/hardwired locations (like IO or ROM).
and since the program is compiled/assembled to be placed at some specific 16-bit address it won't care about the upper 8-bits so you can place the code/data in whatever banks you want.
that's why i called it "Bank Aligned" since the program/data can be moved around in memory but only in steps of 64kB.

"Bank Confined" is a bit more difficult, it means the program can be placed ANYWHERE within memory as long as it doesn't cross a bank boundary (that's why it's "Confined"). while with "Bank Aligned" programs you only had to keep away from long addressing modes, now you also have to do the same for absolute addressing modes... well not entirely but you have to get a bit more creative when using them.

for example, instead of JMP you can use BRL which has the same 16-bit range as JMP but is relative and therefore relocatable. replacing JSR requires a bit more effort though. i made this ca65 macro that implements a 16-bit relative version of JSR (called BSR like from the 65ce02):

So having your program flow relocatable is pretty straightforward. the more difficult part is the data.
If the program cannot know the exact location of where it's data is, then how can it function at all?

Assuming that all data for the program was loaded into Memory as a single monolithic chunk (or segment), then program CAN know where data is located within that chunk as long as it knows what the base address is.
and that is easy to do, the loader (or OS) just has to set the data bank, and pass the 16-bit base address of the data segment/chunk to the program as an input parameter.
the program can then use that base address with indirect or absolute indexed addressing modes to access the data. this still needs a bit of thinking when writing programs as you can no longer just use plain absolute addressing like LDA $1060 as you have to somehow add the Base Address to that, which is surprisingly simple thanks to the 16-bit index registers.
assuming the 16-bit Base Address of the data segment is in Y, you can just do LDA $1060,Y in this case.
when you want to sweep across a section of data you have to either modify the index register with the base address in it, or use indirect addressing.

Overall i'd say the advantage of Bank Confined is that really small programs can easily be put into the same banks without issue. While with Bank Aligned every program, no matter the size, will always take up a whole bank. the main downside is the additional overhead of the more complicated data accessing.
And in terms of an OS having to keep track of used/free memory, this means with Bank Confined you can choose a much smaller "virtual bank" size, like 4kB for example, to try and squeeze more active programs into memory than Bank Aligned could.

this also reminds me that i kinda want to ask the Calypsi C dev to add support for PIC, i'll probably do that later while also coming up with some basic PIC executable format.

so, any thoughts or tips&tricks on writing or dealing with PIC? i'd be interested to see what others think of this.

BSR and BSL would have been highly desirable CMOS 65xx additions, IMO. But I have never written any P.I. code, or any code that approaches the 64KB limit. The 6809 designers had P.I. code directly in mind when they designed it, but it's big-endian, so

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

the name was probably poorly choosen but i don't mean that the program HAS to start aligned with a bank boundary, just that it has to be placed at a specific address within any bank, like $8000, $1700, etc.


yes i'd thought it would make sense to use seperate banks for code and data (+bss) to allow for larger programs without having the program itself split between multiple banks. the Kernel could for example count the amount of useable memory banks and then use the first half for code, and the second half for data.


well my SBC has IO in Bank 0 and the main ROM in Bank 1, plus i plan on putting the Kernel code in Bank 1 as well...
hmm i might move IO to Bank 1, which would also free up some RAM space in Bank 0, increasing the total amount to 63.75kB.

also i would still have to use long addressing modes when accessing IO since the Data Bank is set to wherever the calling process is located. and cahnging it would be slower than just using long addressing, even when moving large chunks of data as you likely have to move them from or to the Process' Data chunk anyways so might as well leave the Data Bank there and just use long addressing for IO.
So i don't think there is an easy way around the long addressing penalty without making it even slower by messing with the Data Bank Register.


now you got me curious, how would you define an Insane Memory Map?
anyways, my idea for DP and the Stack is rather simple. each process gets assigned it's own DP somewhere in the first 4kB of RAM (which is enough for 14 processes + 2 for the Kernel). and the remaining ~60kB get split into 4kB chunks for the stacks (enough for 14 processes + ~1 for the Kernel).
4kB of Stack should be plenty even for C Programs if they're smart about passing parameters (ie using pointers for large structs and such)


yes, API calls through COP or BRK seem like the best option, i remember there being a thread about API calls and such: viewtopic.php?f=2&t=5434
i'll give it a thorough read later.


i'm a bit confused, why would there be a speed benifit from having the data in the same bank as the code? they use seperate Bank Registers so you can place static (or even bss) data in a different bank and still be able to use 16-bit addresses to access it.
also i would say only the kernel should be allowed to change the program/data bank registers, with processes never touching either register (except reading them out maybe using PHB/PHK).
but i do like the idea of being able to use PER.


honestly i would try to keep things simple and avoid having to deal with multiple banks of data. If bss and static data don't fit into 1 bank, the program will simply not be loaded and just throw an error. same with code size.

if both code and data can occupy multiple banks then, like you said, you run into the issue of accessing it. the process cannot know where they are located due to potential memory fragmentation. the other banks could be sitting anywhere in memory and only the kernel would know where.
so when a process wants to access data from outside the current data bank there would need to be an API Call to ask the kernel to either change the Data Bank Register (and in addition return a 16-bit pointer), or to return a full 24-bit pointer to where the data is located.
either way it sounds like a pain so i won't be dealing with that for the time being.


I've been getting used to the 65816 pretty well actually. you have to rethink a bunch of stuff but i still think it has the same "6502 feel" to it.
I'll give that link a read, thanks!

I have written one 6809 program using PIC and it was no walk in the park, piece of cake or bed of roses.

That program is the resident part of a system extension to add command recall, aka history, to FLEX. The 6800 and 6502 versions use a relocation bitmap similar to how MOVCPM worked on an 8080 - assemble the code at two addresses a multiple of 256 bytes apart; the bytes which differed needed to be adjusted to relocate the code. But the code can only be placed at addresses differing from the original location by entire pages.

I thought that PIC would allow me to put the code anywhere and not waste up to a page of memory. It did, but one programming idiom was not easy to implement.

In absolute 6800 code, I can write:

to compare register X with the address of the end of a data structure.

In PIC 6809 code I cannot write:


I can write:

to load the address into a register, but I cannot easily compare it with another register. I had to push it onto the stack and compare it there:

which is substantially larger and slower.

If only Motorola had given me four "compare effective address" instructions: ceax, ceay, ceau and ceas...

That doesn't seem so bad - you found an idiom which works and you could wrap it in a macro.

Back to the '816, I think we put I/O up in bank FF for the beeb816. These things might cost a few cycles or a few bytes, but that's really no big deal: we're no longer talking about an 8k machine running at 1MHz.

The initial intended target of the 6809 version of the program is a Peripheral Technologies PT69-5 single board computer.

It is based on a 6809 processor running at 2 MHz. Unlike the 6502, evolution of the 6809 stopped when Motorola moved on to bigger things, the 680x0 family. FLEX on a 6809 officially supports up to 56 KBytes of RAM. I specifically chose to target the PT69-5 because it has an additional 4 KBytes, much of which is otherwise unused; my code and the history buffer resides there so that the amount of memory available for program use remained the same.

Instead of that push and compare sequence in my last post, I ended up doing the load effective address and storing the result in a variable during program initialization then comparing pointers against that later - much smaller and faster. The point is that position independent code on the 6809 does not come free though it is easier than on most other architectures.

Maybe Motorola moved on, but there's definitely some further-evolved 6809 DNA out there. Back in the day, Hitachi out-6809ed Motorola by an embarrassing margin with their backward compatible 6309. "To the 6809 specifications, it adds higher clock rates, enhanced features, new instructions, and additional registers. Most of the new instructions were added to support the additional registers, as well as up to 32-bit math, hardware division, bit manipulations, and block transfers."

Also noteworthy are the MC9S12 and HCS12 series. These guys have "only" three stackpointer/index regs (U got turfed) but otherwise seem very 6809-like. Unfortunately this resemblance includes the 6809's very high prevalence of dead cycles, but on the plus side the MC9S12 and HCS12 are in current production by NXP and presumably clock a great deal faster.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just for completeness, you can run multiple programs when you are able to relocate code at load time.

I think I still have to learn a lot about the 816 regarding bank management.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Tiny contribution, i have created a Macro to implement a Relative version of an Indirect JSR Instruction.
It's horrible and slow but it seems to work, so might as well share it!



The Jump Table is expected to be relative to the "base address". what that address is has to be choosen at assemble-time. assuming all code is in one big chunk, you can set the base address to be any label or address from your program. I just set it to the address of the first function located in the table. this also makes the first word in the table always $0000.

example:


where the table is located doesn't matter as long as it's in the program bank, same with where the functions are located relative to the table.

maybe someone can make use of this, or improve it.
i'll probably be using this in my current programming project:

an 8080 Emulator for the 65816 that is fully relocatable! the idea comes from the CP/M-65 topics on here recently that made me want to try and run CP/M on a 65816 but still have it able to run original 8080 programs.

so i might use this for Instruction decoding as currently i'm just masking bits and decrementing them to seperate the program flow (like a switch statement or if, else if, else if, else if, ...)
and should hopefully make it more readable!

Thank you for defining the terminology bank aligned and bank confined. For my use case, I would like to make a 65816 desktop where applications execute from $xx2000 and possibly re-locate downward within one 64KB bank. However, there is one miscellaneous case where plinky little desktop toys, such as perpetual calendar and volume control, can all share one bank. It is possible to write them all as one statically linked bundle. Contiki does this for all applications to avoid any of the complexity of platform specific pre-emptive multi-tasking. Likewise, FLEX and C64OS make the distinction between application and utility.

There is definitely a case for sharing one memory segment and I wonder if restricted cases are sufficiently useful. For example, in my case, none of the utilities are performance critical. Nor do they require highly variable amounts of memory. Therefore, is it sufficient to restrict all utilities to one bank and insist that they are all written with the same memory allocator or written in the same language? In a single-threaded, co-operative multi-tasking environment, where performance is not critical, BASIC in a shared heap may be sufficient. I believe that many RiscOS applications work in this manner. This solves the problem with a level of indirection (mandated interpreter) and won't cover all cases. However, it may be sufficiently general for common cases such that the remaining awkward cases require a greatly reduced number of banks.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!