Keresés

Részletes keresés

Kováccss Creative Commons License 14 órája 0 0 10831

Ez a Raspberrys izé lehet hogy jó sima 1541 helyettesítőnek, de több más funkcióra is szükség lehet. Vannak egyéb bővítések, fejlesztések is. Ha már SD kártyás eszközt használok, ne egy alapcucc legyen csak, ami csak d64-et és pár más formátumot kezel.

1-- Pl. gyorstöltő, sima 1 file-os programoknál is jól jön, meg utántöltősnél az 1. file betöltésére is.

2-- Aztán van 512 KB-os 1750 RAM bővítő, erre írtak demókat is. Több felhasználói program és rendszer is használja, mint a lemezmásolók, a GEOS, Wheels, stb.

3-- Ebből már létezik 16 MB-os is, pl. az 1541 Ultimate-ben, vagy az Ultimate 64-ben. Erre is írtak utilt, videókat lehet vele készíteni, alapból 1 MHz-en 1 MB/s körüli DMA-t tud, ami megint sokmindenre használható. A Turbo Chameleon 64-ben is van 16 MB-os REU.

 

4-- A Turbo Chameleon 64-ben (TC64) van turbó mód is, így nem kell megakadni a szokásos demók, játékok szintjén, mert sokkal több lehetőség van az 1 helyett 15 MHz körüli sebességgel. Meg nem kell C128 2 MHz módban trükközni csak az alsó-felső kereteken bekapcsolva, hogy ilyen raszterszíneket csinálj. http://csdb.dk/release/?id=155871

Így is csak 3 színt lehet csinálni 1 sorban, mert csak az A, X, Y regiszter létezik.

950C LDA 10, LDX 38, LDY 60, STA D020, 3×NOP, STX D020, STY D020, STX D020, STA D020.....

Vsz-esen így is csak 2 karakterhelyen tud 1 színt létrehozni, 1 helyen nem. Ez is csak úgy működik, hogy muszáj a nulláslapot használnia puffernek a színek beolvasásához. Ha rendes 2 byte-os területről olvasná be a színeket, akkor máris csak 3-4 karakterhelyet tud programozni, 2-t nem, mert több időbe telik az utasítás végrehajtása. Megnéztem a kódot.

 

5-- TC64-gyel no limit turbó módban akárhány színt lehet csinálni 1 sorban, 1 szín = 1 karakterhely, sima LDA #érték, vagy LDA ABCD, STA D021-gyel. Ez a képernyő belső részén 40 színt jelent soronként. Azaz 1 kurzornyi 8×8 pixeles helyen 8 szín lehetséges. Már csak ezzel sokféle demóeffektet lehet létrehozni. Az oldalsó és az alsó-felső kereteken is lehet ezt alkalmazni. Ezt a sebességet a sprite-ok még alaposabb kiszínezésére is fel lehet használni, a 24×21 pixeles területen 3×21=63 szín lehetséges, és ehhez nem kell többszínű sprite módba kapcsolni. Azaz a grafikai felbontás nem csökken a felére, mint minden többszínű módnál. Normál esetben többszínű (karakteres, nagyfelbontású) üzemmódban 1 karakterhelyen (vagy összesen az egész sprite-ban) csak 3 szín, plusz az 53281-es háttérszín lehetséges.

 

Még csak a színek növelését említettem, van sok más lehetőség is a turbó móddal. Számításigényes animációk gyorsítása, 3D effektek, akár több is egyszerre, tömörítés, kicsomagolás, stb.

A TC64-ből sokat eladtak, több 100-at, mégse írt még senki a sebességet kihasználó demót, pedig ez lenne a lényeg, mert a sima 1 MHz-es gép lehetőségeit már kimerítették.

Előzmény: Commodore-szerviz (10830)
Commodore-szerviz Creative Commons License 16 órája 0 0 10830

Ez olcsó, azonnal van, nem egy gyártási batch-re vársz, majd posta ,stb,

Bármennyi van, nem a szokásos megy, hogy ""most gyártunk 200at, ebbe nem fértél bele, de majd jövő akármikor...""

 

A használhatósága nekem semmivel nem tünt rosszabbnak mint pl. az SD-IEC, kártyára másol, bedug, bekapcsol, load, megy.

 

 

Előzmény: Kováccss (10829)
Kováccss Creative Commons License 21 órája 0 0 10829

