26

(707 odpowiedzi, napisanych Fabryka - 8bit)

Nie powinno. Wygląda, jakby albo układ generujący strob zapisu (który powinien być pojedynczy) wytwarzał jakiś dodatkowy glitch, co jest raczej mało prawdopodobne, bo działa synchronicznie i teoretycznie nic takiego nie ma prawa się zdarzyć, albo to wynik jakichś zakłóceń przenikających liniami adresowymi, r/w albo cs, w drugiej połowie cyklu zegarowego, kiedy teoretycznie powinny być stabilne. Gdyby to wyszło na początku, można by temu w prosty sposób zaradzić, opóźniając propagację SPECEN przerzutnikiem o jeden cykl maszynowy. Teraz już za późno. Nie da się przeprogramować wszystkich Sophii, a nowe oprogramowanie powinno działać na każdej bez wyjątku.

27

(707 odpowiedzi, napisanych Fabryka - 8bit)

Nie zwraca się na to uwagi, ponieważ w zwykłej maszynie, w normalnym trybie, niczemu nie służy. Gdyby nie tryb przyciągania uwagi, rejestr byłby kompletnie bezużyteczny.

28

(707 odpowiedzi, napisanych Fabryka - 8bit)

Wyjaśnienie jest dość proste - przerwanie VBLKI, zanim przepisze zawartości rejestrów-cieni koloru, ustawia w rejestrze maski ($4E) wartość $FE, po czym, przepisując, robi AND z maską, zerując najmłodszy bit. Trzeba albo wyłączyć NMI i ustawiać kolory bezpośrednio w rejestrach sprzętowych, albo przepisać procedurę przerwania w inne miejsce i usunąć z niej maskowanie.

29

(707 odpowiedzi, napisanych Fabryka - 8bit)

mono napisał/a:

Dwa spostrzeżenia po testach które wykonywaliśmy dzięki uprzejmości AtariFana.

Sophia2 rev.3

1. Przy uaktywnionym bicie LUM0EN 8-bitowe są rejestry kolorów COLPF1 i COLPF2, a reszta nadaj jest 7-bitowa.

W pierwszym odruchu chciałem na to odpowiedzieć, jak łyżka - niemożliwe. Wszystkie rejestry koloru w Sophii są fizycznie 8-bitowe, a tylko dla zachowania kompatybilności, bit0 wejść wszystkich rejestrów podłączony jest do magistrali danych przez bramkę AND, której drugie wejście jest sterowane bitem LUM0EN. Zbyt proste, żeby nie działało, albo działało odmiennie na różne rejestry. Pomyślałem sobie jednak, że "jeśli dwie osoby mówią ci, że jesteś pijany... itd." Najprostszy test, który wykonałem w BASIC - cztery pasy w kolejnych kolorach, w grafice 7, wyłączenie NMI i zapis rejestrów koloru sąsiednimi wartościami nieparzystymi i parzystymi - wykazał, że 8 bitowy kolor jest dostępny także przynajmniej dla rejestrów COLPF0 i COLBAK. Jak wyglądały Wasze testy?

2. Przy uaktywnionym bicie HIRESBC i włączonym trybie HiRes (2,3,F ANTIC-a) w pełni odseparowane faktycznie są kolory piksela zapalonego COLPF1 i piksela zgaszonego COLPF2. Natomiast kiedy kładziemy sprajta (co powoduje zmianę koloru piksela zgaszonego), wtedy starą modą podkolorowywany jest również piksel zapalony - czyli kolor brany jest ze sprajta, a luminancja z COLPF1. Wydaje mi się, że byłoby logiczne że kolor i luminancja piksela zapalonego brana byłaby z COLPF1 tak, jak w przypadku zwykłej grafiki niepodkolorowanej sprajtem. Dotyczy to i playerów, i missilli, i włączonego multicoloru sprajtów, i missili połączonych w piątego playera, i priorytetu 0.

