I will check 407 scanner dump later, we will see what's new ... actually, maybe I will have working assy 250407 board by end of the next week,
pls. cross your fingers .
Hallo Besucher, der Thread wurde 57k mal aufgerufen und enthält 314 Antworten
letzter Beitrag von Peto74 am
Unicart64 - The FPGA based cartridge for Commodore 64
- Peto74
- Erledigt
-
-
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 1101wrong 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 !!!
if you use my previous 4 wrong values, the result will be correct: $7D or $8C or $05 or $F5 => $FDYes, 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.zipPlease, 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.
-
Hi,
i am back with the last results (error / red border):
again, sorry for the delay...
-
-
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 .
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).
-
Hmmm...
as i said before I think there are some problems with the board ..
for you it's must be like hunting ghosts, i hope i didn't wasted all your time.
just tell me if i should test anything else with my other board
-
Maybe the "Problem" Comes from an VIC Interrupt while accessing Memory???
The VIC sometime stops the CPU and use the Memory bus for accessing SRAM.
-
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.zipSLOT-6 table:
Segment # Base bank # CRT type 0 $00 KERNAL 0..7 1 $08 KERNAL 8..15 2 $10 KERNAL 16..23 3 $18 KERNAL 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 .
KERNALS32.crtJust 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
---------------------------------- -
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.zipScanner program, only retreives data from FPGA into $6000 C64 memory:
SCANNER.zipJust 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:
sadly, my c64 died after the tests... black screen, no prompt anymore. c64 dead test cartridge runs, c64 diag don't...
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...
-
sadly, my c64 died after the tests... black screen, no prompt anymore. c64 dead test cartridge runs, c64 diag don't...
ohh, that's sad, annoying
My situation is that my promised board 407 is repaired now (hopefully ...), the newest promised date of delivery is around 10-11 this month ... we will see. -
fyi: your previous dumps - boot sequence is corrupted like before, R/W toggling 0/1 ... disturbing. And also I cannot recognize data/address of the expected opcodes, so unfortunately not readable for me.
-
hmmm...
it seams as if the board was in the process of dying a long and painfull death after the moving...
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 -
My "new" C64 ASSY 250407 RevA arrived !!!
C64-assy-250407revA.JPGassy-250407revA-board.JPG
Quick check ...
1) SD card boot does NOT work ... but stable Red screen 7x, light blue/blue screen without chars/cursor 3x, but seems to be stable crash !
2) EF boot WORKS !!!
3) RAM test OK
4) SD card browser OK ...This computer was repaired ... seems to be not board dependent, but chip dependent.
-
CPU MOS 6510
assy-250407revA-board-CPU-MOS6510.JPGPLA M82S100
assy-250407revA-board-PLA-M82S100.JPGVIC CSG 8565 R2 (PAL)
assy-250407revA-board-VIC-CSG8565R2.JPGSID - SwinSID replacement
assy-250407revA-board-SwinSID.JPG