The MOS 6502, Part 2

Another important aspect we need to care of is the speed that the CPU reads the instructions at. The real hardware is ruled by a signal that pulses. This is called Clock. This signal is very important because in the majority of the systems all components are synchronized and can work together.

In an emulated system this signal doesn't exist really, but it's simulated by a repeated task that executes all the components of the system for a time unit. Something like:

1) Execute CPU.
2) Draw graphics.
3) Check the keyboard.
...
n) Other task.

Now, the program that emulates the CPU is called every n time units and executes a specific number of instructions. 

The instructions usually take a certain amount of time, measured in clock pulses. So for example a CPU can take 2 clock pulses to perform an addition. Or maybe 5 clock pulses to access the RAM and save a value. Every instruction take a certain amount of cycles. It's very important to count these cycles in order to keep the correct speed of the system that is emulated.

The Apple-1 was "Clocked" at 1,023 MHz, this means that in a second the system receives 1,023,000. So one pulse every 977 micro seconds. If we want to emulate this kind of speed we can't pretend that a micro controller executes the virtual CPU at this speed, we would need a very fast micro controller. What we need is to reduce the number of times the virtual CPU is executed, and let it execute more instructions at once.

So for example we can setup a repeated cycle that runs at 102,300 Hz, 1/10th of the original frequency:

Every 102,300
1) Execute 10 cycles of CPU.
2) ...
n) Other task.

We can keep track of the cycles executes with a simple global counter, and update it after each instruction executed.

Every 102,300
1) Execute 10 cycles of CPU:
     - Instruction 1: -2 clocks, still 8 to execute.
     - Instruction 2: -5 clocks, still 3 to execute.
     - Instruction 3: -5 clocks, Overflow, the counter goes negative -2 cycles

n) Other task.

In the previous call the virtual CPU has executed 2 clocks more than needed, so for the next call the two clocks are subtracted from the number of cycles to execute.

Every 102,300
1) Execute 10-2 cycles of CPU:
   ...

n) Other task.

It's very important to read the documentation of the system, and then the documentation of all the components that the system uses.

The MOS 6502, Part 1

I won't dig to much deep into the architecture of this microprocessor, there is a lot of information over the Web, but I will discuss more about the way I implemented the "behavior" of the CPU in my Apple-1 emulator. If you want you can read more about this CPU on Wikipedia:

Wikipedia MOS 6502

Or you can find a lot of information, material, link and tutorial at:

www.6502.org

That said, the MOS 6502 is one of the most popular 8 bit processor used in the past, together with the Zilog Z80 dominated the market of the home/personal computers of the 70s/80s/90s.

From Wikipedia: The MOS 6502

From Wikipedia: The Zilog Z80

One of the most popular computer that was equipped with it is the Commodore 64, probably the most selling computer ever. Actually the CPU present in this computer was a 6510, but it's compatible and many sources say that this computer has a 6502, so we will assume it is so.

From Wikipedia: The Commodore 64.

One of the reasons why this CPU was so popular is because it's very simple but still powerful. Its architecture is simple, not many instructions, no complicated interfaces. A very good piece of hardware to use for building a computer around.

Like any other 8 bit CPU, the 6502 interfaces with the rest of the world through an address bus, and a data bus. All the informations are received and transmitted on the data bus, and all other chips are driven with the address bus.

The typical footprint of the 6502 shows the Address lines A0~A15 and the Data lines D0~D7. Then there are other very important lines that in a real hardware matters, such as the Phi0,1,2 lines used by the internal clock, or the NMI and INT that tell the CPU to perform specific tasks when the external hardware trigs it.  Software emulators, like mine, does everything inside a program so it's not necessary to replicate all those lines.

The emulation of a CPU is not that difficult. Every CPU performs tasks that are called by specific codes. These codes or Instructions are stored in the memory. So the CPU reads sequentially the codes and executes the program made of these codes. So, like a list of tasks, it starts from a specific point, and then it reads the codes and performs the task associated to that codes. Very simple.

We could abstract this behaviour with the following pseudo code:

START:

   Read next instruction.

   What is the code of the instruction?

      001: Do task 001

      002: Do task 002

      ...

      nnn; Do task nnn

   Go back to START

Of course it is a bit more complex than this example, but the idea is very simple. So it's a question of reading data from a memory, and performing instructions according to the value of the code read.

What we see from the footprint of the 6502 is that the address can be a 16 bit word, something like 0x1234, and Data can be an 8 bit byte, 0x12. So data is a value that can assume values from 0 to 255, while the address can assume values from 0 to 65535. This CPU can read 256 types of codes or instructions, from 65536 (0 included) different places or locations. Thus we now remember something of the old Commodore 64 :)

64 

It meant 64 Kbytes: 65536 / 1024 = 64

The Commodore 64 was sold saying that it had 64 KBytes of memory available, COOL, but not really true ;) Actually the 6502 CPU could handle 65536 locations of memory at startup but in the hardware the memory space is subdivided in different sections dedicated to different areas. So the real available memory to the user was less than 64KBytes.

Usually these kind of computers had a built in programming language, and several built in functionalities that were stored in  the memory space as Read Only Memory, or ROM. The real accessible memory, the Random Access Memory, or RAM, was reduced to 48, 32 or less KBytes.

What we need for our emulator is a program that reads and executes instructions in sequence from a ROM memory, and reads or stores data from/into a RAM memory :) In our emulator we don't have external memory chips so we will use the memory available in the microcontroller present in the board we are using.  I will discuss this later.

Apple-1 architecture

It is possible to find information about the Apple-1 architecture on Internet, but there are a few websites that describe it very well:

www.sbprojects.com

www.applefritter.com

