Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorsmaku
   • CommentTime5 Oct 2015 23:10

    
   Przenoszę wątek spod "Fanowskie konwersje z innych platform" oraz ew. porozrzucane komentarze z innych wątków w temacie, żeby było w jednym miejscu.
   
   Chodzi o realizowanie zadań jednej maszyny z danego poziomu technologicznego przez inną maszynę z tego samego poziomu technologicznego - w kwestii rozwiązań ogólnych zbiorczych zrealizowanych działających - jako emulator pomiędzy dowolnymi dającymi się emulować wzajemnie maszynami.
   
   Na przykładzie konkretnym pomiędzy Commodore 64 a Atari 65XE.
   
   Ostatni komentarz w temacie z wątku "Fanowskie konwersje z innych platform":
   
   ====
   22: smaku
   27 minut temu
   
   Gdyby ktoś chciał samodzielnie przenieść sobie gry z Commodore 64 na początek na Atari 65XE, to tu na Wikipedii jest co nie co o serii procesorów z układami w architekturze MOS.
   
   ->link<-
   
   Commodore: 6510
   Atari: 6502
   
   Zestawy instrukcji są w tych podręcznikach w PDF i schematy.
   
   Kompletne opisy rozkazów procesora, żeby zrobić sobie ten filtr, o którym opowiadałem, pewnie są w podręcznikach do Assemblera Commodore 64.
   
   Wystarczy przepisać i porobić relacje jako funkcje, przykładowo: i w Atari i w Commodore 64 jest rozkaz ładowania akumulatora: LDA. Zrobić tak, żeby ten rozkaz poruszał układy Atari w pełni wskaźników, rejestrów i czego potrzeba, co jest poruszane w Commodore. I LDA zakończone jako relacja gotowa. I dokończyć po pozostałych rozkazach. Gotowe.
   
   Kto chce grę z Commodore 64 na Atari => ma gotowe. Wystarczy wgrać sobie i grać.
   
   Działa 100% idealnie. Zapewniam.
   
   Więcej pomóc nie mogę. Nie te tematy 'fanowskie'.
   
   A propos fanonwskich produkcji 'własnoręcznych', to w sumie aktualnie nie wiem, czy bym robił sam. Wolę gotowe. :)
   
   
   Dzięki.
   
   Więcej nie męczę tematem. Nie te Fora. Przepraszam.
   
   DS`.
   OCT.05.2015.
   
   [koniec]
   
   ====
   
   O to mi chodzi właśnie. Żeby grać sobie w gry z Commodore 64 ale nie na emulatorze Commodore 64, ale na Atari 65XE.
   
   W skrócie chodzi TYLKO o realizowanie programu Commodore 64 przez Commodore 64 - czyli na procesorze 6510 z pamięcią dedykowaną do tego procesora (jak piszą w Wikipedii, nie wiem, czy to ten procesor jeszcze, dopiero zaczynam, więc sprawdzę dokładnie z czasem, jak już będę robił) :) - ale wszystkie efekty pracy procesora z pamięcią muszą iść na filtr, który przeniesie efekty pracy Commodore 64 instream in real time na efekty działania układów Atari 65 XE. Czyli efekt będzie taki, że co by uruchomić na Commodore 64 => ma robić to Atari 65XE na swoich własnych układach, a układy Commodore są mu nie potrzebne. Jedynie procesor Commodore 64 ma robić swoje i brać z powrotem to, co dostaje i robić dalej jak należy. Reszta należy do Atari 65XE - żeby wiedzieć co zrobić z praca Commodore 64.
   
   Efekt musi być jak na Commodore 64, ale lepszy - zakładam, bo Atari 65XE jest lepszy w robocie praktycznej dla Użytkownika, jak widać i słychać po efektach. Ciekawe, czy wszystkie gry i programy i wszystko co na Commodore 64 zrobi Atari 65XE 'w locie' i gotowe. :)
   
   READY
   []
2. • 2: CommentAuthorsmaku
   • CommentTime6 Oct 2015 00:10

    
   Żeby zacząć sensownie pracę, zacząłbym od dwóch tabelek tego typu, co poniżej (wstępnie i ogólnie):
   
   1. Tabelka (trzy kolumny): Lista rozkazów 6510|Wartości lub sygnały zwracane|Wartości lub sygnały odbierane
   
   2. Tabelka (trzy kolumny): Lista rozkazów 6502|Wartości lub sygnały zwracane|Wartości lub sygnały odbierane
   
   Te dwie kolumny w każdej z tabelek dotyczące sygnałów i wartości zwracanych / odbieranych trzeba połączyć tym filtrem, którego szukam, czyli rozwiązaniem i zakończeniem zdania w formie ostatecznej gotowej i można przenieść filtr programowy na sprzętowy intereface (mała płytka drukowana) i gotowe.
   
   Chodzi o sporządzenie relacji między dwoma tabelkami powyższymi w odwzorowaniu jedno na drugie poprzez zestaw skończony - jednoznacznie określonych funkcji konkretnych i skończonych. Czyli co robi rozkaz w Commodore praktycznie => ma robić to Atari praktycznie u siebie na swoich układach zgodnie z wartościami przekazanymi przez Commodore wynikającymi z pracy swojego procesora z pamięcią. Atari ma to rozpoznawać, robić i zwracać zgodnie z funkcjami określonymi 'z powrotem' do Commodore tak, żeby Commodore wiedział, że wszystko zrobione zgodnie z tym, co podane i do przodu.
   
   I koniec zadania.
   
   W drugą stronę trzeba sporządzić analogiczny filtr, żeby Commodore robiło na swoich kładach to, co daje mu 6502 od siebie. Analogicznie. I filtr obustronny byłby gotowy.
   
   Potem można analogicznie zrobić filtry dla dowolnych maszyn, które łatwo dają się przenieść odwzorowawczo zgodnie z przykładem Commodore 64 i Atari 65XE.
   
   ZX Spectrum powinno być chyba łatwo 'łyknięte' przez Commodore i przez Atari. Odwrotnie trzeba by się pomęczyć z funkcjami, ale jakąś część emulacji Atari 65XE lub Commodore 64 na ZX Spectrum da się zrealizować - do barier technologicznych układów posiadanych przez ZX Spectrum, oczywiste. Bariery to bariery. Więcej się nie da, najwyżej można zrobić filtr 'deluxe' (dodatek na oryginał wprost) dla każdych relacji między komputerami emulowanymi, żeby PC to emulował. Ale to inne tematy i na potem. Typu 'deluxe'.
   
   I analogicznie drugi przykład 'wzajemny':
   
   Atari 520 ST i Amiga 500.
   
   100% ta sama analogia - zrobić i zobaczyć.
3. • 3:
      
     CommentAuthorjhusak
   • CommentTime6 Oct 2015 00:10 zmieniony

    
   Niestety, żeby zrobić taki "filtr" - trzeba określić przestrzeń wspólną, co na C64 i AtariXE prowadzi do mocnego okrojenia hardware do trybu znakowego i grafiki bitmapowej, która jest niemal tożsama.
   
   Co do muzyki, pokey potrafi odegrać w uproszczony sposób sidowe kawałki (ale znowu nie wszystkie), a sid coś tam by z pokeya też mógł zagrać.
   
   Na pewno można by wbudować AtariBasic do C64 i mieć tam kilka kompatybilnych trybów graficznych, coś tam by działało.
   
   Ale w praktyce - gier, co by chodziły i tu i tu, byłoby pewnie 1-2% i to tych kiepściejszych 0 bez sprajtów itp.
   
   Ogólnie mówiąc kupa roboty a efekt mierny.
   Wszystko rozbija się o specjalne hakerskie tryby graficzne, generator znaków 256 czcionek i sprajty.
   
   
   --------------------
   Ale:
   Atari potrafi emulować ZX Spectrum, są 2 emulatory.
   Atari potrafi udawać wirtualnie AppleII; ponadto sporo gier zostało przeniesionych "just like that", np. Karateka z racji tego, że Atari jest tak uniwersalny.
   
   Amiga potrafi hardware'owo udawać Atari ST i Macintosha z 68000/68020 i pewnie wyżej, działa to podobnie, jak piszesz, ale Amiga ma tego hardware trochę i w miarę znormalizowanego, więc część wspólna w tę stronę dotyka niemal całości komputera udawanego.
   
   Sam na 1200 i na 500 odpalałem powyższe dwa środowiska wirtualne ST i Mac i działało toto normalnie, jak udawany komp, z podobną prędkością.
   
   O odpalaniu tego w drugą stronę można zapomnieć (COPPER i duchy)
4. • 4: CommentAuthorbob_er
   • CommentTime6 Oct 2015 07:10

    
   @smaku:
   Nie chcę gasić Twojego entuzjazmu, ale normalna kolejność powinna wyglądać tak:
   1. Wpadasz na pomysł.
   2. Czytasz o możliwości jego realizacji.
   3. Jeśli uznajesz, że problem jest możliwy do realizacji - to to robisz.
   4. Jeśli jakiś detal Cię blokuje - się ewentualnie publicznie pytasz, jak to obejść.
   
   Ja sam na XE znam się conieco (choć kozakiem się nie czuję), to nie napisałbym, że ZX będzie łatwo 'łyknięty' przez XE. Kuba ma rację pisząc, że sporo gier przeportowano na XE, ale wiele apsektów sprzętu (dźwięk, mapa kolorów) odpada. Z C64 tym bardziej.
5. • 5:
      
     CommentAuthoranonymus
   • CommentTime6 Oct 2015 08:10

    
   Też obawiam się, że przenoszenie kodu z jednej maszyny na drugą to nie google translate kodu.
6. • 6:
      
     CommentAuthorpirx
   • CommentTime6 Oct 2015 11:10

    
   w dzisiejszych czasach to pewnie najtaniej by było jakiegoś arma na cartridge usadzić, na nim emulatory czegokolwiek i renderer grafy w stylu karta Nosty'ego. Grafa wtedy mogłaby być zbliżona. Dźwięk trzeba by wypuścić bokiem (szkoda, że w XL/XE nie ma audio in na złączu karta). Zostaje tylko pytanie "po co".
7. • 7: CommentAuthorsmaku
   • CommentTime6 Oct 2015 17:10

    
   @jhusak: ta 'przestrzeń wspólna' konwertowana w jedną lub w drugą stronę jest tylko wirtualna w postaci gotowego filtru, który jest zakończeniem zadania w wersji gotowej i skończonej. I właśnie chodzi o zrobienie pełnego skończonego zestawienia funkcji na relacji pomiędzy jednym a drugim komputerem. Nic więcej. I pozostałe aspekty 'problemowe' znikają automatycznie i nie istnieją.
   
   Pod warunkiem, że uda się zrealizować w tym 'filtrze', którego szukam i chciałbym zrobić i zobaczyć jak działa - wszystkie funkcje idealnie jak należy - przenoszące pracę procesora+pamięć (jedynie to: pamięć +procesor pracujący na pamięci swojej dedykowanej - jako wspólny zestaw pracujący niezależnie samodzielnie) jednej maszyny na drugą.
   
   Wtedy dalsze rozważania, co się da, a czego nie, a co nie bardzo - są zbędne 100%, bo po zrealizowaniu 100% tego zestawu funkcji wszystko est od razu gotowe i działa 100% idealnie. Chodzi tylko o pełen zestaw tych funkcji. Nic więcej. I koniec roboty - 100% idealna emulacja jednej maszyny przez drugą na swoich układach.
   
   Jeśli ktoś dysponuje gotowym zestawem zaprogramowanych rozkazów procesora i układów w emulatorze Commodore 64 na PC i analogicznie Atari 65XE, to wystarczy zrobić przejście tym 'filtrem', o którym opowiadam pomiędzy układem pamięć+procesor pierwszej maszyny a realizacją programu na układach (z drugiej maszyny) a emuluje efekt i tak PC.
   
   No koniec. Czy wystarczająco opisałem, o co mi chodzi?
   
   Sprawdzając, że to działa - miałbym analogiczny idealny emulator we wszystkie strony hurtem dla dowolnych maszyn nie tylko na tym samym poziomie technologicznym.
   
   Oczywiste. Amiga i Atari ST mogłyby emulować Atari 65XE, albo Commodore i każdy komputer 8-bitowy na swoich układach 'w locie' i dowolne z innych poziomów, np. PC-ty i dowolne, etc. - w każdą dowolna stronę każdy komputer mógłby emulować dowolny inny zgodnie z zestawem przygotowanych funkcji, czyli tego 'filtru', którego szukam - z zachowaniem oczywistych barier technologicznych, czyli emulacja jedynie na ile jest możliwa ze względów możliwości sprzętowych układów, które miałyby realizować program wykonywany drugiej maszyny.
   
   Gotowe zestawy funkcji w parach typu Atari 65XE<=Commodore 64 lub Commodore 64<=Atari 65XE, czy ZX Spectrum<=Atari 65XE działałyby jako gotowe interface do realizowania programu procesora jakiejś maszyny NA SWOICH układach własnych. Obojętne jaki procesor, ważne, że jeśli podaje program realizowany i wartości, to ma to być realizowane przez układy dowolnej maszyny, a nie przez układy dedykowane dla tego procesora. Tylko o to mi chodzi i powtarzam opisując w każdym komentarzu to samo.
   
   Gdyby ktoś dysponował kodem źródłowym w pełni działającego emulatora Atari 65XE i Commodore 64, to pewnie zrobienie tego interface ('filtru') pomiędzy procesorami, a układami z podmianą układów byłoby kwestią 15 minut, jak opowiadam od początku wątku w innych w miejscach na atarionline.
   
   Tyle trwa pewnie przygotowanie zestawu funkcji przenoszących realizację rozkazów jednej maszyny na rozkazy drugiej maszyny:
   
   do(IR)Atari => filtre => do (IR) Cmmodore - albo odwrotnie. Z zachowaniem wartości i sygnałów wszystkich.
   
   Ta książka powinna wystarczyć:
   
   ->link<-
   
   i tak samo do Commodore, jeśli nie ma kodów źródłowych jakichś dostępnych dla emulatorów obu komputerów.
   
   I ew. szczegółowe opisy działania układów. Żeby dobrze napisać te funkcji w odwzorowaniu jak najbliższym idealnemu.
   
   I to tyle. Nic więcej nie trzeba zrobić.
   
   Czy dobrze wyjaśniłem, o co mi chodzi?
8. • 8: CommentAuthorsmaku
   • CommentTime6 Oct 2015 17:10

    
   @anonymus: w sumie sprowadza się to w pierwszym etapie działania filtru do czegoś podobnego, ale rzeczywiście niekoniecznie tak samo. Zestawy funkcji w sumie analogicznie na zdaniach prostych i najprostszych, czyli aż na rozkazach, których jest tylko 52 czy 55 i nie więcej.
   
   Ale w tym, co opowiadam, 'filtr' jest zrobiony RAZ i koniec, potem zupełnie nie o to chodzi jak w Google Translator. To nie to. To nie jest konwertowanie programów na programy innej maszyny. To jest realizowanie swojego programu przez maszynę, czyli u siebie na swoim procesorze z pamięcią, ale układy wszystkie 100% okołoprocesorowe są innej maszyny. I to jest ta różnica i zasada działania, o która mi chodzi.
   
   Z Google Translator to ma tyle wspólnego, co dwie tabelki i funkcje na relacji między elementami tabelki w najprostszych zestawieniach gramatyki i syntaktyki, etc. - dotyczące języka i zasad językowych. Ale nic więcej w realizacji.
   
   Tak to widzę, ale musiałbym myśleć, żeby opowiedzieć konkretnie w porównaniu do Google. Na pewno da się zrobić analogię pewnych elementów. :)
9. • 9:
      
     CommentAuthorbocianu
   • CommentTime6 Oct 2015 18:10

    
   @smaku: no dobra, to na serio, weź mi powiedz prostą rzecz - skoro to takie banalne w realizacji, to dlaczego nikt tego nie zrobił przez ostatnie 30 lat? Myślisz, że nikt nie chciał zagrać w gry z Atari na Commodore lub odwrotnie?
10. • 10:
       
      CommentAuthorjhusak
    • CommentTime6 Oct 2015 18:10 zmieniony

     
    @Smaku, jak przedsawia się Twój pomysł do freeRTOS, cpm oraz linuksa?
    
    Bo przyznam szczerze, nie wiem, czy Cię w pełni rozumiem.
    
    Powyższe 3 systemy operacyjne działają na różnych sprzętach; poza tym cpm jest binarnie zgodny AFAIK - tę samą binarkę można uruchamiać na różnych architekturowo komputerach chodzących pod tym systemem. Linuks podobnie, o ile architektura procesora jest ta sama. A freeRTOS, cóż, piszą, że są 3 wspólne pliki, tego systemu, a reszta jest dopasowana do konkretnej architektury - jednak wydaje mi się, że raz napisany kod będzie działać na każdym z supportowanych mikrokontrolerów, oczywiście z dokładnością do prędkości/pamięci etc.
11. • 11: CommentAuthortbxx
    • CommentTime6 Oct 2015 18:10

     
    @smaku
    załóżmy że w ogóle nie interesuje nas architektura komputerów, ot mamy kompletny zestaw "sygnałów" wejściowych do układów komputerów do tego powiązany z nimi komplet sygnałów "wyjściowych". Teraz z tego co zrozumiałem robimy "magic box" który wymyśla jaki sygnał "X1" podać do atari aby na wyjściu uzyskać sygnał "Y1" zgodny z sygnałem "Y0" wychodzącym np. z ZX Spectrum po podaniu sygnału "X0".
    
    Nawet gdyby udało się zrobić "magic box" to jak rozwiążesz sprawę w różnicy częstotliwości pracy układów?
12. • 12: CommentAuthorsmaku
    • CommentTime7 Oct 2015 15:10

     
    @bocianu: to typowe pytanie ludzi generalnie, którzy o czymś się dowiadują oczywistym i banalnym i nie mogą tego przyjąć do świadomości walcząc automatycznie odrzucając jako 'nierzeczywiste, ponieważ nawet, każdy wie, oczywiste [wstaw wypowiedź bocianu]'.
    
    Oczywistości. Można najwyżej z takimi pomysłami rozmawiać jak z czymś 'psychicznym, dziecięcym, to tylko dziecko z pomysłami, nie trzeba się zajmować, trzeba szanować, niech sobie myśli, to jego sprawa, ma chłopak / dziewczyna zapał i pomysły, nie wolno mu/jej przeszkadzać, żeby traumy nie miał/a, to bardzo wartościowe na pewno, super, i to jest możliwe może nawet w jakiś sensie teoretycznym może, nie wiadomo w sumie, hmm... no ciekawe, ciekawe, ciekawe, czy to realne, niesamowite...' - i można sobie iść dalej komentując innym najwyżej jak ktoś wspomni temat: 'tak, to zapaleniec, maniak, trochę poza rzeczywistością, ma kosmiczne pomysły, ale chyba wie co robi, nie trzeba przeszkadzać, na pewno wie lepiej, lepiej zostawić, na pewno da sobie radę, bardzo pomysłowe pomysły, jak kosmiczne i niewiarygodne, ludzie czasem mu/jej tłumaczą, ale wie, lepiej, być może wie lepiej, ale trudno jest generalnie pewnie przebić się do ludzi z najbanalniejszymi rzeczami, wiesz, jak Emk itp. - Emk? - E=mc^2, Einstein, itp. Prosta rzecz, jak koło i kwadrat. No ale weź wynajdź koło, kiedy nikt nie wymyślił wcześniej, prawda?... - No tak. - Pewnie trzeba być geniuszem, a i tak nikt nie zrozumie... - No tak...
    
    I kończy się temat. Wolne... :)
    
    @jhusak: ponownie to samo opisuję, poniżej, wprost najprościej, bo rzeczywiście wydaje mi si, że znowu poza tematem, który opisuję:
    
    (procesor commodore'a + pamięć commodore'a) robią swoje 'u siebie' i zwracają wyniki swojej pracy DO i OD układów i pracują w trybie ciągłym zgodnie z programem w pamięci (listą rozkazów procesora). Zwracając DO i biorąc do dalszej pracy własnej OD => otrzymują i dostają dokładnie to, na co oczekują i dają - czyli 100% pełna prawidłowa praca układu procesor+pamięć. Jedynie w miejscy zwracania sygnałów i wartości DO => idzie to na filtr, który przekazuje na układy atari do zrobienia, co trzeba zgodnie z funkcjami (pełen zestaw) po czym funkcje filtrowe zwrotne (drugi pełen zestaw) zwraca po wykonaniu rozkazów commodore przez układy atari prawidłowe wyniki z powrotem DO układu procesor+pamięć commodore'a i commodore nie zauważa różnicy. To, co robi procesor commodore'a w swojej pamięci zgodnie z podanym programem z pamięci rozkaz za rozkazem jest realizowane prawidłowo na układach atari i atari zwraca poprzez ten filtr z funkcjami zwrotnymi prawidłowe wartości DO procesora commodore i pamięci commodore do dalszej pracy, że commodore nie musi wiedzieć, że wykonanie programu jest realizowane przez atari. Co procesor commodore to interesuje? Robi, podaje dalej DO i dostaje OD prawidłowe zgodnie jak potrzeba, czyli realizuje cały swój program idealnie. A że atari robi na swoich układach - to bez znaczenia dla commodore, bo commodore dostaje wartości takie, jak gdyby prawdziwe układy commodore robiły swoją pracę prawidłowo. Czyli 100% odwzorowanie commodore na układach atari lub dowolnych - w zależności od filtra dedykowanego w tę<=> wewtę.
    
    Wtedy Twoje pytania są poza tematem znowu. Jak wyżej. Czy ja nie zrozumiałem czegoś? To zastanowię się.
    
    Chodzi o przygotowanie tego zestawu funkcji, które z wartości pracy procesora+pamięć jednego komputera robią wartości odczytywalne do zrealizowania przez układy drugiego komputera. I zestaw funkcji równoległych do pełnej pracy prawidłowej filtra: wartości zwracane przez układy drugiego komputera realizujące wartości pierwszego komputera muszą w trybie ciągłym podczas pracy procesora+pamięć pierwszego komputera być zwracane do pierwszego komputera jako wartości odczytywalne do zachowania ciągłości prawidłowej pracy, czyli wykonania programu.
    
    No i to tyle. To samo co od początku opisuję. Mogę narysować i dać przykład na kilku rozkazach i układach muzycznym i graficznym i wejść/wyjść, żeby mieć początek i byłoby widać. (?)
    
    
    @tbxx: prawie tak, ale nie aż na takim niskim poziomie realizowania sygnałów układów wprost pomiędzy układami.
    
    Te funkcje w 'magic boxie' mają realizować sygnały zbiorczo zwracane z danego rozkazu czy z pełnego zestawu 'zmian wartości i sygnałów' po wykonaniu jednego rozkazu 65010 (dla commodore) na układzie innej maszyny w taki sposób, żeby uzyskać efekt odwzorowujący pracę PRAKTYCZNĄ układów pierwszego komputera ale wykonaną na układach drugiego komputera.
    
    Czyli zestaw może nawet dość skomplikowanych funkcji w zakresie prostoty typu jedna linia, czyli do przeniesienia na sprzęt w 10 minut przez elektronika na bramkach podstawowych, kilka chipów standardowych po grosiku albo z odrzutów i kilka lutów (ale sprzęt to potem, najpierw funkcje gotowe przetestowane, oczywiste) - jednak wystarczających do odwzorowania pracy układów jednej maszyny na układach drugiej.
    
    Pod wieczór spróbuję dać przykład na jakimś rozkazie procesora commodora, żeby było konkretnie widać.
    
    Rozkazy wewnętrzne, takie jak LDA są nawet nie dotykane przez filtr - pusty plastik - żadnych lutów ani połączeń (głucha ścieżka), bo realizuje to procesor u siebie i nigdzie nic nie zwraca oprócz sobie - przykładowo.
    
    Ale rejestry, które wrzucają wartości na układy zewnętrzne trzeba zaprogramować w konkretnych skończonych idealnych funkcjach właśnie, czyli przykładowo:
    
    rozkaz podaj na sid wartości => filtr => podaj na pokey wartości => zwróć wartości do 6502 => filtr => zwróć wartości do 6510 - i dalej... next IR... - ale to już wie i robi commodore, oczywiste.
    
    Atari TYLKO służy swoimi układami i perfekcyjnie zwraca efekty swojej pracy zrozumiałe idealnie i prawidłowe do commodore. I tak by działał każdy program realizowany na commodore, czyli pełna 100% emulacja pracy commodore na układach atari i powinno być idealnie i w standardzie, jeśli dobrze zrobić te funkcje odwzorowujące. I to tyle. Koniec zagadnienia. I zrobić i zobaczyć jak ślicznie to musi działać, zakładając.
    
    A propos Google Translator, to byłoby to używanie języka swojego i rozumienie języka swojego ale polecenia w tym języku i realizowanie zadań w tym języku, oraz przyjmowanie raportów ze zrealizowanych zadań zgodnie z poleceniami w języku podstawowym (czyli tu commodore) należałoby do robotników z atari (którzy używają zupełnie 100% innego i obojętnie jakiego języka, ale swojego i czystego jedynie swojego), którzy robią zgodnie z poleceniami commodore na swoich materiałach i usługach i raportują w języku commdore co zrobiono i jak dzięki tłumaczowi (filtr poszukiwany z zestawem funkcji do zlecenia do wykonania), który tłumaczy commodorowi co atari twierdzi, że zrobił i jak.
    
    100% poprawne i pełne i zakończone porównanie w kwestii tego, o czym opowiadam - a propos wczorajszego pytania o Google Translator i porównanie.
13. • 13: CommentAuthorsmaku
    • CommentTime7 Oct 2015 15:10

     
    @jhusak: A propos muzyki i dźwięków, nie wiem w jakim zakresie kolega / Pan pracował dotychczas ze swoimi genialnymi muzyczkami, które znam od dziecka i nadal są świetne, czyli dobra robota i to bardzo, bo lubię (a to znaczy, że ktoś się zna lub postarał) - jeśli tylko jako muzyk lub spec od dźwięków do zakresu korzystania z Atari jako keyborda z gotowymi zestawami brzmień do wykorzystania, to byłaby rozmowa jak z każdym dowolnym muzykiem lub dźwiękowcem, nie w temacie za bardzo czyli.
    
    Bo chodziłoby o znajomość układów dźwiękowych bardziej od strony sprzętu, czyli kogoś jak elektronika prawie, kto majstruje przy brzmieniach i dźwiękach, jak autor Soft Syntha przykładowo być może, że mając układy gotowe dane, umiał zrobić sobie coś ciekawego z tym, co miał - ale nadal nie ten poziom, bo byłoby to wykorzystanie znowu brzmień w sensie praktycznym do używania z tego, co dane - wystarczy poznać programowe metody, czyli nadal nie ten poziom.
    
    Chodzi o znajomość układu dźwiękowego pod względem sygnałów otrzymywanych, realizowanych i zwracanych w pracy układu (pełna paleta możliwych sygnałów sprzętowych wywoływanych programowo lub dowolnie, czyli pełna 100% paleta sygnałów możliwych) - sygnałów i wartości w komplecie - które przepływają przez układy dowolne każde i wszystkie w całym zestawie Atari lub Commodore - podczas pracy z danym układem, czyli powiedzmy dla Atari jeśli jest wydany rozkaz dotyczący dźwięku na pokeya, to musi być wiadomo w jednej paczce pełnej skończonej zamkniętej sygnałów i wartości - jakie rzeczy dzieją się w całym Atari na skutek wydanego rozkazu dot. układu.
    
    I te wartości podawane przez procesor, przyjmowane przez układy do zrealizowania, a potem zwracane wartości po zrealizowaniu przez układy z powrotem gdzieś - do rejestrów nie tylko procesora pewnie i do pamięci bezpośrednio, etc. (komplet - gdzie i jak jest potrzebny) muszą być realizowane zgodnie i prawidłowo po przetworzeniu przez filtr na paczkę odpowiadającą dla procesora realizującego program własny, żeby zachować prawidłową ciągłość pracy programu, oczywiste.
    
    No i o to by chodziło.
    
    Żeby funkcjami pełnymi zamkniętymi skończonymi w potencjale sygnałów i wartości możliwych w pracy układów opisać pracę dwóch układów odpowiadających sobie w dwóch osobnych komputerach. I to byłby zestaw funkcji dla rozkazów dot. danego układu, czyli tu: pokey cały najlepiej, nie tylko część dotycząca dźwięku, a w commodore chyba ten 'sid'? Nie wiem, bo nie sprawdzałem. odpowiednik pokeya w każdym razie, żeby mieć tablicę funkcji realizowanych 100% wzajemnie.
    
    Nawet gdyby pokey lub inny układ miał odpowiedniki w kilku układach osobnych w innych komputerach, to trzeba zebrać sensownie w paczkę, żeby odwzorować sensownie i sprawnie pracę jednego na drugi. I w efekcie końcowym: wszystkie układy jednej maszyny na wszystkie układy drugiej maszyny, żeby jedna robiła swój program a układy drugiej realizowały ten program praktycznie. I to tyle w zagadnieniu. Ciągle o tym samym z różnych opisów i stron. :)
14. • 14: CommentAuthorsmaku
    • CommentTime7 Oct 2015 16:10

     
    @jhusak: Spojrzałem, żeby zobaczyć jak to wygląda, żeby wiedzieć o czym dalej rozmawiać w szczegółach konkretnych już bardziej na podstawie wcześniejszego ogólnego opisu.
    
    MOS Technology SID (dla Commodore 64):
    
    ->link<-
    
    
    Atari Inc. POKEY (dla Atari 65XE):
    
    ->link<-
    
    
    Chyba dobre schematy ogólne znalazłem wstępnie?
    
    No i teraz trzeba zrobić tak, żeby w opisie funkcji nawet słownie: jedno robiło drugie. Na przykład POKEY ma odwzorować 100% pracę pełnego 100% SID. na ile technologicznie jest w stanie to zrobić, tyle musi być.
    
    Tego, co POKEY nie umie zrobić w żaden możliwy sposób - oznaczyć, że się nie da i dlaczego - dorobi się w wersji deluxe filtra emulowane przez Emulator Atari 65XE - bo tu nie ma ograniczeń żadnych akurat. Ale najpierw powyższe.
    
    I będzie wiadomo co dalej. Sam mogę zaprogramować funkcje filtra między Commodore a Atari, jeśli ktoś zna te dwa układy SID i POKEY) i opowie co odpowiada w odwzorowaniu praktycznym w drugim. Wtedy ja to napiszę, żeby robiło samo w funkcjach.
    
    I na koniec oznaczenie procentowe dla statystyki i raportu, żeby wiedzieć: jaki procent SID zrealizował idealnie w odwzorowaniu tożsamościowym lub niepełnym (też % i wyjaśnienie) POKEY. Tabelka konkretna i gotowy filtr w funkcjach dźwiękowych. A te elementy nie dźwiękowe - analogicznie na układach odpowiadających, niczego to nie zmienia. Ta sama droga pracy.
15. • 15: CommentAuthorgorgh
    • CommentTime7 Oct 2015 16:10

     
    bob_er dobrze radzi, talk is cheap, liczą się efekty,szkoda czasu marnować na czczą gadaninę, lepiej coś zrobić a jak się nie da to zostawić to
16. • 16: CommentAuthorsmaku
    • CommentTime7 Oct 2015 17:10

     
    @gorgh: prawda, czyli 100% nie w wątku niniejszym. :)
    
    Kontynuując o POKEY, udało mi się znaleźć mapę pamięci i ogólny opis działania POKEY dla Atari 65XE:
    
    "D200-D2FF POKEY do D20F. Rejestry dźwięku, paddle, generator liczb losowych (D20A), bajt danych szeregowego wejścia-wyjścia (D20D), wektor przerwań IRQ (D20E)"
    
    ->link<-
    
    [Asembler 6502 - Jan Ruszczyc - SOETO, Warszawa 1987]
    
    I lista rozkazów po kolei we wszystkich rodzajach adresowania i używania:
    
    ->link<-
    
    Pozostałe układy i elementy 65020 i otoczenia - istotne - też opisane wystarczająco, przynajmniej wstępnie.
    
    No i teraz to samo dla Commodore 64, żeby wiedzieć linijka po linijce jak przenieść funkcjami jedno na drugie w odwzorowaniu najbliższym możliwym pełnym 100% w postaci tabelki:
    
    [commodore robi 'to1' => atari robi 'to2', żeby było 'to samo' dla użytkownika atari, czyli 'to1' - czyli gra na commodore, albo użytki, wszystko 100% co robił commodore dla siebie dla swoich układów => zrobił sobie atari na swoich układach zgodnie z tym, co robił commodore dla swoich układów].
    
    I znowu: koniec zdania. Tylko zrobić do końca i całość linijka po linijce. I gotowe. READY[]
    
    :)
    
    Czy gdzieś się mylę?
17. • 17: CommentAuthorblacktofu
    • CommentTime7 Oct 2015 17:10 zmieniony

     
    Tych samych argumentów, których tu użyłeś, można użyć do udowodnienia tego, że Twój samochód przekroczy prędkość światła, gdyby spadał z dostatecznie dużej wysokości.
    
    Więc tak, masz rację. Przenieś teraz Andropolis z C64 na stock Atari i zamknij tym usta niedowiarkom.
    
    Acha, link: ->link<-
18. • 18:
       
      CommentAuthorTheFender
    • CommentTime7 Oct 2015 18:10 zmieniony

     
    Chłopaki.... A jeśli on to zrobi? :)
19. • 19: CommentAuthor8bit
    • CommentTime7 Oct 2015 18:10

     
    Ale to już jest nazywa się PC + emulatory ;)
20. • 20: CommentAuthorsmaku
    • CommentTime7 Oct 2015 18:10 zmieniony

     
    Tymczasem sprawdziłem grafię ogólnie na Wikipedii: Commodore 64 ma najwyższy tryb 320x200 - genialny tryb, jak PC-towy, tylko marzyć o 16 lub 256 kolorach i mamy VGA. Super rozdzielczość.
    
    Mniejszy tryb to 160x200 pixeli - nie wiem czy (horizontal) x (vertical) czy odwrotnie, potem się sprawdzi. Obojętne chyba przy tych liczbach. Da się 'łyknąć' w obie strony nawet (atari<=>commodore).
    
    
    Więc Atari w swojej technologii układu graficznego ma barierę na rozdzielczości maksymalnej: 320x192 (zamiast 320x200) - taka mała różnica, a totalna różnica w każdym aspekcie epokowym nawet, łącznie z przejściem bezpośrednim na super kolorowy tryb VGA 256 - strasznie tego trybu brakuje w Atari 65XE - jak drabina bez ostatniego szczebelka, albo drabina z ostatnim szczebelkiem lekko za nisko, odrobinkę.
    
    Wystarczyło te 8 linii - nic więcej, kurde... nie da się tego dolutować na układach Antic gdzieś? Tych 8 linii? Byłby perfekcyjny Atari jeśli chodzi o rozdzielczości graficzne.
    
    To tę barierę da się obejść na dodatku do filtru deluxe-graph-chipset-fulfill jakiś. :) Żeby było porównywalne 1 do 1 (pełne odwzorowanie pracy układów graficznych commodore na atari) i luz w tym temacie. Jedna dodatkowa liczba na funkcjach graficznych w tym filtrze (+c jakieś). Gotowe.
    
    OK.
    
    To grafika działa. I ten dźwiękowy teraz. Ktoś znający się na muzyce może potwierdzić, że POKEY umie odegrać 100% SID-a, jeśli odpowiednio poda mu się wartości?
    
    Są jakieś emulatory SID-a na POKEY-u? Żeby to usłyszeć, wtedy napiszę zestaw funkcji i na jutro gotowe.
    
    (?)
    
    Pozostałe układy to formalka, przepisuje się wprost i gotowe.
    
    Czyli gotowe. Amen.
    
    Czy coś opuściłem?
    
    ... Jeśli nie, to w najbliższy weekend miałbym gotowy mój patentowany 'deluxe' filtr robiący programy Commodore 64 na układach Atari 65XE. :)
21. • 21: CommentAuthorblacktofu
    • CommentTime7 Oct 2015 19:10

     
    Bomba. Pochwal się, jak Ci poszło z NUFLI ( ->link<- ).
22. • 22: CommentAuthorsmaku
    • CommentTime7 Oct 2015 19:10

     
    @blacktofu: Jeśli te genialne screeny są z Commodore 64, to idealnie 100% odwzorowanie 1:1. Pełne 100%. Genialne te screeny. Będzie co pooglądć na Atari 65XE. :)
    
    Ale prawdopodobnie filtr będzie musiał używać tych funkcji deluxe-fulfil-chipset, jeśli jest to 320x200. Kolory powinny być wprost przerzucone. Potem sprawdzę przy pisaniu konkretnych funkcji, jak się przenoszą kolory na tryby. Najwyżej dodam delux-color-in-res-fulfill-chipset i będzie ideal.
    
    Musi być 1:1 odwzorowanie, czyli tożsame. Oczywiste. To jest cel zadania. Bo ja chcę pograć na Atari w gry z Commodore. Wszystkie. Sprawdzić chociaż ter najlepsze i najciekawsze. Może przygodówki są jakieś fajne?
    
    
    Ale ładne te screeny. Mobilizuje mnie to w tym momencie ostatecznie. Muszę mieć wszystkie gry i dema z Commodore 64 na moim Atari 65XE. Wszystkie. Amen.
    
    
    Podsumowując opis zadania, byłoby to w efekcie tylko takim przejściem jak w aktualnie działających emulatorach Atari 65XE typu AtariWin 800, Altirra (niedawno poznałem dopiero - kilka dni temu - też ładnie emuluje, czyi pewnie dobrze i jak należy).
    
    Czyli analogicznie do działających emulatorów Atari 65XE:
    
    (procesor+pamięć)+układy Atari 65XE => filtr funkcji => wykonanie na układach PC
    
    musi być z poniższym przejściem jedynie i koniec zadania: gotowe 100% można grać:
    
    (procesor+pamięć)+układy Commodore 64 => filtr funkcji 1 => wykonanie na układach Atari 65XE => filtr funkcji 2 => wykonanie na układach PC
    
    I gra.
    
    READY
    []
    
    Pozostało wcisnąć ten zestaw funkcji do AtariWin 800 albo do Altirry jak powyżej na schemacie strzałkowym i gotowe.
    
    No to zostało zrobić. Wait.
    
    DS`.
    OCT.07.2015.
    
    Gotowe.
