Retro Dev Tools

Hello, just getting back into the CE dev scene. I did some work on Symbol and Falcon scanners back in the day. Recently I managed to score an HP 320LX so I figured I would mess with it again..... with a twist. A bit back I started playing with writing my own dev tools, from scratch. I started with an assembler and 6502. I was going to work my way up the chain (Z80, etc) but then jumped up to playing with ARM and Thumb as I wanted to compile direct for a Raspberry Pi Pico. I picked up the 320LX as it seemed like an easy way to test getting an SH3 assembler stood up. I had the ELF code started for the Pi and the EF2 code started for the Nano, I figure the PE code for EXEs and DLLs is not that far off.

This is mostly for fun. I do think it would be fun to have a way to cut code for older systems in a 'timeless' tool. I started this in Java and I'm playing with an IDE of sorts in Swing. If .Net Core ever gets serious about cross platform GUI I may port some stuff over there. Good to see there is still a crowd out here playing with this stuff. Is anyone else here mucking at the lower levels of the stack on this stuff?

Hi cgallaty,

That's some very cool stuff you're doing there. Lower level than I dare tread, but very impressive none the less. Are you publishing work-in progress to GitHub for others to check out what you are doing?

Trying to figure out how I want to slice all that. Originally it was all for fun. Then I went to pull down the dev tools for the Raspberry Pi Pico. To do development on a Raspberry Pi proper they wanted a 2GB download of tools. Then, the default "Hello World" build resulted in a whopping 40K UF2 file. (?!?) I did some poking and looked at the bare metal version of it and was able to get the same demo down to 512 bytes (Which is technically bigger than it needs to be, but the smallest block size for the file format.)

I've played with other things like Raspberry Pi Zero. The ELF files generated by the stock tools have a lot of noise in them. Some of it is just symbol tables and the like that you can work out, but there is also just a lot of sloppy stuff from the multiple layers of abstraction. I realized that some of the stuff that I was doing could likely turn into a general platform for IoT for current platforms. Pondering if I could use turning it into a real tool set for more modern stuff to subsidize working on the older stuff. (Sell an IoT tool that also has 'vintage' modules)

That said, I know for a fact that there is a lot of CE equipment still in the field. Symbol scanners are built tough and there are likely a number of IT shops still suffering old tools. Not to mention all the hardware I find laying around for cents on a dollar that is only 'scrap' because folks can't be arsed to support them anymore.

A general purpose assembler was always on my bucket list. If enough folks where interested in playing with it, I could see starting a few general retro themed repos for the port to .Net Core. Getting back into it, I'm curious (short of the obvious) what gaps still exist.

Most of this is just 'information' i.e. the right scan of a given older bit of hardware could yield a set of data files that could be used by a tool chain to generate code. Seas of header files are an arcane way of thinking of the issue when you could likely merge some of the information in with the technical bits. Companies have tended to develop tool chains like rockets used to be built... i.e. You build a new one for each effort, and then throw it away. It's depressing that Microsoft itself has taken so long to embrace going pure .Net with tools. There is zero reason that they don't have just modules that you can pull into VS that still support any chipset. That and with both .Net and Java in existence, the notion that an app can ever get 'outdated' is just funny. Java is the new COBOL, Swing is slated to be supported until 2030 and I promise you someone will likely pick up the mantle after that. That I can't just drop something on my current Windows 10, or MacOS daily drivers is just silly.

I would argue that even GCC has sort of dropped the ball some on this. My vision is a stock base system, it can be centered around a build core or an IDE, likely both. A platform is broken down into its base components and a 'store' of sorts is created to host the modules. So if you want to say start an effort for a Pocket PC handheld there is likely a CPU core (or cores) for the base machine code bits. There is a container for packaging (PE building, CAB generation) that for that platform, and then there is some OS layer support, and finally an outside 'wrapper' that is really just specialized project types so you can easily just select a build target for what you are doing.

