8085 setup

[Keith S]

I've been putting together a 8085 based system using the backplane pro, the 8085 cpu card and memory module card from Phillip, the Tynemouth 68B50 card and the CF v2.0.

Burnt the 'rc2014-8085cf-cpm22.hex' file into a 27C256 (and verified it). Formatted a blank CF card as FAT32. Then connected to the ACIA using Putty from a PC at 115200 baud.

So far, there has been largely no signs of life, but every now and then I get a tantalising message 'Bdos error on A: Select. ANd one an 'Exit from CP/M'. So something's working (including the serial link).

The LED on the CF card rarely comes on, and the tx/Rx leds on the ACIA never do (should they?)

Any pointers for what to try ?

Keith

[Phillip Stevens]

Hi Keith,

From what you're describing, it sounds like you have a marginal power source.

The 8085 CPU will not run off a USB power supply at all. And this would be compounded by the presence of the CF Module (and potentially the APU Module, if it was inserted).

For reference I'm using the Backplane-8 with a 1A 7805 replacement device. For the PRO Backplane to use a 2A 5V wall-wart would be my suggestion.

The OKI and Tundra devices are CMOS, but the Intel H2 devices are NMOS and they (alone) require over 200mA at 7MHz.

The rest of the 8085 Module is also quite high current, with 6x devices additional devices of which 3x are 8 line buffer devices, where each line can source up to about 8mA.

Once your 5V power is OK, you can start with just the ACIA, 8085 CPU, and Memory Modules. You should be able to see a sensible response from the shell, that you can type into, without any CF (or IDE) Module.

You should see, something like this using 115200 8n2.

>

RC2014 8085 CF - CP/M-IDE
feilipu 2024

> :-)

> md 0
Origin: 0000
0000: C3 80 00 00 00 00 00 00 C3 46 00 5A 38 38 44 4B .........F.Z88DK
0010: C3 46 00 32 2E 33 30 00 C3 46 00 00 00 00 00 00 .F.2.30..F......
0020: C3 46 00 00 C3 46 00 00 C3 46 00 00 C3 65 0C 00 .F...F...F...e..
0030: C3 46 00 00 C3 75 01 00 C3 65 0C 00 C3 65 0C 00 .F...u...e...e..
0040: C3 65 0C E1 E1 E1 C9 1B 1B 1B C9 0B 0B 0B C9 77 .e.............w
0050: 23 77 23 77 23 77 23 77 23 77 23 77 23 77 23 77 #w#w#w#w#w#w#w#w
0060: 23 77 23 77 23 77 23 77 23 77 23 77 23 77 23 C9 #w#w#w#w#w#w#w#.
0070: 23 23 23 23 23 23 23 23 C9 00 00 00 00 00 00 00 ########........
0080: 31 00 DC 21 DB 6C 11 00 80 01 5B 00 CD 69 0D 21 1..!.l....[..i.!
0090: 5B 80 01 46 0B 36 00 23 0B DD 95 00 21 5D 80 36 [..F.6.#....!].6
00A0: 13 21 67 80 36 15 21 71 80 36 15 21 A2 8B 22 C2 .!g.6.!q.6.!..".
00B0: 80 EB 38 00 EB EB 21 C2 80 4E 23 46 03 AF 77 2B ..8...!..N#F..w+
00C0: 77 EB 08 54 5D 10 10 3E 3F A4 67 EB 7D 93 6F 7C w..T]..>?.g.}.o|
00D0: 9A 67 C5 E5 CD 05 08 3E 03 D3 80 3E 92 32 B4 FE .g.....>...>.2..
00E0: D3 80 21 00 FF 22 AB FE 22 AD FE 21 E0 FE 22 B0 ..!..".."..!..".
00F0: FE 22 B2 FE AF 32 AA FE 32 AF FE 3E 1D 30 21 13 ."...2..2..>.0!.

> 

Once you can see something like that, then you can insert the CF Module (or IDE Module if you used the ROM for that instead).

Let us know if that step helps, and then we can dig deeper.

Good luck, Phillip

[Phillip Stevens]

On Thursday 4 April 2024, Keith S wrote:

I've been putting together a 8085 based system using the backplane pro, the 8085 cpu card and memory module card from Phillip, the Tynemouth 68B50 card and the CF v2.0.

Burnt the 'rc2014-8085cf-cpm22.hex' file into a 27C256 (and verified it). Formatted a blank CF card as FAT32. Then connected to the ACIA using Putty from a PC at 115200 baud.

So far, there has been largely no signs of life, but every now and then I get a tantalising message 'Bdos error on A: Select. ANd one an 'Exit from CP/M'. So something's working (including the serial link).

