ZEPROM Programmer: Software Bug? - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html) +--- Forum: General Forum (/forum-4.html) +--- Thread: ZEPROM Programmer: Software Bug? (/thread-709.html) |
ZEPROM Programmer: Software Bug? - Ángel Martin - 02-18-2014 02:35 PM Hi folks, admittedly not a very frequently asked subject but nonetheless there may be some interest out there... For a while I've been experiencing some glitches programming ZEPROMS using the ZVC device. I sort of assumed the device wasn't doing its job due to age but in looking at the Zeprom programmer's code I noticed a couple of potential bugs. The one with most dubious results is a call at addresses 0xp3BE and 3BF to the mainframe location 0x2C6C. That particular destination is in the middle of a LDI S&X instruction, thus not a good choice. Worse yet, the second half of said instruction is actually 040 WROM (when executed stand-alone) so I reckon it's got to opportunity to wreck things up during the EPROM burning job... Has anybody run into this before? Maybe there was an updated version that corrected this problem.. . if you know, pls. let me know. Cheers, ÁM PS. does anybody know of any ZEPROM-based module that used bank-switching for user code (i.e. FOCAL) programs? RE: ZEPROM Programmer: Software Bug? - J-F Garnier - 02-19-2014 02:40 PM Hi Angel, This seems intentional, according to the Zeprom programmer's manual, p92 (see attachment). Which ROM are you using? I don't see the call to the system ROM at x3BE in my image of the "-PROGRAMMER" ROM (ROM signature is I9-G#, checksum=29F). Your PS: I don't know a user code program that uses bank switching on the Zeprom, but I know a large one on the RAM-box which does... RE: ZEPROM Programmer: Software Bug? - Ángel Martin - 02-20-2014 07:02 AM Hi J-F, sorry it was a dyslexia-induced typo, I meant at addresses 0xpB3E and B3F. I have attached the "blueprint" pdf for you to see. I have the same ROM image, BTW. Code:
Re. your comments about being intended: I guess you're referring to the fact that the ZEPROMs handle bank-switching in a slightly different manner, because they don't revert to the main bank unless there is an explicit ENBNK1 instruction ordering so. This may also be the system used by the original HEPAX, Advantage and RAMBOX - but it contrasts with the CL implementation, and possibly also the Clonix/NoVo and MLDL2k - in that in those the primary bank is restored upon light sleep. Easier on the programmer but more restrictive - for instance, no FOCAL code can be used on secondary banks. Thanks for replying! |