exxos's Atari, Amiga & retro forum

great progress.

terriblefire wrote: 09 Oct 2020 22:48 great progress.

Unfortunately that what I could get. confirm RTC_SEL only.
Any attempt with putting anything on the data bus from arm GPIOs crashes CD32. (Like we had before when trying to overwrite mouse values)
I think I can't read correctly RW signal and ARM put data in wrong time, messing with data bus.
I see Write on Memory monitor, even when I just look what on those locations.

I am not letting go that quickly with this.

I have changed crystal from 8Mhz to 25Mhz, this allows me to configure speed of core to 216Mhz.

This should give me interrupt latency of 190ns, I will try to skip library and operate directly on registers, and set up compiler for preformance, if this will not let me do what I need then I will try set up DTACK for some cycles.

If I won't be able to get this working, I will try to learn verilog enough to do it in cpld. stm32 would be simply just data source and heavy lifting would be done by CPLD.

@terriblefire

I have tried everything what I could to place data on the bus, but Amiga doesn't like it at all.
I simply can't sync with bus.

I have tried the same from cpld and some data was visible in monitor.

Do you think I could have registers on cpld, and refresh it using SPI from ARM? Does this sound like reasonable solution?
I was thinking of similar idea for overriding mouse movements?

That will work as per my exemplar however you are going to run out of macrocells in that CPLD quickly.

terriblefire wrote: 11 Oct 2020 21:35 That will work as per my exemplar however you are going to run out of macrocells in that CPLD quickly.

...and 144 macrocell version doesn't come in 64pin package :(

EDIT
Anyway I am doing this for fun, so I will be doing this in pieces RTC or Mouse etc :D

arkadiusz.makarenko wrote: 11 Oct 2020 22:06

terriblefire wrote: 11 Oct 2020 21:35 That will work as per my exemplar however you are going to run out of macrocells in that CPLD quickly.

...and 144 macrocell version doesn't come in 64pin package :(

EDIT
Anyway I am doing this for fun, so I will be doing this in pieces RTC or Mouse etc :D

The alternative is to have the CPLD latch the data bus and make it wait until the data is off the bus from the arm before it asserts DTACK.

i.e.

1. CPLD recognises the bus request and triggers an interrupt on the ARM.
2. ARM puts data on data bus.
3. ARM asserts the acknowledge.
4. CPLD latches the data on the data bus.
5. ARM removes data from the bus.
6. ARM disasserts the acknowledge.
7. CPLD puts data on the data bus and asserts DSACK0.

I'm just checking something...

You absolutely cannot use DSACK0 from the ARM. It will never release the signal in time before. There is an internal signal between the ARM and the CPLD to get it to respond for you.

terriblefire wrote: 12 Oct 2020 14:59 I'm just checking something...

You absolutely cannot use DSACK0 from the ARM. It will never release the signal in time before. There is an internal signal between the ARM and the CPLD to get it to respond for you.

Does it mean that we can place data on the bus, but control signals need to be controlled over CPLD?
So what need to happen on cpld and side to check this?

arkadiusz.makarenko wrote: 12 Oct 2020 15:39

terriblefire wrote: 12 Oct 2020 14:59 I'm just checking something...

You absolutely cannot use DSACK0 from the ARM. It will never release the signal in time before. There is an internal signal between the ARM and the CPLD to get it to respond for you.

Does it mean that we can place data on the bus, but control signals need to be controlled over CPLD?
So what need to happen on cpld and side to check this?

Can you push/send what you currently have for the CPLD / arm code somewhere i can look.