Unicart64 - The FPGA based cartridge for Commodore 64

Zitat von borstie

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.

Zitat von wolfme

no time for testing today, i will test tomorrow or Sunday.
Edit: tomorrow or Saturday

yes, that's fine, only when you have time

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).

Zitat von wolfme

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:

Zitat von borstie

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:

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 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.

Zitat von Diddl

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.

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

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)