Dreamcast felépítés

Rodrigo Copetti által készített gyakorlati elemzés

This is a volunteer translation of the original article. If you find any mistakes, please help improve it. Thanks!

Ha akadálymentesítő eszközöket vagy régi böngészőket használ, váltson a ‘klasszikus’ kiadásra.

eBook kiadás
Image

This article is also published on many digital book stores for the benefit of eBook readers. The new edition is DRM-free and can be read whilst offline. Furthermore, it's updated at the same pace as the website.

You can find the eBook at Amazon Kindle, Apple Books, Kobo and other stores. The profits contribute towards the improvement of current articles and the development of future ones.

For more information, please take a look at here.

Támogató képek

Modell

Image
The Dreamcast.
1998. November 29-én jelent meg Japánban, 1999. Szeptember 9-én Amerikában és 1999. Október 14-én Európában.

Alaplap

Image
Alaplap
A 'VA1' revízió.
Bár a hivatalos dokumentáció szerint 128 KB flash memóriával volt szerelve, valamilyen oknál fogva ezen az alaplapon ténylegesen egy 256 KB-os EEPROM chip van.
Az akkumulátor és a kontroller portok a 'Front panel' ('Előlap') elnevezésű kiegészítő nyomtatott áramkörön voltak.
Image
Az alaplap - a fontosabb alkatrészek feliratozva

Diagram

Image
Fő architektúra diagram
A lényeges adatbuszokon jelölve volt a buszszélesség és a sebesség is.

Bevezetés

A Sega Dreamcast számos újdonságokot vezetett be az elődjéhez (a Saturn-hoz) képest, hogy mind a játékfejlesztők, mind pedig a játékosok számára vonzó legyen. Bár ez volt a Sega utolsó kísérlete a játékkonzol-piac meghódítására, a Dreamcastben úttörő szerepet játszó technológiák közül néhány tovább élt a későbbi jelentősebb konzolokban is.

CPU

Nem meglepő módon a Sega ismét a Hitachit választotta a CPU kifejlesztésére. Ha már olvastad az előző cikket a Sega Saturn-ról, akkor, láss csodát, íme az SH processzor következő generációja: az SH-4 ami döbbenetes 200 MHz [1] sebességen futott.. Szóval, mi is olyan érdekes ebben a CPU-ban?

Extra meló

A játékkonzolok CPU-jának általános feladatai közé tartozik a játék logikájának kezelése, az ellenséget vezérlő MI futtatása és a GPU utasításokkal való ellátása. A Dreamcastban az SH-4 a grafikus futószalag nagy részében is szerepet kap, így a geometriai adatok feldolgozásában, például a perspektíva-transzformációk kiszámításában. Ennek eredményeként tartalmaz egy 128 bites SIMD egységet, amely képes a vektorműveleteket [2] gyorsítani.

A memória elérés gyorsítása

A CPU tartalmaz egy dedikált Memory Management Unit (Memória Kezelő Egységet) vagy ‘MMU’ egységet a virtuális címzéshez, ami azért hasznos, mert a CPU fizikai memória címtartománya 29 bit széles. Így négy TLB segítségével a programozók 32 bites címeket használhattak anélkül, hogy a teljesítmény csökkent volna.

Mivel csak 29 bitre volt szükség a címzésekhez, az fennmaradó három bit vezérelte a memóriavédelmet, a memória térkép váltását és a gyorsítótár kikerülését [3] [4].

Csak a programozón múlt, hogy használja ezeket a funkciókat vagy nem. Az erre a rendszerre szánt játékokhoz nem feltétlenül volt szükséges a memóriavédelem, és az MMU-t manuálisan kellett engedélyezni a rendszerindításkor.

Nem UMA, de…

Bár ezt a rendszert nem a szigorú Unified Memory Architcture (Egységes Memória Felépítés) szerint tervezték, mint egy jól ismert versenytársát, ettől függetlenül lehetővé teszi a GPU I/O elérést. Ez azt jelenti, hogy ha a CPU-nak olyan adatra volt szüksége, ami a dedikált memórián vagy a soros interfészen (ami szintén csatlakoztatva lehetett) kívül volt, akkor a GPU-t kellett megkérnie, és várnia is szükség esetén.

Különleges kérések

