First steps...

[cr1901]

Preliminary Address Space...
Range Banks Purpose
0000-0FFF 0 Zero Page, OS stack space
0000-0FFF 1-FF Application stack space
1000-1FFF 0 OS kernel buffers
2000-2FFF 0 OS kernel system calls
1000-2FFF 1-FF Application RAM
3000-DFFF 0-FF OS/Application RAM
E000-EFFF Shared I/O Space
F000-F7FF Shared Shared ROM, Bank switch routines (For Position-Independent application bank allocation/code jumping*)
F800-FFDF 0-FF Generic ROM
FFE0-FFFF 0 Vector Table
FFE0-FFFF 1-FF Generic ROM


"Shared" means that portion of the address space is mirrored in all banks (one copy). Otherwise, assume each bank has a unique copy of that portion of the address space reserved for the described purpose.

This is meant to be forwards-compatible. No chance in hell I'm implementing a full OS now. Only bank 0 and 1 are meaningful for now... the latter just for a checkerboard test, as BDD suggested, to test my bank logic. *But if anyone knows how create a bank-independent program loader and bank-independent '816 applications, I'm all ears. When we get to this point, I'll probably use a 7400-series MMU for virtual memory.

[BigDumbDinosaur]

cr1901 wrote:

Preliminary Address Space...

Code: Select all

  Range    Banks    Purpose
0000-0FFF  0        Zero Page, OS stack space
0000-0FFF  1-FF     Application stack space
1000-1FFF  0        OS kernel buffers
2000-2FFF  0        OS kernel system calls
1000-2FFF  1-FF     Application RAM
3000-DFFF  0-FF     OS/Application RAM
E000-EFFF  Shared   I/O Space
F000-F7FF  Shared   Shared ROM, Bank switch routines (For Position-Independent application bank allocation/code jumping*)
F800-FFDF  0-FF     Generic ROM
FFE0-FFFF  0        Vector Table
FFE0-FFFF  1-FF     Generic ROM

"Shared" means that portion of the address space is mirrored in all banks (one copy). Otherwise, assume each bank has a unique copy of that portion of the address space reserved for the described purpose.

Just my curmudgeonly opinion, but it's much too complicated. You're "micromanaging" memory allocation and will pay for it in complex (i.e., slow) glue logic. If you're going to go to that much trouble then you might as well apportion all RAM into pages (not 65xx pages) and set up hardware memory protection.

Quote:

Code: Select all

0000-0FFF  1-FF     Application stack space

4KB is a lot of stack space, probably much more than you'll likely need. Also, what about the application's direct page?

Mirroring ROM in every bank will prevent you from treating RAM above $00FFFF as flat space. While programs officially can't overlap banks, data certainly can, as indexing will span from one bank to the next. So I wouldn't be inclined to throw away that possibility.

Also, if you decide you want to run this system at 20 MHz, you are going to have to wait-state ROM accesses. That will add to the complication of ROM being in every bank.

Quote:

This is meant to be forwards-compatible. No chance in hell I'm implementing a full OS now. Only bank 0 and 1 are meaningful for now... the latter just for a checkerboard test, as BDD suggested, to test my bank logic. *But if anyone knows how create a bank-independent program loader and bank-independent '816 applications, I'm all ears.

Bank-independent applications? You already have that. If you load a program at $xx1000, for example (where $xx is any bank), it will run regardless of what $xx is. Relative branches, JMPs and JSRs are bounded by the bank in PB. Only JML and JSL can take you out of a bank, and I don't recommend their use in the ordinary course of events. I recommend that OS calls be via software interrupts so applications don't have to know about specific addresses.

Quote:

When we get to this point, I'll probably use a 7400-series MMU for virtual memory.

I don't want to sound negative or discouraging, but exactly what 7400-series MMU would you use that could stay with the 65C816 at any speed above a couple of MHz? Are you thinking about the 74LS610? This sounds like a job for programmable logic.

[GARTHWILSON]

If you use wire-wrap or programmable logic so it's not too big a deal to change things after the bulk of the project is built up, it should give more flexibility than a PC board and 74-family logic would. (Remember there are PLCC sockets, even for WW.) Some things you may just have to learn from experience; but do try to avoid painting yourself into corners such that a change of mind requires starting over. Actually, on early projects, ideas seem to develop faster than you can build, which has a tendency of keeping one from finishing anything; so I recommend starting simple but with the possibility of expansion left open.