Nem látom ennek a nagy előnyeit. Miért kell ilyennel szenvedni? Akiknek nem felel meg a valódi 1541 valódi lemezekkel, az használjon VICE-t. Ha egyik se jó, vannak rendesen használható SD kártyás 1541 emu eszközök.

Előzmény: Commodore-szerviz (10826)
Commodore-szerviz Creative Commons License 1 napja 0 0 10828

Ha megy a cucc, semmi nem kell, a GPIO gombokkal "vakon" is nyomathatod, van egy "kidobott lemezzel" betölthető commander is benne, amivel aztán már lehet mászkálni a lemezek és a file-ok között.

 

 

Előzmény: siz (10827)
siz Creative Commons License 1 napja 0 0 10827

Ja, valaki plus4world-re is feltette már. Én tervezem kipróbálni, de egyelőre még nem barátkoztam meg azzal, hogy a pi-re kell belépni és ott kiadni a mount parancsokat.

Egyébként UK1541-em is van, azzal a legnagyobb baj az idétlen kijelző és távirányító. Meg hogy a készítője egyáltalán nem hallgat a javaslatokra. De az emuláció konkrétan egészen jól működik.

Előzmény: Commodore-szerviz (10826)
Commodore-szerviz Creative Commons License 1 napja 0 0 10826

Skacok, ha valakit esetleg érdekel, egy gyors hír:

 

https://cbm-pi1541.firebaseapp.com/

 

Ez egy teljes értékű 1541 emulátor Raspberry Pi 3-ra.

 

Az ember majd egy éve harangozta be Lemon64 fórumon, volt némi kétség, hogy (mint sokan, akik évekkel ezelőtt igértek arm-os 1541-et) sosem ad ki semmit.

De itt van, működik. Nem csak valahogy-fogjuk-rá, hanem egészen extrém, mármár agyrém másolásvédelmekkel is!!

Az emuláció szintje megítélésem szerint bőségesen túllépi a bármiféle "hétköznapi" szükségleteket.

 

A rossz emlékű UK1541-el szemben ez egy "kit", magadnak kell Pi3-at "szerezni", kábelt "építeni".

Ugyanakkor nem kereskedelmi termék, ennek előnyei is vannak, nagy tévén nézheted a képet, akár átkapcsolgatva ugyanazon mint a C64-et, nem vagy valami agyrém mechanikai formátumba szorítva, stb.

 

Az ára érdekes, hisz épp a "lényeg", a tudás, az emuláció gyak. ingyen van. Letöltöd, kártyára másolod, használod, örülsz.

Pi3 még a kezdetekkor kb. egy éve olyan "drága" volt, úgy tűnt szinte "meg sem éri"...kereskedelmi megoldások kompletten voltak ilyen 20e körül-alatt kicsivel. (pl az a bizonyos magyar emulátor)

 

Mostmár a Pi3 idehaza is elérhető kb. 10e ft körül, és ez várhatóan még csökkenhet, sőt akár használtan töredéke is lehet 1-2 év múlva.

 

Egyébként a csóka ígéri a forráskódot is, ha azt kiadja, égszakadás, földindulás, lassanként akkor a régi kis mikrokontroller alapú protokoll-emulátorok (SD_IEC) stb többékevésbé "okafogyottá" válnak.

 

 

Kováccss Creative Commons License 2018.05.06 0 0 10825

A dolphindos be van építve a DCR-em belső 1571-ébe is. Meg a jiffydos is. Nem nézted végig a leírást?

185 blokk load 4,3s.

Előzmény: Sheme (10823)
Kováccss Creative Commons License 2018.04.29 0 0 10824

Rengeteg munka volt, nem is teljes áron hirdetem. Nem tervezek több átalakítást, ezt se fizeti meg teljesen senki. Még ezen az áron is nehéz eladni. Ez a DCR egy életre elég bővítést tartalmaz.

Hirdettem 16 MB-os RAM bővítőt is, ez már teljes ár. http://www.vatera.hu/16-mb-os-ram-bovito-commodore-128-c128-modhoz-es-commodore-64-hez-2621083736.html

Előzmény: Sheme (10823)
Sheme Creative Commons License 2018.04.29 0 0 10823

Szép munka, gratulálok! Nekem nem lett volna türelmem hozzá! Egyébként ha már beépítettél egy rakás gyors töltőt az alapgépbe, esetleg be tudnád építeni a 1571-be is azokat? Delfin, meg a többi...

