Fwd: Re: Wireless - switchless kernal mod

From: earth1dome1 <earth1dome1_at_yahoo.com>
Date: Wed, 18 Apr 2018 15:18:29 -0700
Message-ID: <fm14jjy3xx9ep47xf93e7afd.1524089909743@email.android.com>
Terry your right I think. But Jim right busy with other projects and a journey to some other place. Jeremy

Sent from my T-Mobile 4G LTE Device-------- Original message --------From: Terry Raymond <traymond160@gmail.com> Date: 4/18/2018  08:25  (GMT-08:00) To: cbm-hackers@musoftware.de Subject: Re: Wireless - switchless kernal mod 
Hi,Correct Jim Brain I believe is the only active distributor right now forJiffy-Dos.www.store/go4retro.com
I think is the URL to his shop.
Terry Raymond

On Thu, Apr 12, 2018, 6:01 PM Nejat Dilek <imruon@gmail.com> wrote:
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
Received on 2018-04-19 10:00:03

Archive generated by hypermail 2.2.0.