To już kwestia konstrukcji stopnia wyjściowego video, niestety jest totalnie spartolony... widać wszelakie "szarpnięcia" prądu przy aktywności RAM (a więc głównie cykle refresh i DMA generowane przez ANTIC). Tutaj może pomóc trochę układ typu Ultra/Super Video, lub kompletna rekonstrukcja stopnia wyjściowego (chociażby ta w wersja GTIA Fixer od simiusa. Lub układ UAV od Bryan-a (z tym że nie wiem czy jest on obecnie do kupienia)

Nie bardzo ma jak "lepiej" reagować bo sygnał luminancji wychodzi z GTIA w formie cyfrowej... potem efekt psuje prymitywny 4-bit video DAC zrobiony na 4050 i 4 rezystorach. Co do sygnału chrominancji to tam amplituda nie ma zbytnio znaczenia (i tak jest sporo za wysoka, poza dopuszczalna normą) ... większość monitorów sobie z tym radzi... a na pewno 99,9% TV/Monitorów CRT radzi sobie z tym doskonale. To że takie LG tego nie przewidziało... no cóż... albo to błąd konstrukcyjny, albo problem stopnia wejściowego w LG, albo wręcz błąd w firmware monitora, który odpowiada za AGC dla wejścia chrominancji.

no czyta, czyta... (tu moja wina jest niezaprzeczalna, chociaż było napisane "nie trzeba przedstawiać", co nie oznacza iż było to zabronione :P) ale praca zespołowa też jest fajna :) skoro kod się zrobił open-source to teraz społeczność ma szansę wycisnąć z niego ostatnie soki :)

ale chociaż widzę co się dzieje w kodzie... nawet z hex-ami...

0 DPOKE 19,%0:GRAPHICS 56:POKE 559,%0
1 POKE $BF4F,$FF:-MOVE $A151,$A150,$1DFF
2 PUT #6;125:? TIME

wynik: 8 (sporadycznie trafia się 7)

Hej!

10 TIME$= "000000"
11 GRAPHICS 24:SCR=DPEEK(88)
12 POKE SCR+7679,255
13 -MOVE SCR+1,SCR,7679
15 POKE SCR+7679,0
16 -MOVE SCR+1,SCR,7679
17 ? TIME$

coś wygrałem? ;)

ps1) TIME$ jest zbyt mało precyzyjne, trzeba raczej użyć TIME, a jeżeli tak to:

10 DPOKE 18,0:POKE 20,0
11 GRAPHICS 24:SCR=DPEEK(88)
12 POKE SCR+7679,255
13 -MOVE SCR+1,SCR,7679
14 ? #6;CHR$(125)
15 ? TIME

ps3) TIME$ pokazuje czas w sekundach, TIME którego użyłem (ponieważ time$ był zbyt mało precyzyjny) liczy z rozdzielczością (1/50) sek. (dla PAL), więc wynik który uzyskałem 12 jest równy = 12*(1/50)= 0.24 sek.

ps2) tak na serio, nie chcę żadnych nagród rzeczowych :) możecie mnie nie uwzględniać w konkursie ;)

Hej!

z tego schematu:

i tego rysunku:

(rysunki są z tego artykułu z Atariki: Turbo Blizzard)

... wynika że "D" łączysz tam gdzie szedł przewód był podłączony przewód idący od do pinu #3 we wtyczce SIO (DATA_IN), natomiast ten odlutowany przewód podłączasz do punktu "E" interface Blizzard.

"F" łączyć do kabla który idzie z pinu #5 we wtyczce SIO (DATA_OUT). Po prostu przylutowujesz go równolegle do tego przewodu. Ten sygnał normalnie służy do zapisy danych, ale w przypadku Blizzard przy odczycie służy do przełączenia interface w tryb pracy turbo.

w chwili testu miałem "pod ręką" miniaturową BAT165, ale każda "shotka" powinna działać, na sch napisałem przykładowe typy, tzn:

• BAT45

• BAT46

• BAT85

• 1N5711

• 1N6263

1N4148 nie jest niestety diodą shottky-ego. Ale połączone w szereg, z tym że w kierunku przewodzenia też dają radę.

Problemem dla "automatyki" w LG jest zbyt wysoki poziom sygnału chrominancji, normalnie powinno się wziąć jakiś video op-amp i zrobić aktywny układ nazwijmy to "tłumika". Tyle że bez małego PCB i paru elementów pasywnych się nie obejdzie już. Można to też skleić na 2-3 tranzystorach ale nie wiem czy to warte zachodu jest.

Co do efektu... w przypadku mojego LG trudno mówić o jakiejś kolosalnej różnicy w jakości pomiędzy ultra-video a samą diodą w torze chrominancji, ale ten mój LG za dużo "poprawia", tzn. odszumia, wyostrza, etc. Co gorsza w tym monitorze co mam tego się nie da wyłączyć ;/

Hej!

