Re: Wireless - switchless kernal mod

Finally I was able to get it work :)

https://www.youtube.com/watch?v=OBxgCRnvcg8

Solved problem,

- Not every access triggers an interrupt on attiny85
Solved by going up from 6.44mhz to 16mhz.

Remaining problems,

- /KERNAL chip select signal is toggling between high and low even if
all interrupts are disabled and cpu doesn't access kernal. VIC is also
in default bank. Temporarily I used /BASIC signal from PLA.
- Selection doesn't work sometimes. (May relate to interrupts missing problem)
- EXOS kernal just displays M-R. (Possible timing problem or some kind
of protection?)

Regards,

Nejat


PS: JiffyDos there is not licensed btw. It's there just for
demonstrational purposes. I know it's still a product that's being
sold.

On Tue, Apr 10, 2018 at 6:53 PM, Nejat Dilek <imruon@gmail.com> wrote:
> On Mon, Apr 9, 2018 at 8:44 AM,  <afachat@gmx.de> wrote:
>> On Montag, 9. April 2018 02:05:43 CEST Nejat Dilek wrote:
>>> On Tue, Apr 3, 2018 at 7:44 PM, Mike Naberezny <mike@naberezny.com> wrote:
>>> > I used an AVR pin change interrupt to detect an edge on a past project.
>>> > The code was in assembly.  The AVR has a large number of working
>>> > registers so I reserved one of them for the pin change interrupt service
>>> > routine.  The very first instruction of the ISR, before preserving
>>> > registers or anything else, was to read the port into that dedicated
>>> > register.  This was to capture the state of the pin as close in time as
>>> > possible to when the edge occurred. The ISR would then compare the value
>>> > to detect the edge and either continue or bail out.
>>> >
>>> > Source code:
>>> > https://github.com/mnaberez/vwradio/blob/b06c3a95f9b345dc4330cc3a8751b3f62
>>> > 44829ba/avr_volume/firmware/m62419fp_spi.asm#L50-L61
>>> >
>>> > This is only an approximation of edge detection.  Several processor cycles
>>> > will occur between the edge and that first instruction of the ISR
>>> > capturing
>>> > the port value.  The pin may change state again during that time.  In my
>>> > project, the signal I was sampling was slow enough that this was
>>> > acceptable.
>>> >
>>> > Regards,
>>> > Mike
>>>
>>> Nice clever approach! I'm familiar with the syntax but I never handled
>>> these microcontrollers with only assembly. So I'll definitely go along
>>> the C route even if I hate soldering bodge wires.
>>
>> You can have an example of a mixed ASM/C approach here https://github.com/
>> fachat/XD2031/tree/master/firmware/xs1541 in atn.S where I use the pin change
>> interrupt to detect the ATN line going low. The few following assembly code
>> lines set DATA / NRFD low like the 1541's/2031's XOR gates on the IEC/IEEE bus
>> would do so the C64/PET does not trigger on a "device not present". All the
>> rest of the code is in C.
>>
>> In the interrupt I only save the registers that are necessary in the interrupt
>> routine, which makes it rather small and fast.
>>
>
> Well I'm only familiar with the syntax actually :) Out of laziness, if
> possible I prefer the shortest route that is possible. Of course there
> are side advantages like portability, readability and ease of
> maintenance.
> In this project speed is the last priority and I want to avoid strict
> timing requirements.
>
> Bu these are good options, the last time I used inline assembly was to
> sync to the PAL C64's clock with an Atmega328 with such a construct.
>
> #define WAIT_1_CYCLE asm("nop\n nop\n nop\n nop\n nop\n nop\n nop\n
> nop\n nop\n nop\n nop\n nop\n nop\n nop\n nop\n nop\n")
> #define WAIT_2_CYCLE WAIT_1_CYCLE;WAIT_1_CYCLE;
> #define WAIT_3_CYCLE WAIT_2_CYCLE;WAIT_1_CYCLE;
> #define WAIT_4_CYCLE WAIT_3_CYCLE;WAIT_1_CYCLE;asm("nop\n");
> #define WAIT_5_CYCLE WAIT_4_CYCLE;WAIT_1_CYCLE;
>
> Regards,
>
> Nejat