23. • 23: CommentAuthorsmaku
    • CommentTime7 Oct 2015 20:10 zmieniony

     
    Żeby zdążyć na gotowe działające na za tydzień zgodnie z mobilizacja ostateczną powyżej uzasadnioną, sprawdziłem wstępnie te kody źródłowe do Altirry, co były obok wykonywalnych plików gotowych i tam okazuje się, że pięknie i schludnie idealnie, jak robot porządkowy idealny - zrobiono cały emulator Atari 65XE z podziałem na biblioteki typu cpp i spojrzałem akurat na interesujące biblioteki przykładowe w tematach wyżej omawianych, żeby wiedzieć tylko, że nie jestem bez niczego i musiałbym od zera zaczynać wszystko no i genialne, pięknie zrobione, jak cudo.
    
    Source code (i.e. stuff programmers can modify and compile):
    
    Altirra 2.60 source code (local download)
    
    ->link<-
    
    
    pokey.cpp, assembler.cpp i cała reszta, setki genialności 'na gotowe' :) i pięknie poszeregowane w foldery, poukładane, no robota grzecznego studenta perfekcjonisty max 100%, że bardziej perfekcyjnego perfekcjonisty się nie da - tak wygląda z pierwszego spojrzenia. Perfekcyjne śliczności. :)
    
    Ale ja nie robię w C, bo to mi C przypomina, tylko w Borland Pascalu albo w Delphi najwyżej - musiałbym poznać najpierw Delphi dokładniej. Ale o Pascal by chodziło.
    
    Chociaż tak idealnie to zrobione składnie i ładnie, że możliwe, że lepiej nie dotykać nic i nie zmieniać na Pascala, bo by trwało dłużej niż tydzień konwertowanie lub adaptowanie, hmm... to wystarczy dołączyć pracę układów z Commodore... ktoś ma źródła do Commodore?
    
    Chodziłoby na tym etapie TYLKO o źródła a(na)logiczne do emulatora Commodore 64 i najgenialniej, gdyby to było w tym samym języku, żebym mógł dokleić wprost i na weekend by było gotowe.
    
    Czy ktoś wie, czy są analogiczne źródła do jakiegoś emulatora Commodore 64, co źródła do Altiryy? Żeby ten sam język był tylko - byłoby najlepiej - nic więcej. Poradzę sobie z resztą sam.
    
    (?)