Ennek a CPU-nak volt egy egyedi funkciója is, amit Parallel I/O (Párhuzamos I/O)-nak vagy ‘PIO’-nak hívtak, és ami egyszerre több I/O címet tudott módosítani. A Sega úgy kötötte be ezeket, hogy a CPU a GPU videó módját tudta ezzel állítani (részletesen később foglalkozunk ezzel).

Grafika

A GPU csomag egy egyedi tervezésű chip volt, amit Holly-nak hívtak, és 100 MHz-en futott. A VideoLogic tervezte (amit ma már Imagination Technologies-nek hívnak), és az NEC gyártotta. A Holly 3D része teljes egészében a VideoLogic PowerVR2 volt (amit ‘PowerVR Series2’-nek és ‘CLX2’-nek is neveztek).

Image
Sonic Adventure (1999).

A VideoLogic a 3D motorjuk fejlesztésénél egy alternatív megközelítést alkalmazott, amit Tile-Based Deferred Rendering (Csempe Alapú Összefűzött Renderelés) -nek (TBDR) neveztek.

Ahelyett, hogy az egész képet egyben renderelték volna (ahogy azt a hagyományos Immediate Mode Render (Azonnali Renderelő)-k vagy ‘IMR’-ek csinálják [5]), a TBDR felosztotta a renderelendő képet több, ‘csempének’ nevezett részletre. Ezután az egyes csempéket külön-külön renderelte le, majd az eredményeket összefűzte a végső képpé [6].

Ez az előremutató fejlesztés érdekes előnyökkel járt:

Nem meglepő, hogy az Imagination ezt a hatékony technológiát alkalmazta a következő tervezése során, és a Series 4 PowerVR magok elképesztő mennyiségű eszközben voltak megtalálhatóak, beleértve az iPhone első generációját, az iPhone 3G-t, a Nokia N95-t, és a Dell Axim x51-et is.

Felépítés

Vessünk egy pillantást a Dreamcast GPU-jának két fő komponensére [7]:

Csempe-gyorsító

Image
A Tile Accelerator (Csempegyorsító) felépítése.

Mielőtt elkezdődik a renderelés, a Tile Accelerator (Csempe gyorsító)-nak nevezett részegység hajtja végre az előfeldolgozási feladatokat. Először is lefoglal több 32x32-es csempekockát, amelyekbe a geometria renderelésre kerül.

Ezután a csempe-gyorsító:

  1. Átveszi a CPU által kiadott geometriai adatokat és rajzparancsokat (DMA vagy hagyományos adatátvitel segítségével).
  2. Ezeket az adatok egy belső formátumra alakítja át.
  3. A koordináták alapján szétosztja a geometriai adatokat a csempekockák között. A levágott geometriai adatokat eldobja.
  4. Legenerálja az eredményül kapott Display List (Megjelenítési listák)-at.

Ezeket a megjelenítési listákat végül a PowerVR2 3D motor dolgozza fel.

A PowerVR2 mag

Image
A PowerVR2 mag felépítése.

Ez az a rész, ahol a grafika “életre kel”: a csempe-gyorsítótól kapott megjelenítési listák alapján a grafikus mag rendereli le egyetlen csempe geometriáját a belső képkocka puffer használatával. A folyamat a következő:

  1. A Image Synthesis Processor vagy “ISP” lekérdezi a primitíveket (háromszögeket vagy négyszögeket), és elvégzi a Hidden-Surface Removal műveletet a nem látható sokszögek eltávolítására. Miután megtörtént a Z-pufferek és a sablonpufferek kiszámolása, az adatok átmennek a Depth Testing (Mélység Teszt)-en, hogy elkerüljék az olyan sokszögek renderelését, amelyek más sokszögek mögött jelennének meg, valamint a Stencil Tests (Sablon teszt)-en, ami azokat a geometriai adatokat szűri ki, amelyek nem lennének láthatóak, ha egy 2D-s sokszög mögött helyezkednek el (ezt maszkolásnak is hívják).
    • Figyeljük meg, hogy ezeket a teszteket már a futószalag első állomásán elvégzik. Ezzel ellentétben a korábbi játékkonzolok késői z-bufferelést alkalmaztak, és a futószalag végén dobták el a geometriai adatokat. Az ISP által biztosított módszer megelőzi az olyan geometriai adatok feldolgozását, amelyek végül eldobásra kerülnének [8], így takarékoskodik az erőforrásokkal.
  2. A Texture and Shading Processor (Textúrázó és árnyékoló processzor) vagy ‘TSP’ végzi el a színezést, árnyékolást és más effekteket a csempekockákon.
    • A textúrák egészen az exportálásig nem kerülnek a csempekockára, így az esetleges túlrajzolás nem csökkenti a kitöltési teljesítményt.

