I was reading about a Z-machine[*] implementation, where 17-bit addresses were needed, and they were shifted to fit into 16 bits and stored in a two-byte word. This seems quite efficient, certainly a good use of space, and gives access to a 128k sized data area, with the only limitations being that each data item has to start on an even byte, and you can only have 64k items at most.

We can of course extend the idea - common SRAMs connected to our 6502-like systems go up to 512k although of course you can use several chips to make up an even larger memory. At the limit, using only 16 significant bits in a 24 bit pointer looks like quite a coarse-grained data store with fairly low capacity, but this seems practical to me up to say 512k.

Any thoughts? Has anyone tried it?

This is the article I was reading - it's one of a series.

Edit: I see now that SRAMs larger than 512k are also available and not too expensive.

[*] virtual machine for a text adventure game interpreter

So how do you access the data on the least significant bits? I am suitably confused. Are you referring to the CPU's address bus or some arbitary memory interface, driven by the CPU through some kind of port or controllerk?

_________________
8 bit fun and games: https://www.aslak.net/

Thinking aloud here, and presuming we're talking about an '816 system: the idea is to be able to store the long-distance pointer in two bytes rather than three. So pointer-based datastructures will be smaller. To be used, they would need to be unpacked into a three byte pointer in direct page.

Ah, ok. Similar to holding indexes into an array of structs (say), instead of pointers to those structs, which are arranged consecutively in memory?

_________________
8 bit fun and games: https://www.aslak.net/

From what you're saying, what I imagine for a 6502/816-like processor addressing the 512K you mention, branches and indexing and absolute addressing would still have single-byte resolution, while long-addressing instructions would have something like 8-byte resolution (to cover 512K). Long addressing would be separate from absolute addressing as you say Ed, but would have two-byte operands instead of three-byte like the '816 uses for longs. Indexing on the longs can still have single-byte resolution, but the base addresses won't.

_________________
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?

Aslak3: yes, the pointers are a bit like indexes. Once activated in a 3-byte pointer in direct page, they can be incremented. So they can point to strings or to complex structures.

Garth: yes, for a variant CPU we could support scaled pointers directly. This all sounds fine, so long as you don't use a paragraph size of 16 and start to have flashbacks about x86 segmentation!

Right. And unpacking a two byte pointer into a three byte pointer is fast because there's no shifting (I mean with a scale factor of 256).

This Compact Pointer idea surfaced in another context not too long ago. Rob Finch was looking at 32-bit CFA's for Forth and I proposed a 16-bit CFA but scaled (shifted left in hardware).

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

I did something like this once for a file of images on disk. I needed 17 bits to store the byte offset to each image start, but that seemed really clumsy. So instead I kept the offsets as 16 bit words and multiplied by two when I needed to use one. Sometimes I had to put a single "pad" byte between the images on disk to make the scheme work, but that seemed a small price to pay!