24. • 24: CommentAuthorAdam
    • CommentTime7 Oct 2015 20:10

     

    Smaku:

    Więc Atari w swojej technologii układu graficznego ma barierę na rozdzielczości maksymalnej: 320x192 (zamiast 320x200)

    
    
    Skąd bierzesz takie informacje? ANTIC w trybie najwyższej rozdzielczości potrafi wyświetlić w poziomie 256, 320 lub 384 piksele. W pionie do 240 bez żadnych sztuczek.
25. • 25:
       
      CommentAuthorjhusak
    • CommentTime7 Oct 2015 21:10 zmieniony

     
    @Smaku, już wiem. O ile Twoja teoria jest w porządku, to z praktyką się spotka w nieakceptowanym podzbiorze. Np. tryb tekstowy czarno-biały.
    Weź pod uwagę, że to, co robi układ Pokey czy Antic - wrca przez uszy, transmisję szeregową czy oczy. Próba:
    
    Antic + GTIA:
    wyświetla obraz względem programu w display listy
    W C64- niepotrzebne. Więc możemy ustalić kilka display-list dla okrojonych trybów C64. Będziemy musieli je trzymać w pamięci, ew. w romie.
    Od biedy się dało by tylko na wyższym poziomie, czyli poprzez jakieś API. A wszyscy kodują gry na poziomie niskim, poprzez odwołania do pamięci.
    Pamięć ekranu jest inaczej zorganizowana w trybie graficznym, w tekstowym da radę tryb monochromatyczny.
    Zostaje tekstowy tryb 128 znaków z dwoma duszkami 3kolorowymi, bo takie ma C64 (8) i Atari (wówczas 2) ale też tylko poprzez API.
    Pokey generuje przerwania - napisać API, które ustawi przerwanie w danej linii, bo ZTCW na c64 też się cośtakiego da zrobić.
    
    Pokey - generuje dźwięk, przerwania i obsługuje klawiaturę.
    
    Klawiatura - przezroczyście, pokey dźwięki poprzez API, a po przerwaniach zapominamy. C64 dźwięki poprzez API.
    3 kanały.
    
    Obsługa stacji/IO - to też poprzez API.
    
    No jak Cię mogę, powstaje coś na kształt CPM.
    
    CZyli: wymyślone, zrobione, czas świetności ma za sobą.
    Odpalisz na tym kompilator, edytor tekstów, jakiś interpreter, przetwarzanie danych.
    
    Ale nie odpalisz gry innej, niż tekstowa, ew. tekstowa w 4 czy 5 kolorach.
    
    Jeśli pogodzimy się z utratą funkcjonalności, to warunkiem zadziałania są rejestry sprzętowe w innych obszarach pamięci. A tak jest w stronę Atari->Commodore, bo w C64 można podczepić ram w miejsce rejestrów sprzętowych, ale Commodore -> Atari już się nie da, bo Atari ma rejestry sprzętowe nieodłączalne, a nie ma jak wykryć zapisu do tego obszaru (natywnie) Natomiast pisząc emulator się da się, ale to nie to samo, bo prędkość zmniejszy się kilkunastokrotnie.
    
    Co nie znaczy, że to nie ma sensu, bo duszki np. można by zmultipleksować i mieć te 8 sztuk. Pozostaje wykrywanie kolizji.