I've gotten down to the bits on a ton of platforms. I've written tools to generate PDBs for Palms, EF2, ELF, going to be committing to getting the Windows stack going. If done right, it's a lot of work, but oddly a lot less than it sounds. After a few prototypes and attempts on the assembler, I'm leaning towards a core that would actually treat the instruction sets as data, so that supporting a new chip variant would be as easy as just defining the chip in a way it can understand. This would also allow for the system to 'evolve' without the earlier stuff lagging. Case in point, my shallow 6502 module was good enough to crank out Commodore 64 runnable code, but dealing with the ARM chipset and its flavors expanded how the core needs to work, etc.

It's a lot of fun, but I'm still looking for what the 'tipping point' is where it is anything more than an academic curiosity. Lots of learning to be done. If the community has any utilities or smaller scope things that are needed let me know. Back in the day I started a project for the Palm called Pocket Knife which was just a geeky collection of tools to use on the device for development. Remembering as I get to a bare CE device how maddening it is to not even be able to copy a ROM based app to a CF card to rip it apart and see what makes it tick. I figure I'll start trying to get to 'Hello World' with my tool chain and in parallel start poking around an old tool chain. I actually have Visual Studio 2005 laying around that I had bought back in the day to mess with Pocket PC. I guess I'll be dusting that all off in a VM again.

Glad to have found this site. Mainly looking for a crowd as mad as I am to be dusting this stuff off at this point.

Well there is definitely room for someone to figure out a way to reliably and consistently copy files from ROM down to disk. The request comes up frequently and apart from a few ARM/XScale full ROM image dump tools, I've yet to see something that can binary read from the XIP back into the file system and produce a working copy.

It's a very intriguing project and you make it sound so easy - which of course it isn't, but I'm certain we will help in any way that we can.

The thing to keep in mind is that a PE, whether it's an EXE or a DLL is really (for the most part) just a frozen chunk of RAM. When they are loaded, the sections are really just sort of exploded into the RAM section by section. In the 'old times' of handheld devices, all there was was RAM, some of it acting like storage. And ROM is just not writable. So in theory the foot work is finding the header of whatever it is, and then trying to pull all the sections into a discreet file. i.e. it's likely not just a 'copy' in the sense of the image being in there somewhere, it's potentially more scattered. That said if you have full access to RAM on older Windows systems you can go out and find the blocks in RAM while the program is running. (i.e. even if for some reason you could not get directly at the ROM you could still get at the bits)

Once you get into it, its actually rather fun to play with, but yes, a bit esoteric. I've been using Wayback to dig up old MSDN (and earlier) articles out there. Lots of good reads, but at this point the stuff has been scattered to the winds. To make things more 'interesting' some of the MS stuff was brought over by DEC folks from VAX/VMS. I'm trying to save out PDFs of some of the articles I'm finding, but it would be even better to capture some of it in a working tool that is not going to 'expire'. I think with CE et all we are at a critical point where some of this could just be lost. This was the start of the internet itself that this was all created and sadly the Internet is not aging well.

I wholeheartedly agree with you on the rapidly dissolving state of CE documentation and archival. Most of the low level knowledge is long gone from public gaze. they're veritable black boxes - though mainly this was by design because of Microsoft's increasingly secretive and paranoid approach to CE as it evolved.

The issue with H/PC ROM dumping is that everything executes in place (XIP), so the ROM map is abstracted from the operating system with a layer of middleware. Most - in fact all dump tools that I am aware of - have gone for a read of the entire ROM rather than trying to reconstitute the file system in-place. As there was no standard hardware interface for ROM chips, the idea of building bespoke tooling to electronically dump chips (that couldn't be flashed back) was a non-starter. Couple the fact that Microsoft made, hid and the rapidly abandoned the platform generation tools in quick succession as they changed their minds about was CE was prior to CE 3. It's really no surprise that there is next to no information out there.

Part of why I'm getting into all this. It's like a crime scene investigation where you have cues, but you have to piece all the bits back together. Down to cheating and ripping open existing drivers to learn how to talk to the hardware installed. I'm one of those odd folks that seems to like digging though hexdumps.

Careful, you just called me normal. Just because I glaze over at the though of looking as ASM and hex dumps, doesn't make me a normal, functional human being

C'mon, C:\Amie, we know you're just a folder in a hard drive.

Na, that's not true. I'm a folder on a USB drive lost and long forgotten at the bottom of a drawer