Sebastian Taylor 2026 3 19 http://localhost/diamond7/ diamond7 /diamond7/ Reverse Engineering Floppy Disk Filesystems see the repository here As part of the CST Part IB group project over the last few months, our group was allocated clients from the Cambridge University Library and Churchill College archives. We were presented with two collections of floppy disk images, both from old word-processing systems, with the task of recovering all the files from them. I was responsible for a set of disks from the Diamond 7 system, made in the early-80s by Data Recall Ltd wiki. There is no documentation online for this system. These disks were originally from the office of Neil Kinnock, where the word-processing system was in use. After initial inspection of the disks, no file-table data structure was located, neither were the disks in the CP/M 2.2 format, which was mentioned on the disk. Interestingly, most of the disks in the collection were designed to be bootable, the general structure was as follows: Bootloader, with a sled of RST 08h instructions (Z80 assembly): ......... 00000030: 0aff e1c1 c815 2811 7a1f d44f ffc5 7ae6 ......(.z..O..z. 00000040: 0306 14cc 40ff c118 e4c7 223a ffcd 40ff ....@.....":..@. 00000050: c079 d38e 2132 ff46 230e 90ed b33e 88cd .y..!2.F#....>.. 00000060: 51ff 473e bfd3 90db 90e6 21fe 01c0 78e6 Q.G>......!...x. 00000070: 9cc9 0d6d 8fff 002c 108d 0000 8acf 8b87 ...m...,........ 00000080: db8d b8c8 78d3 8f3e 1ccd 51ff e698 c93e ....x..>..Q....> 00000090: 00d3 8c3e 0b3d 20fd db8c b7f8 1f38 f917 ...>.= ......8.. 000000a0: c942 2331 2e4b 3a23 34cf cfcf cfcf cfcf .B#1.K:#4....... 000000b0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000000c0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000000d0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000000e0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000000f0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000100: 004a 004a 0500 0000 0000 0000 0000 0000 .J.J............ ... NULLS ... 00000200: 3148 4fcd 074a e93e 0032 004f cdd5 4dcd 1HO..J.>.2.O..M. 00000210: d94c 3e01 3200 4fcd d94a 3e02 3200 4f3e .L>.2.O..J>.2.O> . . . 00000580: 1428 858f 8acf 05cf 8b87 cd26 4dd0 7932 .(.........&M.y2 00000590: 024f fe01 3f30 02fe 1b3e 03d4 7e4a 79d3 .O..?0...>..~Jy. 000005a0: 8edb 88e6 feb2 d388 5623 7ed3 9015 20f9 ........V#~... . 000005b0: 78e6 0187 83cd fb4c 3ebf d390 db90 e621 x......L>......! 000005c0: ee01 3e0b c0db 8ce6 943e 0cc0 db88 e602 ..>......>...... 000005d0: fe02 3e0d c93e 18d3 853e 18d3 853e 18d3 ..>..>...>...>.. 000005e0: 873e 18d3 873e 18d3 973e 18d3 973e 18d3 .>...>...>...>.. 000005f0: 953e 18d3 95c9 db88 e6ef d388 c9db 88e6 .>.............. 00000600: bfd3 8818 f8cf cfcf cfcf cfcf cfcf cfcf ................ 00000610: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000620: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000630: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000640: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000650: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000660: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000670: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000680: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000690: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006a0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006b0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006c0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006d0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006e0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006f0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................]]> The most interesting part of the disk follows: system version information followed by some semi-structured binary data: BEBE Using diff to perform a comparison between disks of the same software version allowed me to distinguish between software data and disk-metadata (since only the disk metadata varies between these disks). The data above was determined to be disk metadata. The remaining two sections of the disk were a larger section of software (presumably the word processing software itself), followed by the actual text content of Kinnock's files, split into 256-byte sectors. To summarise, the general layout is as follows: Bootloader: from 0x000 to 0x700 Metadata: from 0x1900 to 0x3400 Software: from 0x3400 to ~0x3a400 Text data: rest of disk The next phase was to attempt to order the text sectors on the disk into full files using the metadata. Disassembling the software to help with this was an initial idea. However, this was not viable since the Z80 instruction set covers the whole 8-bit space, and the software spans a space larger than 16-bits can address, making the task of aliging jumps non-trivial. Therefore, the only recourse was to try to reconcile the contents of the metadata with the ordering of the text sectors. The lack of a file table on any of these disks meant I had to be creative. In the end, best-effort recovery was all that I could manage, but here is what I tried: Comparing binary information with sequences of sectors that seemed to be continuous file data on the disk The Diamond 7 was an ancestor of the Amstrad system, so I tried using cluster numberings used there to map from the binary data to the sectors Looking for structure corresponding to a FAT12 layout Comparing the position of the filenames within the binary section to locations on the disk itself These all proved fruitless. However, the file headers and footers on the disk had some discernible structure, and furthermore many of the files were stored roughly in sequence on the disk. Using the fact that multiple versions of the files were present in most cases allowed the files to be conservatively pieced together by scanning down the sectors from the top of a file, stopping either when the end is reached or when a sector unification would contradict another sector elsewhere: Try to unify: ...Mr Churchill’s government tak with Yours sincerely, ... Fails in the presence of the sector containing: ...’s government takes no responsibility for the downfall of... This led to good results, with only files that made sense being output. Since there is the occasional missed text sector (either it is control information, it is a sector from another version of a file already used, or it has been genuinely missed), the program also presents these in a file, along with a file of file names that have been recovered. References Context Sebastian Taylor 2025 11 2 http://localhost/0002/ 0002 /0002/ Technical Notes These notes include both exposition of work as well as documentation/scratch work. Sebastian Taylor 2026 3 19 http://localhost/diamond7/ diamond7 /diamond7/ Reverse Engineering Floppy Disk Filesystems see the repository here As part of the CST Part IB group project over the last few months, our group was allocated clients from the Cambridge University Library and Churchill College archives. We were presented with two collections of floppy disk images, both from old word-processing systems, with the task of recovering all the files from them. I was responsible for a set of disks from the Diamond 7 system, made in the early-80s by Data Recall Ltd wiki. There is no documentation online for this system. These disks were originally from the office of Neil Kinnock, where the word-processing system was in use. After initial inspection of the disks, no file-table data structure was located, neither were the disks in the CP/M 2.2 format, which was mentioned on the disk. Interestingly, most of the disks in the collection were designed to be bootable, the general structure was as follows: Bootloader, with a sled of RST 08h instructions (Z80 assembly): ......... 00000030: 0aff e1c1 c815 2811 7a1f d44f ffc5 7ae6 ......(.z..O..z. 00000040: 0306 14cc 40ff c118 e4c7 223a ffcd 40ff ....@.....":..@. 00000050: c079 d38e 2132 ff46 230e 90ed b33e 88cd .y..!2.F#....>.. 00000060: 51ff 473e bfd3 90db 90e6 21fe 01c0 78e6 Q.G>......!...x. 00000070: 9cc9 0d6d 8fff 002c 108d 0000 8acf 8b87 ...m...,........ 00000080: db8d b8c8 78d3 8f3e 1ccd 51ff e698 c93e ....x..>..Q....> 00000090: 00d3 8c3e 0b3d 20fd db8c b7f8 1f38 f917 ...>.= ......8.. 000000a0: c942 2331 2e4b 3a23 34cf cfcf cfcf cfcf .B#1.K:#4....... 000000b0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000000c0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000000d0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000000e0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000000f0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000100: 004a 004a 0500 0000 0000 0000 0000 0000 .J.J............ ... NULLS ... 00000200: 3148 4fcd 074a e93e 0032 004f cdd5 4dcd 1HO..J.>.2.O..M. 00000210: d94c 3e01 3200 4fcd d94a 3e02 3200 4f3e .L>.2.O..J>.2.O> . . . 00000580: 1428 858f 8acf 05cf 8b87 cd26 4dd0 7932 .(.........&M.y2 00000590: 024f fe01 3f30 02fe 1b3e 03d4 7e4a 79d3 .O..?0...>..~Jy. 000005a0: 8edb 88e6 feb2 d388 5623 7ed3 9015 20f9 ........V#~... . 000005b0: 78e6 0187 83cd fb4c 3ebf d390 db90 e621 x......L>......! 000005c0: ee01 3e0b c0db 8ce6 943e 0cc0 db88 e602 ..>......>...... 000005d0: fe02 3e0d c93e 18d3 853e 18d3 853e 18d3 ..>..>...>...>.. 000005e0: 873e 18d3 873e 18d3 973e 18d3 973e 18d3 .>...>...>...>.. 000005f0: 953e 18d3 95c9 db88 e6ef d388 c9db 88e6 .>.............. 00000600: bfd3 8818 f8cf cfcf cfcf cfcf cfcf cfcf ................ 00000610: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000620: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000630: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000640: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000650: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000660: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000670: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000680: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 00000690: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006a0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006b0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006c0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006d0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006e0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................ 000006f0: cfcf cfcf cfcf cfcf cfcf cfcf cfcf cfcf ................]]> The most interesting part of the disk follows: system version information followed by some semi-structured binary data: BEBE Using diff to perform a comparison between disks of the same software version allowed me to distinguish between software data and disk-metadata (since only the disk metadata varies between these disks). The data above was determined to be disk metadata. The remaining two sections of the disk were a larger section of software (presumably the word processing software itself), followed by the actual text content of Kinnock's files, split into 256-byte sectors. To summarise, the general layout is as follows: Bootloader: from 0x000 to 0x700 Metadata: from 0x1900 to 0x3400 Software: from 0x3400 to ~0x3a400 Text data: rest of disk The next phase was to attempt to order the text sectors on the disk into full files using the metadata. Disassembling the software to help with this was an initial idea. However, this was not viable since the Z80 instruction set covers the whole 8-bit space, and the software spans a space larger than 16-bits can address, making the task of aliging jumps non-trivial. Therefore, the only recourse was to try to reconcile the contents of the metadata with the ordering of the text sectors. The lack of a file table on any of these disks meant I had to be creative. In the end, best-effort recovery was all that I could manage, but here is what I tried: Comparing binary information with sequences of sectors that seemed to be continuous file data on the disk The Diamond 7 was an ancestor of the Amstrad system, so I tried using cluster numberings used there to map from the binary data to the sectors Looking for structure corresponding to a FAT12 layout Comparing the position of the filenames within the binary section to locations on the disk itself These all proved fruitless. However, the file headers and footers on the disk had some discernible structure, and furthermore many of the files were stored roughly in sequence on the disk. Using the fact that multiple versions of the files were present in most cases allowed the files to be conservatively pieced together by scanning down the sectors from the top of a file, stopping either when the end is reached or when a sector unification would contradict another sector elsewhere: Try to unify: ...Mr Churchill’s government tak with Yours sincerely, ... Fails in the presence of the sector containing: ...’s government takes no responsibility for the downfall of... This led to good results, with only files that made sense being output. Since there is the occasional missed text sector (either it is control information, it is a sector from another version of a file already used, or it has been genuinely missed), the program also presents these in a file, along with a file of file names that have been recovered. Sebastian Taylor 2025 11 2 http://localhost/0001/ 0001 /0001/ On Writing an Operating System I set out in summer 2025 to write a toy operating system on x86. The repository is here. This has been a fun project so far, with the development cycle consisting mostly of reading the manual for some hardware feature, then implementing and debugging interface code. It's taught me a great deal about how multi-faceted old platforms like x86 become, especially after having to read datasheets from the 80s. The OSDev Wiki page has been indispensible, and my main reference for the project I have written some documentation for the project so far: here it is file-by-file Sebastian Taylor 2025 11 2 http://localhost/0006/ 0006 /0006/ gdt Documentation for files gdt.h, gdt.asm and gdt.c void place_gdt_entry(const struct GDT_entry* data, void* addr) This function lays out the data field in the proper way for a Global Descriptor Table entry at the place addr void load_basic_gdt(void* addr) This function lays a bare-bones GDT at addr, featuring kernel code, kernel data, user code, user data segments and one task state segment uint16_t get_gdtr_limit() Extracts the limit member for the GDT from the currently loaded GDT in the CPU uint32_t get_gdtr_base() Extracts the address of the start of the currently loaded GDT void load_gdt(const struct GDT_descriptor* desc) Points the CPU GDTR to the GDT described by desc Sebastian Taylor 2025 11 2 http://localhost/0007/ 0007 /0007/ graphics A rudimentary graphics library designed to write to the VGA buffer. Documentation for files graphics.h, graphics.c WinFormat Struct describing memory layout for the VGA buffer. Note that double buffering is employed, with the VGA memory being at ren_buf and back-buffer draw memory being at draw_buf void set_layout(const struct WinFormat* fmt) Sets the (private) static state of the display configuration fmt void clear() Clears the draw_buf void swap() Swaps the buffers, leaving draw_buf in-tact void set_pixel(uint16_t x, uint16_t, pixel_t colour) Draws a single pixel at the specified location with VGA colour colour. Don't use for drawing bigger shapes for performance reasons void draw_rect(uint16_t xtl, uint16_t ytl, uint16_t w, uint16_t h, pixel_t colour) Filled rectangle Sebastian Taylor 2025 11 2 http://localhost/0008/ 0008 /0008/ idt Documentation for files idt.h, idt.asm, idt.c void null_handler() This interrupt handler does nothing void asm_handler() Currently a test handler wrapping the cool_handler ISR void load_idt(void* desc) Similar to load_gdt, this function loads our descriptor table at desc into the CPU's IDTR register void write_null_idt_entry(void* loc, uint16_t num) This code loads num null IDT entries (calling the null_handler) to address loc void load_idt_entry(void* loc, const struct IDT_entry* entry) Lays out the entry according the proper descriptor layout at loc void cool_handler() Do not call directly, since this function is not wrapped properly with iret. Currently prints the results of keypresses in VGA text mode 0x03 void setup_idt() Loads the current test IDT to location 0x1100 Sebastian Taylor 2025 11 2 http://localhost/0009/ 0009 /0009/ kernel File contains rudimentary VGA mode 0x03 terminal output. Documentation for file kernel.c void terminal_initialise() void terminal_setcolour(uint8_t colour) Sets colour for next characters, colour is an offset into the currently loaded colour palette in the VGA void terminal_putentryat(char c, uint8_t colour, size_t x, size_t y) void terminal_scroll() void terminal_putchar(char c) Supports newlines, tabs and backspaces void terminal_write(const char* data, size_t size) void terminal_writestring(const char* data) void println() void print_hex32|16|8 Fixed-width hex literal printing void print_vga_registers(const struct vga_regs_t* data) Text annotated output of current VGA state Sebastian Taylor 2025 11 2 http://localhost/000A/ 000A /000A/ keyboard Documentation for files keyboard.h, keyboard.c struct KeyEvent to_ascii(uint8_t scan_code) Converts the scancode coming off the interrupt into an ascii value, plus key event state Sebastian Taylor 2025 11 3 http://localhost/000B/ 000B /000B/ pic_8259 Documentation for files pic_8259.h, pic_8259.c. This unit is a Programmable Interrupt Controller of which there are two in modern CPUs. Each can issue 8 distinct hardware interrupts, mapped to some offset in the 256-entry IDT. This is a fascinating little device that has been around as far as I can tell unchanged since the 1980s. void pic8259_unmask() This code removes sets all mask bits for both PICs to zero void pic8259_disable() Sets all mask bits. Must be used if we wish to use the APIC. void pic8259_mask(uint16_t mask) Writes out a new mask. Low byte goes to PIC1, high byte to PIC2. void pic8259_init(uint8_t off_master, uint8_t off_slave) Initialises both PICs, mapping them to the given offsets in the IDT void pic8259_end_of_interrupt(uint8_t irq) Instructs the PIC that interrupt irq has been handled Sebastian Taylor 2025 11 3 http://localhost/000C/ 000C /000C/ utils Documentation for files utils.h, utils.c void* memset(void* dest, int ch, size_t count) Standard LibC style memset function void* memcpy(void* dest, const void* src, size_t n) Standard LibC style memcpy function size_t strlen(const char* str) Standard LibC style strlen function Sebastian Taylor 2025 11 3 http://localhost/000D/ 000D /000D/ utils Documentation for files vga.h, vga.c. See basic_io for vga.asm static inline uint8_t vga_entry_colour(enum vga_colour gf, enum vga_colour bg) Merges VGA 0x03 mode colour enums into a writable byte static inline uint16_t vga_entry(unsigned char uc, uint8_t colour) Merges a character and a colour into an unsigned short writable to the VGA memory buffer struct vga_regs_t read_vga_registers() Reads the important registers from the VGA void write_vga_registers(const struct vga_regs_t* data) Unchecked write of the new register map data to the VGA void vga_disable_display() Blanks the display void vga_enable_display() Unblanks the display uint8_t vga_read_attrib_reg(uint8_t idx) The Attribute registers in the VGA have a special reading/writing protocol making use of the same register for both index select and data output. Function reads the attribute register at index idx. void vga_write_attrib_reg(uint8_t idx, uint8_t data) See above. Function writes a byte to the specified attribute register in the VGA void vga_unlock_crtc() Allows writes to the CRT controller registers on the VGA void vga_lock_crtc() Blocks writes to the CRT controller registers on the VGA void set_vga_mode_0x13() Sets the graphical display mode to 0x13, 320x200 pixels void vga_draw_cool_pattern() >:D struct vga_colour_t vga_read_palette(uint8_t entry) Reads the DAC's palette on the VGA at the given index void vga_write_palette(uint8_t entry, struct vga_colour_t new_col) Write the DAC's palette with the given colour. Note that only the lower 6 bits are used in each colour channel. void vga_write_palette256() Writes the standard 0x13 256-colour palette to the VGA Sebastian Taylor 2025 11 9 http://localhost/000E/ 000E /000E/ MPC Double Pendulum Controller This project was a crude attempt at writing a controller for a reasonably complex system. The repository is here. The controller can sucessfully stabilise the system around all three unstable equilibriums. The project also included handwritten code for a rotary encoder and motor driver, with a view to put this into action on real hardware. If I were to do this again, I'd change the control scheme (a less expensive controller like an LQR would work well around the equilibriums, and there are stability results that I could reasonably rely on.). A robust implementation of the system would have to include a statistical model and characterisation of the sensors, including noise. Cost constraints meant that building a high-enough performance rig here was unfortunately not feasible. The gantry assembly. The gantry in action. Sebastian Taylor 2025 11 9 http://localhost/000F/ 000F /000F/ The Wave Function Collapse Algorithm This algorithm is a very neat constrained procedural terrain generation routine. The Problem. We are given a grid of cells (cast over any number of dimensions) (the Reference ), each with a number label . We are tasked with returning a new grid of cells (with arbitrary dimensions), such that the distribution of neighbour numbers for each number is as close to the Reference as possible (Cells are neighbours if they share an edge (2D) or a face (3D)). This is a surprisingly effective way to emulate the small-scale features of terrain over a large map. The Algorithm. In broad terms: For each unique number label in the Reference, compute , the probability of the neighbour on the edge taking on the value . For example, in 2D, can be (0, 1), (0, -1), (1, 0) or (-1, 0). Initialise each cell in the output grid into a superposition of states. A superposition is a probability distribution, giving the chance of the cell "collapsing" to a given value. If there is no cell that is fully collapsed, choose a random one and generate its collapsed state from its distribution. Recursively propagate distributions from any collapsed cells, asking what their distributions are given the contents of their neighbours. Some cells may end up in a state with a zero distribution. These cells fail to generate. Notes on the Implementation. There are two basic building blocks, a Pattern, representing the neighbour distributions of a single type (dirt, stone or sky for example). In our generation map, there are a series of Cells, each having their own distribution. The challenge here is that the number of unique tile types in the reference is effectively dynamic. This suggests a memory layout: struct Cell { std::vector<double> dist; // ... }; template <size_t D> struct Pattern { std::array<std::vector<double>, D*2> neighbour_dists; }; Where D is the dimension. We then have a vector of Cells which we update according to the algorithm. While this approach will certainly work, each cell having a pointer indirect to somewhere else on the heap is a rather silly memory layout. We can make all the cell data contiguous at the small cost of having to specify a maximum number of texture types N at compile time: template<size_t N> struct Cell { std::array<double, N> dist; // ... }; template <size_t D, size_t N> struct Pattern { std::array<std::array<double, N>, D*2> neighbour_dists; }; Sebastian Taylor 2026 1 6 http://localhost/4GXX/ 4GXX /4GXX/ My NEAT Implementation (2022) The NEAT (NeuroEvolution of Augmenting Topologies) algorithm is an effective genetic neuro-evolution algorithm from MIT. The original paper is here. It's approach is to split the population into different "species", so that topological improvements in the neural nets (which will initially reduce fitness) are allowed to evolve in their own niche. I wrote an implementation of the algorithm (here) and managed to tune it to fairly robustly balance a pole: the network swings up and balances a pole Sebastian Taylor 2026 1 6 http://localhost/X5PF/ X5PF /X5PF/ CREST Silver and Gold Awards (2021) These two awards were given to me in 2021 simultaneously for the project of "Building, Programming and Controlling a Quadcopter". I turned in a 37-page report on the project. This was a naive 14/15 year old attempt at an integrated control system, and I refined the project after the award increasing the motor DAC resolution to 12 bits and the Python to C++. Backlinks Related Contributions