26. • 26: CommentAuthorsmaku
    • CommentTime7 Oct 2015 21:10

     
    @Adam: chyba z pamięci a propos trybu jedo-kolorowego (8-my zdaje się) - wydawało mi się, że to najwyższy dostępny w Atari BASIC - podobny do znakowego, ale bez podziału na kostki znakowe 8x8 zdaje się. Nie pamiętam dokładnie (tryb 0 - znakowy). I z Wikipedii też na temat Antic - tak mi mignęło - dokładnie nie przeglądałem jeszcze. Dopiero przy przerzucaniu funkcjami commodor=>atari będę wiedział konkretnie.
    
    Skoro Atari potrafi wyświetlić 320x240 w jednym kolorze, to łyka Commodore z jego rozdzielczością hi-res 320x200 - tylko nie wiem, która rozdzielczość jest pionowa, a która pozioma, bo to istotne w sumie. Sprawdzę dopiero przy pisaniu funkcji - dla emulatora nie ma to znaczenia - funkcja przeliczy na odpowiednie emulowane rozdzielczości. Nie jestem jeszcze na tym etapie. Dopiero sprawdzam co mam i czym dysponuję, czyli:
    
    przed chwilą znalazłem działające emulatory C64 - działają, to OK. Wygląda chyba jak Commodore 64, ale nie wiem, bo nie znam. Gry nie mogę znaleźć żadnej darmowej na C64, chcą logowania albo płacenia sms-em. Jakoś znajdę potem, żeby mieć efekt widoczny. Na czymś konkretnym muszę pracować. Szukałem Barbariana albo inne - żeby były te, co na Atari - tak chyba lepiej: Agent USA, Blue Max, Montezuma's Revenge - żeby widzieć, że Atari robi mi grę z Commodore 64 i musi być idealnie taka sama. O to by mi chodziło, o nic innego, broń Boże.
    
    Jeśli Atari zrobi mi gry, które zobaczę, że robi dobrze, to wtedy uznam, że mam gotowy emulator i zacznę sobie wgrywać gry, które chciałem, czyli Barbariana, dema, inne fajne, których nie znam pewnie nawet. Wreszcie po latach w Last Ninja zagram, etc. - ale na Atari. Na Commodore nie chcę. Na Atari chcę - oczywiste. :)
    
    Zresztą z wątku 'Fanowskie konwersje...' wynikło wszystko - chcę mieć na Atari, oczywiste.
    
    Udało mi się znaleźć prosty nieduży kod źródłowy w C analogiczny jak ten z Altirry do Atari - powinno być łatwe do skorzystania dzięki temu, ale zanim zacznę porównywać i klepać co potrzeba i szukać, bo nie znam tych kodów, ani do tego Commodore to już zupełnie, więc muszę poznać tego commodora najpierw, gdzie co jest.
    
    Potem się przeniesie hurtem jak znajdę co za co odpowiada. No i powinno grać.
    
    Tylko potrzebuję jakąkolwiek grę na commodore, żeby sprawdzić, czy gra w grafice i muzyce jak potrzeba na tym emulatorze, co mam kod źródłowy. Jeśli zagra ładnie, to przyda się i dalej jak wyżej - do połączenia z kodem z Altirry i gotowe.