The LED on the CF card rarely comes on, and the tx/Rx leds on the ACIA never do (should they?)

 

 On Friday 5 April 2024, Phillip Stevens wrote:

From what you're describing, it sounds like you have a marginal power source.

The 8085 CPU will not run off a USB power supply at all. And this would be compounded by the presence of the CF Module (and potentially the APU Module, if it was inserted).

For reference I'm using the Backplane-8 with a 1A 7805 replacement device. For the PRO Backplane to use a 2A 5V wall-wart would be my suggestion.

Once you can see something like that, then you can insert the CF Module (or IDE Module if you used the ROM for that instead).

Once your shell is responding, then you can check your CF Module by doing a forced mount (mount 1) and disk status (ds).

This checks the diskio level (Media Access Interface) and physical connectivity to the CF Card (or PATA Drive).

RC2014 8085 CF - CP/M-IDE
feilipu 2024

> :-)

> mount 1
rc=0 FR_OK

> ds
FAT type = FAT32
Bytes/Cluster = 4096
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 1944
Number of clusters = 248342
Volume start (lba) = 8192
FAT start (lba) = 8224
DIR start (lba,cluster) = 2
Data start (lba) = 12112

And finally a directory listing (ls) to check your FATFS disk formatting is OK.

Usually in day-to-day operation I will cut directly to a ls, as this does the disk mount function implicitly, before loading CP/M with the cpm command.

RC2014 8085 CF - CP/M-IDE
feilipu 2024

> :-)

> ls
----A 2020/04/01 10:01   8388608  TEMPLATE.CPM
----A 2020/04/26 12:19   8388608  BBCBASIC.CPM
----A 2020/04/26 12:37   8388608  USER.CPM
----A 2020/04/26 12:20   8388608  MSBASCOM.CPM
----A 2020/04/26 12:20   8388608  MSCOBOL.CPM
----A 2020/04/26 12:21   8388608  ZORK.CPM
----A 2020/04/26 12:18   8388608  SYS.CPM
----A 2022/06/12 15:42   8388608  HITECHC.CPM
----A 2020/04/01 10:01   8388608  USR.CPM
----A 2020/01/01 00:00   8388608  3D.CPM
----A 2020/01/01 00:00   8388608  TEST.CPM
----A 2022/07/10 19:52   8388608  TURBOP.CPM
----A 2020/05/03 13:18   1048576  RANDOM1.TXT
----A 2020/04/01 10:01   8388608  MUSIC.CPM
----A 2024/02/26 07:08   8388608  ITDARK.CPM
  15 File(s), 118489088 bytes total
   0 Dir(s),  898715648 bytes free

To avoid doubt, the first time you're using a new CP/M drive, it is worthwhile to check it has been copied to the CF Card (or PATA disk), by using the frag command.

It will take a while to complete, reading through 8MByte at about 200kByte/s.

> frag user.cpm
Checking "user.cpm" at LBA 536576 is OK

> frag itdark.cpm
Checking "itdark.cpm" at LBA 694280 is OK

And then finally, you can load CP/M using the cpm command, with any of up to 4 concurrent disks.

Usually I will put the disk based system utilities first in the A: drive, but that's just for convenience.

Just to note, it doesn't matter where the CP/M drive file is stored on the disk. The initial LBA is used to reference into the CP/M drive.

Any drive file can be stored anywhere, in any directory. Just give the full path when loading it.

> cpm sys.cpm usr.cpm hitechc.cpm turbop.cpm
Opening "sys.cpm" at LBA 589832
Opening "usr.cpm" at LBA 487352
Opening "hitechc.cpm" at LBA 552960
Opening "turbop.cpm" at LBA 520176
Initialised CP/M

A>

Good luck, Phillip

[Keith S]

Good point about the power supply. I am using an Apple ipad USB supply capable of some 2A to power the board via the barrel jack. Looking at the VDD line with the scope (C4 in the pic below) , with the CF card connected its about 4.95v mean, or 5.04v with the CF disconnected. The peak to peak value is~2.4v in both cases, i.e. the supply is about 5v +/- 1.2v, or dips down to 3.8v minimum at or around the clock frequency. I wonder if that's enough to prevent a 5MHz 80C85 from working correctly?

Also looking at the waveform, I see the INT line going low about 5us after the SIO has received a character from the PC.. But there is not a clean 'goes low, stays low for a while'. It changes state multiple times initially, before staying low for about 10us. What is the expected behaviour of INT?

I'll see if some on board decoupling cap can reduce the VDD noise next.