Miután a műveletet befejeződik, a renderelt csempe a fő képpufferbe íródik a VRAM-ban. Ez a folyamat addig ismétlődik, amíg az összes csempe el nem készül. Ha ez megtörtént, a kapott képpuffert a Videókódoló felolvassa, és megjeleníti a videókimeneten keresztül.

A nagy kép

Eltekintve a nyilvánvaló felépítésbeli különbségektől is, a TSP sok olyan képességgel rendelkezett, amelyekből kiderül, hogy mennyire távol állt ez a játékkonzol a régi Saturn-tól. Íme néhány figyelemre méltó példa:

Egyre több részlet

A Holly így már közel tízszer több sokszöget tudott kirajzolni, mint az elődje. Itt van egy gyors előtte - utána összehasonlítás, ami bemutatja, hogy a modellterveknek már nem kellett olyan korlátozottaknak lennie, mint előtte. Nézd meg alaposabban minden oldalról!

DrótvázFelületTexturált
3D model
Sonic R (1997) a Saturnon:
286 háromszög (vagy 185 négyszög).
DrótvázFelületTexturált
3D model
Sonic Adventure (1999) a Dreamcasten:
1001 hármszög.

Videó módok

A videórendszert úgy tervezték, hogy többféle képernyőtípust és formátumot támogasson, ezért a videókódoló a kimeneti jelet egy egységes aljzatra küldte ki, az alábbi jeltípusokkal:

A Dreamcast nem tudja ezeket egyszerre kódolni, ezért a GPU és az audioprocesszor tartalmaz egy Image Mode (Kép Mód) nevű regisztert, amely koordinálja, hogy melyik videó/audió busz lesz aktiválva a kért jel létrehozásához. A CPU érzékeli a csatlakoztatott kábel típusát (a videócsatlakozó aktív “kiválasztó bitjeinek” ellenőrzésével), és a GPU-ba írja a szükséges értékeket. Legvégül a GPU a szükséges beállításokat továbbítja az audióprocesszornak.

Mivel a VGA szigorúan progresszív típusú jel (szemben a hagyományos váltottsoros jelekkel), néhány kompatibilitási felmerül olyan játékoknál, amelyeket csak interlaced videóhoz terveztek. Ezek kódjában direkt szerepel, hogy a játék nem működik VGA-n, így a CPU blokkolja a játékot, amíg a felhasználó ki nem cseréli a VGA-kábelt egy másik típusra.

Audió

A hangfunkciókat a Yamaha által tervezett AICA nevű egyedi chip kezeli, amely a Saturnban használt SCSP továbbfejlesztett változata, és négy komponensből áll:

A fejlesztés megkönnyítése érdekében a hivatalos SDK több hang eszközmeghajtót is tartalmazott a különböző igényekhez (szekvenálás, dekódolás stb.).

Fejlődés

A Mega Drive/Genesis óta nagyon messzire jutottunk. Ahhoz, hogy megmutassuk, mekkora előrelépés történt a hangszintézis terén, íme egy példa két játékra, az egyik Mega Drive-on, a másik Dreamcaston, amelyek ugyanazt a kompozíciót használták:

Sonic 3D Blast (1996) a Mega Drive-on.
Az előd FM-szintézist alkalmaz a hangjelek menet közbeni előállításához.
Sonic Adventure (1999) a Dreamcaston:
Az új audió alrendszer gond nélkül feldolgozza a PCM-mintákat.

Az FM chip programozása helyett a Sonic Adventure zeneszerzői házon belül készítették el a hangsávot, majd a CRI Middleware által kifejlesztett “ADX” veszteséges formátumba kódolták. Emiatt van az, hogy a 64 PCM-csatornából csak kettőt használ (sztereó).

