CMD RAMLink - which important addresses uses?

[MIRKOSOFT]

Hi!

I'm programming my aceCommnader128 and when I enable RAMLink, program crashes...

My program uses area $1300 - $8000 and $a000 - $bfff for directory.

I think that any important address is selected as RAM, not ROM, but really don't know which.

Can anybody help me?

Many thanks for every reply.

Miro

[XmikeX]

The data below is sourced from an old thread on USENET.
Hope it helps!

XmX
---

From : csbr...@ccnga.uwaterloo.ca ( Craig Bruce )
Newsgroups: comp.sys.cbm
Date: 1995/06

>> Bruce McFarling <br...@utkux1.utk.edu> writes:
>>     The REU control registers are not a problem, as we have to
>> sidestep them anyway (and we only need four addresses).  But do
>> I understand this correctly, that the RAMLink is *not* activated by a
>> control register in the IO expansion address space, but only lives there
>> when it is activated?  How *does* it get activated?

The way that you activate the RAMLink hardware is to do a write operation to
location $DF7E and the way to deactivate it is to write to location $DF7F.
The value that you write doesn't matter.  I don't think that there's
actually an I/O port there when the hardware is not active (but I don't know
for sure).  When the RL is not active, what you see in $DE00--$DFFF is
whatever you have plugged into your passthrough port (or the RAMport if the
Normal/Direct switch is in the Direct position).

After you activate the RAMLink hardware, then its I/O registers show up.
The $DE00--$DEFF range shows a page of RAM from either some internal static
memory in the RL or from RAMCard memory, and the $DF00 range contains: the
REU registers from $DF00--$DF0A (if you have an REU plugged into the
RAMport) and some other various registers scattered around the $DF00 page.

There are a number of function-activation locations available in the $DF00
page after the RL has been activated:  $DFC0=show the internal 8K static RAM
in the $DE00 window, $DFC1=show RAMCard memory in $DE00 window, $DFC2=show
the RAMport device in the $DE00 window, $DFC3=show the pass-through port
device in the $DE00 window.  To activate these various features, all you do
is perform a write operation on the trigger address.  There are also some
RL-DOS ROM control locations at $DF60 (activate) and $DF70 (deactivate).

To make a specific page of RAMCard memory available in the DE00 window, you
write the low byte of the page address to $DFA0 and the high byte of the
page address to location $DFA1 and then perform a write operation to
location $DFC1.  Note that the page address includes bits 8-23 of the
RAMCard address, and the RAMCard addresses always start from $000000, which
will not match the information returned by the G-P command if you have an
REU plugged into your RAMport.  When you are finished accessing the RAMCard
memory, you should re-enable the static RAM back into the $DE00 window by
writing to $DFC0.  Presumably, this is where the "pseudo-REU" control
"registers" for the DACC accessing using the standard (slow) subroutines are
stored.  ACE-128/64 uses the hardware accessing technique and is
significantly faster than the standard DACC routines.  ACE will also use the
REU to perform data transfers to/from the $DE00 page, which makes things
even faster, if you have an REU.

The parallel-port registers for the parallel connection to the HardDisk are
in locations $DF40--$DF43.  It is an 8255 I/O chip: $DF40=parallel data,
$DF41=handshake out, $DF42=handshake in, $DF43=control register.

There may be some other control registers available when the RL hardware is
active that I don't know about.

The above information was provided to me by Doug Cotton of CMD.

BTW, don't use the above information to play with your RAMLink if you have
any valuable data in it.  <Include standard lawyershit disclaimer here>.

Keep on Hackin'!

-Craig Bruce
csbr...@ccnga.uwaterloo.ca
"My Internet includes anarchy."
   
      

Adam Fanello      Jun 26 1995, 2:00 am
Newsgroups: comp.sys.cbm
From: adam_fane...@bbs.fullcoll.edu (Adam Fanello)
Date: 1995/06/26
Subject: Re: SwiftLink/RAMLink Pro

 CB> The way that you activate the RAMLink hardware is to do a write
 CB> operation to location $DF7E and the way to deactivate it is to write to
 CB> location $DF7F. The value that you write doesn't matter.  I don't think
 CB> that there's actually an I/O port there when the hardware is not active
 CB> (but I don't know for sure).  When the RL is not active, what you see
 CB> in $DE00--$DFFF is whatever you have plugged into your passthrough port
 CB> (or the RAMport if the Normal/Direct switch is in the Direct position).

Is the RAMLink set as active during normal opporation of the c128, or just when
the contents of the RAMLink are active?

 CB> There are a number of function-activation locations available in the
 CB> $DF00 page after the RL has been activated:  $DFC0=show the internal 8K
 CB> static RAM in the $DE00 window, $DFC1=show RAMCard memory in $DE00
 CB> window, $DFC2=show the RAMport device in the $DE00 window, $DFC3=show
 CB> the pass-through port device in the $DE00 window.  To activate these
 CB> various features, all you do is perform a write operation on the
 CB> trigger address.  There are also some RL-DOS ROM control locations at
 CB> $DF60 (activate) and $DF70 (deactivate).

Please forgive all my questions... I don't have a RAMLink of my own to
experiment with. I'm trying to get the RAMLink and SwiftLink to work smoothly
together on my BBS software (Color 64's V128, and later, Centipede BBS.) but
not having a RAMLink myself means I have to rely on others for info.

As you all know.. The c128 (and similarly with the c64) handles interrupts by
storing the computer's current configuration on the stack, reconfiguring to
handle the interrupt, and then restores the CPU and MMU to their old
configuraton before continuing. What I need for it to do, in addition to
remembering the PC address and bank, is to remember the RAMLink's
configuration, set it to so that the SwiftLink in the passthrough port can be
used during the NMI, then reset the RAMLink back the way it was before exiting.
This way is simpler, quicker, cleaner, and more in line with the way the normal
c128 Kernal works, than using a half-dozen wedges and patches to turn the
SwiftLink on and off all the time for all disk i/o.

About all I can tell is missing from the info Creg has been so kind to provide,
is how to READ how the RAMLink is configured. I see how to set several things,
but not how to read it so that it can later be restored. If anybody has that
info, I'd be a VEEEEERRY happy man!