Előzmény: Kováccss (10822)
Kováccss Creative Commons License 2018.04.26 0 0 10822
Kováccss Creative Commons License 2018.04.20 0 0 10821

Az is fontos milyen rendszerben töltődnek be 27-szeres sebességgel a file-ok. Meg miket töltenek be.

Sheme Creative Commons License 2018.04.20 0 0 10820

Komolyan?

Előzmény: siz (10816)
epy116 Creative Commons License 2018.04.19 0 0 10819

Már kezdtem aggódni :-)

Előzmény: siz (10816)
Kováccss Creative Commons License 2018.04.19 0 0 10818

Nem csak a load sebessége a lényeg. A hibátlan adatolvasás is fontos. Ezek a másolók a gyors olvasással foglalkoznak csak, semmilyen lemezhibával se törődnek. Ki tudja hogy tényleg azt olvasták-e be, mint ami a lemezen volt? 30 évesek a lemezek. Az 1764 REU-kat 1986-7-ben gyártották, itt is lehet hibázás. Az írásnál se biztos hogy van verify, vagy állítható. Jobb a lassabb olvasás és az írás, ha nincs adatvesztés. Nyilván nem véletlen, hogy a delfinnél "csak" 27-szeres a sebesség, amikor az elméleti max. 61-szeres, de képernyőkikapcsolással. Éppen elég gyors a load az átlagos programokhoz, 3-4s.

Előzmény: Sheme (10815)
siz Creative Commons License 2018.04.19 0 0 10817

Hát, ha 35 másodpercre az elméleti maximum 7 másodperc, akkor 8,5 alatt simán be lehet olvasni, nem? (Monduk nem számoltam utána, de érzésre rendben levőnek tűnnek az adatok)

Előzmény: Sheme (10815)
siz Creative Commons License 2018.04.19 0 0 10816

Igen.

Előzmény: epy116 (10814)
Sheme Creative Commons License 2018.04.19 0 0 10815

OK, de akkor hogyan tudta Whitewolf teljes lemezes másolója, a 17s copy azt az egy lemezoldalt benyalni 8,5mp alatt? Legalábbis a tecső szerint ennyi volt.

 

Rendben, biztosan igazad van, én csak vauzom a témát!

Előzmény: Kováccss (10813)
epy116 Creative Commons License 2018.04.19 0 0 10814

TiedLehet?

Kováccss Creative Commons License 2018.04.14 0 0 10813

Nem olvastad el amit írtam? Pont az utolsó sorban kérdezett dolgokra válaszoltam. Leírtam hol a határ, meg milyen programmal, ennél semmi sem lehet gyorsabb, mert 1 lemezfordulat alatt nem lehet 1 teljes sávnál többet beolvasni. Az 1541 lemez fordulatszáma 300/perc, ez 5/mp. Van olyan másolóprogram a delfinhez, ami a képernyő kikapcsolásával 2 mp alatt beolvas 10 sávot a C64-be, ez 10 lemezfordulat. Ez a leggyorsabb, ami fizikailag lehetséges, mert 1 fordulattal beolvas egy egész sávot. Ezt nem lehetséges felülmúlni semmivel. 35 sávra 7 mp read jön ki. Ez 171 KB/7 mp, 24,4 KB/s, ez 25000 byte/s. A delfinnél 11000 byte/s. Ha a delfin 27-szeres, akkor a másolóprogram 61-szeres.

Előzmény: Sheme (10811)
Sheme Creative Commons License 2018.04.13 0 0 10812

Most nem ugrik be, de valamelyik '89-es(?) Mikroszámítógép Magazinban volt szó a C-64-es - soros - gyors töltőkről. Ott 2 v 3 assembly utasítással, állítólag 10%-kal lehet növelni a fejléptetés sebességét, plusz a "trükk", h gyors töltés közben ne kelljen kikapcsolni a képernyőt, a sprite-okat és még a rasztertrükkök is menjenek.

 

(Megvan Excel táblában a lista, mi hol van, cím szerint, plusz egyéb nyalánkságok, de nem tudok PHP+MySQL-ül, időm sincs rá, de ha valaki segít, akkor lenne egy keresőmodul a "knowledgebase"-ben...)

Előzmény: siz (10809)
Sheme Creative Commons License 2018.04.13 0 0 10811

Igen, azt a táblázatot nézegettem.

 