27. • 27: CommentAuthorsmaku
    • CommentTime7 Oct 2015 21:10

     
    @jhusak: nadal na innym poziomie rozumowania i poszukiwania chyba - w kwestii tego filtru. Za chwilę chyba zacznę robić po kolei i na przykładach się zobaczy. Będzie łatwiej.
    
    Potrzebna mi pełna tabelka możliwych wartości i sygnałów DO i OD sida-a oraz skąd są dysponowane, czyli jakimi rozkazami lub sygnałami spoza sid-a.
    
    Przerobię to na pracę pokeya, żeby pokey grał jak należy to, co podaje mu sid w formie przerobionej funkcjami na zrozumiałe dla pokeya, żeby pokey grał. I te funkcje mają zrobić, że co by sid nie miał zrobić, ma to idealnie zrobić pokey. Jak będę miał emulator SID-a na POKEY-u - mam gotowy filtr układu dźwiękowego.
    
    Poszukam schematy i zrobię. Może nie dziś, bo późno, ale jutro powinno być gotowe na wieczór. Wait. Dzięki. Będzie wiadomo o co mi chodziło.
    
    Potem Antica i resztę graficznych elementów Atari dostosuję do pracy, którą miały robić układy commodora. Bo tylko o to mi chodzi. Atari sobie poradzi. Liczy się efekt dla użytkownika, czyli co by commodor nie chciał zrobić na ekranie swoim za pomocą swoich układów graficznych => ma to zrobić na swoich układach Atari. To mnie tylko interesuje. Znajdę schematy i zobaczę jakie rozkazy sterują grafiką w commodore => i przerobię fikcjami na robienie tego układami Atari. I gotowy układ graficzny w tym filtrze. A reszta, ja pisałem wcześniej, pewnie wprost (wejścia wyjścia, klawiatura, dżojstiki, stacje dysków, magnetofony - to już wprost formaka, oczywiste).
    
    Zrobię i jak mi zadziała to pokażę, będzie łatwiej, jak ktoś wcześniej pisał.
