New 8085 CPU Module designed for RC2014

[Phillip Stevens]

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).

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

[Alan Cox]

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

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

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.

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

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

Alan

[Tadeusz Pycio]

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]

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

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

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]

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

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

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]

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]

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]

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

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

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]

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.

Any thoughts? Let me know, please.

Cheers, P.

[Alan Cox]

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]

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]

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]

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.

Please also visit clrhome.org so that their Google Analytics count goes up.

[Phillip Stevens]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

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.

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.

I

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]

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]

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]

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.

 Cheers, Phillip

[Alan Cox]

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]

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

[Phillip Stevens]

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]

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]

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?

[Phillip Stevens]

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

Hmm. More complex than I'd hoped.

P.

[Alan Cox]

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]

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.

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]

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.

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

[Phillip Stevens]

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.

[Phillip Stevens]

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.

Some good news, the revised circuit for generating /MREQ and /IORQ is working.

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.

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]

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.

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]

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.

I've still some 8085 Module PCBs available on Tindie.

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]

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]

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]

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. 

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.

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.

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

Cheers, Phillip

[Chris Odorjan]

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]

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.

I'm calling the Microsoft Basic 4.7c support for the 8085 CPU Module (optionally 8085 with the Am9511A APU Module) release v2.2.

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]

How does the Floating Point performance of the AM9511 compare to the performance of a Raspi Zero?

[Phillip Stevens]

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]

:-)

"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

em: do...@doughq.com

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]

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]

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]

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

em: do...@doughq.com

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 

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/c5901e5c-c3a3-4cad-980c-252044c7e09cn%40googlegroups.com.

[Phillip Stevens]

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.

I'm calling the Microsoft Basic 4.7c support for the 8085 CPU Module (optionally 8085 with the Am9511A APU Module) release v2.2.

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.

Some notes on the instructions had learning here.

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]

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.

 

Cheers, Phillip

[Phillip Stevens]

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.

[Phillip Stevens]

On Saturday, 30 October 2021 Phillip  wrote:

 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.

Some notes on the instructions had learning here.

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...

Again, I got a bit diverted into another (worthwhile) endeavour. But life's more interesting down the side roads anyway.

The z88dk string functions (including the memory copy and memory set functions) were using a slower loop mechanism (24 ticks), which relied on comparing the BC register to zero via the A register. There is a faster way to do it using split high and low decrements, which imposes about half the loop overhead (about 14 ticks) and preserves the A register. So taking this as a basis I've redone all the z88dk string functions. Also many string functions were not enabled for callee, which has now been improved too.

Old code example.

.asm_example

    ;
.loop
    ; stuff to copy / set etc
    dec bc        ; 6
    ld a,b        ; 4
    or c          ; 4
    jp NZ,loop    ; 10

New code example.

.asm_example
    dec bc         ; 6
    inc b          ; 4
    inc c          ; 4
.loop
    ; stuff to copy / set etc
    dec c          ; 4
    jp NZ,loop     ; 10
    dec b          ; 4
    jp NZ,loop     ; 10

 

Overall, after these few months of learning about the 8085 I've got to say it feels like a much more polished object than the Z80.

By that I mean the designers took something very good in the 8080 and tweaked, stretched, and polished to make it great. I like working with it, now that I've understood reasoning behind it more fully.

In contrast, the Z80 design is a major revision with more than twice as many registers, but an incomplete set of opcodes (eg limiting access between register sets), and inheriting some of the failures of the 8080 too.

I'm sure everyone has their opinion, but the only thing I'd change about the 8085 would be to allow pop/push af (PSW) to be generally useful by enabling the final flag bit to store state (as is done in the Z80). That would enable another 16-bit register for stack management at the cost of just one flip-flop.

So, some new foundations to build a new version of CP/M-IDE specifically for 8085 CPU (more on another thread).

And, back to building a new floating point library for the 8085 (and trying to beat the Microsoft implementation).

Happy New Retro Year.

Phillip

[Phillip Stevens]

