[Coco] SCS Line (or others?) - Atmega Microcontroller monitoring

[Chad H]

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.


- Chad H
http://sites.google.com/site/cbhlab101/


-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Chad H
Sent: Saturday, October 17, 2015 7:27 PM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: [Coco] SCS Line (or others?) - Atmega Microcontroller monitoring

Ok, for those who ever might be interested in monitoring the SCS line as a 'trigger' or anything else from a Atmega328 (or similar) microcontroller) , this is just a little note that might save you from the ordeal I just went
through the past 4 hours.   I had a 'alpha' build of my controller board and
I wanted to jury rig it so I could test how the Atmega would read the SCS line.  Here are the results in order tried..

 

1.       Attempt analog read by unused Atmega pin (A6 or A7).  Tried with
and without 10K pullup resistor (SCS pulls low to ground so looking for the drop).

Ran a monitor in the main loop.

 

Result:  Atmega barely seemed to notice the SCS being pulled down to GND, even in a BASIC loop on the CoCo.

 

2.       Tried using a digitalRead() or a analogRead() with different
trigger ranges

 

Result:  Pretty much the same as in #1.

 

Realized I had to get the Atmega to listen more closely to the very very brief time period the SCS was actually pulled low, so using the analog/digital reads in the Loop() might be insufficient to catch it.

 

 

3.       Decided to use the attachInterrupt method and look for a LOW
condition.  Problem was the only 2 pins on Atmega328 capable of this (digital 2 and 3) were tied up by my LCD display.  Solution:  Cut trace on
digital 2 and route to a free analog pin instead.   Test display before
continuing.

 

Result:  Temporary failure.  Tried A6 for LCD but doesn't support output mode to drive the LCD.  Rerouted to push-button leg that was attached to A5
(button was un-needed for these tests).   LCD starts working again.  Proceed
to #4

 

4.       Used attachInterrupt on Digital 2 attached to the SCS line.
Readings were unpredictable without pullup resistor.  Attached 10K pullup to VCC to keep the line HIGH until the SCS line was triggered LOW by the CoCo.
Increment a counter by 1 every time the SCS triggered and display current value on LCD in the Loop() so can see when it's changed and by how much.

 

Result:  The  CoCo BASIC loop (10 X=PEEK(&HFF40):GOTO 10)  caused the counter to take off.  Inserted a INPUT in the loop so I could press <ENTER> for the next PEEK trigger.  This caused the interrupt on the Atmega to fire once and only once.  So far I have yet to see it miss an event when the PEEK
is performed by the CoCo.   * PROBLEM SOLVED *

 

 

Now I have to tweak my PCB's a little to use the different Atmega pins and should be set to order the next batch J

 

 

- Chad H

http://sites.google.com/site/cbhlab101/

 


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