7

As the 8-bit systems hit their peak in the mid-1980s, breaking the 64K barrier was all the rage. Commodore, Apple, Atari, and Tandy all shipped new 8-bit machines that came standard with 128K. Of course, this introduced the need for new memory controllers and programming models, since all these machines had only a 64K address range.

I know that Tandy's solution with the Coco 3 was using Dynamic Address Translation, and the unexpanded 128K Coco 3 presented as 16x8K pages. Commodore and Apple used bank switching to select one or the other 64K memory bank. I think Atari did the same, but I'm not sure.

My gut feeling is using the 128K with the coarse bank switching approach would not work very well. Swapping code/data pages around using DAT seems like a more feasible and familiar programming model to me.

I'll go a little over the top perhaps, and ask: Was the bank switching approach basically a gimmick that allowed the Commodore and Apple machines to be marketed as having 128K, even though the additional memory was not very useful (beyond a RAM disk)?

Likewise, is it true that the DAT approach as provided by the Coco 3 is a superior way to expand memory above 64K and keep the programming relatively simple?

(A great answer would probably include an example of how to use DAT effectively, and which isn't possible with bank switching).

closed as primarily opinion-based by cbmeeks, Tommy, Stephen Kitt, wizzwizz4 May 15 '17 at 15:44

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    What do you mean by "easy"? Fewer instructions? If it's "ease of use for x" this might be too subjective. – wizzwizz4 May 11 '17 at 6:19
  • 1
    @BrianH I know you asked which is easier. That's why I posted as a comment, not an answer. I was not trying to answer your question just posting a general comment. – JeremyP May 11 '17 at 14:40
  • 1
    No, the wording is fine as far as I'm concerned. It's absolutely clear to me what it is about. – JeremyP May 11 '17 at 14:49
  • 5
    Both techniques you describe are both properly referred to as bank switching. The very name "bank" suggests multiple of blocks of memory to switch between, not just two. The Commodore 128 bank switching scheme wasn't quite as simple as you describe, you could set up an unbanked region at the bottom and/or top of memory. As far as I know Apple II bank switching schemes used a single bank of size of 16K at the end of memory. The TRS-80 Color Computer 3 split the entire 64k address space in to 32 8K banks.The later is obviously the most flexible of the schemes, but not necessarily the easiest. – Ross Ridge May 11 '17 at 19:34
  • 1
    Atari used 4x16K banks at $4000 in the Atari 130XE – Tim Locke May 11 '17 at 20:03
10

Neither CoCo nor Retro-Apples are my specific area of expertise - I'll try to answer from a more European viewpoint. Concepts and technical solutions are similar, however.

Basically, all the technologies you describe that allow the adaptation of more memory than the CPU would normally be able to address are, at least in my terminology, denoted under the general term Bank Switching. The implementations of such mechanisms, did, however, differ in terms of memory granularity (that is, size of banks - Which was very often selected as 16kB, which seems kind of appropriate for 64kB address space) and memory flexibility (that is, which bank can be superimposed onto which area in the addressable memory space). The term bank is also kind of unspecific - Some vendors referred to a bank as the source memory area in the larger address space, some others used the term for the target memory area in the CPU's address space.

Some computers also had the limitations that parts of the address space were dedicated to specific purposes like memory-mapped I/O (not on the Z80, typically) and screen memory (the ZX Spectrum 128, for example, always had screen memory fixed at 0x4000 and above). Other computers like the Enterprise could feed the screen more flexibly from selectable memory pages or, like the Cambridge Z88, didn't have screen or other dedicated memory areas in a traditional sense at all.

Some examples:

The Cambridge Z88 is able to address 3.5MB of RAM that is logically segmented into max. 256 16kB pages. Each of those pages can be mapped onto any of four banks of Z80 address space. Granularity: 16kB, Flexibility: full. (Being a kind of early "notebook computer", much of this memory area was normally used for storage in battery-buffered RAM, EPROM or, later, Flash memory)

The Enterprise 128 uses a very similar scheme, 16kB page size, max. addressable memory 4MB, page/bank size 16kB, full flexibility. Like the Z88, the Enterprise provides ROM routines for linear addressing of data and code and moving data and code out and about within the larger address space and thus makes bank switching extremely transparent to the programmer.

The ZX Spectrum 128 ("Toastrack") had a much more limited banking logic. Like the above, it used 16kB pages, and divided its 128kB RAM + 16kb (48k "compatibility" ROM) + 16kB (128k "new" ROM) into 16kB slices. It did, however, have limited flexibility in what pages could be mapped into what bank in the Z80 address space: The lower 16kB bank could only be occupied by either one of the 16kB ROMs (So, that area was dedicated to ROM and made the Toastrack CP/M incapable, unlike later Spectrums), the next bank was fixed for screen memory pages and could only map pages 5 and 7 of the 128kBytes of RAM. Bank 3 was fixed and could not be paged in or out at all, and only Bank 4 could actually receive any of the 8 16kB RAM segments. The original Toastrack ROM did not provide a lot of support for bank switching - You basically have the mechanisms to influence the pages, but beyond that, for example, to move memory contents from one bank to another, you were on your own and had to decide which pages to page in and where.

Picture from http://www.robeesworld.com/blog/35/loading_zx_spectrum_snapshots_off_microdrives_part_two

Later (Amstrad-made) ZX Spectrum models like the +2 and +3 had a more flexible banking scheme.

Computers based on the 6502 or similar CPUs had more challenges with large memory and bank switching than Z80-based computers. The 6502 zero page (or rather, the lower 1kB) is a crucial memory area that cannot be easily moved about in the address space as it holds address information for indirect addressing and other crucial information like the fix-addressed and size-limited CPU stack. Also, 6502 and similar CPUs typically use memory-mapped I/O, so we have another area that needs to fit into the 64k address space. You could easily argue that memory banking had to be more complicated on such a CPU than on the Z80.

The C128 MMU had special mechanisms to relocate this area and always kept the lower 1k mapped to the same RAM. A C128 also had the additional challenge that it needed to orchestrate and accommodate two CPUs - the 8510 and the Z80 with the same memory.

I am not a C128 expert, but understand the following: The C128 had provisions to be able to cope with a maximum amount of 256kB of RAM internally and used sort of fixed memory configurations. While the zero page+ was handled specifically and always paged in from bank 1, you could either have 0x03ff-0xffff all RAM from Bank 0 (one half of the 128k available), or all RAM from Bank 1 (the other half of the 128k), or 16k from Bank 1 and the rest occupied with ROM and either I/O or character ROM. On top of that, the MMU had a common RAM feature, that allowed to partially "override" the RAM configuration in a way that would configure certain memory areas of pre-selected sizes (1k-16k) to always map to Bank 1 memory. All in all, extremely complicated...

With respect to ease of programming, the "fixed page size, fully flexible mapping" approach definitely sounds likethe most simple, easy to understand and program way of doing things on a very low level. Juggling with the C128 MMU and paging registers on a low level doesn't look like fun to me. If, however, the on-board ROM supported you in providing calls and data access routines into the whole memory like the C128 (and, for example, the Enterprise and Z88, where you basically handed in a register triple instead of a register pair to the ROM routines in order to linearly address memory in the 4MB range) did, all of those complications basically became rather transparent to the programmer, so from an applications programmer view, I wouldn't really prefer one over the other.

  • Technically the C128 MMU could have allowed up to 1MB (16 banks of 64k) but that ignores the IO mappings and introduces other issues (and they saved some money by not wiring up all the selector pins anyway). There are tutorials online on expanding a 128 up to the full 1MB. – Joe May 13 '17 at 13:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.