Atom Noise Killer @ 2MHz

discussion of games, software, hardware & emulators relating to the Acorn Atom and Acorn System machines.
Post Reply
User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Atom Noise Killer @ 2MHz

Post by hoglet » Mon Apr 15, 2019 2:38 pm

Hi all,

I've been wondering since yesterday if it's possible to somehow tweak the screen noise killer to work at 2MHz (and beyond).

So I've spent this morning doing some "Evil Mad Scientist" type experiments. :shock:

Now it's time to present the results...

But first, let's recap a bit about the cause of Atom screen noise, and how the current noise killer overcomes it.

On the Atom, the 6502 CPU and 6847 VDG run from different clocks. That make it hard to share the screen memory between the two, because the to clocks are asynchronous. Atom screen noise occurs when the CPU and the 6847 both need to access screen memory at the same time. Acorn dealt with this conflict by giving the CPU priority and allowing the 6847 to briefly read back incorrect data. That incorrect data is what causes screen noise.

The original design for the Noise Killer was from Dr Alan Knowles, of Manchester University Computer Science Dept:
A E Knowles Atom Screen Noise Eliminator.pdf
(841.58 KiB) Downloaded 18 times

It turns out that memory accesses from the VDG are slow and predictable. The pixel clock is 7.16MHz and screen memory is read every 8 pixels (worst case). That's every 1100ns. Alan Knowles' insight was in 1100ns there is time for three memory cycles, even with slow 200ns RAM. The worst case is:
- a video read cycle (<200ns so video data not quite valid)
- a CPU read or write cycle (500ns)
- a second video read cycle (200ns)

Alan's design works using a transparent latch to preserve the current video data during CPU accesses. The latch LOAD signal is simply the VDG signal (which indicates a CPU access) extended to about 700ns by a 74LS123 monostable - 700ns is long enough for the CPU to complete it's access, plus an additional 200ns for the video data to get re-read. The effect of all this is that 6847 sees only stable video data, and the screen noise is banished.

So, back to the actual experiments....

Let's establish some baseline data using the following small test program:

Code: Select all

 10 INPUT B
 20 L=#9F00
 30 M=#8000
 40 P=L
 50[
 60 INC M
 70 JMP L
 80]
 90 CLEAR 4