I would encourage leaving at least some banks as contiguous, free RAM for large data arrays so you don't have the pain of dealing with interruptions in such arrays. If you need a lot of RAM, it will probably be for data, not so much for program space. You'll give yourself a lot more freedom if you don't commit to chopping up RAM in a particular inflexible way.

[cr1901]

BigDumbDinosaur wrote:

Just my curmudgeonly opinion, but it's much too complicated. You're "micromanaging" memory allocation and will pay for it in complex (i.e., slow) glue logic. If you're going to go to that much trouble then you might as well apportion all RAM into pages (not 65xx pages) and set up hardware memory protection.

I'll scale it back for now... again, I was just trying to encourage forwards compatibility. That being said, I'll respond to each of your points because I need to clarify what I was saying .

BigDumbDinosaur wrote:

4KB is a lot of stack space, probably much more than you'll likely need. Also, what about the application's direct page?

The stack is meant for multiple tasks running independently with support from a small kernel. I thought the direct page was limited to bank 0, so the OS will need to share it's direct page with multiple tasks, switching the DP register as necessary.

BigDumbDinosaur wrote:

Mirroring ROM in every bank will prevent you from treating RAM above $00FFFF as flat space. While programs officially can't overlap banks, data certainly can, as indexing will span from one bank to the next. So I wouldn't be inclined to throw away that possibility.

... Oh... yea... I forgot about that tiny little detail. But doesn't mirroring the I/O space introduce the same problem?

BigDumbDinosaur wrote:

Also, if you decide you want to run this system at 20 MHz, you are going to have to wait-state ROM accesses. That will add to the complication of ROM being in every bank.

Can you please clarify what you mean? I intended to place all the ROM banks into a single ROM, where each bank is allocated a different 8kB in the physical ROM.

BigDumbDinosaur wrote:

Bank-independent applications? You already have that. If you load a program at $xx1000, for example (where $xx is any bank), it will run regardless of what $xx is. Relative branches, JMPs and JSRs are bounded by the bank in PB. Only JML and JSL can take you out of a bank, and I don't recommend their use in the ordinary course of events. I recommend that OS calls be via software interrupts so applications don't have to know about specific addresses.

I failed to imply this, but yes, I would do something similar to what you mention, presumably using the BRK instruction, since COP seems more apt for, well, a coprocessor . Best part is that it automatically puts me back into bank 0.

Then HOW do you handle the case where a task/application requires more than 64kB of code in a manner where the application doesn't care which banks to which its code segments are loaded? Using an already-existing EXE format isn't a problem for me (when we get to this point), but I have trouble visualizing how to load programs > 64kB in a position-independent manner.

BigDumbDinosaur wrote:

I don't sound negative or discouraging, but exactly what 7400-series MMU would you use that could stay with the 65C816 at any speed above a couple of MHz? Are you thinking about the 74LS610? This sounds like a job for programmable logic.

Yes, that was the chip I was thinking of. I was under the impression that IC was still available in HC form. Back to the drawing board.

Again, this was all for future use. But I'll tone it back for starting out.

[cr1901]

GARTHWILSON wrote:

If you need a lot of RAM, it will probably be for data, not so much for program space. You'll give yourself a lot more freedom if you don't commit to chopping up RAM in a particular inflexible way.

I'll ask the same things I asked BDD: what about I/O being mirrored throughout each bank? As opposed to using a single bank for I/O. Or perhaps you're implying to split up code and data as much as possible without going full Harvard Architecture, and make the most-accessed banks have access to the mirrored address spaces.

And how do I handle the case where a program has > 64kB of code without hardcoding bank numbers? Perhaps I could implement that as an OS service to "switch banks", instead of using the JSL/JML instructions directly in application/task code.

GARTHWILSON wrote:

Actually, on early projects, ideas seem to develop faster than you can build, which has a tendency of keeping one from finishing anything; so I recommend starting simple but with the possibility of expansion left open.

"The ideas develop faster" is quite the understatement. Really, right now, I'll probably end up with a '816, VIA, VIA's timers, ACIA (presumably accessed through the VIA), SRAM in banks 0 and 1 (to test the bank logic), and EPROM in bank 0 to hold bank switch code (to avoid liberal use of JSL/JML... this isn't SNES code ) and helper routine.

So what's left is:

