[Coco] Coco Digest, Vol 155, Issue 42

Sun Oct 18 00:49:45 EDT 2015

Well, there were a FEW large ROM games from Tandy that used internal
banking schemes where bank switching was controlled by (I think) $FF40.
Could that be what you are seeing?

Art

On Sun, Oct 18, 2015 at 12:22 AM, Chad H <chadbh74 at hotmail.com> wrote:

> That's just it...there is no problem.   The drive activity/light going out
> after a few seconds is a function of DISK BASIC (or HDB-DOS, etc).   It's
> like when you LOADM a .BIN and EXEC before the light goes out...then it
> never does because you didn't give the DOS time to shut it off.
>
> I was merely pointing out a curious behavior I noted on some ROM games.
> They don’t seem to require a disk controller, yet they are continuously
> triggering the SCS line.  There are many ROMs where I can turn on the CoCo
> and boot into the rom and the SCS never triggers at all the entire session.
>
> What I'm using the SCS for happens BEFORE programs get executed.  By that
> point the microcontroller is ignoring all future SCS signals.
>
> - Chad H
> http://sites.google.com/site/cbhlab101/
>
>
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Arthur
> Flexser
> Sent: Saturday, October 17, 2015 10:58 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] Coco Digest, Vol 155, Issue 42
>
> I'm not much of a hardware guy, so I may be way off on this, but....
>
> It is not uncommon for programs to store a zero into $FF40 at some point
> in order to turn the drive light off after a LOADM, particularly if the
> program disables interrupts, or substitutes its own service routine,
> thereby preventing the countdown usually present in IRQ servicing that
> would shut off the drive light when it hits zero.  Could this be what is
> causing the problem?
>
> Art
>
> On Sat, Oct 17, 2015 at 11:10 PM, Chad H <chadbh74 at hotmail.com> wrote:
>
> > I get what you guys are saying, but gating the SCS by way of the
> > E-Clock would add complexity to the PCB when it's already crammed.  So
> > far my Atmega is telling me that the SCS is not misbehaving at
> > startup.  Many ROM's, even after loaded, don't even trigger a single hit
> from the SCS.
> > It's only some programs that are.  My needs for the SCS are very
> > limited and very specific, enough that all the other E-Clock related
> stuff
> > shouldn't be an issue.   If I can boot the CoCo, have the assembly read
> in
> > the .BIN data, then ignore all future SCS signals (if any), I'm good.
> > The only thing that I can think of at this point that would throw a
> > wrench in it would be if some odd .BIN file attempted to write data to
> > the address range that trips the SCS..  I can't imagine why using
> > LOADM on a .BIN would do this (excluding the obvious disk controller
> > access of LOADM of course), or even a CLOADM of a .BIN.  Once  the
> > Power-UP/RESET has been done, the .BIN loaded and executed, the
> > controller will care less what the SCS does until the user activates
> > another EEPROM bank that is also a .BIN and repeats the process from the
> beginning.
> >
> > Again, I understand what you guys are saying, but I'm just not seeing
> > this behavior during the specific situation that I will care about the
> behavior
> > of the SCS.   I'm sure I would have no choice but to deal with the
> E-Clock
> > if I was performing page loads or such communication between the CoCo
> > and the microcontroller, but that's not what's happening here.  The
> > assembly loader is loading data in from the &HC000 ROM space, not
> through some
> > &HFF40+ vectors.   The &HFF40 is only read by the assembly at the end of
> > each 8K segment in order to trip the SCS and signal the controller to
> > switch to the next 8K page for the &HC000 ROM space.
> >
> > - Chad H
> > http://sites.google.com/site/cbhlab101/
> >
> >
> > -----Original Message-----
> > From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Barry
> > Nelson
> > Sent: Saturday, October 17, 2015 9:30 PM
> > To: coco at maltedmedia.com
> > Subject: Re: [Coco] Coco Digest, Vol 155, Issue 42
> >
> >  Like Darren A said below the state of the SCS line is undefined
> > except when E is high, even during relatively brief times when you
> > would not expect it. It is suggested that you always check E=HIGH
> > before reading the SCS line, otherwise you may get strange unexpected
> > results when you least expect it.
> > > Well that may be what's happening with the games.  For my purposes I
> > still think the SCS alone should be enough for what I'm wanting to
> > accomplish.  As I said, the SCS status will be ignored at all times
> > EXCEPT when a .BIN has just been loaded.  Once the .BIN load has been
> completed,
> > the SCS will again be ignored.   There's no reason for the SCS to be
> > triggered for any reason from power-up during the .BIN loading process
> > EXCEPT by the assembly loader signaling the end of the 8K segment.
> > >
> > > - Chad H
> > > http://sites.google.com/site/cbhlab101/
> > >
> > >
> > > -----Original Message-----
> > > From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of
> > > Darren A
> > > Sent: Saturday, October 17, 2015 8:48 PM
> > > To: CoCoList for Color Computer Enthusiasts
> > > Subject: Re: [Coco] SCS Line (or others?) - Atmega Microcontroller
> > > monitoring
> > >
> > > On Sat, Oct 17, 2015 at 7:01 PM, Chad H wrote:
> > >
> > > > P.S.  I'm observing already that several of my ROM/BIN games seem
> > > > to be triggering the SCS a lot while running.  I thought it might
> > > > be games that use joysticks but Color Baseball doesn't trigger any
> > > > SCS
> > events, neither
> > > > does 8-Ball.   I was already going to have my controller ignore SCS
> > events
> > > > except for when it's loading .BIN segments, so this won't be a
> problem.
> > > > Just curious is all.
> > > >
> > > > games already seen to trigger the SCS line include..
> > > >
> > > > Atom (Still don't know how to play this one) - my SCS trigger
> > > > increment counter is going slow and steady on this one.
> > > > Downland - Its running pretty fast on this one.
> > > >
> > >
> > >
> > >
> > > You should not rely on SCS alone. It should be gated with the E
> > > clock
> > and only recognized as a valid access when SCS is low and E is high.
> > False triggers of SCS can occur while E is low and the address bus is
> > transitioning.
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6172 / Virus Database: 4447/10838 - Release Date: 10/17/15
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>