Holiday break – Project update

Happy New Year to all readers!  2017 is the beginning of a new cycle as 2+0+1+7 = 10 or 1.

The holiday season did not bring much progress on this project nor the Z80 SBC project.  Instead, I mulled over some other things having to do with love, life, connections, path to happiness, etc.  It was inspiring … and once again, I found that the answer to the Ultimate Question of Life, the Universe, and Everything is STILL “42” as calculated by the supercomputer named “Deep Thought” over the course of 7.5 million years (… or so I have been told).

Continual intermittent oscillator failures: On the 8052 SBC project, the issue with the oscillator showed up again.  It may be temperature related or simply a faulty crystal.  I have two (2) 11.0592 MHz crystals and only a few values of capacitors (22, 27, 30 and 100 pf) on hand.  Thus, I ordered a few more values of capacitors from MOUSER.COM as I did not wish to wait 4 weeks by ordering from an eBay vendor in China.

I contacted ATMEL on the subject of directly driving the GAL22V10 using the XTAL2 output and the response was “yes, you can use the XTAL1 or XTAL2 pins to drive a buffer but we suggest you do not directly drive the GAL22V10″.

I have since inserted an ON-SEMI NL17SZ17, “Non-Inverting Schmitt-Trigger Buffer”  between the AT89C52’s XTAL2 pin and the GAL22V10 CLK pin but it did not resolve the intermittent oscillator failure problem.  I then switched to a 16 MHz  crystal using 27 pf loading capacitors and found the oscillator to be VERY stable.  In 20 to 30 repeated presses of the hardware reset button, which ALWAYS failed using the 11.0592 MHz crystal, the oscillator remained operational without even a single interruption. However, with the new crystal frequency, neither PAULMON2 nor the MCS-52 BASIC functioned.  I didn’t even receive garbage characters on the serial port, which would indicate a baud-rate mismatch.  I thought that the MCS-52 BASIC was supposed to auto-detect the baud-rate and the version 1.31 had support for 805x MCU’s running up to 40 MHz.  I have not yet checked the code to see if there is a culprit hidden within.  I do not think it is a RAM access timing issue because the RAM is static and rated for 15 nS cycle times (66 MHz) but the EEPROM is rated for 150 nS access time (6.66 MHz).  I need to look at the AT89C52’s timing diagrams to see where the upper limit of the RAM/ROM interface speed lies.

The good news is that the oscillator is stable at 16 MHz.  It is possible that these 11.0592 MHz crystals need larger loading capacitors than 30 pf or that they are “3rd overtone” types, which require a smaller set of loading capacitors than I have on-hand.  Since the ATMEL AT89C52 will run at 24 MHz, I am planning to use either a 16 MHz or 20 MHz crystal for the oscillator (barring any RAM/ROM access speed limits) and modify code if necessary.

Differences between AT89C52 and AT89S52 devices:  I previously wrote about my experiences with acquiring some AT89S52’s from an Chinese eBay vendor.  I ended up ordering a set of AT89C52’s instead because the 1st vendor never sent them.  The AT89C52’s came in a few weeks ago and I have been using one for this project.  I have a TL-866CS programmer, which works great with the AT89C52 in parallel programming mode.  I knew that the AT89S52 was In-System-Programmable and from what I recalled, so was the AT89C52, as the datasheet had stated, thus I had added a 6-pin ISP connector to the 8052 SBC for just that purpose.  Although, I knew that avrdude did not directly support the AT89 series of MCU’s but others had added support via a patch. I had also found s51dude, which uses the USBtinyISP programmer with a modified firmware.  The main difference between the AT89 series and the AVR8 series is that the AVR’s use an active-low reset while the 805x series uses an active-high reset.   Since I had two (2) sources for the RESET signal, I had fed the RST pin of the ISP header and the hardware reset switch to the GAL22V10, which feeds the the AT89C52’s RESET pin.  If need be, I could invert the ISP’s RESET state and hopefully solve the ISP RESET polarity difference but upon testing, I could not get the AT89C52 to respond.  As a matter of fact, the MISO pin showed no activity at all.  Upon another glance at the AT89C52’s datasheet, it seems that the AT89C52 IS in-system programmable BUT there is no direct reference to how to do so in the datasheet.  In researching more on this topic, I found the appropriate information in ATMEL’s “Design Guide for Atmel C51 Standard Devices.pdf“.  The AT89C52 is ISP but the PSEN pin must be held low during RESET, which activates the DFU boot-loader on the serial port.  Hmmm …. not what I had recalled when I glanced over the AT89C52 datasheet and certainly NOT what I had intended on the board.  Still, the part works fine for my testing purposes and I did order more of the AT89S52’s, so I will test the ISP capability using the MISO/MOSI pins when those parts arrive in a few weeks.

• Vintage Computer