#ecobj — Public Fediverse posts

I got up this morning, grabbed the laptop and worked out what I needed to do to create OMF files with CTRAN.

I now know how to generate everything... EXCEPT ONE THING! TopSpeed generates a "Type Index" for every class with one (possibly two) bytes of debug information. I have no idea what it uses to generate this.

The OMF docs imply that it's ignored by most linkers. But that's not the point.

Damn, I thought this was going to be so easy.

#CTRAN #ECOBJ #SIBOSDK

I got up this morning, grabbed the laptop and worked out what I needed to do to create OMF files with CTRAN.

I now know how to generate everything... EXCEPT ONE THING! TopSpeed generates a "Type Index" for every class with one (possibly two) bytes of debug information. I have no idea what it uses to generate this.

The OMF docs imply that it's ignored by most linkers. But that's not the point.

Damn, I thought this was going to be so easy.

#CTRAN #ECOBJ #SIBOSDK

CTRAN to OBJ File Pipeline

I've just thought of this one. Bear with me.

• #CTRAN generates TASM code. Badly, but still.
• It also generates C files that are compiled by TopSpeed C and then processed by #ECOBJ.
• The TopSpeed OBJ Disassembler (tsda) disassembles OMF files compiled by TSC.

First, why aren't I using tsda to make at least some of the TASM code generation in CTRAN more accurate?

But more interestingly, why not add the ECOBJ OMFMaker library to CTRAN and have it just generate OBJ files directly, already in the correct layout? No need for a compiler or a separate app to manipulate the OBJ file. Just ctran -m (-o is already taken) to directly make the object file with class descriptor in the CODE segment.

CTRAN to OBJ File Pipeline

I've just thought of this one. Bear with me.

• #CTRAN generates TASM code. Badly, but still.
• It also generates C files that are compiled by TopSpeed C and then processed by #ECOBJ.
• The TopSpeed OBJ Disassembler (tsda) disassembles OMF files compiled by TSC.

First, why aren't I using tsda to make at least some of the TASM code generation in CTRAN more accurate?

But more interestingly, why not add the ECOBJ OMFMaker library to CTRAN and have it just generate OBJ files directly, already in the correct layout? No need for a compiler or a separate app to manipulate the OBJ file. Just ctran -m (-o is already taken) to directly make the object file with class descriptor in the CODE segment.

Done!

You want a tool that takes an OMF (.OBJ) file and moves the class descriptor data from the DATA segment to the CODE segment? You want it to run on basically everything?

Well, this might do the job.

https://codeberg.org/thelastpsion/ecobj/releases/tag/0.0.1

#ECOBJ #SIBOSDK

Done!

You want a tool that takes an OMF (.OBJ) file and moves the class descriptor data from the DATA segment to the CODE segment? You want it to run on basically everything?

Well, this might do the job.

https://codeberg.org/thelastpsion/ecobj/releases/tag/0.0.1

#ECOBJ #SIBOSDK

My new #ECOBJ works!

It takes an OMF file with class information in the DATA segment, strips out unneeded records, shifts things around, and generates a new file with the class info in the CODE segment!

So far I've tested it with four OMF files compiled with the TopSpeed C compiler, one of which contains about 30 classes and a few hundred methods. It generates files identical to ECOBJ.EXE by Psion.

It is the most cursed code I've ever written, but it does work!

Now I'm going to have a rest. I'll come back to it later and do some serious clean-up.

https://codeberg.org/thelastpsion/ecobj/pulls/1

My new #ECOBJ works!

It takes an OMF file with class information in the DATA segment, strips out unneeded records, shifts things around, and generates a new file with the class info in the CODE segment!

So far I've tested it with four OMF files compiled with the TopSpeed C compiler, one of which contains about 30 classes and a few hundred methods. It generates files identical to ECOBJ.EXE by Psion.

It is the most cursed code I've ever written, but it does work!

Now I'm going to have a rest. I'll come back to it later and do some serious clean-up.

https://codeberg.org/thelastpsion/ecobj/pulls/1

Thinking out loud this morning regarding "now and next" projects.

