RE: software support for memory expansions

ncoplin_at_orbeng.com
Date: 2001-08-08 09:14:29

Lack of software support has always been a reason why I've considered these
RAM expansions at a lower priority to building other things....

The two internal expansions: +60k/VCS (or +192k) and the one hosted on funet
(documented by Marko?), are both great, but neither offers a patched kernal
ROM which makes it easy. There's a patched GEOS version by YTM which the
+60k expansion, and DiskCopy and other tools for both.

My idea of key features that should be supported with Kernal jump-table
calls are:
detect (normal system should have no change, and should point to an RTS)
far JMP
far JSR
copy page (256bytes) from /to
compare page page (256bytes) from /to

With these at a minimum, even someone with only BASIC programming experience
could get things happening with a few pokes and an SYS.

With talk about SIMM based projects, is it worth while standardising a
calling method and JumpTable location which doesn't cause incompatibilities.
Assuming 20bit addresses, I'm thinking a JSR with
A= 4bit "from", 4bit "to" nibbles
Y= 8bit "from" page (hibyte)
X= 8bit "to" page (hibyte)
call to retun code by flags

One other option was to embed this functionality in USR which points to
nowhere, eg 
USR(0)=>detect (already RTS)
USR(1)=> far JMP

with AXY poked into the 7xx locations used for SYS calls

- Nick


PLEASE TAKE NOTE:

The contents of this email (including any attachments) may be
privileged and confidential. Any unauthorised use of the contents
is expressly prohibited. If you have received this email in error,
please advise us immediately (you can contact us by telephone
on +61 8 9441 2311 by reverse charge) and then permanently
delete this email together with any attachments. We appreciate
your co-operation.

Whilst Orbital endeavours to take reasonable care to ensure
that this email and any attachments are free from viruses or other
defects, Orbital does not represent or warrant that such is explicitly
the case

(C) 2000: Orbital Engine Company (Australia) PTY LTD and its
affiliates


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail 2.1.1.