New 8085 CPU Module designed for RC2014

843 views
Skip to first unread message

Phillip Stevens

unread,
Jul 23, 2021, 7:36:34 AMJul 23
to RC2014-Z80
Been having some fun with a 8085 system recently, trying to get it "on-line". So, I was thinking it would be nice to have an RC2014 8085 CPU Module.

Just finished the design, it is still a long way from running, but the layout is done (but not double checked).
8085_CPU_MODULE.png

SInce the 8085 has no Mode 2 interrupt but has plenty of interrupt lines, I thought the best option was to put a MC6850 UART on the PCB. That way it could use one of the IM1 interrupts, and another interrupt could be directed to the RC2014 Bus. I've also set the SID/SOD pins up with another interrupt to allow them to be a second (slower) bit-banged UART, but with no flow control.

It might be a while before this gets built up, but happy to share the build if someone would like the Gerbers.

 Cheers, Phillip
RC2014_8085_CPU.pdf

Alan Cox

unread,
Jul 23, 2021, 9:30:55 AMJul 23
to rc201...@googlegroups.com

SInce the 8085 has no Mode 2 interrupt but has plenty of interrupt lines, I thought the best option was to put a MC6850 UART on the PCB. That way it could use one of the IM1 interrupts, and another interrupt could be directed to the RC2014 Bus. I've also set the SID/SOD pins up with another interrupt to allow them to be a second (slower) bit-banged UART, but with no flow control.

It might be a while before this gets built up, but happy to share the build if someone would like the Gerbers.

Looking at your design - you don't need the extra buffers if you have an 80C85 (you may well do for a classic 8085 if you have any 74LS/ALS on the backplane), and you will have problems with external interrupts because RST7_5 is edge triggered which is why it is normally used for the bitbang serial interrupt.

The one I designed and built (loosely based on Ben's original) is at


along with a full CP/M and Fuzix setup as well as boot ROM

I took a slightly different approach and used the extra space to include a simple MMU so you could run with the cheap 80pin flat memory card or the 512K/512K banked card. The other interrupt lines are then on headers. The order of them is different to yours and it might be a good idea if there was at least commonality on which pin was the RC2014 IRQ line 8)

I have it running with a Tundra 80C85 at the standard 7.37MHz (8MHz 80C85 part). Except for it hating the CF adapter at that speed and the usual Z80 specific chips it seems to be rock solid.




Alan

Tadeusz Pycio

unread,
Jul 23, 2021, 9:55:40 AMJul 23
to RC2014-Z80
Great idea! I admit that for a long time I was going to design a similar system but with 8251. I think my laziness won, because your project relieves me of its implementation  ;-) 
Alan's comment on the interrupts is important.

Phillip Stevens

unread,
Jul 23, 2021, 10:25:31 AMJul 23
to RC2014-Z80

Since the 8085 has no Mode 2 interrupt but has plenty of interrupt lines, I thought the best option was to put a MC6850 UART on the PCB. That way it could use one of the IM1 interrupts, and another interrupt could be directed to the RC2014 Bus. I've also set the SID/SOD pins up with another interrupt to allow them to be a second (slower) bit-banged UART, but with no flow control.

Looking at your design - you don't need the extra buffers if you have an 80C85 (you may well do for a classic 8085 if you have any 74LS/ALS on the backplane), and you will have problems with external interrupts because RST7_5 is edge triggered which is why it is normally used for the bitbang serial interrupt.
 
Thanks Alan,

I'll rework the interrupt order to match.

But, I was thinking to put the 7.5 interrupt on the bus, as it as the "best" interrupt being latched (edge and level sensitive) and highest priority,  and therefore might provide the most options.
And then reserving the lesser 6.5 and 5.5 interrupts for the CPU on-board usage.

Is there a reason why the 7.5 interrupt is not the "best" interrupt and suitable to use on the RC2014 bus?