Jeżeli chcesz na szybko doprowadzić ten monitor do działania, bez przerabiania Atari weź jakąś mało-sygnałową diodę schottky-ego i włącz ją w kierunku zaporowym w sygnał chrominancji, tzn. chodzi o coś takiego:

           BAT45/BAT46/BAT85/1N5711/1N6263
[m][chroma]----------|>|-----------------[chroma][a]
[o]                                              [t]
[n][gnd   ]------------------------------[gnd   ][a]
[i]                                              [r]
[t][luma  ]------------------------------[luma  ][i]

Oryginalnie flashjazzcat zastosował w swoim ultra-video zwykłą krzemową 1N4002, ale ja miałem z nią bardzo nieostry obraz. Z kolei 1N4148 w takiej konfiguracji bardzo, ale to bardzo szumiała. Od biedy jak nie masz pod ręką żadnej  diody shottky-ego, a jakiegoś czerwonego LED-a możesz z nim spróbować.

Można też próbować z 4 szt. 1N4148 włączonymi w kierunku przewodzenia, tzn. tak:

[m][chroma]-----|<|---|<|---|<|---|<|-------[chroma][a]
[o][   gnd]---------------------------------[gnd   ][t]
[n][  luma]---------------------------------[luma  ][r]

powyższe rozwiązania sprawdziłem na 130XE (płyta z pamięciami 8x1bit) takiej bez modyfikacji s-video... z moim LG (pomijając "inteligencję" scalera) uzyskałem stabilny obraz na moim wiekowym LG228WA z tego wątku.

Przypomniało mi się... w zamierzchłych czasach robiłem takie interface równoległy do Atari oparty po VIA (6522) służący do transmisji danych pomiędzy JIL i PC. On wykorzystywał ten pin SO, tzn. sprzętowy hand-shake z VIA i aby osiągnąć szybszy "hand-shake" a co za tym idzie większe transfery wykorzystałem linię SO.

Jak zakończę obecną kolejkę zadań, to poszukam tej atarki i udostępnię to... zresztą mam zamiar wszystkie te moje stare i niepublikowane projekty jakoś odgrzebać i upublicznić... może się komuś coś przyda, a nawet jak nie to niech zostanie w sieci zamiast zgnić gdzieś u mnie w czeluściach chaosu :P

Właściwie dla czystej formalności dorzucam do wątku kolejny (i zarazem ostatni) cart związany z systemem Turbo ROM, tym razem jest to cartridge nazwany "Turbo ROM plus (3)", a prezentuje się tak:

Sam cartridge był już prezentowany w tym wątku: Turbo ROM plus, jednak "zdumpowanie" drugiego egzemplarza pozwoliło na weryfikację poprawności pierwszego "zrzutu", zatem:

1) zawartość pamięci EPROM: TurboROM_plus(3).bin.7z

TurboROM_plus(3).bin:

MD5   : 8693c3308e4815082792816c25e8907c
SHA256: fbae42a945962dc6cc8c47b8f9fac3f29b6814590da44093f94a6b56cd82b80e

2) wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: TurboROM_plus(3).xex.zip

3)  Schemat: wektor (PDF), raster color (PNG), raster grayscale (PNG).

Jak widać cartridge jest wykonany identycznie jak wcześniejszy egzemplarz "Turbo ROM Cartridge", tak samo niedbale i z taką samą dawką ignorancji... jego stabilność pozostawiała wiele do życzenia, co prawda nie był tak problematyczny jak wcześniejszy egzemplarz, jednak montującemu PCB nie chciało się przylutować nawet jednej ze stron układu scalonego 7400... bo po co skoro i tak dwie bramki od układu zabezpieczenia "anty-pirackiego" nie są de-facto podłączone potem. Tym razem zamiast 7438 włożono zwykłe 7400, co jest nawet logiczne jeżeli weźmiemy pod uwagę fakt nie skorzystania z "zabezpieczenia". Brak kondensatorów blokujących powodował że raz na jakiś czas zawartość pamięci przy odczycie ulegała przekłamaniu. Po dołożeniu dwóch kondensatorów filtrujących zasilanie, problem niestabilności zniknął.

Jak tak patrzę na te rozwiązania napotkane przeze mnie i podpisane "Turbo ROM", to zaczynam mieć jakieś uprzedzenia, być może miałem pecha, ale zawsze trafiał mi się jakiś przypadek sprawiający problemy, w dodatku albo zalany a to żywicą epoksydową, a to stearyną, a to zapaćkany klejem DISTAL. I każdy cart na który trafiłem zawsze sprawiał jakieś problemy :) ale dość już tego narzekania, bo na zakończenie jak zwykle bohater "odcinka", czyli...

Cartridge Turbo ROM Plus (3):

PCB, góra:

PCB, dół:

Po dłuższej przerwie wracam do opisywania cartów z kolekcji uicr0bee. Dziś na warsztacie pewien mały upierdliwiec, który spędzał mi sen z oczu parę dni... niby zwykły cart... a jednak uszkodzony w tak specyficzny sposób że już myślałem że cart jest stracony... ale o tym za chwilę, zacznijmy od prezentacji tegoż wynalazku... a będzie to cart dla systemu...

