• Please review our updated Terms and Rules here

80 Trainer project...

alank2

Veteran Member
Joined
Aug 3, 2016
Messages
2,264
Location
USA
It isn't CP/M related directly, but Intel 8080 related, so if it needs to be moved to another forum, I understand.

Here is the project I've been working on lately, a lot is done, but there is a lot to still do. I thought I'd share it with you guys in case you have any ideas that I haven't had.

The general goal of this project is to be a microprocessor trainer for the Intel 8080. It will also support the 8085, and I'd really like to add the 4004/4040/8008 maybe if that ever happens. Like other trainers, it will allow you to enter opcodes, step through code, check registers, set breakpoints, etc. It does not seek to emulate any particular trainer like the SDK-80 or SDK-85. There are lots of differences between its approach and how those were designed including that the control panel and interface are outside of the emulated CPU.

I've been working on the first PCB for it (I'll attach a picture). I haven't ordered the PCB's yet, so if you see something I can improve on, please let me know. Probably going to order pcb's in a week or so - it will b nice to be working on actual hardware and off of the breadboards I've been working on with wires all over the place. I'll start by describing the PCB - for connections it has two RS232 serial ports (9 pin), an IO port (16 I/O pins), an expansion i2c header, and a DC barrel jack for 5VDC. Also on board there is a slide power switch, 24 Cherry MX keyswitches, 3 dual 7 segment displays, Piezo, two EEPROM sockets, and an RTC/backup battery. I've tried to style the PCB like an old trainer board would be by using mitered circular traces to try to make them look a bit more hand drawn, some areas of it look better than others. I didn't want a total departure from 90/45 degree traces. The whole thing will be run by an ATMEGA1284P which has 16K SRAM and 128K flash. I'm using every pin on it so there are no spares. It is really meant for a 5V DC power in connection, but it will work down to 2.5V with a very dim display. I'll probably leave the brown out voltage at 1.8V to allow this in case someone wants to run it on 3 alkaline cells. It has a ground plane on the bottom, but I don't have one one top except for the RTC crystal area. I'll probably make a lower cost tactile switch version as well (switches+keycaps cost $36!). I opted not to use diodes in the keypad, but to deal with ghosting/masking I only allow two keys to be pressed at any given time anyway. I've worked carefully on the code that processes keys so it should allow for quick entry with good debouncing. There is no hardware handshaking on the serial ports (I ran out of pins with only a 40 pin AVR), but it will support software handshaking outside of the emulation level. The i2c expansion header could open up a whole world of more connectivity or devices. You can add 7 more IO expanders (16 pins each), 2 more EEPROM "drives", etc.

The 16K SRAM limit means it will not be running CP/M. I'm hoping to make 15K of that available for emulation leaving 1K for the AVR to use. For the 8080/8085 this will be mapped to 0x0000-0x3bff. I probably won't use all of the 128K flash for code, so some of it perhaps 32K can be set aside for being mapped as ROM into another area such as 0x8000-0xffff. It will have a bootloader that can update the firmware or the mapped ROM area via XMODEM CRC. The RTC has 64 bytes of battery backed up SRAM that I will probably make available as a virtual i2c device. There will be a in/out style function call that initiates an i2c transaction with any of the i2c hardware that could then be used to read or write bytes to the RTC, IO expander, EEPROMs, etc.

The keys picture below gives a hint of how the UI/control panel might work, but the user will be able to load or save chunks of memory to/from EEPROM. I originally was going to just try to carve up a 128K EEPROM into 15K slots, but giving only 8 "files" essentially would be a bit limiting as the user will likely be saving smaller chunks of memory, so I wrote an 8 bit FAT filesystem for it. Essentially it has a 1 byte filename which can be 00-FF so now you can save and load many different chunks of data by "name". There will be an in/out interface for the file system as well so the user can access an i2c EEPROM as a block device or a filesystem device.

The AVR will run at 18.432MHz, and my 8080 C emulation code clocks in somewhere around 2MHz-2.4MHz emulated speed depending on whether I dedicate some registers to it or not.

I really wanted it to be able to be fully used without any other hardware which is why it has the built in keypad and displays. Those could be cumbersome to work on, so the user could use the second serial port instead. Keys will be mapped to the internal keypad so the external control panel and internal one will operate in sync with each other. It would also be able to load/save via Intel Hex or XMODEM CRC. One difference is that the external one can output more data such as all the registers while stepping, etc. The user code can also override the control panel display to display what it wants to or use the control panel keypad for entry (while running).

I've already run Altair 4K and 8K basic and thanks member smp sending me the source for these I may be able to add a load/save command for the FAT8 EEPROM's which would be cool. I'd also like to have some other tools/utilities for it such as emulated CPU exercisers, etc. I'm going to try to expose as many of the AVR's resources as I can such as a 16 bit timer, piezo control, watchdog jitter based RNG, etc.

