Nemesis accelerator wiring/diagram

[DarkLord]

I didn't do my mod myself, so I'm a bit unsure about some of it. I do remember
Mark saying that there was one chip that didn't tolerate the over-clocking so he
had to back it down a bit. I *think* it was the DSP. Maybe running at 40mhz there
instead of 50...

[Guest]

http://www.ebay.co.uk/itm/8MHz-DDS-Func ... 2c66722320

this is cheep
8MHZ DDS .01HZ programmable
so add a X 10 chip and you get 80mhz .1hz accurate
far in a way better than a crystal at 6ppm {6hz * (clock/1million)} most are 100ppm an old one maybe more like 600 or 800
as the impurities in them drift.. {turn the crystal round to make it better {game carts etc even resonators turn them round}}
if you have a game cart that wont work turn the resonator around and the cart then works 10 times out of ten

some reports online dont rate this little board
however since the software is now v4 5 i get different results from the guys online
and see NO issues
works perfect at any frequency and with a times ten ic mixer i can extend it to 80mhz with the same sweep but times 10
you need to divide a bit if you use sweep functions and spot frequency and the good thing is you can move the decimal point in its menus
so adding times 10 becomes easy to see
but for point frequency there is very little glitch and jitter....
http://www.analog.com/en/index.html
look at the RF chips section frequency multipliers like
http://www.analog.com/en/rfif-component ... oduct.html
use a good url based email and ask for a sample or three
a brill company and VERY helpful im making a codec based mid side digital mic just now using pcb and there codec tools
now working in process of adding micro controller menus .. for adjusting the codec
youll find ic's in x10 out the psu is on the out pin and the outpin decoupled dc supply to the ic
others are 8 pin dip with a 5v supply
so....
i got the 5mhz version and the 8 mhz version with sweep this is the 5mhz version with no sweep{better i think for pc's}

so you can get to 50mhz
for the over clock guys try the 8mhz version

i just cant build this for 30 quid or so
no way
or i would

and i like the chinese i have a soft spot for all things made there .... very reasonable and they are very nice to deal with very polite and easy going
angels for sure...

[dml]

http://www.ebay.co.uk/itm/8MHz-DDS-Func ... 2c66722320

this is cheep
8MHZ DDS .01HZ programmable
so add a X 10 chip and you get 80mhz .1hz accurate

Cool stuff - may have to play with that

[Guest]

i am just waiting for 10mhz then ill buy one of those .. also

i found uses in the dds to control vibration therapy tables using a pair of hall effect magnetic switch ic's
to allow for X and Y frequencys output by two dds {below 10Khz }

these tables are dc driven and had rudimentary pot based adjustment

the difference is being able to plot Z also with precise control over x and y using a scope for finite control

[SoundDoctor]

so i would also extend the 50mhz to the coprocessor
and the clkin to the videl {from the video socket external clock like the blowup}
NO CLOCK BUFFER MOD
all resistors are 33R otoh 216 217 221 220?? 222 not sure the four
most falcons are fitted with a zero ohm at 221? needs changed as per ct63 install
and at the sdma a 50R carbon resistor or 4X 75R from old ntl terminator plugs

I was going to ask you about this Simbo - you came up with that much better buffer mod using 74LS09 or 74ALS09 a couple of years ago. Were you able to take that buffer board out after your later clock signal rework swapping to high o/p BC547C in the 32k clock? I was not clear on whether the 7409 was still needed in there or not. Or whether running the other 32k signal was the clincher.

Thanks

[Guest]

after much thought about it what i would do .... if i didnt have the nem fitted and working magic


i decided
to add
all resistors between the combel and mpu are all 33R as per ct mod
mount a 50R and parallel 150pF ceramic cap on the sdma clock in pin to the ground pin on the ic next to it as per nemesis
mount a 50mhz ttl clock the way you have with 50mhz to the dsp
reuse the 32mhz via coax to the left side of L102 to supply the 32mhz to the chipset from the redundant dsp 32mhz clock solves the audio issue
rgb is fine for cubase audio so why modulate it with a dot clock ment for ste games basically some apps drawing {not scooter etc} and daft apps and demos
nothing serious
so tv is best bypassed.... on falcon its defo a no brain gain move

also use coax a cut and rework the clock to the coprocessor use a FN50 ic type or 66 {rare}!!!!{i posted links a while back to a guy with 20,000 fn50 68882's

connect at the chip forget the tracks to it from the 33R resistors!!!! i am going to get rid of the buffer ic in my falcon i think
as per ct 60 mod although they use a wire i would use coax and a termination of some sort for ct60
also coax the 50mhz to the videl clock in from the video port
a ttl clock block will supply all its needed without a buffer
where the dot clock is far too low an amplitude at around 2v p-p where ttl is 2.7 or more
i took a bit from every mod a good buddhist way....

you can use the 50mhz dsp videl
and 48mhz 32mhz with a simple rf switch
you use a RF gas filled relay to switch 55 / 32 mhz to the chipset also

throw the switch the whole chipset is @ 55mhz but dsp at 50 and combel at 50

the problem is the midi a kbd clocks need also adjusted

perhaps i should map the schematic of the nemesis


so 32mhz from the dsp clock
do away with the dot and cclk signals via L102

and clock the dsp videl clkin and the coprocessor at 50mhz
youll get 100% mpu and over 300% fpu and the dsp will be far better

its a pity someone doesnt write a usb stack for the dsp ... and reuse the dsp port

usb 1 is just 64k in total stack size

perhaps the stack can be usb1 retro just 32k static ram {doable !!!} just assign a cashe of 256K in ram static cashe this is normal with dsp and the libs exist

[dml]

all resistors between the combel and mpu are all 33R as per ct mod

This is probably ok, with the other mods in place. My non-nemesis board is fine without a buffer patch, using 33R for those 3 resistors, but with the DMA termination and with the RGB clock path taken out.

I have kept the buffer patch in the other machine but then it still has the RGB circuit intact - i used it regularly for testing some stuff on RGB.

mount a 50R and parallel 150pF ceramic cap on the sdma clock in pin to the ground pin on the ic next to it as per nemesis

- check

mount a 50mhz ttl clock the way you have with 50mhz to the dsp

- check

reuse the 32mhz via coax to the left side of L102 to supply the 32mhz to the chipset from the redundant dsp 32mhz clock solves the audio issue

I actually mounted the 50MHz osc in place of the 32, so the 32 has been moved to U65 - quite far away - with a coax link to the SDMA chip. This works ok for audio/dma and it's not really used by anything else. Roughly the same deal though with things mounted in different spots.

The original fune-tuned 32MHz clock is gone - just the 32MHz DSP clock with nice round digits left. This still works ok on my RGB monitor. I never actually tried on a TV...

also use coax a cut and rework the clock to the coprocessor use a FN50 ic type or 66 {rare}!!!!{i posted links a while back to a guy with 20,000 fn50 68882's

I have some FN40's and those seem to go to 60MHz and beyond. I'm not sure if these chips were classified the same way MOT did some of their other yield management - i.e. nearly all the chips are good for 66MHz and they just stamped them with different figures for different priced markets

In the '040 board I'm reworking with there is no '882 installed - took it out to reduce power and signal activity. The '040 has the FPU inside it. The FN40's will do nicely for the other 'plain' board.

connect at the chip forget the tracks to it from the 33R resistors!!!! i am going to get rid of the buffer ic in my falcon i think

Funny - I've been looking at that today! The pads near the 33R are tricky and I lost a via on one of them on the 040 board a while back. I traced the CPUCLCKA/B/C to the various chips from the schematic (FPU, CPU/GALs, Expansion port) and it's pretty easy to go direct with some care.

the problem is the midi a kbd clocks need also adjusted
perhaps i should map the schematic of the nemesis

Yes this is mainly why Nem needs the 32MHz source to get the 6850 clocks correct.

If you managed to reverse the Nem schematic that would be a handy source for a better version of the board!

its a pity someone doesnt write a usb stack for the dsp ... and reuse the dsp port
usb 1 is just 64k in total stack size

The DSP doesn't have a lot of ram (16k words addressed) but the idea is good with some care it can probably be squeezed in there. Would be an interesting thing to try.

[Guest]

time use 0% !!!!
{
ok
this is the deal
my nemesis is fitted and im not moving it
so to map the nemesis i need one to remove the chips from if needed {mostly ill just use a multimeter diode range
and map it to proteus isis
scan both sides ... also and make to b/w pcb size for copying using ares
then we can add our own tweaks easy
perhaps PG can be contacted and asked
i dont want to tread on any toes... in the process..
perhaps he used scooter to make it in which case i have the app...!!! and files are available {perfect world!!!}
basically any pcb cad app is installed on one of my machines all the way back to multisim/ultiboard
{crap app i cracked ... many years ago and rewrote a mad keygen for {old times gone by !!prove it}
simon was designed on
ill put the chips back and test it as i have smd rework units and plenty of smd 74 logic and cmos...
thats the deal
i need a board to play with or i cant
and im not reversing mine it works and im happy
took me long enough to do it...
unless someone offers me a CT63 {broken or not} and ill do it with this one i have
}

time use better than 60 %
>>>>>>>>>>>>>>>>>>>

we can always just start fresh and ground up a vhdl design or fgpa for clocks
use a R2R for divisions and a multi-channel dds in one,,, {easy free chips these days... and easy code as hell}
{lcd display or perhaps onscreen ...}
easy stuff these days to output upto 10mhz direct from an i/o set of 8 or 16 bit R2R {0-10mhz accurate to .01hz}
or use a 10mhz design thats on the net ... to .01hz and add a multiplier ic then you get 100mhz at .1hz accurate as stated above

its far better than ANY crystal even TTL blocks and low jitter glitch types {1-6ppm at best }
even with a multiplier ... the output of such multi-dds is {0.1-0.2ppm}
this is 32,000,000 +- 0.1- 0.2Hz

oh ye while the rework is on the cards
read into this doug
J6 on the nem goes to pins 4,3 on both 6850's this is TX RX clock into the chip
normaly...

u24 TXclock and RX clock are connected together {for midi sync} and supplied by KHZ500 {high to low}
u52 is supplied by KHZ500V signal for keyboard with midi sync respected inverted 500khz {low to high}
all with respect to the main clocks
as the combel will divide down to make sync ...
and the mfp will expect and get layed at the right time framing

ie
TxD clock to the keyboard etc coms U52 6850 is supplied by khz5000V
RXD clock from the keyboard is U52 supplied by KHZ500

U24 midi clocks TXc and RXc uses the same non inverted clock KHZ500 for TX and RX data for its serial data in/out pin's 4,3 clocks 6,2 data

khz500v and khz500 both come from the combel .. ic


BUT!!!

the nem manual has some info on what is output to U24 and 52 {3,4} {by J6 on the nemesis }after mod
i think it changes by .5khz or so ... around depending as you say on the switch level set norm lo hi
u52 and 24 pin 5 RTS Request to send
{not used on both ics but used by the nem for switching hi low {prob uses a flip flop or two or a latch 00 01 10 11 low mid high {pulse set} {and a hidden 4rth state.. without further encoding }
this is why i dont think a nemesis is a brill good design

becouse if you press a key while cubase is running in hires etc a mid file
you may get a clash or collusion in control of midi and keyboard at once {loss of midi clock sync etc IKBD hang or loss of sync }
as there clocks are with nemesis not the combel at all not even and gate sync....
and both TXc and RXc on both ic's are the same framing even when its turned off
re-arbitration is then needed and mpu combel bus time all used by atleast one frame

so for this reason i would NOT use a nemesis and midi
but this is just my opinion

im not fully sure how the mfp would assign priority??? to int

as 500v and 500 are clearly different and are not 50% duty either more like 2% duty combel outputs rubbish with a very thin 500us or so LO HI LO or HI LO HI time frame

{scope check says its as dirty pair a clock as hell }
however they are in exact time frame for the mfp etc int and priority stack

the combel signal never get reused by the nemesis !!!!!

instead are regen
however PG must know what he was doing {eeek} not sure he does here
never seen any machine with a nemesis perform well with midi and ive seen heeps of them
like the mark 4 5 etc so called beefed up midi boxes ... rubbish.... and never worked well enough
or even as good as a stock NTSC machine {uses no dot clock }
now you know why people

you see now i am treading on some toes again!!!
so separate RX TX clocks preserved but adjusted is my choice of fix
you can use something like a CD4059 or two
or similar code jam counter to adjust and 'fix up' the 500khz clock to reuse the combels perfect sync output
im not sure how the combel divides down but you can be assured its sync around the mfp ...
with resect to 32 in = 16 8 4 and 500khz {invert 500khz}
but all these divisions will be with respect to the 4mhz clock
i dont think the combo will just divide 32 to 16 to 4 to 500khz
it will divide 16 by 2 etc.. and 4 by 8 as jam registers
but in perfect sync not with the 32mhz but in a more 'slack' way
so allows a little latency to 'clock in' data
this is why i feel it looses sync and midi clock frames smpte is hard to lock if atall even using external cubase dsp boxes

[Guest]

so given above

can you add to nembench a bus/perif chip {floppy scsi etc etc }
re-arbitration counter or similar set of tests that see if there is a bottleneck
or one in contention of midi or ikbd activity {its fifo etc... usage}
to see if the keyboard or midi looses sync or any other ic???

or some way to measure these data i/o events .. are in complete sync with the combels normal 500khz
i dont think it is ... needs some thinking what to test/display or log to file at test end or something???
would be nice to check this accept out doug

the problems with nemesis i feel and the 500khz clock
are amplified if an after burner /ct60 63.. is also fitted
as it will use the khz 500 from the combo where the two midi keyboard chips will use the nemesis clock output from J6

could cause things like mouse freeze up/driver fail to handshake joy port sticky or keyboard not responding midi or scsi drives drivers lock up
not sure the ide wont freezeup for re-arbitration
as the mfp stack will be reworked to suite data waiting and ready perif etc... collusion

all the data will just stack up with bad clocks sync and control then the machine will just freeze prob no bombs
or a screen full

not sure the combel cant just stop the clock 500khz output anyway... if it wants to {ignore keyboard and midi}
however this cant happen if there is a nemesis fitted

some other peoples clock boards are good but PG is the only one to at least attempt to play with the 500khz clocks

the power up and the power up 2 work with it also but im sure they must adjust the actual combel clock
would be nice to see there wiring details {pinouts} lets see what they do {you cant see inside they are both potted in epoxy}

does someone have the install guide or can scan it ???

[dml]

so given above
can you add to nembench a bus/perif chip {floppy scsi etc etc }
re-arbitration counter or similar set of tests that see if there is a bottleneck
or one in contention of midi or ikbd activity {its fifo etc... usage}
to see if the keyboard or midi looses sync or any other ic???

I think this sort of thing already shows up in STRam read/write performance timings i.e. it's not always a nice multiple of the clock rate - it gets quantized into some other clock 'space' and misses beats so perf goes up or down a few %.

However the whole architecture was made to operate async (the MOT chipset is a fully async/self-arbitration design) so this kind of thing just gets soaked up into performance error of a few % (maybe more than a few % if the clock sync is bad).

It's possible some bits and pieces of the board have cost-saving design shortcuts that expect perfect sync all the time, but I don't know how many or where they are. It would take very careful study of the schematic and more knowledge than I have on the design!

The IKBD won't suffer at all because it is fully async and quite heavily buffered. There would have to be several milliseconds of loss for it to fall over. MIDI I assume is the same but timing cues are probably affected as you say... so it's unlikely to crash as a result but precision loss for MIDI events is quite possible.

I'm more surprised that the SDMA and VIDEL churn happily along with all these clocks flying around. They are designed to be async but they are comparatively fast devices with minimal (if any) buffering so I would have expected them to be the very first things to break. The SDMA has it's problems but it seems to be more electronic/signal management problems than async-logic design problems.

But yes - Nemesis is a small simple thing that messes with a fairly complicated (overloaded even) clock arrangement and it's probably also a bit evolved from experiments and other hacks. So it works but there may be things at the very periphery that don't work so well and aren't easily noticed. I think it's mostly converted into uneven performance dropouts measured in micro or nanoseconds and these don't really get noticed - but there could be worse things lurking e.g. 1 in 10 times you start the machine it's in a 'bad sync state' and won't behave (I have no evidence of this but it's not impossible!).

Mr P Green is probably the better man to ask these questions Or Mr Czuba - who has probably had to fight with a lot of this stuff at a board design level...

[dml]

An updated version of the board diagram with J6 labelling fixed and 25/32MHz RGB clock out properly marked...

nem101.png

[Guest]

was thinking of making up some buffer boards

same design as others just about
but when you remove the 33R resistors from the board
the buffer board has them there

ill use a double sided board the base is a ground plane copper
and is thru to grounds above
all smd 74 with the 33R resistors also on it
there will be pads for coax {ie ground pad and connection pad}
i can i think supply with with coax on it already cut to size and bare ended {precut and trimmed}

i think with this approach there is no need so terminate at the sdma ic

ill draw up the schematic i mean just now and post a pic see what people think
the pcb side will take a few hours more to get a nice design
this way people can also use some paint {nail varnish etc} on one side
and some press and peal or a lazered A4 iron on
to make the top tracking and pads if they want to make there own ,,,

[catmando]

There's now a wiki for the Nemesis here http://www.atari-wiki.com/index.php/Nemesis

[Rustynutt]

So, I have all the Falcons up and running and was moving onto firing up the Afterburner unit.
It's been setting since selling the Falcon Rack at least 7 years ago.
Worked great then, Nemesis and all. Pulled the AB for safe storage and haven't touched it since.
Reinstalling the AB, all I could get was a black screen. After careful inspection of the buffer, found one of the wires have become detached over time. Re-soldered, still black screen.
Reseated the clocks, re-soldered the buffer, with the same results.
This lasted 3 or 4 hours over a couple nights.

The moral of the story is, always plug the VGA cable into your monitor when using your computer.
The screen works much better

[DarkLord]

Reminds me of what I just went through with my '06 Trailblazer.

It had that high pitched whine you usually associate with it being low on
power steering fluid. (I just got this vehicle from my son and his wife, who
wanted to get rid of it for a new Mazda MX5 and I needed a 4WD so...)

So...checked the fluid. Full, no problem there. Bought a rebuilt one from
Advance Auto parts for $70. Pulley remover kit from AutoZone for $30.

Spent 2 hrs one afternoon carefully changing everything. No difference.
Asked around, was told that it probably now has air in the lines. Jacked
it up, motor off, cap off reservoir, lock to lock steering, right and left many
times. No difference. A little more research and was told that the belt
tensioner and its bearing, located just below the P/S pump, could do the
same thing. $30+ from Advance. 10 minutes to change. No difference.

Was also told that bad bearings/armature in the alternator could make the
same sound but I had replaced it just a few months ago and it was making
the sound before I replaced it.

Finally, a guy at Autozone says that the idler pulley, just below the alternator,
can also make the same sound. $19.99 and 5 minutes to replace. Fixed it.

Moral of the story, should have followed the KISS principle and/or Occams'
Razor. Sounds like you should have too.

[Rustynutt]

Tip there, pull all belts and test run first, fiddle by hand, then replace one at a time. If you have a newer vehicle with serpentine belt, sorry
At least I had the monitor powered

Don't know how long ago the Nemesis was first available here, have had this one since. To coin what Doug said, I did a dog puke installation back then. Always planned to go back and make it pretty like some photos here, but its been rock solid on the A/B, and Mighty Sonic before it. Forgot how hot the oh4oh runs at 44mhz!
To re-cap (pun), it's by the book installed, with SDMA clock fed via shielded wire. Clock goes through a ferrite lead, with signal SDMA clock in pin terminated with a resistor, ala, Czuba.
Time has come to pull it, bring the board "back to perfection"
Looking forward to having the AB, NOVA and Expose assembled. So tempted to put it in a spare MKX case, with some Steinberg boxes to boot