100 *LOAD MNUA/SPLASH 8000
110 ?#BFFE=B
120 PRINT $7$7$7
130 LINK L
It does two things:
- executes a tight loop from screen memory (the worst case for screen noise)
- increments the first location of screen memory (so you can tell it's not crashed)

With the no noise killer, here's what you get:

No Noise Killer - 1MHz
capture1.png
No Noise Killer - 2MHz
capture2.png
No Noise Killer - 4MHz
capture3.png
Next, with the existing noise killer enbled, here's what you get:

Existing Noise Killer - 1MHz
capture4.png
Existing Noise Killer - 2MHz
capture5.png
Existing Noise Killer - 4MHz
capture6.png
At 2MHz and 4MHz the screen actually stops updating.

Why you might ask?

When this test program is running, every CPU cycle is a screen memory access. When the CPU is running at 2MHz, the VDG signal pulses low every 500ns, triggering the monostable. But wait, the monostable is set to 700ns. So it continues to re-trigger, the latch load signal is always low, and so the latch stays frozen at one value.

If you change the lest program a bit to reduce the rate of screen memory accesses, you do see a bit more:

Existing Noise Killer - 2MHz - lower rate of screen memory accesses
capture7.png
Existing Noise Killer - 4MHz - lower rate of screen memory accesses
capture8.png
But there are still artefacts.

To summarise, the current noise killer design doesn't work well at 2MHz and 4Mhz.

So can we do anything about this?

(to be continued.....)

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Mon Apr 15, 2019 2:38 pm

Let the story resume...

To have a chance of working correctly at 2MHz and 4MHz, two things have to change:
(1) The screen memory should be faster
(2) The length of the latch LOAD pulse needs to vary, depending on the clock speed.

It's easy/cheap to get hold of 55ns RAM (Phill uses these on his video boards), so (1) is not a problem. However, (2) is more of a challenge.

The (active low) LOAD latch pulse length needs to vary such that:
- it's (500+A) ns long @1MHZ
- it's (250+A) ns long @2MHz
- it's (125+A) ns long @4MHz
where A is the access time of the RAM.

That sounds tricky, but it gets easier if you think about it another way: the latch LOAD signal is basically just the VDG signal extended by the access time of the RAM (A == 55ns in this case).

The current design uses a monostable triggered off the falling edge of VDG:
Selection_019.png
I thought about switching to the rising edge, and reducing the monostable timeout to ~55ns. But that's not going to work, because there will be a short delay between the rising edge of VDG and the monostable output triggering, so when combining them you will get a glitch.

So instead, I've just replaced the 74HCT123 monostable by an RC based delay element:
Selection_020.png
This gives the intended behaviour for LOAD, and is safe from any glitches.

In practice, it is easy to construct a prototype delay element:
IMG_1621.JPG
Here you can see it fitted directly into the 74HCT123 socket in one of Phill's boards:
IMG_1623.JPG
And so finally, onto the initial testing, i.e. does it work any better?

Here's the results:

Updated Noise Killer - 1MHz
capture9.png
Updated Noise Killer - 2MHz
capture10.png
Updated Noise Killer - 4MHz
capture11.png
It now works perfectly at all speeds!

Just time to update the PCB!

Dave
Last edited by hoglet on Mon Apr 15, 2019 4:39 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Mon Apr 15, 2019 2:38 pm

Why was there a third post reserved?

For an epilogue of course. :D

In the course of these experiments, I've discovered some interesting facts about the original noise killer.

At least on my board, the original noise killer design is only just working. Works most of the time, but I occasionally see small amount of screen noise. However, if load the VDG signal slightly, e.g. with a 50pF capacitor, or even just a scope probe, you get some screen noise appearing immediately.

It's also very sensitive to the part types used.

The following combinations work:
- 74HCT00+ 74AHCT573 + 74HCT245 (as originally shipped)
- 74HCT00 + 74AHCT573 + 74LS245
- 74HCT00 + 74ALS573 + 74LS245
- 74LS00 + 74AHCT573 + 74LS245
- 74LS00 + 74ALS573 + 74LS245

However, the combinations show screen noise:-
- 74LS00 + 74AHCT573 + 74HCT245
- 74HCT00+ 74ALS573 + 74HCT245
- 74LS00+ 74ALS573 + 74HCT245

I've made sure that the nNKEN signal is tied firectly to 0V.

In all these cases, the overall load latch pulse length is pretty much the same, and varying the monostable time constant doesn't seem to help. Something else must be going on....

It turns out, there is surprisingly little time to freeze the current video data in the latch before it starts to change.

When VDG goes low, the faster 74HCT245 video data bus buffer turns on very quickly and within ~14ns the video data has changed. This means the LOAD signal (two gate delays from VDG) has to get there pretty quickly as well.

You can improve the situation (i.e. increase the margin) in three ways:
- use a slower part for the data bus buffer (e.g. a 74LS245, or indeed the Atom's original 8304 in the later video boards)
- use a faster part for the NAND gates (e.g. a 74HCT00)
- use a faster part for the Latch (e.g. a 74AHCT573, as this has a very low hold time)

I have a couple of questions for people.

For Phill (if you are following this), what part type did you settle on using? Does the above match your experiences?

For anyone else who cares:
- what version of Phill's video board do you have?
- do you ever see screen noise?
- what part types are used for the 74xx00, the 74xx573, the 74xx123 (and the 74xx245 if there is one)

Dave
Last edited by hoglet on Mon Apr 15, 2019 6:42 pm, edited 3 times in total.

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Mon Apr 15, 2019 6:43 pm

(Nudge, as parts 2 and 3 updated)

User avatar
roland
Posts: 3231
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Atom Noise Killer @ 2MHz

Post by roland » Mon Apr 15, 2019 6:58 pm

Did somebody already today say to you that you are brilliant ?

=D> =D> =D> =D>

I don't have a colour board so I cannot give an answer to the questions. I'd love to see this board working in my blue Atom :D
256K + 6502 Inside
MAN WOMAN :shock:

User avatar
Multiwizard
Posts: 1567
Joined: Wed Jan 11, 2012 9:03 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by Multiwizard » Mon Apr 15, 2019 7:02 pm

roland wrote:
Mon Apr 15, 2019 6:58 pm
Did somebody already today say to you that you are brilliant ?

=D> =D> =D> =D>
What Roland said... =D> :D =D>

User avatar
BigEd
Posts: 2528
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Atom Noise Killer @ 2MHz

Post by BigEd » Mon Apr 15, 2019 7:08 pm

Excellent!

User avatar
-B-
Posts: 123
Joined: Wed Nov 26, 2014 11:54 am
Location: Noordwijk ZH (NL) / Durham (UK)
Contact:

Re: Atom Noise Killer @ 2MHz

Post by -B- » Mon Apr 15, 2019 7:43 pm

Wow!
Atom | BBC Model A | BBC Model B | Electron | Olivetti PC128S.

User avatar
jonb
Posts: 2527
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England
Contact:

Re: Atom Noise Killer @ 2MHz

Post by jonb » Mon Apr 15, 2019 7:46 pm

Gotta say, that's some impressive work Dave. =D> =D> =D>

User avatar
oss003
Posts: 3000
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Atom Noise Killer @ 2MHz

Post by oss003 » Mon Apr 15, 2019 7:48 pm

You're a wizard Dave ...... Nice job .... =D>

Greetings
Kees

User avatar
oss003
Posts: 3000
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Atom Noise Killer @ 2MHz

Post by oss003 » Mon Apr 15, 2019 8:15 pm

IIRC there was also a difference in timing for the 123 types according to the specs.

Greetings
Kees

bprosman
Posts: 289
Joined: Sun Mar 29, 2015 10:27 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by bprosman » Mon Apr 15, 2019 8:33 pm

Great work Dave !!!

User avatar
trixster
Posts: 868
Joined: Wed May 06, 2015 11:45 am
Location: York
Contact:

Re: Atom Noise Killer @ 2MHz

Post by trixster » Mon Apr 15, 2019 8:33 pm

These are my two Phill boards:

A 5.10c colour board and noise killer
8813490D-2287-4504-A7A0-90514009C548.jpeg
A 2.1 32k ram/rombox and noise killer
59108331-997A-489D-9A66-0B787C37255E.jpeg
There is a toggle switch on the ram/rombox to select 1mhz or (I think) 1.7mhz

I do see some sparklies but I think thats from the Atom rgbtohdmi, not the noise killer when the atoms connected to a tv via scart
Last edited by trixster on Mon Apr 15, 2019 8:35 pm, edited 1 time in total.
A3020 | A3000 | A420/1 | BBC B | Master Turbo | ZX48K | NeoGeo
Atom | Amiga A4000 | A3000 | A1200 | A500 | PC Engine | Enterprise
Falcon | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD | Jaguar | X68000 | CD32

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Mon Apr 15, 2019 8:37 pm

oss003 wrote:
Mon Apr 15, 2019 8:15 pm
IIRC there was also a difference in timing for the 123 types according to the specs.
Yes indeed there is, and that need's to be taken account of by using a different capacitor value:
- 74LS123 + R=8K2 + C=150pF (in the original Alan Knowles article)
- 74HC/74HCT123 + R=8K2 + C=68pF (on Phil''s board)

These both give the same ~700ns pulse length.

If you use a 74LS123 with the 68pF capacitor, or a 74HCT123 with a 150pF capacitor, it won't work either.

Dave

P.S. Thanks everyone for the kind comments :oops:

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Mon Apr 15, 2019 8:45 pm

trixster wrote:
Mon Apr 15, 2019 8:33 pm
A 5.10c colour board and noise killer
..
I do see some sparklies but I think thats from the Atom rgbtohdmi, not the noise killer when the atoms connected to a tv via scart
Phill's larger sized colour boards all make use of the 8304 on the Atom's board, which buys some extra timing margin. I wouldn't expect any issues regardless of whether 74LS or 74HCT parts are used elsewhere.

User avatar
oss003
Posts: 3000
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Atom Noise Killer @ 2MHz

Post by oss003 » Mon Apr 15, 2019 8:56 pm

The switch on the ramrom board, selects 1/2 of the videoprocessor clock speed as CPU clock 1,79 mHz.
It also syncs both clocks to eliminate noise and dissables the 1mHz noise killer.

Greetings
Kees
Last edited by oss003 on Mon Apr 15, 2019 8:58 pm, edited 2 times in total.

Prime
Posts: 2723
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by Prime » Mon Apr 15, 2019 10:59 pm

Right Interesting work there,

Will have to try replicating as it would certainly possibly make things easier to not have the 74xx123 in there :) Though the two boards I have ready to go out will go out with that circuit on, as they are being delivered at the Riscos show :)

