@color_bars... to wygląda jakby brakowało Ci najmłodszego bitu luminancji... jeżeli GTIA jest sprawne, to przyjrzy się buforowi 4050 i jego okolicy, podobny przypadek był tutaj. Może być też tak że np. wyjście LUM0 lub LUM1 z GTIA jest po prostu uwalone, masz jakiś oscyloskop pod ręką aby zobaczyć czy te sygnały po wyjściu z GTIA wykazują jakąś aktywność? A jeżeli tak to zobacz co widać na wyjściach bufora 4050 (szczególnie piny 6 i 12)

ew. pokaż co widać gdy uruchomisz to:

10 GRAPHICS 9
11 FOR I=0 TO 79
12 COLOR I/5
13 PLOT I,0:DRAWTO I,191
14 NEXT I
15 POKE 712,128
99 GOTO 99

Hej!

Dopiero teraz dostrzegłem powiadomienie na o nowych postach w wątku, oczywiście potwierdzam chęć zakupu.

Hej!

Akurat "Duszpasterz" był łatwym przypadkiem, zakładam że masz windows jako główny system operacyjny, więc czyniąc to założenie można to zrobić tak...

Uruchomiłem plik ATR zawierający ową grę, zobaczyłem że wystartował MyDos:

po obejrzeniu katalogu, wcisnąłem klawisz "1" aby obejrzeć katalog dyskietki #1:

... okazało się że widnieje tam plik "rzygon.xex", a więc zwykły binarny plik DOS-u, zatem należało do niego dodać kawałek kodu zerującego komórkę $41... można było to uczyć na dwa sposoby, poprzez napisanie kawałka kodu w ASM, i dołączenie tego kodu wraz z segmentem INIT na początku pliku "rzygon.xex", albo skoro zmieniac mamy tylko jeden bajt w pamięci można dołączyć odpowiedni nagłówek na początku pliku. Można tego dokonać z poziomu samego MyDOS, plus mała pomoc ze strony BASIC-a.

Jako że w chwili gdy robiłem "patch" miałem pod ręką tylko emulator, przeniosłem plik "rzygon.xex" z ATR-a do filesystemu na komputerze PC, można użyć np. emulatora Altirra, należy włączyć w nim emulację wirtualne dysku twardego, dodajemy urządznie "H:" w menu System -> Configure System -> Devices:

potem wskazujemy ścieżkę gdzie będą się znajdowały pliki:

po tej operacji możemy przenieść z poziomu MyDOS-a plik na dysk twardy:

mając już plik "po stronie PC", należy przygotować plik zawierający sekwencję wyłączającą dźwięk podczas I/O, można użyć dowolnego edytora HEX pod windows, np. HxD:

po zapisaniu tego małego pliku należy go dołączyć do istniejącego "rzygon.xex", z linii poleceń można to uczynić następująco:

copy /b silent_io.bin + rzygon.xex rzygon_p.xex

po tej operacji pozostaje już tylko skopiowanie pliku "rzygon_p.xex" na powrót do pliku ATR:

... i to jakby wszystko. Uruchamiając "rzygon_p.xex", uruchomisz po prostu plik z dodaną sekwencją wyciszającą I/O.

Jeżeli chcesz to zrobić na komputerze, nie mając do dyspozycji PC, to z pomocą przyjdzie również MyDos, który jest na "dyskietce" oraz wbudowany w ROM Atari interpreter BASIC. Pierwsze co należy zrobić to uruchomić komputer z tej dyskietki z włączonym BASIC-iem, ew. użyć opcji M, wpisać adres "E477", komputer się zrestartuje z BASIC (nie należy oczywiście trzymać OPTION).

Po tym gdy załaduje się DOS i uruchomi się BASIC (napis READY na ekranie) wpisujemy następujący kod:

10 OPEN #1,8,0,"D:RZYGON_P.XEX"
20 TRAP 40
30 READ A:PUT #1,A:GOTO 30
40 CLOSE #1
50 DATA 255,255,65,0,65,0,0

Po wpisaniu kodu uruchamiany program pisząc "RUN", po chwili po tej operacji na dyskietce powinien pojawić się plik "rzygon_p.xex", należy do niego dołączyć plik "rzygon.xex", można to zrobić również z poziomu MyDOS-a. Przechodzimy do DOS-a z poziomu BASIC-a pisząc DOS, a potem używając polecenia "Copy" (klawisz C) w menu MyDOS, łączymy plik "rzygon.xex" z przed chwilą stworzonym plikiem "rzygon_p.xex":

RZYGON.XEX,RZYGON_P.XEX/A

Restart komputera z wyłączonym BASIC-iem, oraz uruchomienie "rzygon_p.xex", spowoduje uruchomienie gry z wyłączonym dźwiękiem I/O.

Tyle że cała przedstawiona operacja tyczyła się tej konkretnej produkcji, na dyskietce maiłeś normalny file-system, DOS-a, etc. Jeżeli dyskietka lub plik ATR zawierają produkcję która jest programem typu BOOT i nie zawiera żadnego systemu plików sytuacja się komplikuje, i do sprawy należy podejść indywidualnie.

