Please define "doesnt work". Are you sure you actually flashed it? The new firmware should be more stable than the old one actually 
Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
Don't Panic. Please wash hands.
-
-
Well, it finishes writing and verifying flawlessly but after a reboot the firmware doesn't show up (your earlier responded with 'it looks like it's written to RAM instead of EPROM' to this matter).
-
now i am confused. and the older firmware works? please describe exactly what you are doing there (eg did you powercycle after flashing? what happens then? is it back to the older firmware?) the code used for flashing is the exact same for both so if one works, the other works
-
Ok, lets explain it this way:
I downloaded the firmware from the link as suggested above.
Once the disk is mounted when I use the program 'originalflasher' it flashes that firmware successful (8000-9FFF both writing and verifying) using the Ultimate settings as posted above. I remove the jumper and the RR-NET information shows on screen at boot. I put on the jumper again.
Then I create a 8K ROM file named RRNETMK3.ROM with the RRNET-TOOL on that same disk and use RRNETMK3FLASHER to write that 8K ROM file. Again 8000-9FFF both writing and verifying succesfull.
Now when I just reset (not reboot or poweroff), I do get the information on the screen from the 8K ROM allowing me to enable DHCP and such things, but as soon as I reboot or poweroff that information (at boottime) is not shown anymore.
And the original RR-NET information is not showing either (makes sense since the 8K overwrote the original firmware).
The last case (generated 8K ROM file flashed) is not working.
I hope this clarifies and I hope you know a solution for this. -
could you attach the RRNETMK3.ROM you have generated? lets see if that is even a valid rom
-
Sure I can send it. It's not possible for me to upload an attachment here. Can I send it by mail? Please let me know.
-
You can upload attachments after registering. Ann account in this forum will also let you write without the annoying captcha.
-
Ok Here is the zip file , I put in the D64 image with the RRNETMK3.ROM file in it.
-
ok, the generated file looks good. not sure how to proceed... as said the code for the flasher is pretty much the same (except one is loading from disk, the other is not) *shrug*
i'll have to setup my U64 and see if i can reproduce the problem (i still didnt get the CPLD update though, so no idea how much sense that makes)
-
What is the 'CPLD update'?
-
My U64 is from the first batch, which had a buggy CPLD (that is a programmable logic chip) on it, which needs to be updated for the I/O mapping to work 100% correctly. I was planning to do this next time i can meet Gideon at the X party.... and then this corona crap started. If your U64 isnt from the first few hundred (iirc ~200 or so) then you will not need this, i think.
-
I have a Ultimate 64 and Ultimate 64 Elite and tried the RR-NET on both and both had the same behavior so for me the CPLD is not the problem I think.
I hope there will be a solution for this as I really like to use the RR-NET for Contiki/GEOS internet related applications (the built in networkcard of the U64(E) doesn't support RR-NET hence I ordered the RR-NET card with you guys). -
Well, in any case, since it works at a C64, there isn't much we can do about it - Gideon will have to fix it
-
I have Gideon's address now, and will send him a unit.
-
I have Gideon's address now, and will send him a unit.
That's so cool! Thanks for your cooperation!
-
Interesting issue. I'll look into it soon after I receive the unit. Thank you Jens, for sending me one.
I am actually surprised that the RR-NET does not work correctly; the timing on the U64 cartridge is quite crisp and much better defined than on a real C64. So in terms of setup time, I don't expect any issues as there is way more margin. However, this may turn out to be a hold-time issue on write. Jens, do you have the timing specification of the RR-NET?
Another issue can be improper configuration. Since the introduction of the turbo mode, the cartridge port does no longer expose all CPU accesses, as it would cause to be a bottleneck. The cartridge port has become more like a peripheral, which performs bus-cycles only when needed. When not configured correctly, the I/O accesses don't end up there at all. Yes, I understand this introduces some incompatibilities. It's on my TODO list to fix this, but the way in which the built-in Ultimate-II+ is attached to the bus makes this a bit complicated. A quick fix is not enough; it needs some restructuring.
Note that the CPLD update on the early units is not related to cartridge timing. The CPLD is a slave on the cartridge bus and implements the joystick / keyboard / userport I/O only. Early units used A4 in the address decoding, making $DC1x not the same as $DC0x. It was a simple address mirroring bug. -
Ah yes, the CIA mirrors, i remember now
-
The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.
- Marks thread as resolved after post creation.
