- Not every access triggers an interrupt on attiny85
Solved by going up from 6.44mhz to 16mhz.
- /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
PS: JiffyDos there is not licensed btw. It's there just for
demonstrational purposes. I know it's still a product that's being
On Tue, Apr 10, 2018 at 6:53 PM, Nejat Dilek <[hidden email]> wrote:
> On Mon, Apr 9, 2018 at 8:44 AM, <[hidden email]> wrote:
>> On Montag, 9. April 2018 02:05:43 CEST Nejat Dilek wrote:
>>> On Tue, Apr 3, 2018 at 7:44 PM, Mike Naberezny <[hidden email]> 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
> 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;
On 4/18/2018 5:18 PM, earth1dome1 wrote:
> Terry your right I think.
There are a few licensed JD sellers, listed on
> But Jim right busy with other projects and a journey to some other place.
Well, I am busy all the time, but orders placed in the store get
fulfilled in a timely manner.
That said, I think the OP was just clarifying for folks that he burned
JD to test with, which seems fine to me.
> On 4/18/2018 5:18 PM, earth1dome1 wrote:
>> Terry your right I think.
> There are a few licensed JD sellers, listed on
>> But Jim right busy with other projects and a journey to some other place.
> Well, I am busy all the time, but orders placed in the store get
> fulfilled in a timely manner.
> That said, I think the OP was just clarifying for folks that he
> burned JD to test with, which seems fine to me.