This is how I am now trying to make it work as of earlier this morning. I created a public repo that my crypto library agents and my consumer agents (like https/TLS 1.3 and Wireguard) can all use to coordinate to ensure that projects normalize on symbols for use of ZP and REU and whatnot. I have not given much thought to an optimal arrangement so much as trying to bring order to what is happening when a consumer like HTTPS needs to integrate an updated version of nist-curves. Even though list curves was using public symbols it was a heavy lift from a CI/CD standpoint because the https application might not be using the same symbols or was using fixed RAM locations internally etc and having to do extensive refactoring. I did have the idea of maybe trying to align with C64OS at some point too. https://github.com/JC-000/c64-lib-contract I started this process off by having the c64-https supervisor agent and my c64-wireguard supervisor agents cross connect using issues in the crypto libraries. Then had the supervisors for the crypto libraries address the open issues and PR bringing the symbols into alignment. I then had c64-https open this new repo and let c64-wireguard know it existed so that going forward I can have all of my current programs and any future ones that might not be encryption-related work towards a standardized way of allocating ZP, REU, etc. I figure if I make this modular enough then optimization will naturally flow from it. My C64 test harness is now pretty mature at driving the U64E (and presumably C64 Utlimate) now in addition to VICE. I recently decided to standardize on the VICE snapshot format and then have the test harness handle translating that into U64E machine state. There are some missing features in both directions since they don’t have complete feature parity but it’s neat. Some of my projects run over 15000 unit tests so seeing up to ten VICE instances at a time being rapidly created and torn down as it runs the complete test suite is kind of awesome. Justin > On May 20, 2026, at 12:43, ruud_at_baltissen.org wrote: > > Hallo Justin, > > >> ... to use the REU to DMA things in and out of system RAM. > > That is one of my ideas well but how to use it exactly, that is something I have to figure out yet. I managed to start up from the Kernal ROM without the need of the BASIC ROM. Result: 51200 bytes free. The last time I used a REU is maybe 15 years ago. So I have to figure out how to use it again. Including how big the swap area can be. If it is more than 4 KB, then I'm happy that I swapped the BASIC ROM for RAM. > > I haven't been thinking about using the BASIC ROM range for an own one. I consider it a bit of an handicap that it is in "the middle" of the RAM. But it has one big advantage: immediately available and fast. > > >> ... to use ... zero page ... > > That is what I am working on now: to free all zero page variables not needed by my ROM. Not only the zero page but also the RAM in the $02xx and $03xx range. That is not so difficult: just look if a variabele is used in the rest of the source code. If not, then just remove it from the source code as well. But I'm already running into a dilemma: what to do with all the gaps between the variables? A logical thought is to shift them all on one heap and creating one big free block of RAM for future use. The disadvantage: discompatibility. But if I start to loose compatibility, unfortunate but not something to shed tears about. > > To be continued.... > > > -- > > Kind regards / Met vriendelijke groet, Ruud Baltissen > > www.Baltissen.org > >
Archive generated by hypermail 2.4.0.