Like the rest of the world I am tinkering with AI. I spend a lot of time going “Can it do this …”. When I first started playing with AI a few years ago, my general concensus was “Good at modern languages, but rubbish at older retro stuff”. For example, asking any AI to write 6502 or Z80 assembler was most likely going to leave you disappointed. But that’s all changed now.<\/p>\n\n\n\n\n\n\n\n
While I have my own ‘AI workstation’ for running local models, I realise the ‘frontier models’ from Anthropic and OpenAI are significantly better and to help me experiment more I ended up getting the cheapest Anthropic subscription to contain costs. So a lot of this article is all referring to claude code on Sonnet 5 primarily because that’s what I had and I didn’t want to spend more money on more subscriptions just to compare. I suspect that the offerings from openAI and others are probably just as good as what I discovered with Sonnet 5.<\/p>\n\n\n\n
So essentially I set out to do a number of experiments to see how good Sonnet 5 is at writing retro stuff (but I also asked a lot of hardware design questions along the way too). The TL;DR is “its very good”. In terms of 8 bit assembly language it is very good at writing z80 and 6502 assembly ( I didn’t test with any others). It makes mistakes like a human does such as register clobbering, but you can ask it to try to recheck for that style of bug which improves but does not eliminate the issue. The code it produces works, but its not the type of code that would ‘impress your mates back in the 80s’. Its functional. I found there were times too where I knew that something could be optimised down substantially and it felt like I was spending more time convincing Sonnet 5, than getting it to write code.<\/p>\n\n\n\n
Anyway, one of my first experiments was to port the game “Planet Defender” to MSX. So Planet Defender is an 8KB cartridge game for the Funvision\/Wizzard\/Creativision<\/a> machines from the early 1980s. Its a really nice smooth scrolling defender clone. Given that the video chip has no hardware scroling, I always thought it was quite awesome. The Funvision had a 2MHZ 6502A, a TMS9929 (ie. 9918\/9928 etc) video chip and a 76489 sound chip. It had the usual 16KB of VRAM for the video chip and only 1KB of RAM for the CPU (which was not that uncommon in this era). So the video chip is the same as used by MSX<\/a>, but MSX had a Z80A CPU and used a AY-3-8910 sound chip. So I used claude code for this and basically my CLAUDE.md just said “Port the Funvision game planet defender to MSX”. So a few key things happened as it ported it<\/p>\n\n\n\n I’ve uploaded the experiment to msx-planet-defender<\/a> . It is much the same as the original Planet Defender.<\/p>\n\n\n\n In another experiment I asked Claude to write a BASIC interpreter for MSX from scratch. This used CBIOS as the underlying BIOS so it wasn’t a complete ‘from scratch’ ROM for MSX. Again, this was very impressive and I would just add commands as I went. Effectively I ended up with a Tiny BASIC that was not much compatible with real MSX BASIC, but it could actually load a few different games from cassette images as BLOAD games dont actually care about BASIC and the RUN “CAS:” type games generally only have less than 10 lines of BASIC then a BLOAD command at the end, so they only needed to understand a subset of BASIC to actually work. So the Tiny BASIC was only taking up about 5K, so I asked Claude to add in an entire Z80 Assembler inside the BASIC interpreter, and it did. The interesting part is that as it added in different groups of instructions to the assembler it would work out small BASIC test programs to run with openmsx, sort of automatically type them in slowly, run them and snapshot the screen.<\/p>\n\n\n\n In another experiment I asked Claude to write a simple Breakout clone in Z80 Machine Code. But to write the assembly code and ‘hand assemble it’. So hand assembly is not something anybody does these days, but in the early 1980s when kids had one computer, a casssette interface and no assembler, your only option was to write Z80 assembly programs on a paper notebook and then look up the hex opcodes for each line, then type those hex codes in. Basically I was asking Claude to do the same and ‘skip running an assembler to assemble it’ … and it did. If you look at what it did, it effectively wrote the Z80 Assembly instructions as comments on lines that just included the hex codes. Effectively it was assembling the instructions without an assembler.<\/p>\n\n\n\n I then ventured in to hardware design. I quite like the Z80 based systems that used the CPU to generate video. The ZX-80 and Galaksija did this. There are different ways to do this but it often involves the Z80 being forced to see NOPs on its databus so that it can ‘walk through video addresses’ or to use the refresh cycles in M1 cycles to generate video addresses. Again, Claude knew all about this stuff. And my first idea sort of looked like this<\/p>\n\n\n\n So that all worked on some breadboards, and Claude helped a lot at fleshing this design out. It did get stuck in a few places. The way the Z80 only updates the bottom 7 bits of R got confusing for a while, but it eventually all worked with some nudging and testing. Then I decided to do a benchmark to work out just how much slower the Z80 is due to all the line generation and interrupts. Effectively its busy doing video generation for 200 out of 312 lines so its not going to be great. It turned out to be roughly like a 2MHz Z80 in terms of throughput which was worse than I expected.<\/p>\n\n\n\n With that Z80 design I had as a goal to run Zork 1 on CP\/M. So basically get CP\/M ported to it and then run CP\/M … but because it was going to be quite slow I abandoned it.<\/p>\n\n\n\n I came up with another idea. Instead of getting the Z80 to self generate video, I had some Atmega1284p chips. They are 5V logic and have 32 GPIO pins. They have counters and timers and usarts and so on. I thought if I could wire that into the Z80 bus I could get it to generate the video address, hsync and vsync. It could just stall the Z80 via _BUSRQ for 40us out of every 64us scanline and hopefully that would be faster overall than the interrupt design I had before. And ultimately get it to run CP\/M and Zork 1. I’ll leave that all for the next post.<\/p>\n\n\n\n I’ve tried lots of other experiments. Many of them to do with financial related stuff. Using AI I can ask quite complicated questions and get decent answers.<\/p>\n\n\n\n So what does this all mean? I genuinely enjoy thinking up hardware and weird software ideas, and AI can sort of ‘do a lot of it anyway’. It sort of takes the fun out of it. You sort of lose that ‘beating your head against a wall for days or weeks and then having an aha moment’. Does that mean I want to avoid using AI? No, not really. But I can empathise with those that are confronted by it. Generally when you come across someone else’s software or hardware project you want to think its as a result of a person’s hard efforts, or a groups hard efforts. So it feels less authentic if its partially done by AI. But the flipside is that I can fast track a lot of ideas.<\/p>\n\n\n\n For the Z80 CP\/M project I’ve effectively used it to ‘flesh out the software quickly’. So for that project I’m more interested in the hardware side, but I am able to relatively quickly build code to drive characters on the screen, read the keyboard and far more complicated things like port CP\/M and bitbang SD card access. It accelerates getting to a ‘more interesting point’ in the project. A huge downside is that I often don’t even look at the code it produces. So did I write the code or did Claude write the code?<\/p>\n\n\n\n Of course this is meant as an experiment so I’m interested in the places where AI hasn’t worked so well. Another project I am advancing is effectively a respin of my msx-rom-emulator project, but instead of using a stm32f407, I use a rp2350b. This project has been very interesting so far as I originally just got it to ‘act as a simple 16KB cartridge emulator’ using https:\/\/github.com\/niklasekstrom\/RPROM<\/a> as a ‘basis. Then I thought “It’d be cool if I could combine the tms9918a branch of my fork of the Apple II VGA <\/a>thing to get a VGA output at the same time the ROM is emulated. That was trivial for claude to port. This got rid of the 74LVC245 level shifters at the same time. Then Claude offered to implement read support for the tms9918. So the way this video emulation normally works is to only capture writes to the tms9918a. And any reads from it come from the real tms9918a on your MSX system circuit board. Because I was using my MSX breadboard computer to test all this, it was trivial to disable the real tms9918a … and so now I have an MSX breadboard system where I could actually remove the tms9918a and almost half the chips if I wanted to. The next part was to add the floppy controller emulation. This was much harder for Claude, and there were quite a few times where I just had to say “Stop, I will have a look at the code myself”. In these cases I would debug by making a series of educated guesses and eventually solve some issue. The style of programming my msx-rom-emulator is super time critical, so you have to be aware at all times about the time cost of what you’re trying to do. In some ways, Claude was very aware of this, but in others it made mistakes and you just see your 5hr limit blowing up in front of your eyes , so you say ‘STOP’. But we got there eventually. I guess this highlights a negative about tools like Claude. When its not doing the right thing I feel like I’m talking to a really egotistical junior programmer and I am wasting ‘my own brain tokens’ trying to convince it to do something (and hence spending real tokens in the process). In a work context, having to deal with an egotistical junior programmer is probably normal, but for me this is a hobby, and its the last thing I want to do.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Like the rest of the world I am tinkering with AI. I spend a lot of time going “Can it do this …”. When I first started playing with AI a few years ago, my general concensus was “Good at modern languages, but rubbish at older retro stuff”. For example, asking any AI to write […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2885","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/posts\/2885","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/comments?post=2885"}],"version-history":[{"count":3,"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/posts\/2885\/revisions"}],"predecessor-version":[{"id":2923,"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/posts\/2885\/revisions\/2923"}],"wp:attachment":[{"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/media?parent=2885"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/categories?post=2885"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kernelcrash.com\/blog\/wp-json\/wp\/v2\/tags?post=2885"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n