Your findings with relation to the combinations of latch, buffer and timing does rings some bells I seem to remember having to use an LS245 on one version of the board as I was getting noise with a HC/HCT one.

The current 123 circuit uses a 10K resistor and a 47pf cap, I did this to reduce the number of different component values as I already had a bunch of 10Ks and another 47pf, and the timeing works out about the same (and it works!).

I've also run across a problem with some combinations of faster RAM / 6847, where the RAM would actually become corrupt which I suspected was the address lines from the 6847 changing the values on the RAM's address lines befor the /WE had gone completely high leading to data being written to the wrong location (and so getting screen corruption). I fixed this in the 5.9 boards by running the /WE and /OE to the RAM through the CPLD, so that during a CPU write cycle, /WE would be timed from a fast oscilator on board and rasised before /VDG (/MS) so that the write cycle had definately ended before the VDG was released (I also gate /OE high during this period).

Cheers.

Phill.

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Tue Apr 16, 2019 9:49 am

Prime wrote:
Mon Apr 15, 2019 10:59 pm
I've also run across a problem with some combinations of faster RAM / 6847, where the RAM would actually become corrupt which I suspected was the address lines from the 6847 changing the values on the RAM's address lines befor the /WE had gone completely high leading to data being written to the wrong location (and so getting screen corruption). I fixed this in the 5.9 boards by running the /WE and /OE to the RAM through the CPLD, so that during a CPU write cycle, /WE would be timed from a fast oscilator on board and rasised before /VDG (/MS) so that the write cycle had definately ended before the VDG was released (I also gate /OE high during this period).
I think that's a very good approach. How long a write pulse are you using?

