| | 92 | |
| | 93 | = Rom DUMP = |
| | 94 | |
| | 95 | With the help of an AT90USBkey a dump of the ROM was made. I don't publish it because there are some grey areas still. |
| | 96 | It looks like there is a protection system. I held the CPU in reset+halt state so it doesn't get in the way, and ran my dumping program that dumps the rom twice. The first 77 bytes are different, but the remaining part is perfectly identical. It looks like the VTech chip is jamming the memory bus during early startup. Interesting partis that the jammed version seems to make more sense (reset vector falls in ROM space, for one). |
| | 97 | |
| | 98 | I have not completely figured out the jamming algorithm. The values read do depend on the address, so it is not simple bootstrap code injection like on the Amstrad PCW. I don't know what matters, the ROM data or the address. The VTech chip is overriding ROM access. Other parts of the rom look clean, with code that makes sense and a lot of strings. But the reset vector doesn't make any sense in the non-jammed version. |
| | 99 | |
| | 100 | We will start disassembling the code by another end. If only 77 bytes are missing, we should gather enough hardware knowledge to guess them. An alternative is getting to know more about the jamming algorithm to guess the data. Or just use a powerful enough logic analyzer on a running system (my oscilloscope can't help, it's too slow !) to get the actual executed code. |
