8085 Boards

[Alan Cox]

An update on where I am with 8085 on RC2014 using Ben Chong's CPU board

I've fixed the CPU board by rewiring the \IRQ line to the 8085 INT6.5 pin instead of INTR. The INTR pin on the 8085 works the same way as Z80 IM0 (or rather Z80 IM0 works like 8080), but there is nothing to provide an instruction and there is nothing to pull the lines the right way to generate FF reliably. With the RST 6.5 pin it always jumps to 0x34 which is nice and simple to deal with. Fortunately it's not too hard to do. Bend two pins up on the 8085, wire INTR to ground (or the adjacent INT5.5 pin which is grounded), and wire the RST 6.5 pin to the output of the inverter on \INT on the bus.

I've tested a few cards so far

- CF adapter works, although curiously it is compatible with a different subset of cards than the Z80

- 32K ROM/RAM card works

- 512K/512K ROM/RAM card works

- 16550A UART works

I'm currently playing with the TMS9918A as I need something to generate timer interrupts.

The following won't fully work short of some further mods

- Z80CTC (it can only clear down an interrupt with RETI). It can still in theory be used for counting and generating square waves

- Z80PIO  (interrupt setup requires RETI, otherwise works)

The Z80SIO should work as it has a magic backdoor way to fake RETI.

The other option I am pondering is using the 8085 single GPIO output (the one intended for bitbang serial) for M1 so I can fake M1 cycles but that is a difficult board change.

Software wise I have it running a very simple boot ROM image that tests the RAM banks and loads sector 0 off CF then runs it. I've got Fuzix running on it but I've not yet brought up CP/M. ROMWBW won't work as it's full of Z80 specific instructions.

Alan

[Richard Lewis]

I don't recall the 8085 being used in any consumer PC's at the time since I think the Z80 was already dominating the scene. With builtin serial and lots of interrupt support it would make a pretty useful micro-controller.

[Sergey Kiselev]

TRS-80 Model 100 and related computers used 80C85: https://en.wikipedia.org/wiki/TRS-80_Model_100

[Richard Lewis]

Ah,I remember the model 100. My mom was doing some research work in real estate and was contemplating buying one.  Cool, I had always assumed it was some kind of Z80 given it was a radio shack product. 

[Greg Holdren]

You could use it as a serial port. :)  The SDK-85 used the serial pins for an auto baud detecting UART for the monitor. Yeah, I know that is what the serial card it for but it was slick and clever. The Intel 80C52-BASIC ROM masked chips had the same auto baud detect scheme too.

http://oldcomputers.net/intel-mcs-85.html

http://oldcomputers.net/micro-professor.html

I was contemplating the SDK-85 or the Z80 based micro professor in early 84. I chose the SDK-85 because I got an Intel employee discount. :) The 85 was fun but in some ways I wish I went with the Z80.

Greg

On Thursday, June 20, 2019 at 11:35:46 AM UTC-7, Alan Cox wrote:

An update on where I am with 8085 on RC2014 using Ben Chong's CPU board

[Alan Cox]

I was contemplating the SDK-85 or the Z80 based micro professor in early 84. I chose the SDK-85 because I got an Intel employee discount. :) The 85 was fun but in some ways I wish I went with the Z80.

The 8085 could have been a really nice CPU (actually it was) but Intel at the time chose not to document the extra 8085 instructions they added - which is a bit sad because they fixed the big gaps in the 8080 for compiled languages and some of the silly oversights (like not having a way to check if DEC of a 16bit register hit zero cleanly - something the Z80 never fixed). The 16bit data handling on the 8085 with a compiler is really nice because unlike Z80 you've got instructions to set DE = HL + immediate and DE = SP + immediate and to set HL = (DE) or (DE) = HL.

Alan

[Alan Cox]

I've now had time to start testing my revised 80C85 board and MMU.

The two parts actually stand alone. The MMU lives on I/O 0xFF and supplies a configurable A16-A19 for 0xE000-0xFFFF and 0x0000-0xDFFF - much like the S100 world often had a latch that provided A16-A23. Unlike them I've split it into two parts because the days of jumpering a 16K RAM card for any bank and a set of 48K ones for specific banks have somewhat passed. The MMU is designed to be good enough for CP/M 3 and MP/M. It's not as nice as the 512K/512K but it means I can use the much simpler (and cheaper) linear memory cards, and that I can run at 8MHz which with the 8085 seems to push the other card too far.

The MMU should also work separately with any CPU if you omit the 80C85 and address/data demux 74HCT573. That is part of my cunning plan as I want to use the same MMU with the 6502 and with some other pending boards. My bits box has a 63B03RP, a CP1802 and a ROMless Z8 in it so I sent some more bits off to JLCPCB 8)