The one I designed and built (loosely based on Ben's original) is at

Yes, I saw your MMU version. I am trying to be a little simpler, and just use the existing memory modules for the RC2014, and just aiming for a 64kB CP/M solution.
 
I have it running with a Tundra 80C85 at the standard 7.37MHz (8MHz 80C85 part). Except for it hating the CF adapter at that speed and the usual Z80 specific chips it seems to be rock solid.

Actually it was reading about the CF issues you faced in the post mentioned, and participating in the conversations elsewhere about issues with CF cards generally that lead me to use the AHCT logic bus buffers.
Got to admit that I don't even have a CF Module, preferring to use the 8255 IDE Module exclusively. But, I thought others might find it helpful though.

Happy to hear that it is working well at 7.3MHz. 
The Tundra 80C85B suppliers that I've found are all eBay. Not sure I'd be getting the right thing buying there. But perhaps UTSource has some.

Another board revision shortly.
Cheers, Phillip

Alan Cox

unread,
Jul 23, 2021, 10:47:47 AMJul 23
to rc201...@googlegroups.com
Is there a reason why the 7.5 interrupt is not the "best" interrupt and suitable to use on the RC2014 bus?

All the existing hardware expects level triggered interrupt behaviour like the Z80 provides. Also for the serial you want the edge (inverted if I remember rightly) and the highest priority
so that the bitbanger gets serviced fast. Same reason you wire the bitbanger to the NMI on a Z80.


The one I designed and built (loosely based on Ben's original) is at

Yes, I saw your MMU version. I am trying to be a little simpler, and just use the existing memory modules for the RC2014, and just aiming for a 64kB CP/M solution.

You can just leave all the MMU parts off - I designed it so the MMU is totally optional. It builds as CPU only, MMU only or both 8)

 
I have it running with a Tundra 80C85 at the standard 7.37MHz (8MHz 80C85 part). Except for it hating the CF adapter at that speed and the usual Z80 specific chips it seems to be rock solid.

Actually it was reading about the CF issues you faced in the post mentioned, and participating in the conversations elsewhere about issues with CF cards generally that lead me to use the AHCT logic bus buffers.

If it's drive related - if it's timing related then it won't make any difference. I've not dug into the signal ordering in detail to double check. Of course if it's drive related you want the buffers on the CF end. AHCT may also not be a good idea unless you have to - AHCT has very sharp edges and very sharp edges on a long passive unterminated bus with random slower logic all down it makes me nervous 8)

Got to admit that I don't even have a CF Module, preferring to use the 8255 IDE Module exclusively. But, I thought others might find it helpful though.

Happy to hear that it is working well at 7.3MHz. 
The Tundra 80C85B suppliers that I've found are all eBay. Not sure I'd be getting the right thing buying there. But perhaps UTSource has some.

I've had no problem - they are cheap parts so little incentive to fake, and were available until quite recent times in the Tundra form, but yeah ebay is a bit buyer beware.

Alan

Bill Shen

unread,
Jul 23, 2021, 2:30:38 PMJul 23
to RC2014-Z80
I did a 8085 for RC2014 bus a while ago,  https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:g8pp:g8ppbase8085.  I need to refresh my memory; I know it ran CP/M, but didn't use interrupt so I don't think I had even enabled 8085's interrupts.  I also don't recall CF interface was a problem, but it is important to have some setup time from CF chip select valid to CF read/write strobes.  Most RC2014 CF boards do not have the needed setup time so can be problematic with non-Z80 processors.
  Bill

Chris Odorjan

unread,
Jul 23, 2021, 11:31:11 PMJul 23
to RC2014-Z80
On Friday, 23 July 2021 at 10:25:31 UTC-4 Phillip Stevens wrote:
Happy to hear that it is working well at 7.3MHz. 
The Tundra 80C85B suppliers that I've found are all eBay. Not sure I'd be getting the right thing buying there. But perhaps UTSource has some.
 
Good news: I've ordered about 100 ICs from Utsource and only 5 of them have been defective.

Bad news: 3 of those were Tundra 80C85s :-P  The date codes were all 0052, which maybe not coincidentally was the same as the image on their website at the time. And one of them actually worked up until I tried enabling interrupts and it began jumping to random locations in memory instead of the RST6.5 vector. (This made debugging the interrupt code fun.)

Good news: The replacements (date codes in the late 1990s) work fine in an SBC I've built (that I need to document on retro-comp sometime) at 7.3728MHz without buffers. Admittedly it's a small board without expansion and the only things on the bus are the address latch, RAM, ROM/flash, a DUART, and an SPLD to glue everything together.

More good news: I've had good luck getting OKI MSM80C85AHRS CPUs and even ceramic-topped Intel 8085AH CPUs, both rated at 5MHz (and also obtained from Utsource) running reliably at 7.3728MHz. (I need to do some more testing and document this, too.)

--
Chris Odorjan

Phillip Stevens

unread,
Jul 24, 2021, 1:30:22 AMJul 24
to rc201...@googlegroups.com
Alan wrote:
Is there a reason why the 7.5 interrupt is not the "best" interrupt and suitable to use on the RC2014 bus?

All the existing hardware expects level triggered interrupt behaviour like the Z80 provides. Also for the serial you want the edge (inverted if I remember rightly) and the highest priority so that the bitbanger gets serviced fast. Same reason you wire the bitbanger to the NMI on a Z80.

All fair points. I’ve redone the interrupt assignment to match yours.

TRAP <- inverted NMI line.
7.5 <- inverted RX line. For bit bang serial, and effectively a second interrupt.
6.5 <- inverted INT line.
5.5 <- inverted 6850 IRQ. 
INTR <- GND.

I’d forgotten to tie M1 high so that’s done too.

The one I designed and built (loosely based on Ben's original) is at

Yes, I saw your MMU version. I am trying to be a little simpler, and just use the existing memory modules for the RC2014, and just aiming for a 64kB CP/M.

Noted that you tie X2 capacitor high, rather than to GND as per datasheet.  Is there a background to that decision?

I have it running with a Tundra 80C85 at the standard 7.37MHz (8MHz 80C85 part). Except for it hating the CF adapter at that speed and the usual Z80 specific chips it seems to be rock solid.

If it's drive related - if it's timing related then it won't make any difference. I've not dug into the signal ordering in detail to double check. Of course if it's drive related you want the buffers on the CF end.

Yes I think that was the summary of the other discussion too. But failing buffers on the standard CF Module, it can’t be worse to do it on CPU Module and the user can also just jumper over them if preferred.

AHCT may also not be a good idea unless you have to - AHCT has very sharp edges and very sharp edges on a long passive unterminated bus with random slower logic all down it makes me nervous.

Totally not an expert. But I did do some sample testing the RC2014 bus with these AHCT devices versus unbuffered Z80 and against ABT devices too at the other discussion. The AHCT signals did look better, with less overshoot and bounce. But that’s as scientific as I can call it. Someone with better measuring kit could do an actual study of this.

Reading material suggests whilst AHCT is very fast, the drive (8mA) is much less than standard CMOS, and hence doesn’t tend to bounce. But how much is marketing, and how much is real, I don’t know. Not a hill to die on.

Cheers, P.

--
Sent from a Mobile Device. Replies may appear terse.

Phillip Stevens

unread,
Jul 24, 2021, 7:30:52 AMJul 24
to RC2014-Z80
Alan wrote:
Is there a reason why the 7.5 interrupt is not the "best" interrupt and suitable to use on the RC2014 bus?

All the existing hardware expects level triggered interrupt behaviour like the Z80 provides. Also for the serial you want the edge (inverted if I remember rightly) and the highest priority so that the bitbanger gets serviced fast. Same reason you wire the bitbanger to the NMI on a Z80.

All fair points. I’ve redone the interrupt assignment to match yours.

TRAP <- inverted NMI line.
7.5 <- inverted RX line. For bit bang serial, and effectively a second interrupt.
6.5 <- inverted INT line.
5.5 <- inverted 6850 IRQ. 
INTR <- GND.

So this is what I'm going to mull on for a few days.
It should be compatible with Alan's 8085 Module for interrupts, etc, so for the user it would just be a choice of integrated MMU, or integrated 6850 USART.
But everything else should be the same.

RC2014_8085_CPU.png
Any thoughts? Let me know, please.
Cheers, P.
RC2014_8085_CPU.pdf

Alan Cox

unread,
Jul 24, 2021, 9:36:15 AMJul 24
to rc201...@googlegroups.com
Noted that you tie X2 capacitor high, rather than to GND as per datasheet.  Is there a background to that decision?

No that I remember. I'd have to go back and check the data sheet and reference diagrams I used. It may just be wrong - but it works 8)

 
I have it running with a Tundra 80C85 at the standard 7.37MHz (8MHz 80C85 part). Except for it hating the CF adapter at that speed and the usual Z80 specific chips it seems to be rock solid.

If it's drive related - if it's timing related then it won't make any difference. I've not dug into the signal ordering in detail to double check. Of course if it's drive related you want the buffers on the CF end.

Yes I think that was the summary of the other discussion too. But failing buffers on the standard CF Module, it can’t be worse to do it on CPU Module and the user can also just jumper over them if preferred.

Agreed - and being able to use NMOS is fun if you want to go more retro.


Reading material suggests whilst AHCT is very fast, the drive (8mA) is much less than standard CMOS, and hence doesn’t tend to bounce. But how much is marketing, and how much is real, I don’t know. Not a hill to die on.

I don't know either - Bill probably does. I'm hoping you are right because I need to use 74AHCT to demux the top lines of the new 65C816 card I am working on 8)

Alan

Phillip Stevens

unread,
Jul 24, 2021, 9:58:19 AMJul 24
to RC2014-Z80
Chris wrote:
Good news: The replacements (date codes in the late 1990s) work fine in an SBC I've built (that I need to document on retro-comp sometime) at 7.3728MHz without buffers. Admittedly it's a small board without expansion and the only things on the bus are the address latch, RAM, ROM/flash, a DUART, and an SPLD to glue everything together.

More good news: I've had good luck getting OKI MSM80C85AHRS CPUs and even ceramic-topped Intel 8085AH CPUs, both rated at 5MHz (and also obtained from Utsource) running reliably at 7.3728MHz. (I need to do some more testing and document.

Chris (or anyone who knows),

do you know how reliable is the presence of the undocumented instructions?
I mean on Z80 the undocumented instructions are always present. But I read the 8085 undocumented instructions may not always be present, depending on the manufacturer build.
The 8085B has them. Does the OKI device?

P. 

Alan Cox

unread,
Jul 24, 2021, 10:12:02 AMJul 24
to rc201...@googlegroups.com
do you know how reliable is the presence of the undocumented instructions?
I mean on Z80 the undocumented instructions are always present. But I read the 8085 undocumented instructions may not always be present, depending on the manufacturer build.
The 8085B has them. Does the OKI device?

As far as anyone has been able to test and verify 100%. They are present on the original Intel masks and were clearly all deliberately added. Intel insiders from the period have also stated that the instructions were added deliberately and then for various business reasons (8086, incompatibility with the 8080->8086 translator software) not released. From a compiler perspective it's a shame Intel did that as they fixed pretty much all the nasty 8080 code generation problems with a tiny number of rather elegantly designed instructions.

Oki, AMD and co were all second source licensees so the same design. The soviet ones I assume were just copies of the masks too.

The big problem with using them of course is that they do different things on the Z80, so whilst 8080 code is mostly universal (there are very subtle differences) 8085 is 8085 specific so won't run on Z80 CP/M.

Alan


Phillip Stevens

unread,
Aug 3, 2021, 6:11:17 AMAug 3
to RC2014-Z80

Over the past few days I've been reworking MS Basic 4.7 to make it 8085 clean (again). I had put quite a few Z80 things in it, but now they're gone.
I hope it will "just work" when the board is assembled.
 
As far as anyone has been able to test and verify 100%. From a compiler perspective it's a shame Intel did that as they fixed pretty much all the nasty 8080 code generation problems with a tiny number of rather elegantly designed instructions.
Alan

I like using Zilog mnemonics because that's what the MS Basic code is available in, and also they seem more logical than the Intel mnemonics at least to my eyes. I'm sure that's a personal opinion though.

To make it easier I needed to have an extended 8085 instruction card, using Zilog codes. I couldn't find one, so I've modified a Z80 one that I use regularly for the purpose.

Because it is not my own work I won't host it, but it is available as a github repository for 8085 Zilog Opcodes.
So if you clone it and then click on the html file then it should be visible in your browser.
The details of each opcode are visible when the mouse hovers.

I've stripped out all of the analytics, and updated jquery.js to a recent version.

8085-opcodes.png
Please also visit clrhome.org so that their Google Analytics count goes up.

Phillip Stevens

unread,
Aug 3, 2021, 9:40:29 AMAug 3
to RC2014-Z80
Phillip wrote:
Over the past few days I've been reworking MS Basic 4.7 to make it 8085 clean (again).

I have found what I believe to be an interesting piece of software archaeology.
From what I can tell, MSBasic 4.7 was never 8080 / 85 clean.

When assembling it tonight, I found a few Z80 instructions remaining scattered in the code.
I know they were not my doing so I went back to the paper disassembly document and found that they're written in there too.

They are  ADC HL,DC  and  LD (**),DE 

I first thought that there might have been a transcription typo, and the intended instruction was ADD HL,DE but, because the P flag is later tested, the author meant to use ADC instruction.

Any guesses as to where and when these instructions came in to the code?

Phillip

Alan Cox

unread,
Aug 3, 2021, 11:52:43 AMAug 3
to rc201...@googlegroups.com
On Tue, 3 Aug 2021 at 14:40, Phillip Stevens <phillip...@gmail.com> wrote:
Phillip wrote:
Over the past few days I've been reworking MS Basic 4.7 to make it 8085 clean (again).

I have found what I believe to be an interesting piece of software archaeology.
From what I can tell, MSBasic 4.7 was never 8080 / 85 clean.

4.7b (the one you have) was for the Nascom;  it's entirely possible they had some Z80 specific tweaks. 4.51 was the last Microsoft Basic 4.x release for CP/M before the big changes in 5.0. The CP/M ones do support 8080.

Alan

Chris Odorjan

unread,
Aug 3, 2021, 12:45:48 PMAug 3
to RC2014-Z80
On Tuesday, 3 August 2021 at 09:40:29 UTC-4 Phillip Stevens wrote:
When assembling it tonight, I found a few Z80 instructions remaining scattered in the code.
I know they were not my doing so I went back to the paper disassembly document and found that they're written in there too.

They are  ADC HL,DC  and  LD (**),DE 

I first thought that there might have been a transcription typo, and the intended instruction was ADD HL,DE but, because the P flag is later tested, the author meant to use ADC instruction.

I'd noticed Nascom Basic was almost, but not quite, 8080 compatible and unsuccessfully tried removing the Z80isms. Replacing LD (**),DE with an exchange plus LD (**),HL was an easy fix, but I missed that ADD HL,DE doesn't affect the sign flag like ADC HL,DE does (after verifying that carry was always clear on entry to COUNT).

(Grant Searle's additions used some Z80 instructions but from what I remember it was mostly relative jumps.)
 
Any guesses as to where and when these instructions came in to the code?

They all involve the LINES statement. Was this added for the Nascom?

--
Chris Odorjan

Phillip Stevens

unread,
Aug 4, 2021, 3:18:57 AMAug 4
to RC2014-Z80
Over the past few days I've been reworking MS Basic 4.7 to make it 8085 clean (again).
I have found what I believe to be an interesting piece of software archaeology.
From what I can tell, MSBasic 4.7 was never 8080 / 85 clean.

4.7b (the one you have) was for the Nascom;  it's entirely possible they had some Z80 specific tweaks. 4.51 was the last Microsoft Basic 4.x release for CP/M before the big changes in 5.0. The CP/M ones do support 8080.

Yes, that makes sense. Thanks Alan & Chris.
Probably the LINES() function was added to 4.7b specifically for the NASCOM machine.

Anyway FWIW, I've finished a version of MS Basic 4.7 for the 8085 RC2014 now, that will fully assemble with TASM.
This version has added keywords HLOAD to upload Intel HEX, and RESET to effectively software cold start MS Basic.
These are what I need to build an 8085 development platform.

Because TASM didn't understand Zilog 8085 opcodes out of the box, I've made a table specifically for extended 8085 in Zilog with opcodes.
This TASM85.TAB replaces the Intel 8085 version (which you can rename to still use if you want).
That's how I caught the last sneaky Z80 opcodes.

Looking forward to my 8085 PCBs arriving soon.
P.

Phillip Stevens

unread,
Aug 5, 2021, 11:16:03 AMAug 5
to RC2014-Z80
Phillip wrote:
Because TASM didn't understand Zilog 8085 opcodes out of the box, I've made a table specifically for extended 8085 in Zilog with opcodes. This TASM85.TAB replaces the Intel 8085 version.

Does anyone know what the effect is of adding a 2s complement number in `LD DE,SP+n`?

The assemblers all produce `$FF` if confronted with `LD DE,SP+-1`, but adding 255 to the SP is far less useful for high level languages than subtracting 128, and establishing a stack frame.

The text all seems to point to the offset being an unsigned number though. So, I’m now doubtful that they did the sensible thing.

Alan Cox

unread,
Aug 5, 2021, 11:45:00 AMAug 5
to rc201...@googlegroups.com


On Thu, 5 Aug 2021, 16:16 Phillip Stevens, <phillip...@gmail.com> wrote:
Phillip wrote:
Because TASM didn't understand Zilog 8085 opcodes out of the box, I've made a table specifically for extended 8085 in Zilog with opcodes. This TASM85.TAB replaces the Intel 8085 version.

Does anyone know what the effect is of adding a 2s complement number in `LD DE,SP+n`?

The assemblers all produce `$FF` if confronted with `LD DE,SP+-1`, but adding 255 to the SP is far less useful for high level languages than subtracting 128, and establishing a stack frame

It is unsigned. The better 8080 C compilers already knew how to avoid the cost of a frame pointer so it makes a lot of sense to be unsigned. Besides which you can use Dec on the high byte of the frame pointer and add the correct amount in the offset cheaply

Alan

Chris Odorjan

unread,
Aug 5, 2021, 11:54:22 AMAug 5
to RC2014-Z80
On Thursday, 5 August 2021 at 11:16:03 UTC-4 Phillip Stevens wrote:
The text all seems to point to the offset being an unsigned number though. So, I’m now doubtful that they did the sensible thing.

I wondered this at some point in the past and kept the results of a test program (I think I was working on an 8085 emulator). It produced FEFF (when SP=FE00), not FDFF., so unfortunately it's unsigned.

On the other hand it doesn't affect flags, so something like XCHG; LDSI 0; XCHG will get SP in HL without clearing carry like LXI HL,0; DAD SP does (and in the same time and size).

--
Chris Odorjan

Phillip Stevens

unread,
Aug 5, 2021, 8:08:05 PMAug 5
to RC2014-Z80
Phillip wrote:
The text all seems to point to the offset being an unsigned number though. So, I’m now doubtful that they did the sensible thing.

Chris wrote: 
I wondered this at some point in the past and kept the results of a test program (I think I was working on an 8085 emulator). It produced FEFF (when SP=FE00), not FDFF., so unfortunately it's unsigned.

Thanks Alan & Chris. Saves a lot of time to just ask. I see Alan’s point that it is only 4 cycles more to optionally decrement D and then create a pointer at anywhere within +255 and -255 bytes of SP.
 
On the other hand it doesn't affect flags, so something like XCHG; LDSI 0; XCHG will get SP in HL without clearing carry like LXI HL,0; DAD SP does (and in the same time and size).

Yes this is a useful mini macro. I actually added the 4 byte `LD HL,SP` as those instructions when I added pseudo word load instructions to my TASM85 table. But, then I took it back out because I thought it might encourage laziness on my own side.

Alan, not sure I understand “The better 8080 C compilers already knew how to avoid the cost of a frame pointer so it makes a lot of sense to be unsigned.”?

How did they calculate a stack relative address, without using SP as a pointer? I didn’t think there were enough registers free to use one as a frame pointer. Or, did they just use 8080/Z80 style push/pop to access stack variables?

How best to do stack relative addressing using these 8085 instructions is an interesting problem, I’m thinking about now. I’d like to write some reentrant functions that will need to store local intermediate results.

Alan Cox

unread,
Aug 5, 2021, 9:18:35 PMAug 5
to rc201...@googlegroups.com

Alan, not sure I understand “The better 8080 C compilers already knew how to avoid the cost of a frame pointer so it makes a lot of sense to be unsigned.”?

How did they calculate a stack relative address, without using SP as a pointer? I didn’t think there were enough registers free to use one as a frame pointer. Or, did they just use 8080/Z80 style push/pop to access stack variables?

If you look at CP/M 8080 compilers they generally used HL = accumulator DE = operand (because for most stuff you need to load the second value somewhere unlike 680x), and BC as a frame pointer. Stack offsets can then be generated with LXI H,#offset DAD B, although most compilers had helpers or RST handlers for common offsets. The better ones (eg Whitesmiths) instead tracked the stack depth during code generation and so could use LXI H,#offset DAD SP. Whitesmiths I believe used BC as a register variable instead.

The 8085 instructions basically replace all the LXI H,#offset DAD SP,  MOV A,M INX H MOV H,M MOV L,A stuff with LDSI #offset LHLX/SHLX, and you then can walk structure and pointer chains  LDHI #oiffset, LHLX/SHLX and XCHG patterns.

The K flag (sometimes called X5) serves two purposes - it fixes the horrible signed maths on 8080 and also the 8080 (and Z80 problem) with 16bit DEC not setting flags so you can replace the old  DCX B  MOV A,B OR C JNZ sequences with DCX / JNK

The other important detail is RDEL (rotate DE left). As well as the obvious use it's the equivalent of DAD H and means you can deal with pointer scaling in either register.

Alan

Phillip Stevens

unread,
Aug 9, 2021, 9:16:03 AMAug 9
to RC2014-Z80
Phillip wrote:


So this is what I'm going to mull on for a few days.
It should be compatible with Alan's 8085 Module for interrupts, etc, so for the user it would just be a choice of integrated MMU, or integrated 6850 USART.
But everything else should be the same.

RC2014_8085_CPU.png

The PCBs arrived today. They look very nice. But, things aren't working. Hmm... And so the debugging starts.
Just for overview, the initial startup copying the vector table and initialising some variables (about 60 pulses on the /WR line), seems to be working properly.
Screenshot from 2021-08-09 23-05-55.png

But when it comes to initialising the 6850 (pulses on the /IORQ line), the problems become apparent.
The control address is $80, so A7 line should be high. And indeed the CPU and ALE do show A7 high.
But the 573 latch doesn't catch this and so the address is read incorrectly by the 6850.

Screenshot from 2021-08-09 23-01-52.pngI

What I'm finding quite interesting (read bloody annoying) is that for every other read or write cycle the ALE correctly traps the address, and the BA7 line is correct.
It is only when writing to /IORQ that it is going wrong. In fact on the second write to the 6850 the BA7 line goes out of its way to be wrong.

Going to have to sleep on this.
Cheers, Phillip

 

Alan Cox

unread,
Aug 9, 2021, 9:50:18 AMAug 9
to rc201...@googlegroups.com

What I'm finding quite interesting (read bloody annoying) is that for every other read or write cycle the ALE correctly traps the address, and the BA7 line is correct.
It is only when writing to /IORQ that it is going wrong. In fact on the second write to the 6850 the BA7 line goes out of its way to be wrong

Looking at the traces I may be missing something but I think your problem is the buffering logic is wrong. For a write cycle at least RD will stay high. Now with RD always high the
74HCT245N will drive the RC2014 bus signals onto AD0-AD7 during the address demultiplexing cycles so the 74HCT573 actually sees a fight between the latch and the CPU.

What happens if you pull the 245 and replace it with 8 wire links ?

Alan

Greg Holdren

unread,
Aug 9, 2021, 12:52:55 PMAug 9
to RC2014-Z80
Phillip,

I think you need to do something with the G of the 245. There is bus contention on the internal databus between the 245 and the UART during read.

Greg

Phillip Stevens

unread,
Aug 9, 2021, 9:10:32 PMAug 9
to RC2014-Z80
Greg wrote:
I think you need to do something with the G of the 245. There is bus contention on the internal databus between the 245 and the UART during read.

Alan wrote:
Looking at the traces I may be missing something but I think your problem is the buffering logic is wrong. For a write cycle at least RD will stay high. Now with RD always high the
74HCT245N will drive the RC2014 bus signals onto AD0-AD7 during the address demultiplexing cycles so the 74HCT573 actually sees a fight between the latch and the CPU.

Yes, both on the right track, thanks.

There is a bus contention between the '245 and the UART during read. But there is a also a contention between the CPU and the UART during the when the low addresses are on the bus.

The way I have it set up is that the 6850 has no way of knowing to stay off the bus during the low address latching time. As soon as it sees its I/O address, coupled with a RD signal, it will enable its outputs. But this is exactly when the CPU is trying to write to the '573 latch. A way to fix this would be to add the ALE into the 6850 addressing, but that wouldn't solve the problem fully.

The only way to solve the problem properly is to put the 6850 outside the '245 buffer, and I have it currently, manage the '245 G signal using ALE. This will ensure that nothing disturbs the CPU while it is trying to set up the low addresses.

What happens if you pull the '245 and replace it with 8 wire links?

I've not tried it, but in this case it won't help. The 6850 is going to jump on the bus as soon as it sees its I/O address, and mess things up whether there is a '245 or not.

I would go so far as to say that, I can't see how a robust 8085 system can work without data bus isolation (a tristate transceiver like a '245).
Without the isolation, any device on the bus can "wake up" its bus drivers when it sees its I/O address and the RD line, and disturb the data bus whilst the CPU is trying to latch these low addresses.

Anyway, with the 6850 pulled out the trace looks much better. So I'll have to reroute the PCB to put the 6850 data bus "outside" too.

Screenshot from 2021-08-10 10-50-27.png

 Cheers, Phillip

Alan Cox

unread,
Aug 9, 2021, 9:42:44 PMAug 9
to rc201...@googlegroups.com


I would go so far as to say that, I can't see how a robust 8085 system can work without data bus isolation (a tristate transceiver like a '245).
Without the isolation, any device on the bus can "wake up" its bus drivers when it sees its I/O address and the RD line, and disturb the data bus whilst the CPU is trying to latch these low addresses.

