Qwen 3.8 27b helped me with something unique that Opus 4 couldn't - Firmware + Software preservation and emulation on an early 2000's ARM based POS system
Mirrored from r/LocalLLaMA for archival readability. Support the source by reading on the original site.
| | Hi all, I made a post regarding how much Qwen 3.8 has improved over 3.6: I made a very thorough write-up of how Qwen 3.8 compared not only to 3.6, but frontier models when it came to creating a HTML version of Galaga, and to what degree it got the details correct. The biggest issue with this test is that all models know what Galaga is at this point, and probably has this exact scenario in it's training data. I took it upon myself and tried various real world examples of more unique stuff, and wanted to share this one that absolutely blew me away. This is something that I attempted last year with Opus 4.1, but couldn't get it to budge. Basically, I'm a software developer (yes, an actual software developer, I got my degree and was hand-typing code for a company a solid year before ChatGPT 3 came out and ANY vibe coding tools) and have always been fascinated with Point of Sale systems. My high school job was working in the food industry where we used this early 2000's point of sale system, titled the Sam4S SPS-2000: Backstory / Lore (feel free to skip this part if you want): It was made in 2006, and the restaurant I worked at used it up until 2024. This thing was a dinosaur and had many weird stability issues from time to time, and had a very interesting approach to data management. It was one of 6 terminals in our store, and being the IT guy, I dealt with most of the programming for item pricing, buttons, attempting to fix or avoid bugs, etc. I've had a love/hate relationship with this register because it was showing it's age very early on, but offered the most flexibility that any point of sale system ever had. We attempted to 'upgrade' to a newer system in 2021, but ended up reverting back (and losing $20,000 in the process) to this old system because the newer systems didn't let us to what was integral to the business. We could set up multiple button pages, multiple food items, different prices on different week days or happy hours, etc. The biggest bugs were that sometimes orders would get corrupt upon storage. The registers all had one 'hub' register that would store all the order data, and each register would have to FTP back and forth physical files for each order. My theory is that some interference would happen and cause bit flipping or something else that changes the order item's PLU ID. Another issue was that when the hub terminal had it's cash register drawer open, the 'CLOSE DRAWER' message that popped up if it was open for more than 30 seconds would thread lock everything and even make it so other terminals couldn't store or recall orders, until the drawer was closed. Just annoyances really, the new POS system we attempted in 2021 had much worse issues (credit card transactions would say they succeeded, but later would just disappear from our system and we would never see the money). This system was replaced in 2024, and I was sad to see it go. What I've been trying to do: Even before the retirement of the system, I have always tried to get a dump of the system program and wanted to see if I could fix any of these bugs myself, maybe even add some custom code for features that we've been wanting in the system. The hardware was also starting to die over the years so I wanted to see if I could port it to something like a Raspberry Pi. I cracked open this register to see if it was a regular PC or not, and to my surprise it was a custom ARM based system with flash memory (no HDD) and everything was soldered in. The cash register had a backup system where I could back up the current firmware, program, kernal, bootrom, and all config files to a USB. I also later learned that on their website, they offered these free to download as well, it's just out there! I didn't know if I need anything else or not, but in ~2019 I attempted to see if I could get it running in QEMU. It was 32 bit ELF binary data I was trying to run, not like an .exe file or anything. This was a raw program made up of ARM instructions for custom chips. I didn't have any luck whatsoever. After weeks of taking different approaches, I ended up just shelving the project. The only thing I managed to do was modify the sps2000 program code to include additional colors in the button designer's color palette, which had about 10 different colors I could choose from. I also modified it to not show the 'DRAWER OPEN' message when the drawer was open after 30 seconds so it wouldn't tie up the entire system when we had teenagers who struggled with counting out change quickly on the registers. I essentially couldn't emulate the program, though had no problem sifting through the raw code, making very minor tweaks, and patching it back onto the register by it's 'restore' function that allowed you to upload the binary files to the machine again. Last year when I was transferring my PC's files to a new hard drive, I came across all of these files and remembered the project. I had a Claude Code subscription with Opus 4, and I had it try to take a crack at what I was doing. It made more progress but it couldn't handle all the errors, any further debugging was one step forward, two steps back. The entirety of this past week, I've been working with Qwen to once again attempt to get this going. I'm happy to report that we did it! Granted, there was a lot of hand holding given the complexity of the matter, but that was the case with last year's Opus as well. Qwen build qemu-arm from source and implemented 4 needed patches in order for this thing to work. The /dev/ devices that the register expects and requires, that I don't have access to, Qwen looked at all the inputs and expected outputs for them. It deduced that /dev/buzzer was the beeper/buzzer that the register had, and simulated the sounds the actual buzzer would make when /dev/buzzer was touched, it knew that /dev/front was the touch screen panel that the register received touch data from and implemented a simulation that after some debugging, works perfectly. It knows that the /dev/screen is just a data block that holds raw screen pixel data, so it made a blank file for it to store this data in and made the simulator GUI interpret it and show it. I've ran through a complete real-world workflow and it has yet to crash, but thats only on single-register mode and I haven't even tried simulating an environment where other registers are FTPing data to eachother, like the real hardware does. Here's a video of someone using the actual register: https://www.youtube.com/watch?v=vBet8OQgRms And here's me fiddling with the emulator in action (I kinda forgot how to use it): https://reddit.com/link/1vwhcuf/video/8ft82d3dj6lh1/player The screen seems to update upon keypress rather than a fixed framerate (which is expected) so the FPS counter at the bottom isn't needed. It feels much more responsive than the actual register, probably because we're on hardware that's 20 years newer. Anyway, this is really cool to see for me personally as I've been wanting to do this forever. It obviously can't be used in a commercial settings for many reasons (practical, ethical, and legal) but personal/fun is probably more than fine. This emulator uses the firmware, bootrom, and program files from their public downloads page. I opted to use it as it was a slightly newer version of the program than the dump I had (2014 vs 2011). All of the files needed are publicly available from the manufacturers so it was only a matter of time until someone did this. I'm going to polish this up and release the emulator on GitHub (with human-made documentation, don't worry) for anyone who feels inclined to play with this thing or improve upon it, you just have to retrieve your own copy of the actual program and firmware and bootrom files from Sam4s's site. I know this is incredibly niche, but that's what made it perfect to gauge how far Qwen and LLMs in general have come. [link] [comments] |
Discussion (0)
Sign in to join the discussion. Free account, 30 seconds — email code or GitHub.
Sign in →No comments yet. Sign in and be the first to say something.