28. • 28:
       
      CommentAuthorCOR/ira4
    • CommentTime7 Oct 2015 22:10

     
    ->link<-
    poszukaj tutaj.Można darmowo pobierać ,musisz tylko przejść weryfikacje wpisując kod i odczekać 10 sec.
29. • 29: CommentAuthorsmaku
    • CommentTime7 Oct 2015 22:10

     
    @jhusak: te wszystkie elementy, o których piszesz w kwestii dźwięków i grafiki i reszty i wszystkiego w sumie - to właśnie trzeba zebrać na odpowiednio najniższym sensownym poziomie, czy warstwie w paczki, o których wspominałem i wcisnąć w funkcje, które tym zarządzą tak, żeby układy Atari dostawały czysty prosty kod rozkazów i wartości do wrzucenia na swoje układy. I Atari ma robić, co dostaje i zwracać, co ma zwracać i do przodu - wykonywanie programu commodore na układach Atari. I ma być efekt jakby to był Commodore, a nie Atari.
    
    No i to się powinno wprost funkcjami łatwo zrobić. To, co wymieniasz, szczegółowe elementy - właśnie trzeba zobaczyć jak będą działać w tych funkcjach, żeby działały w efekcie odwzorowawczo.
    
    Atari MUSI robić to, co w efekcie uzyskuje Commodore ze swojej pracy na swoich układach. Obojętne jak to robi Commodore - ma to robić Atari na swoich układach PO SWOJEMU, żeby uzyskać efekt taki, jak na Commodore - zgodnie z programem wykonywanym przez Commodore na swoim procesorze i pamięciach. Bez układów sprzętowych pozostałych, bo mają to robić atarowskie. I trzeba to po kolei funkcjami przenieść. I tylko tyle.
    
    Zrobię, to pokażę.
30. • 30:
       
      CommentAuthorCOR/ira4
    • CommentTime7 Oct 2015 22:10

     
    Blue Max 2001 zapodaje...

    • blue_max_2001[synapse_1984].nib
31. • 31: CommentAuthorsmaku
    • CommentTime7 Oct 2015 22:10

     
    @irata4: poszukam, nie chciał mi dać Montezumy, wpisałem captchę, zrobiłem co mi kazali a potem nie dali, forbidden jakiś 403. Popróbuję. jedna gra by mi wystarczyła. Dzięki.
    
    Poszukam aż się da. :)
32. • 32: CommentAuthorsmaku
    • CommentTime7 Oct 2015 22:10

     
    Ale to rozszerzenie *.nib się nie znajduje w emulatorach.
    
    Gdyby to było prg, p00 albo crt (cartdrige)to by poszło.
    
    Ale dzięki, znajdę sposób, bo dopiero pierwszy raz to uruchamiam w życiu. Na pewno to jakiś format znany. Dam już sobie radę dalej. Dzięki. To bardzo dużo.
33. • 33: CommentAuthorsmaku
    • CommentTime7 Oct 2015 22:10

     
    Zestawienie SID-a bardzo ładne do przeniesienia na POKEY-a jest tu Wikipedii znowu:
    
    ->link<-
    
    Adresy pamięci - cała lista analogicznie do Pokeya opisanego w tej książce Asembler 6502 i pewnie w Wikipedii też szczegółowo. Właśnie o te skończone pełne tabelki mi chodziło.
    
    Trzeba to przenieść funkcjami adres za adresem, rozkaz za rozkazem (lista rozkazów procesora dot. sid-a u commodora, jeżeli istnieją takie konkretne dedykowane) i pozostałe elementy wylistowane na odpowiadające pokeyowi.
    
    I pokey ma robić to, co sid - automatycznie. Co by nie było podane na elementy zebrane w tych tabelkach sid-a => przenosi się sensownie celem odwzorowania pracy sid-a na pokeya.
    
    Pokey ma robić to, co zrobiłby sid dostając elementy, które dostaje, czyli wartości i sygnały. I to koniec emulacji układu dźwiękowego.
    
    Grafika analogicznie, a reszta znowu to samo co wyżej powtarzam co komentarz: pewnie wprost i najłatwiej.
    
    No i znowu: gotowe. Tylko zrobić i działa. :)
    
    Tak to widzę. Chyba się nie mylę?
34. • 34:
       
      CommentAuthorCOR/ira4
    • CommentTime7 Oct 2015 22:10 zmieniony

     
    a taki plik ?
    ->link<-
    ->link<-
    innych rozszerzeń nie znalazłem .

    • Blue Max.d64
35. • 35:
       
      CommentAuthorCOR/ira4
    • CommentTime7 Oct 2015 22:10

     
    kurcze ,nie da się zmusić układu do wykonania pewnych zadań ...wykona to fakt ale po swojemu i nie będzie to zgodne z oryginałem ,to nie T 1000 ;-).
36. • 36: CommentAuthorfalcon030
    • CommentTime7 Oct 2015 22:10

     
    A to widziałeś:
    ->link<-
    Istniejący player SIDa:
    ->link<-
37. • 37: CommentAuthorsmaku
    • CommentTime7 Oct 2015 22:10

     
    Ten BlueMax (d64) jest OK. Działa, ale na tym emulatorze, którego nie mam kodu źródłowego akurat. :) Na tym etapie już nie będzie nic w tej kwestii problemem. Poszukam odpowiedniego emulatora z kodem źródłowym do plików, które będzie czytał i obsługiwał, czyli przykładowo ten Blue Max.d64, albo sobie przerobię na inny format, ważne, że działa gra, czyli da się z nią zrobić cokolwiek. Więcej nic nie trzeba. Wielkie dzięki. Na gotowe. :) Wystarcza.
    
    Teraz muszę poszukać odpowiedniej pary emulator + kod źródłowy, gierki sobie dostosuję najwyżej, żeby je czytał i OK.
    
    Dzięki. Przydało się.
