Frustration, poke is thy name

“If you don’t know where you’re going, any road’ll take you there.”

— George Harrison

The poke must die

I have a problem. I set myself up for this problem. I knew exactly what was going to happen. This moment has come as no surprise whatsoever. What has surprised me is just how much of a problem it is.

As you may recall the Enbugger only has 3 commands PEEK, POKE and CALL. So the only way to get data into memory has been to POKE each byte into memory individually. This is incredibly slow, it’s incredibly easy to type in the wrong address or value and if you happen to type something wrong and it breaks the system then it’s soul destroying to have to redo the program from scratch.

Therefore I wanted to do away with POKE and I decided to write a little memory editor.

I won’t put the code in the post because it’s too long and quite frankly it’s some of the most atrocious assembly code that has ever seen the light of day, but I’ll give a link to a file. Those 371 bytes of code nearly broke me. In fact I think you can actually see the point where I start to lose my mind.

The major problem was just how difficult it is to refactor this code. Let’s say that, like a foolish dwarf, you forget to store the offset for the start of memory that you’re editing. Let’s say you only remember you’ll need this value when you’re over 300 bytes into the program. Well it’s your lucky day dwarf, now you have to find a place for an instruction to store that value, rework all the locations in memory below your new instruction and lastly go through and update all the call/jmp pointers. Now do that multiple times, and throw in occasionally mistyping a POKE so that you kill the Enbugger and have to type it in from scratch.

A lesser dwarf would have quit. In fact when retyping 300+ POKE statements for the 2nd time I came vanishingly close to quitting myself. But I didn’t, because I’m a dwarf and aside from POKE frustration I’m having fun. This took me 2 full days and much ranting to achieve.

Without further ado here’s what the editor looks like:

It’s a fairly typical layout. You have your memory location on the left, bytes in the middle, ASCII equivalents on the right and an indicator showing which nibble you’ll change if you hit 0-9/1-F. The 384 bytes can be navigated with the cursor keys and escape takes you back to the Enbugger where you can persist changes by calling the save component.

For those of you who wish to see the ravings of a mad programmer here’s the code: editor.S.

Things to do

There is no scrolling; you’re stuck in whatever section of memory you loaded. In fact it doesn’t even move to the next line if you move the active nibble all the way to the left or right. You should also be able to change the segment:offset of the starting point. Another handy thing would be to allow saving without having to leave the editor.

Of course there is an endless list of fun things people have come up with for editors to do.

I also need to come up with a different name for components. The word doesn’t fully fit my meaning and it’s used all over computing for different purposes.

Things I’ve learnt

Space is important. You won’t believe how important. It’s so important I’m planning on padding everything with lots of NOP instructions. Because there’s no assemble/compile step, so if you want to add some extra instructions or rearrange what’s there then you need some space to work in. Because otherwise you’ll have to shift the entire program around to squeeze in your changes. I like to think the pioneers came across the same challenge and probably the same frustration.

Planning is useful. I can’t plan everything, because I don’t know what problems I’ll come across before I actually come across them. But I can at least plan some structure to programs instead of charging in blindly. I thought the editor would be straightforward, but thanks to the environment it wasn’t and it very nearly got away from me. That’s one reason the code is so hideous.

There’s a reason we don’t program by inserting each byte into memory by hand. I know that now, I never want to do it again.

Onwards

Despite the code being bad and despite my frustration I’m glad I did this. It’s a shining example to me that sometimes it’s better to just push through and get something done, even if you’re not happy with it, even if it only just works. There have been many times in my life when I’ve been paralysed by endlessly redoing things to try and make them perfect. It’s a nasty loop that prevents you from moving forwards onto the next thing and a very easy way to never really accomplish anything.

Obviously the next step is going to be to keep improving the editor so that it becomes more useful. Once it was working I went back and made some changes to the save, load and boot components. It took me 5 minutes because I could see what I was changing.

One tired dwarf ending their shift in the byte mine.

— Curufir