![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The SuperPET is a version of the Commodore PET which has been outfitted with an extra 64 kilobytes of memory and a 6809 processor. There is some nice software for it from Waterloo University in Canada (interpreters for various languages, such as Basic, Cobol, Fortran, Pascal and APL, and an 6809 assembler development system). Unfortunately, this software checks for the presence of an undocumented chip, the 6702. Since I wanted to add SuperPET emulation to VICE, something had to be done about emulating this chip.
Over the last months, several people on the cbm-hackers mailing list have helped to work on this issue. We used, over time, various approaches.
The presence of the dongle was checked by writing values to a memory location (which was part of the chip) and reading values back, and checking some complicated properties that must hold. (More about that below).
One approach was to identify the location of the dongle check routine and "disarm" it. This can be done by hooking in the emulation of the JSR opcode, and check if it happens to jump to the offending routine. If so, it doesn't actually do that, but instead just sets the registers to what they should be to "pass", and continue on. This approach is slightly complicated by the fact that there is bank switching involved (the relevant addresses may be the same but if the bank number is different, it isn't jumping to the same code) and that there are different calling methods used. There are different versions of the various language processors too, so this increases the size of the list of addresses/bank numbers to check. Nevertheless, this method works.
A more efficient approach is to patch the actual programs themselves, to simply remove the dongle check. This is also useful because there are SuperPETs in the wild that don't have their 6702 dongle chip any more. In the first SuperPET version, it was on a small separate board and may have gotten lost. At least one 6702 was destroyed for analysis by the visual6502 team. The dongle check routine can be stubbed out, but this procedure is complicated by the fact that there is a routine which checks the dongle check routine!
There were approaches from the other end too. Dave Roberts made a C version of the dongle check routine for analysis. He used a Monte-Carlo simulation to find values to return from the dongle that would pass the check. This method would simply ignore whatever was written to the chip, and simply regurgitate a fixed list when it was read. He was luckier with this than I was, since he found several working sequences, but his program gave me none at all. Therefore I tried a less random and more exhaustive search (with some branch-and-bound tricks of course) but that didn't really get anywhere.
( Read more... getting more detailed here! )
Over the last months, several people on the cbm-hackers mailing list have helped to work on this issue. We used, over time, various approaches.
The presence of the dongle was checked by writing values to a memory location (which was part of the chip) and reading values back, and checking some complicated properties that must hold. (More about that below).
One approach was to identify the location of the dongle check routine and "disarm" it. This can be done by hooking in the emulation of the JSR opcode, and check if it happens to jump to the offending routine. If so, it doesn't actually do that, but instead just sets the registers to what they should be to "pass", and continue on. This approach is slightly complicated by the fact that there is bank switching involved (the relevant addresses may be the same but if the bank number is different, it isn't jumping to the same code) and that there are different calling methods used. There are different versions of the various language processors too, so this increases the size of the list of addresses/bank numbers to check. Nevertheless, this method works.
A more efficient approach is to patch the actual programs themselves, to simply remove the dongle check. This is also useful because there are SuperPETs in the wild that don't have their 6702 dongle chip any more. In the first SuperPET version, it was on a small separate board and may have gotten lost. At least one 6702 was destroyed for analysis by the visual6502 team. The dongle check routine can be stubbed out, but this procedure is complicated by the fact that there is a routine which checks the dongle check routine!
There were approaches from the other end too. Dave Roberts made a C version of the dongle check routine for analysis. He used a Monte-Carlo simulation to find values to return from the dongle that would pass the check. This method would simply ignore whatever was written to the chip, and simply regurgitate a fixed list when it was read. He was luckier with this than I was, since he found several working sequences, but his program gave me none at all. Therefore I tried a less random and more exhaustive search (with some branch-and-bound tricks of course) but that didn't really get anywhere.
( Read more... getting more detailed here! )
