Since I built up the single PCB, I have started testing the hardware. Of course, the hardware on this project is useless unless it has software to make it do something. I first noticed that the 8052AH, which I am using until the AT89S52’s arrive, was running a bit warmer than I thought it should. After probing the 74HC573’s “D” inputs and “Q” outputs, I could see that there was no activity on the “Q” outputs and that the 74HC573 was also getting a bit hot. From memory, I knew that the ‘HC373 and HC573 were functionally compatible BUT upon comparing pinouts, I saw that they were not pin-compatible (refer to images below). I replaced the ‘HC573 with an ‘HC 373 and the “Q” outputs all started working. First problem solved. I must have used the ‘HC373 footprint and decided to use the ‘HC573 part without verifying complete compatibility. I would rather have used the ‘HC573 as it has a pinout that has the data inputs on one side and the “Q” outputs on the other, better suited for “bus” designs than the ‘HC373’s pinout.
I then started to focus on the software portion of the project, using the 28C256 I have on hand in place of the 28C64’s the PCB was laid out for. Using a bit of KYNAR wire, I added the A13 connection from pin 26, which is a “no connect” on the 28C64. Since pin 1 is the READY pin on the 28C64, it is connected to the 8052AH’s INT0 line, which has a 100KΩ pull-up to Vcc, essentially pulling A14 on the 28C256 high, which isn’t a problem. When programming the 28C256, I use an offset of 0x4000 so that it effectively maps in at 0x0000 for the 8052AH.
I first tried to use the standard build for the MCS-51 BASIC interpreter, which did not work. I then tried to use Paul Stroffgen’s “paulmon2” mapped for ROM at 0x0000 (PROGSPACE) and RAM at 0x8000 (dataspace) and still nothing. I then decided to write a simple port-toggle routine to see if the program code was even being read properly. I had already installed ATMEL’s AT89L IDE but it does not directly support the At89C/S52 parts. I was able to get by with using a different part that had the same port definitions. That port-toggling routine DID work, so I know that program ROM is being read and that the 8052AH is able to execute the code properly. I then wrote a simple routine to initialize the on-chip UART, receive a character and then echo it back and that did not work. In testing the code on the ATMEL simulator, I could see that the registers were being set properly but I am not able to modify any register contents in the simulator, so testing the UART code in the simulator produces little forward movement in tracking down the issue. I found the lack of register modifications in the AT89L IDE to be very odd since the last release date of this software was 2012 and I have been using the AVR SUDIO series for well over 15 years and was always able to modify registers, ports, data and eeprom while simulating a program. I guess there were different development teams that never compared notes and features on their respective projects?
I’m still a little torn between which IDE to use for software development but I already have the “lite” version of the KEIL MDK for the ARM series. KEIL does allow the download of a “lite” version of the “C51” development tools for free but the current download image does not execute under Windows-XP®, which I am running as a virtual-machine under Linux. I have a support request in to KEIL, so I’ll wait to see what they have to say. I suppose ultimately, I could use the Linux “WINDOWS®” emulator (wine) to run the WINDOWS® version of the C51 assembler and “C” compiler from the Linux shell. I already do that with the AttoBASIC project to build the various “flavours”.
Meanwhile, I changed the address decoder PLD equations to ignore the 8052AH’s EA pin setting so that the ROM always maps in at 0x0000 to 0x7FFF in PROGSPACE and the RAM maps into 0x8000 to 0xFFFF in DATASPACE. I don’t see anything wrong with my previous PLD equations that swap address spaces between EEPROM and RAM depending on the EA pin’s state but I wanted to step back a bit just to simplify for trouble-shooting purposes.
At this point, I am going to break out the logic analyzer and grab the data, control and a few address lines to see if I can trace the code fetches from a RESET condition.
A few points to add:
- It has been a number of decades since I programmed the 8051 and it’s derivatives. I had forgotten how weird the I/O register usage is. Especially the “quasi-bidirectional” I/O pins, which have an open-drain output. Essentially, a “low” output is a “hard tug” to ground via an N-MOSFET junction and a “high” output is a “soft tug” to Vcc via an internal pull-up resistor (to Vcc).
- Having spent so much time in the last few decades using the AVR and the development tools for code development (AVR STUDIO) and debugging (AVR DRAGON), I find it very impossible to “see” what is going on “inside” the 8052AH, which is why any one serious about 8051/52 code development usually shelled out the $$$ for a hardware emulator, which were typically in the several US$1000’s range. I know debugging code on the Z80 project will be the same and that’s why I want to implement a “shadow register” feature for code debugging on the Z80 project. Is that a complaint? Sort of… It makes me appreciate just how far the industry has come in terms of simplifying and cost-reducing the easing the software developer’s part in debugging code. Of course, finer resolution lithography and die reduction has enabled many more hardware functional blocks to fit on the same size die as these older parts, including “on-chip debuggers”.