pakman wrote:simbo2 wrote:ill do the routing tomorrow etc.
I see the address line routing is somewhat scrambled, for no reason.
To make routing easier, I propose to rearrange the address lines:
SIMM pin : Current -> Proposal
1st F157:
12 MA0 : MAD0(A2,A3) -> MAD0(A20,A21)
13 MA1 : MAD1(A4,A5) -> MAD1(A18,A19)
14 MA2 : MAD3(A8,A9) -> MAD2(A16,A17)
15 MA3 : MAD4(A10,A11) -> MAD3(A14,A15)
2nd 157:
16 MA4 : MAD9(A20,A21) -> MAD4(A12,A13)
17 MA5 : MAD7(A16,A17) -> MAD5(A10,A11)
18 MA6 : MAD8(A18,A19) -> MAD6(A8,A9)
19 MA10 : MAD10(A23,A22) -> MAD10(A23,A22)
3rd 157:
28 MA7 : MAD6(A14,A15) -> MAD7(A6,A7)
29 MA11 : MAD11(A25,A24) -> MAD11(A25,A24)
31 MA8 : MAD2(A6,A7) -> MAD8(A4,A5)
32 MA9 : MAD5(A12,A13) -> MAD9(A2,A3)
Basically you can swap the address lines according to your needs.
Only MA10 and MA11 should be kept fixed as shown above.
There is no impact on the MACH (or M4A5) code at all.
simbo2 wrote:any other mods needed? tell me soon ...
Will think about it..
think the address lines are arranged to allow nibble {4bits blocks} mode to work properly with modern EDO and FPM as the ram initally used was nibble mode FPM from what i understand nibble mode FPM was just before EDO and EDO is backward complient but nibble mode addressing and also FPM can use this method if addresses differently ... {in 4 bit blocks}
hum.... now im not sure what too do
ive mostly finished routing it
so ill alter a schematic on its own see what it looks like
not sure this is right ... it seems addresses are correct for 4 bit nibble mode {burst mode transfers}
edo supports nibble mode and kinda works the same way anyway... fpm doesnt and needs different addresses but this is done in the simms chips
need to see.. perhaps make a proto i think first with all mods done
and leave the rev 1 schematic as is just now
work on a copy ....
?? this is a better idea i can get us two made up for testing perhaps make 4 and some testers ... can help us
and send you a populated one... some ram access tests gembench or etc to test the TTRAM only
perhaps we can write a little test app for this ill ask frankb see if he has time for this step or any member who wants to help please...
with some test routines for TTRAM only perhaps some load a block to STRAM then transfer it about to TTRAM etc
moving where its put .... etc etc
dram edo or fpm uses simm chips internal address counters/decoders for block address etc...
remember the board supports burst nibble modes
and edo and fpm both support it if wired up right
i think the address ladder is setup in such a way nibble mode works with edo and fpm
burst mode is all down to the type edo supports burst mode but im not sure its used too its best extent or EDO runs in compatable mode but nibble mode and the fpm is nibble mode anyway by the addresses ladder employed.
...edo and fpm simms chips decoder encoder etc is setup very different
but in a masked sort of way.... i think this setup is right,,,, to maintain edo as nibble mode fpm ...
the original magnum TT was made in 1998?? so was before EDO became mainstreem and nibble mode fpm was current
so the story is FPM then nibble mode FPM then EDO ...
more research is needed before such a major change....
members are waiting with baited breath.... for there boards too be sent....
and perhaps will start to get a bit peed off
its a lot of work and im just being causious ...
afterall we have a 100% design just now ... and performance can or cannot suffer
some benchmark tool needs built or found first... some block diagrams of ram layout from some simms datasheets details
and chips details ...
moving these two lines RAS to the bottom will mean i must use perhaps 4 or 8 vias i hate vias .....
so im glad also if we can rip it up....
if you have a pc download the proteus vsm demo from the makers site
and you can view the designs ... proteus PDF output is lame and fails to display the ! invert active state labels on the schematics
the problem is i think it exports in generic PDF format and not as a captive image so misses details
if you use a mac and virtual windows youll need VC6 etc runtimes and open GL driver at least... and add directx mostly just for the handles
ps i can simulate this design with code ... ive already made up in the past EDO simms and FPM simms as code dlls
just generic non specific setup as per ram standards publications
runs up too 1mhz...in realtime overall and my dlls will work fine in the demo .. app so you can simulate it
adding stimulus is just a few added this and that.... that also work in the demo
just no save mods.. to the design {its a cheep app to buy a simple version}
now youve confused me ... na not really... from my own experience of coding dlls for simms
ill do a bit of reading ,, ill download a wee collection of simms ic's and simms datasheets
this way we have a pool of generic types to look at the internal stucture of different edo and fpm
see exactly why the addresses are laddered in such a way i have enough respect for uwe to know there must be a reason more than track placement...
i do see your point ... and perhaps we can get other types too work
but so far i modded 5 pairs of simms 3 EDO and 2FPM with mods too the PD resistors they all worked ...
so 5 pairs of 128MB simms only two sets used the same pcb .....
perhaps we can fix the problem with the PD lines but using an and gate or something like a nor... to better use the i/os
or totally overide the simms pd select and hard select by size
and the final decision has been made !!! 
