To jest w zasadzie tester elementów - bo o tym mówimy. Też byłem sceptyczny, ale ktoś mi też polecił i zachwalał, więc się skusiłem i jestem bardzo zadowolony. Wpinasz w to jakikolwiek element, w dowolną stronę, a urządzenie wykrywa sobie samo co to jest za element, rysuje Ci na ekranie kolejność wyprowadzeń i szereg parametrów. Dla kondensatorów np. mierzy ESR, miałem też w szufladzie pudło jakichś starych tranzystorów bez oznaczeń, to mi pokazał co to w ogóle jest i poprzebierałem sobie co się przyda a co nie, pomiary są bardzo szybkie. Kondensatory np. mierzy do bodajże 100mF (milifaradów). Małe kondensatory z kolei mierzy już od jakichś 20pF - tu też miałem trochę ceramików ze startymi oznaczeniami, więc już wiem co mam. Elektrolity sprawdzisz dokładnie, okazało się, że niektóre starocie z odzysku mają lepsze parametry niż nowe nieużywane. Ponadto są pady, na których kładziesz i przyciskasz elementy smd i tak samo je sobie sprawdzasz. Ogólnie jestem z tej zabawki bardzo zadowolony. Aha, najważniejsze: wszystko co mierzyłem mierzy bardzo precyzyjnie, myślę, że o wiele dokładniej niż zwykłe multimetry.

Te mierniki UNI-T, które pokazał yamahalodz są bardzo fajne z takich tańszych. Warto tylko zwrócić uwagę, one występują w kilku odmianach, różnią się literką, chyba A,B,C,D - i każdy z nich ma tą samą podstawę V/A/R, ale każda z wersji ma dodatkowo coś tam jeszcze do wyboru, chyba temperaturę, lub pojemność, lub piszczyk, lub coś tam jeszcze, ale to tak nie wiem dokładnie co, tylko pamiętam, że jest ich kilka modeli.

Hehe:-) No widzisz, co człowiek to ma swoje przyzwyczajenia:-) Dlatego kupno miernika to jednak każdy powinien sam dobierać pod siebie. Ale podtrzymuję, że jak amatorsko do zastosowań domowych, to tak na prawdę może być jakikolwiek bądź miernik.

A tak swoją drogą, to dziwię się jer, że masz kłopot z piszczykiem w mierniku. Ja używam starego mernika, którego kupiłem sobie jeszcze w technikum jakieś 25 lat temu i on mi piszczy jak należy:-) I tu dochodzimy do jeszcze jednego aspektu: miernik stary, prosty, podstawowy, prymitywny - ale po tylu latach wiem dokładnie co i jak pokazuje, mam zaufanie do niego, a używając czasem nowych przyrządów współczesnych i tak sprawdzam i porównuję wskazania z moim starym wysłużonym, który stanowi dla mnie wzorzec:-)

@ccwrc, to nie chodzi czy carty są od xangela, czy jakiekolwiek inne, z resztą ja mówię o innej płytce od xangela niż te Twoje kartridże z grami - chodzi o SDX z RTC, których xangel zrobił tylko kilka sztuk.
Chodzi o obciążenie magistral pojemnościami, co wpływa na kształty i długości zboczy sygnałów oraz przesunięcia ich timingów względem siebie, do tego dochodzą zakłócenia, więc i zasilacz ma w tym swój udział. Im bardziej rozszerzone Atari, tym bardziej problematyczne jest dokładanie czegokolwiek, w tym również zwykłych kartridży. Te tematy wracają jak bumerang, jest to kwestia konstrukcji Atari i konstrukcji rozszerzeń - dopóki magistrale nie są buforowane, dopóty każde gmeranie w magistralach niesie ze sobą różnorakie problemy.

Kto nie wysyła za granicę? Zaxon robi klony XF pod różnymi postaciami. Jak nie masz problemu z zakupem, to kup od niego jakąś wersję, wtedy będziesz miał cały komplet części na podmiankę i też sygnały do porównania.

Wiesz co, tak sobie myślę, że nawet bez napędu powinien wstać EPROM wraz z elektroniką, a Intel powinien odpalić program i powinieneś w Atari zobaczyć menu Hyper-XF, które jeden raz zobaczyłeś. To menu odpala się jeżeli nie ma w stacji dyskietki, więc odpalaj stację bez dyskietki, żeby w pierwszej kolejności dojść chociaż do momentu, że Hyper-XF się odpala, a samym napędem zajmij się dopiero jak uzyskasz Hyper-XF na ekranie Atari. Słuchaj, a w jakiej kolejności włączasz sprzęt? Może to banał, ale najpierw włącza się zawsze stację, a dopiero później Atari. Musisz włączyć stację, dać jej chociaż z 5 sekund na odpalenie programu (choć dzieje się to o wiele szybciej) i dopiero włączyć komputer. Wtedy powinieneś zobaczyć na ekranie menu Hyper-XF.