RD does not go low until the rising clock edge in the middle of T2. So the device will not get an RD or WR until the point it has valid data on the bus for a write or is expected to provide it for a read. Your 68B50 is, however, Motorola bus so you are using \WR as R/W and that won't work because your E clock isn't properly qualified by requiring either \RD or \WR is low.

I still think your 245 setup looks wrong. During the T1 cycle the CPU drives AD0-AD7 with the address and DIR is \RD which is high so the 74HCT245 also drives the same lines with whatever is randomly floating about on the bus.

G needs to be something like a NAND of \RD and \WR so the buffer is only active when data is being transferred. Maybe you can just flip the sides of the HCT245 and use \WR so that the 245 drives the bus with crap during address demux cycles  but you seem to need the same signal for the 68B50 anyway.

It's very different to the Z80 cycles where RD and MREQ/IORQ are basically aligned. On an 8085 your generated MREQ and IORQ occur much earlier and you will get spurious selects without RD/WR. That is fine with the proper decoding because they are no different to the glitfches you get on the Z80 bus because they are not quite aligned, even more so once buffers or decoders are involved.

Alan


Phillip Stevens

unread,
Aug 9, 2021, 11:50:28 PMAug 9
to RC2014-Z80
I would go so far as to say that, I can't see how a robust 8085 system can work without data bus isolation (a tristate transceiver like a '245).
Without the isolation, any device on the bus can "wake up" its bus drivers when it sees its I/O address and the RD line, and disturb the data bus whilst the CPU is trying to latch these low addresses.

