30 BUILDS MATILDA ================= VibeDroneSwagman / Matilda Emulator Journey to Build 0.30 Compiled 21 September 2026 PURPOSE ------- This file records the development journey of the Matilda emulator project up to VibeDroneSwagman build 0.30, with emphasis on the discoveries, regressions, diagnostics, and hardware evidence that moved the project forward. PROJECT TARGET -------------- The target is the Microbee Matilda / 640TC environment built around the NEC V40 (µPD70208) CPU and the original Matilda ROM/BIOS. The long-term aim is not merely to display the POST screen, but to reproduce the machine closely enough to run its DOS environment and the 640TC CP/M emulation software, including keyboard, floppy, CMOS/RTC, video, interrupts, and the host-interface services used by the 640TC BIOS. EARLY BUILDS ------------ Builds before 0.18 established the basic Matilda framework: CPU execution, ROM mapping, video output, floppy-controller support, machine-state dumps, and the ability to reach substantial portions of the Matilda BIOS POST sequence. The exact change log for every build from 0.01 through 0.17 is not completely reconstructed in this document. By 0.17 the project had reached a stable enough state that the remaining major blocker was the keyboard path. BUILD 0.18 ---------- 0.18 became the clean recovery point after a corrupted build. At this stage the machine was active and progressing through POST, but the keyboard still did nothing. State evidence showed: - CPU active in F000 ROM space. - Keyboard controller enabled. - Scanning enabled. - Data latched in the controller. - IRQ activity pending. - BIOS already performing 8042 self-test/command traffic. This shifted attention away from browser key mapping and toward the KBC/PIC interaction. BUILD 0.19 ---------- 0.19 concentrated on keyboard IRQ delivery. Changes included: - preserving queued keystrokes while the BIOS temporarily disabled keyboard interface traffic; - asserting IRQ1 when appropriate; - reasserting IRQ1 when more keyboard bytes remained; - stopping controller response bytes from being treated as ordinary user-key interrupts. Result: IRQ1 could be raised, but the keyboard was still not usable. BUILD 0.20 ---------- The 0.19 dump showed IRQ1 pending while IRQ0 remained in service. 0.20 therefore changed PIT/PIC behaviour so IRQ0 acted more like an edge rather than continually re-latching while already pending/in service. A PIT0 diagnostic value was also added to the machine-state report. Result: IRQ0 starvation was reduced, but the interrupt controller could still become stuck with IRQ0 in service. BUILD 0.21 ---------- 0.21 added a safety fallback around hardware interrupt retirement. The emulator began tracking hardware interrupt frames and retiring the PIC ISR state on IRET when required. If the BIOS had already sent EOI, the fallback was a no-op; otherwise it prevented a stale IRQ0 from permanently blocking IRQ1. This was a major improvement: - IRR could return to 00. - ISR could return to 00. - the KBC queue could drain. BUILD 0.22 ---------- 0.22 added detailed keyboard-path instrumentation. The state dump began reporting: - host key event count; - last translated scan code; - IRQ1 delivery count; - INT 09h entry count; - port 60h read count; - last port 60h byte; - BIOS keyboard-buffer head/tail pointers. This proved that the path could reach: host key -> scan code -> IRQ1 -> INT 09h -> port 60h. The BIOS keyboard buffer nevertheless remained empty. BUILD 0.23 ---------- 0.23 added: - CMOS/RTC access tracing; - keyboard shift-flag reporting; - cleaner diagnostics around the dump gesture. An important discovery was made: the scan code 1Dh seen in earlier dumps was mostly the Ctrl key used to trigger the diagnostic dump itself. This explained some apparently successful INT 09h activity that never created characters: Ctrl alone should not place a printable key in the BIOS buffer. BUILD 0.24 ---------- 0.24 separated the diagnostic Ctrl gesture from normal emulated keyboard input. It also added a HOST KEY LOG showing: - key down/up; - browser KeyboardEvent.code; - generated scan code; - whether the event was deliberately suppressed. This build finally proved that ordinary keys such as X, C, V, J, Space and others were reaching the emulator. However, the machine could enter a HLT loop around F000:7E4C while: - the keyboard interface was disabled; - host scan codes were still visible to the BIOS; - a large number of scan bytes accumulated. That exposed an 8042 modelling error. BUILD 0.25 ---------- 0.25 corrected the rule that user keyboard bytes must not be exposed through port 60h while the keyboard interface is disabled. Host keys could remain queued internally, but the BIOS would no longer see them during controller initialization/POST as if they were controller responses. This restored a much cleaner active state. BUILD 0.26 ---------- 0.25 still showed nine latched bytes even when no real user key had been accepted. Those nine bytes matched three keyboard-identification sequences: F2 command -> FA AB 83 F2 command -> FA AB 83 F2 command -> FA AB 83 0.26 therefore separated keyboard-device response traffic from user scan-code traffic and ensured response bytes could assert/reassert IRQ1 until fully consumed. Diagnostics were split into: RESP= USER= This stopped keyboard-identification replies from sitting indefinitely in front of real keyboard input. BUILD 0.27 ---------- The Matilda 640TC schematics changed our understanding of the interrupt path. The schematics showed: - a real Intel 8042 at U11; - data bus XD0-XD7 connected to the 8042; - XI0R/XI0W driving the controller read/write strobes; - XA2 driving the 8042 address-select input; - the expected 60h/64h register pair; - keyboard clock/data driven through open-collector interface circuitry; - IRQ1 feeding the NEC V40 INTP1 input. Most importantly, the Matilda did not use a separate PC-style 8259 in the usual way. The V40 has an integrated interrupt controller. 0.27 therefore changed the emulator's keyboard interrupt model toward: keyboard -> 8042 U11 -> V40 INTP1 -> V40 internal interrupt controller. It also added explicit INTP1 line and edge diagnostics. The 0.27 dump was encouraging: - response queue empty; - user queue empty; - INTP1 idle; - F2 identification response consumed correctly. BUILD 0.28 ---------- 0.28 continued the V40/8042 work and updated the visible build header. This build later produced the most revealing keyboard failure so far. After typing, the state showed: - 40 real user scan bytes queued; - keyboard interface disabled; - roughly 730 IRQ1 deliveries; - roughly 730 INT 09h entries; - repeated port 60h reads returning 00; - BIOS keyboard buffer corrupted/non-sensical rather than containing normal keystrokes. This exposed a disconnect between IRQ1 delivery and the byte actually returned by port 60h. BUILD 0.29 ---------- 0.29 directly targeted the IRQ1/port-60 queue disconnect. The intention was that each keyboard interrupt would correspond to the actual front byte of the appropriate queue, instead of repeatedly driving INT 09h while returning 00. A packaging mistake remained: the file was named 0.29 but some visible/internal build labels still reported 0.28. BUILD 0.30 ---------- 0.30 corrected build identification consistently. The build-number/header problem was moved to a single consistent build identity so the HTML title, UI, diagnostics and state report no longer drift away from the actual downloadable build. 0.30 retains the keyboard queue / port-60 work introduced in 0.29. MATILDA SERVICING NOTES ----------------------- The original 1990 Matilda servicing notes turned out to be extremely valuable. They confirm that Matilda was difficult even in its own era. The notes state that: - video could take 8-10 seconds to appear; - another roughly 45 seconds could pass before the machine became usable; - the machine could report "Auxiliary input port interface test failed"; - faults around U11, the 8042 keyboard controller, were a known cause; - the famous "Keyboard/Mouse fuse is blown" message referred to a fuse that did not actually exist; - the keyboard interface board itself could behave bizarrely; - a 47 pF capacitor modification reportedly repaired many keyboard interface boards despite there being no obvious theoretical reason for that exact value. The notes also document many production fixes, timing problems, wrong component values, and board-level modifications required to make real Matildas reliable. In other words: the emulator is reproducing a machine whose real hardware was famously sensitive to timing and implementation details. CMOS / RTC ---------- The emulator does have CMOS RAM and standard 70h/71h access. Diagnostics showed very heavy CMOS activity during POST, proving the BIOS actively depends on configuration-state reads and writes. The servicing notes also identify the 82C606 and its battery-backed RTC/config logic as a major source of real Matilda faults. This remains an area worth modelling carefully. THE 640TC BOOT DISK ------------------- The image: matilda_boot_disk_bios9_ds80.dsk was inspected and identified as a genuine 800K 640TC CP/M system disk. Geometry: 80 cylinders 2 sides 10 sectors/track 512 bytes/sector 819,200 bytes raw payload The disk identifies itself with: "MicroBee 640TC CP/M BIOS version 9" "256k CP/M vers 2.20" It contains the expected 640TC ecosystem, including: SHELL.SYS CCP.SYS INIT.COM TRANSFER.COM BACKUP.COM BASIC.COM HELP.COM EP.COM FN.COM PICFONT.COM WP.COM BIOS 9 EXTRACTION AND DISASSEMBLY --------------------------------- The boot/system tracks were extracted and the runtime BIOS image was reconstructed. Generated artefacts: matilda_bios9_system_tracks_side0_0-3.bin matilda_bios9_reconstructed_D600-FAC5.bin matilda_bios9_disassembly_notes.txt The boot sequence revealed a critical 640TC host-service entry: CALL E039h The boot loader uses E039h to load blocks of the CP/M image, relocates the loaded code upward, and finally jumps into the BIOS at: JP E400h The standard BIOS jump table at E400h was identified. Important disk calls include: E418 HOME -> E9AA -> ED32 E41B SELDSK -> E9AF -> EC51 E41E SETTRK -> E9B4 -> ED34 E421 SETSEC -> E9B9 -> ED2D E424 SETDMA -> E9BE -> ED28 E427 READ -> E9C3 -> ED39 E42A WRITE -> E9C8 -> ED48 E430 SECTRAN -> E9D2 -> ECE5 Working variables identified so far: FB0E = DMA address FB10 = selected drive FB11 = track FB12 = sector The BIOS eventually reaches physical disk hardware through ports in the 44h-48h and 90h-92h ranges, while port 50h appears around machine/bank-mode changes. The E039h service entry and the wider E000h service block remain major targets for continued reverse engineering. INIT V3.03 ---------- The standalone program: init_3d80_v3.03_640tc.com was also inspected. It identifies itself as: "INIT v3.03 - 3.5\" 800k 640TC version" created 30/5/91 It explicitly requires: Microbee 640TC emulation software version 1.2 or higher BIOS version 06 or later This is valuable because it confirms that significant parts of the 640TC environment are software contracts between CP/M-side programs and the Matilda host/emulation layer, not merely generic CP/M behaviour. CURRENT STATE AT BUILD 0.30 --------------------------- The project has progressed from "keyboard does nothing" to a much narrower and better-understood problem. We have proved: - browser keyboard events can be captured; - PC/AT-style scan codes can be generated; - the 8042 model can accept host keys; - IRQ1/INTP1 can be asserted; - INT 09h can execute; - keyboard-identification commands and FA/AB/83 replies can be modelled; - the V40 interrupt path is more appropriate than assuming a discrete 8259; - the Matilda BIOS actively talks to ports 60h/64h in the expected way. The remaining keyboard problem is primarily synchronization and data ownership: the byte that causes INTP1/INT 09h must be exactly the byte made visible at port 60h at that moment, with controller responses and user scan codes obeying the same ordering and enable/disable rules as the real U11 8042. NEXT PRIORITIES --------------- 1. Test build 0.30 with a deliberate string such as: ABCDEF 123 before generating the diagnostic dump. 2. Confirm that: HOST count increases; USER queue changes; INTP1 edges correspond to real bytes; INT09 count follows; port 60h returns the expected scan codes rather than 00; BIOS keyboard head/tail pointers become sane. 3. Continue disassembly of BIOS 9, especially: E039h the E000h service block disk I/O entry points bank-switch / host-interface calls 4. Cross-reference those calls with the Matilda ROM and schematics. 5. Continue using the original servicing notes as evidence for timing-sensitive or non-standard hardware behaviour. CONVENTION ---------- Every new build should: - increment the build number; - update the visible header; - update the internal/state-report build identification; - preserve diagnostic facilities; - be output immediately as a direct downloadable HTML file. Current build: VibeDroneSwagman 0.30 END