I've got some portable code which is intended to run on multiple machines. I want a quick and dirty buffer for passing parameters from one command to another; it's variable sized, and can be up to 164 bytes in the worst case.

I'm curious to know what people think about stealing space from the bottom of the stack page --- 0x0100 to 0x01a4, in my case. I know some platforms use this area for scratch storage. The BBC Micro copies error messages there for processing; the C64 seems to use this for cassette I/O buffers, but I haven't seen any which actually reserve this area for long-term use (except the Atari 2600...).

Are there any platforms which, e.g., don't completely populate that page with RAM? (Except for the Atari 2600.) Is this something I can generally assume will work, or something I should avoid like the plague? 256 bytes is a lot on the 6502, and it's at a very handy fixed address.

Sounds like a good idea to me - preferably with some way to gain confidence that the stack won't grow enough to cause trouble.

I can't imagine that any reasonable-size system would fail to provide a full page of RAM at 0100.

I do have the vaguest idea that NMI points to 0100 on some system. In other words the OS already had the bright idea to use this area.

That's not quite right. The Commodore 8-bits have dedicated memory, not on the stack page, set aside for cassette buffers. They are popular places to stash short machine code programs.

Their BASIC interpreters do use a small portion of memory at the bottom of the stack while converting floating point numbers into text form. This is more-or-less protected; when the interpreter allocates stack space for a GOSUB call or a FOR loop it checks to make sure the pushed parameters will not overwrite that bottom portion. If there is not enough room, it fails with an "out of memory" error.

The C64 does use the start of page 1 as a cassette-related buffer. It's just not the data buffer.

When loading, it is able to detect some kinds of errors - I suspect (without looking too closely at the code) that it could be if the time between transitions isn't close enough to the time it expects for either a 0 or a 1. When an error is detected, it appends a pointer to the byte in question to this buffer. Files are stored twice, so if there weren't too many errors, there is a chance to correct it.

It allows up to 30 errors, so will use the first 60 bytes of page 1 for this buffer.

The Commodore 1541 and 2030 disk drives use the lower part of page 1 as buffer for the GCR encoding and decoding IIRC. GCR increases the size if a block by 25% (4-to-5 group code) and that needs to be done for every read and write. Stack usage is limited, as in idle mode the disk drive always resets SP to 0xff and there is no recursion.

Also, I have an option for my GeckOS multitasking operating system to share the stack. I was able to run a few processes with 32 bytes of stack per process (and 64 byte for kernel)

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

It all turns out to be moot anyway --- it turns out that the BBC Micro, which I'm doing initial development on, uses about 50 bytes of stack in interrupt handling. Putting my buffer at the bottom of the stack page means that there are only 40 bytes left, which I reckon isn't enough. So I'm going to have to put the buffers elsewhere, which will be excessively annoying. At least now I don't have to worry about running out of stack space...