• Get #ECOBJ to a "good enough" 0.0.1 release.
• Switch to some investigative work of some sort. I miss researching and there's still so much to discover about #Psion kit.

I've also got a lot of write-ups that I want to. Get things noted down before I forget them.

Thinking out loud this morning regarding "now and next" projects.

• Get #ECOBJ to a "good enough" 0.0.1 release.
• Switch to some investigative work of some sort. I miss researching and there's still so much to discover about #Psion kit.

I've also got a lot of write-ups that I want to. Get things noted down before I forget them.

Like #CTRAN, #ECOBJ will eventually be rolled into a compiler that's aware of the SIBO/EPOC16 ecosystem. CTRAN will probably end up as something to convert category files from legacy projects to whatever OO C I end up using. And a compiler will just generate OMF files in the right format without conversion.

But just because these tools are stop-gaps, doesn't mean they're useless. First, all of this is prep-work and learning for me. Second, a lot of the code I'm writing will be re-used in different places further down the line. But also, at the rate I'm going with the project, that "stop-gap" could last years.

#SIBOSDK

Like #CTRAN, #ECOBJ will eventually be rolled into a compiler that's aware of the SIBO/EPOC16 ecosystem. CTRAN will probably end up as something to convert category files from legacy projects to whatever OO C I end up using. And a compiler will just generate OMF files in the right format without conversion.

But just because these tools are stop-gaps, doesn't mean they're useless. First, all of this is prep-work and learning for me. Second, a lot of the code I'm writing will be re-used in different places further down the line. But also, at the rate I'm going with the project, that "stop-gap" could last years.

#SIBOSDK

One of the aims of the new SDK is to create drop-in replacements for the old tools. This was pretty easy with #CTRAN - switches in the original enabled specific outputs. No switches, no output files.

#ECOBJ is a little different. As its simplest, it takes one parameter - the name of the OMF file to process. It then overwrites that file with the re-jigged output. Fine as a quick tool that's never called by a human, not so fine for... everything else. You can specify a separate output file, but I've never seen a Makefile, make.bat or TopSpeed project file that does.

I wonder if I need to create two executables. One would be ecobj/ECOBJ.EXE, which is the drop-in replacement for the original tool. And then another that will dump and analyse... maybe tsda, to replace the tool that comes with the TopSpeed compiler? They'd mostly use the same functions/classes, but the default behaviours would be different.

I need to create the bulk of the latter in order to build the former anyway.

#SIBOSDK

One of the aims of the new SDK is to create drop-in replacements for the old tools. This was pretty easy with #CTRAN - switches in the original enabled specific outputs. No switches, no output files.

#ECOBJ is a little different. As its simplest, it takes one parameter - the name of the OMF file to process. It then overwrites that file with the re-jigged output. Fine as a quick tool that's never called by a human, not so fine for... everything else. You can specify a separate output file, but I've never seen a Makefile, make.bat or TopSpeed project file that does.

I wonder if I need to create two executables. One would be ecobj/ECOBJ.EXE, which is the drop-in replacement for the original tool. And then another that will dump and analyse... maybe tsda, to replace the tool that comes with the TopSpeed compiler? They'd mostly use the same functions/classes, but the default behaviours would be different.

I need to create the bulk of the latter in order to build the former anyway.

#SIBOSDK

Spent the evening re-familiarising myself with various tools that will dump the contents of OMF files. So far I have three:

TSDA.EXE - The TopSpeed Disassembler

16-bit DOS binary, bundled with the TopSpeed compiler suite. It doesn't give every tiny bit of detail about an OMF file, but it's formatted nicely and shows what the compiler cares about.

Happily, it runs perfectly with emu2. One shell script later and it's practically a native Linux tool.

omfdump

https://github.com/boeckmann/omfdump

A lightweight tool written in C. Seems highly portable, although I'm only running it on Linux. Feels like it's missing some information, but still good.

dumpomf.exe

https://github.com/Baron-von-Riedesel/DumpOMF/tree/master

This one outputs the most information. However, it's written in 32-bit assembly and needs jwasm and jwlink. I couldn't work out how to build it as an ELF binary. emu2 can't handle 32-bit DOS binaries, so I have to run it via WINE. Compared with the other tools, the three second wait for WINE to start is frustrating.