On Thursday, 30 December 2021 Phillip wrote:

Overall, after these few months of learning about the 8085 I've got to say it feels like a much more polished object than the Z80.

By that I mean the designers took something very good in the 8080 and tweaked, stretched, and polished to make it great. I like working with it, now that I've understood reasoning behind it more fully.

I'm sure everyone has their opinion, but the only thing I'd change about the 8085 would be to allow pop/push af (PSW) to be generally useful by enabling the final flag bit to store state (as is done in the Z80). That would enable another 16-bit register for stack management at the cost of just one flip-flop.

And, back to building a new floating point library for the 8085 (and trying to beat the Microsoft implementation).

I've just committed support for the Am9511 (Intel 8231) APU math library for the 8085 CP/M target within z88dk.

We've got MS Basic for 8085 and for 8085+Am9511.

And now CP/M for 8085 which supports both/either Microsoft MBF32 math and Am9511 APU compiled C or assembly programs.

So now the 8085+Am9511 support is pretty much rounded out and complete.

To use the APU math library with CP/M, the library just needs to be linked with --math-am9511_8085. For example

zcc +cpm -clib=8085 -v -O2 n-body.c -o nbody --math-am9511_8085 -lndos -create-app

Just working through some benchmarks with my CP/M System now.

The Whetstone Benchmark for RC2014 results are:

• 8085+MBF32 -> 78.2 Seconds -> 12.8 kWhetstone.
• 8085+AM9511 -> 30.4 Seconds. -> 32.9 kWhetstone.

And for the n-body Benchmark the RC2014 results are:

• 8085+MBF32 -> 252.3 Seconds.
• 8085+AM9511 -> 69.3 Seconds.

So the the 8085+APU system is 2.5x to 3.6x faster than the best 8085 software maths library.

And what is very interesting is that these numbers align very closely with the Z80 results.

Phillip

[Todd Decker]

Phillip,

I'm checking the BOM of the 8085 card against my parts inventory.  I have many of the needed chips in the HCT family but not in the specified AHCT family.  Are they close enough that I would be okay using my stock instead of ordering new?  Or, are they going to be too slow?

P. Todd

[Phillip Stevens]

I'm checking the BOM of the 8085 card against my parts inventory.  I have many of the needed chips in the HCT family but not in the specified AHCT family.  Are they close enough that I would be okay using my stock instead of ordering new?  Or, are they going to be too slow?

You're totally OK to use HCT or even HC parts if you want. No issue at all.

In fact, if you look at the pictures closely you'll see that I couldn't even find a AHCT573 device, so had to substitute a AHC573.

The reason that AHC(T) devices are preferred is that they are a later generation of logic, and (according to the data sheets and tech documents) have a much slower slew rate and lower drive than HC(T) which means that they are less susceptible to producing ground bounce or other bus related ills. AHC(T) logic devices are much faster though, because they have less internal delay, and they also consume much less power so they are better all round.

Good luck with your build.

P.

[Mark T]

Hi Phillip,

I think you might be confusing HC(T) with AC(T). AC(T) can cause problems with overshoot and undershoot when driving transmission lines, this is normally reduced by adding a series resistor to the output of AC(T).

From Nexperia data sheets for ‘00

HC(T) transition time is 6ns.

AHC(T) transition time is 3ns.

Unfortunately I couldn’t find the transition times for AC(T).

Mark

[Phillip Stevens]

Mark T wrote:

I think you might be confusing HC(T) with AC(T). AC(T) can cause problems with overshoot and undershoot when driving transmission lines, this is normally reduced by adding a series resistor to the output of AC(T).

There's been a few discussions in this place about the CF Module, and how ground bounce arises from the CF card, and potentially driving the CF Module.

So, whilst I'm not using the CF Module, it is good to try to get the "best" buffer drive characteristics for the RC2014 bus.

I've understood that ground bounce can be mitigated by having slower slew rates, and that's a feature of the AHC(T) family vs HC(T) family.

At least that's what TI says in their Designer's Guide (switching diagram attached).

