GRG's Miscellany

 A good while back, I ordered an ISA network card for my socket-5 Pentium machine.  Finally today I managed to get it working with EtherDFS .  Finding the right steps involved a lot of web searching. First, I had to figure out exactly what model the card was.  Thankfully, it says it right on the chip: RTL8019AS .  I have spewed much bile about Realtek and their crappy audio drivers before now, but I was seriously impressed that they still had a page where I could download the packet driver for this ancient NIC. As far as I can tell, there are two types of NIC drivers for DOS-era machines: an NDIS type for Windows things, and a 'packet' driver with an open interface.  EtherDFS needs the packet drivers, and I don't care for Windows guff, so I'm happy with just that. I found a page at legroom.net which had the info I needed to install the packet driver.  That page has a whole wealth of stuff, but the bit I needed told me to save the packet driver (pnppd.com for me) in the

My C64 is still banjaxed, but now in a way that makes me feel it's closer to being fixed. I had thought it was just a dead PSU, so I ordered a new one.  When it arrived, I plugged it in and.....the same problems happened.  So that's the first potential fault ruled out. So I ordered a C64 dead test cartridge .  When this arrived, I plugged it in and powered on...and it gave me all sorts of crap on the display.  Still recognisable characters and border, but utter random garbage.  There was some screen flashing, which is the way the cart indicates dead-ram chips, but it couldn't decide which one - every time I switched the machine on it gave a different number of flashes. The internet had already suggested that garbage text meant a duff multiplexer, and with the cart encountering seemingly random errors across multiple chips, I decided to order a couple of spare multiplexers (there are two in the C64). So today I cautiously desoldered the U13 multiplexer and soldered in a rep

So moving house has been an absolute pain in the plums.  Monthly projects are on hiatus and until the start-of-term chaos has died down, I'm working on the odd piece of project here and there. The first such project is doing some C64 development, which I've wanted to do for literally years.  I bought an SD-card reader from the future was 8-bit and when it arrived, I dug out  my C64 from storage and powered it on... ...and it was dead. Not fully dead, just...weird.  Blue border and blue background are fine but the screen is filled up with garbage text. So step 1: order a new power supply.  The PSU I was using wasn't a Commodore original, but a replacement from the late 80s.  The problem could still be a b0rked or loose chip, but I got paranoid about using a vintage PSU anyways so I ordered one from Poland.  If that doesn't fix it, I plan to follow some of the procedures here . In the mean-time, I decided to search for an IDE that would run on linux and work with an emul

I want to explore the full potential of the BBC Micro:bits my school has. Making rock-paper-scissors games and the like is all well and good, and the students love it (for the most part), but it always feels a little bit gimmicky.  But when students really get engaged and suggest ideas for them (e.g. games, compass display), it all gets a little bit cramped and feels like it could  kinda  work, but not really . Then I found out that all the tiny strips on the edge are actually GPIO pins, not just the fat 0, 1 and 2 ones.  Since then, I've wanted to explore what I can do with it. Hence, over the last few days I have been trying to get the microbit to control a TFT display. I first went for this 2.4" display with a touchscreen.  The SPI interface is just for the microSD, not for the screen but I didn't think that would be a problem because the micro:bit has so many pins.  After much frustration, I discovered that there are many of the pins you can't reliably use extern

This post follows on from a previous post about my recent attempts to implement the Wave-Function Collapse algorithm in Godot's GDScript to generate tile map levels. I'm only just posting it now because I didn't realise I'd left it as a 'draft'.  Woe is me. As I mentioned in the previous post, this isn't meant as a set of instructions - more as a reminder for my future self so I don't fall into the same traps again.  That said, hopefully someone else finds it useful as well. Dealing with contradictions When you are trying to generate a grid of tiles using Wave Function Collapse, each cell in the grid can be the top-left corner of one (and only one) super-tile.  As soon as you choose a super-tile for one grid cell, it limits which super-tiles the nearby cells can be.  This is implemented as adjacency rules: essentially there is a set of tiles which is allowed to be to the right of (or left of, or above or below) the chosen super-tile. A contradiction oc