So I personally thanks them for their support, very precious for my research. So, let's move to the Apple-1 block diagram. Here we can understand what this computer is made of:

Apple-1 blobk diagram by http://www.sbprojects.com

What we have here is:

• CPU 6502, at the center of the diagram. This is the core of the Apple-1.
• ROM 256 bytes, at the left most border. In this memory there is the "Monitor" program written by Wozniak. This is a kind of minimal BIOS, needed to enter programs.
• RAM 4+4Kb, on the left. This is the portion of memory used by the user to store programs.
• IO PPI 6821, on the right. This is the programmable input output interface that is used to drive the "world outside" the CPU: the video terminal, the keyboard and the expansion slot.
• Terminal Circuitry, at the top right. This is the electronic circuit that generates the composite video signal and shows the characters on the screen like a terminal.
• Keyboard, on the right most border. The Apple-1 originally didn't come with a keyboard. The user was supposed to buy it separately. In those ages it was common to find the ASCII keyboards, that for each key stroke they send an ASCII code to the computer through a data bus.
• Address Decoder, at the bottom left. This is the hardware circuitry that selects the chips of the board according to the address set by the CPU. This routes the data from/to the CPU.
• Expansion Slot, on the right bottom. This is the expansion bus of the Apple-1, where users could plug custom hardware or specific interfaces like the cassette tape interface (ACI).

I will discuss next all the components and how they are implemented in my emulator.

Considerations on the Apple-1 system

Originally the Apple-1 computer was planned to have a Motorola 6800 CPU, cheaper than a more popular Intel 8080 (400$ in those ages). So the project has never been developed, and remained on paper. It was modified to have a cheaper and better configurable 6502 ($25), just released in those ages.

So the Apple-1 was designed around this processor, equipped with RAM; a ROM containing the little operating system that Wozniak developed on purpose; a ROM containing the information on the character set for the video section; the hardware video terminal section; and a programmable input output interface chip.

Actually the computer is very simple compared to what we are used nowadays, but Mr. Wozniak was really smart in putting everything together. Especially the video terminal section is really clever because it is an assembly of logic ports and electronic components that are able to generate an NTSC composite video signal without a specific IC like modern video cards.

For my project the design is "easier" because I have to program everything software side, the tricky part is to emulate as best as possible timings and behaviour of the virtual hardware (CPU, I/O, Video signal etc.).

By any chance, who knows why software errors are called "Bugs"?

The first electric computers were made mostly of valves. These used to get very hot during operations of the computer so the huge electronic assembly became a very warm and cozy place for? ;)

It is said that when a renowned and seminal computer scientist "Grace Hopper" was working on a project in 1950's, one of her computer machines (a massive part-electrical part-mechanical) broke down because there was an actual bug (insect) in one of the circuits.

Women in tech history: Grace Hopper – Admiral, programmer, and rebel.

The insects caused the valves breaks, so the entire computer didn't work as expected. So engineers had to search the bug. That explains :) There's a good and interesting article about Mrs Hopper who was an incredible and pioneer woman in the computer science history:

Women in tech history: Grace Hopper – Admiral, programmer, and rebel

In 70s computers weren't so friendly

In the seventies computers weren't so friendly like nowadays they are. The software was essential and not as smart as now we expect to be. Programmers had to know everything about the computer: CPU, RAM, ROM, input and output ports, everything. There weren't high level programming languages like Python, Javascript or Delphi or others, but the most of the times they had to write programs in binary format, burn them on a EPROM, plug it on an IC socket on the motherboard and hope that everything was correct.

EPROMs plugged into their sockets on a motherboard.

The debug process was performed on paper instead during run-time. And Actually this approach saved a lot of time, and it should like that even nowadays with high levels programming languages.

A very good example of a hand written Assembly program.

The procedure of erasing and burning an EPROM was long, and sometimes tricky: some old EEPROMs had a tiny circular transparent window; right under that window there was the memory chip, and when you had to erase it, you needed to expose that to an UV light for a specific amount of time.

Old EPROM UV eraser.

We can understand that the development of a computer was affordable and possible mostly for professionals and big companies. Moreover the ICs and electronic components were very expensive, so it was really difficult to "experiment" with the hardware. Nowadays a microcontroller costs around 1$, so if a developer burns it who cares, but in the seventies a microprocessor had a price of hundreds of dollars!

Actually this wasn't really negative because engineers and programmers were pushed to do things once and right! And I personally think that this is the main reason why nowadays the software is alway full of bugs.

The replica projects: Mimeo and Replica 1

The first Apple-1 Replica project that I have found is the Mimeo project. This is a reproduction of a real Apple-1 board, where you have to solder real vintage parts. The result is a real clone of an Apple-1.

Mimeo 1 assembled board

This is a very cool project, and even you need an electronic background to assemble and test it, at the end you have a real clone almost identical to the original hardware.

The second Apple-1 replica project is the Replica 1, a bit different from the previous project in the use of the components.

The Replica 1 board

This is very interesting because here we have almost the same main components used in the original board such as the Motorola 6502, logic ports, Memory chips etc. But, for specific tasks like the I/O, handled by the PIA or the video terminal, we have a Parallax Propeller that does everything. I could call this not a real clone but a hybrid clone.

Now, there isn't really the right choice between these projects. I was interested in both of them, but at the end the challenge of building something is to start from scratch. I thought a third way. Since I have some experience in programming microcontrollers, I started to check if I could have created an emulator for a development board like Arduino. This choice leaves most of the work to the software coding, but you have also the chance to easily update the firmware without changing the hardware.

I didn't take in consideration the use of FPGA chips because this technology even if it's more suited for replicating a real hardware, it's very hard to configure, set and program.

So the work started with the first important question: How does a real Apple-1 work?