Alan wrote: 
RD does not go low until the rising clock edge in the middle of T2. So the device will not get an RD or WR until the point it has valid data on the bus for a write or is expected to provide it for a read. Your 68B50 is, however, Motorola bus so you are using \WR as R/W and that won't work because your E clock isn't properly qualified by requiring either \RD or \WR is low.

Yes, the 6850 is "badly behaved" from a 8085 point of view.
As I'm using E input as  the 6850 /IORQ (not properly qualified), the 6850 will drive the bus within 20ns, which interferes with the address demultiplexing. No way around this without a lot more logic.

I still think your 245 setup looks wrong. During the T1 cycle the CPU drives AD0-AD7 with the address and DIR is \RD which is high so the 74HCT245 also drives the same lines with whatever is randomly floating about on the bus. 

G needs to be something like a NAND of \RD and \WR so the buffer is only active when data is being transferred. Maybe you can just flip the sides of the HCT245 and use \WR so that the 245 drives the bus with crap during address demux cycles  but you seem to need the same signal for the 68B50 anyway.

I don't think I posted the most recent schematic (there were too many changes). But on the built PCB I'm driving the '245 /OE input with the ALE pin. This disables the '245 outputs while ALE is high. The '573 only needs 1ns to latch the addresses when ALE falls, but the '245 takes typically 9ns to 14ns on /OE to reactivate either set of outputs. So the CPU now has a clean window to latch the low addresses no matter what sins are happening on the "outer bus".