Like all projects it is huge and unwieldy, but I'm going to start with the minimum and then try to add more stuff to it as I have time! If you guys have any ideas on how to do something better or perhaps more in line with how trainers actually worked, let me know. I see this project as sort of an educational style thing that someone can use to get close to how the hardware was and learn how to make it do things. It is sort of a hybrid crazy idea, but for years I've been trying to do a project around emulation so this is what has materialized!

80trainer.png

keys.png
 
This looks great. I've always preferred the 8080/8085 to the Z80 despite the latter's technical superiority. So it's great to see more hardware focussing on it.

Out of interest what is the 'animate' button - I remember seeing scrolling displays when the text wouldn't fit in the line width, is it for something like that?

Lorry
 
Thanks for commenting Lorry.

Animate will run a certain number of instructions per second (while updating the display) such as 8/sec. It seems like I remember someone could hold down a step button on some hardware and it would do a repeat stepping at some rate (Altair maybe?).

Since the 8080 is being emulated, I was thinking of having these "run" modes:

step will step one instruction and stop
animate will run at 8 instructions per second
trace will run at maximum speed but still update the display (and serial control panel) until stopped
run will run at maximum speed - the display is not updated and will just say "run..." until stopped (will not stop for breakpoints)

In run mode, the display could say "run..." or the program being executed can take over the display and use it to output something. If you press stop, it will go back to the control panel display/functionality. That is what the "user view" on shift-0 does, it toggles the display between the control panel display and the "user view" or whatever display the program last had.

Between the mnemonic's, I find the 8080 ones a bit easier to wrap my mind around, but maybe I need to spend more time with the Z80 ones!
 
Between the mnemonic's, I find the 8080 ones a bit easier to wrap my mind around, but maybe I need to spend more time with the Z80 ones!

There were assemblers which utilized a Z80ized 8080 mnemonic set.

TDL and DRI's Z80.lib are examples.

More at:

http://www.retrotechnology.com/restore/TDLmonitor.html
http://www.s100computers.com/Software Folder/Assembler Collection/Assembler Collection.htm
http://www.vcfed.org/forum/showthread.php?64946-Z80-Type-In-Program-Listing
 
What do you guys think of the STOP and SHIFT placement. Should I swap them so shift is in the lower left corner?
 
What do you guys think of the STOP and SHIFT placement. Should I swap them so shift is in the lower left corner?

I would probably keep the STOP key where it is to reduce the chance that it is accidentally pressed. My initial reaction was to recommend moving the STOP key to the top left, but then thinking about it, it's easy to recover from if accidentally pressed, assuming the user realizes. The SHIFT key location looks good as it's easy to reach.

However, often with these things it's only on using them that you find the most natural locations.

Best wishes


Lorry
 
PCB's arrived today - other than some scraping on the silkscreen they look good. Here are some parts on the board, but not soldered yet.

80trainer_pcb2.jpg
 
Soldered up and working. It runs Altair 8K BASIC and I can step through instructions so far, but a lot of firmware development to do.

80trainer.jpg
 
I've been reading quite a bit about the 4004, but there is quite a bit to understand about it! It seems that because of how few pins it has that it is a little bit "distributed" in that they have ROM and RAM chips also doing I/O. It also seems that there was a dual direction type of thing going on where a development environment would use one memory setup (4289 and some sort of programmable ROM) vs. just using a 4001 ROM.

Questions:

Q#1 - When the datasheet says "by metal option" so they mean that an IC was hardwired for a particular option? You could order it hardwired this way or that way for example?

Q#2 - Given the nature of my project, I'm thinking it makes sense to have the "program random access memory" be a 4K range from 000-FFF that you can use the trainer to review/modify/step/etc. Given that the data random access memory is a separate thing and not in the same address space doesn't fit so much with my project, so I am thinking of mapping the data memory to another range beginning at 1000h. This is more complicated by the fact that there are data characters, status characters, and also the I/O's. Should all those be mapped in order, or should there be an entire range for data characters, then a range for status characters, then a range for I/O's.

Q#3 - The way I plan to make the 80trainer work in 8080 mode is that there will be IN/OUT ports that can be used to access host/AVR services. For example, if you want to read or write to an i2c device, there will be a command for that. It sounds like the 4004 does it all of its I/O through 4 pins on each chip though. I do have a 16 pin I/O expander that I could virtually map these pins to, or I could try to come up with some sort of interface access like I plan to do with the 8008, but that sounds a bit complicated and unwieldy even though it would probably be more powerful.

All thoughts welcome on how it might be implemented.
 
From what I remember, the metal option created a different part number (-1 vs -2)

Trying to implement any 4004 based system without a 4289 is much more of a challenge. It is really the only way to interface standard memory devices to the 4004 multiplexed bus. Without it you would need external logic to implement what’s inside of the 4001/4002s. In the 4004 data book there was a schematic for the SIM-4 which uses discrete logic for this.

I did manage to dig up the schematics for my 4004 trainer project. I will try to get them scanned and post later today.
 
Back
Top