Az ADX tömörítés lehetővé tette, hogy a játék közvetlenül a GD-ROM-ról folyamatosan olvassa és dekódolja az adatokat a Sound IC-re anélkül, hogy a memória vagy a sávszélesség elfogyna. Az illesztőprogram sokféleképpen megvalósítható, mivel többféle megközelítés létezik a fő CPU és az ARM7 közötti terhelés elosztására.

Életben maradni

Valamért ez a chip felelős egy Real Time Clock (Valósidejű óra) (RTC) biztosításáért is, amit a BIOS használ - ez egy óraelemhez is csatlakozik, hogy táp nélkül is működjön.

Operációs rendszer

A 2 MB “System ROM” tárolja a BIOS-t, amely a konzol bekapcsolásakor elindítja a játékot vagy egy kis keretprogramot.

A BIOS olyan rutinokat is tartalmaz, amelyeket a játékok az I/O funkciók egyszerűsítésére használnak [9], mint például a GD-ROM meghajtóról való olvasás.

Keretprogram

Ha nincs érvényes játéklemez behelyezve, a konzol elindítja a grafikus keretprogramot.

Image
A keretprogram lemez nélküli indítás esetén.

Ez egy egyszerű grafikus felhasználói felületet tartalmaz, amely lehetővé teszi a felhasználó számára olyan alapvető, de szükséges feladatok elvégzését, mint:

  • A játék elindítása (ha még nem történt meg).
  • A VMU-ban lévő mentett adatok kezelése (erről az eszközről részletesebben kicsit később!).
  • Zene lejátszása, ha audió CD van behelyezve.
  • Néhány beállítás megváltoztatása (dátum, idő, hang, stb.).

Windows CE

A Dreamcast bejelentése óta lehetett azt hallani, hogy a konzol képes a Windows CE futtatására: ez a Windows egy lecsupaszított verziója, amelyet beágyazott eszközökön való használatra terveztek. Ez egy kicsit félrevezető volt, tekintve, hogy egyes felhasználók azt várták, hogy a konzoljukon egy teljes Windows CE asztali környezet fog futni.

Image
A Windows CE logó a ház elejére nyomva.

Valójában ennek az “operációs rendszernek” a célja nagyon hasonló volt ahhoz, amit a Nintendo a a Nintendo 64 rendszerrel tett: a programozók számára egy jelentős absztrakciós réteget biztosítani bizonyos műveletek egyszerűsítésére.

A Microsoft együttműködött a Segával, hogy a Windows CE-t a Dreamcastra is eljuttassa [10]. Az eredmény egy olyan lecsupaszított Windows CE lett, amely a grafikához, hanghoz és hibakereséshez szükséges minimális komponensekkel rendelkezett. Ez magában foglalta a Microsoft csúcs integrált fejlesztőkörnyezetét, a Visual Studio-t is, amit a fejlesztők használhattak a játékokhoz.

Néhány fejlesztő nagyon vonzónak találta ezt a lehetőséget. Mivel a CE-hez mellékelt multimédia keretrendszer nem más volt, mint a DirectX 6, a kor több ezer PC-s játéka elméletileg könnyen átültethető volt a Dreamcastra…

A Dreamcast és a hagyományos PC közötti tervezési különbségek azonban túl nagyok voltak ahhoz, hogy figyelmen kívül lehessen hagyni őket [11]. Emellett ennek a rendszernek a beágyazása megnövelte a játékok betöltési idejét (elvégre az operációs rendszert egy lemezről kellett betölteni), és a Windows CE történetesen a Dreamcast erőforrásainak jelentős részét felemésztette (nem meglepő módon a PC-k is szenvedtek már ettől).

Végül a “Windows CE for Dreamcast” csak egy újabb SDK volt a fejlesztők számára (általában Dragon SDK néven emlegették). Mindazonáltal jelentős számú Dreamcast játék fejlesztője választotta végük a Windows API-kat és a DirectX-et.

I/O

A GPU tartalmazott még egy modult, ami az I/O nagy részét kezelte, ez volt az úgynevezett System Bus. A következő interfészeket biztosította:

Játékok

A fejlesztés legnagyobbrészt C-ben vagy C++-ban folyt. Eleinte a C volt az ajánlott választás, mivel a rendelkezésre álló C++ fordítók kezdetben nagyon korlátozott funkcionalitásúak voltak.