I've just captured a screen memory write cycle on the fast scope, and it does look quite dodgy:
IMG_1624.JPG
The traces are:
- Green - VDG
- Purple - RAM /WE
- Pink - RAM Address A7

As you say, the problem is at the end of the write cycle.

When VDG goes high, IC27 turns off, and the only thing driving /WE back high is a 470R pull-up. At the same time, the 6847 starts driving the address bus back low again. Depending on where you measure it, there is only ~8ns margin between /WE going high and the address changing.

I wonder if I can do something similar with the spare gates on the 74HCT00 and 74HCT14?

Dave
Last edited by hoglet on Tue Apr 16, 2019 9:50 am, edited 1 time in total.

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Tue Apr 16, 2019 10:27 am

hoglet wrote:
Tue Apr 16, 2019 9:49 am
I wonder if I can do something similar with the spare gates on the 74HCT00 and 74HCT14?
It turns out I do have enough spare gates of the right type to generate a shaped write pulse of ~60ns duration.

I've just tested the following circuit on the breakboard:
Selection_022.png
The new write pulse looks like this.
IMG_1626.JPG
The traces are:
- Purple - NWE (the old write pulse)
- Pink - RAMNWE (the new write pulse)

The Atom is running at the maximum speed I want to support, namely 4MHz.

The write pulse width varies between 59.5ns (@VCC=5.25V) up to 62.5ns (@VCC=4.75V). The minimum pulse width for 55ns RAM is 45ns.