Jeden raz zobaczyłeś Hyper-XF, więc założył bym, że wszystkie układy masz sprawne, a EPROM prawidłowo zaprogramowany. Szukał bym najprostszych rzeczy, czyli najpierw opisany wyżej motyw z kolejnością włączania sprzętu, a jeżeli wszystko robisz poprawnie, to szukał bym problemu w samych połaczeniach (zimne luty, przerwane ścieżki, niekontaktujące złącza, uszkodzone kabelki itp.).

Nie mam stacji 5,25, używam tylko 3,5", ale na moje to ROM A i ROM B właśnie tym się różnią, że nie będzie jeden działał na stacji 3,5, a drugi na stacji 5,25:-)

Aha, nie wiem jaką tam kość użyliście, ale generalnie nie może być tak, że jakaś noga adresowa "wisi" w powietrzu. Wg schematów w oryginalnej stacji noga A12 jest dopięta na stałe do masy, a noga A13 do +5V. Czyli wg tego co napisał pancio.net jak nagrał te obrazy, to wychodzi, że jeśli tylko po prostu wsadziłeś kość w podstawkę wszystkimi nogami, to odpala Ci się HYPROMB - czyli wersja dla stacji 3,5". Jeśli masz stację 5,25, to najprościej odegnij nogę A13 (pin 26) tak żeby nie weszła w podstawkę i kawałkiem przewodu przylutuj ją gdzieś w pobliżu do masy -sprawdź miernikiem, ale wg schematu na tymże EPROM-ie masa powinna być na nogach 2,14 i 22, więc możesz ten kabelek nalutować na eprom z wierzchu bez grzebania w płytce stacji.

Sikor, wpadła mi w ręce oryginalna płytka z kartridża XEGS z grą One On One. W komplecie mam do niej oryginalną naklejkę z tegoż kartridża i nie pasuje ona do okienka w wydrukowanej obudowie od Ciebie.
Naklejka ma 55x53mm, a okienko 54,5x52,5mm.
Myślę, że okienko powinno być większe w obie strony o 1mm niż naklejka, żeby naklejka mieściła się w nim swobodnie. Czyli jakieś 56x54mm by musiało mieć okienko, nie wiem jakie jest w oryginale.

Mam pytanie dot. zawartości materiałów binarnych. Co to jest za plik z tymi polskimi fontami? Oprócz tego, że ma polskie fonty, to zauważyłem, że ma trochę pozmieniane też inne literki. Np. S jest bardziej zawinięte itp. Ale najistotniejsze co zauważyłem, to font ma zamienione miejscami przecinek i średnik. Pytam z ciekawości, to tak ma być, czy może jest to jakaś wersja "rozgrzebana" czy coś w tym stylu? A może celowo font ma szereg jakichś zmian. Czy jest gdzieś do tego opis jakiś autora, lub coś, albo możesz Sikor Ty coś więcej o tym pliku opowiedzieć?

I może trochę wybiegnę tutaj do przodu, ale mam pytanie dot. przygotowania tekstów do gry i ich wyświetlania.
Kłopot jest taki, że jak chcę przykładowo wyświetlić większe ilości tekstu całymi ekranami, to najmniej kosztowne wydaje się być wrzucenie takich tekstów również jako dane binarne i wówczas wyświetlanie ich za pomocą MOVE bezpośrednio wrzucając pod adres ekranu z odpowiednim ofsetem. To działa super, jednak żeby w ogóle zadziałało, to teksty muszą być przygotowane w kodowaniu znaków z użyciem INTERNAL CODE. Jednak jak mamy tak przygotowane teksty, to z kolei nie da się (chyba) łatwo takiego tekstu wydłubywać jednocześnie z pamięci i wyświetlać za pomocą standardowych PRINT, czy TEXT, czy pojedynczych znaków przez CHR$, bo wszystkie te polecenia wymagają z kolei tekstu zakodowanego jako ATASCII. Czy da się jakoś łatwo radzić sobie z tą dualną naturą kodowania znaków na Atari (IC/ATASCII)?

Ja z uwag mam tylko coś o czym już mówiliśmy wcześniej, ale chciałbym przypomnieć: żeby wszystkie pliki, całość prac trzymać w jednym atr i nie bawić się w ustalanie gęstości i innych takich. I tak większość chyba programuje to i testuje pod emulatorem na pececie z racji wygody, a jeśli ktos jest takim hardkorowcem, że robi wszystko na Atari, to również poradzi sobie bez problemu z samodzielnym podzieleniem tego sobie jak mu wygodnie na dyskietkach.
Tak że proponował bym atr 720kB i wrzucić wszystko do niego - ale to już decyzja Sikora.