Oczywiście owy plik zawierający te 6 bajtów ($FF,$FF,$41,$00,$41,$00,$00) dołączysz sobie na początku dowolnego pliku .XEX, to o ile sam plik i segmenty INIT nie włączą sobie ponownie dźwięku I/O... to takie pliki .XEX będą się wczytywały po cichu już po odczytaniu pierwszego sektora zmodyfikowanego pliku.

A w takim wypadku to najszybciej będzie zwrócić się do autora gry o patch-a. Sądzę że taką poprawkę może wprowadzić do gry :D

W przypadku transmisji danych dwa generatory POKEY-a są łączone w jeden 16-bitowy, ten połączony generator robi jako "baud rate generator" dla logiki portu szeregowego... ale jak wiadomo każdy rejestr/kanał dźwiękowy oprócz częstotliwości ma również swoją głośność... w przypadku dźwięku I/O (gdy komórka $41 ma wartość różną od zera) do tej. określających głośność wpisywane jest chyba $A8, gdy $41 jest zerem głośność kanału jest ustalana na zero.

Teoretycznie niczego nie powinno być słychać, bo BRG jest ustawiany poza częstotliwością słyszalna dla człowieka... piszę teoretycznie bo w praktyce jest inaczej... Przydźwięk I/O

tak naprawdę jeżeli nie ma takiej opcji w menu/ustawieniach SIO2SD to będzie ciężko Ci ten problem rozwiązać w sensowny sposób. Jeżeli byłaby opcja w SIO2SD która zerowałaby komórkę $41 przed rozpoczęciem transmisji danych to byłoby to najsensowniejsze rozwiązanie. Niestety nie posiadam SIO2SD, więc nie mam zielonego pojęcia czy gdzieś w jego konfiguracji nie kryje się możliwość wyłączenie dźwięku podczas I/O.

Dopsuję się do listy:

Dzięki WIELKIE że chce Ci się tym walczyć! :) świetny pomysł ze złożeniem zdjęcia i projektu! :)

Hi!

I of course I have read Your first post... and I probably understand why You do not include those materials from mega-hz in Your post. I also, have some doubts about license, and maybe some copyrights, because this is mega-hz materials, and I don't asked him for permission, but those files is placed in public place (on his website) so I assumed this not violates his rights (I've included an information from where those files are taken, and the credits are also given), so I finally decided to post those materials from mega-hz web site here, for those reasons:

• we talking about those topic here, so I think it's worth to include all materials here, so the other community members will not have to search for those on the internet.

• for archiving of those materials (as a backup of materials from mega-hz website)

• to keep all the information about this memory expansion in this topic, so the other members of forum can comment, or maybe add some more information. I think it is good idea to share all the knowledge and materials from the past, this is our hobby, this is also pure fun! And this is important for historical reasons and educational purposes.

... and of course I think even with those simple photos and included "Handbuch" it is possible to reverse-engineer and fully reconstruct the schematics... we have two sides of original PCB (those with (c) 1986 CompyShop), so we don't need to have "uncensored" version of mega-hz PCB. Ask Toriman, he probably confirm my words ;)

But I can't help at this moment :( Currently I have other duties to do... if nobody from our community can't help in near future... I will do it, but this can took some time.

gwoli ścisłości... w trybie Hi-Res w przypadku 8-bit Atari litery zawsze mają kolor tła na którym się znajdują... w standardowych warunkach nie uzyskasz białych, czerwonych czy innych liter w kolorze odmiennym niż ma tło... masz wpływ tylko i wyłącznie na ich jasność. A że domyślnie tło masz "niebieskie" to i litery będą miały ten odcień jak zmienisz na zielone to i litery staną się zielone, tak ma być.

Jak już będziesz miał klawiaturę to spróbuj sobie napisać z poziomu BASIC-a np:

POKE 710,196

albo

SETCOLOR 2,12,4

standardowe "niebieskie" tło i litery z o jasności 10, przyjmują odcień tła (0x94):

po zmianie tła na odcień "zieleni" (0xC4) litetry o jasności 10, przyjmują również jego odcień:

Standardowy format zapisu danych używany w przypadku Atari to właściwie transmisja szeregowa plus modulacja częstotliwościowa (FSK)... taki format zapis danych jest bardzo wrażliwy na wszelakie odchyłki od prędkości narzuconej przez prędkość odbioru danych narzuconą przez Baud Rate Generator (BRG)... co prawda procedury obsługujące jak i format danych zostały niby przystosowane do kompensacji odchyłek, np. pomiar aktualnej prędkości danych na podstawie bajtów transmitowanych na początku każdego nagłówka rekordu, a potem korekcję prędkości BRG... do kompletu podział na krótkie rekordy danych... jednak jak pokazał praktyka przy mizernej jakości magnetofonów wszystkie te pomysły były niewystarczające... dodatkowo demodulator FSK zastosowany w przypadku standardowych magnetofonów Atari nie jest szczytem możliwości rozwiązań technicznych dostępnych w tamtym okresie (znowu cięcie kosztów) .... a to powoduje że niewielkie już zniekształcenie sygnału zapisanego na taśmie powoduje przekłamanie w odczycie transmitowanych danych.

