151

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

pasek wymieniony i nowy... napędza koło zębate, które to ma trzpień na górze (to jasne, po lewej), do którego dociskane jest kółko pośrednie... jak obkleiłem chwilowo trzpień koła zębatego taśmą to koło pośrednie zaczęło się ślizgać na styku z prawym tależykiem.

A stają oba koła bo napęd jest z trzpienia koła zębatego po lewej... zaraz wrzucę drugi filmik.

https://www.youtube.com/watch?v=glGERBdnxtc

^^^ Wszystko wskazuje na to że ów materiał cierny na kole pośrednim jest totalnie sztywny i "wyślizgany" ... nie rozbierałem tego koła jeszcze, ale wygląda że też to koło składa się z plastików i części wewnętrznej, tylko ne wiem jak to rozebrać bez destrukcji plastików, tzn. samo kółko wyjąć potrafię, tylko tej powierzchni która styka się innymi kółkami ruszyć nie mogę.

152

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

Dzień Dobry Wieczór wszystkim! :)

Już kiedyś pytałem o podobną sprawę, ale ona dotyczyła magnetofonu Atari 410, tym razem chodzi o XC12 i ślizgające się koło pośrednie....

https://www.youtube.com/watch?v=ngpgRnJmZCI

^^^ trafia mi się coraz więcej magnetów które mają tę przypadłość... zgaduję że znowu jest problemem materiał na kole pośrednim który stracił swoje właściwości... i teraz pytanie do was ... czy ktoś ma jakiś patent na naprawę tej przypadłości?

W przypadku Atari 410 szanowny kolega Perinoid udzielił mi genialnej w swojej prostocie porady... można o tym poczytać w tym wątku: magnetofon Atari 410 - naprawa

Niestety zupełnie nie mam sensownego pomysłu jak rozwiązać tę kwestię w przypadku XC12 czy też pochodnych?

153

(19 odpowiedzi, napisanych Bałagan)

syscall napisał/a:

Działa, używam produkcyjnie w jednym projekcie.

Dzięki za info! Warto wiedzieć że ten program nadal funkcjonuje pod nowszymi wersjami windy :)

154

(19 odpowiedzi, napisanych Bałagan)

Jeżeli nie chcesz niż przerabiać po stronie kodu w ATMEL-u, to jeżeli korzystasz z windows i program w ATMEL wysyła to jako IntelHEX, a więc właściwie ciąg znaków ASCII, to można wykorzystać jakiś program terminalowy (np. "TerraTerm Pro" lub PuTTY i używając którychś z tych programów, można mieć konsolę terminala która będzie mogła odebrać ciąg znaków z portu COM. Potem to co wyszło na konsolę można sobie albo zapisać do pliku albo skopiować do schowka i gdzieś przenieść. Nie potrzeba odpalać CMD i używać polecenia Copy. Nie wiem którego Windows używasz, jeżeli jakiegoś starszego to w nim był wbudowany program terminalowy (HyperTerminal).

A jeżeli dodatkowo trzeba wysyłać jakieś dziwne sekwencje do tej płytki z ATMEL-em aby cokolwiek zechciała odpowiedzieć (np. jakąś nie czysto tekstową sekwencję bajtów) to można skorzystać z takiego narzędzia jak terminal od Br@y++. Jest to dość wiekowy soft, używałem go za czasów windows 7, miał mocno rozbudowane opcje wysyłania różnych sekwencji bajtów, makra, etc. Niestety nie wiem czy obecnie działa to jeszcze pod Windows 10, nie mam pod ręką żadnego nowożytnego Windows aby to sprawdzić.

Jest też trzecia opcja, trzeba by napisać sobie prosty program który odbierze taki plik intel-hex z portu szeregowego i zapisze go do pliku.

ps) grzebanie w przeszłości, szczególnie takiej może dać dużo radości :) Zatem życzę owocnego grzebania w projekcie :D

155

(19 odpowiedzi, napisanych Bałagan)

Hej!

@Zenon: z tego co pamiętam z czasów używania RS-ów, Modemów i DOS-a to transmisja z kanału znakowego jakim może być port COM: była kończona gdy w strumieniu danych znalazł się tzw. control-character oznaczający koniec pliku (EOF), a przypadku PC/DOS była to sekwencja generowana po naciśnięciu control+Z, więc jeżeli to ATMEL nadaje w stronę PC to spróbuj jako ostatni wysyłany bajt pliku wysłać bajt o wartości 26 (dec), czyli 0x1A (hex).