HC is -0.9V/ns slew whereas AHC is -0.8V/ns slew, yet the total switching time is reduced substantially.

And the power consumption of AHC is also substantially lower, for what it is worth.

But, the AC(T) logic is certainly showing the undershoot that you're describing.

Cheers, P

[Mark T]

Hi Phillip,

That “design guide” looks to be more of a marketing presentation than a design guide. They seem to be cherry picking the data they present and don’t give details of the test methods.

Also raises some questions about their choices. Why show typical performance of the ‘244 and then switch to ‘245, so they can include the wide bus devices in the advantages instead of showing performance of the ‘245? Why is the Vi showing a better transition time than any of the output traces, how do they perform when driven by the same family? What’s with using a 50 ohm load when all the specs use 1k and 50pF? They quote 18ns propagation delay for 74hct245 in the table, but in TI spec this is 14ns.

I think the choice for driving a bus would be between 74HC(T) or 74AHC(T), with the second chosen if higher speed was needed, but not convinced by their design guide that AHC(T) is significantly better beyond speed.

Mark

[Todd Decker]

Thank you, Phillip.  I appreciate your help and your efforts with this board.  In my youth, I designed a single-board computer based around the 8085 that I never built.  It will be amazing to have an 8085-based version of the RC2014 family if I can get it to work.

P. Todd

[Phillip Stevens]

Todd wrote:

Thank you, Phillip.  I appreciate your help and your efforts with this board.  In my youth, I designed a single-board computer based around the 8085 that I never built.  It will be amazing to have an 8085-based version of the RC2014 family if I can get it to work.

I hope that it goes well. Let me know if you've concerns about anything.

I've been intending to write a how-to for CP/M-IDE 8085.

In short you can just burn the hex file to a EEPROM and then you can test both RAM and IDE Modules are working as expected, then drag some CP/M drives onto a CF or SSD drive and go.

Or, you can do the same testing with MSBasic for 8085 or for 8085 with APU Module.

But the more interesting process is to document how to build your own custom solution from source if you'd like to.

There's quite a few steps that need to be done in order, but here's not the place to write this down because I can't edit later to fix or update instructions if things change.

Once again. Good luck.

Phillip

[Todd Decker]

I'd be interested in the more interesting process, Phillip.  The whole reason I'm getting into the RC2014 platform is to learn things from the ground up over semi-plug and play.  I have much to learn

P. Todd

[Phillip Stevens]

Added a few more sections on the end of CP/M-IDE for RC2014.

I think that covers most of the things needed to understand how a C shell is useful for CP/M, and where all the pieces of code come from, and why they're used.

I've written a first draft of a "how to" and a "why it exists" for CP/M-IDE for RC2014 on my site.

No coloured pictures. Quite terse, and a bit disorganised for now.

But hopefully covers the points to be able to replicate the final HEX file.

Todd wrote:

I'd be interested in the more interesting process, Phillip.  The whole reason I'm getting into the RC2014 platform is to learn things from the ground up over semi-plug and play.  I have much to learn.

[Phillip Stevens]

As I'm planning to be mainly unavailable for a longish while, and so my Tindie store will be on vacation more often than not, I've published the design on Seeed Studio Fusion.

The PCBs for the 8085 CPU Module can be ordered there, or the Gerberfile used to order at your favourite vendor.

Seeed Studio - 8085 CPU Module for RC2014

Cheers, Phillip

Great that the older Intel HMOS 8085AH-2 part has no problem running at 7.3728MHz.

[Phillip Stevens]

Phillip Stevens wrote:

As I'm planning to be mainly unavailable for a longish while, and so my Tindie store will be on vacation more often than not, I've published the design on Seeed Studio Fusion.

The PCBs for the 8085 CPU Module can be ordered there, or the Gerberfile used to order at your favourite vendor.

Seeed Studio - 8085 CPU Module for RC2014

Just noted that Spencer has finally obtained the unobtainable 82c55 devices for his IDE Hard Drive Module and has them for sale on Tindie and z80kits.

