Pinned Unicart64 - The FPGA based cartridge for Commodore 64


  • Peto74
  • 10231 Views 237 replies

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • the accidently overwriting of slot 0 was my fault, my problem was that i can't rewrite slot 0 with ef-short using sdcmduc 2.5 in a way that it would start sdcmduc when switching on the c64 pressing the arrow button...

    I had to write it with sdcmduc 2.4, this time sdcmduc starts when i pressed the arrow button while switching my c64 on, same results with writing kernals to slot 4.

    As i am short of time atm i had no possibility to investigate the problem any further and as i said: maybe the problem was in front of the keyboard :)

    I think I'll find some time to test the new version this weekend, i will try to reproduce my problems with version 2.4 and report the results...
  • So, the last dump comparing ...
    My minimal FW is just catching data byte, without sending to SRAM, I have deleted almost everything from FW, only basic regeneration and scanner remains, but still disturbing.
    Here is comparing 469 with 3 dumps of 407, inst. STA $DF00,X (X=$FE), 5th halfclock writing $FD to $DFFE.
    469 22 correct values / 26
    407 #1 13 correct values / 26 (we were lucky here, correct value caught)
    407 #2 7 correct values / 26
    407 #3 4 correct values / 26 (we were lucky here, correct value caught)

  • back to 407 ... after analysis of C64 disturbing, I think it can be hw/electrical issue, most probably my resistor dividers.
    Once I will receive working board I have to recreate my "ugly" protoype full of wires & resistors on universal board and experiment with resistor values.

    Facts:
    - disturbing seems to be random and my FW simplification didn't help, still the same, so I can exclude this (but it is sensitive and every change had impact ...)
    - previous test showed that corrupted value was always (seems to be...) higher value - many bits with logical "1".
    - if the error value appeared, always some bits were dropping down to zero - logical "0" (1 --> 0), I didn't see the opposite direction 0-->1 (!)

    So, if the theory about resistor is correct, I have to finetune the resistor values and future boards can have different resistor networks (or resoldering). This must be confirmed first.
    I believe the rework of board is not needed.
  • Based on the knowledge that the bits are only dropping down 1-->0, it could be possible to create workaround !
    I can catch more values (incl. wrong) on every clock in some range during write and the logic join it by OR gate to result value !
    Just an idea ...

    Overview:
    correct value: $FD 1111 1101

    wrong value: $7D 0111 1101
    wrong value: $8C 1000 1100
    wrong value: $05 0000 0101
    wrong value: $F5 1111 0101
    ...

    value1 OR value2 OR value3 OR ... OR valueX => ResultValue

    theoretically, all values can be wrong, but there is a chanse for correct result value !!! :D
    if you use my previous 4 wrong values, the result will be correct: $7D or $8C or $05 or $F5 => $FD

    Yes, this is only workaround, not serious solution, but it could increase probability of correct write very high !
    Then must be tested ... and create statistics.
  • Hi,

    Here is test firmware for 250407 containing workaround, SRAM controller IO2, $DF00..$DFFF.
    2019-04-25-fw-407-min.zip

    Please, test it using HWERR2.PRG from post #184.
    In case of error (red border), pls. send me the dump.
    Thanks.

    FYI: I still don't have promised board 407. On 469 it is working fine.

    The post was edited 1 time, last by Peto74 ().

  • Hi,

    I have analyzed the dumps and I can see the workaround is working ;) , but in dump #2,#3 are simply missing data on the C64 data bus.
    So, if disturbing is so high, only way is to wait for real fully working 407 board. Hopefully, I will get it, currently there is a bug ...

    Dump #1: Here, value was repaired by the workaround logic (!) and seems to be written to the SRAM, but the error came due to reading by CMP instruction when wrong address was caught after short disturbing on address bus. So CMP read the different address with different value. At least I see reading is working perfectly :D .

    Dump #2, #3: During write the value to SRAM, workaround did the best it could, but 1 bit was completely missing, so the writing value was wrong (7/8 correct bits).
  • Diddl wrote:

    The VIC sometime stops the CPU and use the Memory bus for accessing SRAM.
    No, no ... that's not the case. I have BA signal inside and this is "1" all the time in the dumps. And of course, I saw every cpu halfcycle exactly in the detail, cpu (O2=1) / vic (O2=0) are changing nicely.

    My theory is that my resistor dividers do the problems. The resistor values were "finetuned" on 469 and maybe for 407 there are different electrical conditions. I think only way is to recreate my "ugly" prototype and test various resistor values directly on 407 like in the beginning.
  • Hi all,

    Here is my update of "standartized" Flash ROM mapping 18/04/2019:
    I have completely changed SLOT-6, now reserved areas for 32 Kernals, 2x AR, 2x SS5.

    The corresponding starters are here (please, update ...):
    2019-04-18-CRT-STARTERS.zip

    SLOT-6 table:
    Segment #Base bank #CRT type
    0$00KERNAL 0..7
    1$08KERNAL 8..15
    2$10KERNAL 16..23
    3$18KERNAL 24..31
    4$20#0 for AR/RR/NP
    5$28#1 for AR/RR/NP
    6$30#0 for SS5
    7$38#1 for SS5



    I have also compiled the dedicated CRT file containing 32 binaries found on internet ... used by me :D .
    KERNALS32.crt

    Just use starter filenames containing only numbers and/or starter filenames containing numbers & kernal names (my dedicated).
    Don't forget ...
    32 Kernal flashing: use Slot 6 & segment 0 (see table above ...).


    List of Kernals:

    ----------------------------------
    # KERNAL NAME
    ----------------------------------
    0 KERNAL-V1
    1 KERNAL-V2
    2 KERNAL-V3
    3 KERNAL-SX
    4 JIFFYDOS
    5 EXOS-V3
    6 EXOS-V4
    7 TT-ROM-0.1
    8 TurboTrans-v3.0-1
    9 TurboTrans-v3.0-2
    10 Datel_DOS-ROM-1.2
    11 Datel_Mercury-ROM3-US
    12 Datel_Turbo-ROM2-PAL
    13 TurboAccess-v2.6
    14 TurboProcess
    15 TurboProcess-US
    16 Cockroach_Turbo-ROM
    17 Cockroach_Turbo-ROM-SX
    18 BEAST
    19 HCBASIC
    20 HCBASIC-
    21 Dolphin_DOS-10-mager
    22 Dolphin_DOS-20-2
    23 Dolphin_DOS-20-3
    24 Dolphin_DOS-30
    25 Professional-DOS-Rel-2-4-L2
    26 Professional-DOS-Rel-3-5
    27 Professional-DOS-Rel-3-5-L2
    28 Professional-DOS-V1-SpeedDOS
    29 SpeedDOS
    30 SpeedDOS-40t
    31 C64GS
    ----------------------------------



    Files
  • Hi,

    Here is test of FPGA ultimax boot cartridge for 407, or in other words very first instruction flow after Power ON / initial reset.

    Firmware:
    UC64_2019-05-17-ef-boot-scanner6-bootseq.zip

    Scanner program, only retreives data from FPGA into $6000 C64 memory:
    SCANNER.zip

    Just try Turn ON your C64 (407).
    In case of booting crash, just use <Run/Stop> & Master Reset button (left most) to end in blue screen prompt.
    (use pen, not fingers ...)
    Then, load somehow Monitor & Scanner, start SYS3000, then save data from Monitor by S DATA,6000,8000.

    This firmware is a little bit different in main logic, no workaround, I hope clock will be stable/data readable.
    Reason: I try to understand, why program was running "randomly" in your previous software tests.

    Please, test.
    Thank you.
  • here are the results from my tests with the 407-board...

    No crash, 3 dumps:

    dump20190531.zip

    sadly, my c64 died after the tests... black screen, no prompt anymore. c64 dead test cartridge runs, c64 diag don't... :cry:

    i think it'll take some time until it runs again...

    i have tested the cartridge on my 250469 assy with the kernals from post #233, that one works like a charm... :)
  • hmmm...

    it seams as if the board was in the process of dying a long and painfull death after the moving... :cry:

    The board is not completely dead since the dead test cartridge works and shows no error so iI think there is a problem with the kernal access. Over the last weeks I had more and more problems with temporary black screens so I think there must be a cold solder joint or some hairline cracks on the board.
    Nevertheless I think the problems with the bus signals will still be there when I found the problem with the kernal, so it seams there is something more wrong with the board ;(