My interest in building my own WDC 65C816-based PC-on-a-card that could emulate an #AppleIIGS started a year ago, when I was looking for a job in the embedded systems space and wanted to practice writing something in Ada 2012 as a hobby project.
-
My interest in building my own WDC 65C816-based PC-on-a-card that could emulate an #AppleIIGS started a year ago, when I was looking for a job in the embedded systems space and wanted to practice writing something in Ada 2012 as a hobby project. I came up with the idea of an Apple IIe emulator since I figured it'd be much simpler than a #commodore64. Little did I reckon with the bizarre memory bank switching of different-sized segments for 80-column text (and "double hi-res" graphics).
-
I realized Ada is both unloved and becomes tedious after a while because it's so verbose. The C style with { } is overwhelmingly more popular than Pascal style begin / end, and Ada is even wordier than Pascal. The other annoyance is having up-to-date Ada bindings to any C libraries you want to use.
I think I should take the work I've done so far and convert it to #Rustlang before continuing, and extend it to Apple IIGS compatibility so I can then port that code to run on the RP2350 in my SBC.
-
I found the #AppleIIGS disk images and docs I'd downloaded last year, so I'm going to mess around with the GSplus emulator and check out the ORCA compilers which I purchased via Byteworks because they're still making new updates to the C compiler! You have to buy the latest full version to install the updated releases on the GitHub page. https://github.com/byteworksinc/ORCA-C/releases
I bought the package with all the source code as well. IIRC, the name comes from the macro assembler ORCA/M (macro spelled backwards).
-
It's weird to be reading about an Apple IIGS natively-hosted C compiler with C17 language support. GitHub says they're working on C23 features now.
I presume/hope the '816 code generation is good. WDC has their own C compiler and tools, but they only run on Windows and I don't like not having source code to the build tools I'm using.
tbqh, one area of the native OS design I want to have is that I need open-source equivalents to code packages Apple supplied for their devs, like SANE math libs.
-
SANE (Standard Apple Numerics Environment) is a fast IEEE-754-compliant math library written in 6502/65C816/68000 assembly language.
The Amiga came with IEEE software FP plus a second math library using Motorola's Fast Floating Point (FFP) format. Later 680x0 CPUs had optional IEEE-754-compliant FPUs, then the 68040 had an integrated FPU but slightly cut down from the external 68881/68882 FPUs. Transcendental routines such as trig functions requiring lookup tables removed, things like that.
-
ARM had a wacky byte-swapped original floating point format and then an FP accelerator (in the Acorn days) called FPA that used that format. At some point, the ARM community switched to standard IEEE FP, and then they added the VFP FPUs that we use today. Neon is the SIMD extension added later.
RISC OS has a version of BBC BASIC compiled for software ARM FP format, another for the rare Archimedes with the FPA accelerator, and a third version using the VFP and IEEE that you see on modern ARM.
-
In the 8-bit world, the Apple II series and the Commodore 8-bits share a large chunk of code licensed from Microsoft in the form of the BASIC interpreter. Microsoft 8K ROM BASIC uses their own custom FP routines and 5-byte variables (1-bit sign, 32-bit mantissa, 8-bit exponent). https://en.wikipedia.org/wiki/Microsoft_Binary_Format
It's not a bad set of math routines, AFAICT, but it is single-precision. The BASICs for x86 PCs, like GW-BASIC & QuickBASIC, as well as Acorn's BBC BASIC, also supported double-precision floats.
-
If you're an Apple IIe / IIGS developer working at the bare metal, e.g. for a game or the demoscene, Apple's manuals provide you with the ROM entrypoints for 16-bit ProDOS, SANE math libs, ADB I/O (keyboard/mouse, same as pre-USB Macs), and other libraries independently of GS/OS (the GUI).
I suppose the whole package is "GS/OS", and a lot of it is in ROM, at least for the later IIGS models that doubled the ROM from 128 KB to 256 KB.
Writing GUI apps is eerily like early Mac OS, e.g. QuickDraw.
-
As with classic Mac OS, the IIGS wants to be able to hand you chunks of RAM through a manager that it can then relocate at whim to defragment the RAM because there's no MMU to create contiguous virtual address spaces. So you have to do things through handles (pointers to pointers) and lock RAM in place at times to make sure it doesn't get moved.
Amiga OS was very fast because it had a tiny microkernel to pass messages that contained pointers to the areas of memory to manipulate to R/W directly.
-
You can't just add memory protection to AmigaOS because the architecture assumes user programs can share pointers with each other to chunks of RAM owned by each other.
Consequently, AmigaOS doesn't even attempt to compact regions of user-allocated memory because it has no idea where all the pointers might be within messages in transit, as well as in programs own memory.
I don't remember too many fragmentation issues. Running out of limited chip RAM, yes. Running out of total free RAM, yes.
-
P [email protected] shared this topic