I guess even a 78 week lead time comes to an end, eventually.

I mention that because I've only 6 remaining 8085 CPU Module PCBs left on Tindie, and 8085 CP/M-IDE needs the IDE Hard Drive Module.

So if you're interested in having an 8085 CP/M computer, compatible with the RC2014 bus, then this is the chance.

This shows the 4 Module CP/M-IDE, with ACIA Module, IDE Hard Drive Module, Memory Module, and 8085 CPU Module.

Once these 6 are gone, then the next option will be either the Gerbers (or PCB order) from Seeed Studio as noted above.

For reference, this is how it looks on the terminal.

Cheers, Phillip

[Todd Decker]

Thank you, Phillip!  I saw that and ordered the IDE hard drive module.  It should be at my home when I return from vacation on July 5.  I think I have the other modules.  I’ll keep in touch

THANK YOU!

P. Todd

On Jul 2, 2022, at 9:17 AM, Phillip Stevens <phillip...@gmail.com> wrote:

Phillip Stevens wrote:

As I'm planning to be mainly unavailable for a longish while, and so my Tindie store will be on vacation more often than not, I've published the design on Seeed Studio Fusion.

The PCBs for the 8085 CPU Module can be ordered there, or the Gerberfile used to order at your favourite vendor.

Seeed Studio - 8085 CPU Module for RC2014

Just noted that Spencer has finally obtained the unobtainable 82c55 devices for his IDE Hard Drive Module and has them for sale on Tindie and z80kits.

I guess even a 78 week lead time comes to an end, eventually.

I mention that because I've only 6 remaining 8085 CPU Module PCBs left on Tindie, and 8085 CP/M-IDE needs the IDE Hard Drive Module.

So if you're interested in having an 8085 CP/M computer, compatible with the RC2014 bus, then this is the chance.

This shows the 4 Module CP/M-IDE, with ACIA Module, IDE Hard Drive Module, Memory Module, and 8085 CPU Module.

<IMG_1688.jpeg>

Once these 6 are gone, then the next option will be either the Gerbers (or PCB order) from Seeed Studio as noted above.

For reference, this is how it looks on the terminal.

<cpm-idev6.png>

Cheers, Phillip

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/qo7nfDZmY-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/9d5ae64e-a910-494a-95d6-db1b566b1249n%40googlegroups.com.
<cpm-idev6.png><IMG_1688.jpeg>

[Spencer Owen]

On Sat, 2 Jul 2022 at 14:17, Phillip Stevens <phillip...@gmail.com> wrote:

Just noted that Spencer has finally obtained the unobtainable 82c55 devices for his IDE Hard Drive Module and has them for sale on Tindie and z80kits.

I guess even a 78 week lead time comes to an end, eventually.

Well, the 25 chips I ordered back in October arrived. They were almost double the price I paid a couple of years or so ago, and ordering any more still looks like a 2024 delivery date. So, whilst this is a good news blip, we're far from seeing the end of component shortages.

Spencer 

[Phillip Stevens]

Phillip wrote:

Added a few more sections on the end of CP/M-IDE for RC2014.

I think that covers most of the things needed to understand how a C shell is useful for CP/M, and where all the pieces of code come from, and why they're used.

Todd wrote:

I'd be interested in the more interesting process, Phillip.  The whole reason I'm getting into the RC2014 platform is to learn things from the ground up over semi-plug and play.  I have much to learn.

I had occasion to dig into 8085 code generation for our z88dk compiler, sccz80, over the last few days, and I love to see again how the addition of a few (undocumented) instructions makes the 8085 CPU so much more effective than the z80.

Compare the code fragments for a 32 bit subtraction for 8080, 8085, gbz80, and z80. Using the sub hl,bc instruction the 8085 uses 2 Bytes fewer than the z80 and is still 16 cycles faster.

Similarly, using the rl de instruction (1 byte, 10 cycles), quick multiplication on 8085 is much faster than on z80 using rl e, rl d instructions (4 bytes, 16 cycles).