I'll see if I can add this onto the PCB.

Dave

Prime
Posts: 2723
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by Prime » Wed Apr 17, 2019 10:52 pm

Ok,

So I've tried Dave's circuits on the Mk5.9 board and they apper to mostly be working.

The Write pulse shortening circuit works as designed, giving about a 70ns write pulse which should be long enough for 55ns RAM. Modified R/C values would of course be required for slower say 70ns or 100ns, but most of the commonly available these days is 55ns.

The noise killer circuit however seems just on the edge (well in my lashup anyway, which was done on a piece of tripad). I'm still getting some noise with the following :

Code: Select all

10 P=#9000
20 [ STA #8000; JMP #9000;]
30 LINK #9000


Looking at the scope trace the total latch time is coming out at around 575ns, the odd thing is if I rest my finger lightly on the R and C the latch time goes up by about 10ns and the snow goes away, so I may need to just adjust the C slightly to slightly lengthen the pulse. It could of course just be thgat my lashup isn't particularly good with regard to grounding etc.

It's enough to get the modified board made and test it.

On the plus side this would allow me to illiminate the dependence on the 74xx123, who's constants vary from manufacturer to manufacturer, it would also allow me to remove the onboard oscillator as the write pulse circuit would replace that. Downside is an extra R and C.

Cheers.

Phill.

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Thu Apr 18, 2019 6:38 am

Prime wrote:
Wed Apr 17, 2019 10:52 pm
The noise killer circuit however seems just on the edge (well in my lashup anyway, which was done on a piece of tripad).
There are two distinct timing paths that seem to matter in the noise killer:
(1) - the latch must freeze before the video data on the RAM output becomes unstable
(2) - the latch must become transparent after the video data on the RAM output becomes stable again

If either of these is violated, then screen noise will result.

(1) Is associated with the falling edge of VDG, and the critical path is from VDG through two 74xx00 NAND gates, ending at the latch control input of the 74xx573. It's not in any way associated with the duration of the monostable.

(2) Is associated with the rising edge of VDG, and the critical path is from VDG through the 6847, to the address bus, through the RAM, ending at the data input of the 74xx573, The latch needs to stay transparent until after the data is stable again.

From (2), you can see as well as the RAM access time (55ns) and the latch setup time (<5ns), the time taken for the 6847 to drive the address bus again needs to be included. The 6847 data sheet is not much help on this: "Memory Select High to Display Address Valid" (tDMSV) = max of 400ns. This is actually total rubbish, because if it were anywhere close to 400ns, there is no way the system would work at 2MHz and 4MHz. I would say in practice it's more like 25ns. But this needs to be included in the delay, so the current values of ~75ns may indeed be on the edge.

But In my prototype, I had far more issues with (1) rather than (2).
Prime wrote:
Wed Apr 17, 2019 10:52 pm
Looking at the scope trace the total latch time is coming out at around 575ns, the odd thing is if I rest my finger lightly on the R and C the latch time goes up by about 10ns and the snow goes away, so I may need to just adjust the C slightly to slightly lengthen the pulse. It could of course just be thgat my lashup isn't particularly good with regard to grounding etc.
It could be either (1) or (2) that is being influenced by the proximity of the finger. Try increasing R by ~50%, say to 330R.

What flavour of '245 '573 and '00 are you using?
Prime wrote:
Wed Apr 17, 2019 10:52 pm
On the plus side this would allow me to illiminate the dependence on the 74xx123, who's constants vary from manufacturer to manufacturer, it would also allow me to remove the onboard oscillator as the write pulse circuit would replace that. Downside is an extra R and C.
Just a note of caution. With R=220ohms and C=100pF, the internal resistance of the TTL gate output will be significant in how long C takes to charge. So you may still find variations between manufacturers. Increasing R and reducing C might help reduce this factor.

Dave

Prime
Posts: 2723
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by Prime » Thu Apr 18, 2019 9:36 am

hoglet wrote:
Thu Apr 18, 2019 6:38 am
Prime wrote:
Wed Apr 17, 2019 10:52 pm
Looking at the scope trace the total latch time is coming out at around 575ns, the odd thing is if I rest my finger lightly on the R and C the latch time goes up by about 10ns and the snow goes away, so I may need to just adjust the C slightly to slightly lengthen the pulse. It could of course just be thgat my lashup isn't particularly good with regard to grounding etc.
It could be either (1) or (2) that is being influenced by the proximity of the finger. Try increasing R by ~50%, say to 330R.

What flavour of '245 '573 and '00 are you using?
Not using 245, using original Acorn 8304 (on Atom mainboard), 74HC573, 74HC00.

Chips on my lashup board are 74HCT14 and 74HC00, I used another nand chip as it meant I didn't have to modify the colour board, and could just plug into the 74HC123's socket. But since the additional NAND is used in the /WE circuit which works, that probably doen't have any bearing on it.....

And I'm sure you meant try increasing R by ~50% to 150R......
Just a note of caution. With R=220ohms and C=100pF, the internal resistance of the TTL gate output will be significant in how long C takes to charge. So you may still find variations between manufacturers. Increasing R and reducing C might help reduce this factor.
Right I'll bear that in mind, once I get things working :)

Cheers.

Phill.

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Thu Apr 18, 2019 10:07 am

Prime wrote:
Thu Apr 18, 2019 9:36 am
And I'm sure you meant try increasing R by ~50% to 150R......
Sorry, I ended up changing to using 100pF and 220R (rather than 220pF and 100R). I didn't update the earlier schematic.

Anyway, I'm expecting to have to fiddle with the values a bit more.

Dave

Prime
Posts: 2723
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by Prime » Thu Apr 18, 2019 12:00 pm

hoglet wrote:
Thu Apr 18, 2019 10:07 am
Prime wrote:
Thu Apr 18, 2019 9:36 am
And I'm sure you meant try increasing R by ~50% to 150R......
Sorry, I ended up changing to using 100pF and 220R (rather than 220pF and 100R). I didn't update the earlier schematic.

Anyway, I'm expecting to have to fiddle with the values a bit more.
Ahhh so same as on the /WE circuit then :) That's what confused me :)

