29.09.2015 09:27
[#1]
Amiga 500 Rev.6a 1mb chip i 0.5mb slow
maliniak
autor wątku
autor wątku
Witam.
Potrzebował bym schemat logiki do rev6a aby zwiększyć pamięć chip do 1mb i aby była widoczna pamięć slow pod klapką 0,5mb.
W tej chwili mam na płycie 512kb i pod klapką 512kb.
Chcę wlutować kości dodatkowe w płytę główną aby uzyskać na płycie 1mb chip i aby 512kb wsadzone pod klapką było widoczne jako slow.
Wiem że potrzebna jest dodatkowa logika "reslow", czy ktoś ma schemat tej logiki ?
Potrzebował bym schemat logiki do rev6a aby zwiększyć pamięć chip do 1mb i aby była widoczna pamięć slow pod klapką 0,5mb.
W tej chwili mam na płycie 512kb i pod klapką 512kb.
Chcę wlutować kości dodatkowe w płytę główną aby uzyskać na płycie 1mb chip i aby 512kb wsadzone pod klapką było widoczne jako slow.
Wiem że potrzebna jest dodatkowa logika "reslow", czy ktoś ma schemat tej logiki ?
29.09.2015 15:55
[#5]
Re: Amiga 500 Rev.6a 1mb chip i 0.5mb slow
29.09.2015 18:07
[#12]
Re: Amiga 500 Rev.6a 1mb chip i 0.5mb slow
maliniak
autor wątku
autor wątku
@janekdrukarz, post #11
Niestety janek nie myliłeś się , ja nie widzę dalej żadnego schematu, tylko ikonke obrazka o pikseli 20x20.
Po zbadaniu elementu okazuje się że to obrazek ze strony amibaya, kto jest niezalogowany to nie widzi jego, wy wydzicie bo jesteście stale zalogowani do amibaya za pomocą cookies.
Taka prośba jakby ktoś mógł wrzucić ten schemat gdzie indziej i go tutaj wystawić....
Po zbadaniu elementu okazuje się że to obrazek ze strony amibaya, kto jest niezalogowany to nie widzi jego, wy wydzicie bo jesteście stale zalogowani do amibaya za pomocą cookies.
Taka prośba jakby ktoś mógł wrzucić ten schemat gdzie indziej i go tutaj wystawić....
29.09.2015 19:15
[#15]
Re: Amiga 500 Rev.6a 1mb chip i 0.5mb slow
maliniak
autor wątku
autor wątku
@janekdrukarz, post #14
dzięki wam, tylko strasznie słabej jakości to jest ale może być.
dzięki jeszcze raz.
ps. dziwna sprawa z tym amibayem, założyłem konto miałem czekać na aktywacje, a tu odpowiedź że konto zablokowane
o co chodzi
kurde ... myślałem że jak będę mieć konto to sobie sam ściągne schemat... janek a na amibayi nie ma lepszej jakości schematu? mógłbyś mi to wysłać mailem??
Ostatnia aktualizacja: 29.09.2015 19:24:08 przez maliniak
dzięki jeszcze raz.
ps. dziwna sprawa z tym amibayem, założyłem konto miałem czekać na aktywacje, a tu odpowiedź że konto zablokowane
o co chodzi
kurde ... myślałem że jak będę mieć konto to sobie sam ściągne schemat... janek a na amibayi nie ma lepszej jakości schematu? mógłbyś mi to wysłać mailem??
Ostatnia aktualizacja: 29.09.2015 19:24:08 przez maliniak
30.09.2015 05:45
[#18]
Re: Amiga 500 Rev.6a 1mb chip i 0.5mb slow
@maliniak, post #17
klik
tak wygląda płytka którą wykonał @Hemiyoda ze Szwecji i on też wprowadził zmiany do schematu.
Ten drugi schemat to jego dzieło. A tu jego wypowiedź:
"If you have already built the original circuit, try to add the 74HCT14 between gary and the circuit, should work much better."
tak wygląda płytka którą wykonał @Hemiyoda ze Szwecji i on też wprowadził zmiany do schematu.
Ten drugi schemat to jego dzieło. A tu jego wypowiedź:
"If you have already built the original circuit, try to add the 74HCT14 between gary and the circuit, should work much better."
30.09.2015 09:17
[#20]
Re: Amiga 500 Rev.6a 1mb chip i 0.5mb slow
@maliniak, post #19
Pewnie nic biorąc pod uwagę, że zgodnie ze schematem docelowo nic to nie zmienia, a takie połączenie kaskadowe co najwyżej zwiększa odporność na zakłócenia. Próbowałem to na XC9536 zsyntetyzować (bez schmitta czyli LS14, bo nie ma takiej możliwości w tym CPLD) i wyszły 3 makrocele zajęte (Z 36) ale podejrzewam, że soft sobie przy syntezie wywalił to co uznał za niepotrzebne/nadmiarowe (np. te opóźnienie zrobione na 3x AND) więc ze schematu może nie da się tego przenieść do webpacka i trzeba by w hdl pisać.
30.09.2015 09:38
[#22]
Re: Amiga 500 Rev.6a 1mb chip i 0.5mb slow
@Krashan, post #21
Nie wiem jak kolega odebrał to co napisałem, ale wyraźnie zaznaczyłem to co soft uznał za niepotrzebne/nadmiarowe (taka optymalizacja czegoś co wg softu niczemu nie służy i nic nie zmienia). I wyraźnie też dopisałem, że korzystając ze schematu nie bardzo da się takie na bramkach opóźnienie zapewnić w ISE. Choć akurat odnośnie tego IDE ekspertem to nie jestem.
A jeśli chodzi o 74LS14 to łącznie wprowadza to ~6x(5-22)ns opóźnienia przy ~140ns cyklu zegarowym (68000) i zasilaniu 5V. Oczywiście na schemacie są LS, ale wyraźnie jest w opisie, że mają być HCT - te mają typical 12ns (czyli DBR opóźniamy o łącznie 72+4ns) - dodatkowo opis sugeruje, że jest to prawdopodobnie potrzebne jedynie do szybkich kości ram poniżej 80ns czasu dostępu (w połączeniu z układami serii F, czyli zasadniczo CPLD również). Tak czy inaczej opóźnienie jest w zasadzie generowanie wyłącznie na DBR więc i tak można by wszystko zrealizować na jednym CPLD co znacznie ułatwia konstrukcję.
Ostatnia aktualizacja: 30.09.2015 09:57:47 przez abcdef
A jeśli chodzi o 74LS14 to łącznie wprowadza to ~6x(5-22)ns opóźnienia przy ~140ns cyklu zegarowym (68000) i zasilaniu 5V. Oczywiście na schemacie są LS, ale wyraźnie jest w opisie, że mają być HCT - te mają typical 12ns (czyli DBR opóźniamy o łącznie 72+4ns) - dodatkowo opis sugeruje, że jest to prawdopodobnie potrzebne jedynie do szybkich kości ram poniżej 80ns czasu dostępu (w połączeniu z układami serii F, czyli zasadniczo CPLD również). Tak czy inaczej opóźnienie jest w zasadzie generowanie wyłącznie na DBR więc i tak można by wszystko zrealizować na jednym CPLD co znacznie ułatwia konstrukcję.
Ostatnia aktualizacja: 30.09.2015 09:57:47 przez abcdef
01.10.2015 06:02
[#23]
Re: Amiga 500 Rev.6a 1mb chip i 0.5mb slow
@abcdef, post #22
Wypowiedź Hemiyody na temat przeróbki i pomiarów na oscyloskopie:
"The DBR* line goes low when the Agnus DMA accesses to the chip ram and up again when it does not. This hack distributes the RAS signaling to the correct membanks depending on the A23 and DBR*.
This hack also needs to consider the RAS refresh that happens on every rasterline, otherwise the memorychips will forget what they have stored. It seems that when it is time for this refresh, both RAS0 and RAS1 goes low. ( RAS is an active low signal btw. ) It it also seems that this is the only time both RAS:es are low, critical for this hack to work.
I hooked up my ancient scope to notice that the DBR* and RAS accesses were not aligned at all. (probably because of long propagation delays inside the agnus..) So basicly there is not a big chance for this hack to work as it is in the finnish magazine imho.
The DBR* needs to be aligned and I did it with 8 OR-gates in series. ( 74LS32, that was the slowest chips I had at hand )
A bit weird that this hack still works at all. I thought Pekka had taken the wrong RAS(0) to the signal he calls RAF0 in the schematic, I think it has to be RAS1 . But there is so much inverting logic going on so I may have missed something. (quite optimized I have to say..)
First screenshot
First screenshot, lower line = original DBR*, upper delayed DBR (closer to 100ns delayed)
Second screenshot
Second screenshot shows delayed DBR* in relation with chipmem RAS (display refresh). (It may have to be delayed a bit further still?) I'll post a timing diagram of a generic dram chip later..
Third screenshot
Third, test with some load on the ram, mainly display updates on first 512kB bank, mod playing on 2nd 512kB bank, Powerpacker doing some crunching in 512kB slowfast mem.
Fourth screenshot
Fourth, "the delay bodge"."
I wypowiedź z tego samego wątku @NMI:
It's just that the propagation delay on the RAS-signals must be kept to an absolute minimum.
That's also why "74F"-logic should be used, or even better, a fast PAL or GAL.
I intend to try and implement this using a CPLD, if I get the time...
Anyway, here is a variation of the hack, with a SR-latch instead of the delay line:
kliknij
"The DBR* line goes low when the Agnus DMA accesses to the chip ram and up again when it does not. This hack distributes the RAS signaling to the correct membanks depending on the A23 and DBR*.
This hack also needs to consider the RAS refresh that happens on every rasterline, otherwise the memorychips will forget what they have stored. It seems that when it is time for this refresh, both RAS0 and RAS1 goes low. ( RAS is an active low signal btw. ) It it also seems that this is the only time both RAS:es are low, critical for this hack to work.
I hooked up my ancient scope to notice that the DBR* and RAS accesses were not aligned at all. (probably because of long propagation delays inside the agnus..) So basicly there is not a big chance for this hack to work as it is in the finnish magazine imho.
The DBR* needs to be aligned and I did it with 8 OR-gates in series. ( 74LS32, that was the slowest chips I had at hand )
A bit weird that this hack still works at all. I thought Pekka had taken the wrong RAS(0) to the signal he calls RAF0 in the schematic, I think it has to be RAS1 . But there is so much inverting logic going on so I may have missed something. (quite optimized I have to say..)
First screenshot
First screenshot, lower line = original DBR*, upper delayed DBR (closer to 100ns delayed)
Second screenshot
Second screenshot shows delayed DBR* in relation with chipmem RAS (display refresh). (It may have to be delayed a bit further still?) I'll post a timing diagram of a generic dram chip later..
Third screenshot
Third, test with some load on the ram, mainly display updates on first 512kB bank, mod playing on 2nd 512kB bank, Powerpacker doing some crunching in 512kB slowfast mem.
Fourth screenshot
Fourth, "the delay bodge"."
I wypowiedź z tego samego wątku @NMI:
It's just that the propagation delay on the RAS-signals must be kept to an absolute minimum.
That's also why "74F"-logic should be used, or even better, a fast PAL or GAL.
I intend to try and implement this using a CPLD, if I get the time...
Anyway, here is a variation of the hack, with a SR-latch instead of the delay line:
kliknij
09.10.2015 06:55
[#25]
Re: Amiga 500 Rev.6a 1mb chip i 0.5mb slow
maliniak
autor wątku
autor wątku
@zyga64, post #2
Wykonałem pcb wg schematu nowszego ReSlow v2.2
Niestety nie działa u mnie, jako IC1 zastosowałem 74HCT14 , dziś przelutuje na LS i zobaczę czy to coś da. Przy próbie botowania jest czarny ekran.
Chciałem zwrócić uwagę że schemat ReSlow v2.2 ma błąd. Wyjście IC5A:3 ma iść na CX:38 , a IC5B:6 po rezsytorze ma iśc na JP3 lowwer right.
Schemat oryginalny peeki v2.1 jest poprawny.
Natomiast przepinając jedno połączenie sygnału DBR uzyskuje się ReSlow v2.1 który podał Zyga64. Ten układ jak najbardziej działa i ma się wtedy 1mb chip i 0,5mb slow i to działa u mnie.
Moje kości ram to 4x 100ns i 4x 120ns. Czy jest wogóle sens dawać układ 74**14 w połączenie DBR przy kościach z takim czasem?
Ostatnia aktualizacja: 09.10.2015 06:57:13 przez maliniak
Niestety nie działa u mnie, jako IC1 zastosowałem 74HCT14 , dziś przelutuje na LS i zobaczę czy to coś da. Przy próbie botowania jest czarny ekran.
Chciałem zwrócić uwagę że schemat ReSlow v2.2 ma błąd. Wyjście IC5A:3 ma iść na CX:38 , a IC5B:6 po rezsytorze ma iśc na JP3 lowwer right.
Schemat oryginalny peeki v2.1 jest poprawny.
Natomiast przepinając jedno połączenie sygnału DBR uzyskuje się ReSlow v2.1 który podał Zyga64. Ten układ jak najbardziej działa i ma się wtedy 1mb chip i 0,5mb slow i to działa u mnie.
Moje kości ram to 4x 100ns i 4x 120ns. Czy jest wogóle sens dawać układ 74**14 w połączenie DBR przy kościach z takim czasem?
Ostatnia aktualizacja: 09.10.2015 06:57:13 przez maliniak
