🚀 go-pugleaf

W dniu wtorek, 14 lutego 2017 17:19:33 UTC+1 użytkownik Luke napisał:
> > no mozesz powiedziec co tobie da maxymalny fun i wtedy
> > zobacze czy moj fun bylby dla mnie wiekszy ;-)
> > 
> 
> Nie ma odpowiedzi na to pytanie. Nigdy nie czułem potrzeby ani fun'u w
> pomyśle robienia własnej maszyny wirtualnej. Być może fun byłby wtedy,
> gdyby była emulatorem czegoś realnego, co jeszcze nie ma emulatora (jest
> jeszcze coś takiego dzisiaj?).
> 

to chyba nie do konca emulator bo na przyklad takie 8 bitowce czy 16 bitowce maja swoja fizyke (rezimy czasowe scisle okreslone przez fizyke) tutaj nie jestem pewien czy chcialbym emulowac ta cala fizyke z realnego swiata 
(bo wydaje mi sie to ew trudniejszym zadaniem) czy tylko okreslone stany pamieci i 'fizyke'
z grubsza
 
dlatego mowie o maszynie wirtualnej, choc tez nie wiem czy to poprawna nazwa, albo o wirtualnym komputerze


> Albo poszedłbym w opracowanie jakiegoś małego komputerka od zera.
> Bodajże widziałem gdzieś realizację komputera o możliwościach
> ośmiobitowców na mikrokontrolerze. No i pod to można np. pisać proste gry.
> 
> Oczywiście praktyczne zastosowanie tego nie ma sensu, komercyjność też
> żadna.
> 

zastosowanie edukacyjne jest naprawde potezne (a ze zastowanie edukacyjne jest praktyczne wiec jest to praktyczne zastosowanie - tyle ze w edukacji ;c )  - teraz np pisze kompilator A, bez maszyny wirtualnej na ktora moge to duzo napisac by mi sie tego nie chcialo bo
ogrom detali wspolczesnego peceta nieco przytlacza a na mala maszynke wirtualna - czysta przyjemnosc ;c Podobnie moze byc z innymi oldschoolowymi aspektami np z pisaniem
w samym asemblerze czy z pisaniem swojego malego osa czy wogole z projektowaniem jakichs
wirtualnych architektur (raj dla ludzi ktorzy lubia cos wymyslac) 







> > wlasnie na tym to polega ze mozna zakodowac kompletnie wszystko, dowolny proc dowolny asm +  niemal dowolny
> > 'hardware' (czy apis systemu) i to jest ciekawe
> 
> To jest ciekawe, ale jednocześnie nieciekawe przez to, że wszystko
> można. Sens pisania w assemblerze polegał na radzeniu sobie z
> ograniczeniami. A tutaj w pewnym momencie przestanie to nawet spełniać
> definicję assemblera, a stanie się "interpreterem cyferek", tzn.
> parserem pliku binarnego.

nie do konca rozumiem o czym mowa, co sie stanie tym interpretaterem cyferek/parserem
pliku binarnego? maszyna wirtualna czy assembler? akurat ja samej maszyny nie
planowalem zbytnio optymalizowac - swoja 
droga nie wiem ile by to dalo 


> Bo można to zaprojektować nie jak dla
> procesora, tylko jak dla znacznie bardziej inteligentnego interpretera.
> 

no mozna ale to odzielne zagadnienie - jesliby maszyna miala analizowac kod maszynowy zamiast go iteracyjnie wykonywac to chyba znaczny wzrost predkosci by byl tylko wtedy gdyby robila to nie jako interpreter asma  a jako 
kompiler asma - czyli defakto jakby optymizer
dla juz wygenerowanego kodu - to raczej calkiem odzielne zagadnienie


> > z dzwiekiem jest taki problem ze nie mam wiekszego pojecia jak takie hardware dziwkowe powinno wygladac 
> 
> Robiłbym coś na wzór komputerów ośmiobitowych. Ewentualnie emulację
> lepszego dźwięku podobną do Sound Blastera pod DOS (czyli DAC i FM
> obsługiwany portami albo przerwaniami).
> 
z kims tak ostatnio gadalem i ktos powiedzial ze taki dzwiek generowany bardzo masywnie bardzo w realtime (co kazda ramke wiele dzwiekow) moze sie jednak wiazac z opoznieniami - nie wiem na ile ten ktos jest 
jednak kompetentny a sam nie mam ostatnio ciagle czasu rzucac wszystko na pare dni czy wiecej i czytac i eksperymentowac ;C 

ktos tez pokazywal jakis kod w c jak sie robilo dzwiek pod dosem wygladalo to prosto ale sam nie mialem z tym doswiadczen, tak samo
z soundblasterem... wydaje mi sie ze kompletnie najprostsza wersja dzwieku to by bylo ustawic czestotliwosc w jednym rejestrze i amplitude dzwieku w drugim ale to bylby tak prosty piszczek ze nie wiem czy jakies realne sprzety mialy taki prosty dzwiek

wspolczesne api dzwiekowe nie wydaja sie 
z tego co sie zorientowalem wiele berdziej skomplikowane po prostu sie ustawia ofsset
w samplu i tyle 

c64 mial cos bardziej skomplikowanego niz 
jednotonowy brzeczek ale chyba nie az tak bardzo (szkoda ze nie pamietam), mial chyba 4 kanaly i mial jakies fazy (obwiednie dziweku 
narastanie podtrzymanie opadanie ale nie pamietam juz czy na jednym tonie czy to bylo cos bardziej skomplikowanego)

fajnie by bylo zaprojektowac sobie jakies wlasnie hardware do dzwieku 'syntetycznego'
ale cos bardziej skomplikowanego nic to co bylo na c64...

te wszystkie trackery na amige itd, wtedy tego nei ogarnialem ale wydawalo sie to fajne