Just tried compiling Wari, a game written in #Psion OO C. The project uses #Borland Make 3.6.
Got it to compile first time with my SIBO SDK setup - all good!
However... Borland Make uses 16-bit DPMI, and its extender won't load 32-bit DPMI binaries. If I pre-load the 32-bit extender, it won't load 16-bit DPMI binaries, so Make won't run!
TL;DR: I can't use the new #ctran with Borland Make 3.6.
Looks like I'll be converting that Makefile to GNU Make or a #TopSpeed project.
If I want to have any hope of learning to write #EPOC16 device drivers in the future, I'm going to need to learn x86 (specifically 8086 and NEC V30) assembly.
That is DEFINITELY not a Today Problem. It's not even a This Year Problem.
Looking through some #Psion C code, I've seen CDECL a few times. Being a noob, I didn't know what they were or why they were there.
So, looking at Wikipedia...
#CDECL is a "caller clean-up" calling convention using the stack. This is pretty common in the x86 world, but is explicitly mentioned in Psion code. Why?
#TopSpeed C uses its own "callee clean-up" calling convention, using registers for the first 4 int parameters, which #EPOC16 really likes.
I say #EPOC16 "likes" calls using registers, but that's an assumption and I could be getting confused.
AFAIK, EPOC16 uses the "pure" small memory model (preserving the CX register) so that 64K code blocks can be moved around memory without interfering with the program running "within."
I assume this ties in, but if anyone knows otherwise then please feel free to correct me!
EPOC16 restricts apps to the x86 small memory model, so that it can move 64K blocks of RAM around easily. (It's also VERY picky about register usage, for the same reasons.) This basically means that apps can't be bigger than 64K.
The way I understand it, you can get around this by using dynamic libraries, or .DYL files, splitting out you app's functions and dynamically loading an unloading them when needed.
I'm not listed (yet), but I'm going to be showing off the not-disassembled items in my #Psion collection on Saturday 4th and Sunday 5th November at the Retro Computer Festival.
I'll also have that #HaikuOS netbook running #MAME for you to try out a few classic #EPOC16 apps and games without risk of breaking the hardware. (Yes, there was a real point to that project!)
If you can get to Cambridge that weekend, come say hi!
For example, on Linux I have ~/dosbox, in which I have sibo-c and sibo-m folders, mounted as C: and M: in DOSBox. I also have a P: drive mapped to ~/psion containing projects.
For Windows, would you put them in c:\users\username\dosbox?
I want to make a video for using the Psion SIBO C SDK. I want to stick to conventions where possible.
12 years ago, someone wanted to build a "new" Series 3a with an FPGA.
They were talking to #Psion about getting hold of the source code for #EPOC16. Psion seemed willing to help, but concerned about "other intellectual property rights."
Good to see willingness, but my heart sank a little.
But... Looks like they were happy for the SDK to be freely available, so I'll look into that.
Anyway, it's been on my list to attempt porting it to #Psion#EPOC16 for ages. It's not top priority, but the machine is perfectly designed for playing #textadventure games (see @root42's escapades with #Infocom).
Be great if it could decompile and play old games, too.
Spent a lot of time this morning looking for old #EPOC32 software.
Most of my #Psion time is spent in the #EPOC16 world, so it's been good to look around at what was done on the newer machines.
Highlights so far include #SimCity, Frotz (#Infocom emulator), Jumpy, #NetHack, a WAP browser, Imperium (Command & Conquer clone), Z80 (#ZXSpectrum emulator) and #Doom!
I need to dig my 5mx out, but I'll be giving these a go.
Trying to give #EDisAsm a proper help menu, which requires compiling a resource (.RSC) file.
After much faffing, I've got compiled a basic .RSC file, and added its .RSG (header) file to the project. All compiled OK. Copied the app and .RSC to the DOS #EPOC16 emulator and...
DOES ANYONE REMEMBER HOW TO DO THIS?
I'm currently trawling through old code and the SDK docs.
Did you write code for #Psion machines in the #80s and #90s?
We're calling for you to open source your code!
I'm working with a group of enthusiasts, building a library of information about the SIBO/EPOC16 platform. Your old code could give valuable insight, as well as encourage people to write new code.
We're especially interested in old C and #x86#assembly.
Upload it to your public repository of choice, and set it free!