From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-28 12:43:32
On Wed, Nov 27, 2002 at 02:12:35PM -0800, Shawn Jefferson wrote:
> In the Atari, this is complicated by the fact that a huge window is banked
> out (16 kB). Using the banked memory as storage is easy if you do your own
> linker config and assign code segments manually. Using it for code would be
> more of the same, I guess (as you have explained to me.)
Using it for code would need small wrappers in common memory (this is an
example where the new LOWCODE segment is useful). The reason for the wrapper
is that it banks in the memory where the actual routine resides, and it allows
code in one bank to call code from another bank.
> In the internal.txt there is mention of using the extended ram and ram under
> the OS as a far heap. What does this mean?
It means that this memory is not usable by normal means. One possible use
would be the memory extension API we talked about, which needs copying in this
case.
> I have thought of writing routines that would allow you to malloc memory in
> this extended memory banks, and when you want to access it, it would bank in
> the right memory bank and then malloc a block in regular ram, copy the data
> there, bank in the regular 16kB bank again, and return a pointer to the
> regular ram where it was copied. This may be just too much overhead/work
> though....
Too much overhead compared to what? When talking about extended memory, it
does not make sense to compare it with real linear memory. Instead, compare it
with disk access, which would otherwise be needed.
> Problems:
> - this code must not be in the bank window
This is not a problem. Just place the critical pieces into the LOWCODE
segment. LOWCODE will be placed in low memory, directly above the startup
code.
> - the bank window cannot contain interrupt routines, or you must disable
> interrupts while the extended memory access is happening (might this be too
> long?)
The critical parts of an interrupt handler (entry code at least) should also
go into LOWCODE, so interrupts should not be a problem. The new Plus/4 code
does also banking (you may have read the discussion a week ago). The Plus/4
hardware is able to bank in ROM in the upper 32KB or RAM. Several stubs in low
memory (including an interrupt handler stub) allow RAM code to call ROM
routines regardless of the address where the RAM code itself is located, even
if the RAM is in the high range that is banked out when ROM is enabled.
> - lots of overhead/speed issues maybe too.
I wouldn't think too much about speed. When having to decide between access to
extended memory, and no access to extended memory, people will almost sure
choose the former, even if this is slower than access to linear memory. For
someone with a lot of time, there's always the possibility to write
handcrafted routines for a special purpose.
> Another topic: Are/is the module loading routines going to be supported on
> the Atari?
The question is not, if these routines are supported on the Atari, but if
these routines will be supported on other platforms than the Atari:-)
Seriously: o65 modules are platform independent (a 6502 CPU is necessary), but
the data must come from somewhere, and the most common data storage is a
floppy drive. Since the Atari was the first platform to have working disk I/O
(besides the old ACE target which is no longer supported), it was never a
question if the module loader would work on the Atari. However, it *was* a
question if loadable modules would be useful on other platforms, since for
example the CBMs had no standard disk I/O until two weeks ago.
If you want to know more about the o65 format, please have a look at Andre
Fachats o65 spec at
http://www.6502.org/users/andre/o65/fileformat.html
cc65 has an "official" o65 id, like OSA/65 and Lunix, and I have suggested a
small addition to Andre, which was accepted by him. Both things are currently
not reflected in the docs, but apart from that, the page is current.
If you really want to write a memory extension library, please consider taking
part in the discussion regarding an API for such a library. Having a common
API across all platforms would certainly help all developers.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-11-28 12:44:20 CET