Keith

[Phillip Stevens]

On Friday 5 April 2024, Keith S wrote:

Good point about the power supply. I am using an Apple ipad USB supply capable of some 2A to power the board via the barrel jack. Looking at the VDD line with the scope (C4 in the pic below) , with the CF card connected its about 4.95v mean, or 5.04v with the CF disconnected. The peak to peak value is~2.4v in both cases, i.e. the supply is about 5v +/- 1.2v, or dips down to 3.8v minimum at or around the clock frequency. I wonder if that's enough to prevent a 5MHz 80C85 from working correctly?

To the question as to whether the +/- 1.2V on the supply line could cause an issue, I would still guess that it is the cause.

You are seeing some sensible text outputs. These things don't happen randomly, so things are mostly working.

The CF Card is a particularly high consumer of current, so perhaps try with that Module removed initially.

I'm a bit OCD about supply stability. All my Modules use 4 layer routing, with one internal layer +5V and the other GND. I use decoupling caps on every device.

On my backplanes I have substituted one of the decoupling caps with a Tantalum 100uF across the rails (and usually put the CF Module close by) and use 47uF on both input and output of the 7805 device (which has its own power capacitor of 10uF too).

I also replicated both the +5V and GND lines with extra copper on the back side.

Probably overkill, but it costs almost nothing to add some wire and a few caps.

So try without the CF Module first, to see how you get on.

Good luck, Phillip

[Keith S]

Thanks, I'll try adding decoupling to see if I can reduce the noise. I did try removing the CF card, made no difference to how it is behaving, but it didn't change the noise much either.

