Edmond Wong

This is an emulator for a theoretical CPU with a simplified machine language that I made for educational purposes. The CPU uses memory mapping to interface with a Python Turtle Graphics controller. By writing to certain memory addresses it is possible to draw shapes on a canvas. Using this, I wrote a small program that drew this hexagon snowflake pattern.

This is chat bot that I made to remember Discord messages using a key value store. Instead of storing the message, the bot stores a reference to the message such that the data is stored on Discord, allowing the for updates to be done without the bot by just editing the Discord message. The primary use of this bot was to query documentation for Dungeon and Dragons, although it was also used to reference notes in a variety of Discord servers.

Additional features include animated timers and dice rolls. While simple, this was one of my more useful projects that saw frequent use in multiple private servers during its years of operation.

Rust HTTP web server utilities

These are a collection of middleware and services that I wrote when I was experimenting with using Rust for web development. They are compatible with Axum. Currently they are part of a web server in a private repository, but I may break them out and put them on GitHub later.

• A static file service that embeds files inside the program's binary. It supports etags and compression for gzip, brotil, and deflate.
• CSRF prevention middleware that checks fetch metadata and origin headers.
• HTMX integration for Axum.

8-bit CPU

While I was studying digital electronics, I decided to build a CPU from scratch as a way to bridge my understanding of electronics with my background in computer science. While I started by following Ben Eater's guide, since I've already have some digital electronics experience, I branched off from the guide whenever I could. Because of the CPU's architecture where everything is nicely broken down into self-contained modules connected by a central bus, I can branch off from the guide in implementation details. Later on, after knowing the interactions between the modules, I would then redo parts of the previous modules to add optimizations that required redesigning the system.

The most obvious change that I made to the original design was the Nixie tube display. Although conceptually simple, there were a whole lot of implementations challenges that I had to overcome for the tubes. First was building was the Nixie control module which wasn't too hard due to my prior knowledge of electronics. The hard part was with the high voltage power supply and the relay (electro-magnetic switch) used to toggle the Nixies. It's just a power supply and a switch, how could it possibly be hard? The problem was that the high-voltage requirement of the Nixies and the power consumption of the relay was very disruptive to the sensitive electronics of the CPU. While the CPU was in operation there would be seemingly random hardware glitches even though the system makes perfect logical sense, it was a physics problem. It was only after hours of isolating and testing did I finally realized that I had get a separate power source just for the Nixie tube unit.

The biggest change that I made to the original design was to increase the total addressable memory to 256 + 16 bytes from only 16 bytes. Previously the program counter was only 4-bits large due to the way that the 8-bit CPU instructions were split into a 4-bit operation code and a 4-bit argument. This made it impossible to jump to any memory address greater than 16. After improving the program counter module to support 8-bits, I had to redesign the the CPU instructions such that they support instructions 8-bit arguments by loading the argument from the next byte or from a register. Doing so was easy since the instructions was implemented in microcode which is essentially just a big lookup table that maps the op-code and clock cycle to a set of flags used to control the operation of each module. As for the new memory module, I decided to use an EEPROM. This way I would be able to program the CPU using the same arduino circuit used to program the microcode. Memory that needed to change often would be stored in the old 16 byte module and everything can be stored in the EEPROM. Given that this was a slow breadboard CPU, high-performance RAM is not necessay. Even writing persistent data would be possible although unnecessary.

CNC milled Genshin Impact Vision

For this project, I wanted to try to manufacture an item from the video game Genshin Impact and then do a small production run to sell if I deem it to to be profitable. While this type of merchandise is already proven to be in demand, there exists no high end variation in the market. Most are made with 3D printed plastic with a spray-on zinc coating and the metal ones have to make some heavy sacrifices in design to be more cheaply manufactured. So I attempted a version without such compromises.

While my CAD experience is in Autodesk Inventor, my student license has expired so I modeled on the open-sourced FreeCAD instead. With some online pictures as a reference, I was able to create a model looks essentially like in-game version but with small almost unnoticeable tweaks that allowed the frame to be produced in only two setups on the mill without any special or custom tooling.

The difficult problems was in CAM. The reality is that the open-source ecosystem is heavily under-developed when it comes to CNC milling. FreeCAD's CAM toolkit lacked many essential features. In order to create a more efficient program I had to write a few Python scripts to generate several of the necessary tool paths. The generated tool paths are kept in sync with the model because my scripts each take in a FreeCAD sketch as an input, since the sketches are constrained to the model they are updated whenever the model is updated.

After milling came another problem. The marks left by the mill looked horrible. To get rid of the markings I would have to go though several stages of grinding/polishing. Polishing also helps combating corrosion since a smoother surface has a smaller surface area that is in contact with oxygen. The problem is that polishing requires a large amount of human labor, several repetitive stages, and the product's geometry is too complex for me to polish quickly with motorized tools. I first did several experiments using a variety of tools and techniques to cut down the human cost, then I automated the early stages on the CNC mill using ceramic brushes (A and B), but despite my efforts the was still a significant amount of work that needed to be done by hand. I ultimately decided that it was not worth the labor to take it to production.

Autodesk Inventor Star Wars Project

This is a project that I did in high school to learn how to use Autodesk Inventor. I got a picture of a ship from Star Wars and tried to make a CAD model of it. Each movable part is modeled separately and is assembled together using Inventor's joint system, allowing for the model to be animated and be moved around for various poses.