Cheers.

Phill.

Prime
Posts: 2723
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by Prime » Sat Apr 20, 2019 5:50 pm

Right I've done some more playing with my lashup.....

For both R/C delay circuits I have used the following values :

R = 1.1K
C = 27pf

Reason being that they give approx the correct delays and the board already has those values elsewhere so helps keep the number of different component values down. I was also seeing problems with the /WE delay with the previous 220R/100pf values as the RAM in there was 70ns and those values where right on the edge. 70ns sould also be good for 4MHz operation, but have not actually tried this.

With the above values I get no snow at all in text mode with the [ STA #8000 JMP #9C00 ] loop it's absolutely bang on. However in mode 4 with the Atom MMC menu screen loaded I do get some disturbance on the screen, however this can be 'tuned out' by adjusting the Y comparitor.

I rather suspect it's noise that's getting onto the Y line, as it only appears in areas of the screen where the Y signal is used. I tried drawing the 4 blocks of colour green, yellow, red, blue (I used the code from 8col to draw this but without the interrrupt to switch the coloursets), but with the sta/jmp loop and the interference *ONLY* happens in the green areas, but also only happens if the screen RAM is being accessed. So IU suspect crosstalk from the digital lines being picked up by the Y signal.

Cheers.

Phill.

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Sat Apr 20, 2019 6:09 pm

Prime wrote:
Sat Apr 20, 2019 5:50 pm
I rather suspect it's noise that's getting onto the Y line, as it only appears in areas of the screen where the Y signal is used.
If you change the test program to:

Code: Select all

[ LDA #8000 JMP #9C00 ]
do you still get noise?

I'm wondering if during CPU writes there is a brief bus conflict, where momentarily both the SRAM and the 8304 drive the bus at the same time.

I've been experimenting with different TTL devices on the Mk 3.5 Video Board. As I reported earlier, you have to be very careful what device types are used for:
- the '573
- the '00
- the '245 (or 8304)

The '573 and '00 need to be as fast as possible, and the '245 (or 8304) needs to be as slow as possible, otherwise you get hold time issues with the latch that result in screen noise.

If I use a 74HCT573 and a 74HCT245, then I definitely need to use a 74F00. Anything else doesn't work.

I'm probably going to do another revision of the design, and switch to using 74xx08 AND gates, so there is only one gate delay between VDG and the Latch control input.

Dave

Prime
Posts: 2723
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by Prime » Sun Apr 21, 2019 2:23 pm

hoglet wrote:
Sat Apr 20, 2019 6:09 pm
Prime wrote:
Sat Apr 20, 2019 5:50 pm
I rather suspect it's noise that's getting onto the Y line, as it only appears in areas of the screen where the Y signal is used.
If you change the test program to:

Code: Select all

[ LDA #8000 JMP #9C00 ]
do you still get noise?

I'm wondering if during CPU writes there is a brief bus conflict, where momentarily both the SRAM and the 8304 drive the bus at the same time.
What I've noticed through a series of experiments is that even if I assembe the loop in main RAM and just have something like :

Code: Select all

10 B=#4000;P=B
20 [ JMP B;]
30 CLEAR 4
40 LOAD"screendata"
50 LINK B
I still gat occational noise**, this seems to match up with noise on the VCC line about +/- 0.2v from it's normal value, I setyp the scope so that I was triggering on this and monitoring the Y line at the same time, it also seems to cause a blip there, so would probably be the culpret.

**with the above code running I only seem to get the noice occasionally, maybe once every 2-3 seconds, with the code running in video RAM it's much more frequent, and causes much more of a problem.

The other thing I did find is that the /MS line was only reaching approx 4.2-4.4V, it seems to be being pulled / loaded down by the 81LS95 & 8304 chips as without them in circuit it's up at 4.9-5.0V.

One thing I do noytice is that this board still has some of the ~35year old electolytics onboard, so I may try changing them. There's also less than the ideal number of decoupling capacitors on the Atom board, so I may look at that. Specifically I may add individual 0.1uf caps to the buffers.
I'm probably going to do another revision of the design, and switch to using 74xx08 AND gates, so there is only one gate delay between VDG and the Latch control input.
The original version of that board used 74xx08 AND gates, I modified it to use 74xx00 NAND, when I found that I needed to disable the latch based noisekiller when the clock based nosekiller (on the RAMROM) was active.

Sorry I seem to have hijacked your thread :(

Cheers.

Phill.
Last edited by Prime on Sun Apr 21, 2019 2:24 pm, edited 1 time in total.

Prime
Posts: 2723
Joined: Sun May 31, 2009 11:52 pm
Contact:

Re: Atom Noise Killer @ 2MHz

Post by Prime » Mon Apr 22, 2019 12:59 pm

Welll......none of those things seemed to help :(

I've posted a video of the noise I'm getting here : https://www.youtube.com/watch?v=C5XY52Fh1X4

First half of the video is displaying menu with the sta #8000 loop. I then hit break and just boot the mmc, which displays the standard games collection menu, which shouldn't be accessing the video RAM, and I'm still getting the same noise so I'm at a loss to see where it is coming from :(

Cheers.

Phill.

User avatar
hoglet
Posts: 8281
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Atom Noise Killer @ 2MHz

Post by hoglet » Mon Apr 22, 2019 1:42 pm

Hi Phill,
Prime wrote:
Mon Apr 22, 2019 12:59 pm
First half of the video is displaying menu with the sta #8000 loop. I then hit break and just boot the mmc, which displays the standard games collection menu, which shouldn't be accessing the video RAM, and I'm still getting the same noise so I'm at a loss to see where it is coming from :(
I've sort of lost track of exactly what you have on the bench at the moment.

Could you post a current schematic, CPLD design, and a list of exactly what part type you are using for each TTL IC (if there are any)?

Actually, do you think it might be better to start a new thread for the Mk 5.x colour board?

Dave

Post Reply