Can you say anything about the INT signal? I'm assuming this is generated by the 68B50 every time it's received a character, would that be correct? And so it should go low (as I'm seeing it does, ~5us after a key press) then go high after the interrupt has been serviced (about 10us later). The fact that its going low/high erratically at first (a bit like key bounce) doesn't seem right to me.

Keith

[Phillip Stevens]

On Friday 5 April 2024, Keith S wrote:

Thanks, I'll try adding decoupling to see if I can reduce the noise. I did try removing the CF card, made no difference to how it is behaving, but it didn't change the noise much either.

Can you say anything about the INT signal? I'm assuming this is generated by the 68B50 every time it's received a character, would that be correct? And so it should go low (as I'm seeing it does, ~5us after a key press) then go high after the interrupt has been serviced (about 10us later). The fact that its going low/high erratically at first (a bit like key bounce) doesn't seem right to me.

Yes, I agree that the /INT signal looks weird. But, I believe you have used the Tynemouth ACIA Module previously, so that is proven good.

So I think this weirdness is from the power stability.

If you have not used the Tynemouth ACIA Module before, then using your proven Z80 CPU you could try to burn a Basic ROM designed for Z80+ACIA and see what you get.

In fact, you can use this to test first the 8085 CPU only, by using the Basic for 8085 Module. Then test later for Z80+APU Module.

Regards, Phillip

[Phillip Stevens]

On Friday 5 April 2024, Keith S wrote:

Thanks, I'll try adding decoupling to see if I can reduce the noise. I did try removing the CF card, made no difference to how it is behaving, but it didn't change the noise much either.

Can you say anything about the INT signal? I'm assuming this is generated by the 68B50 every time it's received a character, would that be correct? And so it should go low (as I'm seeing it does, ~5us after a key press) then go high after the interrupt has been serviced (about 10us later). The fact that its going low/high erratically at first (a bit like key bounce) doesn't seem right to me.

Another quick thought is to check you've removed the power supply link from the ACIA Module.

Having the +5V supply fighting with the USB interface +5V line is also bad. Will lead to bad / odd behaviour.

 

[Keith S]

So I soldered 6 x 10uF tantalums onto the backplane, one every other slot. That does seem to have cleaned up the INT signal; it now goes low after a keystroke and stays low for the 10us or so. Key presses are echoed as before so I believe the ACIA is working OK (yes I had removed the 5v link).

One interesting fact: if I type 'cpm' I get a response:

cpm

rc= FR_

Just those characters, and it's reproducible -every time. Mean anything?

Keith

[Phillip Stevens]

On Friday 5 April 2024, Keith S wrote:

So I soldered 6 x 10uF tantalums onto the backplane, one every other slot. That does seem to have cleaned up the INT signal; it now goes low after a keystroke and stays low for the 10us or so. Key presses are echoed as before so I believe the ACIA is working OK (yes I had removed the 5v link).

One interesting fact: if I type 'cpm' I get a response:

 

cpm

rc= FR_

 

Just those characters, and it's reproducible -every time. Mean anything?

Yes. That is expected and it means is that the CF Card has not been mounted.

You would need to do a directory listing (ls) first, which would auto mount the FAT Disk.

But what is more of a concern is that you don't see the initial boot message, after pressing the reset button.

If you don't see this message (including the smiley face :-) ) then there is something else going on.

RC2014 8085 CF - CP/M-IDE
feilipu 2024

> :-)

>

If you are seeing this initial boot message, and are entering cpm at the prompt, try ls first and see if you get proper directory listing.

Phillip

[Doug Jackson]

Hi Keith,

Intermittent errors are insanely frustrating.

In my case, I can always trace intermittent faults with established RCBUS hardware to either faulty components (Fakes) or problematic solder joints.

Fortunately, your minimal system is only two boards and a backplane - I would start by reflowing and examining the solder joints on the backplane, and then each of the cards.

Did you use the Lead Free solder?  If so, remember that the soldering iron has to be set to a significantly higher temperature than normal leaded solder.  I personally don't use lead free solder, as my experience was that in non-production environments it easily produces dry joints, or the excessive heat damages the PCB pads very easily.

I hope that is helpful.

Remember, you can always send us detailed photos of both sides of the boards - many people on the list are always happy to examine them for you.

Kindest regards,

Doug Jackson

em: do...@doughq.com

ph: 0414 986878

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/cebf8c48-6b4d-4f8c-a710-f2964e67435en%40googlegroups.com.

[Keith S]

Getting somewhere!

I replaced the OKI M80C85A with an Intel 8085A. Now I see a welcome message on reset. There is something odd about the terminal, it's like its running at 110 baud or less, as its very, very slow. 

So I can conclude that the OKI 80C85 was just not up to running at 7+ MHz, or maybe noise on the supply was causing issues, but the Intel part can handle it. The clock waveform is cleaner too.

Keith

[Phillip Stevens]

On Friday 5 April 2024, Keith S wrote:

Getting somewhere!

I replaced the OKI M80C85A with an Intel 8085A. Now I see a welcome message on reset. There is something odd about the terminal, it's like its running at 110 baud or less, as its very, very slow. 

So I can conclude that the OKI 80C85 was just not up to running at 7+ MHz, or maybe noise on the supply was causing issues, but the Intel part can handle it. The clock waveform is cleaner too.

Keith

 

That seems tantalisingly close. But seeing the repeated > prompt does mean something's still wrong.

And slow motion listings mean something is definitely not healthy.

The Intel H2 part being NMOS does consume quite a bit of power, so I guess this might still point to something power quality related.

But the fact that you can read the CF Card and list the contents of the Card means that all the hardware is nominally "good".

Does the cpm command get you into CP/M?

Try for a start: cpm sys.cpm

Phillip

[Keith S]

Those repeated prompts were just me hitting 'return' a few times!

I measured the current consumption with the 80C85, it was 120mA, that's including the cpu board, memory board, CF board and ACIA board. Nothing really - I did try running on a 3A stabilised supply which made no difference. I guess the nmos 8085 will consume a bit more, but still well within the 11W (over 2A) the iPad supply can give.

Yes, 'cpm sys.cpm' works as expected. A 'dir' listing takes about 10s to complete, which seems slow for 115200 baud, but then maybe that's all an 8085 can manage?

Some CPM commands hang and/or give errors (ls gives a 'Bdos error on @: Select' error, then it sits for a while with the CF led flashing for a minute or so before coming back to the prompt.). So still not 100%.

Keith

 

[Phillip Stevens]

On Friday 5 April 2024, Keith S wrote:

Those repeated prompts were just me hitting 'return' a few times!

I measured the current consumption with the 80C85, it was 120mA, that's including the cpu board, memory board, CF board and ACIA board. Nothing really - I did try running on a 3A stabilised supply which made no difference. I guess the nmos 8085 will consume a bit more, but still well within the 11W (over 2A) the iPad supply can give.

Yes, 'cpm sys.cpm' works as expected. A 'dir' listing takes about 10s to complete, which seems slow for 115200 baud, but then maybe that's all an 8085 can manage?

It should be equally fast as the Z80 version. If not there’s still an issue lurking.

If you like try a comparison test, try swapping for your Z80 CPU and using the ROM for the MINI, which will works with the ACIA Module and Z80 CPU.

Your listing looks good though. So I’m a little confused as to why it might be behaving “slow”. Very odd.

In CP/M ls will fail as it is Z80 command.

 

Some CPM commands hang and/or give errors (ls gives a 'Bdos error on @: Select' error, then it sits for a while with the CF led flashing for a minute or so before coming back to the prompt.). So still not 100%.

Some non-DRI (more “modern”) commands in the sys.cpm drive are made for Z80 CPU systems. They will fail on the 8085 CPU. Probably crashing the system in the worst case. Best case it will just restart, and go straight to CP/M since it has a valid disk LBA available.

Regards, Phillip

[Phillip Stevens]

It should be equally fast as the Z80 version. If not there’s still an issue lurking.

Your listing looks good though. So I’m a little confused as to why it might be behaving “slow”. Very odd.

I just remembered that sometimes a drive FAT format has been “slow” for me in the past. It has been a few years since I last formatted a drive used for RC2014, so I just twigged to that possibility.

If it is a small CF Card you’re using, try formatting using FAT16 rather than FAT32. You can also try leaving a few MBytes free and unused before and after the file system. I remember that helped too, sometimes. This is not a RC2014 issue, but it has something to do with the way the CF Card handles sector reads.

Regards, Phillip

[Andrew Valencia]

It feels almost dumb, but one trick that has saved me hours of hunting is to hold each board up to the light, and look for any bits of light coming through what should be a soldered hole.

Good luck!

[Keith S]

 I just noticed the clock on the 8085 is running at about 120KHz!

This is with the Intel nmos 8085. Fortunately, I have a couple of OKI 80C85's, one of which I tried before. So I tried the other and... 7.3728MHz clock, and, the speed of test scrolling etc is comparable to the z80 version!

I wonder why the Intel chip was oscillating at 120KHz even with the same 14.7456 crystal. Maybe it was a faulty part. Anyhow all seems to be working now, thanks for the all the advice, it's always worth  assuming nothing!

Keith

[Phillip Stevens]

On Saturday 6 April 2024, Keith S wrote:

 I just noticed the clock on the 8085 is running at about 120KHz!

This is with the Intel nmos 8085. Fortunately, I have a couple of OKI 80C85's, one of which I tried before. So I tried the other and... 7.3728MHz clock, and, the speed of test scrolling etc is comparable to the z80 version!

I wonder why the Intel chip was oscillating at 120KHz even with the same 14.7456 crystal. Maybe it was a faulty part. Anyhow all seems to be working now, thanks for the all the advice, it's always worth  assuming nothing!

That’s great to hear. It is interesting that you had two nonfunctional CPUs. I have been lucky, it sounds, as I’ve not had any devices that didn’t work.

It does explain the very low current consumption when you measured the Intel NMOS device, if it was only running at 120kHz.

Now that everything is working, it would be interesting to hear what your peak to peak variation on VCC is. The Tantalum caps would be making a big difference, but how much?

Similarly the total operating current consumption is an interesting statistic, also compared to the Z80 variant.

For reference, Hitech-C and z88dk can both compile for either z80 or 8080. Z88dk can also further optimise for 8085 using the undocumented instructions.

Phillip

[Keith S]

Thanks Phillip,

The Intel cpu was functional, just a little (well very) slow.... it is strange that with exactly the same circuitry, same crystal, it did what it did. Reading the Intel spec sheet it indicates the crystal does not require the 20pF capacitors if it is less than 4MHz, perhaps they should be removed for the Intel 8085 part.  From reading the OKI 80C85 spec, it's not clear if the capacitors are required either for crystals > 6.25MHz.

The power supply p/p variation was still about 1.25v with the working 80C85. But that's well within the operating limit in the spec of 3-6v.

I'll try and measure the current consumption to compare with the z80 system when I get a round tuit.

Keith

[Sergey Kiselev]

My $0.02:

If you're running either OKI 80C85 or Intel 8085 at 7.3728MHz, you're overclocking them.

The OKI 80C85 is rated at 5 MHz, and Intel 8085AH-1 (the fastest Intel 8085) is rated at 6 MHz. The 8085A part without suffix is only 3 MHz.

The only parts that are actually rated at 8 MHz are Tundra 80C85B-8.

For NMOS parts, you don't need load capacitors on the crystal...

USB chargers are frequently crap, and do very poor job of power filtering. Get a regular switch mode 5V power supply.... These are frequently used for home network equipment (switches, small routers)

NMOS and TTL outputs might not be compatible with CMOS inputs (74HC). If using NMOS and TTL better use them with 74HCT CMOS ICs

-- Sergey 

[Phillip Stevens]

On Sunday 7 April 2024, Sergey Kiselev wrote:

For NMOS parts, you don't need load capacitors on the crystal...

Anecdotally, my Intel 8085AH-2 works with the load capacitors. But you're quite correct that they're not needed according to the data sheet.

I guess it is worth trying without to see what happens.

 

USB chargers are frequently crap, and do very poor job of power filtering. Get a regular switch mode 5V power supply.... These are frequently used for home network equipment (switches, small routers)

I've measured the bus voltage provided by my 7805 equivalent switch-mode power supply (like this), with a loaded PRO. It has the added APU Module and Digital I/O Modules, which both consume substantial current.

Essentially the VCC line has a few mV of noise, but that's all.

In all images

GREEN is CLOCK.

YELLOW is VCC.

Measuring probes on x10, measuring directly off the bus at opposite end to ACIA Module.

The Z80 version looks like this.

The 8085 version looks like this.

So I tried running off the "worst case" being a keyboard USB connector as an unpowered USB Hub.

In that condition I had to removed the APU Module and Digital I/O module to get the system to work, because they drew too much current.

But then work it did.

With only a few mV of noise too.

The 8085 powered from USB Hub looks like this.

In all cases there's only a few mV of noise on VCC.

So I'd be quite worried about a power supply for m system that was providing an unstable 5V, particularly one that had a +/- 1 V variation!

 

NMOS and TTL outputs might not be compatible with CMOS inputs (74HC). If using NMOS and TTL better use them with 74HCT CMOS ICs

I specified AHCT logic for the buffers and other devices, but they're not available for all devices. So, specifically for the '573, I had to use AHC logic in my builds.

Probably HCT would be better to use for all devices, but they would consume a bit more power.

-- Sergey 

On Friday, April 5, 2024, Keith S wrote:

The power supply p/p variation was still about 1.25v with the working 80C85. But that's well within the operating limit in the spec of 3-6v.

Perhaps try off a PC USB-3 connector, with just the smallest system (8085 CPU Module, Memory Module, CF Module, ACIA Module), and it should run.

Then measure what is going on with the VCC line like that.

Cheers, Phillip

 

[Keith S]

On Monday, April 8, 2024 at 5:23:37 AM UTC+1 Phillip Stevens wrote:

In all cases there's only a few mV of noise on VCC.

So I'd be quite worried about a power supply for m system that was providing an unstable 5V, particularly one that had a +/- 1 V variation!

I've measured ripple using a Keithley 2231A 5V, 3A stabilised power supply and the board level ripple was not that much different. Actually Apple USB chargers are well designed, and have low output switching noise (in the tens of KHz range). The same cannot be said for generic chinese USB chargers which can have 3x the ripple.

The measurements I made showed the ripple issue was not from the SMPS, it was generated by switching at the clock frequency at 7.3MHz, not kHz. There are 3 possible causes:

1) insufficient decoupling cap on board

2) Inductance in the supply leads causing L * di/dt drop

