I'm actually compiling these Psion apps without DOSBox.

I'm using #emu2 as a wrapper for the TopSpeed Compiler. Its project system calls the various tools in the #Psion SIBO C SDK.

If anyone already has the SDK and wants to try compiling EPOC16 apps from the Linux terminal (or your OS of choice - *BSD, macOS and Haiku should all work), this is the script I'm using. Modify it to suit your needs:

#! /bin/sh
EMU2_DEFAULT_DRIVE=P EMU2_DRIVE_C=~/dosbox/sibo-c/ EMU2_DRIVE_P=~/psion/ exec emu2 ~/dosbox/sibo-c/TS/SYS/TSC.EXE $@ -- 'PATH=C:\BIN;C:\SIBOSDK\INCLUDE\;C:\SIBOSDK\SYS;C:\SIBOSDK\LIB;C:\TS\SYS'

My Psion projects are mapped to P: in DOSBox, so I've mirrored that here.

Annoyingly, this won't work with my new SDK tools, such as the new #CTRAN. emu2 can only handle 16-bit DOS apps, and CTRAN-ng will only compile for 32-bit DOS. If you have an app that needs CTRAN, you'd either need to run it directly from Linux , or use the original ctran.exe from the old SDK. It would be great if I could make emu2 check a list before calling a new executable and select whether to run the DOS or native version of an app.

emu2 isn't perfect, but it does save me from starting DOSBox.

I think I'm using the term "metaclass" incorrectly in #CTRAN.

Is there a term for squashing all of a class's ancestors together as if they were just one parent class or superclass?

#OO #OOP

Current main projects:

  • #ecobj: Another piece of the #Psion SIBO SDK rewrite puzzle. ECOBJ.EXE takes an Intel OMF file (.OBJ) for a class and moves the class descriptor data into the code segment. I think I might be able to get this working by the end of the year.
  • Get my website running #GoHugo (this is almost done!).
  • #CTRAN: Still haven't started writing unit tests. Also, complete a full write-up of what it took to get the thing working.
  • Research into compilers: I'm nowhere near ready to start yet, but I'm learning as much as I can.

Upcoming projects:

  • #siboimg: Rewrite in Pascal, and add the ability to create and modify FEFS images.
  • #plptools: I'd like to see two-way transfer working for EPOC16 -- I'm sure I'll need the help of the rest of the maintainers to get this working. I can't do much with the #HaikuOS port until the USB serial drivers are "fixed" (hardware flow control added) -- I don't think I have the skills for this, so it'll have to wait until some kind soul has the time to work on it.
  • #PsiDrive: Add a ~17V boost converter to allow writing to Flash SSDs.
  • NAS/home server: Rebuild or replacement of DEATH, my Microserver gen8. It's been over 18 months since DEATH's RAID died. It's lead me to thinking that maybe I don't need the sort of server I thought I need. TBD.

Maybe next year, maybe not:

  • New Psion SSD with RP2350: I doubt I'll get anything made, but I'd like to experiment to see what can be done with the protocol.
  • Rewrite the rest of the SIBO C SDK tools.
  • Compiler: Recreation of the JPI/Clarion TopSpeed C compiler, targeting the SIBO/EPOC16 platform (8086 and V30). I was hoping to get going with this around July this year, but it just didn't happen. This is my Everest. I know I'm not ready yet. I need to train for it.
  • Vine: New word processor for EPOC16. Trying to start this project in 2023 lead me to rewriting the SDK, so we're quite some way away from getting this done.
  • Research into Objective-C: Not Foundation, just the syntax. For compiler shenanigans.

I've really struggled to get going with projects this year. That's fine, these things happen. But I'd like to find better ways to cope next year so that I can make a little more progress.

Yesterday, in an attempt to avoid all sorts of responsibilities, I started pulling apart another #Psion SIBO C SDK tool.

ECOBJ.EXE takes an Intel OMF file (.OBJ) for a class and moves the class descriptor data into the code segment. Unlike #CTRAN, I have absolutely no docs on how it does this. I also have no experience with the object file format.

This has never stopped me before.

So, armed with a hex editor, a PDF documenting OMF (link below), and my beloved #Pascal, I've set to work.

So far, so good!

https://www.azillionmonkeys.com/qed/Omfg.pdf