Nie sprawdziłem tego jeszcze więc traktuj moje wywody z dużą dawką ostrożności, bo piszę "z pamięci" która bywa mocno zawodna.

Na pytanie dlaczego kiedyś to działało, odpowiedź może być taka że być może kiedyś BIOS czy DOS inaczej traktowały odbiór danych i miały założony jakiś timeout po którym po prostu kopiowanie się kończyło lub oczekiwane było nadanie znaku "BREAK" na linii transmisyjnej (zero logiczne utrzymujące się dłużej niż 10 bitów). Nie wiem czy obecne systemy Windows potrafią prawidłowo taki sygnał zinterpretować. Wszystko też zależy od portu jaki masz na płycie, nie wiem czy używasz prawdziwego RS232 czy też jakiejś przejściówki RS232-USB, ale część takich przejściówek nie potrafi prawidłowo rozpoznać sygnału BREAK na linii RX.

Podsumowując ta moją nieco przydługą odpowiedź, możesz spróbować wysyłać ten dodatkowy bajt na końcu danych (#26 / $1A) lub też po zakończonej transmisji ustawić linię TX po stronie ATMEL-a na logiczne "0", na tyle długo aby komputer PC zorientował się że został nadany sygnał BREAK.

156

(32 odpowiedzi, napisanych Miejsca w sieci)

Czyta jak najbardziej! :) W dawnych czasach nie miałem okazji przeglądać ani do Horyzontów Techniki ani do Przeglądu Technicznego, to teraz dzięki Twojej robocie mogę zobaczyć jak to kiedyś wyglądało :) Dzięki!

157

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

Nie ma za co :) Ktoś chciał mieć magnet co czyta kasety zapisane w kilku standardach turbo. Mój XC12 swego czasu też wyglądał jak gniazdo węży, bo chciałem czytać co tam mi się pod rękę nawinęło. Dodawałem jakieś modyfikacja do szybkiego hamowania silnika, LED-y pokazujące aktualny tryb pracy, zmiana LED-a od zapisu na dwu-kolorowy (zielono-czerwony) tak aby pokazywał kiedy jest silnik włączony a kiedy następuje zapis. Masa kabli i przewodów.

Ten magnet co masz jest całkiem ciekawym okazem, warto go zachować... jeżeli działa to uporządkować te wszystkie przewody, ogarnąć trochę wnętrze. Jeżeli nie działa warto go uruchomić. Kolejna ciekawostka w przeszłości którą warto zachować.

158

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

co do pierwszego zdjęcia, to jak najbardziej podtrzymuję to co pisałem... to jest jakiś klon czeskiego Turbo 2000, tzn. może to być "Wrocławskie Turbo 2000", lub cokolwiek innego zgodnego z czeskim Turbo 2000, tzn. AutoTurbo, Atari Hard Turbo, etc.

Płytka turbo jest właśiwie identyczna tym co zastałem kiedyś w magnetofonie XC11 od uicr0Bee-iego: XC11 - Turbo 2000 CZ.

Co do drugiej płytki to dużo wskazuje na to że to może być ta wersja Blizzard-a, którą już kiedyś rozrysował Zenon: Blizzard v2.

Oczywiście masz jeszcze tam masę innych kabli, modów i innych przysłowiowych "przyczłapów" :P Ale analiza tego ze zdjęć nie ma już najmniejszego sensu, za dużo w tym by było dywagacji i zgadywania. Tutaj potrzebne jest trochę cierpliwości, czasu, sprzęt na stole, kartka, ołówek i można by rysować co autor tego gniazda węży miał na myśli składając tego małego frankensteina :D

159

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

#1) Blizzard Turbo ---> http://www.atari.org.pl/forum/viewtopic … 80#p286080

#2) gdybyś zrobił ostrzejsze i nieco bardziej dokładne zdjęcia może by dało się coś więcej wywnioskować, a tak to mogę tylko zgadywać że są to dwa systemy turbo wmontowane w jeden magnetofon, jeden z nich to prawdopodobnie klon czeskiego Turbo 2000, lub tzw. wrocławskie Turbo 2000, drugie turbo to może być Blizzard (wersja na UL1111 + UCY7400)

160

(31 odpowiedzi, napisanych Software, Gry - 8bit)

@faust: świetny pomysł! :D Bardzo mi się podoba efekt działania Twojego kodu :) ... pobawiłem się chwilę i zauważyłem jedną drobnostkę... przy wyborze "atari dwie strony wpisu" pojawia się okładka na której widać na jednej z krawędzi napis "COMPUTER CASETTE", dałoby się poprawić aby było "COMPUTER CASSETTE"? :)

Druga uwaga dotyczy grzbietu na którym widnieje napis z numerem zestawu, w przypadku okładek Atari (tylko takie sprawdzałem) jest kawałek miejsca w którym można by umieścić dodatkowy napis, tak aby był widoczny gdy kaseta stoi/leży sobie na półce (grzbietem do użytkownika). Wtedy oprócz numer zestawu możnaby mieć dodatkowe informacje dotyczące danej kasety np. *** PIRAT SOFT *** ;-)

na Twoim przykładzie pokazanym wyżej widzę za to logo ATARI, u mnie jest po prosu białe tło, dlatego pomyślałem o napisie :D

161

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

Zgrd napisał/a:

Bezpośrednie podpięcie się do TV sygnałem kompozytowym (s-video już przerasta nowoczesny tv) daje obraz bez pasów.

Może to głupie pytanie, ale jeżeli bezpośrednio wepniesz się z konwertera do TV (przez HDMI) to też widzisz te pasy?
Pytam ponieważ to co pokazujesz może wyglądać (ale nie musi) jako "artefakty" kompresji którą robi grabber. Pytanie czy możesz zwiększyć bit-rare strumienia video generowanego przez grabber? Jakiej kompresji używa grabber (h264/h265) ... do jakiego portu jest podpięty (USB 2.0, USB 3.0 czy to może karta PCI-Ex)?

Pytam o to wszystko bo kiedyś dawno temu podobne "efekty" miałem na starym grabberze który potrafił robić tylko kompresję MJPEG w dodatku z niskim bit-rate, każdy błąd kwantyzacji był "propagowany" i widać było to właśnie w postaci takich bloków, w momentach w których w obrazie występowały duże różnice jasności (luminancji).

Jeżeli te pasy są również na TV bezpośrednio po wyjściu z konwertera, taki efekt może występować przy zastosowaniu kabla o nieodpowiedniej impedancji falowej (kabel nie ma 75 ohm) i to co widzisz to odbicia sygnału powstałe w kablu i konwerterze. Może być też tak że konwerter nie ma rezystora 75 ohm na swoim wejściu (widziałem takie konwertery) i jego impedancja wejściowa jest dość wysoka, a to może sprzyjać powstawaniu takich odbić (szczególnie przy niedopasowanej impedancji przewodu łączącego konwerter z wyjściem Atari) ... pomóc może rezystor 75 ohm podłączony pomiędzy wejście konwertera a masę (ważne aby rezystor był jak najbliżej wejścia konwertera). Jeżeli podłączasz po s-video to te rezystory muszą być dwa (jeden dla chrominancji, drugi dla luminancji).

162

(115 odpowiedzi, napisanych Software, Gry - 8bit)

^^^ dorzuciłem do poprzedniego posta również wszystkie pliki źródłowe niezbędne do wygenerowania plików wykonywalnych (zarówno w wersji z trainerem, jak i wersji "pure"). W środku są też źródła depacker dla formatu ICE! (generowanych PACK-ICE) ... skoro już to wygrzebałem z odmętów przeszłości to posprzątam ten chaotyczny kod naklepany na kolanie, dorzucę jakiś przykład jak tego używać i wrzucę jakoś na github, a może się komuś przyda w przyszłości :D a nawet jeżeli nie to niech zostanie w ramach ciekawostki historycznej.

Takie eksperymenty pokazywały że kod z Motoroli 68000 dało się w miarę bez problemów przenieść na 6502, ba... dało się go nawet jakoś optymalizować i przyspieszać. nazwy lokacji na stronie zerowej nazwane D1, D2, D4, D7 czy AD0 nie są przypadkowe maja odwzorowywać oryginalnie użyte rejestry w kodzie depackera napisanego w ASM dla Motoroli 68000. Ta procedura dekompresji była właśnie pisana na podstawie analizy kodu oryginalnego depackera dla PACK-ICE dla M68K który wpadł wtedy w moje łapy ;-)

163

(115 odpowiedzi, napisanych Software, Gry - 8bit)

@Polar Pierre: No dobra, dorzucam na razie samą wersję .XEX ... niebawem jak dopiszę "readme" to wrzucę też i źródła. Prawdę mówiąc mam dość już tej gry ;D nie wiem czy ona nie jest napisana w jakimś języku, bo kod w tej grze to jakieś dziwne bagno jest, w dodatku gra ma masę błędów :D poprawiłem błędne wyświetlanie "game over" w przypadku wyboru opcji gry na dwóch graczy.

Wersję z "trainerem" robiłem z wersji kasetowej, bo wersja dyskowa ma doczytywaną każdą planszę po przejściu poprzedniej. W dodatku gra w wersji dyskowej ma o wiele więcej plansz. Ta wersja ma ich mniej, w dodatku zajmują te plansze również obszar aż do $BEFF, a więc pakuje się to w obszar ekranu ($BC20-$BFFF), ale dlaczego o tym piszę? Bo gra jest "odporna" na RESET i po jego wciśnięciu startuje ponownie, jednak w tym wypadku ostatnia plansza dostępna w grze która znajdowała się w obszarze $BC00-$BEFF zostaje zniszczona, gra po wciśnięciu RESET ma jakby o jedną planszę mniej, ale to chyba i tak nie ma znaczenia, ponieważ gra i tak nie ma zakończenia i po przejściu ostatniej dostępnej planszy startuje niejako od poziomu #1.

Jak pisałem wcześniej, dorzucę później źródła gdyby kogoś interesowało "jak to zostało zrobione", dla nie lubiących kompresji (dłuższy czas oczekiwania po wczytaniu) ostrzegam iż ta wersja została spakowana PACK-ICE 2.40 (z ATARI ST), więc dekompresja trochę trwa ;-) Źródła niebawem będa dostępne więc jeżeli ktoś będzie chciał, będzie mógł bardzo łatwo zrobić sobie wersję bez dekompresji :)

164

(115 odpowiedzi, napisanych Software, Gry - 8bit)

x_angel napisał/a:

A w "Moon Patrol color fixed" wstawiłeś poprawioną wersję? Bo nie widzę różnicy między "przed" a "po" :)

No wersja z tego postu: http://www.atari.org.pl/forum/viewtopic … 98#p302698

jest na 100% poprawiona, własnie sprawdziłem, wygląda tak:
http://seban.pigwa.net/aa/moon_patrol_color_fixed.png

przed poprawką było tak:
http://seban.pigwa.net/aa/moon_patrol_color_bad.png

165

(115 odpowiedzi, napisanych Software, Gry - 8bit)

@x_angel... pewnie że rzucę okiem, ale powiedz mi proszę czy "to tak ma być"? ... tzn. chodzi mi o to, że gdy wybiorę grę na dwóch graczy i na planszy pojawia się JACQUES, to zamiast jego wyniku, liczy żyć, etc. od razu pojawia się napis GAME OVER, próbowałem wersję dyskową i kasetową z atarimania i obie wersje mają tą samą wadę/błąd... czy to zawsze w tej grze tak było? (prawdę mówiąc to nie pamiętam jak było w wersji którą miałem na kasecie w Turbo 2000).

166

(115 odpowiedzi, napisanych Software, Gry - 8bit)

@pustak: tak, faktycznie... ta gra ma w sobie coś że chce się grać i grać ;-) Nie dłubałem w tym zbyt długo, więc nie ma trainera, ale dodaję do załącznika wersję z nieśmiertelnością zrobioną na szybko.

Gra przechowuje aktualną liczbę pozostałych żyć pod adresem $0615, pod adresem $58D2 znajduje się instrukcja DEC $0615, którą reprezentuje ciąg bajtów $CE $15 $06, w pliku zamieniłem zatem ciąg $CE $15 $06 na $2C $15 $06 co odpowiada instrukcji BIT $0615, co powoduje że komórka $615 nie jest już zmniejszana,  instrukcja BIT w tym wypadku "robi" za dwu-bajtowego NOP-a.

Co prawda gra po pierwszej "śmierci" gracza znika jedną z kulek reprezentujących liczbę żyć (tak napisano kod gry i nie chciało mi się tego poprawiać), ale od tego momentu liczba "kulek" nie będzie już ulegała zmianom :)

167

(14 odpowiedzi, napisanych Programowanie - 8 bit)

No to mamy nowego króla wydajności (pomijając LUT na który trzeba zmarnować 256 bajtów pamięci :P)

http://seban.pigwa.net/aa/parity_bench2.png

ja metodę xor-based znałem ze świata HDL-owego (dlatego pisałem o tym że HDL-owo się zrobiło jak ją Willy zaprezentował), tzn. stosowałem ją np. w kodzie verilogowym dla SlightSID-a, tyle że w verilogu to jeszcze prościej, w przypadku rej. konfiguracyjnego SlightSID-a musi się zgadzać parzystość danych, tylko wtedy rej konf. będzie "zaktualizowany":

inout [7:0]            ata_DAT;            // ATARI data bus
...
...
if (atr_str[7:0]==8'h41 && ~(^ata_DAT)) cfg_reg  <= ata_DAT;

a więc jak widać całe "obliczenie" parzystości sprowadza się do wykonania operacji XOR na wszystkich bitach i zanegowaniu wyniku:

parity = ~(^ata_DAT)

I to jest własnie piękno "języków opisu sprzętu!" :D

W sumie po tych moich przygodach z parzystością na początku lat '90 nigdy potem nie miałem potrzeby obliczania parzystości na 6502 i zaprezentowałem te moje wykopalisko z przeszłości bez większego zastanawiania się nad problemem, nawet nie chodziło mi o żaden wyścig na cykle, a temat potraktowałem jako ciekawostkę, która koniec końców dzięki waszym postom przekształciła się całkiem ciekawy wątek. W dodatku QbaHusak zainspirował mnie to optymalizacji i napisania tego mini-bechmarka, wiem że nie jest on doskonały ani jakiś "pro", ale mniej więcej spełnia swoje zadanie pozwalając zweryfikować czy każda z procedur działa poprawnie i ile czasu się wykonuje.

Ostatni kod zaprezentowany przez Willy-iego (ten z 6502.org) pokazuje jak bardzo ekstremalnie można zoptymalizować każdy problem! :) To się nazywa pomysłowe wykorzystanie dostępnych instrukcji CPU aby osiągnąć efekt końcowy :D Ten fragment kodu w zestawieniu z verilogową implementacją bardzo fajnie pokazuje jak rozbić problem natury typowo równoległej na coś co da się wykonać etapami, i co ciekawe nie krok po kroku (metodą zliczania poszczególnych jedynek) ale jak wykorzystać możliwości prymitywnego ALU którym dysponuje 6502 do "zrównoleglenia" operacji.

@marok: dzięki za miłe słowa, jednak uważam że nie robię nic wyjątkowego, a to że czasami mi coś wyjdzie można chyba tłumaczyć tylko tym że jak mnie jakaś rzecz zainteresuje to staram się poznać dany temat jak najlepiej, czy też na tyle na ile pozwala moja możliwość percepcji. Sądzę że inni są o wiele bardziej sprawni w różnych kwestiach. Dla mnie niektóre rzeczy są po prostu poza zasięgiem bo wymagają jakiegoś mega abstrakcyjnego myślenia, co w moim przypadku jest chyba jakimś problemem... mój mózg działa chyba w ten sposób że wszystko dla niego musi być logiczne i wytłumaczalne w prosty sposób, jeżeli problem jest natury abstrakcyjnej trudno zainteresować moją mózgownicę tego rodzaju problemami, tak już mam i nic na to nie poradzę :D

Grzegorz,

Dzięki za linki i fotki, dzięki Twoim wykopaliskom wiadomo chociaż że na takim carcie był standardowy i typowy soft dla Blizzarda, dobrze że wiedzieć że nie trzeba poszukiwać kolejnego "artefaktu z przeszłości", jeden problem mniej na głowie :D

A dla zobrazowania jak wygląda ładowanie przykładowej gry z magnetofonu Yolk-a... z użyciem podobnego softu jaki znajdował się na carcie "Blizzard Megasoft", wrzucam to video: (zgrane z realnego sprzętu, w roli głownej magnet Yolka, jeden z cartów od uicr0Bee-iego oraz kaseta nagrana z pomocą Turgena od Baktra):

https://www.youtube.com/watch?v=tXP9ALcZAsU

169

(6 odpowiedzi, napisanych Bałagan)

drobne uściślenie, Archer Maclean nie zmarł w wigilię, w/g informacji na Wikipedii: https://en.wikipedia.org/wiki/Archer_Maclean lub tutaj: https://fusionrgamer.com/2022/12/25/arc … s-left-us/

zmarł on 17 grudnia 2022 przegrywając długą walkę z nowotworem. Pokłony dla mistrza. Niech spoczywa w pokoju. Dropzone było i nadal jest naprawdę niesamowitą grą.

170

(14 odpowiedzi, napisanych Programowanie - 8 bit)

Oczywiście że wszystko można, nawet zrobić benchmark tak aby faworyzował dany algorytm, zresztą to i tak nie istotne... willy zapodał taki algo który nie zależy od ilości zapalonych/zgaszonych bitów. Zresztą każdy może powalczyć, do tego posta dodaję źródła na prędce skleconego "benchmarka"... to czy liczymy wszystkie wartości ($00-$FF) czy też sekwencję pseudo-losową ($D20A) ma niewielkie znaczenie, tzn. nie zamienia miejsc na liście w tym moim pseudo-benchmarku ;D

Jeżeli chodzi o ten mój ślimakowaty algo bazujący na pomyśle Kernigana, to podobało mi się w nim to że nie był zależny czasowo od wartości, np. czas wykonania obliczeń zarówno dla wartości $AA,$55,$0F,$F0 będzie identyczny... tzn. pętla skończy się po 4 przebiegach ... Zresztą różnice (w porównaniu z Twoją implementacją) są niewielkie... i całe te nasze wyścigi są czysto "akademickie", to takie udowadnianie wyższości jednych świąt nad drugimi ;-)

http://seban.pigwa.net/aa/parity_bench.png

EDIT: Wyniki w tabelkach się nieco zmieniły (na wyższe) ponieważ w stosunku do wersji pierwotnej przybyło kodu w pętli pomiarowej, a nie chciało mi się już bawić w kompensację tegoż, gdyż wszystkie algo zostały ponownie uruchomione w "nowych warunkach". Drastycznie przybyło czasu dla wersji LUT, ponieważ proste LDA parity_table,X zostało zastąpione skokiem do procedury (a jak wiadomo JSR/RTS kosztują sporo czasu ;P)

171

(14 odpowiedzi, napisanych Programowanie - 8 bit)

hi hi hi... wiedziałem że to się tak skończy :D nie wklejałem swojego wiekowego kodu aby udowadniać jaki jest szybki... to tak jak pisałem "kalka" algorytmu Kernigan-a przepisana bez jakichś specjalnych optymalizacji, bo i tak użycie LUT o wielkości 256 bajtów jest nie do pobicia, ale skoro zaczyna się "walka na cykle", to ja będę uparty jak osioł :D tzn. będe obstawał przy swoim (żartuję oczywiście), ale w ramach eksperymentu myślowego wyobraźmy sobie następującą procedurę testową:

st      sei
        inc    $d40e
        lda    $d40b
        bne    *-3
        sta    $d400

m_loop  lda    $d40b
        bpl    *-3
        lda    $d40b
        bmi    *-3
        lsr    $d01a

        ldx    #$00
l1      txa

        jsr    parity

        inx
        bne    l1

        inc    $d01a
        lda    $d40b
        cmp    vc_max
        bcc    l_nup
        sta    vc_max

l_nup    jmp    m_loop

A więc synchronizujemy się z VBL (powrót pionowy), obliczamy parzystość dla wszystkich bajtów od $00 do $FF, po czym odczytujemy wartość vcount ($D40B) sprawdzamy czy jest ona mniejsza czy większa niż poprzednio odczytana i zapamiętujemy ową wartość tylko jeżeli jest większa niż poprzednio odczytana (czyli zapamiętujemy najbardziej pesymistyczny przypadek)... i tak pętlimy w kółko (wartość vc_max) można odczytać pod debuggerem/emulatorem.

I teraz skoro już mamy procedurę testową zaproponuje swoje "zoptymalizowane" rozwiązanie, skoro użyłeś rej. Y (moja stara procka nie używała rejestrów X,Y, tylko A i lokacji na stronie zerowej) to zakładam że również mogę a więc:

parity  sta    v
    
        ldy    #0
    
        ora    #0
        beq    endp

loop    iny
        sec
        sbc    #1

        and    v
        sta    v
        bne    loop
    
endp    tya
        lsr    @
        rts

^^^ a więc tak jak u Ciebie, wejście rej. A, wyjście C.

I teraz prezentacja wyników: (mniej --> lepiej)

     LUT: $0D
   willy: $40
lizard_1: $6A
   seban: $6F
lizard_2: $78
qbahusak: $85

nie sądziłem że wyjdą z tego wyścigi na cykle! Ale skoro się zaczeło to czemu nie! Na pewno wyjdzie z tego coś fajnego! :)

EDIT1: o widzę że szybko się dzieje, willy dopisał wersję xor-based :D że tak powiem mocno HDL-owo się zrobiło! i szybko! :D uzupełniam zatem tabelkę.
EDIT2: dodałem do tabelki wyniki procek zaproponowanych przez Lizarda.

172

(14 odpowiedzi, napisanych Programowanie - 8 bit)

Kiedyś... dawno, dawno temu... w czasach gdy na ziemi jeszcze pamięci FLASH nie było i gdy mikrokontrolery (MCU) miały okienko do kasowania promieniami UV, a 6502 było całkim szybkim CPU parzystość liczyłem w ten sposób:

parity  sta    v
    
        lda    #0
        sta    p
    
        lda    v
        beq    endp

loop    inc    p
        lda    v
        dec    v
        and    v
        sta    v
        bne    loop
    
endp    lda    p
        and    #1
        rts

a jak trzeba było mieć wynik ultra-szybko to się robiło look_up_table (LUT):

        ldy    #0

l0      tya
        jsr    parity
        sta    p_lut,y
    
        iny
        bne l0

i potem obliczenie parzystości danego bajtu było trywialne i szybkie, bo wystarczyło sięgnąć do tabelki.

Aby uzyskać wzór który wygenerował marok wystarczy albo skorzystać z p_lut, albo skorzystać z procedury parity:

        ldy    #0

l1      tya
        lda    p_lut,y

;       jsr    parity         ; --> gdy nie chcemy korzystać z look-up-table

        lsr    @
        ror    @
        sta    ($58),y
    
        iny    
        bne    l1

        lda    #$21
        sta    $22f

Jeżeli nie używamy LUT, to czas wykonania procedury "parity" jest oczywiście zależny od liczby "ustawionych" bitów w bajcie.

Oczywiście pomysł algorytmu nie był mój, podpatrzyłem go w jakimś artykule o programowaniu w C i przeniosłem sobie ten kod na assembler 6502. O ile dobrze pamiętam to powyższy algorytm bazował na sposobie liczenia bitów zaproponowany przez Brian-a Kernigan-a, a tenże algorytm (zliczania bitów) był opublikowany w książce "C Programming Language 2nd Ed." (by Brian W. Kernighan and Dennis M. Ritchie). Książka pochodziła chyba z okolic 1988 roku.

173

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

Yolk napisał/a:

Musiałeś coś jeszcze naprawiać w tym magnetofonie żeby całość ruszyła?

No trochę tego było:

  • wymiana głowicy; nie wiem skąd była ta zamontowana w magnecie, ale po pierwsze miała zamienione przewody po drugie nie była możliwa prawidłowa regulacja skosu, gdy chciało się prawidłowo ustawić głowicę ta gniotła taśmę.

  • wymiana rolki dociskowej; ta była "jajowata" więc nie było mowy o równomiernym prowadzeniu taśmy.

  • wymiana paska napędowego; ten był na granicy swoich możliwości, końcówka kasety i pasek potrafił się już ślizgać na rolce napędowej od silnika

  • wymiana silnika; ten zaczął mi rzęzić i piszczeć po paru testach, po rozebraniu silnika (destrukcyjna operacja) okazało się że nie dość że łożysko ślizgowe było wytarte i suche to jeszcze szczotki (tzn. miedziane blaszki) które miały kontakt z komutatorem, były praktycznie przetarte do cna.

  • dołożenia paska od licznika (tego brakowało w magnetofonie po jego otwarciu)

po tych operacjach magnet zaczął działać całkiem sprawnie :D

174

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

Yolk ... a jednak Blizzard... Blizzard uA741 ;-)

Hej!

Dawno nie pisałem w tym wątku, ale w końcu coś się ruszyło i walczą dalej... co prawda nie będzie to dziś wpis z cyku "z kolekcji uircr0Bee", a tym razem będzie dotyczył tego co znalazłem w magnetofonie Yolk-a. Jakiś czas temu Yolk poprosił o identyfikację turbo w magnetofonie który posiadał, jego pytanie padło w tym wątku: Prośba o identyfikację Turbo w magnetofonie", a ja podąrząjac drogą rutynową oczywiście wypaliłem (sądząc po ilości i rozmieszczeniu elementów) że jest to kolejny klon czeskiego turbo 2000, zastanawiała mnie co prawda pr-ka na płytce, ale reszta się zgadzała i mogło by to być kolejne wcielenie czeskiego turbo 2000 i sprawa pewnie nie została by dokładniej zbadana, gdyby nie to że Yolk nie mógł doprowadzić tego magnetu do działania... zaproponował że wyśle go do mnie i że będę mógł się temu przyjrzeć... i chwała mu za to iż to uczynił bowiem okazało się że to turbo w jego magnetofonie nie jest żadnym klonem czeskiego Turbo 2000... a dość specyficzną wersją Turbo Blizzard, piszę specyficzną ponieważ nie widziałem wcześniej takiej wersji... może na początek wkleję zdjęcia PCB:

http://seban.pigwa.net/Yolk/blizzard_uA741/photos/blz741_pcb_top.jpg
^^^ górna warstwa PCB, oczywiście napisy ze scalaków starte, jednak można się od razu domyślić że 8-nóżkowy scalak to zapewne uA741, a 14-nóżkowy scalak to komplet czterech dwu-wejściowych bramek NAND z których zbudowano multiplekser pozwalający przełączać tryb pracy interface z normal na turbo.

http://seban.pigwa.net/Yolk/blizzard_uA741/photos/blz741_pcb_bot.jpg
^^^ tutaj widzimy spód płytki drukowanej, na podstawie własnie tego układu ścieżek można było przystąpić do odtworzenia schematu tego co znajduje się na płytce.

Początkowo, jak pisałem już wcześniej sądziłem ze jest to kolejny klon czeskiego turbo 2000, jednak tym razem podczas odtwarzania schematu okazało się że niewiele z czeskim turbo 2000 ma ten układ wspólnego, ale aby nie przedłużać wkleję po prostu schemat tego co udało się przerysować ze wzoru ścieżek na płytce:

http://seban.pigwa.net/Yolk/blizzard_uA741/sch/blizzard_ua741.png
^^^ otwórz obraz w nowej karcie aby uzyskać większą rozdzielczość, lub pobierz wersję wektorową, o tutaj: Blizzard uA741 version (plik w formacie PDF).

Przyznam że początkowo się zdziwiłem gdy zobaczyłem co narysowałem i nie dawało mi to spokoju, bo jak się okazało jest to dość "uproszczona" wersja układu który miałby realizować funkcjonalność interfejsu dla Blizzard Turbo, i zastanawiałem się czy aby na pewno ma prawo ona poprawnie działać, bowiem brakowało w niej stopnia wejściowego który zapewniłby dość duże wzmocnienie sygnału, więc zacząłem również analizować dokładniej płytkę magnetofonu. Bardzo szybko okazało się że płytka jest zmodyfikowana w taki sposób, aby dostosować już istniejący na płycie magnetofonu wstępny wzmacniacz i ogranicznik sygnału do wymogów jakie stawia torowi odczytu Blizzard Turbo, zmodyfikowano więc obwód ogranicznika, (zmodyfikowano pętlę sprzężenia zwrotnego), zwiększono wzmocnienie przedwzmacniacza, usunięto większość kondensatorów odcinających wyższe częstotliwości, zwiększono jeden z kondensatorów separujących sekcje przedwzmacniacza z ogranicznikiem. Listę zmian i modyfikacji umieściłem na schemacie powyżej. Bazowałem na schemacie magnetofonu XC12 narysowanym przez Jer-a (Jerzego Sobolę). Aktualna wersja schematu znajduje się na jego stronie www (schemat XC12).

Jak zatem widać czasami zdarzają się perełki w różnych magnetofonach, ta wersja w/g nadruku na PCB powstała w '91 roku i jest sygnowana przez Megasoft (ktoś kojarzy może tę nazwę? skąd pochodzili, etc?). Także dzięki uprzejmości Yolka, udało się zarchiwizować kolejną mutację/wersję Blizzard Turbo.

Testowałem ten interface za pomocą plików wygenerowanych przez Turgen-a od Baktra, po uruchomieniu magnetofonu i przywróceniu go do działania, udawało się bez najmniejszego problemu wczytać pliki zapisane w formacie Blizzard. Jedyne co zauważyłem to że ten interface nie lubi kaset nagranych z poziomem 0dB, idealne warunki dla niego to kasety zapisane z poziomem -3dB lub mniej, zresztą z podobnym poziomem nagrywa również ten magnetofon.

Zatem kończę już ten wpis nie przedłużając zbytnio i nie zanudzając was kompletnie :)

ps1) @piguła: dzięki za kolejne dumpy!