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