Jump to content


  • Content Count

  • Joined

  • Last visited

Recent Profile Visitors

510 profile views
  1. Nice work. It doesn't appear that toolkits like Nuklear and Dear ImGui have facilities for partial updates, so for better drawing performance I would think lvgl would be a better choice. However, if the UI isn't updated often, Nuklear and Dear ImGui would be fine.
  2. If you are looking for something more lightweight but still maintained, I would check out lvgl: https://lvgl.io/ It can run on low-powered microcontrollers, so I suspect it can also apply for old Macs.
  3. Fix the indentation so it matches the if statement
  4. Some fast decompressor like lz4 or lzo could reduce the CPU cycles needed while allowing faster transfers.
  5. I think offloading heavy processing e.g. TCP, UDP, TLS, transfers, etc on faster hardware would be interesting. The nice thing about A/ROSE for hardware manufacturers is that the driver is included and you don't need to write your own. The last thing I read that is difficult about manufacturing NuBus cards is that the connectors are hard to find. I think it would be better suited to e.g. RaSCSI since SCSI connectors are easier to find than NuBus connectors and can be made to work on more systems. However, the SCSI interface in 68k systems don't support DMA so the speed
  6. NetSurf is separated by multiple frontends, inside the "netsurf/frontends" directory of the source code. At the moment, there are Amiga, Atari, BeOS, framebuffer, GTK2/3, RISC OS, and Windows frontends.
  7. It seems like there isn't much information in one place on how the graphics on Classic MacOS work (relatively to modern graphics APIs like Vulkan etc). I'd like to document this further, hopefully to fix graphics acceleration for newer processor/OS or to implement your own graphics interface over NuBus or SCSI (e.g. RaSCSI). Let's start off with a few questions, and see if others can answer or provide documentation references. --- On older Macintoshes, you can access the framebuffer directly. Which machines or system configurations started to mak
  8. There's on-board RAM. The bus is going to be the bottle neck
  9. Latest GCC has more proper support for language features and has more optimizations. Also, it has a higher possibility to be automated with Continuous Integration compared to older toolchains.
  10. Looks like only emulation of fastram, IDE, mmu, fpu, and CPU. Rest is real hardware. I think the idea of PiStorm is nice, as you could have similar possibilities as RaSCSI but with more bandwidth. It looks like A314 (trapdoor expansion for Raspberry Pi) services can be integrated on the PiStorm.
  11. On Pi4, USB is implemented over PCIe. On CM4, the PCIe bus is exposed, allowing you to add USB or another interface. (PCIe<->PCI<->NuBus?)
  12. Most likely. The eMMC would take up the place of the SD connection.
  13. You can also use an eMMC to microSD adapter for your Raspberry Pi. eMMC are more reliable than microSD
  14. Binutils does not require any patches. The version used is 2.10.1. The last version of Binutils to support m68k-coff format is 2.16.1. GCC requires patches. I ported the patch to in unified format. Retro68 exists, but it creates applications for the Macintosh environment, not the UNIX environment. https://github.com/autc04/Retro68
  15. If I remember correctly, GCC is pre-installed on this image: https://github.com/unxmaal/aux_sdcard Be aware that it is an older GCC based on the 2.7 series. I planned to port GCC 10 but other things took my time. You cannot use the GCC patch as-is when cross-compiling, since it requires the native assembler instead of the one from GNU Binutils. It would be nice to use QEMU userspace emulation to run the programs from A/UX…
  • Create New...