Hello, Guest the thread was called80k times and contains 902 replays

last post from Sjaak74 at the

Kung Fu Flash Cartridge

    rayden,


    Regardless of the disk insertion support, it looks to me like Retro Replay support might be challenging. Have a look here:

    https://sourceforge.net/p/vice…rc/c64/cart/retroreplay.c

    It looks to me like there is a lot happening on a write to $de00/$de01. It might be too much when using C for the KFF's ARM cpu to be able to handle in one interrupt.


    I think the KFF easyflash and action replay drivers are on the edge of amount of cycles available.

    But there is still some optimization possible if you carefully code the C and tune for your gcc version / optimizer. Changing from if-statements to switch-statements can make large differences in worst-case speeds of the interrupt. The C-compiler can create jump tables sometimes, this is much slower than without jump table.


    From experience building the KFF soft-kernal driver though, if you spend time optimizing the ARM assembler it will probably be possible to fit Retro Replay with some limitations.

    There are some optimizations the C compiler doesn't consider that make quite a difference on the interrupt duration. (like re-using address constants)


    The Easyflash disk support not only depends on the 3 $de00 range USB registers of easyflash, but also on 256 bytes of RAM in the $df00 range for trampolining (turning on/off the easyflash rom banks during disk accesses). Combining that again with another cartridge seems very difficult.

    Quote from merlintwa

    It looks to me like there is a lot happening on a write to $de00/$de01. It might be too much when using C for the KFF's ARM cpu to be able to handle in one interrupt.

    That's true. But you do not need to emulate everything. The logic to update the lash rom from Retro Replay is not needed.


    When writing the expert code I encountered the same issues. Even reordering the statement can mesh things up very badly. Any tips of constructs in the if-else or switch/case stuff that compiles in fast code? Prolly asm is the best way to do it...

    Quote from fepo

    If I want to update the firmware,

    I only need to save the * .upd on the SD card

    and when I switch on the C64,

    the module then updates itself to the new firmware.

    Is that right ?

    No, you will have to select the *.upd file in the menu of the cartridge.


    EDIT: Select it, press enter and then start the update. This way, you can have multiple versions on your SD card and switch between them. Also, you can keep them in a folder of your choice.

    I prefer the way from bigby , or is this way wrong?

    Sorry, but what is the Launcher ?

    When i start the Kung Fu Flash it switches to the Menu.



    Edit: I have read this on C64 WiKi .

    • Die Firmware kann einfach über den Filebrowser aktualisiert werden. (UPD-Datei)
    Quote from Sjaak74

    When writing the expert code I encountered the same issues. Even reordering the statement can mesh things up very badly. Any tips of constructs in the if-else or switch/case stuff that compiles in fast code? Prolly asm is the best way to do it...

    Well I've encountered SD card instability on my fork, which now seem only to have been caused by a few constant GPIO addresses and pins to have different values, causing the compiler to have a few cycles (I think no more than 3 cycles longer) interrupt, which is enough to cause occasional SD card buffer underruns. So yes the compiler is very sensitive.

    In fact, if you change other parts of the code and alignment of the interrupt handler changes by 2 bytes, then you can easily see 3 cycles difference for the interrupt duration even if the ARM assembly code is identical.


    I look at the generated assembly in the output list file in the build dir and check for funny behavior there.

    I also measure everyhing with an oscilloscope, change some pin to a value at the end of the interrupt. And check the data signal eye.

    Also I use the DWT->CYCCNT or even better TIM1->CNT and dump its content at the end of the interrupt to a memory location I can monitor live with the ST-link. With min-max detection as well.


    The documentation about how long every instruction takes from ARM is not the whole story, ST has added delays on the external busses that slow the CPU down.


    In general: Check the generated assembly listing in detail always, try to move around statements to use less registers, use case statements that are not too large. A single branch even if taken is pretty fast thanks to the ARM's speculative branch fetch, but a taken-branch followed by compare followed by taken branch is very slow. The speculative fetch doesn't work if the prefetch buffer is empty


    The interrupt latency at the start is also very though to get under control.

    I've had to pull every trick I could think of and use assembly now to get the soft-kernal stable and working across several boards. But I'm in the final stages of that, and as it is now fully in assembler I've made sure changing the GPIO constants doesn't change the interrupt delay.


    Feel free to PM me if you want to go into more details.

    Moin,


    wohl eine eher ungewöhnliche Frage zur Hardware, eines meiner Kung Fu Flash sitzt in einem

    gelben Gehäuse und hat eine rote LED, zudem war die LED auch sehr Hell.


    Da habe ich so geändert das ich dort ein Kung Fu Flash mit grüner LED einbaut habe, damit

    passt das dann auch, die grüne LED im gelben Gehäuse sieht gut aus, Helligkeit stimmt auch.


    Dann habe ich mir von Reichelt SMD LED's besorgt (Gelb, 120 mcd) und gegen die rote LED

    getauscht, ist für ein blaues Kung Fu Flash gedacht.


    Das Ende vom Lied, ich habe den Vorwiderstand mittlerweile auf 220 Ohm verringert, aber

    die LED ist immer noch nicht ausreichend Hell. (Ist doch R1, oder ?).


    Nun stellt sich mir die Frage welche LED (mcd) dort zu empfehlen ist?


    Luxusprobleme!


    Mfg Jood

    Thanks for your answer,


    but im not looking for the value of resistor (R1), i am searching for the right type of LED,

    currently i have 3 Kung Fu Flash, blue, yellow and red.



    the blue one has an yellow LED (R1 = 220 Ohm), brightness is really weak,

    yellow has an green LED (R1 = 510 Ohm), brightness is ok and the red one

    has a blue LED (R1 = 510 Ohm), brightness seems also a little weak.


    Mfg Jood

    Quote from Jood

    but im not looking for the value of resistor (R1), i am searching for the right type of LED,

    currently i have 3 Kung Fu Flash, blue, yellow and red.

    (color) LEDs are made from different (organic) materials, each leading to their own combination of forward voltage somewhere usually in the 2.4-3.0 V range, and perceived brightness in cd depending on the current injected. That depends on temperature as well.

    You can really only pre-calculate these know if you have the datasheet for the LED you've ordered, then calculate the required brightness from the specification looking up the current that should flow. You can then calculate the resistor value independently per ordered LED using 3.3V - Vledforward=Iled * R1

    In practice LED's from China are produced in bulk quantities, and LEDs from one batch are very close to each other, but the spec per batch varies quite a lot. Producers then "bin" (= select ones with similar stats) then into different product ranges. Premium LEDs and el-cheapo leds only differ in this "bining", having a smaller set of variation. But all LEDs come from the same few huge factories.

    The el-cheapo ones just are whatever the've got left over in the warehouses, and typically you simply adjust the resistor to your taste as you can never be 100% sure what specs the LED will have. When you order say 100 of the same LEDs, you will be 100% sure those 100 come from the same batch of production so will have the same specs. But ordering the same cheap led with a month delay you can get something wildly different.


    Just be sure to measure (with a multimeter) the current through the LED (and as a result the STM32) to be below the max the LED and STM allow. For the STM32 its max rating per pin is 25mA - when used to sink current to ground, for this particular pin. The STM32 spec mentions you cannot use this same pin to source current (from 3.3V) to more than 3mA, but that mode is not used on the PCB.

    Hello,


    is the circuit board from me still in the red housing (with red pcb)?

    Because there should also be a red LED on the red circuit board.



    Here are a few more pictures of red and blue in PLA and one in PETG.

    The PETG is much better in terms of lightproofness.

    all LEDs with 510 Ohm resistor


    according to the friendly chinaman, the red LED in the red housing should have 120-150mcd.

    I don't have any information on the blue ones and the green LED is from a KFF I bought from ronduc - maybe he can help

    Quote from Starquake

    according to the friendly chinaman, the red LED in the red housing should have 120-150mcd.

    I don't have any information on the blue ones and the green LED is from a KFF I bought from ronduc - maybe he can help

    Die hatte ich aus China gekauft und die Helligkeit mit dem Widerstand angepasst. Keine Ahnung was die für "mcd" hatten.