• reset circuit
• clock circuit
• power supply (I'll probably cheat and use a bench supply for now)
• three TTL chips

For the three TTL chips- one TTL latch to hold the bank, one TTL bidirectional hiz transceiver to attach/detach the '816 from the data bus, and one TTL chip to expand the VIA's I/O capabilities. Garth, I seem to recall you mentioning that the VIA can support more I/O devices with simple glue logic, but the post where you mention this escapes me. Do you know by any chance what I am referring to?

[GARTHWILSON]

cr1901 wrote:

what about I/O being mirrored throughout each bank?

I wouldn't do it. I won't pretend to know your envisioned application, but for myself, I would really want to be able to have arrays that are more than 64K long--even megabytes long--without requiring that the software watch for boundaries to jump over in places.

Quote:

Or perhaps you're implying to split up code and data as much as possible without going full Harvard Architecture, and make the most-accessed banks have access to the mirrored address spaces.

The direct page is always in bank 0, while the data bank can be something else, and a program can have its own direct page and its own data bank which may or may not match the program bank. I'm no expert on OSs though. I can say that one of the biggest projects I worked on was about 10,000 lines of 65c02 assembly-language source code, in 1987-89. I think it took about 24KB of memory. I could do a much better job today, much more quickly and using a lot less memory. At the beginning of the project, there was another engineer working with me who seemed to type an awful lot, and I wondered what he could be typing without taking time to think things through. Soon after he left the company, I got my answer. The boss asked me to change how a particular routine worked, one that the other man had written. I had to dig into it and figure it out. This one was four pages. I ended up re-writing it, got it down to half a page, and it did more, with less memory, and incorporated the desired changes. It was like reducing an equation to lowest terms, using subroutines that were already there, cutting out redundant instructions, clarifying a few things with macros, etc.. Eventually I had to re-write a lot of his work.

Quote:

And how do I handle the case where a program has > 64kB of code without hardcoding bank numbers?

Unless you have a team of programmers working for you, I can't imagine any excuse for letting a program get that big. Data, yes. Program, no. See the article, "Low Fat Computing (A politically incorrect essay by Jeff Fox). It's amazing.

[GARTHWILSON]

cr1901 wrote:

Garth, I seem to recall you mentioning that the VIA can support more I/O devices with simple glue logic, but the post where you mention this escapes me. Do you know by any chance what I am referring to?

You might be thinking of one or more of these pages:
http://wilsonminesco.com/6502primer/ExpBusIntrfc.html
http://wilsonminesco.com/6502primer/IO_ICs.html
http://wilsonminesco.com/6502primer/potpourri.html

[BigDumbDinosaur]

cr1901 wrote:

BigDumbDinosaur wrote:

4KB is a lot of stack space, probably much more than you'll likely need. Also, what about the application's direct page?

The stack is meant for multiple tasks running independently with support from a small kernel. I thought the direct page was limited to bank 0, so the OS will need to share it's direct page with multiple tasks, switching the DP register as necessary.

Stack accesses are also automatically mapped to bank $00. The 65C816 is designed so that when started from a dead stop it will work within the confines of 64K. Even after being switched to native mode, it still works within the confines of 64K. However, you can map direct page and stack accesses anywhere within that first 64K of RAM. Also, note that JMP (<addr>) assumes that <addr> is in bank $00. This is not the case for JMP (<addr>,X), however.

Quote:

BigDumbDinosaur wrote:

Mirroring ROM in every bank will prevent you from treating RAM above $00FFFF as flat space. While programs officially can't overlap banks, data certainly can, as indexing will span from one bank to the next. So I wouldn't be inclined to throw away that possibility.

... Oh... yea... I forgot about that tiny little detail. But doesn't mirroring the I/O space introduce the same problem?

Yes it does. Since any reasonable I/O system will be interrupt-driven, and since any interrupt automatically forces execution to bank $00, you might as well keep the I/O hardware in bank $00. You will have to account for DB in your ISR, since it may being pointing to something other than bank $00 when an I/O device comes calling. Please review the 65C816 interrupt guide for details.

Quote:

BigDumbDinosaur wrote:

Also, if you decide you want to run this system at 20 MHz, you are going to have to wait-state ROM accesses. That will add to the complication of ROM being in every bank.

Can you please clarify what you mean? I intended to place all the ROM banks into a single ROM, where each bank is allocated a different 8kB in the physical ROM.

Your memory map implied that ROM would be visible in every bank. If so, any access to that address range would have to be wait-stated at higher clock speeds.

Quote:

BigDumbDinosaur wrote:

Bank-independent applications? You already have that. If you load a program at $xx1000, for example (where $xx is any bank), it will run regardless of what $xx is. Relative branches, JMPs and JSRs are bounded by the bank in PB. Only JML and JSL can take you out of a bank, and I don't recommend their use in the ordinary course of events. I recommend that OS calls be via software interrupts so applications don't have to know about specific addresses.

I failed to imply this, but yes, I would do something similar to what you mention, presumably using the BRK instruction, since COP seems more apt for, well, a coprocessor . Best part is that it automatically puts me back into bank 0.

I recommend the use of COP. BRK is traditionally associated with program debugging and entering a machine language monitor. COP has 256 usable signatures, of which $00-$7F are recommended by WDC for user use. I highly doubt that a 65xx compatible co-processor will be developed, so you might as well take advantage of COP. That said, there's a different way to call a kernel API via software interrupts that does not use the signature. It's discussed in the interrupt guide.

Quote:

Then HOW do you handle the case where a task/application requires more than 64kB of code in a manner where the application doesn't care which banks to which its code segments are loaded? Using an already-existing EXE format isn't a problem for me (when we get to this point), but I have trouble visualizing how to load programs > 64kB in a position-independent manner.

Garth responded to this, but I'll reiterate. There's no earthly reason for a 65C816 assembly language program to get that large. This isn't x86 code written with a C++ compiler, you know.

Quote:

BigDumbDinosaur wrote:

I don't sound negative or discouraging, but exactly what 7400-series MMU would you use that could stay with the 65C816 at any speed above a couple of MHz? Are you thinking about the 74LS610? This sounds like a job for programmable logic.

Yes, that was the chip I was thinking of. I was under the impression that IC was still available in HC form. Back to the drawing board.

I suspect the only sources for the 74LS610 are on eBay. I don't recall ever seeing a 74HC610. For a smaller system with no more than 512KB of RAM, you can probably manage with a GAL 22V10 for glue logic. You can do it in discrete logic, but it quickly gets complicated and the prop time starts to get out of hand. Capturing the bank address is tricky with discrete logic if operating at elevated clock rates, but can be done with 74ABT logic.

Quote:

So what's left is:

• reset circuit
• clock circuit
• power supply (I'll probably cheat and use a bench supply for now)
• three TTL chips

For the three TTL chips- one TTL latch to hold the bank...

That would be a 74ABT573 (or 74AC573).

Quote:

...one TTL bidirectional hiz transceiver to attach/detach the '816 from the data bus...

That would be a 74ABT245 (or 74AC245).

Quote:

...and one TTL chip to expand the VIA's I/O capabilities.

I highly recommend that you use 74ABT or 74AC logic, not 74LS or 74HC. All WDC 65xx devices are CMOS, so there's no need for 74ACT/74HCT logic. Incidentally, most 74HC devices are no faster than their 74LS equivalents.

[BigDumbDinosaur]

P.S. If I were building this, I'd set up a memory map thusly:

Code: Select all

000000-00BFFF  RAM
00C000-00CFFF  Lo ROM
00D000-00D7FF  I/O
00D800-00DEFF  Reserved
00DF00-00DFFF  HMU (hardware management unit, aka MMU)
00E000-00FFFF  Hi ROM
010000-xxFFFF  contiguous RAM

The HMU could be some registers in a PLD that would allow you to map out one or both segments of ROM and expose the RAM underneath. Writing to a ROM address would bleed through to RAM.

[GARTHWILSON]

I didn't really think about the 4KB for stack space before; but I will comment now that 16 pages for stack space may be a lot more than you'll ever need. You probably won't need even a quarter of a page for any task. (If you use Pascal, I'll have to eat my words. ) The amount you give to each task is variable in one-byte increments; ie, it does not have to be multiples of 256 (or any other number). You could just as easily give a task 75 bytes' space as 64 or 256. 4KB at a quarter of a page each would be 64 tasks.

The same goes for direct-page space. It does not have to start on a page boundary, although if it does, certain instructions will take one less clock to execute. So there again, you could give each task only slightly more direct-page space than it needs, whether that's 30 bytes or 230.

[cr1901]

BigDumbDinosaur wrote:

P.S. If I were building this, I'd set up a memory map thusly:

Code: Select all

000000-00BFFF  RAM
00C000-00CFFF  Lo ROM
00D000-00D7FF  I/O
00D800-00DEFF  Reserved
00DF00-00DFFF  HMU (hardware management unit, aka MMU)
00E000-00FFFF  Hi ROM
010000-xxFFFF  contiguous RAM

The HMU could be some registers in a PLD that would allow you to map out one or both segments of ROM and expose the RAM underneath. Writing to a ROM address would bleed through to RAM.

I'll probably do some variation on that. One issue I see is when an application needs direct I/O port access- with this scheme, all I/O writes will be long (I can't envision creating an ISR just for writing bytes to the VIA or ACIA registers). This issue was also brought up when I proposed using a bank solely for I/O.

