SwiftLink/RAMLink Prgming
Adam Fanello
and RAMLink. Calls to CMD tech support in the past have had them denying a
problem, but my own experience and a chat with Jim Brain have shown that there
is in fact a problem.
Apparently the RAMLink does not like being interrupted by an NMI request from
the SwiftLink. Such an occurence will cause the c128 to crash into the ML
monitor, where bank 2 (external rom) is active. I assume that to be the
RAMLink.
According to Jim, the problem is that some setting is not being restored after
an NMI, leaving the RAMLink to crash.
I am currently turning the SwiftLink off before and disk access, and then back
on afterwords. Since my program also has BASIC coding though, I have to wedge
into all the i/o vectors to turn the SwiftLink on and off... which creates a
small, but noticable slowdown. Even then... some people are still experiencing
occational crashes of their RAMLinks.
What I would really LIKE to do is simple include a call at the end of the NMI
routine to propperly re-enable the RAMLink - illiminating the slowdown and
making the code simpler, shorter, and more reliable.
I send email to Doug Cotton about this a month or two ago, but never received a
responce. I do not own a RAMLink myself. I run my BBS off an Lt.Kernal system,
which works fine with the SwiftLink without any of this turning it on/off
stuff.
---
ş Blue Wave/QWK v2.12 ş
==========================================================================
Fullerton College claims no responsibility to the opinion expressed above!
==========================================================================
Susie Martin
AF> responce. I do not own a RAMLink myself. I run my BBS off an Lt.Kern
AF> which works fine with the SwiftLink without any of this turning it o
AF> stuff.
Am I to assume this is something related to your v128 or the
development of the new Centepede software Adam? I'm powerless to help
ya but I figured I'd ask (being nosey as usual).
Off topic but now that I finally got all the toys to do my v128
upgrade, I've landed on the disabled list and unemployed...I WILL get
that upgrade someday...at least now I have the 80 col monitor and it IS
fixed!
Todd S. Elliott
>Apparently the RAMLink does not like being interrupted by an NMI request from
>the SwiftLink. Such an occurence will cause the c128 to crash into the ML
>monitor, where bank 2 (external rom) is active. I assume that to be the
>RAMLink.
>
accessing the RAMLink to do some assembling. I will take off the SL and see
what happens.
Todd Elliott
tsel...@gate.net
Doug Cotton
>I 'm trying to find a simple work-around for a conflict between the SwiftLink
>and RAMLink. Calls to CMD tech support in the past have had them denying a
>problem, but my own experience and a chat with Jim Brain have shown that there
>is in fact a problem.
>Apparently the RAMLink does not like being interrupted by an NMI request from
>the SwiftLink. Such an occurence will cause the c128 to crash
The only time RAMLink is active is during Kernal calls to serial bus routines.
The breaks to monitor will occur at this point if an NMI occurs. Since NMI's
aren't supposed to be happening during disk access, this isn't really
considered by us to be a 'bug' in any way. It's more like a harsh indicator
of a problem in the way your program is operating with the hardware.
>I am currently turning the SwiftLink off before and disk access, and then back
>on afterwords. Since my program also has BASIC coding though, I have to wedge
>into all the i/o vectors to turn the SwiftLink on and off... which creates a
>small, but noticable slowdown. Even then... some people are still experiencing
>occational crashes of their RAMLinks.
There pretty much has to be an NMI sneaking past your code somewhere.
>What I would really LIKE to do is simple include a call at the end of the NMI
>routine to propperly re-enable the RAMLink - illiminating the slowdown and
>making the code simpler, shorter, and more reliable.
The only person who has that kind of info is Mark Fellows at CMD, who designed
RAMLink. I can't be sure he'd give it out, but you can ask him directly. It's
likely he'll point out to you, though, that this kind of patching only treats
the symptom... not the problem.
==========================================================================
_____ _ _ _____ ||
/_____\ | \ / | | ___\ || Creative Micro Designs, Inc.
// ||\\ //|| || \\ || P.O. Box 646, E. Longmeadow, MA 01028
|| || \\// || || || || Orders: 1-800-638-3263
|| || \/ || || || || Info & Support: 1-413-525-0023
\\______ || || ||___// || Fax: 1-413-525-0147
\_____/ || || |____/ || Online Contact: cmd-...@genie.geis.com
||
==========================================================================
Visit our WWW site at: http://www.msen.com/~brain/guest/cmd
==========================================================================
Doug Cotton
Craig Bruce
>That may explain why Buddy 128 crashes inexplicably on my C128 when
>accessing the RAMLink to do some assembling. I will take off the SL and see
>what happens.
Unless the SwiftLink is _active_ while you are using Buddy, where the SL
usually is NOT active when you are not inside of a terminal program, then
you are having some different problem. I use Buddy with everyday with my RL
and I have no problems. Of course, Buddy becomes quite disturbed if you
mess with page $c00 while it is wedged into BASIC.
Keep on Hackin'!
-Craig Bruce
csb...@ccnga.uwaterloo.ca
"Kids today have video games where we had inexpensive 8-bit computers to play
with when we were young. I wonder if they are going to have the same deep
technical understanding of how computers work when they get to university
that we had, in addition to an incredible eye-hand coordination."
robe...@turner.lamf.uwindsor.ca
Even using standard RS-232 routines in either the C64 or C128, one of the major problems was that the roms didn't disable disk access before modem I/O. I solved this by simply organizing the output routines so that the modem I/O is disabled durring CHKIN, CHKOUT etc. And when I am done I enable them (usually at CLRCHN).
I can say this works since I have yet to see C-NET 64 lockup after and modem I/O from either the RS-232 or the Swiftlink.
Adam Fanello
DC> The only person who has that kind of info is Mark Fellows at CMD, who
DC> designed
DC> RAMLink. I can't be sure he'd give it out, but you can ask him
DC> directly. It's likely he'll point out to you, though, that this kind
DC> of patching only treats the symptom... not the problem.
I never said bug.. I said conflict. The kernal waits for a normal rs-232
opperation through the user port to finish before partaking on a serial port
opperation. This code doesn't work for the SwiftLink though. Since no serial
code in the c128 was designed to work with the SwiftLink, any modification for
the user of a SwiftLink, is by definition, a patch. The only way to FIX the
problem rather than PATCH it, as you say, would be to burn new ROM chips.
How can I get in contact with Mr. Mark Fellows?
Bruce McFarling
We don't need a functional breakdown, just the range of addresses used.
Thanks,
Bruce McFarling, Knoxville
br...@utkux1.utk.edu
Doug Cotton
>How can I get in contact with Mr. Mark Fellows?
Call CMD during technical support hours and ask for him directly.
David Schmoll
BE> New header, same query: what are the
BE> register addresses of the RAMLinK?
BE> We don't need a functional breakdown,
BE> just the range of addresses used.
$de00 - $de26 are the published addresses, and they are only visible
when Ramlink is mapped in - which maps out the original $de00 -, so you
can have another cartridge at that same address, at other times. I have
a cartridge using $dexx plugged into my Ramlink, and there is no
conflict.
... dsch...@nyx10.cs.du.edu (David Schmoll)
/\/ QWKRR128 V4.32 [R]
Craig Bruce
>New header, same query: what are the register addresses of the RAMLinK?
>We don't need a functional breakdown, just the range of addresses used.
That's a bit of a trick question, but when the RAMLink hardware is active,
it asserts a peephole page window at address range $DE00-$DEFF in the I/O
space, and it asserts its control registers and your REU registers (if you
have one) in the $DF00-$DFFF I/O space. When the RL hardware is not active,
you see whatever is normally at $DE00 and $DF00.
Keep on Hackin'!
-Craig Bruce
csb...@ccnga.uwaterloo.ca
"Never underestimate the power of a simple tool."
Bruce McFarling
> >New header, same query: what are the register addresses of the RAMLinK?
> >We don't need a functional breakdown, just the range of addresses used.
>
> That's a bit of a trick question, but when the RAMLink hardware is active,
> it asserts a peephole page window at address range $DE00-$DEFF in the I/O
> space, and it asserts its control registers and your REU registers (if you
> have one) in the $DF00-$DFFF I/O space. When the RL hardware is not active,
> you see whatever is normally at $DE00 and $DF00.
The REU control registers are not a problem, as we have to
sidestep them anyway (and we only need four addresses). But do
Iunderstand 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?
Bruce McFarling, Knoxville
br...@utkux1.utk.edu
Todd S. Elliott
>Unless the SwiftLink is _active_ while you are using Buddy, where the SL
>usually is NOT active when you are not inside of a terminal program, then
>you are having some different problem. I use Buddy with everyday with my RL
>and I have no problems. Of course, Buddy becomes quite disturbed if you
>mess with page $c00 while it is wedged into BASIC.
>
other assemblers. One interesting thought- Does Buddy use the $de00
address range which may conflict with the RAMLink? (Please forgive me as I
don not know accurately which address range that the RAMLink uses) From
what I understand, Buddy is under BASIC, and is called upon action by
common ram entry point.
Thanks for the tip.
Todd Elliott
tsel...@gate.net
Michael Bendure
: I heard of this problem from a couple people and it is easily worked around.
Okay, brag, brag.. We still need to test it on the RMMLink.. Hurry
up and get those maintenance files done so we can test it out.. :)
Just kidding, or am I? :) Nice to see you on here, this is the second
message in here that I've seen from you..
Adam Fanello
BE> New header, same query: what are the
BE> register addresses of the RAMLinK?
DS> $de00 - $de26 are the published addresses, and they are only visible
DS> when Ramlink is mapped in - which maps out the original $de00 -, so
DS> you can have another cartridge at that same address, at other times. I
DS> have a cartridge using $dexx plugged into my Ramlink, and there is no
DS> conflict.
Okay... Do you know how to map the RAMLink in and out, and how to detect if it
is currently in or out? (That sounds like what I'm looking for
in my prior post about the SwiftLink interupting the RAMLink.)
Lonnie McClure
In a recent message in the CMD category on GEnie, Doug at CMD posted that
a new custom GAL chip will soon be available for the RAMLink that will
allow the SwifLink to coexist with an REU in *direct mode* while both
are plugged into the RAMLink (i.e., no mods to the RAMLink or port
expanders required).
David Schmoll
AF> Okay... Do you know how to map the
AF> RAMLink in and out, and how to detect if it
AF> is currently in or out? (That sounds like what I'm looking for
AF> in my prior post about the SwiftLink interupting the RAMLink.)
I haven't hacked around with RL as much as Craig Bruce has, but
according to my notes you switch in the RL registers with a write to
$df7e, and turn them off with a write to $df7f. Ramlink is normally
only triggered when there is serial activity, or I think more precisely
RL disk activity. The person to ask is either Mark Fellows or Doug
Cotton. Mark Fellows was the one to help me on the above registers.
The RL manaual also list a two sys addresses that map in the RL
hardware and allow access to RL memory and 4 sys addresses to disable
the hardware and memory - some turn off interupts, some do not. When RL
is mapped in the entire Kernal is swapped, and since it is swapped
simply comparing against a know fixed value at the right location would
tell you it was swapped, but I have not had a reason to ever do such a
check, so I don't have any specific location to reccommend off hand. I
would think there is probably an official location for this check, and
that is what your asking for, but I don't know it. I'm hoping Doug
Cotton jumps in on this so we can all learn this information. :)