Może tak być. Logika priorytetów, ze wszystkimi łatkami, z odtwarzaniem zachowań nieudokumentowanych, jest już tak zagmatwana, że ją teraz nie do końca ogarniam. :) Musiałbym dużo czasu poświęcić na opracowanie łatki, a jeszcze więcej na sprawdzenie, czy czegoś innego przy okazji nie zepsułem. A czasu mam coraz mniej, musiałbym inne rzeczy odstawić. I co dalej? Ogłoszenie akcji serwisowej? Nie bądźmy Volkswagenami. Sprawa zbyt mało istotna moim zdaniem.

30

(707 odpowiedzi, napisanych Fabryka - 8bit)

mono napisał/a:

@Simius: Dwa pytanka:

1. Dokumentacja mówi, że po uaktywnieniu banku rejestrów Sofii licznik palety jest zerowany.
Mówi też, że ostatnie 768 bajtów jest nieużywane.
Mówi też że system domyślnie (rozumiem że po resecie układu) uaktywnia paletę 0.
Czy to oznacza, że licznik 0 wskazuje na paletę 1? Palety są ułożone w kolejności rosnącej w pamięci?

Palety programowane ułożone są w pamięci w kolejności rosnącej. Paleta 0 (default) nie rezyduje w pamięci. Jest tworzona przez logikę i stan rejestrów PAL3..0 = "0000" podłącza ją zamiast pamięci. Ponieważ jednak pamięć palet jest ładowana od adresu 0, a pierwsza ładowalna paleta ma nr 1, po drodze między rejestrem PAL3..0 a pamięcią, jest sumator, który dodaje $0F do zawartości rejestru, przez co paleta nr 1 wypada w pamięci od adresu 0. W ten sposób ostatnia paleta, o numerze 15, kończy się pod adresem $2CFF i obszar $2D00...$2FFF pozostaje nieużywany. Choć oczywiście można tam coś wpisać i licznik przekręci się po przekroczeniu $2FFF. Lepiej tak, niż wysyłać na początku na pusto 768 bajtów.

Rejestr PALDATA ($D01F) jest write-only - nie mógłbyś go zrobić do odczytu? Ja rozumiem że tam są dane dla YPbPr, ale w ten sposób można byłoby zrobić przynajmniej jakiś zrzut palety i/lub ominąć paletę i zaprogramować tylko tą, którą chcę. A potem sobie ją aktywować tylko.

Nie przyszło mi nawet do głowy, że ktoś chciałby zrobić coś takiego. Zresztą prawdopodobnie i tak by się nie udało z powodu braku zasobów. I tak trzeba było dociskać kolanem, żeby zmieściło się to, co jest. Zamierzenie było takie, żeby użytkownik ładował sobie na początku wszystkie potrzebne palety i potem już tylko sobie wybierał według bieżącej potrzeby. 16 palet po 256 kolorów to razem 4096. Za mało?

2. Czy da się rozpoznać tę pierwszą partię która ma 24-bitowe wpisy w palecie? REV=0 czy co?

Da się. Mają niebieską soldermaskę, a nie zieloną i układ 10M04 a nie 10M02, jak pozostałe.

Edit: Albo wybranie palety w PRIOR mogło by ustawiać wskaźnik na jej początek.

Mogłoby, ale to bardziej skomplikowane układowo niż ustawienie jednego bitu, a celowość wątpliwa. W każdej chwili możesz sobie przecież kłapnąć tym bitem i wyzerować licznik.

Edit 2: A może nie są w YPbPr bo przecież jest też tryb RGB (czyli konwersja odbywałaby się w locie przy wybraniu YPbPr). To tym bardziej poprosiłbym o możliwość odczytu.

Nie ma oddzielnych palet YPbPr. Konwersja RGB do YPbPr jest wykonywana arytmetycznie. Jak pisałem wyżej, raczej bym na to nie liczył.

Reszta później.

31

