Appler: Apple ][ emulator for IBM PC, written in 8088 assembly
github.com
github.com
The story in the README is also worth reading! E.g.
> At the time we wrote Appler we of course knew that the colors are supposed to be purple, blue, green, and orange, but we had never seen them displayed by an actual physical computer, because the Apple ][ displays that were available in Bulgaria were all monochrome-green. Alex looked at the schematics, and he used the actual resistor values of the DAC to calculate what the 4 primary colors should be.
WHAT??? Awesome
[1] Might not actually be RGB, did not look at the schematic. But having RGB before modulating into NTSC's color difference signals is not uncommon.
The standard NTSC Apple II does not generate color this way, but the European PAL models do.
The native Apple II video signal is 560x192 1-bit monochrome pixels. The PAL video circuit converts video signal into a digital stream of color pixels, 4 bits per pixel. It then converts the digital pixels into analog YPbPr signals by attaching various resistors to each of the 4 bits. The YPbPr signals are then fed into a PAL encoder chip.
Presumably, the original authors used these YPbPr resistor values to determine the colors sent to their Bulgarian PAL/SECAM encoder.
This is a schematic of the PAL color encoder for the Apple IIe: https://imgur.com/CQH7vNS
1. The native monochrome video signal is SEROUT in the top-left of the schematic. It is fed into the LS164 shift register.
2. The LS175 buffer captures each 4-bit color pixel from the shift register.
3. The output of the LS175 is then fed through a various resistors to generate the YPbPr signal which are fed into the TCA650 PAL encoder.
The PAL color circuit was initially an expansion card for the Apple II+ in 1979. The same circuit was built-in to the later Apple IIe and IIc models.
A novel part of the design is that the TCA650 is actually a PAL decoder chip that is meant to split a composite video signal into YPbPr components. The Apple II drives the TCA650 in reverse to generate the composite signal.
Very nice use of a macro assembler though [3], makes the code feel very high level.
To my defense, my generated code has a lot of redundancies (such as assert(false) which were meant to catch any 'stray cycles' but which are removed in release mode - and it could be more compact if it would use preprocessor macros (but since the code is generated anyway that seemed kinda wrong).
[1] https://github.com/zajo/appler/blob/develop/src/65C02.ASM
[2] https://github.com/floooh/chips/blob/master/chips/m6502.h
[3] https://github.com/zajo/appler/blob/52aaa0f768cdf303438cd2c7...
I'm also planning on using your header files in another emulator project I'm working on. Thanks for a building an awesome set of emulators.
It was developed in 1990, at a time when Apple IIe was still in
production, which means that Appler is likely the first Apple ][
emulator ever made
I knew that Bender from Futurama had a 6502 as his brain (https://spectrum.ieee.org/the-truth-about-benders-brain), but I expected the Terminator to be powered by something a bit more advanced...
The mind behind the 6502 was interviewed at CHM.
https://www.pagetable.com/?p=64
(More details in the recent comments at the bottom.)
The only way to make it better is to change the spelling to App][er. It's an extra l that way, but I think that's forgivable.
I haven't seen them anywhere except for Apple keyboards.
I understand it wouldn't feel like much of an upgrade.
The ARM team decided to design their own CPU because they felt that the available options weren't that much better than the 6502 as they wished them to be.
A => dl
X => cx
Y => bp
PC => si
The Z and N flags are stored directly in the 8086 ZF and SF, while dh stores the C and the O flags. The stack pointer is stored in memory."
The clock speed was higher (4.77 vs 1MHz) but it was generally less efficient.
However, it was an easier machine to use. The Apple 2 was full of Woz shortcuts as the article mentioned. Made it cheap, but hard to program. Not just the floppy and the speaker, the high res graphics mode (HGR) had memory addresses that were not aligned to actual screen rows. The first row of pixels started at $8000. The next row in memory was 1/3 of the way down the screen, probably due to refresh timing.
Amazing what was achieved on such hardware, in days when documentation was good, but very hard to find.