The enulator in the browser
Our pie chart visualisation!

First stages

We began the began with the ambition to visualize data from the Mastodon federated social media software, using Python. We wanted to show the connections between people on the network as a graph of nodes and connections. The first step was to create our code environment, and thet's where we immediately encountered our first problem. Installing Taipy wasn't working! pip install taipy surely should've worked, but instead we were getting pages of output with unparseable errors at the end. The first error Jade encountered, she fixed by setting an environment variable specifying the version of visual studio for one dependancy to use - but that immediately surfaced another error. After what felt like hours, we figured out that pyarrow 0.10, one of taipy's dependancies, did not support any python version newer than 3.10.

However, now we had a working environment! The next step was pulling some data for our visualisations. We started simple, by pulling a list of the 110 people following Jade's accont and some metadata for each of them. After some confusion about there only being 40 entries, we discovered that the result was paginated, and implemented that, getting 67 results, and then after a bit more debugging the full 110. Conor was on the next part - creating somevisualisations! We created a pie chart of which servers Jade's followers were on, and a scatter plot of the amount of followers each user had against how many people they followed.

Our pie chart!

However, moving to the next part- visualising the network - we quickly encountered challenges in efficiently retrieving the required data and navigating unexpected 403 errors. This was a combination of third party servers having shut down, having different APIs, and using a technology called 'authorised fetch' - a complex technology that requires any program fetching the data to attest to its public identity. At this point, unfortunately, Jade and Maria had had to leave, so Dia and Conor were left with the hard decision to pivot towards a more immediatly feasible project—a Brookshear Machine Emulator.

The Brookshear Machine is a theoretical 8-bit computer architecture with it's own assembly langauge. It contains 16 general purpose 8-bit registers, a PC, and a 16-bit CIR. It was first written about in the book Computer Science an overview, and has since had additions made by professors at MIT and Sussex University. The version we emulated is from 2008 with these additions, with a total of 16 opcodes (0x0-0xF).

What it Does

Our project serves as the foundation for an in-browser emulator of the Brookshear machine code. It provides a platform for users to interact with and understand this machine code. We additionally built an assembler, which users can use to create machine code for the emulator.

How We Built It

A very painful all nighter, and sympathy (or maybe mockery? /j) during delerious debugging. The Assembler works by first doing some preproccessing of each line (basic comment, whitespace and empty line removal), then doing some basic string matching to find the assembly instruction. The whole instruction is passed into a relavent function which does more pattern matching to find the correct opcode and operands.

The emulator itself stores an 8 bit (well it's JS so it's not really, but we pretend it is) PC, a 16-bit CIR, an array of 16 8-biit registers, and an array of 256 8-bit memory cells. Each FDE cycle starts by fetching 2 memory cells, at addresses PC and PC+1 and loading that into the CIR (in big endian format), before incrementing the PC by 2. From there it gets the opcode stored in the highest nybble and calls the function for that opcode, the function then uses the operands to modify the relavent registers/memory cells. This continues until a Halt instruction is encountered (0xC000).

Challenges We Ran Into

JavaScript, being primarily designed for high-level operations, proved to be challenging when working at the bit level. Emulating correct overflows, and bit rotations specifically took some creative wranging and a non zero amount of &255. The ADDI and ADDF instructions both had required behaviour which didn't mesh well with JS's internal storing of numbers as well.

On the Assembler side of things; Whoever decided the single instruction MOV should be used to represent 5 different opcodes based on how the following arguments are provided made that function a pain to write. At the end of the project time certain MOV instructions would return NaN as their upper byte. This lead to having to test the Emulator by hand assembling into machine code!

Accomplishments We're Proud Of

Despite the challenges, we take pride in having developed a functional emulator. This achievement allowed us to delve deeper into addressing modes, pointers, and the intricacies of binary representation. Our journey of learning was as rewarding as the product itself.

What's Next for Brookshear Machine Emulator

We hope to improve on our porject by developing a new emulator in a language which compiles to WebAssembly. This will allow us more flexibility and performance in creating a correct emulator. Additionally, we hope to have an assembler which correctly handles MOV in future.