A Sega fejlesztői hardvert is biztosított egy PC-szerű torony formájában, amelyet Sega Katana Development Box-nak hívtak. Ez egy Dreamcast hardver volt, bővített I/O képességekkel a fejlesztés megkönnyítése érdekében. Tartalmazott egy CD-t is, amelyen a hivatalos Katana SDK és egy Windows 98-at futtató PC-re telepíthető eszközök voltak.

Abban az esetben, ha a fejlesztők inkább a Dragon SDK-t választották, a DirectX 6.0 és a Visual C++ 6.0 is elérhető volt számukra.

Adattároló

A játékok a GD-ROM-on voltak, amik igazából csak nagyobb pitsűrűségű CD-ROM-ok voltak (a kapacitás elérte az 1 Gigabyte-ot). A sebesség 12x-es, ami nem gyenge a Saturn 2x CD olvasójához képest.

Online platform

A Dreamcastot egy beépített modem egységgel szállították, amellyel a játékok “behívhattak” egy betárcsázós szolgáltatásba az online játékhoz. A Sega két ilyen szolgáltatást nyújtott: a SegaNet-et (Amerikában és Japánban) és a Dreamarena-t (ez volt az európai megfelelője).

A játékosok a szolgáltatáshoz a DreamKey, egy extra lemez segítségével regisztráltak, amelyet egyes játékokhoz mellékeltek. A DreamKey egy webböngészőt biztosított, amivel regisztrálni lehetett egy felhasználói fiókot. Kezdetben a DreamKey a régiótól függően előre konfigurált szolgáltatásként jelent meg, de a későbbi módosítások lehetővé tették a felhasználók számára, hogy megváltoztassák az internetszolgáltató beállításait, és így bármelyikhez csatlakozhassanak.

Egy Dreamcast márkájú billentyűzet és egér is megvásárolható volt, ha a felhasználó PC-stílusban szeretett volna netezni.

Sajnálatos módon a SegaNet és a Dreamarena alig két évvel a megjelenés után megszűnt. Így azok a játékok, amelyek kizárólag ezekre támaszkodtak, használhatatlanná váltak, kivéve, ha az ilyen szolgáltatásokat extra eszközökkel emulálják (mint például a DreamPi, egy Raspberry Pi-re telepíthető rendszer, amely a felhasználói közösség által fenntartott szerverek segítségével replikálja az eredeti Sega szolgáltatásokat).

Interaktív memóriakártya

A Dreamcast egy másik innovatív funkciója a Vizuális memóriaegység vagy “VMU” volt. A kontrollerhez csatlakozott, és azon kívül, hogy memóriakártyaként is szolgált, egy teljes értékű eszköz volt, ami a következőket tartalmazta [12]:

Image
A VMU lecsatlakoztatva a kontrollerről.
Image
A kontroller a VMU nélkül.
Image
A kontroller csatlakoztatott VMU-val.
  • Sanyo LC86K87: Egy 8-bites, alacsony fogyasztású CPU.
  • 32x48 monkróm LCD négy további ikonnal: ezeket az XRAM (external RAM) 196 byte-jával lehetett vezérelni (mint frame-buffer).
  • Két soros csatlakozó: Egy ki és egy bemenet.
  • Hat fizikai gomb: Akkor használatos, amikor a VMU nem csatlakozott a kontrollerre.
  • 16 KB Mask-ROM: a BIOS-IPL-t tárolja.
  • 64 KB Flash: 32 KB egy (a konzolról átvett) program tárolására, a másik 32 KB pedig a Dreamcast mentéseinek tárolására.
  • 512 byte RAM: 256 byte a rendszer számára van fenntartva, így csak 256 byte áll rendelkezésre a program számára.

A VMU két módban tudott működni:

Anti-Piracy & Homebrew

A teljesen egyedi GD-ROM formátum használata megakadályozta a játékok engedély nélküli másolását (és más konzolokon való futtatását). A Dreamcast-játékok régiózárral is el vannak látva, ami azt jelenti, hogy a konzol nem hajlandó futtatni egy más földrajzi régióba szánt játékot.

… és a legyőzése

A gyarkorlatban ezek a kalózkodást megakadályozó technikák hihetetlenül haszontalanaok voltak, ugyanis a Sega nyitva hagyott egy hatalmas hátsó bejáratot: a MIL-CD-t. A Music Interactive Live-CD vagy ‘MIL-CD’ egy olyan formátum, amelyet a Sega hozott létre, hogy egy Audió CD-t interaktív programokkal bővítsen… és a Dreamcast kompatibilis volt ezzel [13].

