ZEPROM Programmer: Software Bug?

[Ángel Martin]

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?

[J-F Garnier]

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...

[Ángel Martin]

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:


AB3A    130    LDI S&X    010
AB3B    010    CON:    
AB3C    270    RAMSLCT    
AB3D    198    C=M ALL    
AB3E    1B1    ?NC XQ    2C6C ??
AB3F    0B0    ->2C6C    
AB40    149    ?NC XQ    
AB41    024    ->0952    [ENCP00]
AB42    198    C=M ALL      
AB43    35C    PT=  12

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!