Additionally, I could reserve part of the HMU for virtual-memory like features in addition to mapping out ROM and RAM (assigning pages to the contiguous RAM, etc), should I choose to go that route. The ABORT pin seems like it could use some love .

Okay, not that it excuses me not doing my research, but my experience with the '816 is with the SNES. The SNES doesn't seem to use the COP interrupt, at least for anything I've looked at. So of course I told myself "I'll review COP later." Guess how that turned out . Ditto with not knowing that the Stack Pointer is automapped to bank 0: xx:0000-xx:1fff is mirrored RAM in all banks except 7f on the SNES, and 1fff is a good initial SP.

Some clarification- I thought the 7400 series MMUs accomplished similar goals to, say, the Motorola 68451- just being a lot simpler to set up. There's even a page on 6502.org detailing the discrete equivalent of the 74ls610. I don't think of an MMU as simply a bank switcher/swapper.

... I'll start at 8MHz, and work my way up. I'll probably also include a single-instruction mode as well... that's as simple as waiting for VDA/VPA to both be asserted I believe.

I know my code is not likely to exceed 64kB for a task, but just for the sake of discussion... what WOULD you guys do in that case to make the resultant executable position-independent if the code size exceeded 64kB? Semi-related: Didn't someone create an EXE format just for the 65xx series? The DOS MZ/Linux ELF formats, for example keeps a list of offsets that must be patched before running the program (though in the case of the former, those are segment markups, not linear addresses ).