I've attached the current broken schematic. I'm planning to move the 6850 data lines to the "outside" data bus. But the layout will be a pita I'm sure.
But first I'm testing using an old 6850 RC2014 board and the IRQ6.5 to make sure that there's nothing else broken.

It's very different to the Z80 cycles where RD and MREQ/IORQ are basically aligned. On an 8085 your generated MREQ and IORQ occur much earlier and you will get spurious selects without RD/WR. That is fine with the proper decoding because they are no different to the glitches you get on the Z80 bus because they are not quite aligned, even more so once buffers or decoders are involved.

Yes, I agree. I don't know enough about the different families' bus protocols.
But from what I see using the '245 to isolate the 8085 and '573 from the rest of the world during the critical latching time would insulate from most issues.

Updates when I've more test results.
Cheers, Phillip

RC2014_8085_CPU.pdf

Phillip Stevens

unread,
Aug 10, 2021, 5:02:56 AMAug 10
to RC2014-Z80
Phillip wrote:
I've attached the current broken schematic. I'm planning to move the 6850 data lines to the "outside" data bus. But the layout will be a pita I'm sure.
But first I'm testing using an old 6850 RC2014 board and the IRQ6.5 to make sure that there's nothing else broken.
Updates when I've more test results.

Well that's going to nowhere now.
I don't have a functioning ACIA Module, and I can't repair my broken one with the new MC6850 devices.
So until that is resolved, I've got nothing more I can do.
P.

Alan Cox

unread,
Aug 10, 2021, 8:12:27 AMAug 10
to rc201...@googlegroups.com
I don't think I posted the most recent schematic (there were too many changes). But on the built PCB I'm driving the '245 /OE input with the ALE pin. This disables the '245 outputs while ALE is high. The '573 only needs 1ns to latch the addresses when ALE falls, but the '245 takes typically 9ns to 14ns on /OE to reactivate either set of outputs. So the CPU now has a clean window to latch the low addresses no matter what sins are happening on the "outer bus".

ALE is only driven high during the low half cycle of T1, so for the second half of T1 and the first half of T2 whilst you've latched the data the CPU is fighting the 245 on the bus still.  It's better but it still looks very wrong. You should only drive the AD lines into the CPU when \RD is low.

Alan

Phillip Stevens

unread,
Aug 11, 2021, 12:12:48 AMAug 11
to RC2014-Z80
I don't have a functioning ACIA Module, and I can't repair my broken one with the new MC6850 devices.
So until that is resolved, I've got nothing more I can do.

Well using my old ACIA Module as a platform, I've "fly wired" it back to a working state (I think).
But my code is not working with ACIA as it stands.

However, the 8085 module is working, and counts using digital I/O Module, etc. So I think the non-working is a combination of a) bad code b) possibly overclocking on subtlety on non B type 6850 c) possible timing issues d) IDK.

Alan wrote:
  • ALE is only driven high during the low half cycle of T1, so for the second half of T1 and the first half of T2 whilst you've latched the data the CPU is fighting the 245 on the bus still.  It's better but it still looks very wrong. You should only drive the AD lines into the CPU when \RD is low.
Alan, sorry for being thick here. I've read (and reread) your comments here and above, and still I'm not getting what the concern is.

The '245 DIR line is being driven by /RD. So according to the OKI 8085 specification /RD active will never overlap with the AD0-7 address timing, so the '245 can never be driving the CPU when the AD0-7 are valid.
And the AD lines are only being driven into the CPU when /RD is low because of DIR. That also makes the ALE on /OE signal a "nice to have" but quite unnecessary.