3) Fast edge rates aggravating (1) and (2).

The decoupling cap on the backplane being augmented by adding 10uF tantalums helped a bit, I'd like to see more onboard decoupling too to address (1). For (2) wider power/ground traces on the backplance would help, or a 4 layer board with 2 being used for VDD and GND. 

For (3) using not the fastest buffers may help, when those big octal buffers switch they are probably the source of the noise. When I was designing 74F logic at Fairchild many years ago we have to limit the slew rate of the output buffers as othewrwise the fast edge rates caused a lot of supply noise problems compared to older 74LS. So using AHCT instead of HCT may not be a good idea.

Keith

 

[Phillip Stevens]

On Monday 8 April 2024, Keith S wrote:

On Monday, April 8, 2024, Phillip Stevens wrote:

In all cases there's only a few mV of noise on VCC.

So I'd be quite worried about a power supply for m system that was providing an unstable 5V, particularly one that had a +/- 1 V variation!

I've measured ripple using a Keithley 2231A 5V, 3A stabilised power supply and the board level ripple was not that much different. Actually Apple USB chargers are well designed, and have low output switching noise (in the tens of KHz range). The same cannot be said for generic chinese USB chargers which can have 3x the ripple.

 

The measurements I made showed the ripple issue was not from the SMPS, it was generated by switching at the clock frequency at 7.3MHz, not kHz. There are 3 possible causes.