It is such a pity that the engineers who designed the additions didn't get to release those extra instructions because of "marketing strategy".

Marketing departments be damned.

More reading on the 8085 here.

Cheers, Phillip

[Phillip Stevens]

On Saturday, 10 September 2022 Phillip wrote:

I had occasion to dig into 8085 code generation for our z88dk compiler, sccz80, over the last few days, and I love to see again how the addition of a few (undocumented) instructions makes the 8085 CPU so much more effective than the z80.

It is such a pity that the engineers who designed the additions didn't get to release those extra instructions because of "marketing strategy".

Marketing departments be damned.

More reading on the 8085 here.

We've been adding more and better 8085 optimisation into the z88dk over the past weeks. The focus has been on the use of ld de,sp+n and ld de,hl+n with ld hl,(de)instructions. These undocumented 8085 instructions allow efficient access into structures, saving many bytes and cycles over the equivalent z80 ld hl,n and add hl,sp instructions.

With the optimisation process complete the sccz80 compiler is probably now the best ever 8085 compiler, given that period authentic 8085 compilers would not have had access to the undocumented instructions as we do today.

Specifically the 8085 acia version of CP/M-IDE is more than 1,500 bytes smaller than the z80 version (28178 bytes versus 29767 bytes). This saving comes mainly from the FAT file system library, where access into structures is very common. The CCP/BDOS/BIOS code is essentially the same as the original DRI 8080 code, and doesn't contribute much to the relative savings.

Pity there are not too many 8085 fanbois left these days. ;-)

Phillip

[Alan Cox]

> With the optimisation process complete the sccz80 compiler is probably now the best ever 8085 compiler, given that period authentic 8085 compilers would not have had access to the undocumented instructions as we do today.

Some of them did, especially later on. Once everyone knew about the
instructions they got used. Even the Small C for 8085 uses them.

> Specifically the 8085 acia version of CP/M-IDE is more than 1,500 bytes smaller than the z80 version (28178 bytes versus 29767 bytes). This saving comes mainly from the FAT file system library, where access into structures is very common. The CCP/BDOS/BIOS code is essentially the same as the original DRI 8080 code, and doesn't contribute much to the relative savings.

Sounds about right - my ANSI 8085 C compiler produces much more
compact code than the Z80 one, and usually faster. That's without
having taught it how to use the spare BC register pair as register
variables.

Alan

[Phillip Stevens]

Glad that you're still a fanboy too. :-)

The more I learn about the 8085, the better I like it.

Where did you get the ANSI 8085 C compiler? Is it public domain?

I'm planning to do some more 8085 benchmarking over the coming weeks, so I'd love to add it into this numbers game.

Cheers, Phillip

[Alan Cox]

Where did you get the ANSI 8085 C compiler? Is it public domain?

I'm planning to do some more 8085 benchmarking over the coming weeks, so I'd love to add it into this numbers game.

It's the one I've been writing. I have been using 8085 as the initial target to actually bring it up fully because 8085 is nice and logical, as well as 8080 basically being 8085 with helpers.

https://github.com/EtchedPixels/Fuzix-Compiler-Kit

 

At this point it's getting most stuff right. I need to find some time to sit down and wire a proper test suite to it to knock out the remaining bugs. As it stands it'll build the entire Fuzix tree but something goes boom in user space I think with /bin/sh that needs pinning down further.

Alan

[Phillip Stevens]

On Monday, 30 January 2023 Phillip wrote:

> With the optimisation process complete the sccz80 compiler is probably now the best ever 8085 compiler, given that period authentic 8085 compilers would not have had access to the undocumented instructions as we do today.

> Specifically the 8085 acia version of CP/M-IDE is more than 1,500 bytes smaller than the z80 version (28178 bytes versus 29767 bytes). This saving comes mainly from the FAT file system library, where access into structures is very common. The CCP/BDOS/BIOS code is essentially the same as the original DRI 8080 code, and doesn't contribute much to the relative savings.

I'm planning to do some more 8085 benchmarking over the coming weeks.