Unless you see I've got the whole '245 backwards in terms of the DIR signalling?
But then nothing would work, which is not the case. So, I don't know?

Could you explain again, please?

Screenshot from 2021-08-11 14-00-12.png

Phillip Stevens

unread,
Aug 11, 2021, 1:27:42 AMAug 11
to RC2014-Z80
But my code is not working with ACIA as it stands.
However, the 8085 module is working, and counts using digital I/O Module, etc. So I think the non-working ACIA is a combination of a) bad code b) possibly overclocking on subtlety on non B type 6850 c) possible timing issues d) IDK.

Sorry for the 8085 related spaming, but I think the reason the ACIA doesn't work is c) timing issues.

The 6850 needs the E signal to happen after the address and /CS lines have stabilised. 13 and 14 in below image.
But the proposed method using the IO / /M line provided by the 8085 happens very early.
Even before the address lines have been stabilised. This is clearly wrong.

It means that the standard ACIA Module can't work with the 8085 CPU, unless the /IORQ and /MREQ signals are provided in Z80 timing (rather than just piping IO / /M directly to the Z80 bus lines).

So, I'll have to produce signals /IORQ and /MREQ signals that have the right timing, and use them for the RC2014 Bus

MC6850_Timing.png8085_Timing.png
Hmm. More complex than I'd hoped.
P.

Alan Cox

unread,
Aug 11, 2021, 9:17:42 AMAug 11
to rc201...@googlegroups.com


On Wed, 11 Aug 2021 at 06:27, Phillip Stevens <phillip...@gmail.com> wrote:

Nope I got the 245 backwards not you.

But my code is not working with ACIA as it stands.
However, the 8085 module is working, and counts using digital I/O Module, etc. So I think the non-working ACIA is a combination of a) bad code b) possibly overclocking on subtlety on non B type 6850 c) possible timing issues d) IDK.

The 6850 needs the E signal to happen after the address and /CS lines have stabilised. 13 and 14 in below image.
But the proposed method using the IO / /M line provided by the 8085 happens very early.
Even before the address lines have been stabilised. This is clearly wrong.

I think it's "one of RD or WR low". Z80 you can get away with IORQ as E generally. If you generate IORQ that way for the bus however it would make the access times much shorter and I don't know what that would result in. The old 68B50 module also doesn't work with the 6502 card unless you wire it to the proper E, and probably also the 6800, 6803, 6809 and 68HC11 cards for the same reason.

I can confirm the undoctored 68B50 doesn't work with my 8085 card either though. I've always used the 16x50 anyway (or the bitbanger ports)


Phillip Stevens

unread,
Aug 12, 2021, 12:07:03 AMAug 12
to RC2014-Z80
But my code is not working with ACIA as it stands.
However, the 8085 module is working, and counts using digital I/O Module, etc.
So I think the non-working ACIA is a combination of a) ... b) ... c) possible timing issues d) ...

The 6850 needs the E signal to happen after the address and /CS lines have stabilised.
But the proposed method using the IO / /M line provided by the 8085 happens very early.
Even before the address lines have been stabilised. This is clearly wrong.
 
Alan wrote: 
I think it's "one of RD or WR low". Z80 you can get away with IORQ as E generally.

Yes, that's what I'm working with. I looked at S0 and S1, but they're also too early. So /RD and /WR it is.

I couldn't find a solution to this problem in any reference on the 'net. But I'm sure this problem must have been solved previously.
So anyway, I've cooked up a set of logic that I think will implement the required truth table. Sadly it took me far too long to solve this.

I think the result can be obtained in 4 NAND gates, which fits into a 7400 nicely.
Any thoughts or corrections would be welcome.

8085_to_Z80_signals.jpg

If you generate IORQ that way for the bus however it would make the access times much shorter and I don't know what that would result in.

Yes. Next step is to check timing, to see if the resulting signals are long enough to work with the standard RC2014 Modules.
 
I can confirm the undoctored 68B50 doesn't work with my 8085 card either though.
 
Good to hear an independent view, and confirm. Thanks.

Cheers, Phillip

Phillip Stevens

unread,
Aug 12, 2021, 7:00:28 AMAug 12
to RC2014-Z80
Here's a revised 8085 CPU Module and the schematic.
So now only the SOD/SID serial port is on-board, and the RST5.5 is free to route to a user pin..

As usual, a day of consideration, then I'll hit order form for them.

8085 CPU MODULE.png

Let's hope the timing issues are resolved sufficiently, and it can pretend to be a Z80 well enough to fool the RC2014 standard modules.
Cheers, Phillip

RC2014_8085_CPU.pdf

Phillip Stevens

unread,
Aug 15, 2021, 9:49:32 PMAug 15
to RC2014-Z80
Chris wrote: 
On the other hand it doesn't affect flags, so something like XCHG; LDSI 0; XCHG will get SP in HL without clearing carry like LXI HL,0; DAD SP does (and in the same time and size).

Paulo added the LD HL,SP+* and LD HL,SP pseudo instructions to the z88dk-z80asm assembler.

So now there's a fairly complete set of abstract 8085 macro LD instructions to make life a little less tedious.

example.png

Phillip Stevens

unread,
Aug 25, 2021, 2:40:01 AMAug 25
to RC2014-Z80
Phillip  wrote:
Here's a revised 8085 CPU Module and the schematic.
So now only the SOD/SID serial port is on-board, and the RST5.5 is free to route to a user pin..
Let's hope the timing issues are resolved sufficiently, and it can pretend to be a Z80 well enough to fool the RC2014 standard modules.


I've loaded my MICROSOFT (RC2014) BASIC 4.7C for 8085 onto a Memory Module, and the system is working fine with the standard ACIA Serial Module.
I've also got the CPU SOD transmitting properly at 115200 8n2, but at this stage there's some timing issues to check on the SID receive side.
The plan is to have both serial options (ACIA + SID/SOD) working jointly. With the transmission channel being selected by the most recently received byte.

IMG_1567.jpg

Both the OKI and Tundra 8085 devices I got from UT Source are working fine at 7.3728MHz, so that's good news too.

Now, I'll spend some time polishing the BASIC implementation to use the 8085 undocumented opcodes where appropriate.

Then my plan is to invest some time extending the existing z88dk 8085 support.
Essentially to try to make everything reentrant, and faster where possible.
And then also build a new 8085 specific reentrant IEEE floating point maths library.

Cheers, Phillip

Phillip Stevens

unread,
Sep 14, 2021, 6:42:11 AMSep 14
to RC2014-Z80
Phillip wrote:
I've loaded my MICROSOFT (RC2014) BASIC 4.7C for 8085 onto a Memory Module, and the system is working fine with the standard ACIA Serial Module.
I've also got the CPU SOD transmitting properly at 115200 8n2, but at this stage there's some timing issues to check on the SID receive side. 
I may have to go to 38,400 baud.
 
The plan is to have both serial options (ACIA + SID/SOD) working jointly. With the transmission channel being selected by the most recently received byte.

IMG_1567.jpg

I've still some PCBs available on Tindie (and have ordered some more), but because postage from Australia is such an expensive PITA, I've also put the 8085 CPU Module up on Seeed Fusion so anyone can order the PCB from them directly.
Cheers, Phillip

Phillip Stevens

unread,
Sep 26, 2021, 8:52:33 AMSep 26
to RC2014-Z80
Things have been moving forward on the 8085 front (despite the rubber bullets flying around our city), so it is time for an update.

