Angepinnt Unicart64 - The FPGA based cartridge for Commodore 64


  • Peto74
  • 7403 Aufrufe 196 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • borstie schrieb:

    Peto74 schrieb:

    borstie schrieb:

    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
    1) done... :) 2) Yes it works...
    3) Works like a charm, no scrambled screen...
    3) uaw, are we talking about / testing 250407 :) ?
    If yes, so EF image works and EasyProg is NOT working ? Or was it only one time issue - post #87.
    It is possible that EasyProg uses SRAM and if bad r/w comes (my "hw error" inside sdcmduc) the code crases there (EF eapi or so ...).
    Please, check. I wanted check later "RAM test" there.
    Note: I'm preparing first "hw error" experiment.
  • So, my experiments to avoid "hw error" during flashing using SDCMDUC.
    UC64_2019-02-28-test-hwerror-46-46.zip
    UC64_2019-02-28-test-hwerror-46-47.zip
    Pls. test on 250407, 250469 Rev.A

    I have only moved sync points, we will see if it helps.

    Please, try to flash larger EF image to any slot using SDCMDUC.
    Expectation: No hw error message.

    Note: I have tested both on 250469 Rev.B. Both FWs fully working. Maybe can be retested on 250425 as well (just for compatibility).
  • Peto74 schrieb:

    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
    Ok, here the results:

    0cmds: Green screen
    1cmd: Solid red screen
    n paar Cevies, n paar Amigas, n paar FPGAs, n Haufen Zubehör und viel zu wenig Zeit...
  • Peto74 schrieb:

    borstie schrieb:

    Peto74 schrieb:

    borstie schrieb:

    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
    1) done... :) 2) Yes it works...3) Works like a charm, no scrambled screen...
    3) uaw, are we talking about / testing 250407 :) ?If yes, so EF image works and EasyProg is NOT working ? Or was it only one time issue - post #87.
    It is possible that EasyProg uses SRAM and if bad r/w comes (my "hw error" inside sdcmduc) the code crases there (EF eapi or so ...).
    Please, check. I wanted check later "RAM test" there.
    Note: I'm preparing first "hw error" experiment.
    Yes i tested it on the 250407... i can't flash on that assy (hw error) so i used my 250469, switched with the module to the 250407, started sdcmduc via prompt and then started ef image with the starter-prg. Worked as expected. I just can't boot that image on the 250407, on the 250469 there are no problems.

    The last time i tested easyprog with the matching firmware it crashes every time.
    Flashing via sdcmduc also says hw error.
  • my tests for post #165:

    Assy 250407:
    46/47: black screens, mostly red screens, flickering lines. Problems getting a prompt.
    After getting a prompt starting sdcmduc trying to flash kernals to slot 4: hw error

    Assy 250469:
    No problems, starting ef image, getting prompt and green screen.
    Should sdcmduc automatically start after green screen with no key pressed?
    I think i saw this with fw 46 (not sure), on fw 47 i saw it definitely not.
    I did not try any flashing on this assy during this tests.
  • wolfme schrieb:

    Peto74 schrieb:

    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
    Ok, here the results:
    0cmds: Green screen
    1cmd: Solid red screen
    OK, I'm back. So, the first command write access blocked $DE03 status, instead of 0->1->0, there is 0->1 .... 1, simply remains blocked (red screen).
    So controller is blocked, wrong internal state ? Or write access sent wrong value, normally it should not stay like that. But, we have at least the boot code position.
    Thank you.
  • Another test:
    So, if we have no direct possibility to check clock regeneration, the fastest way is this indirect clock check.
    This is REU DMA transfer check only. But, there is very strong dependency to regenerated clock.
    REURAM.PRG
    Just run this prg, no fw change is needed.
    Steps:
    1) run/stop, promt load & start sdcmduc
    or
    boot sdcmduc
    2) load reuram.prg into C64 memory
    3) deactivate all controllers and activate REU only
    POKE56832+255,12
    4) start: SYS3000

    Result:
    Green border - OK (in this case DMA transfer/regenerated clock must be OK !)
    Red border - Error (in this case we are not sure, but most probably bad regeneration)

    This is for 250407 mainly, but please test it on all ASSYs.

    Overview:
    SD-bootEF-bootSDEFDMA/CLKHW-error
    250407errerrOKOK?err
    250425errOKOKOK?OK
    250469 AOK?OKOK?err
    250469 BOKOKOKOKOKOK

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Peto74 ()

  • borstie schrieb:

    I will be on a business trip for my boss the next couple of days but I hope i'll be back on saturday or sunday, so no testing until then, sorry...
    Yes, that's fine :) . When I put here something it is not command for you, only kindly wish :) .

    Overview:
    SD-bootEF-bootSDEFDMA/CLKHW-error
    250407errerrOKOKOKerr
    250425errOKOKOKOKOK
    250469 AOK?OKOK?err
    250469 BOKOKOKOKOKOK
  • Peto74 schrieb:

    borstie schrieb:

    I will be on a business trip for my boss the next couple of days but I hope i'll be back on saturday or sunday, so no testing until then, sorry...
    Yes, that's fine :) . When I put here something it is not command for you, only kindly wish :) .

    i know... :)

    btw.: my 250469 has Revision 3, i forget to mention it all the time, i think... :)
  • Hi,

    This test is for 250407 only ("HW" error).
    The test program will perform RAM test like EasyProg.
    It will hopefully answer me if this problem is during read or write.

    1) run/stop ... prompt
    2) load ram2test.prg from somewhere (can be from sdcmduc)
    RAM2TEST.zip
    3) start SYS3000 (can be started more times ...)

    Result:
    Green border - no RAM error found
    Yellow border - RAM error, probably read problem
    Red border - RAM error, probably write problem
    In case of error hex. number in upper left corner.
    Just start it more times (no C64 restart needed) let's say 10x & report results, colors numbers.
    Thank you !

    Note: FYI: I'm finishing my new internal signal scanner :thumbsup: so I will be able to see your C64 signals soon ... I'm limited to only 8kB memory buffer, but I hope it will be helpful to scan remotly your boards.
  • Neu

    I'm astonished About this Problems with 407 boards …

    The timing of a 6510 is not very critical and for a modern FPGA it is really slow.


    I'm sure you do, so excuse my Question …
    Do you combine Clock with PHI2 correctly?
    Do you react correctly on Signal BA and DOT Clock from VIC?

    Only an idea ...
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Neu

    Diddl schrieb:

    Do you combine Clock with PHI2 correctly?
    Do you react correctly on Signal BA and DOT Clock from VIC?
    I hoped yes, 469 works. That's why I need to look at it closer, even I have no 407 board.
    I have developed internal signal scanner.
    It comes soon, I hope. Then analyzing data, understanding, repairing, testing.
    I know it is slow. But I'm moving forward.
    Currently, looking at the VHDL I don't see the error.
  • Neu

    Some words about Signal scanner:

    Start writing "mode" value to $DEE0.
    Scanner starts immediatelly samples signal states to fast internal FPGA RAM.
    When 8kB buffer is filled, it stops.
    State can be read from $DEE0 status register (bit7: 1=working, 0=stopped).
    Buffer can be read byte by byte reading $DEE1 register.
    So, the test program can start it in the "right" moment.

    Mode 0: approx. 1200 C64 clocks 1 signal

    Mode 1: approx. 600 C64 clocks 2 signals

    Mode 2: approx. 300 C64 clocks 4 signals

    Mode 3: approx. 160 C64 clocks 8 signals

    Mode 4: approx. 80 C64 clocks 16 signals

    ***Mode 5: disabled

    Mode 6: approx. 20 C64 clocks 64 signals

  • Neu

    Hi,
    So, the test "HW error" for ASSY 250407:

    The experimental FW containing Signal scanner:
    UC64_2019-03-10-ef-boot-scanner6.zip
    This is test program which tries to write and read/compare into/from SRAM and waiting for "HW error" situation.
    HWERROR.zip
    And here is standard well known Monitor $C000, which can be used for saving binary data to your drive 8 disk (/sd2iec).
    MONITOR.zip

    Steps:
    1) run/stop ... basic prompt
    2) load Monitor to C64 memory by LOAD"MONITOR.PRG",8,1
    3) load test program to C64 memory by LOAD"HWERROR.PRG",8,1
    ... steps 2,3,can be done via sdcmduc: navigate Monitor.prg, <Return>, RUN<Return>, navigate Hwerror.prg<Return>
    4) start hwerror.prg by SYS3000
    - Green screen, no error found, just try start it again/ more times ... SYS3000
    - Red screen, error found, in this case test program retreives data into C64 memory $6000-$7FFF, continue steps 5, ...
    5) start monitor SYS49152
    6) save binary data into drive 8 by
    .S FILENAME,6000,8000
    7) exit monitor by
    .X

    Please, export let's say 3-5 binary files and transfer it into your PC, send me that :) .
    You can change filename in monitor, of course !
    In case of green screen there is no need to save data.
    Scanner starts mode 6 (20 clks/sample 64 signals in full 50MHz speed) before every try to write into SRAM.
    I hope I did no error, we will see.
    Thank you !

    Code:
    STY DEE0 ; start scanner, end of this instruction will be visible/sampled
    STA DF00 ; 4 clocks sampled (write)
    CMP DF00 ; 5 clocks sampled (read/compare)
    BNE ... ; 3 clks sampled
    ... approx 8 clks sampled / not important for me (max. 20 clks due to buffer size)