That is pretty amazing. Kudos to the authors, I never would have believed emulating an Apple II on an 8088 in a way that is actually usable would be remotely possible.
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.
That's more or less equivalent to reading out the RGB values of the colors[1]. As far as I know (never had one), the Apple II's output was composite NTSC, so what colors the values actually correspond to is also standardized. Of course, different monitors will still have different color output, but that's basically a choice, and for emulators a reasonable one is to just go with what the NTSC standard says.
[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.
> 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.
Thanks, that's great context. Do I read it right that the NTSC Apple II generated "artifact colors" (heard that before, but did not know if it applies to the Apple II) through effectively monochrome pixels that just work out to the desired color in NTSC, but since that would not work for PAL (because of the phase flip each line, and because the colors would be different), PAL Apple IIs have some extra circuit to convert artifact color pixels into YPbPr and then modulate that using the TCA650?
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.
I was super familiar with Nibble Magazine when I saw The Terminator in the theatre and it totally broke me out of my suspension of disbelief. I was still a youngster and almost wanted to say something out loud! haha.
I remember my Apple II "felt" quicker than the first 4.77 MHz IBMs I used. A lot of that was due to BIOS character output on CGA needing to coordinate when to write to VRAM with the 6845 to avoid causing "snow" on the screen.
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.
I think the 16-bitness alone won't help all that much except for some 16-bit address computations, but the bigger register set of the 8088/8086 and the code being written in assembly may allow to map 6502 registers to fixed 8086 registers, which is a pretty big advantage compared to writing the emulator in a high level language (not sure if the emulator uses that approach though, if it would just run the CPU emulation it would be trivial, but when emulating the whole hardware the manual register allocation may become a bit trickier).
8088 and 8086 are internally equivalent, the difference is the size of the data bus - which would make little difference if any when emulating an 8 bit data bus processor.
No. The 8088/86 was similar in speed to the 6502, around 1.4x faster.
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.
Oh my, the 6502 emulation [1] has fewer lines of assembly code than my (code-generated) implementation has lines of C code [2] :D
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).
Don't be sad, your code is pretty helpful! I use it with great success in my AccuraApple emulator :-) Thanks for giving it away, it helped me to boostrap my project much easier !
Looking at the src code gives me a headache. How can someone develop an actual emulator in Assembly? From where is the motivation and what is the principle?
Ah Karateka! We all know what happens at the end of the game if Karateka tries to kick Mariko when he enters her room. Apple's basic was my first language. I can hear Human League blasting away in my Sony Walkman.
48 comments
[ 3.4 ms ] story [ 142 ms ] threadThe 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.
https://youtu.be/l7rce6IQDWs
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 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.
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.
https://archive.org/details/2InaMac
https://arachnoid.com/electric_duet/index.html
I haven't seen them anywhere except for Apple keyboards.