Naná, a sávváltás is időbe telik, ezt nem feledtem el.

 

Köszi a fejtágítót! Abból indultam ki, h Joe Forster/STA megcsinálta a Star Commander-t, amin anno kísérleteztem. Sorosan olvasva nagyjából 90s kellett egy teljes lemezoldal beolvasásához Warp módban - tudom, ez =/= az Action Warp-jával, vagy a Heureka tempójával.

 

Aztán lepárhuzamosítottam két drive-omat - egy 1541-est és egy 1570-est - és kipróbáltam párhuzamosan. Nos, 1570-en 23s a teljes beolvasás - az Enter megnyomásától számítva, ami után a diskimage nevet megadja az ember. Tehát paralel olvastatva 4x-es a gyorsulás, innen gondoltam, kissé "halovány" a 25 (serial) -> 27 Delfin (paralel) olvasás.

 

Már így is szép teljesítmény az eltolt block-ok beolvasása 1->11 -> 2 ->12, s.í.t. olyan tempóban, ahogy meg van oldva a S.C.-ben a párhuzamos olvasás - nem mellesleg le is kell "kötni" a CPU figyelmét ehhez a tempóhoz, igaz, "csak" 25x a sebesség, párhuzamosan, szemben az Action-nel, sorosan.

 

A 69x-es sebességet pont abból számoltam ki, h az SC-vel 9p50s egy full disc copy, és - Isten nyugosztalja - Whitewolf mérése a 17s Copy-val, egy lemezoldal párhuzamosan olvasva a C-64-en a 256kByte-os RAM bővítőbe cca 8,5s. 590/8,5 = 69x-es tempó.

 

Azért nagyon kíváncsi vagyok, hol lehet a határ? Valaki készített ilyen - akár képernyő lekapcsolós - párhuzamos olvasós turbót?

 

 

Előzmény: Kováccss (10807)
Kováccss Creative Commons License 2018.04.12 0 0 10810

A fej sávváltást nem lehet kikerülni, mindegy hogy milyen rendszert használunk. Az 1541 emuknak is emulálniuk kell ezt, akkor is, ha e nélkül gyorsabb lenne. De a delfin és a többi, amit az előbb írtam ennél sokkal többről szólt, te csak 1 dolgot ragadtál ki. A szoftveres töltőkről írtam már, ezek nagyon ki vannak hegyezve időzítésileg, pláne ha a képernyőt nem kapcsolják ki, és még illegális utasítások is vannak benne. Ettől is bármikor lefagyhat a töltés, mert a CPU nem mindig hajtja végre az illegális utasításokat. Ezért jó a olyan CPU, ahol mind a 256 utasításnak eleve van jelentése. Volt ilyen már a 80-as években, kár hogy gyárilag nem fejlesztették idáig a C64-et. Sokminden könnyebb lett volna. A delfin a 80-as években azért volt jó fejlesztés, mert simán párhuzamos kábellel működött, nem kellett illegális kód, se képernyőkikapcsolás, se RAM bővítő, se 2 bites serial kábeles trükközések, se semmi, csak a 8 KB RAM, amiben dolgozott. Nem kellett minden művelet előtt átküldeni a floppy RAM-ba a gyorstöltő kódot, se a C64 RAM-ba elrakni a C64 oldali kódot, hogy ne íródjon felül, mert csak így működnek a szoftveres töltők. A delfinnél eleve minden ott van a gép és a floppy ROM-ban. Ha már bővíteni kell a gépet és a floppyt, akkor erre volt érdemes, a jiffy lassú. Ezért látni még ma is új gyártású delfin dolgokat. Nyilván megéri ezzel foglalkozni.

Előzmény: siz (10808)
siz Creative Commons License 2018.04.12 0 0 10809

És még egy, ami nem volt elég hangsúlyos az előzőnél: az adatátvitel lehet bármilyen gyors, a mechanikát mindig meg kell várni, az a legtöbb idő. A sávváltás is, illetve ha nem tudja egyszerre beolvasni a sávot, akkor a lemez körbefordulását is meg kell várni.

 

Ezért volt pár éve akkora durranás a Spindle nevű demo gyorstöltő, mert az (nem dokumentált, "illegális" opkódok segítségével) real-time megcsinálta a GCR dekódolást, így soros kábelen keresztül is gyakorlatilag holtidő nélkül tud tölteni.

Előzmény: siz (10808)
siz Creative Commons License 2018.04.12 0 0 10808

