• Please review our updated Terms and Rules here

AT2XT keyboard converter

I was using the official XGecu software 12.66A (latest) from here: http://www.xgecu.com/en/download.html (The T48 is a chinese programmer for a lot of EEPROMs, PICs an others; very common, usually works well). The HEX file from the AT2XT contained 0x3FD4 for the configuration word.
This value should not enable any protection, according to this: https://gputils.sourceforge.io/html-help/PIC12F629-conf.html

Also, whats confusing: The programming specification says "The ID locations and the configuration word read out in an unprotected fashion", but I'm getting zeros for them as well.
 
BLUF: You probably destroyed OSCCAL and maybe a few other locations.

This was a regular problem for the 12F629/675 - Search for "destroyed osccal 12f629" or something similar and you will see many discussions and tales of woe. Essentially, you needed to save it and put it back during programming. Take a look at the datasheet page 52 in that version. Read ALL of the notes.

Eventually, Microchip software and programmers handled the situation pretty well, IMO. I went from the old PICSTART to a PICKIT3 (likely a clone) and now to a PICKIT4 and, while it was a long road, I think it is a fine programmer.

If you look at the asm listing (Version 0.94, January, 2011), the configuration bits are:

__CONFIG _MCLRE_OFF & _CP_OFF & _WDT_OFF & _INTRC_OSC_NOCLKOUT ;Internal osc.

Comparing them to your configuration word, they appear to have been handled ok by your programmer. Code Protect is not the problem.

Advise that you dig deep into your programming manual and see if there is anything about OSCCAL saving.....try something else. That's my two cents.
 
I was using the official XGecu software 12.66A (latest) from here: http://www.xgecu.com/en/download.html (The T48 is a chinese programmer for a lot of EEPROMs, PICs an others; very common, usually works well). The HEX file from the AT2XT contained 0x3FD4 for the configuration word.
This value should not enable any protection, according to this: https://gputils.sourceforge.io/html-help/PIC12F629-conf.html

Also, whats confusing: The programming specification says "The ID locations and the configuration word read out in an unprotected fashion", but I'm getting zeros for them as well.
I think xgecu has some issue with latest few update, as my T56 also had trouble with PIC12F629, but it was ok before software update.

I also have a TL866II, and it works with their latest xgpro software(v12.66) with PIC12F629. my T56 always report failed after programing PIC12F629 with this software version but same software TL866II works fine.

I know it sucks, but i would suggest you to downgrade the software to try it.
 
In post #493 of the AT2XTKB development thread, member schnurzel posted some alternative code for the AT2XTKB.
The link to that post is [here].
In the later posts of #499 and #528, other members reported that the alternative code fixed some issues.
Maybe you should try that code.
This Prince of Persia shift issue still there, i also tried #493 ver of firmware. As I just built one micro 8088 and play this game, the shift+left and shift+right just not work correctly in the game, but signal shift key works in the game.

BTW, thanks to sergey made this wonderful micro 8088, i love it.
 
I happened upon this thread when trying to program a PIC12F629 for a micro 8088 build. I ran into the same issues others are experiencing when using the XGecu T48 programmer but have some extra info to share that might be helpful.

After putting the fresh-from-mouser bare chip into the programmer and programming the .hex it seemed to work at first but failed on the verification step. All following programming attempts failed. All attempts to read from the chip returned nothing but zeros. If you disabled ID check and verification it would appear to program OK though. At first, I used software 12.57, which I setup sometime last year. I tried to install an older version of xgpro, but it looks like old version won't work if the programmer has firmware that's too new. I also tried with the latest version 12.67.

Now here's where it gets strange.

I bought an old PicKit2, installed the v2.61 software from Microchip's web page (I had trouble getting it to see the pickit 2 on my win11 system, but it fired up no problem on an old XP box), and wired up the chip on a breadboard..
The software instantly recognized the chip no problems. I performed a read and found it was not blank and appeared to be programmed. ID, oscal, everything appered to be in order. I loaded up the .hex and ran a verify, and it came back with no errors.

I plopped the chip in to the micro 8088 and the keyboard worked no problem.

So it looks like these programmers program the chip ok, but there is a bug when it comes to reading the data back? It looks like the oscal value isn't ruined and the chip functions OK. In any case old pickit2 and pickit3 programmers + some dupont leads and a breadboard are all you need to program the chips and they're pretty easy to find/cheap.

Side note: I also noticed the issue @mx450 ran in to, where shift+arrow key combinations don't seem to work. In MS DOS edit you're not able to highlight text by holding down the shift key and using arrows to move the cursor. I used firmware XTATKEY_094.HEX
 
I confirm if you attempted to program PIC12F629 with the XGecu T48 you will fail to verify it. But the chip and the XTAT FW will be OK and in work condition.
I've also verified that if you write FLASH, EEPROM, and Config of the PIC12F629 with the XGecu T48 you can verify FLASH and EEPROM. But after writing the config the XGecu T48 can't read the chip properly.
 
Back
Top