[Coco] Coco Digest, Vol 155, Issue 42

[Chad H]

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