So I've been doing some benchmarking of the z88dk 8085 support over the past days, and the results look pretty good.

As background the z88dk sccz80 compiler is derived (a very long time ago) from the Small C compiler, but it is being continuously developed to this day. It can do pretty much everything that the sdcc compiler can do, but it works in different way. As sccz80 is derived from an 8080 based compiler it uses the HL and DE registers for almost everything, and uses stack access via HL for its Z80 support. In contrast the sdcc uses the IX register for stack access almost exclusively. The benchmarks don't call convincingly for one or the other strategy.

In z88dk the output of the sccz80 compiler is passed through an optimisation tool (copt) which uses rules to improve the "generic" compiler generated code. There are rules for z80 by default, and different rules for the 8085 (and gbz80, and rabbit, etc).

The recent work has been generating rule set for the 8085 that translates the compiler generated z80 stack access to 8085 undocumented instructions, which are much faster and smaller than their z80 equivalents. This is particularly effective where arrays or structures are being accessed, and a pointer to the array or structure is passed into the function and an offset reference needs to be calculated from that pointer to access the element.

Anyway, cutting to the chase, in a head-to-head competition (sccz80 compiler & classic library) the 8085 comes out ahead of the z80 in two benchmarks, and is actually the fastest of all compiler and z80 machine combinations in the binary-trees benchmark. An overview of the compilers and benchmark tools is on the wiki.

There is still a gap because there isn't a "modern" IEEE single precision 8085 floating point library available. We're relying on the Microsoft Basic floating point or the DAI floating point libraries. But these are both quite good and it would be only a small (if any) gain to rewrite them. And also there is support available within z88dk for the APU Module with the 8085 CPU, which is about 3x faster than any software, so there's little motivation to plug the gap.

Hope that's interesting.

P.

[Tadeusz Pycio]

Hi Phillip,