Systemy turbo stosują nieco inną zasadę zapisu... nazwaną "modulacją szerokości impulsu" (ang. PWM - Pulse Width Modulation) i można się spierać że to koniec końców dość podobne do FSK, ale założenia teoretycznie i realizacja sprzętowa inna, np. w przypadku odczytu nie mamy tutaj sprzętowego dekodera który decyduje czy to do niego wchodzi na wejściu jest aktualnie transmitowaną "1" czy też "0". Wszystkie systemy turbo swoją konstrukcją sprowadzają się do jednego... do zrealizowania wzmacniacza o dużym wzmocnieniu który będzie mógł przetworzyć zapisany na taśmie sygnał postać zero-jedynkową... potem ten strumień danych jest już przetwarzany "programowo" ... decyzję o tym czy przychodzące impulsy traktować jakoś 0 czy 1 podejmuje kawałek programu mierząc czas trwania poszczególnych impulsów... tutaj oczywiście programista miał pełną dowolność co do wyboru metody kodowania poszczególnych stanów, a także co bardzo ważne... miał dużą swobodę co do wyboru tolerancji długości impulsów... z mojego doświadczenia z systemem Turbo 2000, wynika że autor rozwiązania przyjął bardzo dużą tolerancję systemu na odchyłki dotyczące długości czasu poszczególnych impulsów określających "0", "1" czy sygnał pilotujący.

Moje XC12 w pewnym okresie zaliczyło przysłowiową glebę, przez co skrzywieniu uległa ośka do której dociskana jest taśma, efekt był taki że następowała ogromna nieliniowość przesuwu taśmy, oczywiście zapis i odczyt w "standardzie" okazał się niemożliwy... natomiast odczyt/zapis w przypadku turbo 2000 nadal przebiegał bez problemów, nawet pomimo wyraźnie słyszalnego (i widocznego) nierównomiernego przesuwu taśmy.

Ponieważ na warsztacie mam teraz trochę magnetofonów od kolegi uicr0Bee i zacząłem walkę z innymi systemami turbo, to mogę powiedzieć że systemy turbo która zakładają mniejsze tolerancje i oczekują wyższej liniowości przesuwu taśmy, czy też oczekują wyższego pasma które można zapisać na taśmie dany magnetofon są również bardzo kapryśne i wczytanie części programów staje się nie lada wyczynem, a szczególnie tych które były zapisane dawno, dawno temu. Czy to Blizzard, czy to TurboROM nie wypadają już tak różowo jeżeli chodzi o stabilność pracy. Magnetofon musi być naprawdę w dobrym stanie aby te systemy działały sprawnie i bezproblemowo.

No i do tego wszystkiego błąd w OS-ROM, o którym napisano już wyżej. Czy zatem standard FSK jest gorszy od PWM? Trudno mi to oceniać, ale uważam że doskonałym przykładem że FSK może być równie skuteczne był system Turbo 2600. Ten system pokazuje że dało się skonstruować stabilnie działający demodulator FSK, oraz napisać całkiem poprawnie działające procedury odczytu i zapisu. System ten niestety nie przyjął się, a złożyło się pewnie na to kilka faktów... całe oprogramowanie siedziało pod OS-ROM, w już w tamtych czasach gdy promowano to rozwiązanie w "Radiokomputerze"... duża część oprogramowania ładowała się również w ten obszar, uniemożliwiając poprawną pracę tychże programów z systemem. Nie wiem czemu autorzy rozwiązania nie zaproponowali czegoś w rodzaju loaderów, czy mini Kasetowego Systemu Operacyjnego ładowanego na dół pamięci. Wydaje mi się ze autorzy systemu bardzo chcieli w tamtym czasie chronić swoją "własność intelektualną" i chronili dostęp do informacji o działaniu ich systemu i ograniczali wszelaką wiedze o nim, co przyczyniło się do jego upadku. Interfejs do tegoż systemu były ponoć dostępne w "składnicy harcerskiej" w Warszawie, jednak nie udało mi się nigdy takiego interface kupić. Używając magnetofonu szpulowego M2404S i zew. interfejsu udało mi się natomiast bez problemu uzyskiwać prędkości transmisji na poziomie 1300bd. (przy przesuwie taśmy 19,05cm/s)

to no nie tak że "nikt"... ja jestem bardzo mało reprezentatywną "grupą" reprezentującą to zjawisko :) zapewne jestem jakimś wyjątkiem :P wiesz mogłem siedzieć wtedy długo pod kamieniem... albo "wyginałem" jak dinozaury ;-)