#epoc16 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #epoc16, aggregated by home.social.
-
Some #Psion news! #plptools, the open source suite of programs for transferring files to and from #EPOC16 and #EPOC32 devices, has some additional maintainers: @captfab, @jbmorley ... and me!
We're looking into how we can take the project into the future. We do have some ideas, but we're taking a considered approach to future development.
plptools currently runs on Linux and macOS (and possibly FreeBSD, NetBSD, Solaris, AIX and HP-UX, although these haven't been tested in a while). I've started work on porting it to #HaikuOS.
The repo has been moved to a new GitHub organisation, which you can find here. https://github.com/plptools/plptools
-
Some #Psion news! #plptools, the open source suite of programs for transferring files to and from #EPOC16 and #EPOC32 devices, has some additional maintainers: @captfab, @jbmorley ... and me!
We're looking into how we can take the project into the future. We do have some ideas, but we're taking a considered approach to future development.
plptools currently runs on Linux and macOS (and possibly FreeBSD, NetBSD, Solaris, AIX and HP-UX, although these haven't been tested in a while). I've started work on porting it to #HaikuOS.
The repo has been moved to a new GitHub organisation, which you can find here. https://github.com/plptools/plptools
-
Some #Psion news! #plptools, the open source suite of programs for transferring files to and from #EPOC16 and #EPOC32 devices, has some additional maintainers: @captfab, @jbmorley ... and me!
We're looking into how we can take the project into the future. We do have some ideas, but we're taking a considered approach to future development.
plptools currently runs on Linux and macOS (and possibly FreeBSD, NetBSD, Solaris, AIX and HP-UX, although these haven't been tested in a while). I've started work on porting it to #HaikuOS.
The repo has been moved to a new GitHub organisation, which you can find here. https://github.com/plptools/plptools
-
Some #Psion news! #plptools, the open source suite of programs for transferring files to and from #EPOC16 and #EPOC32 devices, has some additional maintainers: @captfab, @jbmorley ... and me!
We're looking into how we can take the project into the future. We do have some ideas, but we're taking a considered approach to future development.
plptools currently runs on Linux and macOS (and possibly FreeBSD, NetBSD, Solaris, AIX and HP-UX, although these haven't been tested in a while). I've started work on porting it to #HaikuOS.
The repo has been moved to a new GitHub organisation, which you can find here. https://github.com/plptools/plptools
-
Some #Psion news! #plptools, the open source suite of programs for transferring files to and from #EPOC16 and #EPOC32 devices, has some additional maintainers: @captfab, @jbmorley ... and me!
We're looking into how we can take the project into the future. We do have some ideas, but we're taking a considered approach to future development.
plptools currently runs on Linux and macOS (and possibly FreeBSD, NetBSD, Solaris, AIX and HP-UX, although these haven't been tested in a while). I've started work on porting it to #HaikuOS.
The repo has been moved to a new GitHub organisation, which you can find here. https://github.com/plptools/plptools
-
If anyone fancies following in my footsteps with #EPOC16 hackery, I've released my updates to #EDisAsm as 0.0.6. First update in a couple of years!
-
If anyone fancies following in my footsteps with #EPOC16 hackery, I've released my updates to #EDisAsm as 0.0.6. First update in a couple of years!
-
If anyone fancies following in my footsteps with #EPOC16 hackery, I've released my updates to #EDisAsm as 0.0.6. First update in a couple of years!
-
If anyone fancies following in my footsteps with #EPOC16 hackery, I've released my updates to #EDisAsm as 0.0.6. First update in a couple of years!
-
If anyone fancies following in my footsteps with #EPOC16 hackery, I've released my updates to #EDisAsm as 0.0.6. First update in a couple of years!
-
I originally thought that it was just a hardware thing - solder on another chip, job done. After all, the pads were on the board, so why wouldn't #Psion have made #EPOC16 work with 4MB RAM?
But maybe a 4MB 3mx just wasn't a priority for Psion any more. #EPOC32 and the Series 5 were in full swing by the time the 3mx was released. The two Psions were drifting apart, too - Psion's hardware business ended up refocusing on Windows CE machines.
Psion had the ramdrive working with 2MB machines since the 3a2. The code probably hadn't been touched in ages, and it might have been too much hassle to update for the returns they thought they might get.
This is all speculation, of course. But it would make sense.
-
I originally thought that it was just a hardware thing - solder on another chip, job done. After all, the pads were on the board, so why wouldn't #Psion have made #EPOC16 work with 4MB RAM?
But maybe a 4MB 3mx just wasn't a priority for Psion any more. #EPOC32 and the Series 5 were in full swing by the time the 3mx was released. The two Psions were drifting apart, too - Psion's hardware business ended up refocusing on Windows CE machines.
Psion had the ramdrive working with 2MB machines since the 3a2. The code probably hadn't been touched in ages, and it might have been too much hassle to update for the returns they thought they might get.
This is all speculation, of course. But it would make sense.
-
I originally thought that it was just a hardware thing - solder on another chip, job done. After all, the pads were on the board, so why wouldn't #Psion have made #EPOC16 work with 4MB RAM?
But maybe a 4MB 3mx just wasn't a priority for Psion any more. #EPOC32 and the Series 5 were in full swing by the time the 3mx was released. The two Psions were drifting apart, too - Psion's hardware business ended up refocusing on Windows CE machines.
Psion had the ramdrive working with 2MB machines since the 3a2. The code probably hadn't been touched in ages, and it might have been too much hassle to update for the returns they thought they might get.
This is all speculation, of course. But it would make sense.
-
I originally thought that it was just a hardware thing - solder on another chip, job done. After all, the pads were on the board, so why wouldn't #Psion have made #EPOC16 work with 4MB RAM?
But maybe a 4MB 3mx just wasn't a priority for Psion any more. #EPOC32 and the Series 5 were in full swing by the time the 3mx was released. The two Psions were drifting apart, too - Psion's hardware business ended up refocusing on Windows CE machines.
Psion had the ramdrive working with 2MB machines since the 3a2. The code probably hadn't been touched in ages, and it might have been too much hassle to update for the returns they thought they might get.
This is all speculation, of course. But it would make sense.
-
I originally thought that it was just a hardware thing - solder on another chip, job done. After all, the pads were on the board, so why wouldn't #Psion have made #EPOC16 work with 4MB RAM?
But maybe a 4MB 3mx just wasn't a priority for Psion any more. #EPOC32 and the Series 5 were in full swing by the time the 3mx was released. The two Psions were drifting apart, too - Psion's hardware business ended up refocusing on Windows CE machines.
Psion had the ramdrive working with 2MB machines since the 3a2. The code probably hadn't been touched in ages, and it might have been too much hassle to update for the returns they thought they might get.
This is all speculation, of course. But it would make sense.
-
Some success with the 4MB #Psion 3mx!
I've been able to write directly to a page of RAM in the upper 2MB of memory, using #EDisAsm. I modified one of the memory-dumping assembly routines to basically go in the opposite direction. It writes 16 bytes to bank 0x6000, page 0x20. Then I dumped that to a file.
It worked! There's no corruption, and I can't see it mirrored anywhere. Using this basic test, we can pretty safely say that ASIC9MX is able to address the extra RAM (like the SDK says), and that the second chip is soldered correctly.
However, this doesn't explain why #EPOC16 doesn't like it. To recap, although EPOC16 reports that it has 4MB RAM, the ramdrive (M:) is inaccessible - apps report that the "media is corrupted", and the OS says it's unformatted. Any attempt to format the ramdrive fails silently.
The current guess is that the ramdrive "driver" can't handle more than 2MB RAM. It might be just the formatting routine, but it could be the ramdrive filesystem can't handle it. However, there might be a hard limit on pointers. This could be a bigger issue: the ramdrive in EPOC16 resizes dynamically, so the ramdrive "driver" and the filesystem's pointers would need to be able to handle the bigger filesystem size.
Unfortunately, this filesystem is undocumented - Psion never expected anyone to need to fiddle with it. Fortunately, EDisAsm can dump all memory, so it would be possible to analyse it. Dump a freshly booted 2MB 3mx, add a file, dump it again, delete a file, dump it again...
If it turns out that this is the case, it might be necessary to create a custom EPOC16 ROM. This would require a few things: working out how to modify the driver (and anything else) successfully, putting together a new EPOC16 image with the be driver, and a 3mx that's been modded to take flash. Bearing in mind that no EPOC16 source has been unearthed.
In conclusion, definitely progress, but there's still a long way to go.
-
Some success with the 4MB #Psion 3mx!
I've been able to write directly to a page of RAM in the upper 2MB of memory, using #EDisAsm. I modified one of the memory-dumping assembly routines to basically go in the opposite direction. It writes 16 bytes to bank 0x6000, page 0x20. Then I dumped that to a file.
It worked! There's no corruption, and I can't see it mirrored anywhere. Using this basic test, we can pretty safely say that ASIC9MX is able to address the extra RAM (like the SDK says), and that the second chip is soldered correctly.
However, this doesn't explain why #EPOC16 doesn't like it. To recap, although EPOC16 reports that it has 4MB RAM, the ramdrive (M:) is inaccessible - apps report that the "media is corrupted", and the OS says it's unformatted. Any attempt to format the ramdrive fails silently.
The current guess is that the ramdrive "driver" can't handle more than 2MB RAM. It might be just the formatting routine, but it could be the ramdrive filesystem can't handle it. However, there might be a hard limit on pointers. This could be a bigger issue: the ramdrive in EPOC16 resizes dynamically, so the ramdrive "driver" and the filesystem's pointers would need to be able to handle the bigger filesystem size.
Unfortunately, this filesystem is undocumented - Psion never expected anyone to need to fiddle with it. Fortunately, EDisAsm can dump all memory, so it would be possible to analyse it. Dump a freshly booted 2MB 3mx, add a file, dump it again, delete a file, dump it again...
If it turns out that this is the case, it might be necessary to create a custom EPOC16 ROM. This would require a few things: working out how to modify the driver (and anything else) successfully, putting together a new EPOC16 image with the be driver, and a 3mx that's been modded to take flash. Bearing in mind that no EPOC16 source has been unearthed.
In conclusion, definitely progress, but there's still a long way to go.
-
Some success with the 4MB #Psion 3mx!
I've been able to write directly to a page of RAM in the upper 2MB of memory, using #EDisAsm. I modified one of the memory-dumping assembly routines to basically go in the opposite direction. It writes 16 bytes to bank 0x6000, page 0x20. Then I dumped that to a file.
It worked! There's no corruption, and I can't see it mirrored anywhere. Using this basic test, we can pretty safely say that ASIC9MX is able to address the extra RAM (like the SDK says), and that the second chip is soldered correctly.
However, this doesn't explain why #EPOC16 doesn't like it. To recap, although EPOC16 reports that it has 4MB RAM, the ramdrive (M:) is inaccessible - apps report that the "media is corrupted", and the OS says it's unformatted. Any attempt to format the ramdrive fails silently.
The current guess is that the ramdrive "driver" can't handle more than 2MB RAM. It might be just the formatting routine, but it could be the ramdrive filesystem can't handle it. However, there might be a hard limit on pointers. This could be a bigger issue: the ramdrive in EPOC16 resizes dynamically, so the ramdrive "driver" and the filesystem's pointers would need to be able to handle the bigger filesystem size.
Unfortunately, this filesystem is undocumented - Psion never expected anyone to need to fiddle with it. Fortunately, EDisAsm can dump all memory, so it would be possible to analyse it. Dump a freshly booted 2MB 3mx, add a file, dump it again, delete a file, dump it again...
If it turns out that this is the case, it might be necessary to create a custom EPOC16 ROM. This would require a few things: working out how to modify the driver (and anything else) successfully, putting together a new EPOC16 image with the be driver, and a 3mx that's been modded to take flash. Bearing in mind that no EPOC16 source has been unearthed.
In conclusion, definitely progress, but there's still a long way to go.
-
Some success with the 4MB #Psion 3mx!
I've been able to write directly to a page of RAM in the upper 2MB of memory, using #EDisAsm. I modified one of the memory-dumping assembly routines to basically go in the opposite direction. It writes 16 bytes to bank 0x6000, page 0x20. Then I dumped that to a file.
It worked! There's no corruption, and I can't see it mirrored anywhere. Using this basic test, we can pretty safely say that ASIC9MX is able to address the extra RAM (like the SDK says), and that the second chip is soldered correctly.
However, this doesn't explain why #EPOC16 doesn't like it. To recap, although EPOC16 reports that it has 4MB RAM, the ramdrive (M:) is inaccessible - apps report that the "media is corrupted", and the OS says it's unformatted. Any attempt to format the ramdrive fails silently.
The current guess is that the ramdrive "driver" can't handle more than 2MB RAM. It might be just the formatting routine, but it could be the ramdrive filesystem can't handle it. However, there might be a hard limit on pointers. This could be a bigger issue: the ramdrive in EPOC16 resizes dynamically, so the ramdrive "driver" and the filesystem's pointers would need to be able to handle the bigger filesystem size.
Unfortunately, this filesystem is undocumented - Psion never expected anyone to need to fiddle with it. Fortunately, EDisAsm can dump all memory, so it would be possible to analyse it. Dump a freshly booted 2MB 3mx, add a file, dump it again, delete a file, dump it again...
If it turns out that this is the case, it might be necessary to create a custom EPOC16 ROM. This would require a few things: working out how to modify the driver (and anything else) successfully, putting together a new EPOC16 image with the be driver, and a 3mx that's been modded to take flash. Bearing in mind that no EPOC16 source has been unearthed.
In conclusion, definitely progress, but there's still a long way to go.
-
Some success with the 4MB #Psion 3mx!
I've been able to write directly to a page of RAM in the upper 2MB of memory, using #EDisAsm. I modified one of the memory-dumping assembly routines to basically go in the opposite direction. It writes 16 bytes to bank 0x6000, page 0x20. Then I dumped that to a file.
It worked! There's no corruption, and I can't see it mirrored anywhere. Using this basic test, we can pretty safely say that ASIC9MX is able to address the extra RAM (like the SDK says), and that the second chip is soldered correctly.
However, this doesn't explain why #EPOC16 doesn't like it. To recap, although EPOC16 reports that it has 4MB RAM, the ramdrive (M:) is inaccessible - apps report that the "media is corrupted", and the OS says it's unformatted. Any attempt to format the ramdrive fails silently.
The current guess is that the ramdrive "driver" can't handle more than 2MB RAM. It might be just the formatting routine, but it could be the ramdrive filesystem can't handle it. However, there might be a hard limit on pointers. This could be a bigger issue: the ramdrive in EPOC16 resizes dynamically, so the ramdrive "driver" and the filesystem's pointers would need to be able to handle the bigger filesystem size.
Unfortunately, this filesystem is undocumented - Psion never expected anyone to need to fiddle with it. Fortunately, EDisAsm can dump all memory, so it would be possible to analyse it. Dump a freshly booted 2MB 3mx, add a file, dump it again, delete a file, dump it again...
If it turns out that this is the case, it might be necessary to create a custom EPOC16 ROM. This would require a few things: working out how to modify the driver (and anything else) successfully, putting together a new EPOC16 image with the be driver, and a 3mx that's been modded to take flash. Bearing in mind that no EPOC16 source has been unearthed.
In conclusion, definitely progress, but there's still a long way to go.
-
Some of you might vaguely remember that I have a mildly modified #Psion Series 3mx. It's got an extra 2MB RAM, bringing it to 4MB. One snag - it doesn't work.
When I last left it (a few months back), #EPOC16 couldn't see the extra 2MB RAM - the OS was saying the machine only had 2MB RAM. However, #EDisAsm (the EPOC16 disassembly/debugging/dumping tool) was able to see and dump the upper 2MB of the 4MB RAM. This means that ASIC9MX's NRAS0 and NRAS1 are clearly working, acting as chip selects. Something else was wrong.
Yesterday, I decided to revisit it. I discovered that pin D1 on the second RAM chip wasn't making contact with the pad. A quick reflow of all the pins on that chip and... a familiar error!
"Media is corrupt"
So now EPOC16 can see the second chip, but it doesn't like something about it. Last time this happened, it was because I'd put in the wrong type of RAM chip (10 rows by 10 columns, rather than 12 rows by 8 columns), so the address lines were messed up. This time I know it's the right chip, because it's identical to the first RAM chip. And the first chip is fine, because if it wasn't then the machine wouldn't boot.
I loaded EDisAsm onto an SSD and dumped the entire 4MB RAM over RS232 to see if I can see any patterns in the higher banks of memory (0x20 to 0x3F). I've also dumped the RAM from a normal 2MB 3mx to see if there are any clues.
Of course, the chip could also be faulty, causing the corruption. (I have spares.) It could be that there's another data pin not connected properly (I did re-flow all the pins and check continuity, but you never know). Alternatively, EPOC16 might just not like seeing more than 2MB RAM, even if ASIC9MX supports it, meaning it's never going to work without some software hackery.
I'm going to leave it again for now as I have $dayjob stuff to be getting on with. I don't know whether to feel encouraged or discouraged by this, but I guess it's progress of sorts.
-
Some of you might vaguely remember that I have a mildly modified #Psion Series 3mx. It's got an extra 2MB RAM, bringing it to 4MB. One snag - it doesn't work.
When I last left it (a few months back), #EPOC16 couldn't see the extra 2MB RAM - the OS was saying the machine only had 2MB RAM. However, #EDisAsm (the EPOC16 disassembly/debugging/dumping tool) was able to see and dump the upper 2MB of the 4MB RAM. This means that ASIC9MX's NRAS0 and NRAS1 are clearly working, acting as chip selects. Something else was wrong.
Yesterday, I decided to revisit it. I discovered that pin D1 on the second RAM chip wasn't making contact with the pad. A quick reflow of all the pins on that chip and... a familiar error!
"Media is corrupt"
So now EPOC16 can see the second chip, but it doesn't like something about it. Last time this happened, it was because I'd put in the wrong type of RAM chip (10 rows by 10 columns, rather than 12 rows by 8 columns), so the address lines were messed up. This time I know it's the right chip, because it's identical to the first RAM chip. And the first chip is fine, because if it wasn't then the machine wouldn't boot.
I loaded EDisAsm onto an SSD and dumped the entire 4MB RAM over RS232 to see if I can see any patterns in the higher banks of memory (0x20 to 0x3F). I've also dumped the RAM from a normal 2MB 3mx to see if there are any clues.
Of course, the chip could also be faulty, causing the corruption. (I have spares.) It could be that there's another data pin not connected properly (I did re-flow all the pins and check continuity, but you never know). Alternatively, EPOC16 might just not like seeing more than 2MB RAM, even if ASIC9MX supports it, meaning it's never going to work without some software hackery.
I'm going to leave it again for now as I have $dayjob stuff to be getting on with. I don't know whether to feel encouraged or discouraged by this, but I guess it's progress of sorts.
-
Some of you might vaguely remember that I have a mildly modified #Psion Series 3mx. It's got an extra 2MB RAM, bringing it to 4MB. One snag - it doesn't work.
When I last left it (a few months back), #EPOC16 couldn't see the extra 2MB RAM - the OS was saying the machine only had 2MB RAM. However, #EDisAsm (the EPOC16 disassembly/debugging/dumping tool) was able to see and dump the upper 2MB of the 4MB RAM. This means that ASIC9MX's NRAS0 and NRAS1 are clearly working, acting as chip selects. Something else was wrong.
Yesterday, I decided to revisit it. I discovered that pin D1 on the second RAM chip wasn't making contact with the pad. A quick reflow of all the pins on that chip and... a familiar error!
"Media is corrupt"
So now EPOC16 can see the second chip, but it doesn't like something about it. Last time this happened, it was because I'd put in the wrong type of RAM chip (10 rows by 10 columns, rather than 12 rows by 8 columns), so the address lines were messed up. This time I know it's the right chip, because it's identical to the first RAM chip. And the first chip is fine, because if it wasn't then the machine wouldn't boot.
I loaded EDisAsm onto an SSD and dumped the entire 4MB RAM over RS232 to see if I can see any patterns in the higher banks of memory (0x20 to 0x3F). I've also dumped the RAM from a normal 2MB 3mx to see if there are any clues.
Of course, the chip could also be faulty, causing the corruption. (I have spares.) It could be that there's another data pin not connected properly (I did re-flow all the pins and check continuity, but you never know). Alternatively, EPOC16 might just not like seeing more than 2MB RAM, even if ASIC9MX supports it, meaning it's never going to work without some software hackery.
I'm going to leave it again for now as I have $dayjob stuff to be getting on with. I don't know whether to feel encouraged or discouraged by this, but I guess it's progress of sorts.
-
Some of you might vaguely remember that I have a mildly modified #Psion Series 3mx. It's got an extra 2MB RAM, bringing it to 4MB. One snag - it doesn't work.
When I last left it (a few months back), #EPOC16 couldn't see the extra 2MB RAM - the OS was saying the machine only had 2MB RAM. However, #EDisAsm (the EPOC16 disassembly/debugging/dumping tool) was able to see and dump the upper 2MB of the 4MB RAM. This means that ASIC9MX's NRAS0 and NRAS1 are clearly working, acting as chip selects. Something else was wrong.
Yesterday, I decided to revisit it. I discovered that pin D1 on the second RAM chip wasn't making contact with the pad. A quick reflow of all the pins on that chip and... a familiar error!
"Media is corrupt"
So now EPOC16 can see the second chip, but it doesn't like something about it. Last time this happened, it was because I'd put in the wrong type of RAM chip (10 rows by 10 columns, rather than 12 rows by 8 columns), so the address lines were messed up. This time I know it's the right chip, because it's identical to the first RAM chip. And the first chip is fine, because if it wasn't then the machine wouldn't boot.
I loaded EDisAsm onto an SSD and dumped the entire 4MB RAM over RS232 to see if I can see any patterns in the higher banks of memory (0x20 to 0x3F). I've also dumped the RAM from a normal 2MB 3mx to see if there are any clues.
Of course, the chip could also be faulty, causing the corruption. (I have spares.) It could be that there's another data pin not connected properly (I did re-flow all the pins and check continuity, but you never know). Alternatively, EPOC16 might just not like seeing more than 2MB RAM, even if ASIC9MX supports it, meaning it's never going to work without some software hackery.
I'm going to leave it again for now as I have $dayjob stuff to be getting on with. I don't know whether to feel encouraged or discouraged by this, but I guess it's progress of sorts.
-
Some of you might vaguely remember that I have a mildly modified #Psion Series 3mx. It's got an extra 2MB RAM, bringing it to 4MB. One snag - it doesn't work.
When I last left it (a few months back), #EPOC16 couldn't see the extra 2MB RAM - the OS was saying the machine only had 2MB RAM. However, #EDisAsm (the EPOC16 disassembly/debugging/dumping tool) was able to see and dump the upper 2MB of the 4MB RAM. This means that ASIC9MX's NRAS0 and NRAS1 are clearly working, acting as chip selects. Something else was wrong.
Yesterday, I decided to revisit it. I discovered that pin D1 on the second RAM chip wasn't making contact with the pad. A quick reflow of all the pins on that chip and... a familiar error!
"Media is corrupt"
So now EPOC16 can see the second chip, but it doesn't like something about it. Last time this happened, it was because I'd put in the wrong type of RAM chip (10 rows by 10 columns, rather than 12 rows by 8 columns), so the address lines were messed up. This time I know it's the right chip, because it's identical to the first RAM chip. And the first chip is fine, because if it wasn't then the machine wouldn't boot.
I loaded EDisAsm onto an SSD and dumped the entire 4MB RAM over RS232 to see if I can see any patterns in the higher banks of memory (0x20 to 0x3F). I've also dumped the RAM from a normal 2MB 3mx to see if there are any clues.
Of course, the chip could also be faulty, causing the corruption. (I have spares.) It could be that there's another data pin not connected properly (I did re-flow all the pins and check continuity, but you never know). Alternatively, EPOC16 might just not like seeing more than 2MB RAM, even if ASIC9MX supports it, meaning it's never going to work without some software hackery.
I'm going to leave it again for now as I have $dayjob stuff to be getting on with. I don't know whether to feel encouraged or discouraged by this, but I guess it's progress of sorts.
-
Someone asked me some questions on the #Psion Series 3, so I thought I'd post my response here in case anyone else is interested. #LongRead
Emulator
You've got two options. The first is the original "emulators" written by Psion,
S3AEMUL.EXEandS3CEMUL.EXE. They both run in DOS and emulate the 3a and 3c. But they're less of an emulator than a runtime environment for #EPOC16 (the OS). There's good and bad to this. You can runS3AEMULandS3CEMULstraight in #DOSBox and it will talk to your host OS's filesystem (Windows, Linux, macOS, whatever). You need to map an M: drive in DOSBox for the internal storage, but once that's done you can copy files straight into that folder on your host OS and run them in the emulators. The downside is that it's not true hardware emulation. You won't get a good judge of the speed of a real device, and some syscalls aren't implemented so will fail or crash the #emulator. They're bundled with the SDK (see below).The alternative is #MAME. This is the closest to proper hardware emulation you're going to find. You can either dump your own ROMs using a tool called #EDisAsm, or you can find them in the usual MAME ROM repos. The one thing that is notably missing is RS232 emulation from the later models, because we haven't been able to find any documentation on the silicon, but it's working fine with the 3a.
Toolchain
At the moment you have only one option - the Psion SIBO C SDK with the #TopSpeed C Compiler. You're going to need DOSBox (I personally prefer DOSBox Staging). It's all available on the Internet Archive in one easy download, including all the documentation you will need.
https://archive.org/details/psion-sibo-c-sdk
From there, you have a few libraries you can use. There CLIB, which is a pure ANSI C implementation, designed to easily port apps - don't use it, it's slow and you'll be missing a lot of features. Then there's PLIB, which is Psion's C dialect - very nice to use, and you can put together a C app pretty quickly. Finally, there's OLIB, which is Psion's proprietary OO C - it feels very clunky, but once you get over that it can be very powerful.
EPOC16 apps are restricted to a very pure version of the small memory model, but you can split code up into libraries known as DYLs.
In the past I've written code using VS Code, which can be made to play nicely with the SDK's header files. I've not got it working with NeoVim and clangd yet, but it should be possible with cmake.
The SDK comes with a debugger (
SDBG.EXE), a DOS GUI app. If you runSDBG.EXEin DOSBox Staging, run thePsion3aMAME emulation, and enable RS232 over TCP on both, you can useSDBGto send apps to MAME. If you enable symbols, you can step through the code. It's rudimentary by modern standards, but it works pretty well.I say "at the moment" because I'm slowly rewriting the tools in the SDK. I already have a new working version of #CTRAN, the preprocessor for Psion OO C, but I'm a long way from a compiler. There have been efforts to coax gcc into compiling for SIBO/EPOC16, but I think they have stalled for now.
If you want some examples of EPOC16 C and OO C code, take a look at these:
https://github.com/thelastpsion/edisasm
https://github.com/thelastpsion/pyramid
https://github.com/thelastpsion/nfsc
https://github.com/nickmat/Psion3-Wari
https://github.com/nickmat/Psion3-VectorDevice
The 3mx is the best choice. It's significantly faster than the earlier models (27.6 MHz vs 7.6 MHz), has a switchable backlight, the fastest RS232 and the best version of EPOC16. I "daily drive" one for journalling, adventure games, and a few other small tasks. After that I'd say the 3c (beware - they were covered in soft-touch rubber, so will need cleaning) and the 2MB 3a. The latter is the most common. Most 3c units came with a backlight, except for the early UK ones. The 3a doesn't. Arguably the non-backlit screens have better contrast so you don't need the backlight so much in lower light, but the backlight has obvious benefits.
-
Someone asked me some questions on the #Psion Series 3, so I thought I'd post my response here in case anyone else is interested. #LongRead
Emulator
You've got two options. The first is the original "emulators" written by Psion,
S3AEMUL.EXEandS3CEMUL.EXE. They both run in DOS and emulate the 3a and 3c. But they're less of an emulator than a runtime environment for #EPOC16 (the OS). There's good and bad to this. You can runS3AEMULandS3CEMULstraight in #DOSBox and it will talk to your host OS's filesystem (Windows, Linux, macOS, whatever). You need to map an M: drive in DOSBox for the internal storage, but once that's done you can copy files straight into that folder on your host OS and run them in the emulators. The downside is that it's not true hardware emulation. You won't get a good judge of the speed of a real device, and some syscalls aren't implemented so will fail or crash the #emulator. They're bundled with the SDK (see below).The alternative is #MAME. This is the closest to proper hardware emulation you're going to find. You can either dump your own ROMs using a tool called #EDisAsm, or you can find them in the usual MAME ROM repos. The one thing that is notably missing is RS232 emulation from the later models, because we haven't been able to find any documentation on the silicon, but it's working fine with the 3a.
Toolchain
At the moment you have only one option - the Psion SIBO C SDK with the #TopSpeed C Compiler. You're going to need DOSBox (I personally prefer DOSBox Staging). It's all available on the Internet Archive in one easy download, including all the documentation you will need.
https://archive.org/details/psion-sibo-c-sdk
From there, you have a few libraries you can use. There CLIB, which is a pure ANSI C implementation, designed to easily port apps - don't use it, it's slow and you'll be missing a lot of features. Then there's PLIB, which is Psion's C dialect - very nice to use, and you can put together a C app pretty quickly. Finally, there's OLIB, which is Psion's proprietary OO C - it feels very clunky, but once you get over that it can be very powerful.
EPOC16 apps are restricted to a very pure version of the small memory model, but you can split code up into libraries known as DYLs.
In the past I've written code using VS Code, which can be made to play nicely with the SDK's header files. I've not got it working with NeoVim and clangd yet, but it should be possible with cmake.
The SDK comes with a debugger (
SDBG.EXE), a DOS GUI app. If you runSDBG.EXEin DOSBox Staging, run thePsion3aMAME emulation, and enable RS232 over TCP on both, you can useSDBGto send apps to MAME. If you enable symbols, you can step through the code. It's rudimentary by modern standards, but it works pretty well.I say "at the moment" because I'm slowly rewriting the tools in the SDK. I already have a new working version of #CTRAN, the preprocessor for Psion OO C, but I'm a long way from a compiler. There have been efforts to coax gcc into compiling for SIBO/EPOC16, but I think they have stalled for now.
If you want some examples of EPOC16 C and OO C code, take a look at these:
https://github.com/thelastpsion/edisasm
https://github.com/thelastpsion/pyramid
https://github.com/thelastpsion/nfsc
https://github.com/nickmat/Psion3-Wari
https://github.com/nickmat/Psion3-VectorDevice
The 3mx is the best choice. It's significantly faster than the earlier models (27.6 MHz vs 7.6 MHz), has a switchable backlight, the fastest RS232 and the best version of EPOC16. I "daily drive" one for journalling, adventure games, and a few other small tasks. After that I'd say the 3c (beware - they were covered in soft-touch rubber, so will need cleaning) and the 2MB 3a. The latter is the most common. Most 3c units came with a backlight, except for the early UK ones. The 3a doesn't. Arguably the non-backlit screens have better contrast so you don't need the backlight so much in lower light, but the backlight has obvious benefits.
-
Someone asked me some questions on the #Psion Series 3, so I thought I'd post my response here in case anyone else is interested. #LongRead
Emulator
You've got two options. The first is the original "emulators" written by Psion,
S3AEMUL.EXEandS3CEMUL.EXE. They both run in DOS and emulate the 3a and 3c. But they're less of an emulator than a runtime environment for #EPOC16 (the OS). There's good and bad to this. You can runS3AEMULandS3CEMULstraight in #DOSBox and it will talk to your host OS's filesystem (Windows, Linux, macOS, whatever). You need to map an M: drive in DOSBox for the internal storage, but once that's done you can copy files straight into that folder on your host OS and run them in the emulators. The downside is that it's not true hardware emulation. You won't get a good judge of the speed of a real device, and some syscalls aren't implemented so will fail or crash the #emulator. They're bundled with the SDK (see below).The alternative is #MAME. This is the closest to proper hardware emulation you're going to find. You can either dump your own ROMs using a tool called #EDisAsm, or you can find them in the usual MAME ROM repos. The one thing that is notably missing is RS232 emulation from the later models, because we haven't been able to find any documentation on the silicon, but it's working fine with the 3a.
Toolchain
At the moment you have only one option - the Psion SIBO C SDK with the #TopSpeed C Compiler. You're going to need DOSBox (I personally prefer DOSBox Staging). It's all available on the Internet Archive in one easy download, including all the documentation you will need.
https://archive.org/details/psion-sibo-c-sdk
From there, you have a few libraries you can use. There CLIB, which is a pure ANSI C implementation, designed to easily port apps - don't use it, it's slow and you'll be missing a lot of features. Then there's PLIB, which is Psion's C dialect - very nice to use, and you can put together a C app pretty quickly. Finally, there's OLIB, which is Psion's proprietary OO C - it feels very clunky, but once you get over that it can be very powerful.
EPOC16 apps are restricted to a very pure version of the small memory model, but you can split code up into libraries known as DYLs.
In the past I've written code using VS Code, which can be made to play nicely with the SDK's header files. I've not got it working with NeoVim and clangd yet, but it should be possible with cmake.
The SDK comes with a debugger (
SDBG.EXE), a DOS GUI app. If you runSDBG.EXEin DOSBox Staging, run thePsion3aMAME emulation, and enable RS232 over TCP on both, you can useSDBGto send apps to MAME. If you enable symbols, you can step through the code. It's rudimentary by modern standards, but it works pretty well.I say "at the moment" because I'm slowly rewriting the tools in the SDK. I already have a new working version of #CTRAN, the preprocessor for Psion OO C, but I'm a long way from a compiler. There have been efforts to coax gcc into compiling for SIBO/EPOC16, but I think they have stalled for now.
If you want some examples of EPOC16 C and OO C code, take a look at these:
https://github.com/thelastpsion/edisasm
https://github.com/thelastpsion/pyramid
https://github.com/thelastpsion/nfsc
https://github.com/nickmat/Psion3-Wari
https://github.com/nickmat/Psion3-VectorDevice
The 3mx is the best choice. It's significantly faster than the earlier models (27.6 MHz vs 7.6 MHz), has a switchable backlight, the fastest RS232 and the best version of EPOC16. I "daily drive" one for journalling, adventure games, and a few other small tasks. After that I'd say the 3c (beware - they were covered in soft-touch rubber, so will need cleaning) and the 2MB 3a. The latter is the most common. Most 3c units came with a backlight, except for the early UK ones. The 3a doesn't. Arguably the non-backlit screens have better contrast so you don't need the backlight so much in lower light, but the backlight has obvious benefits.
-
Someone asked me some questions on the #Psion Series 3, so I thought I'd post my response here in case anyone else is interested. #LongRead
Emulator
You've got two options. The first is the original "emulators" written by Psion,
S3AEMUL.EXEandS3CEMUL.EXE. They both run in DOS and emulate the 3a and 3c. But they're less of an emulator than a runtime environment for #EPOC16 (the OS). There's good and bad to this. You can runS3AEMULandS3CEMULstraight in #DOSBox and it will talk to your host OS's filesystem (Windows, Linux, macOS, whatever). You need to map an M: drive in DOSBox for the internal storage, but once that's done you can copy files straight into that folder on your host OS and run them in the emulators. The downside is that it's not true hardware emulation. You won't get a good judge of the speed of a real device, and some syscalls aren't implemented so will fail or crash the #emulator. They're bundled with the SDK (see below).The alternative is #MAME. This is the closest to proper hardware emulation you're going to find. You can either dump your own ROMs using a tool called #EDisAsm, or you can find them in the usual MAME ROM repos. The one thing that is notably missing is RS232 emulation from the later models, because we haven't been able to find any documentation on the silicon, but it's working fine with the 3a.
Toolchain
At the moment you have only one option - the Psion SIBO C SDK with the #TopSpeed C Compiler. You're going to need DOSBox (I personally prefer DOSBox Staging). It's all available on the Internet Archive in one easy download, including all the documentation you will need.
https://archive.org/details/psion-sibo-c-sdk
From there, you have a few libraries you can use. There CLIB, which is a pure ANSI C implementation, designed to easily port apps - don't use it, it's slow and you'll be missing a lot of features. Then there's PLIB, which is Psion's C dialect - very nice to use, and you can put together a C app pretty quickly. Finally, there's OLIB, which is Psion's proprietary OO C - it feels very clunky, but once you get over that it can be very powerful.
EPOC16 apps are restricted to a very pure version of the small memory model, but you can split code up into libraries known as DYLs.
In the past I've written code using VS Code, which can be made to play nicely with the SDK's header files. I've not got it working with NeoVim and clangd yet, but it should be possible with cmake.
The SDK comes with a debugger (
SDBG.EXE), a DOS GUI app. If you runSDBG.EXEin DOSBox Staging, run thePsion3aMAME emulation, and enable RS232 over TCP on both, you can useSDBGto send apps to MAME. If you enable symbols, you can step through the code. It's rudimentary by modern standards, but it works pretty well.I say "at the moment" because I'm slowly rewriting the tools in the SDK. I already have a new working version of #CTRAN, the preprocessor for Psion OO C, but I'm a long way from a compiler. There have been efforts to coax gcc into compiling for SIBO/EPOC16, but I think they have stalled for now.
If you want some examples of EPOC16 C and OO C code, take a look at these:
https://github.com/thelastpsion/edisasm
https://github.com/thelastpsion/pyramid
https://github.com/thelastpsion/nfsc
https://github.com/nickmat/Psion3-Wari
https://github.com/nickmat/Psion3-VectorDevice
The 3mx is the best choice. It's significantly faster than the earlier models (27.6 MHz vs 7.6 MHz), has a switchable backlight, the fastest RS232 and the best version of EPOC16. I "daily drive" one for journalling, adventure games, and a few other small tasks. After that I'd say the 3c (beware - they were covered in soft-touch rubber, so will need cleaning) and the 2MB 3a. The latter is the most common. Most 3c units came with a backlight, except for the early UK ones. The 3a doesn't. Arguably the non-backlit screens have better contrast so you don't need the backlight so much in lower light, but the backlight has obvious benefits.
-
Someone asked me some questions on the #Psion Series 3, so I thought I'd post my response here in case anyone else is interested. #LongRead
Emulator
You've got two options. The first is the original "emulators" written by Psion,
S3AEMUL.EXEandS3CEMUL.EXE. They both run in DOS and emulate the 3a and 3c. But they're less of an emulator than a runtime environment for #EPOC16 (the OS). There's good and bad to this. You can runS3AEMULandS3CEMULstraight in #DOSBox and it will talk to your host OS's filesystem (Windows, Linux, macOS, whatever). You need to map an M: drive in DOSBox for the internal storage, but once that's done you can copy files straight into that folder on your host OS and run them in the emulators. The downside is that it's not true hardware emulation. You won't get a good judge of the speed of a real device, and some syscalls aren't implemented so will fail or crash the #emulator. They're bundled with the SDK (see below).The alternative is #MAME. This is the closest to proper hardware emulation you're going to find. You can either dump your own ROMs using a tool called #EDisAsm, or you can find them in the usual MAME ROM repos. The one thing that is notably missing is RS232 emulation from the later models, because we haven't been able to find any documentation on the silicon, but it's working fine with the 3a.
Toolchain
At the moment you have only one option - the Psion SIBO C SDK with the #TopSpeed C Compiler. You're going to need DOSBox (I personally prefer DOSBox Staging). It's all available on the Internet Archive in one easy download, including all the documentation you will need.
https://archive.org/details/psion-sibo-c-sdk
From there, you have a few libraries you can use. There CLIB, which is a pure ANSI C implementation, designed to easily port apps - don't use it, it's slow and you'll be missing a lot of features. Then there's PLIB, which is Psion's C dialect - very nice to use, and you can put together a C app pretty quickly. Finally, there's OLIB, which is Psion's proprietary OO C - it feels very clunky, but once you get over that it can be very powerful.
EPOC16 apps are restricted to a very pure version of the small memory model, but you can split code up into libraries known as DYLs.
In the past I've written code using VS Code, which can be made to play nicely with the SDK's header files. I've not got it working with NeoVim and clangd yet, but it should be possible with cmake.
The SDK comes with a debugger (
SDBG.EXE), a DOS GUI app. If you runSDBG.EXEin DOSBox Staging, run thePsion3aMAME emulation, and enable RS232 over TCP on both, you can useSDBGto send apps to MAME. If you enable symbols, you can step through the code. It's rudimentary by modern standards, but it works pretty well.I say "at the moment" because I'm slowly rewriting the tools in the SDK. I already have a new working version of #CTRAN, the preprocessor for Psion OO C, but I'm a long way from a compiler. There have been efforts to coax gcc into compiling for SIBO/EPOC16, but I think they have stalled for now.
If you want some examples of EPOC16 C and OO C code, take a look at these:
https://github.com/thelastpsion/edisasm
https://github.com/thelastpsion/pyramid
https://github.com/thelastpsion/nfsc
https://github.com/nickmat/Psion3-Wari
https://github.com/nickmat/Psion3-VectorDevice
The 3mx is the best choice. It's significantly faster than the earlier models (27.6 MHz vs 7.6 MHz), has a switchable backlight, the fastest RS232 and the best version of EPOC16. I "daily drive" one for journalling, adventure games, and a few other small tasks. After that I'd say the 3c (beware - they were covered in soft-touch rubber, so will need cleaning) and the 2MB 3a. The latter is the most common. Most 3c units came with a backlight, except for the early UK ones. The 3a doesn't. Arguably the non-backlit screens have better contrast so you don't need the backlight so much in lower light, but the backlight has obvious benefits.
-
REPOST (JAN 2024): My first thoughts on #Psion's dialect of Object Oriented C for the Series 3 and related portable computers.
Includes the JPI/Clarion #TopSpeed #compiler, a proprietary preprocessor, the Eiffel programming language, and a handful of calling conventions.
Also, did somebody say Objective-C?
This is an old blog post from the beginning of the year. If you've been following my journey in recreating #CTRAN, this was written a week before I decided to take the plunge.
(Yes, I did say in the article that I definitely wouldn't be writing a compiler. I did say that.)
#RetroComputing #EPOC16 #CDECL #Clarion #TopSpeed #TopSpeedC #RetroProgramming #RetroDev #Smalltalk #ObjectPascal #preprocessor #Eiffel #OOP #ObjectiveC #compilers #ObjectOriented
-
REPOST (JAN 2024): My first thoughts on #Psion's dialect of Object Oriented C for the Series 3 and related portable computers.
Includes the JPI/Clarion #TopSpeed #compiler, a proprietary preprocessor, the Eiffel programming language, and a handful of calling conventions.
Also, did somebody say Objective-C?
This is an old blog post from the beginning of the year. If you've been following my journey in recreating #CTRAN, this was written a week before I decided to take the plunge.
(Yes, I did say in the article that I definitely wouldn't be writing a compiler. I did say that.)
#RetroComputing #EPOC16 #CDECL #Clarion #TopSpeed #TopSpeedC #RetroProgramming #RetroDev #Smalltalk #ObjectPascal #preprocessor #Eiffel #OOP #ObjectiveC #compilers #ObjectOriented
-
Here's something I wish would be open sourced.
The #TopSpeed C #compiler is an integral part of the #Psion SIBO C SDK.
Old timers might remember JPI as a group of developers who left #Borland in 1987, after Borland decided not to use the team's new compiler technology. They took their code with them, and it became the TopSpeed compiler.
From what I gather, the TopSpeed compiler IP is now owned by #SoftVelocity, the company who now also owns Clarion. I emailed them about 6 years ago, asking them if they would consider open sourcing the compiler code. I got no response, which I guess is to be expected.
I even found someone who had a copy of the source code (written in Modula-2), but they understandably wouldn't give it to me without the IP owner's approval.
This is the situation with so many bits of software (including the SIBO C SDK tools) from this time. We are lucky that copies of the applications still exist, otherwise the job of building C software for #EPOC16 would be significantly more difficult. But it is likely that the original source code, along with many other codebases, will disappear thanks to copyright laws that don't support digital preservation.
-
Here's something I wish would be open sourced.
The #TopSpeed C #compiler is an integral part of the #Psion SIBO C SDK.
Old timers might remember JPI as a group of developers who left #Borland in 1987, after Borland decided not to use the team's new compiler technology. They took their code with them, and it became the TopSpeed compiler.
From what I gather, the TopSpeed compiler IP is now owned by #SoftVelocity, the company who now also owns Clarion. I emailed them about 6 years ago, asking them if they would consider open sourcing the compiler code. I got no response, which I guess is to be expected.
I even found someone who had a copy of the source code (written in Modula-2), but they understandably wouldn't give it to me without the IP owner's approval.
This is the situation with so many bits of software (including the SIBO C SDK tools) from this time. We are lucky that copies of the applications still exist, otherwise the job of building C software for #EPOC16 would be significantly more difficult. But it is likely that the original source code, along with many other codebases, will disappear thanks to copyright laws that don't support digital preservation.
-
ICYMI: My first thoughts on #Psion's dialect of Object Oriented C for the Series 3 and related portable computers.
Includes the JPI/Clarion TopSpeed compiler, a proprietary preprocessor, the Eiffel programming language, and a handful of calling conventions.
Also, did somebody say Objective-C?
#RetroComputing #EPOC16 #CDECL #Clarion #TopSpeed #TopSpeedC #RetroProgramming #RetroDev #Smalltalk #ObjectPascal #preprocessor #Eiffel #OOP #ObjectiveC
-
I've just remembered that the source for Vector - a CAD app for #EPOC16 - is on GitHub, and it's completely written in #Psion's OO C (plus some #MASM code).
I believe this is currently the only EPOC16 HWIM (Psion's OO graphics library) app whose source code has been released.
If you're following along at home, the code is in the link below.
-
I've just remembered that the source for Vector - a CAD app for #EPOC16 - is on GitHub, and it's completely written in #Psion's OO C (plus some #MASM code).
I believe this is currently the only EPOC16 HWIM (Psion's OO graphics library) app whose source code has been released.
If you're following along at home, the code is in the link below.
-
I've just remembered that the source for Vector - a CAD app for #EPOC16 - is on GitHub, and it's completely written in #Psion's OO C (plus some #MASM code).
I believe this is currently the only EPOC16 HWIM (Psion's OO graphics library) app whose source code has been released.
If you're following along at home, the code is in the link below.
-
I've just remembered that the source for Vector - a CAD app for #EPOC16 - is on GitHub, and it's completely written in #Psion's OO C (plus some #MASM code).
I believe this is currently the only EPOC16 HWIM (Psion's OO graphics library) app whose source code has been released.
If you're following along at home, the code is in the link below.
-
I've just remembered that the source for Vector - a CAD app for #EPOC16 - is on GitHub, and it's completely written in #Psion's OO C (plus some #MASM code).
I believe this is currently the only EPOC16 HWIM (Psion's OO graphics library) app whose source code has been released.
If you're following along at home, the code is in the link below.
-
Now that the TopSpeed TechKit with its #assembler is out in the world, I'm considering porting the #TASM and #MASM code in one or two of the open source #EPOC16 apps over to TSASM.
Hardly an urgent project, but it would mean that the apps could be built with one #compiler ecosystem with a single project file.
Of course, the code would still be restricted to the #16bit #DOS world, but it's no worse off than we already are in #Psion land.
-
Now that the TopSpeed TechKit with its #assembler is out in the world, I'm considering porting the #TASM and #MASM code in one or two of the open source #EPOC16 apps over to TSASM.
Hardly an urgent project, but it would mean that the apps could be built with one #compiler ecosystem with a single project file.
Of course, the code would still be restricted to the #16bit #DOS world, but it's no worse off than we already are in #Psion land.
-
Now that the TopSpeed TechKit with its #assembler is out in the world, I'm considering porting the #TASM and #MASM code in one or two of the open source #EPOC16 apps over to TSASM.
Hardly an urgent project, but it would mean that the apps could be built with one #compiler ecosystem with a single project file.
Of course, the code would still be restricted to the #16bit #DOS world, but it's no worse off than we already are in #Psion land.
-
Now that the TopSpeed TechKit with its #assembler is out in the world, I'm considering porting the #TASM and #MASM code in one or two of the open source #EPOC16 apps over to TSASM.
Hardly an urgent project, but it would mean that the apps could be built with one #compiler ecosystem with a single project file.
Of course, the code would still be restricted to the #16bit #DOS world, but it's no worse off than we already are in #Psion land.
-
Wrote up a summary of the past year on Hackaday IO (@hackaday) because it was rattling around in my brain.
OK, *now* I'm going to rest.
#psion #retrocomputing #EDisAsm #sibolib #mame #PsiDrive #epoc16 #pda #vintagecomputing #retrodev #retrospective
-
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.
-
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.
-
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.
-
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.
-
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.