[GARTHWILSON]

What bothers me most about requiring long addressing for I/O is that it's missing TSB, TRB, BIT, INC, and DEC. The indirect and indexed longs have less application in I/O, so I don't see them as an issue. Fortunately I myself don't really anticipate having code outside bank 0, only data, so it's not a problem. If I can put I/O in the first page (or two or four) of bank 0, and have all the rest to be RAM, and pre-load a part of RAM (in memory space which would otherwise be ROM) before releasing the processor from reset, it makes thing pretty simple (read: low propagation delays in the address decoding), and leaves a lot of flexibility, with nearly all of bank 0 being RAM. Even the interrupt vectors can be modified by the program. I know that wouldn't be suitable for a multitasking desktop-type computer though, which might be what you have in mind. Maybe you could write to a bit that would switch I/O in and out of a small part of every page, part that would otherwise be RAM.

[BigDumbDinosaur]

cr1901 wrote:

I'll probably do some variation on that. One issue I see is when an application needs direct I/O port access- with this scheme, all I/O writes will be long (I can't envision creating an ISR just for writing bytes to the VIA or ACIA registers). This issue was also brought up when I proposed using a bank solely for I/O.

What I meant was the data flow would come via IRQs, not register setup. You can always change the active data bank with:

Code: Select all

         phb                   ;protect current data bank
         lda #$00              ;bank $00
         pha
         plb                   ;set new bank

Later on when your code has finished tinkering with the I/O hardware:

Code: Select all

         plb                   ;restore old data bank

Setting the data bank in this way eliminates having to use 24 bit instructions, and also gives you the use of some instructions that have no 24 bit counterparts (e.g., TRB).

Quote:

Additionally, I could reserve part of the HMU for virtual-memory like features in addition to mapping out ROM and RAM (assigning pages to the contiguous RAM, etc), should I choose to go that route. The ABORT pin seems like it could use some love .

Use of ABORT is somewhat challenging, as there are strict timing deadlines involved. However, it's there to be used, such as for memory protection, correcting page faults, etc.

Quote:

Okay, not that it excuses me not doing my research, but my experience with the '816 is with the SNES. The SNES doesn't seem to use the COP interrupt, at least for anything I've looked at. So of course I told myself "I'll review COP later." Guess how that turned out . Ditto with not knowing that the Stack Pointer is automapped to bank 0: xx:0000-xx:1fff is mirrored RAM in all banks except 7f on the SNES, and 1fff is a good initial SP.