This is an interesting question, as the results are quite different, but they should be similar. As it is essentially the same hardware being tested.

The only substantial difference is the use of (my) Standard Backplane-8 versus (your) Backplane-Pro. And, I can't believe they're behaving so differently.

Based on using your Keithley 2231A, and my switch-mode 7805, I agree that we can discard the power supply as the origin of the noise.

So it must come from one of the three below (as you say).

 

1) insufficient decoupling cap on board

2) Inductance in the supply leads causing L * di/dt drop

3) Fast edge rates aggravating (1) and (2).

The decoupling cap on the backplane being augmented by adding 10uF tantalums helped a bit, I'd like to see more onboard decoupling too to address (1).

I have a single 100uF tantalum on the rails which is almost electrically equivalent to your distributed 10uF tantalums. So I can't see that as the cause for different experiences.

 

For (2) wider power/ground traces on the backplane would help, or a 4 layer board with 2 being used for VDD and GND.

I have augmented the existing traces with an additional solid core copper wire on both VCC and GND.

But, I can't imagine that small modification would make so much difference though...???

 

For (3) using not the fastest buffers may help, when those big octal buffers switch they are probably the source of the noise. When I was designing 74F logic at Fairchild many years ago we have to limit the slew rate of the output buffers as othewrwise the fast edge rates caused a lot of supply noise problems compared to older 74LS. So using AHCT instead of HCT may not be a good idea.