Ja obecnie dość dużo grzebałem akurat w TBXL przy okazji refaktoringu mojej starej gry z dzieciństwa The Last Disk (udostępniałem na sąsiednim forum) i przy tej okazji doświadczyłem różnych koncepcji, co zaowocowało wypracowaniem najwygodniejszej dla mnie metody pracy. Oczywiście każdy robi po swojemu, ale napiszę jak ja to robię, może się przyda innym.
Po pierwsze skorzystałem z narzędzi Sikora opisanych w tym wątku - wszystko bardzo się przydaje.
Robię tak, że mam atr 720kB, na którym mam MyDOS, TBXL, i pozostałe narzędzia. Pracuję pod Altirra, więc odpalam tego atr-a i z niego startuję. Dodatkowo mam podmapowany katalog na pececie jako H6: i w tym katalogu trzymam cały listing pisanego programu w zwykłym pliku textowym, którego edytuję sobie na pececie (używam akurat Notepad++, który koloruje mi ładnie składnię).
I teraz tak: pracę zaczynam od odpalenia Altirra, następnie uruchamiam TB.COM.
W TBXL piszę sobie ENTER "H6:GRA" (plik nazwałem GRA, żeby szybko się wpisywało).
To powoduje wciągnięcie całego listingu i już można go odpalić RUN
Następnie podczas wprowadzania zmian w listingu nie robię całej operacji za każdym razem od nowa, tylko kopiuję z pliku tekstowego kilka linijek, które akurat pozmieniałem i zwyczajnie w Altirra robię prawym przyciskiem wklej. I znowu RUN.
Bardzo szybko się w taki sposób pracuje. Program przerywam Reset(F5), albo Break(F7). Jak zmienię bardzo dużo w kodzie, to ewentualnie "odświeżam" całość, więc w Altirra robię Shift+F5(cold start), L->TB.COM, ENTER "H6:GRA" i już.
Dodatkowo na każdym etapie wklejania kodu do Altirra można przytrzymać F1(przyspieszenie emulacji), co powoduje szybkie wykonanie szeregu operacji tak długo jak trzymamy F1 - jak puścimy, to wszystko pracuje z powrotem z normalną prędkością.

Jeszcze co do łączenia plików z danymi. Używam Super Packera od Sikora, jest fajny, używam też Mossada - też wszystko super. Ale jak już mamy plik z danymi i chcemy do niego dokładać kolejne dane, które i tak mamy na pececie, to już robię to inaczej, szybciej. Plik binarny edytuję sobie na pececie programem HxD Hex Editor. Jak sobie otworzymy w nim nasz plik z danymi, to zobaczymy, że nagłówek, który dołożył nam Super Packer jest bardzo prosty i można go szybko i łatwo zmieniać ręcznie. Pierwsze dwa bajty, to FFFF, następnie mamy dwa bajty adresu początkowego pod jaki wczytane zostaną nasze dane, a następnie dwa bajty adresu końcowego. Oba adresy mają odwrotnie zapisane bajty (najpierw bajt młodszy, a później starszy -trzeba na to zwrócić uwagę). I teraz jak do swojego pliku doklejam np. kolejne dane, to po prostu wklejam te dane na końcu pliku w HexEditorze, do adresu końcowego dodaję odpowiednią ilość bajtów i poprawiam go ręcznie w pliku. Zapisuję sobie plik i gotowe. Poprawiony plik wrzucam sobie na swojego atr-a również w Altirra. Odmontowuję dyskietkę, wchodzę sobie w Tools->Disk explorer, tam usuwam stary plik, a nowy przeciągam i upuszczam do wnętrza atr-a. I gotowe, podmontowuję z powrotem atr-a i już mam zaktualizowane dane.
Dane binarne wczytuję w pierwszej linii programu za pomocą BLOAD, więc jak robię RUN, to nie muszę o tym pamiętać. Jak już program jest skończony, to wywalam tą linijkę z BLOAD, a dalej kompiluję i łączę wszystko w całość już tak jak opisał Sikor w swoich poradnikach.

Tak, tylko, że nawet gdy to robiłem, to mi się działy jaja. Nie mam już tego problematycznego kodu, ale myślę, że kłopot polegał na tym, że sprawdzałem sobie w szeregu IF-ami po kolei te warunki, tylko że w różny sposób. Prawdopodobnie mój problem się powtarzał dlatego, że na początku sprawdzałem w pierwszej linii Return, więc obojętnie czy sprawdzałem LEN(A$)=0, czy też A$="", to ten warunek prawdopodobnie działał poprawnie i przypisywał odpowiednią wartość pod moją zmienną wynikową. Tylko że po sprawdzeniu tego warunku leciały jeszcze warunki dot. poszczególnych wprowadzonych liter i prawdopodobnie któryś z tych warunków również zwracał prawdę i nadpisywał mi zmienną wynikową inną wartością. Stąd miałem bałagan. Myślę, że temat jest wyjaśniony.