TurboROM Cartridge:

1) Zawartość pamięci EPROM: turbo_rom.bin.7z

turbo_rom.bin

MD5   : 80b7f663b648f71faa9704a21fcc5c22
SHA256: 7e5a98b1f52ce1c80370e3c2d9c485c433703e5f36e9391f2905f309b3c70257

2) wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: TurboROM.xex.zip

3)  Schemat: wektor (PDF), raster color (PNG), raster grayscale (PNG).

Jest to standardowy 8KB cart mapujący się w obszar $A000-$BFFF. Można go odłączyć na drodze programowej poprzez dowolne odwołanie do obszaru $D500-$D5FF. Przerzutnik RS realizujący odłączenie cartridge zrealizowano również w standardowy sposób, czyli na dwóch bramkach NAND. Na PCB carta jest co prawda obecny układ "anty-piracki" znany z cartów blizzard, jednak w tym cartridge nie został on połączony, tzn. ścieżka prowadząca w wyjścia bramki U2C do linii D6 została przecięta. Płytka jest typowym projektem z tamtych czasów, nie jest dedykowane rozwiązanie pod "Turbo ROM", a jedynie adaptacja istniejącego rozwiązania. Jakość wykonanie wnętrza tego carta budzi wiele zastrzeżeń, widać było robotę "byle szybciej", "byle taniej", oszczędzono nawet na kondensatorach filtrujących.

Ten akurat egzemplarz strasznie mnie "umęczył", ponieważ po uruchomieniu albo się ciągle resetował, albo uruchamiał się raz na 10 razy... na początku nie wiedziałem od czego to zależy... okazało się że po pewnym czasie że zawartość pamięci EPROM zmienia się w zależności od temperatury :) im cieplej tym lepiej, gdy EPROM osiągnął temp. ~25°C udawało się odczytać poprawnie większą część pamięci, jednak niektóre bajty nadal odczytywały się losowo... analizując kod i wnikając w przyczynę resetów cart-a odkryłem że kod tego carta-a przed startem właściwego oprogramowania liczy swoje CRC (suma wszystkich bajtów modulo 256) i gdy CRC się nie zgadza, skacze pod wektor RESET. To dawało szansę określić czy odczytana zawartość pamięci jest poprawna, jednak nie było tak różowo jak mi się wydawało. Przekłamania odczytów były na tyle spore że często CRC się zgadzało mimo tego że odczytana zawartość była niepoprawna. Skracając już tą nieco przydługą historię... w carcie była oryginalnie pamięć 8KB od National Semiconductor, dokładniej NMC27C64Q... w tym wypadku postanowiłem ją wlutować i spróbować dokonać odczytu w warunkach o wiele mniej "dynamicznych", tzn. odczyt zew. programatorem ze zmniejszoną prędkością odczytu... okazało się że tym sposobem pamięć udało się poprawnie odczytać. Do carta powędrowała nowa kostka EPROM od AMD (AM27C128 ... okazało się że wszystkie 27C64 które mam odmówiły już współpracy z racji wieku). Dodałem trochę kondensatorów, wcześniej już walcząc z cartem wymieniłem wszystkie elementy pasywne, poprawiłem układ resetu.

Na koniec wziąłem na warsztat to wylutowaną NMC27C64Q... ciekawy byłem że jej wredne i niestabilne zachowanie jest spowodowane tym że to już końcówka żywotności ładunków w celach matrycy EPROM, więc pamięć skasowałem... zaprogramowałem ponownie... okazało się że przy szybkim odczycie losowe bajty są nadal przekłamywane... zmieniłem również sposób aktywacji pamięci z ~OE/~CE na taki w którym ~CE cały czas było przypięte do GND a ~OE aktywowane sygnałem ~S5... jednak kość zaczęła w takiej konfiguracji przekłamywać jeszcze więcej bajtów... czas jej życia definitywnie zakończył się... cieszę się jednak że udało mi się odczytać jej zawartość, to była chyba ostatnia chwila aby to uczynić. Mam 99% pewność iż udało mi się to poprawnie zgrać (CRC się zgadza, chociaż pewności to 100% nie daje, więc wykonałem ponad 256 odczytów każdej strony pamięci i wybierałem te które dawały w większości wypadków identyczny odczyt... pamięć przy okazji podgrzewałem i mroziłem aby zobaczyć jak to wpływa na odczyty ;P Masę czasu przy tym zmarnowałem, ale chyba było warto :P)

I jak zwykle na koniec prezentacja samego carta:

PCB, góra:

PCB, spód:

Jak najbardziej do zrobienia w przyszłości :) Tylko nie pamiętam prawdę mówiąc carta z pierwszego obrazka z wątku który podlinkowałeś... albo skleroza (co jest bardzo możliwe) albo nie było go tu na forum? Jest gdzieś w sieci?

no tak... nie ma to jak moja spostrzegawczość ;) Ale poza tym jeszcze gdzieś to nazwisko mi przemknęło... tylko pytanie gdzie? :)