I don't think it would make too much difference at 7MHz, but the technical marketing material for the AHC(T) logic family does emphasise the slower skew rates of their products, which are designed to eliminate ground bounce and electrical noise. Their higher final speed (relative to HC(T) is achieved by faster internal gates, which allow the output skew to be kept quite slow with relatively low (8mA) drive. But that is technical marketing material that I'm just regurgitating, and I have no tools to analyse the actual nanosecond skew rates properly. So, IDK...???

A fourth option is that I'm not seeing the noise because my 60MHz 'scope is too slow.

I've posted 200ns/div images, and I've also tried to trigger on single shot spikes,  but there's nothing I can see.

So there may not be enough resolution to capture edge spikes.

Could that be a possibility?

Cheers, Phillip

[Keith S]

On Monday, April 8, 2024 at 10:39:46 AM UTC+1 Phillip Stevens wrote:

A fourth option is that I'm not seeing the noise because my 60MHz 'scope is too slow.

I guess that could be the difference. I've measured on a scope sampling at 5GS/s, it is doing the min/max analysis over the sweep interval, running on slower sweep rate (longer interval) usually shows higher min/max values, but the glitches become almost impossible to see. The scope still catches them though. Attached a screenshop showing a capture over a couple of uS - at under 700mV the ripple is quite small and seems to be greatest on the clock falling edges. With a longer capture time (mS not uS) the ripple is greater but very difficult to see where the min/max is.

Keith

[Keith S]

On Monday, April 8, 2024 at 10:39:46 AM UTC+1 Phillip Stevens wrote:

I don't think it would make too much difference at 7MHz, but the technical marketing material for the AHC(T) logic family does emphasise the slower skew rates of their products, which are designed to eliminate ground bounce and electrical noise. Their higher final speed (relative to HC(T) is achieved by faster internal gates, which allow the output skew to be kept quite slow with relatively low (8mA) drive. But that is technical marketing material that I'm just regurgitating, and I have no tools to analyse the actual nanosecond skew rates properly. So, IDK...???

Be careful, the datasheet 'skew' is the difference in delay times between one buffer and another; that's not the same as slew which is the voltage swing of an output divided by its transistion time (i.e. dV/dt). The data sheets don't give the latter alas, some give the transition time, from which you can deduce the slew rate, some don't. For example the TI SN74HCT240 has transition time of 8nS typical at 25C, 4.5v into a 50pF load. The SN74AHCT240 datasheet does not mention transition time alas. But given that  the AHCT propagation delay is about half that of HCT, I'd expect the slew rate to be higher, although maybe not by 2x.

Keith

[Phillip Stevens]

On Monday, April 8, 2024 at 10:39:46 AM UTC+1 Phillip Stevens wrote:

I don't think it would make too much difference at 7MHz, but the technical marketing material for the AHC(T) logic family does emphasise the slower skew rates of their products, which are designed to eliminate ground bounce and electrical noise. Their higher final speed (relative to HC(T) is achieved by faster internal gates, which allow the output skew to be kept quite slow with relatively low (8mA) drive. But that is technical marketing material that I'm just regurgitating, and I have no tools to analyse the actual nanosecond skew rates properly. So, IDK...???

 

 On Monday 8 April 2024, Keith S wrote:

Be careful, the datasheet 'skew' is the difference in delay times between one buffer and another; that's not the same as slew which is the voltage swing of an output divided by its transition time (i.e. dV/dt). The data sheets don't give the latter alas, some give the transition time, from which you can deduce the slew rate, some don't. For example the TI SN74HCT240 has transition time of 8nS typical at 25C, 4.5v into a 50pF load. The SN74AHCT240 datasheet does not mention transition time alas. But given that  the AHCT propagation delay is about half that of HCT, I'd expect the slew rate to be higher, although maybe not by 2x.