Recently, I have been spending a lot of time trying to implement the Wave Function Collapse algorithm to generate tilemaps.  I think Robert Heaton does a great job of explaining what the algorithm is, but I still needed to figure out a lot when implementing it with tilemaps. This post is the first in a set to document for my future self some of what I learned, so I don't fall into the same traps when I inevitably return to it further down the road. Tiles in bitmap version → super-tiles in tilemap version   An individual tilemap tile is equivalent to a pixel, so super-tiles are collections these tilemap tiles The significance of the size of the super-tiles wasn't clear to me until I tried out different sizes.  The super-tiles I used were square, but in the discussion here I only consider a single dimension to try and make things clearer.  (I also ignore the fact that when the super-tiles are produced, they are usually allowed to wrap from one edge of the template to the other.

  Last Month's Projects Following my emerging pattern, it is well into April but here's my attempt at a round-up.   Physical make: Tiny OpenWRT -based server.  Nothing material has happened on this one.  I have done some research into the different packages available for OpenWRT (there are loads ).  I'll probably want to switch from mercurial to git if I want to have an internet-visible source-control server without compiling my own package.  The tiny machine might even have enough grunt for a Nextcloud instance, so long as it's a really small number of users. Coding make: I never even started coding for the Dungeon Crawler Jam .  I decided to try and implement Wave Function Collapse in the latest Gotm.io jam so I could get to grips with it.  Turns out WFC is far from trivial if you want a guaranteed solution in a reasonable time.  I spent so much time working on it that I failed to enter for either jam. However, I do have a working solution in Godot's GDScr

So it's already halfway through March.  A perfect time to review my February projects! Last Month's Projects Physical make: Completed the steering wheel!  I managed to destroy it by accidentally levering the USB connector off the Arduino, but thankfully I had a spare and repaired it (and glue-gunned the damn cable on) and it's going strong! Coding make: I dun it !  ...but I didn't come back to the raytraced helicopter game.  I got sidetracked into looking into making a DOS runtime for the pico-8 subset of lua, and then sidetracked again into making Strike-16 for the gotm game jam. Reading:  The Templars: History and Myth by Michael Haag . So it turns out the Crusades were much more complicated than Christians vs Muslims.  There was plenty of politicking to go around in the Holy Land, and politicking in France eventually did for the Knights Templar.  It was also interesting to learn about the Inner Temple in London, and how St.John's Ambulance cam out of the Knig

Relatively recently, I was told about gotm.io , a site dedicated to playing Godot engine games in-browser.   I had made a game for a previous jam which I couldn't get to work in-browser on itch, and lo and behold, it worked just fine on gotm.io ! So when I heard the gotm team were running a jam I was really keen to try it out again. The Game Submission It's a tribute to StarWing/StarFox trying to fulfill the theme by having some gameplay based around the boost/brake.  You can play it here (perhaps ironically, I haven't got round to putting it up on gotm.io yet) At the time of writing, voting is still ongoing, so I don't want to criticise it too much.  ;p However, having played some other submissions, my link to the theme is pretty weak.  Never mind - I enjoyed making it. The Making Process I learned a lot making this and if I was to make it again, I would approach it differently, but here's how I went about it. I started by trying to get the look and feel of St

Here it is, immortalised with my atrocious photography skills! It's made mostly out of some old tongue-and-groove flooring samples, with some 4mm and 6mm ply in places.  What with the heavy-duty bearings and being screwed together, it's actually a really robust little thing! I decided to have a composite axle so I could fit the button wires down the centre. So I cut two long, thin beams of ply so they could fit through the very centre of the bearings.  Then I cut small sections out of the edges so that when pushed away from each other, they would lock into the bearings (i.e. not slide through them).  The other blocks you can see are holding the two long pieces apart so they can't fall out. I swapped out the middle block with a spring mechanism.  I cut two bits of ply that I could slide onto the beams from opposite sides.  Then I inserted a section of bamboo skewer between those bits to hook the springs onto.  As you can see, I used screws to secure the other ends of the spr

  Last Month's Projects Physical make: This is not finished, but is going okay.  I decided to make some gears so 90 degree of wheel turn is about 150 degree of potentiometer turn.   I encountered a problem trying to 3D print the gears: the weather and workshop was so cold the filament snapped as soon as the printer head moved! So I had to wait for some slightly warmer weather for the printer.  A silicone mould is currently setting around them so I can cast them in more durable resin. Coding make: DOS Raytraced Helicopter Game.  This has not happened.  I've started writing a proper X-mode VGA manager class, and thought carefully about how to do the pixel-plane rendering, but that's about it.  I'm going to switch to update my F-Z game and post it on gotm.io but I'll be back on the raytracing project once that's done. Reading: Black Holes, Wormholes and Time Machines by Jim Al-Khalili . This is a reasonably dated book (pre-Higgs Boson and Gravitational Waves dis

 January Projects Yeah, I know January started a while back now, but my brain is still catching up. Physical make: New USB steering wheel.  My previous one was made with a Teensyduino , which doesn't seem to behave in exactly the same way as vanilla Arduino Micro clones.  The wheel itself has lasted impressively well considering it's made out of cardboard with some really shoddy soldering.  Even more so considering it went through some of its life with pedals attached.  Unfortunately, it has now stopped behaving properly and re-figuring out how the Teensyduino thing works makes me feel tired.  So I'm building a new wooden-framed one, with real bearings and everything! Coding make: As you might have seen, I have started to try my hand at raycasting in C++.  I am going to try and get a playable DOS helicopter game made for the Kajam event .  I'd like it to include shooty missions and transport missions.  Maybe in the fullness of time it'll even have a campaign mode