Ruud, I have been using mine for development and testing and I have a test harness for running code that can drive both VICE and the U64E/C64U. I had to take the repo for it private temporarily in order to clean up a bunch of metadata that shouldn’t have been included in some commits, but I’ll have it public again next week. The UCI documentation is not perfect but using the network interface to tell the Ultimate to load images, change turbo speeds, configure more SIDs, etc is pretty reliable. My test harness includes a huge number of internal tests and effectively documents the UCI functionality that I’ve engaged with so far, so it ends up acting as a UCI reference for my other projects. It will handle dispatching tasks to an Utlimate and up to 10 VICE instances at once with their own text and binary monitor ports. This is fantastic for iterative testing or agentic coding where ensuring that agents are using the test harness lets them run tests without conflicts. Without this logic they clobber each other’s VICE runs and then go crazy imagining that the code “crashed vice”. My test harness is fully implemented for Linux and macOS. One of the big benefits to running tests on the hardware Gideon created is the debug stream. My test harness catches a rolling last-5-seconds of machine state from the debug stream, which is fantastic for stepping through code for debug (and tends to keep things like Claude Code from imagining problems in things other than the code). The primary limitation I’ve run into with this is that the debug stream samples at 1Mhz regardless of turbo speed, so at 2Mhz you lose half your data and at 48Mhz it’s kind of useless. I opened an issue on this in the binary blob repo for the Ultimate firmware. If you have a long running program you can either try to programmatically toggle turbo while it is running and then capture during the window you want, or you still have to be patient. Another difference I’ve noticed from VICE is that on the Ultimate the realtime clock runs in normal time regardless of turbo, whereas on VICE it advances as fast as the rest of the virtual machine in warp mode. I think this realtime counter is supposed to be clocked on the AC circuit in the original hardware, so the Ultimate 64 behavior is more correct. This means you can build timing loops that work properly across the range of turbo speeds. I don’t know why you’d ever use the rr-net instead of UCI networking on an Ultimate, but with this clock behavior IP65 could probably have a polling loop that works at normal and turbo speed. As an example the existing IP65 loop usually exhausts itself before DHCP completes in VICE WARP. The REU also only runs at 1Mhz regardless of turbo which is probably correct “bug compatible" behavior for the 1541 Utlimate if you were attaching it to a C128 in 2Mhz mode, but doesn’t really make sense on the Ultimate 64. Because it is a problem at higher turbo’s where the REU’s DMA starts to become a bottleneck instead of an accelerator like it is at 1Mhz. I also opened an issue on this in the repo. It is kind of amazing to run GEOS mega patch on it with a big REU. It’s been a little while since I looked but IIRC Megapatch was said to be switching to German-only for future development but the repo kept getting new English builds so you probably would have at least those choices. It can bank switch up 9 applications and at at 48Mhz it completes the bank switch and application refresh in a single screen refresh so even though it is not real multitasking it certainly feels like it. Justin > On Apr 30, 2026, at 05:46, ruud_at_baltissen.org wrote: > > Hallo allemaal, > > > Last year I got an unexpected bonus and decide to buy a 64Ultimate from Gideon. He pointed me to commodore.net and there I bought the Starlight Breadbin version. First impression: good. Only the documentation could be a bit better. > But now: what am I going to do with it? > > I'm not a game man, I want to do some technical stuff with it. I was thinking of exploiting its technical advancements in combination with already existing software. One idea is to combine my 1541 hard disk project with the C64U: it would handle D64 files faster and better IMHO. But my projects handles the hardware of an attached IDE HDD directly and I have no idea yet what I have to do to access the D64s on, for example, the attached SD card. > The source code of GEOS is available but IMHO I think that is too big for a "beginner". > Then I ran into Andre's GeckoOS and that looks like something I think I can handle. I'll start with assembling the code first and then run it on the C64U > > Any other ideas from your side are welcome! > > FYI: I'm not a sound ot graphic man. > > > -- > > Kind regards / Met vriendelijke groet, Ruud Baltissen > > www.Baltissen.org > >
Archive generated by hypermail 2.4.0.