#Pascal #FreePascal #16bit #DOSBox #DOSBoxStaging #RetroComputing #RetroDev

Some of this weekend will be spent re-reading the #Psion SIBO C SDK's Object Oriented Programming Guide.

Not because I want to refresh my technical knowledge, but because I threw #CTRAN together with a mish-mash of identifier names. And Present Me is slightly cursing Past Me. So yeah, I want to get Psion's nomenclature right so I can clean up my code.

My trusty Fire 7 2015 running LineageOS is in service. It's not fast (low RAM and dog-slow SD card access) and Android 7 is becoming increasingly untenable (it spends 99% of the time with WiFi off), but it's reliable as hell.

Thank you to the developers of #Librera ereader software for continuing to support ancient Android versions! And yes, that screen really is green - I've got some visual processing issues and Librera lets me change colours.

I've been trying to work out Future Psion Shenanigans™, specifically the new SIBO C SDK that's been in my head for years.

For those following along, #CTRAN was obviously the start of my efforts to create a new open source SDK for #Psion SIBO/EPOC16. But let's be fair - while CTRAN does everything I wanted it to do, it's not a finished product. Testing is still minimal, and getting it fully testable will need a large amount of rewriting.

Further to this, I'd like to start building out the rest of the new SDK, or at the very least setting up the project properly, even if I don't work on it this side of Christmas.

I'm also trying to decide which tools should be included. I've already written FEFSTOOL (in C, not Pascal), but does that belong in the SDK as the replacement for FLASHD.EXE, or in a separate package for disk image management tools? Is it likely that someone who wants to play with Psion Flash disk images would also want to make apps?

I've been wrestling with a few concepts: monorepo vs separate repos for each tool and the shared libraries; versioning; even the name and version number. SIBO C SDK v3, following on from 2.20? Something new? A completely different name?

I've had some advice from people I trust, and now I'm mulling it over.

I've finally moved #CTRAN to #Codeberg.

https://codeberg.org/thelastpsion/ctran

Although I'm not working on the project right now, it's constantly on my mind. I will be widening the scope of the repo from just CTRAN-ng to a new #Psion SIBO C SDK with new tools.

ctran

Recreation of CTRAN.EXE, the Psion OO C preprocessor from the SIBO C SDK.

Codeberg.org

Current main projects:

  • #plptools: Resurrecting old ports (#FreeBSD, #NetBSD) and working on a new port to #HaikuOS. It's an opportunity to get more familiar with the code and maybe find bugs along the way.

Upcoming projects:

  • #CTRAN: Still haven't started writing unit tests. Also, complete a full write-up of what it took to get the thing working.
  • Get my website running #GoHugo.
  • Rebuild of DEATH, my Microserver gen8, probably with #FreeBSD. (Yes, it's been over a year since DEATH's RAID died.)
  • Pick another SIBO SDK tool to rewrite. (Probably EMAKE or RCOMP.)
  • Add a 17V boost converter to #PsiDrive.
  • Make #fefstool create FEFS images. (I'm half-tempted to rewrite fefstool in Pascal to make it easier for me to finish.)

You'll notice that some of these projects have been sitting for a while. I've struggled to get going with things this year. I'm hoping that working though plptools will give me some mental energy to get going with other things.

OK, let's go back to those three projects I mentioned last night.

First, Psion SIBO SDK work. I've got a long list of TODOs for #CTRAN, plus a lot of unit tests to build.

On other SDK tools, I have started some preliminary work on the three "linker" tools - EDUMP, EMAKE and EREMAKE. I say "linker" because EMAKE is not a full linker. When compiling EPOC16 apps, TopSpeed C compiles apps as EXEs with an MZ header. To make an EPOC16 executable, EMAKE strips this header, replaces it with a ImageFileType header, and then adds any resource files the app needs.

EDIT: To give the full info on the three tools, EDUMP just lists info about an app (pointers to resources in the app's file, etc), and EREMAKE repackages an app made with EMAKE so that you can replace (or add extra) resource files.

The eventual plan would be to turn this into a full linker, but that's way in the future.

I'm switching gears on my #CTRAN write-up. I will come back to the blog posts, but right now I think it's more important to make sure the code is fully commented.

I hope this helps others understand the process. But I also think it'll help me to see what changes I can make to make CTRAN better.