#edisasm — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #edisasm, aggregated by home.social.
-
Something quite exciting for #Psion software development. This is a video of #EDisAsm (an EPOC16 app) being compiled with TopSpeed C (a #DOS #compiler) in a Linux terminal.
emu2is a text-only x86 DOS emulator. It's not like DOSBox, which gives you a command prompt, graphics and realistic 90s clock speeds. You give it an executable - CLI or TUI - and it runs it.Why am I excited? This means that it's possible to call TopSpeed C from a script on Linux, such as a Makefile, just like any other native compiler.
Also, it's fast. It runs at the full speed of your CPU.
If you're interested in emu2, the project page is here. https://github.com/dmsc/emu2
-
To be honest, although it is a shame to have to shelve this project, it's also a relief. I've got so many other projects waiting in the wings. It's not a bad thing to have one less to worry about.
Plus it gave me an excuse to do a bit more work on #EDisAsm, which isn't a bad thing.
-
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!
-
Further investigations with #Psion ramdrive shenanigans, this time including the 3mx in MAME (which currently has 512KB). Plus some other notes on the hardware, some guesses, MAME debug tools, and a small but helpful #EDisAsm update.
512K
In this mythical device (emulated in MAME), the root of M: starts at page 07, 0xDFF0. Ramdrive filesystem blocks are 256 bytes on this machine, so smaller than normal for FAT12 (they're 512 bytes on the 2MB 3mx).
The astute among you will have noticed that page 07 is the last block in 512K RAM. From 0xDFF0, blocks for M: are added in reverse order. So the block for the first file is at 0xDEF0, then 0xDDF0, then 0xDCF0, etc etc.
This is what I'd assumed would happen with all models of the 3mx - root record at the top of RAM, then working backwards so that normal working RAM doesn't interfere with the ramdrive. But that isn't the case with the 2MB model (starting in page 08, working up from 0x4200, and probably isn't with 4MB (currently looking like page 08, working up from 0x6660, but still broken). I haven't checked with older ASIC9 devices yet (3a, 3c, Siena, Workabout 1).
Also, I got it wrong before: 512K model is 1x 4Mbit chip (256Kbit * 16 bits), not 2 chips.
ASIC9MX
According to the SDK, ASIC9 can address up to 16MB RAM. It has 4 RSEL lines (used in the ASIC9MX as chip selects), and 2 CSEL lines (upper and lower halves of the 16 bits). AFAIK, each window is 2MB (pages 0x00 to 0x1F). So how on earth does it fit in 16MB when it only has the space for 8MB? Unless it does something from 0x80 onwards? (EDIT: It does! My current guess is that it uses column 9 to switch between 00-7F and 80-FF).
Current Assumptions for 3mx
This is pages 00-7F. This is all mirrored at pages 80-FF.
- 512KB: pages 00, 08, 10 and 18 are mirrors. Then the same for {01, 09, 10, 19}, {02, 0A, 12, 1A} ... {07, 0F, 17, 1F}. Nothing but static after that.
- 1MB: same as above, then repeated for {20, 28, 30, 38}, {21, 39, 31, 39} ... {27, 2F, 37, 3F}. Nothing after that.
- 2MB: only 00-1F and that's it. No mirrors, everything above is static from floating pins. (We know this for sure.)
- 4MB: 00-3F, no mirrors, everything above is static.
I could really do with some more 3mx (or Workabout mx, which is basically the same machine in a different form factor) boards and appropriately sized RAM chips to see what they do.
EPOC16
I'm currently testing with EPOC16 4.08F. However, I have a French machine with 4.14F and a Workabout mx with 4.31F. Both of these could have bug fixes that sort the issues with more than 2MB RAM.
For all I know, it might have the same issue with 1MB (2x512K), and it's some bug with running two chips on this version of EPOC16.
If anyone has a 3mx or Workabout mx with a newer version of EPOC16 (I can tell you how to work it out) then please let me know. We could use your ROM for testing.
EDisAsm
Some slight mods, but they make a difference. Rather than use one universal bank/page number, it now uses four separate variables for the four separate banks
psel0for RAM Bank 1 (addr 0x6:0000)psel1for RAM Bank 2 (addr 0x7:0000)psel2for ROM Bank 1 (addr 0x8:0000)psel3for ROM Bank 2 (addr 0x9:0000)
(N.B.:
pselis Psion speak for "page select")You can now set these individually from the command line in EDisAsm. So I can have psel0 at RAM page 08, psel1 at RAM page 19, psel2 at ROM page 9A, and psel3 at ROM page 80.
Now when using
dbanddwto dump bytes or words to the screen, it will auto-detect which block of memory you're in and will use the correctpselaccordingly.The implementation needs a lot of tidying under the hood, but it works much better than before.
MAME
I've worked out how to dump the RAM in MAME without having to use EDisAsm. This is handy, because serial isn't implemented yet in the 3c or 3mx machines in MAME. You need to use the MAME's debug command prompt:
save asic9ram.dmp,0:asic9:asic9_ram,1000000Other tests are currently happening in MAME with different RAM sizes, but that's not my work. Stay tuned!
-
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.
-
Finally, the 4MB 3mx. I know for a fact that ASIC9(MX) can handle 32MB of memory (8x 2MB RAM, 2x 8MB ROM). All the soldering looks right to me.
There is a chance that the version of EPOC16 on the 3mx just doesn't like 4MB RAM and freaks out. But if it doesn't like it, why bother checking for it?
There are three things I can do here:
- Remove and re-solder the RAM.
- Write a memory testing routine for #EDisAsm.
- #MAME's 3mx emulation currently has broken RAM detection (it can currently only handle 512KB, emulating 2x 256KB chips). If I can fix this, I can set it to 4MB and see how EPOC16 reacts.
If EPOC16 really can't handle it, then I'd hope it wouldn't be too difficult to modify a ROM. But then comes the question of putting that ROM onto a real 3mx. And that's a whole new challenge.
EDIT: Corrected ASIC9's RAM addressing capabilities.
-
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.
-
However...
I've just used #EDisAsm to dump page 0x20 of RAM on the upgraded 3mx (left) and a regular 3mx (right).
Is that uninitialised RAM on the left? Is it a bad solder job? Is EPOC16 just not touching it?
Because ASIC9MX is definitely trying to talk to something at the 2MB mark.
I could add something to EDisAsm that writes directly to a paged-in block, then dump it afterwards. (Big disclaimer warnings would be needed for that, of course.)
-
Thought I'd have a quick look at converting the #TASM code in #EDisAsm to #TopSpeed #assembler. It would get rid of a dependency, which can't be a bad thing. And it can't be that hard, right?
Nope! Much harder than I thought! 😂
Here's a link to an excerpt from the TopSpeed Advanced Programmer's Guide (I can't find the whole thing). It has thoroughly confused me and made me realise I should just go back to my main quest.
https://clarionhub.com/t/unfinished-text-with-some-information-about-the-topspeed-assembler/517
-
So, now the MAME/Haiku project is essentially done (just waiting for my PR to be merged now), I'm thinking about what to work on next.
Outstanding #Psion projects:
- #FEFSgen (golang) to make flash SSD images
- #libsibo: add write for RAM SSDs
- #PsiDrive: add boost converter (set to ~17VDC) for writing to Flash SSDs
- Psion SDK to #AsciiDoc: SO MUCH DOCUMENTATION TO CONVERT!
- Blogging: SO MUCH DOCUMENTATION TO WRITE!
- #EDisAsm: because there's always room for more features -
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
-
Current #Psion projects in various states of unfinishedness:
- PCB for the RPi Pico SSD Drive
- Get Elvis to compile
- Upload Elvis code to GitHub
- Get Solipeg to compile
- Upload Solipeg code to GitHub
- Work out differences between SIBO SDK 2.00 and 2.10
- Try wikis for the Doc Project
- Replace Wordpress on psion.info with static site
- #EDisAsm updates and improvements
- Write *many* blog posts on the past 9 months of work
- Video on how to set up the SIBO C SDK in DOSBox -
Started to build up a framework of files to supplement the #Psion SIBO C SDK for modern compilation.
First one... A half-decent gitignore file.
https://github.com/PocketNerdIO/edisasm/blob/main/.gitignore
It would be half the length if DOSBox Staging generated lower-case files by default.
-
IT LIVES! Didn't need the source code for that game at all, just one line telling EPOC16 that the resource file is compiled into the app.
However, I have realised a fatal flaw... You can't look at the help while using the CLI. Unless you've got an excellent working memory, you'll be writing these commands down. An issue you don't have with the old text-based help system...
One that'll make you chuckle, @M0CUV!
#EDisAsm #RetroComputing #Psion #RetroDev #16bit #pda #handheld #AlwaysLearning
-
Well, that reference to Olib and the other references to HWIM, along with all the code I've seen so far, means only one thing.
Psion's proprietary object oriented C.
I've been avoiding looking at this so far, as it could require more rewriting of #EDisAsm than I really want to do right now.
Going to look for another, undocumented way.
-
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.
-
After a fair amount of pointer-wrangling, #EDisAsm can now dump SSDs to another SSD or the RAMDRIVE as a file.
Why is this useful?
1. People using #plptools can't use the `dumpssd` command because it pushes to C: over serial. This will let them pull the dump instead.
2. Peripheral ROMs (3Link/3Fax) can now be dumped! Just use `savessd c m` to save to RAM.
It's only in the Git version ATM. I'll make a proper release once I've done some cleaning up.
-
Been a little quiet recently because I've been working on a non-retro project (rootless containers, anyone?). But I could really do with a break, so I'm going to get back to some #Psion goodness later this week.
There'll be a little #EDisAsm development to add the ability to dump 3Link ROMs to another SSD. After that, I'll either looking at the USB Drive (still need to design that PCB), or I might start work on a brand new software development project. We shall see!
-
Found a way to get files on to the #MAME #Psion #SIBO #emulator without building any new tools!
#EPOC16 can read FAT volumes. So... mtools!
1. Make an empty file of, say, 2MB.
2. Use mtools to "format" it with FAT.
3. Use mtools to make directories in it and copy files into it.
4. Point MAME at the image.Mtools is available for pretty much every Linux distro. And there's a version for Win32, too: https://github.com/foone/mtools_win32/releases/tag/4.0.23
Here's #EDisAsm 0.0.5 running on an emulated 3mx.
-
Been thinking about #EDisAsm and where to take it next. The demand for the app is, after all, very small, so it's not like I have a userbase asking for features.
I want to check if some of the dumping routines are working properly, specifically for RAM bank 2 and ROM bank 1. I'd like to make the hex viewers usable on smaller screens (Siena, Workabouts). And I'd like to make some features more graphical, including adding a proper help system.
-
#EDisAsm v0.0.5 is out!
A few new features and fixes, but most importantly it now detects screen size.
This means it's no longer restricted to 3a/c/mx - most features now work properly on the #Siena, #Workabout 1 and Workabout mx!
ROM, RAM and SSD dumping are working on all #Psion ASIC9 machines.
And that dumping feature might be quite useful to people soon...
-
OK, I have no idea if I'm doing this right.
I'm trying to get the value of IO port 02h and put it into AX. So far this is what I have, based on some other code on #EDisAsm that @M0CUV wrote. My gut says that it's not right.
For full context, this is for an ASIC9-based #Psion machine (NEC V30H or V30MX, so 8086 plus a few extra opcodes). Port 02h has some info about these machines that the emulator dev needs to get info on memory mapping/addressing/mirroring.
-
OK, I have no idea if I'm doing this right.
I'm trying to get the value of IO port 02h and put it into AX. So far this is what I have, based on some other code on #EDisAsm that @M0CUV wrote. My gut says that it's not right.
For full context, this is for an ASIC9-based #Psion machine (NEC V30H or V30MX, so 8086 plus a few extra opcodes). Port 02h has some info about these machines that the emulator dev needs to get info on memory mapping/addressing/mirroring.
-
OK, I have no idea if I'm doing this right.
I'm trying to get the value of IO port 02h and put it into AX. So far this is what I have, based on some other code on #EDisAsm that @M0CUV wrote. My gut says that it's not right.
For full context, this is for an ASIC9-based #Psion machine (NEC V30H or V30MX, so 8086 plus a few extra opcodes). Port 02h has some info about these machines that the emulator dev needs to get info on memory mapping/addressing/mirroring.
-
OK, I have no idea if I'm doing this right.
I'm trying to get the value of IO port 02h and put it into AX. So far this is what I have, based on some other code on #EDisAsm that @M0CUV wrote. My gut says that it's not right.
For full context, this is for an ASIC9-based #Psion machine (NEC V30H or V30MX, so 8086 plus a few extra opcodes). Port 02h has some info about these machines that the emulator dev needs to get info on memory mapping/addressing/mirroring.
-
OK, I have no idea if I'm doing this right.
I'm trying to get the value of IO port 02h and put it into AX. So far this is what I have, based on some other code on #EDisAsm that @M0CUV wrote. My gut says that it's not right.
For full context, this is for an ASIC9-based #Psion machine (NEC V30H or V30MX, so 8086 plus a few extra opcodes). Port 02h has some info about these machines that the emulator dev needs to get info on memory mapping/addressing/mirroring.
-
I'm hoping this little bit of code that I'm going to throw into #EDisAsm is going to give me the value of IO port 0x02 on an ASIC9-based Psion. #TASM 4.1 doesn't hate it, so I just need to try running it on a real machine. But that's a tomorrow problem.
#RetroComputing #Psion #Series3a #Series3c #Series3mx #NECV30 #16bit #x86asm #assembly #oldtech #RetroDev #borland
-
I'm hoping this little bit of code that I'm going to throw into #EDisAsm is going to give me the value of IO port 0x02 on an ASIC9-based Psion. #TASM 4.1 doesn't hate it, so I just need to try running it on a real machine. But that's a tomorrow problem.
#RetroComputing #Psion #Series3a #Series3c #Series3mx #NECV30 #16bit #x86asm #assembly #oldtech #RetroDev #borland
-
I'm hoping this little bit of code that I'm going to throw into #EDisAsm is going to give me the value of IO port 0x02 on an ASIC9-based Psion. #TASM 4.1 doesn't hate it, so I just need to try running it on a real machine. But that's a tomorrow problem.
#RetroComputing #Psion #Series3a #Series3c #Series3mx #NECV30 #16bit #x86asm #assembly #oldtech #RetroDev #borland
-
I'm hoping this little bit of code that I'm going to throw into #EDisAsm is going to give me the value of IO port 0x02 on an ASIC9-based Psion. #TASM 4.1 doesn't hate it, so I just need to try running it on a real machine. But that's a tomorrow problem.
#RetroComputing #Psion #Series3a #Series3c #Series3mx #NECV30 #16bit #x86asm #assembly #oldtech #RetroDev #borland