Dit artikel beschrijft het proces van het porten van DOOM naar twee budget handheld consoles die worden verkocht door Action: de '104 Games' en de 'PAC-MAN'. Het project is gerealiseerd zonder hardwarematige wijzigingen, waarbij de standaardfirmware is vervangen via bestaande SWD-pads op de printplaat.
Technische kernpunten:
- Hardware: Beide consoles maken gebruik van een ongemerkte QFN48 SoC (geïdentificeerd als STAR-MC1/Cortex-M33 compatibel) met 280 KB SRAM en 4 MB flashgeheugen.
- Software: De port is gebaseerd op de GBADoom engine. Vanwege geheugenbeperkingen is het WAD-bestand getrimd tot slechts één map (E1M1).
- Status: De game is speelbaar met een acceptabele framerate. Er zijn echter beperkingen: er is geen geluid en de kloksnelheid is beperkt tot ~62 MHz om crashes bij XIP-uitvoering te voorkomen.
Board-specifieke details: Hoewel de SoC identiek is, verschillen de consoles in knoppenconfiguratie en scherminstellingen. Bij de PAC-MAN console moest beeldrotatie in software worden geïmplementeerd omdat het displaypaneel bepaalde hardwarematige rotatiecommando's negeerde.
De repository biedt volledige instructies voor het compileren van de firmware met arm-none-eabi-gcc en tools voor het flashen van de images, inclusief een waarschuwing om altijd eerst een back-up van de originele firmware te maken.
DOOM op twee budget-gameconsoles van Action
Prebuilt binaries zijn beschikbaar op de releases-pagina: één image per console plus het WAD-bestand, die bij elke push opnieuw worden gebouwd.
Beide consoles maken gebruik van dezelfde naamloze QFN48 SoC. Er is geen datasheet, SDK of documentatie van de fabrikant beschikbaar. Alle informatie in deze repository — de registerkaart, de panel-init sequenties en de knoppenmatrices — is gereconstrueerd uit de twee standaardfirmwares en geverifieerd op de apparaten.
De consoles
| Kenmerk | 104 Games | PAC-MAN |
|---|
| Artikelnummer | 3217060 | 3219232 |
| Prijs | EUR 5,95 | EUR 12,95 |
| Printplaat (Board) | GC83-250107-V3 | GC86-0617-V1 |
| Knoppen | 11 - d-pad, vier rechts, MENU, START, volumeschuif | 8 - d-pad, A, B, VOL+, VOL- |
| Standaard firmware | FlyThings/ZKSWE met een NES-emulator | Gelicentieerde Bandai Namco arcade-emulator, C++ |
| Scherm (Panel) | 320x240, landscape in de behuizing | 320x240, 90 graden gedraaid in de behuizing |
| Build commando | make | make BOARD=pacman |
Status van de implementatie
Wat werkt
Op beide consoles:
- DOOM (shareware E1M1) met een speelbare framerate.
- Elke knop — elf op de 104 Games, acht op de Pac-Man.
- Correcte kleuren en oriëntatie bij een koude start, zonder afhankelijkheid van wat de standaardfirmware heeft achtergelaten.
- Flashen en volledig herstel via SWD; geen solderwerk nodig buiten de debug-draden.
Wat werkt niet
Beide consoles delen deze beperkingen vanwege de SoC:
- Geen geluid. De hardware is volledig in kaart gebracht en er is een driver plus mixer aanwezig in de boom (niet gebouwd): een DAC op
0x40012C00 gevoed door DMA. Het lukt om een hoorbare toon te produceren, maar de DMA-reload herstelt alleen het bronadres en niet de overdrachtstelling, waardoor het afspelen stopt na één buffer. Zie docs/HARDWARE.md voor de exacte status en mogelijke volgende stappen.
- Klokfrequentie van ~62 MHz in plaats van 194 MHz. De PLL-sequentie is volledig reverse-engineered en aanwezig in de code, maar deze laat de SoC vastlopen. Deze firmware wordt uitgevoerd via XIP vanuit de externe flash; wanneer de klok verspringt, houdt de timing van de flash-interface niet meer stand, waardoor de volgende instructie-fetch faalt. De software zou vanuit RAM moeten draaien. Zie de uitgebreide opmerking in
firmware/sdk/clock.c.
- De screen wipe ziet er onjuist uit. Front- en back-buffer delen geheugen om 38 KB te besparen.
- Beperkt geheugen voor maps. Er past slechts één map naast de firmware in de 4 MB, waardoor het WAD-bestand hier is getrimd tot E1M1.
De gedeelde SoC
De ongemerkte QFN48 (U2) en de Zbit 25Q32 ernaast vormen hetzelfde paar op beide printplaten.
- Core: STAR-MC1 (Arm China), ARMv8-M Mainline, Cortex-M33 compatibel, CPUID
0x631F1320. Fabrikant niet geïdentificeerd.
- RAM: 280 KB SRAM op
0x20000000 (gemeten — een read op 0x20046000 reset de chip).
- Flash: Zbit ZB25VQ32, 4 MB, W25Q command compatibel, memory-mapped op
0x08000000.
- Boot ROM: 32 KB on-chip, byte-identiek op beide consoles — dezelfde mask ROM.
- Klok: 16 MHz vanuit de bootloader, ~62 MHz na onze init.
- Voeding: 3x AAA batterijen.
De peripheral base addresses lijken exact op die van een STM32L4 (RCC op 0x40021000, GPIO op 0x48000000). De register-layouts verschillen echter: GPIO-input zit op +0x0C, BSRR op +0x14 en pull-config op +0x08. Het gebruik van een STM32 SDK is hier niet effectief.
Omdat de boot ROM identiek is, werken de flash-tools ongewijzigd op beide borden. Alles daarboven verschilt: de twee standaardfirmwares delen geen enkele code. Volledige details staan in docs/HARDWARE.md.
104 Games Console
Standaard firmware: FlyThings by ZKSWE (Power by FlythingLite, unsupport platform, please contact www.zkswe.com) met een NES-emulator. Deze string is de beste aanwijzing over wie deze chip daadwerkelijk produceert.
Knoppenconfiguratie
Uitgelezen uit de standaard key scan en bevestigd via inputregisters:
| Knop | Pin | Knop | Pin |
|---|
| D-pad up | PB7 | right 1 (top) | PA12 |
| D-pad down | PB5 | right 2 | PC6 |
| D-pad left | PB6 | right 3 | PA11 |
| D-pad right | PB4 | right 4 (bottom) | PB0 |
| START | PC8 | MENU | PC7 |
| VOL | PA0 / PB2 / PC13 (3-position slider) | | |
De bitvolgorde die de standaardfirmware bouwt is een NES joypad byte, wat exact past bij een NES-emulator. De twee turbo-knoppen zijn daar OR'ed op A en B; hier worden ze L and R, omdat DOOM daar betere toepassingen voor heeft. Het scherm wordt in landscape aangestuurd en PA8 dient als backlight.
PAC-MAN Console
Board: GC86-0617-V1. Let op de silkscreen rechtsboven: KEY-VOL- and KEY-VOL+, de twee knoppen die SELECT en START worden.
Standaard firmware: een gelicentieerde Bandai Namco arcade emulator ("Featuring Moo Emulation", build V.289.1 Aug 12 2025) geschreven in C++. Deze shares niets met de andere board, dus er kon niets direct uit de disassembly worden overgenomen.
Knoppenconfiguratie
| Knop | Pin | Knop | Pin |
|---|
| D-pad up | PB7 | A | PB0 |
| D-pad down | PB5 | B | PA11 |
| D-pad left | PB6 | VOL+ → START | PA0 |
| D-pad right | PB4 | VOL- → SELECT | PB2 |
De bedrading bleek identiek aan het 104 Games board — dezelfde pinnen dragen de d-pad, A en B. Deze console gebruikt simpelweg minder van deze pinnen, en zijn twee volumeknoppen zitten op pinnen die de andere console gebruikte voor de volumeschuif. VOL+ en VOL- worden START en SELECT omdat DOOM deze nodig heeft en er niets anders over is; er is geen strafe-toets aanwezig.
Technische bijzonderheden
Twee zaken die veel tijd kostten:
- PA8 is hier de panel RESET, niet de backlight. Dit is het verschil tussen een port die werkt en een die alleen lijkt te werken. Het aanhouden van de 104 Games logica (hoog houden) betekende dat de controller nooit werd gereset: bij een koude start kwam deze ongedefinieerd omhoog en toonde een witte raster terwijl de firmware init-gegevens en een beeld stuurde. Het zag er verder goed uit omdat flashen de stroom niet onderbreekt en de setup van de standaardfirmware bewaard bleef. De standaardcode pulseert dit laag op
0x08016B98 en wacht voordat er iets wordt verzonden.
- Het paneel negeert MADCTL. Vier waarden zijn geprobeerd, inclusief een schone koude start met volledige init, en één waarbij de BGR-bit was uitgeschakeld om rood en blauw te wisselen. Niets veranderde. Daarom gebeurt de rotatie in software voordat het naar het paneel gaat, wat één extra pass over een line buffer kost die sowieso al wordt opgebouwd.
De panel init (78 bytes, 25 commando's) is statisch uit de standaardfirmware gehaald. Het is dezelfde controller-familie als het andere bord maar met andere parameters: MADCTL 0x28 in plaats van 0xE8, een extra 0x21 voor display inversie, en eigen timing-, power- en gammawaarden. Deze gammacurves zijn de reden waarom het beeld donkerder leek terwijl het nog op de standaardconfiguratie draaide.
Bouwen
Vereisten: arm-none-eabi-gcc (getest met 10.3.1) and make.
cd firmware
make # -> build/action104/doom.bin
make BOARD=pacman # -> build/pacman/doom.bin
Board-specifieke pinnen, panel init en de knoppenkaart staan in firmware/boards/<board>/board.h. Geen enkel ander deel van de firmware weet voor welke console er gebouwd wordt. Voor het toevoegen van een derde console moet een dergelijk bestand worden geschreven; docs/PORTING.md beschrijft hoe de huidige twee zijn uitgewerkt.
Flashen
Het proces is identiek voor beide consoles, afgezien van het image dat geschreven wordt. Lees eerst docs/FLASHING.md, specifiek het deel over het dumpen van de standaardfirmware.
Korte versie:
- SWD aansluiten: Twee pads naast de SoC, plus ground en VTref. Op het 104 Games board zijn deze gelabeld als
SWC/SWD; op het Pac-Man board zijn dit de pinnen gemarkeerd in de foto in docs/FLASHING.md.
- Standaardfirmware opslaan:
``bash cd tools/flashwriter && make && cd .. python flash.py read stock_backup.bin 0x08000000 0x400000 `` Sla deze stap niet over. Dit is de enige manier om terug te keren naar de originele console.
- DOOM en de WAD schrijven:
``bash python flash.py write ../firmware/build/action104/doom.bin 0x08004000 python flash.py write ../wad/doom1_e1m1.wad 0x08110000 ` Gebruik build/pacman/doom.bin` voor de andere console; het WAD-bestand is hetzelfde.
De bootloader op 0x00000000 blijft ongemoeid en blijft werken — deze springt naar 0x08004000. Secure boot is niet actief: de bootloader valideert niets, wat is geverifieerd via breakpointing.
Herstel
Terugzetten van de originele firmware:
python flash.py write stock_backup.py 0x08000000
Als een foutieve flash ervoor zorgt dat een console onbereikbaar is via SWD, kan tools/rescue.py de core vangen in het venster tussen het inschakelen en de crash. Zie docs/FLASHING.md.
Structuur van de repository
.github/workflows/: CI die beide consoles bouwt en een release publiceert.firmware/: De DOOM-firmware, standalone build.boards/: Per board pinnen, panel init, knoppenkaart (action104/ en pacman/).sdk/: Klok, LCD, input, mailbox, startup.port/: Platformlaag van GBADoom.GBADoom/: Vendored engine + engine-patches.diff.tools/: Tools voor flashen (flash.py, de RAM writer, rescue.py).wad/: Getrimde shareware WAD (alleen E1M1).dumps/: Standaardfirmware en boot ROM per console.docs/: Hardware-notities, flashing guide, porting guide.images/: Hardwarefoto's en productvermeldingen.
Credits
- doomhack/GBADoom — De DOOM engine waarop deze port is gebouwd, zelf gebaseerd op prboom. GBADoom was de juiste keuze omdat het de WAD via een pointer direct uit de cartridge ROM leest, wat perfect aansluit op het memory-mapped SPI flash van deze consoles. Upstream commit
89097b3. Zes bestanden zijn gewijzigd (heap size, time base, missing include en drie aanpassingen voor de enkele map); deze staan in firmware/GBADoom/engine-patches.diff.
- id Software — DOOM. Het WAD-bestand hier is de freely redistributable shareware IWAD, getrimd tot één map. De DOOM source code is GPL v2.
- atc1441/TXW818WalkieTalkieDoom — Referentie voor het krijgen van GBADoom op een kleine Cortex-M met een SPI panel.
- NordicPlayground/nrf-doom — Nuttige vergelijking voor geheugenbudgettering.
Productfoto's van de consoles zijn screenshots van de eigen shop-pagina's van Action.
Licentie
GPL v2, overgenomen van GBADoom en de DOOM source release. Zie LICENSE. De inhoud van dumps/ is niet GPL maar behoort toe aan de leveranciers; deze is opgenomen zodat het reverse engineering proces gecontroleerd kan worden. Zie dumps/README.md.
Disclaimer
Deze software overschrijft de firmware van een apparaat dat je hebt gekocht. Dit is herstelbaar als je de back-up in stap 2 hebt gemaakt, en niet als je dat niet hebt gedaan. Niemand verbonden met Action of de fabrikanten was betrokken bij dit project.
DOOM op twee budget-gameconsoles van Action
Prebuilt binaries zijn beschikbaar op de releases-pagina: één image per console plus het WAD-bestand, die bij elke push opnieuw worden gebouwd.
Beide consoles maken gebruik van dezelfde naamloze QFN48 SoC. Er is geen datasheet, SDK of documentatie van de fabrikant beschikbaar. Alle informatie in deze repository — de registerkaart, de panel-init sequenties en de knoppenmatrices — is gereconstrueerd uit de twee standaardfirmwares en geverifieerd op de apparaten.
De consoles
| Kenmerk | 104 Games | PAC-MAN |
|---|
| Artikelnummer | 3217060 | 3219232 |
| Prijs | EUR 5,95 | EUR 12,95 |
| Printplaat (Board) | GC83-250107-V3 | GC86-0617-V1 |
| Knoppen | 11 - d-pad, vier rechts, MENU, START, volumeschuif | 8 - d-pad, A, B, VOL+, VOL- |
| Standaard firmware | FlyThings/ZKSWE met een NES-emulator | Gelicentieerde Bandai Namco arcade-emulator, C++ |
| Scherm (Panel) | 320x240, landscape in de behuizing | 320x240, 90 graden gedraaid in de behuizing |
| Build commando | make | make BOARD=pacman |
Status van de implementatie
Wat werkt
Op beide consoles:
- DOOM (shareware E1M1) met een speelbare framerate.
- Elke knop — elf op de 104 Games, acht op de Pac-Man.
- Correcte kleuren en oriëntatie bij een koude start, zonder afhankelijkheid van wat de standaardfirmware heeft achtergelaten.
- Flashen en volledig herstel via SWD; geen solderwerk nodig buiten de debug-draden.
Wat werkt niet
Beide consoles delen deze beperkingen vanwege de SoC:
- Geen geluid. De hardware is volledig in kaart gebracht en er is een driver plus mixer aanwezig in de boom (niet gebouwd): een DAC op
0x40012C00 gevoed door DMA. Het lukt om een hoorbare toon te produceren, maar de DMA-reload herstelt alleen het bronadres en niet de overdrachtstelling, waardoor het afspelen stopt na één buffer. Zie docs/HARDWARE.md voor de exacte status en mogelijke volgende stappen.
- Klokfrequentie van ~62 MHz in plaats van 194 MHz. De PLL-sequentie is volledig reverse-engineered en aanwezig in de code, maar deze laat de SoC vastlopen. Deze firmware wordt uitgevoerd via XIP vanuit de externe flash; wanneer de klok verspringt, houdt de timing van de flash-interface niet meer stand, waardoor de volgende instructie-fetch faalt. De software zou vanuit RAM moeten draaien. Zie de uitgebreide opmerking in
firmware/sdk/clock.c.
- De screen wipe ziet er onjuist uit. Front- en back-buffer delen geheugen om 38 KB te besparen.
- Beperkt geheugen voor maps. Er past slechts één map naast de firmware in de 4 MB, waardoor het WAD-bestand hier is getrimd tot E1M1.
De gedeelde SoC
De ongemerkte QFN48 (U2) en de Zbit 25Q32 ernaast vormen hetzelfde paar op beide printplaten.
- Core: STAR-MC1 (Arm China), ARMv8-M Mainline, Cortex-M33 compatibel, CPUID
0x631F1320. Fabrikant niet geïdentificeerd.
- RAM: 280 KB SRAM op
0x20000000 (gemeten — een read op 0x20046000 reset de chip).
- Flash: Zbit ZB25VQ32, 4 MB, W25Q command compatibel, memory-mapped op
0x08000000.
- Boot ROM: 32 KB on-chip, byte-identiek op beide consoles — dezelfde mask ROM.
- Klok: 16 MHz vanuit de bootloader, ~62 MHz na onze init.
- Voeding: 3x AAA batterijen.
De peripheral base addresses lijken exact op die van een STM32L4 (RCC op 0x40021000, GPIO op 0x48000000). De register-layouts verschillen echter: GPIO-input zit op +0x0C, BSRR op +0x14 en pull-config op +0x08. Het gebruik van een STM32 SDK is hier niet effectief.
Omdat de boot ROM identiek is, werken de flash-tools ongewijzigd op beide borden. Alles daarboven verschilt: de twee standaardfirmwares delen geen enkele code. Volledige details staan in docs/HARDWARE.md.
104 Games Console
Standaard firmware: FlyThings by ZKSWE (Power by FlythingLite, unsupport platform, please contact www.zkswe.com) met een NES-emulator. Deze string is de beste aanwijzing over wie deze chip daadwerkelijk produceert.
Knoppenconfiguratie
Uitgelezen uit de standaard key scan en bevestigd via inputregisters:
| Knop | Pin | Knop | Pin |
|---|
| D-pad up | PB7 | right 1 (top) | PA12 |
| D-pad down | PB5 | right 2 | PC6 |
| D-pad left | PB6 | right 3 | PA11 |
| D-pad right | PB4 | right 4 (bottom) | PB0 |
| START | PC8 | MENU | PC7 |
| VOL | PA0 / PB2 / PC13 (3-position slider) | | |
De bitvolgorde die de standaardfirmware bouwt is een NES joypad byte, wat exact past bij een NES-emulator. De twee turbo-knoppen zijn daar OR'ed op A en B; hier worden ze L and R, omdat DOOM daar betere toepassingen voor heeft. Het scherm wordt in landscape aangestuurd en PA8 dient als backlight.
PAC-MAN Console
Board: GC86-0617-V1. Let op de silkscreen rechtsboven: KEY-VOL- and KEY-VOL+, de twee knoppen die SELECT en START worden.
Standaard firmware: een gelicentieerde Bandai Namco arcade emulator ("Featuring Moo Emulation", build V.289.1 Aug 12 2025) geschreven in C++. Deze shares niets met de andere board, dus er kon niets direct uit de disassembly worden overgenomen.
Knoppenconfiguratie
| Knop | Pin | Knop | Pin |
|---|
| D-pad up | PB7 | A | PB0 |
| D-pad down | PB5 | B | PA11 |
| D-pad left | PB6 | VOL+ → START | PA0 |
| D-pad right | PB4 | VOL- → SELECT | PB2 |
De bedrading bleek identiek aan het 104 Games board — dezelfde pinnen dragen de d-pad, A en B. Deze console gebruikt simpelweg minder van deze pinnen, en zijn twee volumeknoppen zitten op pinnen die de andere console gebruikte voor de volumeschuif. VOL+ en VOL- worden START en SELECT omdat DOOM deze nodig heeft en er niets anders over is; er is geen strafe-toets aanwezig.
Technische bijzonderheden
Twee zaken die veel tijd kostten:
- PA8 is hier de panel RESET, niet de backlight. Dit is het verschil tussen een port die werkt en een die alleen lijkt te werken. Het aanhouden van de 104 Games logica (hoog houden) betekende dat de controller nooit werd gereset: bij een koude start kwam deze ongedefinieerd omhoog en toonde een witte raster terwijl de firmware init-gegevens en een beeld stuurde. Het zag er verder goed uit omdat flashen de stroom niet onderbreekt en de setup van de standaardfirmware bewaard bleef. De standaardcode pulseert dit laag op
0x08016B98 en wacht voordat er iets wordt verzonden.
- Het paneel negeert MADCTL. Vier waarden zijn geprobeerd, inclusief een schone koude start met volledige init, en één waarbij de BGR-bit was uitgeschakeld om rood en blauw te wisselen. Niets veranderde. Daarom gebeurt de rotatie in software voordat het naar het paneel gaat, wat één extra pass over een line buffer kost die sowieso al wordt opgebouwd.
De panel init (78 bytes, 25 commando's) is statisch uit de standaardfirmware gehaald. Het is dezelfde controller-familie als het andere bord maar met andere parameters: MADCTL 0x28 in plaats van 0xE8, een extra 0x21 voor display inversie, en eigen timing-, power- en gammawaarden. Deze gammacurves zijn de reden waarom het beeld donkerder leek terwijl het nog op de standaardconfiguratie draaide.
Bouwen
Vereisten: arm-none-eabi-gcc (getest met 10.3.1) and make.
cd firmware
make # -> build/action104/doom.bin
make BOARD=pacman # -> build/pacman/doom.bin
Board-specifieke pinnen, panel init en de knoppenkaart staan in firmware/boards/<board>/board.h. Geen enkel ander deel van de firmware weet voor welke console er gebouwd wordt. Voor het toevoegen van een derde console moet een dergelijk bestand worden geschreven; docs/PORTING.md beschrijft hoe de huidige twee zijn uitgewerkt.
Flashen
Het proces is identiek voor beide consoles, afgezien van het image dat geschreven wordt. Lees eerst docs/FLASHING.md, specifiek het deel over het dumpen van de standaardfirmware.
Korte versie:
- SWD aansluiten: Twee pads naast de SoC, plus ground en VTref. Op het 104 Games board zijn deze gelabeld als
SWC/SWD; op het Pac-Man board zijn dit de pinnen gemarkeerd in de foto in docs/FLASHING.md.
- Standaardfirmware opslaan:
``bash cd tools/flashwriter && make && cd .. python flash.py read stock_backup.bin 0x08000000 0x400000 `` Sla deze stap niet over. Dit is de enige manier om terug te keren naar de originele console.
- DOOM en de WAD schrijven:
``bash python flash.py write ../firmware/build/action104/doom.bin 0x08004000 python flash.py write ../wad/doom1_e1m1.wad 0x08110000 ` Gebruik build/pacman/doom.bin` voor de andere console; het WAD-bestand is hetzelfde.
De bootloader op 0x00000000 blijft ongemoeid en blijft werken — deze springt naar 0x08004000. Secure boot is niet actief: de bootloader valideert niets, wat is geverifieerd via breakpointing.
Herstel
Terugzetten van de originele firmware:
python flash.py write stock_backup.py 0x08000000
Als een foutieve flash ervoor zorgt dat een console onbereikbaar is via SWD, kan tools/rescue.py de core vangen in het venster tussen het inschakelen en de crash. Zie docs/FLASHING.md.
Structuur van de repository
.github/workflows/: CI die beide consoles bouwt en een release publiceert.firmware/: De DOOM-firmware, standalone build.boards/: Per board pinnen, panel init, knoppenkaart (action104/ en pacman/).sdk/: Klok, LCD, input, mailbox, startup.port/: Platformlaag van GBADoom.GBADoom/: Vendored engine + engine-patches.diff.tools/: Tools voor flashen (flash.py, de RAM writer, rescue.py).wad/: Getrimde shareware WAD (alleen E1M1).dumps/: Standaardfirmware en boot ROM per console.docs/: Hardware-notities, flashing guide, porting guide.images/: Hardwarefoto's en productvermeldingen.
Credits
- doomhack/GBADoom — De DOOM engine waarop deze port is gebouwd, zelf gebaseerd op prboom. GBADoom was de juiste keuze omdat het de WAD via een pointer direct uit de cartridge ROM leest, wat perfect aansluit op het memory-mapped SPI flash van deze consoles. Upstream commit
89097b3. Zes bestanden zijn gewijzigd (heap size, time base, missing include en drie aanpassingen voor de enkele map); deze staan in firmware/GBADoom/engine-patches.diff.
- id Software — DOOM. Het WAD-bestand hier is de freely redistributable shareware IWAD, getrimd tot één map. De DOOM source code is GPL v2.
- atc1441/TXW818WalkieTalkieDoom — Referentie voor het krijgen van GBADoom op een kleine Cortex-M met een SPI panel.
- NordicPlayground/nrf-doom — Nuttige vergelijking voor geheugenbudgettering.
Productfoto's van de consoles zijn screenshots van de eigen shop-pagina's van Action.
Licentie
GPL v2, overgenomen van GBADoom en de DOOM source release. Zie LICENSE. De inhoud van dumps/ is niet GPL maar behoort toe aan de leveranciers; deze is opgenomen zodat het reverse engineering proces gecontroleerd kan worden. Zie dumps/README.md.
Disclaimer
Deze software overschrijft de firmware van een apparaat dat je hebt gekocht. Dit is herstelbaar als je de back-up in stap 2 hebt gemaakt, en niet als je dat niet hebt gedaan. Niemand verbonden met Action of de fabrikanten was betrokken bij dit project.
Groetjes,