Ryan Carsten Schmidt
Ryan Carsten Schmidt
> The "hang" was in the memory manager routines This was caused by the poor performance of `malloc` which is now filed as #185. > All builds were with: >...
I have not gone down the standalone code resource path yet because it seems like it would have many drawbacks so I consider it a last resort. And I'm not...
Just another progress update... > MWDump68K/MWDumpPPC to convert CW objects and libraries to assembly MWDump68K outputs only the first 0x30 bytes of data hunks: ```m68k Hunk: Kind=HUNK_GLOBAL_IDATA Name="Curl_easyopts"(315) Size=3780 00000000:...
> the given path apparently must be absolute at least when using an out-of-source build, which I was.
This is good to know, thanks. I know the Mac was designed to load and unload small code segments, but I had been under the impression that Retro68 didn't support...
Thanks! I'll try `dlmalloc`. My tests were with System 7.1.
First, here are some things I tried that didn't work. Below the break, what did work. TL;DR: dlmalloc is hundreds of times faster for me. I tried adding dlmalloc.c to...
Do you have any concerns about upgrading gcc or binutils to a newer version? For example, are you aware of any features that have been changed or removed which might...
> No specific concerns yet, except that it will mean that I need some extra backported software to run things on my PowerMac G5. What would you need? > The...
> What if the program the user is developing requires [...] something else on the system disk? For example see https://github.com/autc04/Retro68/discussions/135