#ECOBJ

Spent the evening re-familiarising myself with various tools that will dump the contents of OMF files. So far I have three:

TSDA.EXE - The TopSpeed Disassembler

16-bit DOS binary, bundled with the TopSpeed compiler suite. It doesn't give every tiny bit of detail about an OMF file, but it's formatted nicely and shows what the compiler cares about.

Happily, it runs perfectly with emu2. One shell script later and it's practically a native Linux tool.

omfdump

https://github.com/boeckmann/omfdump

A lightweight tool written in C. Seems highly portable, although I'm only running it on Linux. Feels like it's missing some information, but still good.

dumpomf.exe

https://github.com/Baron-von-Riedesel/DumpOMF/tree/master

This one outputs the most information. However, it's written in 32-bit assembly and needs jwasm and jwlink. I couldn't work out how to build it as an ELF binary. emu2 can't handle 32-bit DOS binaries, so I have to run it via WINE. Compared with the other tools, the three second wait for WINE to start is frustrating.

#ECOBJ

Welp, it looks like I last looked at #ECOBJ on 2026-01-01.

This, of course, leads to a lot of me thinking, "Oh, I wrote that code, did I? Interesting..."

I'm going to need a refresher on the IBM OMF format.

#SIBOSDK

Welp, it looks like I last looked at #ECOBJ on 2026-01-01.

This, of course, leads to a lot of me thinking, "Oh, I wrote that code, did I? Interesting..."

I'm going to need a refresher on the IBM OMF format.

#SIBOSDK

The SDK of Theseus.

Or, for UK viewers, Trigger's Toolchain.

#SIBOSDK #CTRAN #ECOBJ

The SDK of Theseus.

Or, for UK viewers, Trigger's Toolchain.

#SIBOSDK #CTRAN #ECOBJ

I think I'm going to try to improve path management in #CTRAN, make a release and then take a break from it. After that, most of the other TODOs are pretty small anyway.

I'm tempted to go back to my rewrite of ECOBJ.EXE, another tool in the #Psion SIBO C SDK. This one modifies 8086 Object Model Format (.OBJ) files for classes on EPOC16. I don't think it'll take me more than a few weeks to have something that works, even if it's not perfect.

#SIBOSDK #ECOBJ

I think I'm going to try to improve path management in #CTRAN, make a release and then take a break from it. After that, most of the other TODOs are pretty small anyway.

I'm tempted to go back to my rewrite of ECOBJ.EXE, another tool in the #Psion SIBO C SDK. This one modifies 8086 Object Model Format (.OBJ) files for classes on EPOC16. I don't think it'll take me more than a few weeks to have something that works, even if it's not perfect.

#SIBOSDK #ECOBJ

#ECOBJ update. FIXUPP records in OMF files can now be read! It's the bare minimum implementation for translating files, but it's good enough for me to see what's going on. I should now have enough information to work out how to replicate what Psion's ECOBJ.EXE does.

The latest update is here. The code is atrocious, but I'm nowhere near the final app yet. "Make it work, etc etc etc." https://codeberg.org/thelastpsion/ecobj/commit/f28f19ee647dbb4699d27aefcd9d48c938da0b11

I also found a few open source tools that can analyse OMF files. My challenge was to not look at the source code and only use their output as a guide. (I succeeded.) They are:

• OMF-Parser, written in Python. https://github.com/HK47196/OMF-Parser
• DumpOMF, a Win32 app, but runs with WINE. https://github.com/Baron-von-Riedesel/DumpOMF

My next challenge is to work out how to store each record sensibly in memory. I can use #Pascal's TList type, dynamic arrays, and records (structs) to build out the structure. From there, I should be able to work out what moves where, and then generate new files.

This will require a lot of refactoring work. I also want to put most of the code in a class or two for portability - some of the code could easily be reused in other related projects, such as an assembler or a disassembler. Any future compiler will need to be able to build object files with the class information in the code segment. All of this work helps.

I think I said it was going to take me two weeks of work to complete. I think three is more realistic now. But I do need to get one with some $dayjob work this week, so Week 2 might end up being drawn out over January.