Így végül a nem engedélyezett lemezek (csalások, filmlejátszók stb.) MIL-CD-nek álcázták magukat, hogy a Sega jóváhagyása nélkül fussanak a konzolon. Később a különböző hacker csoprtok kivesézték ezt a biztonsági rést, és találtak egy megoldást a kalózjátékok hagyományos CD-ROM-ról történő indítására. Ez az kalóz ISO-k megállíthatatlan hullámát indította el a neten.

Néhány probléma felmerült azért: Bár a GD-ROM-ok egy gigabájtnyi adatot képesek tárolni, a CD-ROM-okra csak ~700 MB fért el. Vajon hogyan tudták a “ripperek” a nagyobb játékokat úgy lekicsinyíteni, hogy elférjenek egy CD-n? A zene és a grafika újratömörítésével, amíg el nem fért. Még az is előfordult, hogy két lemezre szétszedték a játékokat. Végül is a játékadatok már nem egyetlen összefüggő bináris (mint a régi cartridge-okon), hanem hierarchikusan, fájlokba és könyvtárakba vannak szervezve.

Ennyi volt, srácok

Image
Egy Dreamcast, amit szereztem, hogy mindent leírhassak róla ide.
A korához képest nem is olyan rossz!

Remélem, tetszett ez a cikk. Az utolsó egyetemi évem elején fejeztem be az írását.

Mostantól valószínűleg elég elfoglalt leszek, de nagyon élvezem ezeket a cikkeket írni, így remélhetőleg néhány héten belül megkapjátok a következőt!

Addig is:
Rodrigo

Hozzájárulás

Ez a cikk a Konzolok Architektúrája sorozat része. Ha érdekesnek találta, kérjük, fontolja meg a támogatást. A hozzájárulását eszközök és erőforrások beszerzésére fordítjuk, amelyek segítenek javítani a meglévő cikkek minőségét és az elkövetkezőket.

Donate with PayPal
Become a Patreon

Megvásárolhatja az eBook kiadást is angolul. A profitot adományként kezelem.

Image

Ebben a cikkben követjük a kívánatos eszközöket és a legújabb beszerzéseket:

### Interesting hardware to get (ordered by priority)

- Nothing else, unless you got something in mind worth checking out

### Acquired tools used

- A Dreamcast console with controllers and VMUs (£40)
- A game (Sonic Adventure, £9)

Alternatívaként segíthet a javaslatok megfogalmazásával és/vagy fordítások hozzáadásával.

Copyright and permissions

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But you have to respect the license and reference the article properly. Please take a look at the following guidelines and permissions:

Article information and referencing

For any referencing style, you can use the following information:

For instance, to use with BibTeX:

@misc{copetti-dreamcast,
    url = {https://www.copetti.org/writings/consoles/dreamcast/},
    title = {Dreamcast Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2019}
}

or a IEEE style citation:

[1]R. Copetti, "Dreamcast Architecture - A Practical Analysis", Copetti.org, 2019. [Online]. Available: https://www.copetti.org/writings/consoles/dreamcast/. [Accessed: day- month- year].
Special use in multimedia (Youtube, Twitch, etc)

I only ask that you at least state the author’s name, the title of the article and the URL of the article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you may state either the author’s name or URL of the article at the bottom of the image, and then include the complete reference in the video description. In other words, for any resource used from this website, let your viewers know where it originates from.

This is a very nice example because the channel shows this website directly and their viewers know where to find it. In fact, I was so impressed with their content and commentary that I gave them an interview 🙂.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.

Third-party publishing

If you are interested in publishing this article on a third-party website, please get in touch.

If you have translated an article and wish to publish it on a third-party website, I tend to be open about it, but please contact me first.

Források / További olvasás

Anti-Piracy

CPU

Játékok

Grafika

Operációs rendszerek

Fotográfia

Rodrigo Copetti

Rodrigo Copetti

Remélem tetszett ez a cikk! Ha többet szeretne megtudni a szerzőről kattintson ide és ha szeretné támogatni őt, kattintson ide

rsslinkedintwittergithub facebookreddit