[Coco] Coco Digest, Vol 155, Issue 42

Sun Oct 18 01:20:59 EDT 2015

I don’t think so.  These are 8K/16K ROMs on a EEPROM.  If they were looking for $FF40 control I think they would not get the 'pages' they were expecting and not function? Atom(16K) and Downland (8K) are not very big ROMs.    My best guess is they are storing information here ... all RAM mode?

- 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 11:50 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Coco Digest, Vol 155, Issue 42

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
>

--
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