Unfortunately, the SNES was not a true 65C816 implementation and definitely not a model of a general purpose computer. As you are no longer working within the constraints of the SNES architecture you can rig up your system with flat address space and can use that space as you see fit (e.g., large data arrays, as Garth suggests).

I'm sure you're familiar with direct page indirect addressing, e.g., LDA ($12),Y. I don't know if you also know that the 65C816 has a 24 bit version of that, e.g., LDA [$12],Y. The value stored at $12 is a 24 bit address in little endian format, with the bank value being at $14. This addressing mode is the key to treating RAM as flat data space. With the index registers set to 16 bits, you can access 64KB of data at a time by merely indexing .Y as you go. If .Y wraps then you would increment the bank byte. For example:

Code: Select all

;access a large range of RAM
;
         rep #%00010000        ;16 bit index registers
         sep #%00100000        ;8 bit accumulator
         lda #$04              ;starting bank
         ldx #$0100            ;starting address in bank
         stx $12               ;set starting address
         sta $14               ;set starting bank...
;
;	The above sets the effective address to $040100.
;
         ldy #$0000            ;this is 16 bit load
;
loop     lda [$12],y           ;read from RAM
         ...process the byte...
         sta [$12],y           ;write to RAM
         iny                   ;next location
         bne loop              ;loop over 64K locations
;
         inc $14               ;next bank
         bra loop              ;effective address now $050000

Quote:

Some clarification- I thought the 7400 series MMUs accomplished similar goals to, say, the Motorola 68451- just being a lot simpler to set up. There's even a page on 6502.org detailing the discrete equivalent of the 74ls610. I don't think of an MMU as simply a bank switcher/swapper.

The MC68451 is a sophisticated device that goes well beyond what a 74LS610 can do. That said, the '610 is LS logic, and you really shouldn't be using LS hardware in this application.

Quote:

... I'll start at 8MHz, and work my way up. I'll probably also include a single-instruction mode as well... that's as simple as waiting for VDA/VPA to both be asserted I believe.

Right. VDA && VPA is the equivalent of SYNC being high on the 65C02, indicating an opcode fetch is in progress.

Quote:

I know my code is not likely to exceed 64kB for a task, but just for the sake of discussion... what WOULD you guys do in that case to make the resultant executable position-independent if the code size exceeded 64kB?

I've never given it any thought. The largest program I ever developed in assembly language worked out to about 18K total, code and data. That is a huge program by 65xx standards.

Quote:

Semi-related: Didn't someone create an EXE format just for the 65xx series? The DOS MZ/Linux ELF formats, for example keeps a list of offsets that must be patched before running the program (though in the case of the former, those are segment markups, not linear addresses ).

André Fachat, whose page you earlier linked, developed a relocating format for 65xx executables.

GARTHWILSON wrote:

What bothers me most about requiring long addressing for I/O is that it's missing TSB, TRB, BIT, INC, and DEC.

This is where pushing DB to the stack and temporarily loading it with bank $00 (or wherever the I/O hardware is located) helps out. In any 65C816 system with more than 64K, you are going to have to either use long addressing or be prepared to tinker with DB. It's unavoidable.

[cr1901]

BigDumbDinosaur wrote:

This is where pushing DB to the stack and temporarily loading it with bank $00 (or wherever the I/O hardware is located) helps out. In any 65C816 system with more than 64K, you are going to have to either use long addressing or be prepared to tinker with DB. It's unavoidable.

I probably should've been able to figure out to switch DB myself. In any case, I can see uses for both using long addressing and swapping DB. The former probably makes most sense for one-shot reads and writes, such as reading a status register or writing a single value. But the latter probably makes more sense to send blocks of data, i.e. with the ACIA, switch to bank 0, and use one of the complex addressing modes to access your data block wherever it is (bank 0, 1, 2,... etc).

[GARTHWILSON]

I suspect that doing 24-bit addressing would be more efficient than constantly changing data banks when transferring data from I/O to memory or vice-versa. However, my '816 experience is limited to the '802 which is an '816 that goes into a 6502 socket, so it has a lot of '816 benefits but there's no operation outside of bank 0.

Quote:

I know my code is not likely to exceed 64kB for a task, but just for the sake of discussion... what WOULD you guys do in that case to make the resultant executable position-independent if the code size exceeded 64kB?

I think that if it spans two or more banks, it shouldn't be any problem if they're always in the same order (probably consecutive).