Systems Engineering Projects in DhakaSystems Engineering Projects in Dhaka
Cover image for SSX Silicon 1: A Real
SSX Silicon 1: A Real 32-Bit Computer Processor Running Inside Google Sheets (https://github.com/Saminsami73/SSX-Silicon-1_-_A-CPU-that-runs-inside-Google-Sheets) Most people open Google Sheets to handle monthly budgets, invoices, or attendance logs. I wanted to see if spreadsheet cells could work as an actual computer chip. That led to SSX Silicon 1, a working 32-bit computer processor built inside a single Google Sheets workbook. It runs with 32 registers, a 16-kilobyte memory space, 36 instructions, and a 32 by 32 pixel color display. The sheet does not use pre-recorded animations, placeholder numbers, or external file links. Every calculation runs through a five-stage pipeline: fetch, decode, execute, memory access, and writeback. You can run the processor in two ways. With Google Sheets iterative calculation turned on, toggling a manual clock cell advances the machine cycle by cycle using native circular formulas. For continuous execution, an embedded Google Apps Script V8 engine powers interactive buttons and a custom top menu, running programs at hundreds of instructions per second. The 32-bit arithmetic logic unit handles numbers up to 4.29 billion across 36 instructions, covering arithmetic, division, bit shifting, logic gates, and subroutine branching. It also tracks four hardware status flags on every cycle: Zero, Carry, Sign, and Overflow. The memory layout organizes a self-contained 16-kilobyte address space across dedicated sheets. This includes 4,096 words of program ROM, 4,096 words of read-and-write data RAM, system I/O registers, and a stack region starting at address 0x3FFF. Thirty-two registers handle active computation: R0 stays fixed at zero, R1 through R27 store math and variables, and R28 through R31 serve as pointers for the frame, stack, return address, and program counter. A dedicated video RAM block at 0x2400 maps directly to a 32 by 32 grid of 1,024 cells, using conditional formatting and a 16-color RGB palette to draw borders, crosshairs, and pixel graphics. I also wrote a Python two-pass assembler that turns human-readable .ssx assembly code into spreadsheet-ready CSV tables, along with interactive HTML architecture diagrams built with Archify. To make sure the CPU calculates accurately, I tested every instruction against a Python reference emulator across five benchmark programs. The hardware self-test verifies all 32 arithmetic operations, memory reads, and stack frames in 77 cycles, leaving the golden signature 0xCAFEBABE in register R1. A 32-bit Fibonacci program generates 47 terms in RAM up to 1,836,311,903 without rounding or overflow. A prime number sieve finds all 25 primes under 100 using memory arrays, an integer matrix program calculates a 3x3 matrix product, and a graphics routine draws a multicolored geometric crest across 232 lit pixels. The project includes five PDF documents: an academic research paper, an instruction set manual, a microarchitecture specification, a verification report, and a beginner guide. Everything runs in a standard web browser. For anyone who wants to open the processor in Google Sheets, check out the Python compiler, or read the manuals (including the step-by-step Beginner Guidebook and Research Paper), the full open-source release is available on my GitHub! (https://github.com/Saminsami73/SSX-Silicon-1_-_A-CPU-that-runs-inside-Google-Sheets) Inside the repo (https://github.com/Saminsami73/SSX-Silicon-1_-_A-CPU-that-runs-inside-Google-Sheets), you will find: The ready-to-import Google Sheets CPU workbook (.xlsx) The Python assembler & bit-exact reference emulator Interactive HTML architecture & pipeline diagrams All 5 PDF manuals and the 5 sample assembly programs
13
19
6.3K
Cover image for Expert Business Email Setup with Google Workspace & Microsof...
Google Workspace and Microsoft 365 Business Email Setup Set up professional business email accounts using Google Workspace and Microsoft 365. The work included domain verification, mailbox creation, DNS configuration, MX records, SPF, DKIM, DMARC, admin settings, and final sending/receiving tests. This helped the business use reliable email accounts for daily communication, team operations, and outreach. My role: I handled the business email setup, DNS configuration, mailbox setup, and final testing. Tools used: Google Workspace, Microsoft 365, Google Admin Console, Microsoft Admin Center, Cloudflare, and DNS tools.
0
95
Cover image for SaminOS: A Full Operating System
SaminOS: A Full Operating System Stored in a Single Molecule of DNA (https://github.com/Saminsami73/SaminOS_DNA) Creator: Samin Sami (Samin Yasar Al Sami) The Story Behind the Project: Hey there, first off sorry for being this delay in posting projects on Contra. Well in my Contra profile I had uploaded and shown numerous love towards browser based Operating systems. We had seen a famous Vanilla based Win 95 (https://win95bysamin.netlify.app). A perfect retro functioning operating system running in your browser. Then I thought it would be more crazier to have AetherOS (https://aetherosbysamin.netlify.app), an AI agent based operating system running in a single HTML based file system! This year I decided I would build something different, something unique. Most operating systems today are massive. Windows and macOS take up tens of gigabytes of disk space and require gigabytes of memory just to show an empty desktop. Even a simple program usually carries megabytes of hidden background code. I wanted to find out how small a real, interactive operating system could be. I set a hard rule for myself: everything had to fit inside 512 bytes. That is the exact size of a single Master Boot Record sector on a computer hard drive. There is no room for bloat, third-party libraries, or sloppy instructions. Every single byte has to fight for its place. I wrote SaminOS in raw 16-bit x86 assembly language. When a computer turns on, its motherboard BIOS looks for the first sector of a disk, checks for a two-byte signature at the end, and loads the code directly into memory address 0x7C00. SaminOS takes full control of the machine from that exact moment. It does not just print a single line and freeze. SaminOS boots an interactive command line with a live blinking prompt. It draws a four-line bold ASCII art logo. It includes a keyboard driver that handles keystrokes, buffers characters in memory, and erases letters cleanly when you hit backspace. It reads the motherboard real-time clock chip, converts raw decimal numbers, and displays the local time in Dhaka. It gives you six working commands: help, info, time, say, cls, and reboot. The entire system takes up 508 bytes of machine instructions and text, leaving two empty padding bytes and the two-byte boot signature. Exactly 512 bytes. Then I realized something much bigger: that 512-byte operating system could live inside biology. How Code Turns into DNA: Computers think in binary numbers: 0 and 1. Living cells think in genetic letters: Adenine (A), Cytosine (C), Guanine (G), and Thymine (T). Because there are four genetic bases, each letter can store exactly two binary bits: - 00 becomes A - 01 becomes C - 10 becomes G - 11 becomes T Every byte of computer data contains eight bits. In my encoding system, each byte turns into a short four-letter genetic word. For example, the hex byte 0x55 (which is 01010101 in binary) turns into the letters CCCC. The hex byte 0xAA (which is 10101010) turns into GGGG. Because SaminOS is exactly 512 bytes long, the entire operating system translates into an exact strand of 2,048 DNA base pairs. This number changes everything. When large tech companies store data in DNA, such as movies or research archives, the files are millions of bytes long. Chemists cannot easily synthesize a million-letter strand of DNA in one piece. They must chop the data into thousands of tiny, scrambled fragments, store them in a pool, and rely on complicated mathematical algorithms to piece them back together later. If one piece gets lost, the whole file can break. SaminOS does not have to be chopped up. In nature, 2,048 letters is the normal size of a single bacterial gene. That means SaminOS exists as one single, unbroken, continuous strand of DNA. The entire bootloader, the kernel, the command engine, the clock math, the prompt, and the author metadata all fit onto one molecular polymer. From a Glass Tube to a Laptop Screen: People often ask: how can clear liquid in a tube run on a computer screen? The link between biology and hardware works in five clear steps: 1. Digital Compilation: A Python tool reads the 512-byte binary file of SaminOS two bits at a time. It maps each pair to A, C, G, or T, producing a 2,048-letter text sequence. 2. Chemical Synthesis: A DNA synthesizer prints the sequence. Instead of paper and ink, it links real molecules together, base by base, building physical double-helix strands floating in purified water. 3. Biological Storage: The dry DNA forms an invisible salt crystal, or dissolves into clear water. A single molecule of SaminOS is only 696 nanometers long and weighs 1.26 attograms. That is so small that a single drop of water can hold billions of complete copies of the operating system. 4. Nanopore Reading: To boot the system, you pipette a tiny droplet of the liquid into a portable DNA sequencer, like an Oxford Nanopore MinION. This device is smaller than a smartphone and plugs directly into a laptop via USB. Inside the device, an electrical current pulls the DNA strand through a microscopic protein pore. As each letter passes through, it creates a distinct dip in the electric current. 5. Silicon Boot: Software on the laptop reads those electric signals and turns them back into the original 512 bytes of machine code. A script loads those bytes into Sector 0 of a virtual drive or USB flash stick. The computer BIOS checks the last two bytes, confirms the 0x55AA boot signature, loads the code into RAM at 0x7C00, and boots SaminOS live on screen. Molecular Surgery: Using Enzymes as Hardware Switches: Because the computer instructions map directly to physical genetic letters, we can do something impossible with ordinary silicon: we can modify software using biology. In molecular biology, scientists use restriction enzymes. These are natural biological proteins that act like microscopic scissors. Each enzyme looks for one specific pattern of genetic letters and cuts the DNA strand at that exact spot. When we map SaminOS into DNA, our assembly instructions accidentally create real recognition sites for known enzymes: -SmaI and XmaI (They are the Boot Switch): The x86 boot signature 0x55AA translates into CCCCGGGG at base pairs 2041 to 2048. Both SmaI and XmaI cut the sequence CCCGGG. If you add SmaI to the vial, it snips the strand right inside the boot signature. It does not touch any of the commands or code, but the computer BIOS will refuse to boot the disk. It acts like a biological write-blocker or kill switch. - NsiI (The Keyboard Lock): At base pair 100, NsiI cuts right where the code calls the BIOS keyboard interrupt. Adding this enzyme physically unplugs the keyboard handler at the molecular level. - AseI, PmlI, and MscI (The Clock Cutters): All three enzymes cut inside the mathematical routine that decodes the motherboard real-time clock. - AgeI and SalI (The Dhaka Marker): Bases 1989 to 2008 spell out the word "Dhaka" in ASCII. The letters of the city name form the exact cutting site for AgeI and SalI. Dropping these enzymes into the tube cuts the geographic origin marker out of the code. - StuI (The Banner Cutter): This enzyme cuts through the exact middle of the ASCII art startup logo. You do not need a compiler or a hex editor to disable features. You can modify the binary using drops of liquid on a laboratory bench. Why I did this: This project is not just a technical puzzle. It points toward solutions for real problems in computing: 1. Storage That Lasts for Millennia: Modern hard drives fail within ten years. Magnetic tapes degrade. Flash memory loses charge. Synthetic DNA stored in tiny glass beads can last for tens of thousands of years at room temperature with zero electricity. SaminOS proves that executable software, not just static text or images, can be archived for deep time. 2. Extreme Data Density: DNA can store more information per cubic millimeter than any silicon chip known to science. All 512 bytes of SaminOS fit into an object smaller than a wavelength of visible light. You could pack copies for every person on Earth into a single drop of liquid. 3. Living Servers: Because 2,048 base pairs is the size of a normal gene, you can insert SaminOS into a harmless bacterium like E. coli. As the bacteria feed on basic nutrients, they duplicate the operating system billions of times without drawing power from an electrical wall outlet. 4. Absolute Physical Security: A vial of SaminOS has no radio antenna, no network card, and no electrical emissions. It cannot be scanned through an airport X-ray or intercepted across the internet. It exists outside the electromagnetic spectrum until it is sequenced. What This Project Demonstrates: SaminOS shows what happens when low-level assembly language meets synthetic biology. It demonstrates: 1. Deep mastery of bare-metal x86 architecture, memory layouts, and hardware interrupts. 2. Clean algorithm design under a strict 512-byte constraint. 3. Creative cross-disciplinary engineering linking computer science, information theory, and molecular genetics. 4. Clear communication that turns complex biocomputing concepts into accessible, human ideas. Ref and Source Links: 1. SaminOS Research at Zenodo: https://doi.org/10.5281/zenodo.23554876 2. SaminOS Github Repo with all tools and resources : https://github.com/Saminsami73/SaminOS_DNA 3. A 61 Page Guidebook of SaminOS DNA : https://github.com/Saminsami73/SaminOS_DNA/blob/main/SaminOS_Complete_Guidebook.pdf 4. SaminOS Main Research paper : https://github.com/Saminsami73/SaminOS_DNA/blob/main/SaminOS_Research_Paper_v2.pdf
22
16
8.4K
Cover image for Designed a complete multi-region private
Designed a complete multi-region private cloud architecture using OpenNebula across three geographically separated regions with a total of 20 physical servers. The solution provides centralized cloud management, regional workload isolation, secure inter-region connectivity, shared cloud services, disaster recovery, backup replication, and dedicated monitoring for the complete infrastructure. The environment was structured as follows: Primary Region: 8 servers Secondary Region: 8 servers Disaster Recovery and Expansion Region: 4 servers Centralized OpenNebula management and scheduling KVM-based virtualization across all compute nodes Regional firewalls, routers, load balancers, and gateway services Separate compute, storage, management, tenant, replication, and monitoring networks Shared storage and Ceph-based storage architecture Cross-region backup replication and workload failover Centralized image, template, user, network, and lifecycle management Secure administrator and tenant access through SSO and role-based access control A dedicated monitoring and observability environment was also designed separately from the production cloud network. The monitoring stack included Prometheus or Zabbix for metrics collection, Grafana for dashboards, Alertmanager for notifications, and Loki or the ELK Stack for centralized log management. Regional monitoring proxies and agents collect host, VM, storage, application, and network metrics from each region while keeping the monitoring infrastructure isolated from tenant and production traffic. The architecture was designed to provide: High availability across multiple regions Centralized private cloud management Secure workload and tenant isolation Disaster recovery and regional failover Scalable compute and storage capacity Centralized monitoring, logging, and alerting Infrastructure automation through APIs, Terraform, Ansible, and CI/CD pipelines This project demonstrates my ability to design secure, scalable, highly available private cloud platforms using OpenNebula, KVM, software-defined networking, distributed storage, infrastructure automation, and enterprise monitoring technologies.
1
269
Cover image for Proxmox Disaster Recovery and Network
Proxmox Disaster Recovery and Network Segmentation Design Designed a security-first Proxmox architecture separating VoIP, web, database, and management traffic with deny-by-default firewall policies. The solution uses HAProxy for web services, WireGuard for secure site-to-site connectivity, Proxmox Backup Server for off-site backups, and a standalone Contabo host for failover of critical PBX and escrow workloads.
0
79