I spent quite a few hours trying to get the SID serial input to work driven by the RST 7.5 interrupt. Whilst it does work, it is not stable enough to use successfully.
I've tried to slow it down to 38,400 baud, but that works less well because of the longer time spent with interrupts disabled, and tried using an interrupt flag to signal to the Tx routine (then run with interrupts enabled) that it has been interrupted and commit a framing error to abandon an interrupted character and then repeat the character. But none of these solutions work effectively.

So, I've removed the SID/SOD code from the MS Basic implementation, to allow more space in the 8k ROM for me to play with MS Basic optimisations.

Happy to say that the MS Basic implementation is now harmonised across all of my builds (Z80, Z80+APU, 8085, etc) except for specific optimisation paths for Z80 and 8085 opcodes.

But, now the big reveal for today is z88dk support of the RC2014-8085 Module.

The intention is to provide both ACIA ROM and MS Basic RAM subtypes.
But at this stage I've focused on getting the basic85 subtype working. ACIA support can come later.

As z88dk supports 8085 C compilation using the sccz80 compiler and the classic library, whilst the RC2014 target is normally a newlib library target, there was quite a bit of interesting blending of classic and new code to get the crt0 and libraries created and linked properly. But, now the RC2014-8085 is the first 8085 platform in the newlib targets. Woo Hoo!

Having the basic85 subtype means that C and assembly programs can be uploaded to the RC2014 RAM using the MS Basic HLOAD keyword.

In host PC:
> zcc +rc2014 -subtype=basic85 [ --list -m ] myfile.c -o myhexfile -create-app
Then from MS Basic: HLOAD
> cat >/dev/ttyUSB0 <./myhexfile.ihx
And to run the program from MS Basic: ? usr(0)

And that's all that's needed.

This is still being tested, and assume that there will be issues. But the hard work is now done.

In another note, Paulo has gone to town with synthetic instructions for the 8085 in z88dk-z80asm, to make coding more convenient. Essentially, anything you can do with loading indirectly from (hl), you can now transparently do from (de). The assembler implements the ex de,hl instructions silently to make life easy. This helps when writing assembly for Z80 and 8085, because you don't have to write alternate code paths depending on the CPU. Of course all of the other 8085 side effect free convenience opcodes are available too, like ld bc,hl and ld hl,sp+n.

IMG_1567.jpg

But because postage from Australia is such an expensive PITA, I've also put the 8085 CPU Module up on Seeed Fusion so anyone can order the PCB from them directly.

Cheers, Phillip 

Chris Odorjan

unread,
Sep 26, 2021, 9:58:57 PMSep 26
to RC2014-Z80
On Tuesday, 14 September 2021 at 06:42:11 UTC-4 Phillip Stevens wrote:
I've still some PCBs available on Tindie (and have ordered some more), but because postage from Australia is such an expensive PITA, I've also put the 8085 CPU Module up on Seeed Fusion so anyone can order the PCB from them directly.

Thanks for this, I've been meaning to ask if Gerbers were available anywhere. (Shipping to Canada from just about everywhere is bad enough, but shipping to Canada from Australia is even worse...)

I see your notes on Gitlab regarding use of an Am9511A with an 8085. I've been thinking of getting the APU module for my Z80-based RC2014, do you have any plans for a revision with a wait-state generator?

--
Chris Odorjan

Phillip Stevens

unread,
Sep 26, 2021, 10:26:54 PMSep 26
to RC2014-Z80
Chris wrote:
Phillip wrote:
I've still some PCBs available on Tindie (and have ordered some more), but because postage from Australia is such an expensive PITA, I've also put the 8085 CPU Module up on Seeed Fusion so anyone can order the PCB from them directly.

Thanks for this, I've been meaning to ask if Gerbers were available anywhere. (Shipping to Canada from just about everywhere is bad enough, but shipping to Canada from Australia is even worse...)

I see your notes on Gitlab regarding use of an Am9511A with an 8085. I've been thinking of getting the APU module for my Z80-based RC2014, do you have any plans for a revision with a wait-state generator?

Funny you should ask... See RetroChallenge 2021/10.
But I can't say too much because it is not October yet, and I wouldn't want to be caught cheating.

Cheers, Phillip

Phillip Stevens

unread,
Oct 14, 2021, 9:32:55 AMOct 14
to RC2014-Z80
Chris wrote:
I see your notes on Gitlab regarding use of an Am9511A with an 8085. I've been thinking of getting the APU module for my Z80-based RC2014, do you have any plans for a revision with a wait-state generator?

Funny you should ask... See RetroChallenge 2021/10.
But I can't say too much because it is not October yet, and I wouldn't want to be caught cheating.

So I've been making some updates on Twitter and on my RetroChallenge Blog, so perhaps nothing here is news really. But, my new 8085 CPU Module with wait-state generator is working great with the Am9511A APU Module, and with my UX Module.
There's pretty much nothing else missing that's needed, I believe. 

IMG_1621.jpg

Over the past few weeks the z88dk C library support has been improving for the rc2014-8085 variant, to the extent that most serial orientated games (like Super Startrek) are working fine.

My currently preferred option is to run 8085+APU MS Basic 4.7c, which allows me to load compiled/assembled programs from z88dk with target +rc2014 -subtype=basic85 using the HLOAD keyword.
For this option Basic will use the APU (for everything),  but the C maths library is not APU enabled yet.

startrek-8085.png

I've been experimenting with both Basic and C benchmarks, and there's not much between the Z80 and 8085, perhaps the 8085 is around 1% slower, but the standard libraries have not been optimised very much yet.
Since I'm effectively using the APU and 8085 together already in Basic, I've achieved the goals set for my RetroChallenge. But there a few days left. Let's see what else can be done.

IMG_1624.jpg

The new PCBs are also on Tindie now, or mail me if you'd like the Gerber files.

Cheers, Phillip

Chris Odorjan

unread,
Oct 14, 2021, 11:36:32 PMOct 14
to RC2014-Z80
On Thursday, 14 October 2021 at 09:32:55 UTC-4 Phillip Stevens wrote:
So I've been making some updates on Twitter and on my RetroChallenge Blog, so perhaps nothing here is news really. But, my new 8085 CPU Module with wait-state generator is working great with the Am9511A APU Module, and with my UX Module.
There's pretty much nothing else missing that's needed, I believe.

I happened to be reading your blog a few days ago, at which point you weren't expecting the PCB until the 18th. Sounds like you lucked out getting it early, congratulations on reaching your goals!

--
Chris Odorjan

Phillip Stevens

unread,
Oct 17, 2021, 10:28:05 PMOct 17
to RC2014-Z80
So I've been making some updates on Twitter and on my RetroChallenge Blog, so perhaps nothing here is news really. But, my new 8085 CPU Module with wait-state generator is working great with the Am9511A APU Module, and with my UX Module.
My currently preferred option is to run 8085+APU MS Basic 4.7c, which allows me to load compiled/assembled programs from z88dk with target +rc2014 -subtype=basic85 using the HLOAD keyword.
 
Since I'm effectively using the APU and 8085 together already in Basic, I've achieved the goals set for my RetroChallenge. But there a few days left. Let's see what else can be done.


VGA+8085+APU.jpg

