Re: Weird /KERNAL line on old boards

On Tue, Jul 10, 2018 at 8:54 PM,  <silverdr@wfmh.org.pl> wrote:
>
>
>> On 2018-07-09, at 00:59, Nejat Dilek <imruon@gmail.com> wrote:
>>
>>> Or require a longer _KERNAL pulse than this false pulse?
>>
>> How? I use this pulse to interrupt an attiny85. Even if I check for
>> the signal again in the interrupt it's all open to every kind of race
>> conditions since this false signal pops up quite randomly (unless
>> tamed) before and/or after intended access.
>As long as the assumption is that valid pulse is always longer than the longest spurious one, you can use the "software debouncing" - similar to what is sometimes used to debounce relatively fast switches, without adding significant capacitance, Schmitt triggers, etc. I used it more than once with good results.
>

In my tests I encountered 500ns pulses too but I can't confirm it
before doing another test.


>> Side note : I don't want
>> to code this in assembly, I prefer C if I can :)
>
> It can be done in C :-)

I have a timer interrupt too which complicates things a bit.



On Tue, Jul 10, 2018 at 9:06 PM, Mia Magnusson <mia@plea.se> wrote:
> Den Mon, 9 Jul 2018 01:59:35 +0300 skrev Nejat Dilek <imruon@gmail.com>:
>
> If the CPU is fast enough to reliable sample the input not longer than
> 500nS and not shorter than 41nS after an interrupt has been triggered,
> a software solution would work. If the input isn't active after 41nS
> but before 500nS, just ignore the interrupt and be sure to return to a
> state accepting interrupts fast enough so it can trigger on a real
> pulse.

I'm using 16mhz internal clock with Attiny85, sure it's fast but it
has a big interrupt latency.
I also have another timer interrupt going on. Making the two
interrupts behave in this scenario would be a bit problematic.

>
>> Any other hardware means to filter out 41nsec pulses from 500nsec
>> pulses by the way? (Hmm, maybe using some logic gates with >41nsec
>> propagation delays)
>
> A simple low pass filter will do. 500nS is more than 10 times longer
> than 41nS so even a simple 6dB/octave RC filter should do the trick.

Tested this with 10pf capactior and 1.5K resistor, used an online
calculator for 10mhz cutoff frequency. Signal looked clean on the
logic analyzer but it didn't work.
Is this cutoff frequency reasonable?

>
> Depending on the signal quality requirements on the interrupt input you
> might need a schmidt trigger (a 74xx14, 4093 or similar) between the
> low pass filter and the interrupt input.

I'll test this too just for the sake of it. If simple RC worked though
it would be a better candidate than using a 74hc1g32 2 input or gate.


On Tue, Jul 10, 2018 at 9:43 PM, Jim Brain <brain@jbrain.com> wrote:
> On 7/10/2018 12:54 PM, silverdr@wfmh.org.pl wrote:
>>
>>
>>
>> As long as the assumption is that valid pulse is always longer than the
>> longest spurious one, you can use the "software debouncing" - similar to
>> what is sometimes used to debounce relatively fast switches, without adding
>> significant capacitance, Schmitt triggers, etc. I used it more than once
>> with good results.
>
> I think it will require moving from an interrupt driven approach on the AVR
> (used now), to a polling approach:
>
> while(PINC & _BV(PIN5)) {} // or whatever
> if(!(PINC & _BV(PIN5)) {
>  // real signal.
> }
>
> An instruction on the 16MHz AVR takes at least 62.5nS, so the next
> comparison will push you beyond the 42nS issue.
>

I also have a timer interrupt. I just can't pile the whole resources
of the cpu to deal with this task. I want to port this hardware and of
course the firmware to be used along with other machines like Amiga.
If I go down the route of writing very strict timing spesific code
than it would be harder for me to port and maintain the code.

By the way, I still have hope that I could pull this off using c64
software without extra hardware & without changing the attiny85's
firmware. It's possibly related to one or more input term of this
below equations which I might workaround with a clever routine.

!KERNAL = (_HIRAM  & A15  & A14  & A13  & !_AEC  &
               R__W  & _GAME
             # _HIRAM  & A15  & A14  & A13  & !_AEC  &
               R__W  & !_EXROM  & !_GAME );


I've not measured yet but I suspect the culprit here is _AEC. If I
change the _HIRAM using process port I know both selections doesn't
occur. It's not a switching signal. _GAME is pulled up and it's also
not a switching signal. The finding with the badlines directly
suggests that _AEC would be the culprit. Address lines here possibly
not controlled by either VIC or 6510 so they are pulled up. For this
problem to occur, VIC should be leaving the bus to the 6510 a little
bit late possibly.

Some possible routes :
a. Try to time a routine around VIC tricks as smf suggested earlier. I
don't think this would alone be a solution. This phenomenon occurs
when either VIC or 6510 doesn't master the bus. VIC can't see kernal
rom so the accesses should be made by the cpu, upon VIC leaving bus to
the 6510 this spurious access will occur. When AEC is low CPU can't
access the bus, other times it's always toggling (to share the bus
between VIC and 6510) causing this phenomenon.
b. Do not generate extra kernal read access to assert /KERNAL but just
use this unintended 41ns selection. This would be a solution if
Attiny85 can sample that 41ns pulse.

I don't see any other c64 side software solution by the way if negated
AEC signal is indeed the culprit. (This changes the tone of my above
hopeful sentence as I've both written and contemplated about it)

Regards,

Nejat