The Last Psion | Alex

Things I'd like to achieve next year

...with zero pressure - just stuff I'd like to do if I get the chance

  • Get as many of the #Psion SIBO C SDK apps rewritten as possible. I really enjoy using #FreePascal for this! It's vastly underrated for writing cross-platform CLI apps.
  • Make some code run on #EPOC16 from a tiny/toy #compiler of my own. Not an entire C compiler, just something where I've generated some 8086 (or NEC V30) assembly from something very basic that actually runs, including implementing the TopSpeed calling convention.
  • Work out how the #MAME debugger works so that I can add 4MB RAM support to EPOC16. Maybe learn some things about the internals of EPOC16 along the way. Eventually write this updated EPOC16 ROM to flash and get it running on real hardware.
  • Make a #PsiDrive PCB that can write to flash drives. Just needs a +16V boost converter added to the board.
  • Get an #RP2350 to pretend to be a small Psion SSD, using the on-die RAM and PIO. Bonus if it uses a battery. Extra bonus if it can write to external RAM or Flash.
  • Move #libsibo away from the Arduino libraries and over to the Pico SDK. This just feels like the right move, but means I'll need to learn cmake as well.
  • Learn how to write good unit tests. It's not a problem with learning frameworks - both fptest and fpcunit are simple enough. My brain is freezing when trying to decide on what to test and why. I know my code will improve once I've grasped this.

There are a lot of moving parts to all of these. Some need me to learn multiple sub-skills, such as 8086 assembly. Like I said, this isn't a list of Things Alex Must Get Done Next Year. I'd be happy if I achieved just one of them.

I'm curious... Which one of these would you like to see the most?

#retrocomputing

x86 calling conventions - Wikipedia

Dec 21 at 8:47amWeb
Show threadThe Last Psion | AlexDec 21

Sometimes I post here just to get thoughts out of my brain. An attempt to codify the mess, clarify what I actually want.

That last post helped. Deciding which one to tackle wasn't the point. I just wanted to write the thoughts down, shape them into something coherent, push them to the ether, and let them percolate.

If you find them interesting, then that's cool too.

Show threadjonvDec 21
@thelastpsion will you be Retro Festing in Swindon next year?
Show threadThe Last Psion | AlexDec 21
@jonv I think it's 50/50 at the moment. It's at the end of the May half term, and I'm usually busy at that time of year.
Show threadPulkoMandyDec 21
@thelastpsion for unit tests, a good way to start is whenever you find a bug. Instead of going straight into fixing it, first write a test that replicates the problem. Then you make sure that if a later development reintroduces the same bug, you will catch it.
Show threadThe Last Psion | AlexDec 21

@pulkomandy I like this! Saves having to think too hard.

I've been reading up on TDD recently and I just can't get into that mindset. I don't really know how I can write a test when I'm still trying to work out where I'm going with a project.

Show threadMatt GumbleyDec 21

@thelastpsion Not going to recommend any over any other - they’re all great!

But on unit testing and TDD - what to test and why - my approach (when I’m not being lazy) is test everything that’s practical to test-into-existence. I introduce “test seams” aka interfaces at the hard-to-test point (eg a GPIO pin), and build an implementation of that pin interface that I can sense and drive in a test. I then inject that test pin into my main code, and write a test…

Show threadMatt GumbleyDec 21

@thelastpsion … that allows me to build out the first part of my logic, sensing the output of the pin.

So it’s a design approach - tests are the happy side effect you get as you start to build out your code, in small (micro) steps, sensing and asserting as you go.

Getting the mindset right seems to be hard if you’ve not tried it before. It took me a long time to stop galloping ahead with reams of code that I was confident would work (and then got fixed with manual testing/debugging). …

Show threadMatt GumbleyDec 21

@thelastpsion What’s the smallest thing you can bring into existence and sense with a test? Do that, then iterate. The frameworks are the easy bit :)

I have compiler and GPIO examples I could point to to illustrate if a concrete example would help.

Show threadCyningstanDec 22
The MAME debugger stuff. Especially if it leads to being able to diagnose the now infamous OPL "Overflow" error...