You're tempting me to familiarise myself with this 8085 module :)
I guess I'll have to design your module, as the Gerber files won't accept JLC, and buying on Tindie is out - shipping is a couple of new designs from the PCB factory :( I will look into this at my leisure.

[Phillip Stevens]

On Friday, 3 February 2023 Tadeusz wrote:

I guess I'll have to design your module, as the Gerber files won't accept JLC, and buying on Tindie is out - shipping is a couple of new designs from the PCB factory :( I will look into this at my leisure.

I can run a cam job for any PCB manufacturer from my Eagle. Just let me know where, and I'll find their cam files.

Happy to have another 8085 supporter in the house. :-)

Phillip

[Bill Shen]

Very tempting, just like Tadeusz said.  I have designed a 8085 plug-in for GRC (not RC2014), now I'm interested to get it up and running.
  Bill

[Dave White]

I'd be interested in making one too. I have four 8085 chips sitting here looking for a use. I'd also be using JLCPCB for boards, so if you could make Gerbers compatible with them, that would help a few of us out.

[Alan Cox]

On Fri, 3 Feb 2023 at 19:34, Dave White <mrgcm...@gmail.com> wrote:
>
> I'd be interested in making one too. I have four 8085 chips sitting here looking for a use. I'd also be using JLCPCB for boards, so if you could make Gerbers compatible with them, that would help a few of us out.

If it helps, the files for the one I did are on hackaday, and if you
are in the UK I may have a spare or two left for postage cost.

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

Currently running mine with an 8MHz Tundra 80C85.

Alan

[Dave White]

Ah, no, thanks for the offer. I'm a Brit is the US (for now, retiring back to the UK in a few years).

[Tadeusz Pycio]

Sorry for the offtopic, but it's sad that in this day and age we can't support the efforts of makers because it's cheaper to produce in a Chinese factory with shipping than postage and duty from a private individual. I don't know where the world is going.

[Phillip Stevens]

On Sat, 4 Feb 2023 Dave wrote:

I'd be interested in making one too. I have four 8085 chips sitting here looking for a use. I'd also be using JLCPCB for boards, so if you could make Gerbers compatible with them, that would help a few of us out.

Tadeusz has just ordered via JLCPCB and found they complain about my Gerbers (don’t like the Hollerith outline IDK). So he made some adjustments.

I have them here attached.

Hope they work for you.

--

Sent from a Mobile Device. Replies may appear terse.

[Dave White]

Thanks Phillip (and  Tadeusz), I'll order some up when I send me next order in. I'm working on a board for Bill's MB020 to eliminate the need for the three RC2014  support  boards by combining the three features (ROM, serial and storage) into one. As soon as that's done I'll send in an order.

[Bill Shen]

Oh, "missing module" for MB020 and that also works for RC2014, a great idea!  Please send me a blank board and I like to work with you developing the software for it.  I can see ROM, CF or SD, and serial port, but are you also thinking of  DS1302 RTC, I2C bus, and/or SPI?
  Bill

[Dave White]

I'd originally thought of just replacing the three boards needed to allow it to run CP/M 68, but I guess I could add an RTC and the other busses. As you already know, I'm going to be out of action for the next few weeks, but as soon as I get the board pulled together I'll send you a blank.

[Phillip Stevens]

On Monday, 30 January 2023 Phillip wrote:

I'm planning to do some more 8085 benchmarking over the coming weeks.

Recently Tadeusz published a link to a Mandelbrot test program (in English via Translate) with a number of interesting benchmark reference points.

The benchmark is easy to use to get a reference for the Z80, on a standard RC2014 Classic ][ with Microsoft Basic 4.7.

But I think it is interesting for this thread is to see what happens when the Z80 CPU Module is replaced by a 8085 CPU Module and, as an extension, what happens with the further addition of an APU Module.

RC2014 Classic ][ (7.37MHz) + 8085 CPU             = 151 sec

RC2014 Classic ][ (7.37MHz) + 8085 CPU + APU = 113 sec

P.

[Tadeusz Pycio]

Long delay, but I managed to complete the whole thing (PCB, CA80C85B-8CP), so time to assemble.

[Tadeusz Pycio]

A fully functional 8085 computer running under CP/M-IDE

[Phillip Stevens]

On Saturday 7 May 2022, Phillip Stevens wrote:

As I'm planning to be mainly unavailable for a longish while, and so my Tindie store will be on vacation more often than not, I've published the design on Seeed Studio Fusion. The PCBs for the 8085 CPU Module can be ordered there, or the Gerberfile used to order at your favourite vendor.

Seeed Studio - 8085 CPU Module for RC2014

Great that the older Intel HMOS 8085AH-2 part has no problem running at 7.3728MHz.

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.

Just to update on the 8085 CPU thread, I've ordered another set of 10x PCBs for the 8085 CPU Module, the 8231A APU Module, and 128k Memory Module, since they've been sold out from my Tindie store for some time. I'm expecting the new PCBs to arrive around the 12th December, and will ship them as soon as possible.

Because shipping from Australia is an expensive PITA, the best way to order is to add the two additional PCBs as options to the order for the first one, then you'll only be charged for shipping once.

To build a RC2014 CP/M system with a 8085 CPU heart, I'd suggest using the above PCB set, together with the CF Module V2.0 and the Tynemouth 68B50 Serial Module, on a standard 40 pin backplane. A RC2014 Classic ][ Kit is a good starting point to get the standard backplane and RC2014 ACIA (68B50) Serial Module as a base. 

If you don't want to go straight to CP/M, or don't want to get a CF Module or 64k Memory Module, then the standard MS Basic solution for the Classic ][ is also supported with the 8085 CPU Module.

Alternatively, you can use the RC2014 IDE Hard Drive Module to attach a Winchester Disk (IDE hard drive) or any other PATA standard device (e.g. CF in native 16 bit IDE mode, Disk on Module DOM, or SSD), and run CP/M with the 8085 CPU off spinning rust storage.

See the rest of this thread on 8085 support from the z88dk C compiler, assembler and development tools, and benchmarks vs the z80 CPU.

Cheers, Phillip