Hello, Guest the thread was called11k times and contains 243 replays

last post from Peto74 at the

Unicart64 - The FPGA based cartridge for Commodore 64

  • my results for testing fw post#138


    without sd-card:
    12 times red, 25 times black, 13 times blue


    with sd-card:
    8 times white, 16 times black with short white stripes, 2 times black, 0 times green


    the last time i tried to flash some image on my 250407 it says something like hw error

  • without sd-card:
    12 times red, 25 times black, 13 times blue


    with sd-card:
    8 times white, 16 times black with short white stripes, 2 times black, 0 times green

    Thank you.
    But, the results are bad.
    Now, the question is if the $DE03 is alternating 010101010111100010110 or only code is not stable (test #121)
    But, you reported also problems #121. So, after very long reset the code is not 100% stable. Hmm.

  • just use the last one ... run/stop key is working to prompt :) .then load sdcmduc from somewhere ... , flash some EF to slot0. If there are "hw errors", try to use some shorter one.
    If you don't have short one I can compile it for you, having sdcmduc inside.

    ok, flashing worked. But no autostart from sd card, only green screen... :-)

  • Hi,


    I have prepared official FPGA firmware version UC64190226:
    UC64_2019-02-26-ef-boot.zip
    Added: EasyFlash boot system from flash ROM Slot-0.
    Hold "<-" key during the C64 power on. This is top left key of your keyboard ("left arrow" key).
    Note: I had to change the key because the keys "Q", "Run/Stop", "C=" are redirected to BASIC prompt by EasyFlash boot code :search: !!!
    (Discovered after 2 confusing evenings :D I went always to prompt ...)


    For those having "hw error" problem during flashing I have prepared small EF image containing SDCMDUC 2.4 inside.
    ef-short.zip
    You can flash it into Slot-0, hopefully you will be successful.


    Please, test it also for 250407, I would like to know if this is good workaround.

  • Here my results:


    ef-boot.pof:


    EF boot ok, SDCard boot solid red screen.


    test-5cmds.pof:


    EF boot ok.
    With SDCard sometimes normal Kernal, sometimes blue screen / light blue border / no text / no cursor. No green screen...
    Without SDCard border with lines of changing colors, main screen full of random colored boxes. No green screen...

  • ...and here are my results:


    ef-boot on the 250407:


    sometimes red screens, sometimes black, sometimes flickering lines and some garbled screens:



    i have flashed the ef-short.crt-file on my 250469 Assy (works there like a charm) but i can't boot to it on the 250407...

  • test-5cmds.pof:


    EF boot ok.
    With SDCard sometimes normal Kernal, sometimes blue screen / light blue border / no text / no cursor. No green screen...
    Without SDCard border with lines of changing colors, main screen full of random colored boxes. No green screen...

    OK, I have go back ...
    UC64_2019-02-28-test-0cmds.zip
    No commands to SD controller, but check some non-sd card code.
    Expectation: green screen


    UC64_2019-02-28-test-1cmd.zip
    The same from previous, +1 command to SD controller.
    Expectation: green screen

  • ef-boot on the 250407:


    sometimes red screens, sometimes black, sometimes flickering lines and some garbled screens:

    OK, there was a chance to go through the boot code and start EF, but it seems to be EF is not working as well.
    I remember your post #87 (scrambled screen of EasyProg). In this case running EF image & EasyProg both manipulate EF registers $DE00/01/02.
    Please confirm test:
    1) run/stop ... prompt ... load sdcmduc
    2) start sdcmduc, I suppose this is working ... (?)
    3) navigate START-ROM0-EF.PRG, probably EF image inside slot-0 will not work, maybe scrambled screen (?)
    Thanks

  • Comment: Easyflash uses SRAM. So, if the ASSY has "hw error", which is corrupted Flash-ROM & SRAM R/W access timing, can be that EF image will not work due this reason. EF loads API code to SRAM ...


    250407 is only critical board.
    "hw error" should be the prio to solve.


    One crazy idea: I think that it is possible to implement internal "signal sampler" 0/1 in 50 MHz speed directly to iternal fast FPGA RAM.
    I will be limited for max. 8 kB memory. But, it should be enough to see approx. 1280 C64 clocks for 1 signal line, 640 for 2 signals, 160 for 8 signals, 40 for 32 signals (1 C64 clock = 50 bit samples/1 signal).

  • 1) done... :)
    2) Yes it works...
    3) Works like a charm, no scrambled screen...