exxos's Atari, Amiga & retro forum

:) I managed to do my best, I managed to improve things quite a bit.
I managed to measure some stuff. So interrupt latency is about 400ns. This is the time that it takes to get to start executing the code, then I need to clear the flag etc.

But I did find a bug in release routine so managed to save some time there as well. I trimmed some time on write data, read address routines etc.
Now I can measure (cheap analyser btw) between 1.2 and 1.6us. Not too bad as I started from 7us.

I have noticed that my new keyboard routine disappeared :(. Need to port it from different project branch. I will try to trim a little bit more but I don't see much more that could be speeded up. (I will have a look at different flash memory driver as it has prefetch, maybe this will help as well.)

BUAHAHAHAH
With enabled ICache i DCache
Sub 1us on average, some are slow up to 1.4us, but I average are below 1us.
EDIT: I optimized some if statements to switch-case and grouped some. This reduced time by a little. All cycles 0.7-1.2us. Good enough :)


Still need to look at flash prefetch.
EDIT : TCM Interface is slower on F72x and F73x, so I will skip this bit, documentation is rarely clear about this stuff but here it is back on white, so AXI Interface is apparently the best for those devices.

@kulamario
Superfrog and Turrican 3 fix

Now everything looks fine
I would also like to suggest a change in the schema such a solution would extend the battery life

kulamario wrote: 05 Jan 2021 02:20 Now everything looks fine
I would also like to suggest a change in the schema such a solution would extend the battery life
Image2.jpg

It will make no difference and it being missing gives more cell type options. (i.e. it was removed based on the manual recommendation).

kulamario wrote: 05 Jan 2021 02:20 Now everything looks fine
I would also like to suggest a change in the schema such a solution would extend the battery life
Image2.jpg

Agree with TF, it is already done internally in STM32.
Diode is there only because during domain switch there might be power going back to battery, and if battery cannot handle charge it has to be protected.

Another day trying to speed ARM<=>Amiga up a little. But no more luck today.
Generally without changes on hardware side like faster stm32, Address lines connected in a way that address it would be 1 read without shifting bits into right position, 16bit data bus maybe? and this kind of stuff I can't see any more room for improvement - maybe rewriting routines to arm assembler could gain some speed, but I think not that much as bottleneck now I think is on hardware side.
Anyway, it is not that slower (mouse data read/writes not whole computer) maybe 20% on most cycles - very occasionally double (1.2us)
Fact that Amiga CPU need to be exactly timed with external STM32 and communicate only via 8bit part of the data bus, I guess it is quite achievement anyway to even get to those results.

For me it is good enough now, time to look at few smaller bugs now, and port new amiga keyboard routine.

arkadiusz.makarenko wrote: 05 Jan 2021 22:15 For me it is good enough now, time to look at few smaller bugs now, and port new amiga keyboard routine.

Agreed. If its on average 1uS thats fine. 3uS is less fine because things use the CIA to time things sometimes and assume about 1uS. So a 1 second delay could become 3 seconds. Its naughty to do this but some driver code does this.

10 PCBs arrived! I moved battery like 1mm to the left.
I should have parts for 4 of them, need to prepare BOM etc.

Looks nice!
is this the final version or some updates/optimisations will follow?
Thinking about to get small batch of them..
Thre are some discussions on A1k, people are very interested, we'll need some tweaks to get it work with D520 though cause DB23 isn't fully routed..