Just quoting their technical marketing documentation (Designer Guide) ...

But as noted, I've no way to validate or disprove these claims.

Cheers, Phillip

[Keith S]

That's very interesting, Phillipp, I've not seen that before. Do you have a link to that document? Looks like AHCT and HCT have very similar slew rates, whereas AC are around double, which would make them worse for a noise perspective..

Keith

[Phillip Stevens]

On Tuesday 9 April 2024, Keith S wrote:

That's very interesting, Phillip, I've not seen that before. Do you have a link to that document?

It should be attached to the previous post. But follow this link if if doesn't appear AHC/AHCT Designer's Guide.

 

Looks like AHCT and HCT have very similar slew rates, whereas AC are around double, which would make them worse for a noise perspective..

Yes, they're saying tPHL is 0.8V/ns for AHC(T) versus 0.9V/ns for HC(T). Similar, but a bit slower.

From reading the old design documents, they were trying to prioritise the better (slower) drive characteristics of HC(T), but with the high speed and low power of AC(T) as a secondary characteristic

Which is entirely reasonable as I understand AHC(T) logic is implemented with (new at the time) 1um technology, like AC(T) logic, whereas HC(T) is implemented with 2um technology.

So (for example) the internal gate parasitic capacitances would be 1:4 smaller. Both logic families come from the 1980's so I'm always surprised that more people don't implement with AHC(T) these days.

Cheers, Phillip

[Doug Jackson]

While this is interesting, I worry that we may have lost sight of identifying the underlying issue.

I have a STD bus 8085 card with an NEC 8085AHC at 6.14 Mhz (No load caps), with an Intel 8155, 64K of Motorola 60L256 and a 8k of eeprom, and a handful of LS TTL Logic including 74LS240s, 244s,  and LS541s (about 22 chips in total) and it runs beautifully of a standard FTDI TTL adapter.

If Keiths board is not reliable on a FTDI adapter then I would wonder if something is drawing way too much current?

Kindest regards,

Doug Jackson

em: do...@doughq.com

ph: 0414 986878

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/f3e841c9-8a52-4307-b913-aa8651a44ea6n%40googlegroups.com.

[Tadeusz Pycio]

I am also puzzled by such large voltage drops. I checked my 8085 kit and it doesn't draw more than 170mA during operation. When I have a moment, I'll check the power quality with an oscilloscope, but I don't suspect any surprises as I have a TL7705 supervisor in this kit which would reset the system in case of such a large voltage drop. Power is supplied via the FTDI of the computer's USB port.

[Keith S]

The 8085 system (8085 clocking at 7.32MHz , memory, ACIA, CF boards) draws about 120mA at 5V. Adding the AM9511A board increases that to ~370mA, but that 9511 gets hot!

A comparable z80 system (rc2014 z80, clocck, RAM, pageable ROM, SIO/2 and CF boards) draws around 65mA. Quite a difference.

My view is that clocking the 8085 at 7.32MHz is just too risky, its well outside the 80C85 5MHz spec (I cannot find a Tundra 8MHz part supplier to the UK). The power supply noise is a red herring, 

Yes it runs on one of my 8085's but it's could beworth changing the xtal to a 10MHz one so the clock runs at 5MHz. The ACIA has its own xtal, however the 9511 board is more of a problem with its divided by 3 internal clock. Especially as I have the 9511A-4 part which can run at 4MHz...

Keith

[Phillip Stevens]

Well, in light of the very unfortunate news of the upcoming demise of the Z80, I thought it would be timely to place some orders for a variety of 8085 CPUs at UTSource. I've managed to find these interesting options to play with.

• Toshiba TMP8085AP-2 new stock >10,000 units https://www.utsource.net/au/itm/p/11566490.html
  
• NEC D8085AHC-2 new stock >10,000 units https://www.utsource.net/au/itm/p/110827.html
  
• Siemens SAB8085AH2P used stock 81units https://www.utsource.net/au/itm/p/11566490.html
  

and I also found some original Intel DIPs.

• Intel P8085AH-1 used stock >10,000 units https://www.utsource.net/au/itm/p/475383.html

Given these stock levels, it seems there are no shortages of new old stock for those willing to venture to the "dark side" of 8-bit computing.

These will go alongside my existing Intel D8085AH-2, Oki and Tundra CPUs.

I'll run some testing to see if I can find any that don't work.

Cheers, Phillip