There are some worthwhile updates for the RC2014 Classic ][, Mini, and Micro Z80 hardware (and also with APU Module) in this release too.
There weren't any bugfixes from v2.1 to correct, but this release v2.2 is simply slightly faster for Z80 hardware.

My next challenge is to build a native IEEE 32-bit floating point library for the 8085 and Am9511A within z88dk.
This new library will exist alongside the existing RC2014 Z80 + Am9511A floating point library.

Cheers, Phillip

tszo...@pacbell.net

unread,
Oct 18, 2021, 1:56:04 PMOct 18
to RC2014-Z80
How does the Floating Point performance of the AM9511 compare to the performance of a Raspi Zero?

Phillip Stevens

unread,
Oct 18, 2021, 4:22:52 PMOct 18
to RC2014-Z80
Tom wrote:
How does the Floating Point performance of the AM9511 compare to the performance of a Raspi Zero?

Its really like night and day. Their performance is incomparable.

The Am9511A is at least 40x more powerful than a Raspi Zero FPU, when measured on the "Retro scale" (measured in years since launch), with the Am9511A getting bonus points for being the first ever APU/FPU, and the first commercially available 16-bit processor (please correct me if you know better). Incomparable!

Cheers, Phillip


Doug Jackson

unread,
Oct 18, 2021, 6:26:52 PMOct 18
to rc201...@googlegroups.com
:-)

"The Am9511A is at least 40x more powerful than a Raspi Zero FPU, when measured on the "Retro scale" (measured in years since launch), with the Am9511A getting bonus points for being the first ever APU/FPU, and the first commercially available 16-bit processor (please correct me if you know better). Incomparable!"

That made my morning.  Now I have to look up this retro scale :-)

Thank you.

Doug Jackson

ph: 0414 986878

Check out my awesome clocks at www.dougswordclocks.com
Follow my amateur radio adventures at vk1zdj.net


--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/9f6fd32c-9e90-4b42-8090-c2d3ee56b22cn%40googlegroups.com.

Doug Jackson

unread,
Oct 18, 2021, 6:42:24 PMOct 18
to rc201...@googlegroups.com
A quick back of the envelope calculation from the data sheet https://www.hartetechnologies.com/manuals/AMD/AMD%209511%20FPU.pdf

On the Am9511A, Cosine takes at most 4878 cycles which at 4Mhz  = 1.2mS - (833 OPS) That's quicker than I can key it in on my trusty HP41 calculator

If I read the information here https://forums.raspberrypi.com/viewtopic.php?t=308794 correctly
On the Pi 4B, Cosines are calculated at 54MOPS, which is 18.9ns per calculation - Something like 64000 times faster.  

But that's using completely boring hardware which is no where near as cool as a beautiful 28 pin package attached to the Z80 of your choice..


Kindest regards,

Mark T

unread,
Oct 18, 2021, 8:23:20 PMOct 18
to RC2014-Z80

Now compare the speed of the 9511 with the z80a and similar processors of its age, to the relative speed of the rasp pi compared to an i7 or ryzen 5.

Doug Jackson

unread,
Oct 18, 2021, 8:28:26 PMOct 18
to rc201...@googlegroups.com
Hi Mark,

Yes - It is blisteringly fast wrt the CPUs of its age - no question there.   Even at 833 cosines/sec thats amazing!.

I just ordered a RC2014 board with one onboard, and am looking forward to seeing if I can figure out how to do graphics. :-)

Kindest regards,

Doug Jackson

ph: 0414 986878

Check out my awesome clocks at www.dougswordclocks.com
Follow my amateur radio adventures at vk1zdj.net

-----------------------------------------------------------

Just like an old fashioned letter, this email and any files transmitted with it should probably be treated as confidential and intended solely for your own use. 

Please note that any interesting spelling is usually my own and may have been caused by fat thumbs on a tiny tiny keyboard.

Should any part of this message prove to be useful in the event of the imminent Zombie Apocalypse then the sender bears no personal, legal, or moral responsibility for any outcome resulting from its usage unless the result of said usage is the unlikely defeat of the Zombie Hordes in which case the sender takes full credit without any theoretical or actual legal liability. :-)

Be nice to your parents.

Go outside and do something awesome - Draw, paint, walk, setup a radio station, go fishing or sailing - just do something that makes you happy.

^G ^G ^G ^G ^G ^G ^G ^G- In more laid back days this line would literally sing ^G ^G ^G ^G ^G ^G ^G ^G 





Phillip Stevens

unread,
Oct 30, 2021, 7:32:08 AMOct 30
to RC2014-Z80
On Monday, 18 October 2021 Phillip  wrote:
So I've been making some updates on Twitter and on my RetroChallenge Blog, so perhaps nothing here is news really. 
But, my new 8085 CPU Module with wait-state generator is working great with the Am9511A APU Module, and with my UX Module.
There are some worthwhile updates for the RC2014 Classic ][, Mini, and Micro Z80 hardware (and also with APU Module) in this release too.
My next challenge is to build a native IEEE 32-bit floating point library for the 8085 and Am9511A within z88dk.
 
 Well as usual with my plans they don't last very long, and  I got a bit diverted into another (worthwhile) endeavour; working on the compiler support primitives for sccz80 within the z88dk.

Since possibly 1998, and possibly longer, the 8080, 8085 and Gameboy Z80 CPU support has used non-reentrant primitives, with some of the code being derived from the Amsterdam Compiler Kit, which originated in the 1980s.

@suborb recently went to the trouble to reorganise all of the primitives (called l_ functions), so that there is a neat inheritance process, with 8085 derived from 8080 and using common primitives. Gameboy Z80 uses its own primitives, with common primitives, and Z80 also uses its own primitives inheriting from common too. With that mechanism in place, initially it was just a process of picking functions where the 8085 undocumented instructions could contribute to better code. But, then I got a bit carried away and also rewrote all the 8080 and gbz80 primitives where necessary to ensure that the whole library was reentrant.

Its been an interesting few weeks, and quite a useful end to the RetroChallenge month. Hopefully these new compiler primitives will be useful for as long as the last set were.

This reentrancy will open the door to building multi-threaded systems based on the 8085. Something I'm looking forward to implementing too.
And now, back to floating point...

Cheers, Phillip

Phillip Stevens

unread,
Nov 3, 2021, 11:22:35 PMNov 3
to RC2014-Z80
Just got some OEM pieces from my 8085 CPU Module and the 8231A APU Module. And they're working fine.

Great that the older Intel HMOS 8085AH-2 part has no problem running at 7.3728MHz.
And also good to have confirmed that the undocumented instructions are also there (not that there was any real doubt).

I also got an 8231A Intel branded APU, which also works fine in the APU Module.

I'm very happy to have a fully CDIP Intel RC2014 system.

IMG_1640.jpg
IMG_1639.jpg 

Cheers, Phillip

Phillip Stevens

unread,
Nov 4, 2021, 7:07:41 AMNov 4
to RC2014-Z80
Phillip wrote:
Just got some OEM pieces from my 8085 CPU Module and the 8231A APU Module. And they're working fine.

Great that the older Intel HMOS 8085AH-2 part has no problem running at 7.3728MHz.
And also good to have confirmed that the undocumented instructions are also there (not that there was any real doubt).

That's interesting... the 8085AH-2 is running noticeably warm after a few games of SUPER STARTREK.
First time I've experienced that with a CPU retro part.

(Except the Am9511A / 8231A APU which normally runs finger ouch hot).

Just checked the Intel 8085AH data sheet and I'm expecting that it is sinking >200mA supply current at 7.3728MHz.
Probably the CMOS devices I've been using until now are consuming less than 10mA at the same frequency.
That explains it then. NMOS vs CMOS.

Reply all
Reply to author
Forward
0 new messages