38. • 38: CommentAuthorsmaku
    • CommentTime7 Oct 2015 23:10

     
    @falcon030: Sprawdziłem przed chwilą ten istniejący player sida-a - gra super, jeśli te muzyczki są zgodne z oryginałami commodora odgrywane jak należy w standardzie jakimś sensownie zrobionym to o to mi chodziło.
    
    Jeśli ten player odegra każdą muzyczkę i każdy dźwięk z commodora, to mamy 100% to, co chciałem robić w kwestii emuluowania dźwięku commodora.
    
    Tam jest link do kodu źródłowego, czyli na gotowe => wystarczy dołączyć do Altirry zgodnie z projektem wyżej opisanym, po tym 'filtrze'. No to sid gotowy.
    
    Jeszcze grafika. :)
    
    @irata4: nie da się zmusić do zrobienia tego, czego fizycznie nie jest w stanie zrobić, czyli są te bariery technologiczne, o których wspominałem i to są oczywistości i te bariery akurat bez ograniczeń nawet typu 'drobiazg nieistotny' gotowy, czyli T1000 robi system emulujący niższe platformy technologiczne, czyli PC-t. Na PC wszystko robię i emuluję, więc deluxy są drobiazgiem tylko, jako upgrade do sprzętów i poprawki istotne, żeby mieć perfect emulację jaką mam ochotę.
    
    Jeśli uda się zrobić ten filtr w wersji najprostszej bez zbytnich deluxów 'kosmicznych', to spokojnie zrzuci się na warstwę sprzętu i będzie można 1kB emulator Commodore 64 wgrać na zwyczajnym sprzętowym Atari 65XE, podłączyć kablem Commodore 64 i wgrywać gry na Commodore i dowolne programy a robił będzie idealnie Atari 65XE - sprzęt oryginalny. Ale warunkiem jest zrobienie prostych tych funkcji i pakiecie skończonym, żeby na małą płytkę wrzucić jako interface sprzętowy, taśma, łączy się przez porty dżojstików i gotowe. A nawet deluxe się dorobi, jeśli potrzeba, a potem wyjmie się procesor z pamięciami Commodore 64 i dołączy do środka Atari 65 i nikt nie zauważy, że Atari 65XE robi albo swoją robotę albo Commodore 64 i to idealnie - wystarczy zabrać z Commodore 64 procesor + pamięć - jak opowiadam od początku tego pomysłu. Tylko procesor i pamięć - resztę robi Atari samodzielnie u siebie.
    
    Ale to jeśli ktoś by potrzebował sprzętowe - nie wiem, kto by się bawił oryginałami, skoro są emulatory na PC i nie mają ograniczeń w upgradzie... nawet do Super VGA Cosmic 64-bit i analogicznie z muzyką.
    
    A wszystko klika się kliknięciem: załaduj grę Commodore 64 => wykonaj na Atari 65XE - albo w dowolne strony. obojętne. Oczywiste.
    
    Ten drugi lik a propos SID i Pokey też fajny, ciekawe. Bo nie znam tego jeszcze. Dzięki. Zapoznam się potem.
    
    Ale już mam gotowy SID. To najważniejsze. Teraz grafika. Potem reszta i można wrzucać na Altirrę.
39. • 39:
       
      CommentAuthorCOR/ira4
    • CommentTime7 Oct 2015 23:10

     
    Pod Pc da radę, troszkę nie jasno napisałeś a ja w dodatku niedokładnie czytałem ,więc teraz się z tobą zgadzam ,tylko po co się męczyć skoro są emulatory różnych platform ?
    Ja bawię się oryginałami :-), sprzęt oryginalny nigdy nie zastąpi "sprzętu"emulowanego ,już niektóre dopałki do A8 to troszkę za dużo jak dla mnie dla zachowania oryginalności ,dlatego mam dwie Aósemki jak i inne komputery konsole ,jakoś na Pc nie ciągnie mnie do gier, nie lubię grać na tym na czym pracuje już jak patrzę na Kompa to bolą mnie plecy i jestem zmęczony ;-) a zapomniał bym -S.T.A.L.K.E.R. jest wyjątkiem .
    Ciekaw jestem czy istnieje takie "SIO2SD" dla NESA,SNESA,MEGA DRIVE,wykonać się da ,zresztą muszę poszukać , takie urządzenie było by dla mnie zbawieniem ,taki wtyk na taśmie bądź kilka dla kilku modeli konsol na wejście dla kartridża z biosami dla poszczególnych konsol z wejściem na kartę sd z której za pomocą loadera można by uruchamiać programy pod daną konsole i grać na oryginale ,marzenie ... myślę że nie ,ale nie mam tego i szukam .
40. • 40:
       
      CommentAuthorTheFender
    • CommentTime8 Oct 2015 08:10

     
    "zrobi się ..." :D
41. • 41:
       
      CommentAuthorpirx
    • CommentTime8 Oct 2015 11:10

     
    w ogólności to wiemy, że te pomysły nie mają głębszego sensu, ale taki ferment czasem może coś nowego wytworzyć.
    
    Einsteinowi przypisuje się powiedzenie "Gdy wszyscy wiedzą, że coś jest niemożliwe, przychodzi ktoś, kto o tym nie wie, i on to robi."
42. • 42:
       
      CommentAuthorTheFender
    • CommentTime8 Oct 2015 12:10

     
    Ja znam taki cytat: "krowa która dużo ryczy mało mleka daje".
    Polski, zdaje się ;)
43. • 43:
       
      CommentAuthorpirx
    • CommentTime8 Oct 2015 13:10

     
    zdecydowanie tak, kluczem jest "i on to ROBI" :)
44. • 44: CommentAuthorsmaku
    • CommentTime8 Oct 2015 14:10

     
    @irata4: być może za bardzo ogólnie na początku opisywałem, o co mi chodzi, stąd potem niezrozumienie tematu w szczegółach a nawet zaprzeczenie zupełne w postaci tych komentarzy o barierach kosmicznych, których nie da się obejść, itp. jakieś crack pointy, itp. za bardzo ogólnie może opisywałem, schodząc do szczegółów i możliwe, że nie wyjaśniłem na początku, że nie chodzi od razu o emulację czystą sprzętową, ale na emulatorze Atari na PC najpierw - to było dla mnie podstawą rozmyślania o pomyśle i opowiadania o tym, a jeśli niektórzy myśleli na poziomie sprzętów oryginalnych, to mogły to być utrudnienia tego typu, co można poczytać wyżej właśnie, oczywiste teraz i dla mnie się to robi, że nie łatwo od razu zrozumieć, co miałem na myśli, myśląc o sprzętach Commodore 64 i Atari 65XE, bo jest to poziom rozmyślania ograniczony na poziomie jednej linii - obrazując - na której leżą dwie maszyny i teraz trzeba myśleć, jak układy fizyczne jednej maszyny emulować na drugiej - no trudno to sobie o razu wyobrazić, żeby mieć gotowe rozwiązanie zadania, mimo, że to jest 100% to samo zadanie, ale utrudnione straszliwe, bo patrzy się inaczej myśląc o tym.
    
    Miałem na myśli od początku zrobienie tego filtra w postaci programowej na emulatorze Atari 65XE na PC, stąd łatwo mi było myśleć w sposób oczywisty, gotowy i tylko zrobić - same oczywistości jak dla dziecka zadania gotowe.
    
    A komentarze były jakby kosmita jakiś pisał rzeczy niestworzone. :)
    
    Co do pytania 'po co', to wzięło się z wątku 'Fanowskie konwersje' - chciałem mieć zawsze niektóre gry na Atari, które były na ZX Spectrum albo Commodore 64, no to sobie pomyślałem co z tym zrobić, żeby mieć. I tylko tyle.
    
    Zrobię sobie w weekend, albo po weekendzie. Jak będę miał wolny czas. Żeby sobie pograć. Na Atari, nie na Commodore czy Spectrum. Atari jest komputerem, który mam, czuję się jak u siebie w domu z tym kompmuterem, chcę mieć gry z innych 8-bitwoców działające na Atari - to cały powód zrobienia tego, co chcę, czyli przeniesienie hurtem wszystkiego i mam od razu gotowe i spokój.
    
    Zrobienie przejściówki fizycznej między sprzętowymi komputerami to już formalka, jak pisałem wyżej - jedna malutka płytka z kilkoma lutami i ścieżkami. Nic więcej. I będzie działać na oryginalnych kompach. Ale to jeśli ktoś chce, mi wystarczy na emulatorze.
    
    Te przejściówki między konsolami do gier to analogicznie - kilkanaście minut 'formalki' - zrobienie odpowiedników funkcji analogicznie jak w tym pomyśle commodore<=>atari. Tak to widzę. Wystarczy zrobić. Pod warunkiem, że jest podobna specyfikacja techniczna, że mogą się 'łyknąć'.
    
    Inaczej to byłoby męczące, trzeba by robić 'deluxe' filtry, żeby Amiga poszła na Atari 65XE, ale też się zrobi - dorobię sobie. Zawsze chciałem mieć gry i dema z Amiga 500 na Atari 65XE - wystarczy podrasować funkcje na tym filtrze przy filtrowaniu Amiga 500=>Atari 65XE i gotowe. Atari zrobi mi wszystkie gry i dema i użytki, 100% co Amiga robi, ale w wykonaniu autorskim własnym, czyli na 6502, na pokeyu, na Anticu, gtia, etc. - czyli na swoich narzędziach własnych, czyli znowu jak w domu u siebie. Miałbym Amigę, Commodore 64 i resztę potem. najważniejsze, że Atari sam to zrobi u siebie, a nie muszę przenosić się na inne kompy. Chcę mieć na Atari. Oczywiste. Wystarczy podrasować układy Atari, jeśli specyfikacja techniczna komputera emulowanego jest wyższa niż Atari. To tylko drobne zmiany wartości w emulatorze - kilka liczb. Oczywistości same.
    
    A zrzucić to z powrotem na warstwę techniczną, to też drobiazg - każdy elektronik, a nawet nie elektronik umie zrobić sobie sam. Na gotowe. To proste rzeczy chyba są i oczywiste? Tak mi się wydaje oczywistościowo.