#ECOBJ update. FIXUPP records in OMF files can now be read! It's the bare minimum implementation for translating files, but it's good enough for me to see what's going on. I should now have enough information to work out how to replicate what Psion's ECOBJ.EXE does.

The latest update is here. The code is atrocious, but I'm nowhere near the final app yet. "Make it work, etc etc etc." https://codeberg.org/thelastpsion/ecobj/commit/f28f19ee647dbb4699d27aefcd9d48c938da0b11

I also found a few open source tools that can analyse OMF files. My challenge was to not look at the source code and only use their output as a guide. (I succeeded.) They are:

• OMF-Parser, written in Python. https://github.com/HK47196/OMF-Parser
• DumpOMF, a Win32 app, but runs with WINE. https://github.com/Baron-von-Riedesel/DumpOMF

My next challenge is to work out how to store each record sensibly in memory. I can use #Pascal's TList type, dynamic arrays, and records (structs) to build out the structure. From there, I should be able to work out what moves where, and then generate new files.

This will require a lot of refactoring work. I also want to put most of the code in a class or two for portability - some of the code could easily be reused in other related projects, such as an assembler or a disassembler. Any future compiler will need to be able to build object files with the class information in the code segment. All of this work helps.

I think I said it was going to take me two weeks of work to complete. I think three is more realistic now. But I do need to get one with some $dayjob work this week, so Week 2 might end up being drawn out over January.

If anyone wants to see some incredibly poor #ObjectPascal, here's a link to #ecobj in its current form.

It's very much at the "work out how any of this works" stage. Expect the code to change radically!

https://codeberg.org/thelastpsion/ecobj

If anyone wants to see some incredibly poor #ObjectPascal, here's a link to #ecobj in its current form.

It's very much at the "work out how any of this works" stage. Expect the code to change radically!

https://codeberg.org/thelastpsion/ecobj

For the first time in ages, I've had a good afternoon writing code!

I've been working on #ecobj. I can now analyse six OMF record types (well, five and a bit) using some rough-and-ready Pascal. And I've started to get a picture of how the original ECOBJ.EXE moves the records around.

As far as I know, there are 10 record types that ECOBJ.EXE handles. So I'm over halfway there. Sort of.

Using the #TopSpeed Object Disassembler (TSDA) has really helped to make sure I'm heading in the right direction. #DOSBox makes this easy by letting me send the output from TSDA.EXE to a file, so I can view it on Linux.

For the first time in ages, I've had a good afternoon writing code!

I've been working on #ecobj. I can now analyse six OMF record types (well, five and a bit) using some rough-and-ready Pascal. And I've started to get a picture of how the original ECOBJ.EXE moves the records around.

As far as I know, there are 10 record types that ECOBJ.EXE handles. So I'm over halfway there. Sort of.

Using the #TopSpeed Object Disassembler (TSDA) has really helped to make sure I'm heading in the right direction. #DOSBox makes this easy by letting me send the output from TSDA.EXE to a file, so I can view it on Linux.

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.

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.

Sadly I have no time for a full #DecemberAdventure this year. However, I do think that a #TwixtmasAdventure of intense Pascal to get #ECOBJ working could be on the cards.

I would also like to know how many people I've made cringe by using the word "Twixtmas".

Sadly I have no time for a full #DecemberAdventure this year. However, I do think that a #TwixtmasAdventure of intense Pascal to get #ECOBJ working could be on the cards.

I would also like to know how many people I've made cringe by using the word "Twixtmas".

I've done a little more work on #ECOBJ over the past couple of weeks, but not much. Life has, unfortunately, got in the way of most of my retrocomputing fun.

But I'm pretty convinced that I could get something working by the end of the year. I should have some time over December.

It would be nice to get another SDK tool written.

#Psion #SIBOSDK

I've done a little more work on #ECOBJ over the past couple of weeks, but not much. Life has, unfortunately, got in the way of most of my retrocomputing fun.

But I'm pretty convinced that I could get something working by the end of the year. I should have some time over December.

It would be nice to get another SDK tool written.

#Psion #SIBOSDK