The CPU side seems to be working at the full 8MHz (Tundra C80C85-8). The MMU has passed some basic checking as I've got enough test code to boot from ROM and turn on 8K of RAM at the top then use it.

Yet again I'm hitting CF card problems. The 8085 at 3MHz is rock solid with almost every CF card I tried. At 8MHz I've got *one* card that works. I may have to switch to using the PPIDE 82C55 based interface (which would fit nicely anyway as I've got a 16x50 UART, and an 82C54 timer). A reliable CF adapter for non Z80 would be nice (or for Z80 8)).

I might revise the board to put the other interrupt lines in the right places now that there is an official place for them. I've yet to decide.

Alan

[Mark T]

I like the MMU, nice and simple and allows it to be on a separate card from the processor and ram.

Also doesn’t have pull down resistors on the address lines, not a problem for cmos but i still don’t like using them, just old habits.

I guess making use of the top 8k of each user bank might be tricky, unless the plan is that each user space has its own common 8k block and switches out the lower 56k for access to the bios.

Mark

[Bill Shen]

Alan,
I like to follow your 8085 development along.  To that end, I've revived my G8PP+8085,
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:g8pp:g8ppbase8085 
Right now I have it running CP/M 2 at 7.37MHz.  It still have some flakyness and I know XMODEM does not work right now.  However, since the design is CPLD and RAM based, I should be able change the hardware and firmware by just changing the CPLD equations and reload new software.  I also have 512K RAM and the MMU design is similar to yours.  I think you are using 16550UART, what other hardware are you using?

This is a picture of hardware currently on my bench right now, except the oscillator is 7.37MHz.  I can plug it into a RC2014 backplane and add more hardware.

  Bill

[Alan Cox]

On Saturday, 28 September 2019 04:43:38 UTC+1, Bill Shen wrote:

Alan,
I like to follow your 8085 development along.  To that end, I've revived my G8PP+8085,
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:g8pp:g8ppbase8085 
Right now I have it running CP/M 2 at 7.37MHz.  It still have some flakyness and I know XMODEM does not work right now.  However, since the design is CPLD and RAM based, I should be able change the hardware and firmware by just changing the CPLD equations and reload new software.  I also have 512K RAM and the MMU design is similar to yours.  I think you are using 16550UART, what other hardware are you using?

My initial build is the Ancient Computing 8085 CPU card  with a 6.144MHz crystal (so 3MHz CPU), 16550A UART at 0xC0, CF adapter, 512/512K RAM/ROM card and for now a TMS9918A video card just as a timer interrupt.

The current one is the 8085/MMU card with 16MHz crystal (8MHz CPU), one of Tom's 512K linear RAM/ROM cards, 82C54 timer, a 16550A uart at 0xC0 and CF adapter. I'm currently adding code to enable the RTC board at 0x0C and the PPIDE card at 0x20 as well as ACIA support.

Firmware is pretty basic - it does a brief memory test, loads the first block of the CF card, checks for a signature and if valid jumps to it. I've got Fuzix running on the older design, I am just finishing up moving it to the 80C85/MMU board so I can test it all out fully. After that I'll probably take a look at CP/M 3 and MP/M II.

Alan

[Bill Shen]

Alan,
When you said "ACIA", do you mean 68B50?  Which RTC are you using, DS1302?  I think I can emulate Tom's 512K linear RAM/ROM with my existing hardware.  I'll need to prototype a 16550 + 82C54 timer.  I think the required hardware can be made ready fairly quickly.  Please post your firmware when you are ready.  Thanks,
  Bill

[Alan Cox]

(reposting to group not just Bill in error + a bit more info)

ACIA - yes 68B50. At the moment I'm just putting the hooks in for

that. Concentrating on the 16x50 first because it's a much nicer chip.

The 82C54 set up is the board I posted the schematic for. It doesn't
do any fancy checking or anything clever so it ought to work if you
just minimally emulate the behaviour used. In fact it's probably
sufficient as the code stands to emulate only a tiny bit of the 82C54

behaviour.

I think the only things you need to emulate are

out to 0x3E clears existing interrupt, counts that may 1/100ths of a second and interrupts again

in from 0x3E reports the interrupt status in bit 7 (1 = we are an interrupt source)

Everything else written/read from 0x3C-0x3F is just setting the other two things to be as above so can be ignored and the code will be happily oblivious.

Alan

[Alan Cox]

Oh and I am using INT6.5. The others are currently just pulled high.

[Bill Shen]

Alan,
My original idea was to prototype 16550 and 82C54 on a prototype board with a CPLD, but the CPLD alone should be able to generate the 100Hz interrupt and have a command register to clear the interrupt and an interrupt status register.  The remaining CPLD is enough to emulate 68B50 or even 16550 without the deep FIFO.

Are you using a RTC right now?

  Bill

[Alan Cox]

On Sunday, 29 September 2019 02:02:17 UTC+1, Bill Shen wrote:

Alan,
My original idea was to prototype 16550 and 82C54 on a prototype board with a CPLD, but the CPLD alone should be able to generate the 100Hz interrupt and have a command register to clear the interrupt and an interrupt status register.  The remaining CPLD is enough to emulate 68B50 or even 16550 without the deep FIFO.

Are you using a RTC right now?

Yes I'm using the standard RC2014 RTC card at 0x0C. It isn't required though. If it's not there it's not there. The 82C54 is fed from a fixed clock as is the 16x50 so nothing needs to use an RTC to work out the CPU speed.

Alan

[Colin MacArthur]

Hello,

Just for FUN, as this is 8085 based have you thought of using a 8256 MUART?

One 40 pin chip with

   1 x UART 

   5 x 8-Bit Timer / Counters (4 can be 2 x 16-Bit )

   2 x 8-Bit Parallel I/O

   8 Level Priority Interrupt Controller

I have worked with them for years and they are easy to program.

It only has a "double buffer" and does not have the "deep FIFO" of the 16550...

It only has two 16 bit counters not the 3 that the 82C54 has...

CM

[Alan Cox]

On Tuesday, 1 October 2019 05:34:44 UTC+1, Colin MacArthur wrote:

Hello,

Just for FUN, as this is 8085 based have you thought of using a 8256 MUART?

One 40 pin chip with

   1 x UART 

   5 x 8-Bit Timer / Counters (4 can be 2 x 16-Bit )

   2 x 8-Bit Parallel I/O

   8 Level Priority Interrupt Controller

I have worked with them for years and they are easy to program.

I think I'd chose the  28L92 for similar reasons as it's still available. No priority interrupt controller but the 80C85 has several lines anyway.

For now the firmware understands a 68B50 at 0xA0 or a 16550A at 0xC0 (I still need to deal with multiple uarts)

[Alan Cox]

On Saturday, 28 September 2019 20:51:44 UTC+1, Bill Shen wrote:

Alan,

When you said "ACIA", do you mean 68B50?  Which RTC are you using, DS1302?  I think I can emulate Tom's 512K linear RAM/ROM with my existing hardware.  I'll need to prototype a 16550 + 82C54 timer.  I think the required hardware can be made ready fairly quickly.  Please post your firmware when you are ready.  Thanks,
  Bill

CP/M 3 bits are now uploaded to https://github.com/EtchedPixels/CPM8085. They use Z80 syntax but are 8080 clean. It's just easier to maintain my different CP/M 3 codebases that way.

The firmware and boot block are for other reasons built with the ACK compiler suite (but no C in them) and are in 8085 assembler. The current versions are at

https://github.com/EtchedPixels/RC2014-ROM/tree/master/8085

The relevant ones are rom512.s and loader512cpm.s

It's a fairly basic set up, test memory, probe devices, print something vaguely intelligent and boot off the disk.

Hardware files are at

https://hackaday.io/project/167859-80c85-and-mmu-for-rc2014-bp80

[Steve Cousins]

Alan, you said "I might revise the board to put the other interrupt lines in the right places now that there is an official place for them."

Do we have an official place for them?

Steve

[Alan Cox]

On Friday, 4 October 2019 00:43:21 UTC+1, Steve Cousins wrote:

Alan, you said "I might revise the board to put the other interrupt lines in the right places now that there is an official place for them."

Do we have an official place for them?

I was going with your "We don't seem to be getting any new opinions on this topic, so here's where we are at." final table. Nobody seems to have screamed about it ?

Alan

[Alan Cox]

I've pushed new firmware to github to fix various problems with PPIDE setup. It now properly does resets and delays at boot and that seems to make a huge difference. With that fixed CP/M 3 seems happy on PPIDE and Fuzix likewise barring one unrelated bug fix I needed.

[Bill Shen]

Resurrected G8PP+8085 to run the 8085all test posted on VCFED. http://www.vcfed.org/forum/showthread.php?74993-Do-you-have-an-8085-can-you-run-this-test

It is the Z80 zexall test modified to run on 8085.  It took a long time with 7.37MHz 8085 (the CPU clock is actually 3.68MHz), probably 3-4 hours.  The results are wrong, but it is the same wrong results as another person's test results, so perhaps the test software is flawed.
  Bill

b>8085all
8085 instruction exerciser
dad <b,d,h,sp>................  ERROR **** crc expected:00000000 found:44331def
aluop nn......................  ERROR **** crc expected:00000000 found:f1be2031
aluop <b,c,d,e,h,l,m,a>.......  ERROR **** crc expected:00000000 found:1e240909
<daa,cma,stc,cmc>.............  ERROR **** crc expected:00000000 found:bfe51a5a
<inr,dcr> a...................  ERROR **** crc expected:00000000 found:632d47c5
<inr,dcr> b...................  ERROR **** crc expected:00000000 found:b1783261
<inx,dcx> b...................  ERROR **** crc expected:00000000 found:d38a84e2
<inr,dcr> c...................  ERROR **** crc expected:00000000 found:a6d2f555
<inr,dcr> d...................  ERROR **** crc expected:00000000 found:ebf818fa
<inx,dcx> d...................  ERROR **** crc expected:00000000 found:5b56262e
<inr,dcr> e...................  ERROR **** crc expected:00000000 found:465a3bbc
<inr,dcr> h...................  ERROR **** crc expected:00000000 found:f0a67079
<inx,dcx> h...................  ERROR **** crc expected:00000000 found:bb3320ef
<inr,dcr> l...................  ERROR **** crc expected:00000000 found:3b62eb12
<inr,dcr> m...................  ERROR **** crc expected:00000000 found:1c9b9c5d
<inx,dcx> sp..................  ERROR **** crc expected:00000000 found:f1682c84
lhld nnnn.....................  ERROR **** crc expected:00000000 found:6d1eeb35
shld nnnn.....................  ERROR **** crc expected:00000000 found:2c5b71d8
lxi <b,d,h,sp>,nnnn...........  ERROR **** crc expected:00000000 found:cfdfbbb3
ldax <b,d>....................  ERROR **** crc expected:00000000 found:30cdccc6
mvi <b,c,d,e,h,l,m,a>,nn......  ERROR **** crc expected:00000000 found:cc3f3d29
mov <bcdehla>,<bcdehla>.......  ERROR **** crc expected:00000000 found:e2c0feb3
sta nnnn / lda nnnn...........  ERROR **** crc expected:00000000 found:f6187eeb
<rlc,rrc,ral,rar>.............  ERROR **** crc expected:00000000 found:7ea730b3
stax <b,d>....................  ERROR **** crc expected:00000000 found:b726a433
Tests complete
b>

[Chris Odorjan]

On Sunday, 10 May 2020 08:02:20 UTC-4, Bill Shen wrote:

Resurrected G8PP+8085 to run the 8085all test posted on VCFED. http://www.vcfed.org/forum/showthread.php?74993-Do-you-have-an-8085-can-you-run-this-test

It is the Z80 zexall test modified to run on 8085.  It took a long time with 7.37MHz 8085 (the CPU clock is actually 3.68MHz), probably 3-4 hours.  The results are wrong, but it is the same wrong results as another person's test results, so perhaps the test software is flawed.

There's a version that has the CRC values pre-filled (except for the slow aluop tests): https://web.archive.org/web/20151108135453/http://www.idb.me.uk:80/sunhillow/8080.html

They still don't always agree with what you and alank2 get; this might be explained by a comment in the source to the effect that the undocumented flags are being masked out.

(It also doesn't quite agree with an 8085 SBC I've built, but I suspect that's because RAM starts at 8000h on my board and I've had to modify the test to run from there.)

--

Chris Odorjan

[Bill Shen]

Thanks for the link.  Now I know why the CRC values are left at 0.  There are too many variations of 8085 that all yields different CRC values.
  Bill

[Chris Odorjan]

On Monday, 11 May 2020 07:31:42 UTC-4, Bill Shen wrote:

Thanks for the link.  Now I know why the CRC values are left at 0.  There are too many variations of 8085 that all yields different CRC values. 

Ah, I downloaded the version on vcfed and I see alank2 already altered the flag mask to 0ffh (i.e. check all flags, not just the documented ones). I've ported it to v2 of my SBC (which can page RAM into the lower 32KB of memory and will someday run CP/M once I write a BIOS; this just implements enough of the character I/O BDOS functions to run the exerciser) and now get the same results as everyone else:

> g8000

Tests complete85mon - Simple 8085 Monitor
>

This is on a 7.37MHz (i.e. 14.7456MHz external clock) Tundra 8085 with the following markings:

TUNDRA
CA80C85B-8CP
66826.1
9734

Test took a little under 2 hours to run at this speed.

--

Chris Odorjan