45. • 45:
       
      CommentAuthorCOR/ira4
    • CommentTime8 Oct 2015 18:10

     
    jeżeli gra dajmy na to z Zx/a czy C64 dowolna najprostsza (byle nie tekstowa)uruchomi się poprzez ów "filtr" na emulowanym A8 i można by taki wynik plik zapisać jako wykonywalny i ruszyć to na fizycznej Atarynce to pytań nie mam.
46. • 46: CommentAuthorsmaku
    • CommentTime8 Oct 2015 20:10

     
    @irata4: no właśnie o tym elemencie myślałem, czy da się to jakoś zrobić, żeby po uruchomieniu sobie raz takiej gry, dema, czy użytku - 100% obojętne, bo odwzorowanie pracy ma być idealne - pełna emulacja, o to by chodziło w tym filtrze - można się pozbyć potem procesora i pamięci commodore, a właściwie nawet tylko procesora, bo pamięć RAM jest tą samą tablicą 256x256 - nie różni się niczym zupełnie, kiedy jest pusta, napisali w Wikipedii że Commodore 64 ma 64kB RAM, stąd domyślam się,że pewnie też na tablicy bajtów 256x256, czyli w Pascalu prosta zmienna jedna:
    
    var mem_array [0..255, 0..255] of byte;
    
    I to cała pamięć RAM Atari i tak samo Commodore 64.
    
    Składni dokładne nie pamiętam tablic w Pascalu, bo nie jestem na co dzień z tym, ale jakoś tak ogólnie.
    
    No więc wystarczyłoby pozbyć się procesora 6510 po jednokrotnym wykonaniu programu, ale wyszłoby, że można by jedynie zrobić save'a z pracy zrobionej przez Comodore 64. Taki zrzut pracy, jak 'save state' (zapis z danego momentu) albo zapis ciągły całej pracy ('save continuous process of executing program'), coś w tym stylu powiedzmy.
    
    I można by puścić sobie swoje granie jako film - save z tego, co zapamiętał Atari z tego co robił. To jest proste i gotowe. Nieistotne i od razu gotowe, czyli pomijalne w rozmyślaniu, bo nie o to by chodziło.
    
    To, o czym piszesz równa się przełożeniem kodu wykonywalnego z programu Commodore 64 na kod wykonywalny przez Atari 65XE, a to zupełnie inna robota i 100% inna rzecz i nie związana z filtrem.
    
    Hmm... no właśnie o tym chwilę rozmyślałem wczoraj czy przedwczoraj koleją rzeczy myśląć o tym filtrze. Bo to oczywiste w sumie, że byłoby fajnie mieć gotowe wykonywalne pliki com i exe atarowskie zrobione wprost z commodorowych, ale to zupełnie inny projekt by był 100% inna rzecz.
    
    Jedna rzecz jest 'nadziejowa' w tym filtrze, że mając podawane na wykonanie przez Atari programy z Commodore, można zapisać dzięki filtrowi w jakiś sposób coś z pracy filtra w tę i z powrotem... ale byłoby jakieś nie wiem co i jak to uszeregować w coś konkretnego, tak od razu. Taki bit-flow z pracy commodore=>atari, jak tabelka translacyjna - analogicznie jak słownik polsko-niemiecki z gotowymi zwrotami - co oznacza co w danym języku. I to nie po słowach, ale gotowe zdania, jak gotowy słownik turystyczny. Hmm...
    
    Ale nie wiem jak przenieść za pomocą tego filtru kod commodore na kod atari. Robota filtra jest w locie na bieżąco (instream) z pracy procesora commodora - nie wynika z tego kod programu commodora, który miałby być wykonywany samodzielnie na procesorze atari. Commodor robi i daje efekty jedynie na układy atari. Commodor ma swój program, atari nawet go nie zna i nie musi. Potrzebny jest procesor commodora do robienia programu commodora, atari nie umiałby czytać programu commodora z pamięci, nawet, gdyby mu włożyć do RAM program commodora bajt za bajtem do tej tablicy 64kB odpowiednio jak należy, żeby mógł sobie czytać, to co niby miałby zrobić z tym atari, skoro by nie rozumiał? Zestaw rozkazów i reszta jest inna tu i tam. Atari by przeczytał i zawiesił się, nie rozumiejąc.
    
    Trzeba by ten kod z RAM zamienić na zrozumiały dla Atari to wtedy tak. Byłoby gotowe.
    
    Hmm... ciekawe. To można by tak właśnie. prosto z RAMU i gotowe. Nie potrzebny by był procesor Commodora. Hmmm... :)
    
    Jedynie sposób realizowania programu przez procesor commodora musiałby udawać Atari, czyli Atari musiałby umieć czytać i robić program commodora u siebie na układach. OK. Czyli DA SIĘ! :)
    
    No to gotowe. :)
    
    Wystarczyło pomyśleć. Jak wyżej. To proste w takim razie.
    
    To tak będzie. Same ATR-y z plików commodorowych.
    
    Pakiet gier i użytków i dem gotowy w ATR na Atari. Chyba się da, zgodnie z powyższym.
47. • 47:
       
      CommentAuthorTheFender
    • CommentTime8 Oct 2015 20:10

     
    Jedynie sposób realizowania programu przez procesor commodora musiałby udawać Atari, czyli Atari musiałby umieć czytać i robić program commodora u siebie na układach.

    
    
    Przeczytałem to, muszę czytać resztę? :)
48. • 48: CommentAuthorblacktofu
    • CommentTime8 Oct 2015 20:10

     

    smaku:

    napisali w Wikipedii że Commodore 64 ma 64kB RAM, stąd domyślam się,że pewnie też na tablicy bajtów 256x256, czyli w Pascalu prosta zmienna jedna

    
    
    

    smaku:

    czyli Atari musiałby umieć czytać i robić program commodora u siebie na układach. OK. Czyli DA SIĘ! :)

    
    
    Jak to napisał jeden światły człowiek - Nigga, please.
    
    Poczytaj najpierw na co się porywasz: ->link<- (od akapitu Emulation 101 - Fetch and Dispatch).
    
    Może kiedyś, ale jeszcze nie w ten weekend (i jeszcze minie bardzo dużo weekendów) uda Ci się zrobić emulator Apple II na Atari. Bardzo wolny emulator. Nie zapomnij sprawdzić co to jest Apple II.
49. • 49: CommentAuthorsmaku
    • CommentTime8 Oct 2015 23:10

     
    @blacktofu: przejrzałem pobieżnie o czym mowa w tym pierwszym akapicie - o środowiskach wirtualnych i emulowaniu środowisk, ale to nie ten temat mi się zdało - wirtualizacja środowisk to ogromne machiny, wymagające wydajnych dość systemów, na których dokonuje się wirtualizacji, chodzi o szybką transmisję danych i szybki dostęp do zasobów wirtualizowanej maszyny, a raczej JEDYNIE środowiska programowego, czyli np. na Windows wirualizowanie środowiska MAC-a, szczególnie przy systemach sieciowych wielosystemowych zróżnicowanych, chodzi raczej o świat sieci i korzystanie ze środowisk wirtualnych przez klientów / użytkowników w zależności od potrzeb lub wymagań lokalnych i żeby zapewnić taką wirtualizację dla większej ilości terminali w sieci firmowej lub większej, to nawet nie wiem czy sens pod wieloma względami różnymi - potrzebne są porządne systemy sieciowe całe na maszynach wiadomo jak wielce wydajnych i działających równolegle również w sieci, żeby zapewnić wydajność i obsługę rozproszoną, albo na jednym serwerze wydajnym dobrym dobrze skonfigurowanym - wtedy się jakoś da, ale czy jest ens i po co to komu? Pewnie tylko Chmurze i marketingowi. Czyli tak czy inaczej nie te temat, o wirtualizacji środowisk terminali sieciowych to nie ten wątek.
    
    Czy coś tłumaczyć więcej? Czy nie trzeba więcej?
    
    Emulowanie Apple II na Atari 65XE jest prostackie i działa od razu w locie i gotowe po kliknięciu, nawet z uwzględnieniem wirtualizowania środowisk sieciowych wielu terminali na serwerze Apple'a. Nie jest to problem, pod warunkiem, że system, w którym Atari 65XE będzie na tyle wydajny, żeby 'łyknąć' Apple II. Oczywiste, czy narysować i wytłumaczyć dokładnie? :)
50. • 50: CommentAuthorsmaku
    • CommentTime8 Oct 2015 23:10

     
    A co do czasu wykonania, to rzeczywiście nie tylko weekend jest za dużo nawet, bo to również trwa tylko 15 minut na gotowych funkcjach jak dla wersji Commodore 64=> Atari 65XE. Różnica w emulacji i filtrze w środowisku wykonania: 00.00% - czyli żadna.
    
    jak pisałem a propos emulowania tą samą metodą konsoli do gier - irata4 chyba pisał coś o tym. Dokładnie to samo: 00.00% różnicy. Działa od razu tak samo. Czyli idealnie 100% i gotowe. Zawsze z uwzględnieniem wydajności systemu, który trzyma u siebie emulator wykonując pracę emulatora. Maszyna realizująca zadanie musi być minimalnie sensownie wydajna, czyli umieć lekko łyknąć maszynę niższą, czyli tak jak emulowanie Atari 65XE na PC 386DX 33MHz, czyli działa jak piórko na przerwaniu. Oczywistości.