Azt azért ne felejtsük el (alapvetően ez inkább Sheme kollégának szól), hogy azzal az idővel is számolni kell, amíg a fej sávot vált.

Egy sávot be lehet olvasni egy menetben (GCR dekódolás nélkül), így ugye 25%-al több adatot kell olvasni, mert 4 bitet 5-ön tárol. Ehhez vagy plusz memória kell a meghajtóba, hogy egy sáv beférjen teljesen vagy pedig párhuzamos átvitel, ami fizikailag képes ugyanolyan sebességgel  továbbítani az adatokat, ahogyan az olvasófejről érkezik. Utána (sima load esetén) ezt még GCR dekódolni is kell, ezt teszi meg a Dolphin a floppy saját memóriájában. Ez másolásnál tök felesleges, mert ott úgyis csak visszaírod lemezre az adatokat, ahol vissza kell GCR kódolni. Ha van 256k memória a gépben, akkor egy lemezoldal befér GCR kódolva is, így ez a dekódolás/visszakódolás simán kihagyható. (Egyébként is, sőt ki is szokták, csak akkor gyakrabban kell lemezt cserélni)

Előzmény: Kováccss (10807)
Kováccss Creative Commons License 2018.04.12 0 0 10807

Gondolom ezt nézted. https://www.c64-wiki.com/wiki/Comparison_of_fast_loaders

A delfines sebessége úgy van beállítva, úgy van megírva a ROM tartalom mind a floppy, mind a C64 oldalán, hogy még biztonságosan tudjon olvasni hibázás és a képernyő kikapcsolása nélkül, és a floppy mechanikája is bírja. Ezért csak 27-szeres. Ennél gyorsabb olvasás is lehetséges. Az 1541 lemez fordulatszáma 300/perc, ez 5/mp. Van olyan másolóprogram a delfinhez, ami a képernyő kikapcsolásával 2 mp alatt beolvas 10 sávot a C64-be, ez 10 lemezfordulat. Ez a leggyorsabb, ami fizikailag lehetséges, mert 1 fordulattal beolvas egy egész sávot. Ezt nem lehetséges felülmúlni semmivel. 35 sávra 7 mp read jön ki. Ez 171 KB/7 mp, 24,4 KB/s, ez 25000 byte/s. A delfinnél 11000 byte/s. Ha a delfin 27-szeres, akkor a másolóprogram 61-szeres. A másolóprogram load rutinját át lehetne írni simán file loadra is, mint az alap delfinnél van, de minek? 48 KB-os programot nézve 2 mp lenne a load. Sima delfinnel meg 4,5 mp. Ki az, aki 2 mp-et tud várni, de 4,5-et már nem? A heureka, action replay, és egyéb szoftveres töltők csak megerőszakolják a hardvert a 2 bites loaddal. Elég egy kicsi instabilitás valahol, már nem is működnek, mert 1 pillanat alatt szétesik egy kicsit az időzítés, és máris load error lesz. Nekem volt sok ilyen az action replay 6-7 kártyával, kicsit gyengébb a lemez, vagy kopott, vagy a mechanika sokat használt, máris kilépett hibával. A delfinnél nincs ilyen, a párhuzamos átvitel miatt nem kell annyira kicentizni az időzítést. A szoftveres töltők még a sávon belüli blokksorrendre is érzékenyek. A különböző DOS-ok és meghajtók más-más rendszert használnak, amikor lemezre mentenek. Ha nem olyan sorrendben vannak a blokkok, mint amire írták a töltőt, ha kicsit is többet kell várni a következő blokkra, megint kilép hibával. A delfinnél nincs ilyen, mert 1 fordulatra is be tud olvasni egy egész sávot a másolóprogrammal. Az action warptöltője csak úgy működik, hogy előtte warpos módban lett elmentve a file, nem prg, hanem szemét lesz a kiterjesztése, de így a file hosszabb lesz. Ez saját fileformátum, így menti le a gyorsabb töltés miatt. A warppal elmentett file-t csak a warpos töltővel lehet betölteni, és csak a replay kártyával. A delfinnél nincs szükség saját formátumra. A 17 sec copy csak párhuzamos kábeles 1541-gyel működik, és csak min. 256 KB-os RAM bővítővel. A képernyőt kikapcsolja, így könnyebb időzíteni. A RAM bővítő DMA-jával könnyű gyorsnak lenni, mert akár 1 MB/s-gyel is lehet adatot mozgatni. A 69-szeres load sebesség lehetetlen, mert semmi sem lehet gyorsabb 61-szeresnél, fizikailag lehetetlen. Az alap delfinhez nem kell RAM bővítő, se képernyőkikapcsolás, simán tudja a 27-szeres sebességet. A delfines másolóprogrammal a képernyőt kikapcsolva máris eléri a fizikailag lehetséges max. sebességet. Az 1541-ben lévő 8 KB RAM-ot, és a párhuzamos kábelt másra is lehet használni, aki tudja hogyan kell. Akár kis floppy RAM bővítőnek is, vagy a nagy sebességű párhuzamos átvitelt más eszköz illesztésére is fel lehet használni, ami nem floppy. A párhuzamos átvitel a bővítőporton át is lehetséges, nem csak az user porton.