(2 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

Gdzieś powinienem mieć. Poszukam. Chyba nie był żółty.

O, widzę, że Duddie też zrobił folie dwuwarstwowe i nawet się nie pochwalił. Szkoda tylko, że nie na podstawie własnego projektu.
Moje w każdym razie są wciąż dostępne, w cenie 65zł + VAT + wysyłka. Myślę o sklepie internetowym, ale tymczasem jeśli ktoś chętny, proszę o PM.

33

(58 odpowiedzi, napisanych Sprzęt - 8bit)

marxc napisał/a:

@_tzok_
Przedzwoniłem też A(RD4) z 13(5V) nie ma zwarcia

Bez sensu. Może wcale nie być zwarcia. Wystarczy rezystancja w granicach 2kohm do +5V i już będzie źle. Powinieneś zmierzyć napięcie na RD4. W sprawnym komputerze jest poniżej 0.1V. Jeśli jest max. 0.8V to dobrze. Jeśli 0.8-1.4V to już bardzo podejrzane, a powyżej 1,4V z całą pewnością źle. Jest tu tylko jedna trudność. Niski stan na RD4 jest wymuszany rezystorem 1kohm do masy. Jeśli ten rezystor jest uszkodzony, to wejście MMU pływa i napięcie na nim jest nieznane, czyli może odpowiadać stanowi wysokiemu. Próba zmierzenia go miernikiem nie powiedzie się, bo mierniki mają rezystancję w granicach 1-10Mohm, a rezystancja polaryzująca wejście może mieć wartość gigaomową. Dlatego oprócz napięcia trzeba jeszcze zmierzyć rezystancję między RD4 a masą. Czy jest ten 1kohm.

34

(11 odpowiedzi, napisanych Bałagan)

Musi jacyś komodorowcy biedaka dopadli.

35

(22 odpowiedzi, napisanych Sprzęt - 8bit)

https://www.tme.eu/Document/1e3efc14b81 … d/48_4.pdf

Wymiary zbliżone.

36

(22 odpowiedzi, napisanych Sprzęt - 8bit)

https://www.tme.eu/Document/1e3efc14b81 … d/48_4.pdf

Wymiary zbliżone.

37

(22 odpowiedzi, napisanych Sprzęt - 8bit)

12V na wyjściu, czy 2*6V? Bo na schemacie widać podwójne uzwojenie.

38

(22 odpowiedzi, napisanych Sprzęt - 8bit)

Zdaje się, że są różne wersje tych 410, z różnymi transformatorami, a jak ktoś ma szukać, to musi wiedzieć, czego - moc, wymiary, napięcie. Dane z serwisowki wskazują na mniej niż 5V.

39

(707 odpowiedzi, napisanych Fabryka - 8bit)

Montezuma napisał/a:

24. Lampionik - 2 szt (DVI)
25. thar97 - 1 szt (DVI)
27. Spider1975 - 1 szt (DVI)
28. Arko - 1 szt (DVI)
29. Grasol
31. jet - weź pan, każdy bierze (1 szt.)
32. Lexx ( 1szt. DVI )
33. W1k - 1 szt.
34. j4zon3k - 1 szt.
35. pawelkrak - 1 szt.
36. AS - 1 szt. dvi z kablem - potwierdzam 2022-12-08
37. SoundWave - 1szt. potwierdzam 2023 01 23
38. Ryswoj2 -1szt. DVI
39. mix1k - 1 szt. DVI
40. Montezuma - 1 szt

40

(9,977 odpowiedzi, napisanych Bałagan)

Z ciekawości spytam, jakie cele preferujecie za te siedem lat - progresywne, czy ambitne? To znaczy kartki na mięso i talon na samochód, czy tylko sałata i autobus?

41

(31 odpowiedzi, napisanych Sprzęt - 8bit)

Ja używam przystosowanego do Atari kabla Vivanco:
https://c.scdn.gr/images/sku_main_images/036694/36694994/20220616140617_vivanco_s_vhs_to_s_vhs_5m_m_m_for_video_connection_12313.jpeg
Poszczególne żyły są dobrze ekranowane i wyraźnie od siebie odseparowane. Nie mam zastrzeżeń do jakości. Choć trzeba uwzględnić, że kabel ma już chyba z dziesięć lat, więc może nie być identyczny z aktualnie dostępnymi.

42

(12 odpowiedzi, napisanych Sprzęt - 8bit)

A to jest jakiś problem z 6502? W wersji 2MHz (A) mam kilka sztuk w szufladzie.

43

(707 odpowiedzi, napisanych Fabryka - 8bit)

Okazuje się, że w tych dwóch Zosiach faktycznie był wadliwy firmware. W trzeciej za to tylko zwykły, niewyłapany wcześniej niedolut. Nie wiem, jak to możliwe, bo nie mam na dysku starego firmware do tej wersji PCB. Muszę przejrzeć wszystkie zewnętrzne dyski i pendrivy, bo może omyłkowo podczytałem jakiś archiwalny plik z któregoś z nich, przypadkiem wtedy podłączonego.

44

(707 odpowiedzi, napisanych Fabryka - 8bit)

Nie ma rady. Odeślij. Sprawa wymaga dokładnego zbadania.

45

(707 odpowiedzi, napisanych Fabryka - 8bit)

Sprawdź, ale nie sądzę, żebym się pomylił. Nawet nie widzę takiej możliwości. Próbowałem znaleźć wersję z błędem, dla sprawdzenia, ale wszystkie z FPGA w obudowie BGA169 są poprawione. Błąd zachował się tylko w projekcie przeznaczonym do prototypu w TQFP144. Zresztą opis zachowania nie bardzo się zgadza. Poczekajmy na to, co napisze kmor.

Edit: o, już napisał

46

(707 odpowiedzi, napisanych Fabryka - 8bit)

Masz ten efekt na wszystkich trzech, czy tylko na jednej? Sprawdziłem u siebie kilka płytek i czegoś takiego nie zaobserwowałem.

47

(707 odpowiedzi, napisanych Fabryka - 8bit)

24. Lampionik - 2 szt (DVI)
25. thar97 - 1 szt (DVI)
26. kmor - 3 szt. - potwierdzam 2023-01-09
27. Spider1975 - 1 szt (DVI)
28. Arko - 1 szt (DVI)
29. Grasol
30. Inmark - 1 szt. - potwierdzam 2023-01-08
31. jet - weź pan, każdy bierze (1 szt.)
32. Lexx ( 1szt. DVI )
33. W1k - 1 szt.
34. j4zon3k - 1 szt.
35. pawelkrak - 1 szt.
36. AS - 1 szt. dvi z kablem - potwierdzam 2022-12-08
37. rodos - 1 szt.
38. pirx - 2 szt potwierdzam 2023-01-09
39. RiverRaid - 2szt (DVI) z kablem-potwierdzam 2023-01-10
40. Sebastin -1 szt (DVI) - potwierdzam 2023-01-10

48

(707 odpowiedzi, napisanych Fabryka - 8bit)

Inmark napisał/a:
Simius napisał/a:

Dostaniesz więcej, ponieważ obraz w trybie 1280x1024 obejmuje swoja szerokością tylko okno w GR.0, czyli niewidoczne pozostaje wszystko po bokach. W trybie 1536x960 widoczne jest wszystko, co Atari potrafi wygenerować.

Mistrzu @Simius: efekt "widoczne jest wszystko" w których jeszcze trybach Zosi występuje ?

Pozdro
Iro

1704x960

49

(486 odpowiedzi, napisanych Fabryka - 8bit)

Chyba raczej wyciera?

Edit: przyczyna problemów może tkwić także w samym wtyku krawędziowym. Połaczenia zaciskane po dłuższym czasie użytkowania, przeginania taśmy, potrafią tracic kontakt. Nie zawsze samo zdjęcie i zaciśnięcie w nowym miejscu usuwa problem, bo same widełki zaciskowe robią się luźniejsze. Pomagaja precyzyjne szczypce i szczelinomierz 0.1mm. Przewody wstążkowe mają z reguły nominalny przekrój 28AWG (0,08mm2), ale trzeba pamiętać, że to wszystko chińska produkcja, a Chińczycy to naród oszczędny. Dlatego nominalne 28AWG oznacza zwykle siedem drutów o średnicy 0.1mm, czyli w sumie 0.055mm2.

50

(486 odpowiedzi, napisanych Fabryka - 8bit)

Można by sobie teoretycznie taki adapter wyobrazić, ale nie widziałem.