My Option is here, was there any protection before ? etc.
Hallo Besucher, der Thread wurde 56k mal aufgerufen und enthält 313 Antworten
letzter Beitrag von Peto74 am
Unicart64 - The FPGA based cartridge for Commodore 64
- Peto74
- Erledigt
-
-
Yes there is progress bar for programming to 100% and failure for verify.
checking options...Optios are same as yours.
-
just did some short tests with the firmware from post #96, same result as before:
1. Assy 250407, Vic ?
mostly red screens, sometimes black, sometimes prompt...
sdcmduc runs when loaded from prompt2. Assy 250469, Vic 8565R2
Everything is allright -
Hi,
another try, please, test it on 250407
UC64_2019-02-20-sd-card.zip
I don't see any reason, why this controller is locked from outside or inside, but I have restricted sd-card controller for some possible locking situations.
Thanks.
PS: My board is 250469 Rev.B. -
just some short tests with the 250407 assy and the firmware from post #104:
Mostly red screens, some black, some prompts, some screens as if i had problems with the sd-card, one garbled screen...
sdcmduc runs without problems when starting from prompt
-
-
it has to be a 407?
cause i have several unused 425 Boards,
and could donate one of them... -
Hi,
I think, maybe to have such board ...407 (was reported) in house should be the best.
I believed I will be able somehow to catch the root of the problem.
Donate it is not needed, I can honestly return back every board after fixing of the problem.Overview:
1) solid red screen --> must be blocked sd controller. But why, I don't know.
2) many various screen (red, black, prompt ...), not sure what is this ...
3) why after run/stop sdcmduc works without problem ? booting code & sdcmduc do the same , accessing $DE03/04 registers ???
I thought before, the difference is that booting code runs from ultimax cartidge and SDCMDUC from C64 memory, but it didn't help ???Peter
-
ok,
I only have 425 of the old revisions...
maybe someone else?eine/er stellt das Board, un ich zahle Die Air Mail...
your located in England?
-
Mine is 425 and does not work also.
-
your located in England?
No, my location should be public (?), I'm located in Slovakia, my town is called Dubnica n/V.
-
Mine is 425 and does not work also.
Many thanks. If it doesn't work (booting) maybe it would be OK. But, wait a little bit ... I suggest to do couple of experiments first and if the situation will be bad, I will inform you here on this thread.
-
No, my location should be public (?), I'm located in Slovakia, my town is called Dubnica n/V.
yea it is, so Air Mail would be a bit over dimensioned -
Hi,
Back to the roots .
I have prepared 2 experiments, I would like to start from beginning.This firmware will show colorful strips. It is sign that Boot Ultimax cartridge works stable, meaning
instruction opcodes/parameters are fetched from FPGA correctly. The strips are in endless loop.
I don't expect problems here, but nobody knows ...
UC64_2019-02-21-ultimax-boot-test.zipCode:
_wait11:
INC c?VIC_BORCOL ; increment Border color
JMP _wait11 ; endless loop TEST of running Ultimax -
The second firmware is more complicated testing SD controller status register, reading from $DE03.
UC64_2019-02-21-de03-read-test.zipDetails:
SD controller is starting initialization sequence right after the power up.
During this time the busy flag is "1". Right after the successfull init procedure it changes to "0" and must remain there.
So expected scenario is: 11111100000000...0.Register $DE03 (Status register, reading)
BE000000
bit-7: B - busy flag, 1=busy, 0= ready for work
bit-6: E - error flag of the last operation, not important should be 0My code starts with red screen waiting until status is changed to "0". Then it should remain in green screen stable.
No other colors are expected. It runs on my ASSY 250469 rev.B.Code:
LDA #c?RED ; RED COLOR
STA c?VIC_BORCOL ; set Border color
_wait11:
BIT cSD_CMD_STATUS_PORT ; read status
BMI _wait11 ; wait 1 -> 0LDA #c?GREEN ; GREEN COLOR
STA c?VIC_BORCOL ; set Border color_wait22:
BIT cSD_CMD_STATUS_PORT ; read status
BPL _wait22 ; wait 0 -> 1LDA #c?BLUE ; BLUE COLOR
STA c?VIC_BORCOL ; set Border color_wait33:
BIT cSD_CMD_STATUS_PORT ; read status
BMI _wait33 ; wait 1 -> 0LDA #c?WHITE ; WHITE COLOR
STA c?VIC_BORCOL ; set Border color_wait44:
BIT cSD_CMD_STATUS_PORT ; read status
BPL _wait44 ; wait 0 -> 1LDA #c?BLACK ; BLACK COLOR
STA c?VIC_BORCOL ; set Border color_wait55:
BIT cSD_CMD_STATUS_PORT ; read status
BMI _wait55 ; wait 1 -> 0LDA #c?WHITE ; WHITE COLOR
STA c?VIC_BORCOL ; set Border colorJMP _wait44 ; endless loop
-
Previous post #115.
Expected scenario WITHOUT SD card inside connector is: 1111111111111...1. (red screen)
Expected scenario WITH SD card inside connector is: 11111100000000...0. (green screen)According the results we can decide for the next steps. The goal is to find out the root of the problem.
Don't hurry, kindly test it when you will have a time.
Thank you all . -
Ok, here are my results doing some quick tests:
Firmware from post #114
Sometimes orange screen, sometimes stripes, one garbled screenFirmware from post #115 (no pictures)
without sd-card:
sometimes blue screen, sometimes red screenwith sd-card:
one green screen, mostly black with white stripes flashing and white screenshmmm...
i saw garbled screens, screen with crashed prompt with all letters lowercase, blue screens...
i don't know, sometimes i think it is a problem with the contacts but i have no problems with other cartridges in this board (ultimate 1541 II+, easyflash 3, final cartridge III etc) and i have no problems with this board in the other computer.
Sometimes the screens seams to change randomly, when i switch the c64 off, and push a little on the board while switching on i get a completly other screen... frustrating... -
Hi,
Thanks for your inputs, I should explain a little bit what's going on ... yes it is frustrating, and it can be very rarely about the C64 power switch as well, but I think this is about something else.
Firmware #114 (colorful strips/ultimax boot cartridge):
Your tests shows very clear, that code inside this "boot cartridge" which is in Ultimax mode doesn't run correctly !
After power up, most probably the clock is not so nice for a while, no problem for C64, but maybe problem for my FPGA clock regeneration.
Normally, code running from C64 memory doesn't need my regenerated clock, but here (!) FPGA / boot crt needs "to feed" the opcodes from my memory to C64 bus and processor has to run it.
If the bad opcode value is sent to C64, CPU will run different instruction, so the code is "changed" and you will see "randomly" unexpected screens, simply whatever ... black, orange, letters lowercase ... this is because the code is running somewhere without the control ... and this is the problem and this is exactly what I wanted to know !
When I want to feed values correctly, I need regenerated clock. This clock is trying catch the sync point (phi 1->0) from the very beginning. Maybe it takes a while at the beginning when my algorithm is stabilized on that ASSY.
You reported that after run/stop .. prompt... sdcmduc works . So, I suppose that regeneration is later working stable (not 100% sure, but it seems to be).If this problem is only at the very beginning (?) and then later it is OK, the behavior should be:
If you are "lucky boy" and you see changing strips (pic.2), I suppose these are stable running "forever", not freezing, not changing etc. simply still the same. If this is true, opcodes of the endless loop (see post #114) are sending to C64 correctly, so clock should be running.
Please, can you confirm it ?Solution / ideas ?
1) change the regeneration algorithm, not easy to moving parameters, and clock check is required, better to have this board in house.
I don't want start with it, it seems to be only about longer time to stabilize, then all Ok. Of course, I'm not 100% sure.
2) maybe I will try to enlarge initial reset pulse to be longer in time. I prefer this try, clock will have longer time to stabilize, and instruction start will be delayed.
So, there is a hope to run stable, you will see the strips always, not randomly the screens (in case of bad power switch only very rarely).So I will prepare the firmaware, and please check this behavior one more time.
Thank you. I hope we can solve this, maybe slowly, but now it is more clear. -
If this problem is only at the very beginning (?) and then later it is OK, the behavior should be:
If you are "lucky boy" and you see changing strips (pic.2), I suppose these are stable running "forever", not freezing, not changing etc. simply still the same. If this is true, opcodes of the endless loop (see post #114) are sending to C64 correctly, so clock should be running.
Please, can you confirm it ?Just to explain, I need to recognize if the reading from FPGA is always randomly bad or only at the very beginning (time is unknown).
Test to start fw #114, and if the strips are running let's say more than 5 sec. (KERNAL boot time to prompt),
keep it running lets say 2-3 minutes and see if it is running stable or if it crashes (freeze, random color/screen, whatever else ...).
Try it several times. Take in consideration only cases when it is running > 5sec. I need to see statistics.
Expectation: 10 running strip cases > 5sec. will run also always 2-3 minutes without crash. -
Firmware from post #115 (no pictures)
without sd-card:
sometimes blue screen, sometimes red screenwith sd-card:
one green screen, mostly black with white stripes flashing and white screensIn $DE03 is not stable, alternating value 0/1 (like this 00011101010111000), reason can be the same as described in post #118.
In this moment firmware #114 must work first.