This is a bit long, but I feel the need to explain what I'm up to a bit, as there isn't a very large community of people modding 30 year old GPS receivers...
I have a weird hobby of ressurecting old GPS receivers that have been kneecapped by a design flaw in the GPS signal. The original GPS system communicates the current time using a curious system of a 10 bit week number combined with a 19 bit "time of week" number in units of 1.5 seconds. The 10 bit week value means that the system rolls over every 1024 weeks, or roughly every 19.6 years. The first roll-over was in 1999, the second in 2019. Most consumer GPS receivers seem to have no problem with this; if the week number is stored between uses, then when the week number rolls over and the receiver can see that the received week number is less than the previously received week number, it knows that a rollover has occurred and can correct accordingly.
For some reason the folks that made dual channel GPS receivers designed for use by land surveyors and geodetic surveyors (receivers that cost over $10,000 when new) couldn't comprehend the week number roll-over. Their receivers wouldstart reporting dates from the past when a rollover ocurred. Because the 1999 rollover occurred relatively early in the life of civilian GPS use, the makers released firmware updates to compensate week number roll-over (WNRO). But by the time the 2019 rollover happened, many of those receivers had long been end-of-life'd so no fix was made available.
Wanting to play around with a dual frequency GPS receiver, I had bought an old Trimble 4000SSi receiver made in 1996, and it suffered from the WNRO problem. After some effort spent reverse engineering the Motorola MC68332 firmware, I found where the 1999 WNRO fix had been applied. The fix was incredibly simple: 1024 was added to the week number after it had been received from a satellite. They wrote robust date parsing code that could handle week number values greater than 1023. To compensate for the 2019 rollover, I changed the 1024 (0x400) to 2048 (0x800). After figuring out how to re-checksum the firmware and upload it back to the receiver, I had a working 2 channel survey grade receiver.
Then I got curious. I bought an older receiver, a Trimble 4000ST from 1989. This receiver had a similar archicture to the SSi, but was based on the MC68000 and used different firmware. Now knowing what to look for, I quickly found some form of an ADD with an immediate value of 0x400. I changed it to 0x800, and the receiver was fixed.
Encouraged by my success, I went on a quest to find the oldest Trimble receiver I could lay my hands on. I ended up with a Trimble 4000SX from 1986. This thing is a rack mounted monstrosity with a beautiful brushed aluminum finish, but notoriously non-portable for its land surveyor users. I thought it would be easy. An older receiver would have simpler firmware, right?
When it arrived, I excitedly opened the case, extracted the 6 EPROMs and dumped them. To make my job even easier, the base address of each EPROM was silk-screened right there on the PCB. No guesswork needed! I was so excited. I merged the dumps into a single file and loaded it up in Ghidra... where I quickly discovered that the majority of the code in the EPROMs was not valid 68k machine code. In the lowest-address pair of EPROMs I found some valid code, but it clearly wasn't enough for a whole GPS receiver. I found strings in the other ROMs, but I couldn't find any code pointing to the strings.
So I set to work reverse engineering what I could, and soon learned that the majority of the functionality of the receiver has been implemented in a stack based virtual machine. It's similar to many UCSD P-code systems; the lower numbered op-codes are all different forms of immediate loads, followed by basic arithmetic and logic instructions, load/store, and flow control instructions. But none of the opcodes match anything I can find for an known P-code implementation. There is no copyright that identifies the origin of the virtual machine. I can't tell if Trimble used an off-the-shelf commercial Pascal implementation, or if this is some kind of Forth VM, or if Trimble rolled their own VM. I have reverse engineered the majority of the instruction set, and have even written a disassembler that successfully disassembles the entire program of the receiver. I'm still unclear on many of the load/store instructions, as the addressing mode used by the VM is complicated, but their structure is obvious, so the disassembler can disassemble them as known unknowns.
So, if you're still here after reading all of that: what off-the-shelf virtual machine could this receiver have been running? If it was an off-the-shelf solution, who were the players in the market in the mid-80s? Trimble's GPS division was actually acquired from HP, and their later receivers show latent evidence of having been developed using a HP64000 development system, so it wouldn't be a leap to imagine that their earlier receivers used similar tooling. I can't find any clues of a P-code based language coming out of HP, though.
Here's my documentation of the opcodes that I've revere engineered so far: http://beefchicken.com/gps/trimble/4000/sxdeepdive/virtualmachine
I'm fairly confident that I even know who wrote this code. Javad Ashjaee, past employee of Trimble and founder of Javad GNSS, self-described himself as the guy that wrote the code for Trimble's earliest receiver. Unfortunately he passed away in 2020. I would have loved to have discussed this with him!
Anyway, brain dump complete. Any ideas?
- Keelan
[edit] My current disassembly listing, for the curious: http://beefchicken.com/gps/trimble/4000/sxdeepdive/disassembly.txt
I have a weird hobby of ressurecting old GPS receivers that have been kneecapped by a design flaw in the GPS signal. The original GPS system communicates the current time using a curious system of a 10 bit week number combined with a 19 bit "time of week" number in units of 1.5 seconds. The 10 bit week value means that the system rolls over every 1024 weeks, or roughly every 19.6 years. The first roll-over was in 1999, the second in 2019. Most consumer GPS receivers seem to have no problem with this; if the week number is stored between uses, then when the week number rolls over and the receiver can see that the received week number is less than the previously received week number, it knows that a rollover has occurred and can correct accordingly.
For some reason the folks that made dual channel GPS receivers designed for use by land surveyors and geodetic surveyors (receivers that cost over $10,000 when new) couldn't comprehend the week number roll-over. Their receivers wouldstart reporting dates from the past when a rollover ocurred. Because the 1999 rollover occurred relatively early in the life of civilian GPS use, the makers released firmware updates to compensate week number roll-over (WNRO). But by the time the 2019 rollover happened, many of those receivers had long been end-of-life'd so no fix was made available.
Wanting to play around with a dual frequency GPS receiver, I had bought an old Trimble 4000SSi receiver made in 1996, and it suffered from the WNRO problem. After some effort spent reverse engineering the Motorola MC68332 firmware, I found where the 1999 WNRO fix had been applied. The fix was incredibly simple: 1024 was added to the week number after it had been received from a satellite. They wrote robust date parsing code that could handle week number values greater than 1023. To compensate for the 2019 rollover, I changed the 1024 (0x400) to 2048 (0x800). After figuring out how to re-checksum the firmware and upload it back to the receiver, I had a working 2 channel survey grade receiver.
Then I got curious. I bought an older receiver, a Trimble 4000ST from 1989. This receiver had a similar archicture to the SSi, but was based on the MC68000 and used different firmware. Now knowing what to look for, I quickly found some form of an ADD with an immediate value of 0x400. I changed it to 0x800, and the receiver was fixed.
Encouraged by my success, I went on a quest to find the oldest Trimble receiver I could lay my hands on. I ended up with a Trimble 4000SX from 1986. This thing is a rack mounted monstrosity with a beautiful brushed aluminum finish, but notoriously non-portable for its land surveyor users. I thought it would be easy. An older receiver would have simpler firmware, right?
When it arrived, I excitedly opened the case, extracted the 6 EPROMs and dumped them. To make my job even easier, the base address of each EPROM was silk-screened right there on the PCB. No guesswork needed! I was so excited. I merged the dumps into a single file and loaded it up in Ghidra... where I quickly discovered that the majority of the code in the EPROMs was not valid 68k machine code. In the lowest-address pair of EPROMs I found some valid code, but it clearly wasn't enough for a whole GPS receiver. I found strings in the other ROMs, but I couldn't find any code pointing to the strings.
So I set to work reverse engineering what I could, and soon learned that the majority of the functionality of the receiver has been implemented in a stack based virtual machine. It's similar to many UCSD P-code systems; the lower numbered op-codes are all different forms of immediate loads, followed by basic arithmetic and logic instructions, load/store, and flow control instructions. But none of the opcodes match anything I can find for an known P-code implementation. There is no copyright that identifies the origin of the virtual machine. I can't tell if Trimble used an off-the-shelf commercial Pascal implementation, or if this is some kind of Forth VM, or if Trimble rolled their own VM. I have reverse engineered the majority of the instruction set, and have even written a disassembler that successfully disassembles the entire program of the receiver. I'm still unclear on many of the load/store instructions, as the addressing mode used by the VM is complicated, but their structure is obvious, so the disassembler can disassemble them as known unknowns.
So, if you're still here after reading all of that: what off-the-shelf virtual machine could this receiver have been running? If it was an off-the-shelf solution, who were the players in the market in the mid-80s? Trimble's GPS division was actually acquired from HP, and their later receivers show latent evidence of having been developed using a HP64000 development system, so it wouldn't be a leap to imagine that their earlier receivers used similar tooling. I can't find any clues of a P-code based language coming out of HP, though.
Here's my documentation of the opcodes that I've revere engineered so far: http://beefchicken.com/gps/trimble/4000/sxdeepdive/virtualmachine
I'm fairly confident that I even know who wrote this code. Javad Ashjaee, past employee of Trimble and founder of Javad GNSS, self-described himself as the guy that wrote the code for Trimble's earliest receiver. Unfortunately he passed away in 2020. I would have loved to have discussed this with him!
Anyway, brain dump complete. Any ideas?
- Keelan
[edit] My current disassembly listing, for the curious: http://beefchicken.com/gps/trimble/4000/sxdeepdive/disassembly.txt
Attachments
Last edited: