Wysłałem e-mail (via forum), mam nadzieję że dotrze :D

Byłbym zainteresowany!

178

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

Dobra... chwilę to trwało, bo trwały eksperymenty różne, ale już śpieszę z opisem tychże eksperymentów i doświadczeń...

Po pierwsze próba zdjęcia starej bieżni bez jej uszkodzenia nie powiodła się (co niestety przewidywałem ;P )
http://seban.pigwa.net/aa/XC12/XC12_idler_a.jpg

^^^ ta "bieżnia" jest totalnie skamieniała, mogę to dosłownie pokruszyć, popatrzyłem w innych XC12 które mam i tam ta guma jest mięka i "czepliwa", tutaj zero przyczepności.

po zdjęciu tej bieżni z idler-a wyglądało to tak:
http://seban.pigwa.net/aa/XC12/XC12_idler_b.jpg

@qbahusak: wymiary tejże "bieżni" to:

- średnica zewnętrzna 14mm
- średnica wewnętrzna 10mm
- przekrój: 2mm x 2mm

Poprosiłem RZóG-a aby mi wydrukował taką bieżnię na drukarce 3D, wyszło tak: (po lewej skamieniały oryginał, po prawej wydruk)

http://seban.pigwa.net/aa/XC12/XC12_idler_c.jpg

RZoG użył elastycznego filamentu  "Fiberflex 40D"

Początkowo wydawało się że będzie dobrze, jednak pod koniec kasety "60 min" zaczynają się problemy:

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

Co dalej? Po pierwsze spróbuję znaleźć jakieś oringi który by pasowały a jeżeli nie znajdę to RZóG ma spróbować wydrukować z innego materiału który ma większą przyczepność, bo "Fiberflex 40D" okazał się zbyt śliski.

179

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

@perinoid: Nie wiem ile % acetonu jest w novogumie, w karcie charakterystyki nie napisali, ale jest jeszcze cała masa innych związków więc pewnie gdybym to moczył w całości to pewnie i tak by się skończyło tak jak napisałeś. Obawiam się że bieżnika z tego kółka jednak nie da się zdjąć (będę próbował) ale mam inne kółka w podobnym stanie, to będę eksperymentował. Podzielę się oczywiście przebiegiem eksperymentu, może się komuś przyda na później.

Jest jeszcze kilka innych preparatów, tzn. podobnych od innych producentów (np. "Nowa Guma" od Micro-Chip). W tym chyba nie ma acetonu, w zamian jest za to cała grupa innych węglowodorów.

Wszystko wskazuje zatem na to że najsensowniejszym będzie próba wymiany tejże bieżni na coś nowego, "regeneracja" może nie mieć najmniejszego sensu.

@pawex: dzięki za uściślenie terminologii :) Ze mnie mechanik żaden, trochę błądzę więc po omacku... często korzystając z pomocy ludzi mądrzejszych i bardziej doświadczonych niż ja, więc musicie mi wybaczyć nieznajomość właściwej terminologii, ale dzięki temu że piszecie to mogę się zawsze nauczyć czegoś nowego :)

180

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

perinoid napisał/a:

Ale teraz to obawiam się, że prędzej się rozpadnie niż rozciągnie.

No własnie doszedłem do takich samych wniosków :D Dzięki za przyjrzenie się tematowi, będę walczył... najwyżej kółko polegnie... wyciągnę wtedy jakieś inne z innego szrotu... ale nie omieszkam dać znać jak sprawa się zakończyła.

A że mam jeszcze inne egzemplarze z podobnym problemem to wypróbuję też metodę z novogum... przeczytałem co prawda "kartę charakterystyki" tegoż produktu i w składzie jest m.in. aceton, więc trzeba będzie uważać czy to nie będzie miało destruktywnego wpływu na zew. części kółka, no ale jak nie przeprowadzi się eksperymentu to się nie dowiemy.

Na pewno wrzucę info do tego wątku aby było wiadomo jaki sprawa będzie miała finał.

181

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

Samo kółko udało mi się wydobyć, co prawda tak jak piszesz wymagało to pewnego nakładu pracy, ale nie było tak źle, tylko nawet mając owo kółko w ręku nie bardzo wiem jak się dalej zabrać to wyjęcia tego ślizgającego się pierścienia ciernego... w przypadku 410 kółko składało się z dwóch części (góra, dół) ... tutaj nie wiem jak jest... i boję się działać siłowo aby nie połamać zew. powierzchni tego kółka, do tego ten ślizgający się pierścień cierny jest tak sztywny że chyba nie wyciągnę go bez uszkodzenia i to byłoby do jeszcze do zaakceptowania bo to tak jest bezużyteczny w obecnej postaci i formie (ślizga się) ... tylko obawiam się że próby walki z tym zakończą się połamaniem reszty koła ;/

182

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

Jest dokładnie tak jak piszesz, tzn. że środkowe (czarne) koło pośrednie jest cierne i jest sprzęgłem, tyle że jest już tak śliskie i brak mu jakiejkolwiek przyczepności, to oczywiście kończy się tym że prawy tależyk którego zadaniem jest zwinięcie taśmy po prostu przestaje się obracać i zamiast magnetofonu mamy przepiękny "wciągacz taśm" :D nawet bez włożonej kasety sytuacja jest jak widać tragiczne. Minimalne obciążenie i wszystko staje permanentnie, tzn. prawy tależyk i koło pośrednie.

Bardzo dziękuję za poradę z zastosowaniem "novogum", prawdę mówiąc nie wiedziałem że takie preparaty istnieją... sprawdzę oczywiście jego działanie, ale również postaram się pokombinować coś więcej, tzn. poświęcę jedno takie koło pośrednie i spróbuję rozłożyć je na części (o ile się da). Dam znać co z tego wyjdzie, a tymczasem zamówię ten Novogum i sprawdzę jak ten preparat zadziała na te powierzchnię "trącą" tego koła.

Jeszcze raz dzięki za wskazówki!

183

(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ę.

184

(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?

185

(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 :)

186

(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

187

(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.

188

(56 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!

189

(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ć.

190

(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

191

(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)

192

(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

193

(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).

194

(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 ;-)

195

(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 :)

196

(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

197

(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).

198

(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 :)

199

(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