Előzmény: Sheme (10806)
Sheme Creative Commons License 2018.04.11 0 0 10806

Hát nem egészen azért van benne 8KByte RAM, mármint a drive-ban.

 

Amire szerettem volna felhívni a figyelmet, mint érdekességre, h a Heureka diskturbo - és az Action Warploader-je - a soros (már megint!) vonalon két bitenként az alaptempó 25x-ével képes tölteni, mindennemű hardware-s átalakítás NÉLKÜL, pusztán software-s megoldással. A Group Code Recording-et nagy valószínűséggel a C-64 hajtja végre. (Minden beolvasott 5 bitből fél byte-ot csinál, ami már tud értelmezni az alapgép.)

 

(A Data vonal mellett a Clock vonalat is használ(hat)ja a töltés során, bár nem világos számomra, akkor hogyan időzít? A Jiffy-t meg kenterbe veri, az a kanyarban sincs.)

 

A 8KByte RAM a drive-ba azért kell, mert egy track-et oda betölt, ott GCR-kódol és küldi át a C-64-be. Így is "csak" 27x-es tempóra képes, ami alig gyorsabb, mint a Heureka Loader. Ez meg hogy lehet?

 

Van az a 17sec copy, no ott nem egészen 8.5mp kell neki egy teljes lemezoldal beolvasásához - a RAM-bővítőbe. 683 block / 4 = 174 848 byte. Szintén párhuzamosan olvas, mint a Prologic / Dolphin (/Speed)DOS.

 

Egy lemezoldal beolvasása normál tempónál - thx Joe Forster/STA-nak a mérésért: 9 perc 50 mp  - 590mp, amihez képest a 8.5mp-es olvasás 69x-es(!!!) sebességnövekedést mutat. Kicsit több, mint 2.5x-es gyorsulás a Dolphin-hoz, és majdnem 3x-os a Heureka-hoz képest.

 

A lényeg, h alig gyorsabb a Dolphin (/Prologic) DOS a Heureka-hoz képest, holott 4x annyi bitet tud átnyomni - a User porton 8 bitet lehet leolvasni egyszerre, az IEC-n meg 2 bitet egy ciklusban, mégsem 4x gyorsabb a párhuzamos töltés a soros (már megint!) töltéshez képest.

 

Miért? Ez érdekes, nem?

Előzmény: Kováccss (10805)
Kováccss Creative Commons License 2018.04.07 0 0 10805

Az a lényege a delfinnek, hogy sokkal gyorsabb legyen, mint a jiffy, és más soros gyorstöltők. Ezért van benne 8 KB RAM és parallel kábel. A delfin 27-szeres, a jiffy csak 9-szeres loados.

Előzmény: Sheme (10804)
Sheme Creative Commons License 2018.04.06 0 0 10804

Nem is olyan gyenge ez a delfin! Jiffy-vel egy összehasonlítást láthattok.

(Igaz, paralel olvas, nem máshogy.)

 

Ékes német nyelven van, de ez ne tántorítson el!

Beviz.Elek Creative Commons License 2018.04.05 0 0 10803

Köszönöm a linket :) Azt elfelejtettem írni, hogy PDF formátumban megvan nekem a könyv, csak elég kényelmetlen így olvasni és visszalapozgatni fél fejezeteket egy-egy összefoglalóért... :) Ezt a törölt Gyakorikérdésekes posztomban írtam, most jut eszembe :)

Mr. Lipton Creative Commons License 2018.04.05 0 0 10802
Előzmény: Beviz.Elek (10801)

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!