Nieuwste versie coreboot kan DOOM draaien vanaf moederbordfirmware

Het coreboot-team heeft in update 4.17 van zijn firmware een nieuwe payload toegevoegd genaamd coreDOOM. Daarmee is het nu mogelijk om de klassieke first-person shooter DOOM te spelen vanaf de firmware van ondersteunde moederborden.

CoreDOOM is volgens de GitHub-pagina van het project een port van doomgeneric in de vorm van een coreboot-payload. Hij wordt standaard geleverd met een databestand van de shareware-versie van DOOM, maar gebruikers kunnen indien gewenst hun eigen zogenaamde .wad-bestanden toevoegen om andere DOOM-content te spelen, mits het allemaal op de opslagruimte van het moederbord past.

Belangrijk is om wel te weten dat doomgeneric de ondersteuning voor geluid achterwege laat om het porten te vergemakkelijken. Daarnaast stelt de maker van coreDOOM dat USB-toetsenborden niet ondersteund worden; alleen PS/2-invoer werkt. Ook is er momenteel geen ondersteuning voor saves noch een config. Ook loopt het systeem vast als men de game verlaat.

Volgens Phoronix is coreDOOM getest in een QEMU-omgeving en op echte hardware. Helaas maken het coreboot-team noch de coreDOOM-ontwikkelaar beelden beschikbaar van coreDOOM in actie. Versie 4.17 van coreboot ondersteunt verder enkele nieuwe Chromebooks alsmede apparaten van Clevo, Dell, HP en Star Labs. Tweakers publiceerde vorige maand een geschiedenisverhaal over coreboot, dat een alternatief is voor bios en UEFI.

DOOM is dankzij zijn ouderdom, zijn geliefdheid bij fans en de alomtegenwoordigheid van zijn source ports een game die regelmatig 'omdat het kan' geport wordt naar andere platformen. Opvallende voorbeelden daarvan zijn DOOM in Minecraft, op een Kodak-camera uit 1998 en op de touchbar van een MacBook Pro.

coreDOOM?
Beeld via Phoronix, dat niet uitdrukkelijk zegt of deze screenshot van coreDOOM is of niet

Door Mark Hendrikman

Redacteur

05-06-2022 • 13:16

58

Submitter: TheVivaldi

Lees meer

Onderzoeker laat ratten Doom spelen
Onderzoeker laat ratten Doom spelen .Geek van 23 november 2021
Doom is 25 jaar oud
Doom is 25 jaar oud .Geek van 10 december 2018

Reacties (58)

58
52
38
0
0
1
Wijzig sortering
Wel jammer van de audio... Dat moet toch op de een of andere manier wel te doen zijn? Via een setting de audio in 16-bit sb16 stijl naar buiten sturen...
Dan moet je al een AC'97-driver in elkaar draaien. Op MS-DOS zou een TSR dat kunnen regelen, maar hier zou je dat direct in de firmware moeten doen.
Hebben dit soort moederborden nog een onboard speaker (als een ps/2 poort nodig is, lijkt me dat wel)? Die zijn toch een stuk makkelijker aan te sturen, originele doom zou daar zelfs support voor moeten hebben voor het genereren van die bliepjes.
Volgens mij heeft bijna elke moederbord daar nog wel 2 soldeerpunten voor :)
Nou, bijna elk moederbord heeft nog PS/2, zelfs mijn B450 van MSI. Zover ik weet heeft ie geen onboard speaker (of tenminste niet eentje doe compatibel is met Linux)
@Zoop Klopt. Het idee is dat dat alles naar de USB spec/controller/driver gaat.
@field33P
de .dll is genoeg.

Ik ken dit project niet, maar meestal moet je die binary gewoon in de /addon/ directory droppen en die wordt dan automatisch opgepikt en gebruikt waar mogelijk.

@blorf Opvallend zelfs, na honderd ports, dat er nu een dev over audio klaagt, terwijl dat altijd één van de USP's was van DOOM.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:15]

Nou ja, Doom zonder geluid is een beetje jammer. Maar wat was er anders aan? Voor mijn gevoel klonk de muziek iets beter omdat ze het nabootsen van bestaande instrumenten bewust vergaten. Wat meer abstracte instrumenten die gewoon beter in het gehoor liggen.
@blorf De legacy van Doom betreft de game engine, want de game op GNU/Linux gereleased by John Carmack per December 23, 1997, en met GPL per October 3, 1999. Bij de game zat gewoon geluid, maar er ontbraken diverse platformen en architecturen. Vandaar de vele forks en wirwar aan ongeveer dezelfde features. Verder heb je nog de sfx, maar die verschillen per game.

En GNU/Linux had in die tijd ook gewoon muziek. En ook portable sound libraries, danwel apps. De player hoeft dan enkel passthrough te accepteren, en dan doet de codec de rest. En als je C++ geen probleem vindt, dan is er ook smplayer, die die trick ook support.

https://github.com/id-Sof...b/master/sndserv/sounds.c

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:15]

Dit gaat over de '93 shareware-versie toch? Daar zat gewoon audio in. Onderdeel van de engine is waar richting en volume van geluid worden berekend.
De versie van deze Doom engine weet ik niet exact, ik heb de initiële commit in die repo ook niet bekeken, maar ik bedoel idd dat je vaak door die .dll's naar een folder te kopiëren betere .midi en surround support hebt bij het gebruik van passthrough players.

Ik gebruik deze methodiek met papplayer, met extra AC'97, Intel HD Audio & timidity .dll's, met automatische decoder selectie afhankelijk van de source/input file. Het voordeel van die papplayer is dat je met een config file nog allerlei settings kan instellen voor verschillende codecs, zoals gebruikelijk in de Linux/Debian sound system voordat ALSA kwam. De setup support ook CD kwaliteit.

Raspberry/raspbian loste dat toendertijd ook wel handig op, waarbij je $5 of zo extra betaalde voor een codec, en dan moest je gewoon éénmalig een code invoeren voor playback support.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:15]

Dll's zijn dynamic link libraries. Je hebt er Windows voor nodig.
Al deze dingen zijn irrelevant aangezien het om een coreboot variant gaat. Dat is een bios/UEFI vervanger en er is dus geen sprake van een besturingssysteem zoals normaal. In principe draai je doom als bios.
Toen doom uitkwam, was audio redelijk nieuw en was er geen echte standaard, wat het redelijk complex maakt om alle gekuidskaarten te ondersteunen. Daarom heeft Id software voor hun audio gebruik gemaakt van een proprietary library, als gevolg is die library geen onderdeel van de open-source code.

Daarom hebben veel doom ports ook geen geluid, omdat je daarvoor een driver moet programmeren wat een stuk moeilijker is. Doom is namelijk zo opgebouwd dat bijna alles in doom draait en je enkel de in en outputs moet verbinden. Er is een mooi boek geschreven door Fabien Sanglard dat dit mooi uitlegt (GAME ENGINE BLACK BOOK: DOOM)

[Reactie gewijzigd door IStealYourGun op 22 juli 2024 15:15]

Ik dacht een combinatie van 16-bit sfx samples en een midi-achtig systeem. Typerend is de oneindige nagalm als de boel vastloopt. Voor wat ik gezien heb werkt het zo goed als altijd met een Soundblaster (Pro) compatible kaart.
Doom zou gebruik maken van 8-bit. :p

En nogmaals, in die tijd was er niet echt een standaard library. Wolfenstein 3D ondersteunde maar vier sound-cards, wat al een enorme opgave zou geweest zijn. Daarom maakte ze gebruik van een proprietary library (DMX) die veel meer sound cards ondersteund out of the box en Id-software dus maar één library moesten aanspreken ipv verschillende drivers.

De doomcore voorzag de sound en tijdens een interrupt haalde de DMX de sound op en stuurde die door naar de gewenste audio driver. Alleen is die library dus closed source en dus geen onderdeel van de open source.

[Reactie gewijzigd door IStealYourGun op 22 juli 2024 15:15]

Bijna alle DOS-spellen ondersteunden maar klein aantal geluidskaarten. sb16, sb-pro, Gravis, Disney, Tandy. Iets anders was vrij apart. Echt iedereen had een Soundblaster kloon.
Ik had in het begin zo’n module op de printerpoort. Gaf ook nog wel aardig geluid. Geen idee of doom dat supporte. Het waren helaas maar een paar spellen die ermee overweg konden
En hoe/waar ga je dat naartoe sturen?

Dat is net 1 van de mooie dingen van een OS, dat neemt zoveel van die dingen uit je handen en biedt developers een abstractielaag aan waar ze tegenaan kunnen praten. Je OS gaat zelf op zoek naar de hardware en gaat deze voor je configureren en de juiste drivers er voor zoeken.

In dit geval zou je alles zelf moeten gaan afhandellen. Hetzelfde met het toetsenbord. De meeste mensen hebben geen PS/2 toetsenbord meer en er zijn ook meer en meer systemen die de connector niet meer hebben. Maar USB vereist ook weer een stuk meer werk om het werkende te krijgen daar je ineens drivers nodig hebt voor de USB controllers
Hetzelfde als output naar het beeldscherm? Als ze heel Doom erop krijgen en kunnen starten kan de geluidskaart initialiseren ook.
Ze gebruiken PS/2 omdat dat een oude directe hardware-verbinding is. Nog steeds zijn er veel PC's uit de overgangs-tijd, waarbij je niet in de BIOS setup kan komen omdat USB daar nog niet klaar is.
dat kan lijkt me gewoon met standaard VESA/VGA, AFAIK is er niet meer zoiets voor audio vanuit software-oogpunt (zoals vroeger met soundblaster/ADLIB)
Ik weet eigenlijk niet hoe dat zit. Boven heb ik een +/- 15 jaar oude HP dual core staan met Winxp erop als oude game-kast. Daarop beschrijf ik ook SD-kaarten voor een nog oudere Pentium 1 voor MSDOS spellen. Als ik zo'n SD-kaart op de HP boot werkt het geluid (Realtek hda) gewoon. Je moet alleen de BLASTER variabele goed hebben. Ik kan me geen specifieke configuratie herinneren...
Zo'n bootdisk met game erop gebruikt vaak DOS. Dus die voorziening wordt door DOS geboden. Het is de interface tussen je hardware en het spel. Die interface mist in dit geval aangezien het spel dus baremetal draait. VGA is gestandaardiseerd dus dat zal op elk systeem wel werken maar audio is een heel ander verhaal.

Edit: ik lees op Github dat de port dus leunt op de framebuffer die Coreboot biedt.
Video: Assumes coreboot will present an RGB888 framebuffer with bits 24:31 as padding. TODO: add support for other formats later

[Reactie gewijzigd door BezurK op 22 juli 2024 15:15]

Welke interface? Je moet alleen het IRQ en DMA-kanaal weten. Doom 1 doet het zonder enige driver, als je maar SB-compatible bent. Dat is directe adressering.. Het OS boven het programma dat geluid maakt bemoeit zich er in principe niet mee.

[Reactie gewijzigd door blorf op 22 juli 2024 15:15]

Ik zou het zelf niet weten. Een hardware-virtualisatie engine als Vmware of Xen?
USB vereist een complexe softwarestack die verschillende apparaten identificeert en tegelijk aanstuurt over hetzelfde kanaal. Op hoge snelheid, mediastreams kunnen er ook over.

[Reactie gewijzigd door blorf op 22 juli 2024 15:15]

De USB softwarestack is al heel lang beschikbaar op zowel GNU/Linux als op FreeBSD. Het proces om de UEFA bios te voorzien van USB, ter vervanging van IRQ/DMA is een groot industrieel project met vele afhankelijkheden en coördinatie voordat die feature live gaat.

Maar zodra enkele andere projecten zover zijn, dan zal het wel ingeschakeld mogen worden:
nieuws: EU verplicht USB-C in herfst 2024 voor smartphones, tablets en camera's

lol, usb-c zegt de titel, type C is een stekker benaming en een standaard waar de industrie toch al naar toe beweegt, ook zonder overheid. Ik denk dat de nieuwswaarde vooral USB3.2 met wat extensies betreft, zoals bij hdmi2.1 het geval is.
nieuws: HDMI 2.1a krijgt functie om actieve HDMI-kabels direct van stroom te ...

Overigens bedoelde ik dat zo'n hypervisor laat zien dat het niet zo moeilijk is om direct USB aan te spreken. Er is al eens eerder een management laag tussen de bios en userspace gezet. Dus je kan dat ook zien als een soort industriebrede driver. Ook software als XBMC heeft altijd toegang tot usb gehad, ook voor Openelec al. Dat komt dus omdat die USB libs vrij standaard zijn.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:15]

Het is niet allemaal echt technologisch belang. Ik herinner me Norton Ghost in de XP-tijd die stabiel USB kon krijgen via een opstartdiskette met een klein drivertje, terwijl het voor de Windows-eindgebruiker toen een grote instabiele zooi was.

Maar die USB-c verplichting gaat alleen maar over de 2 voedingsdraden, niet? Wat ze nou eens zouden moeten doen is een communicatiestandaard verplichten met de andere 2 draden. Dus elke telefoon moet verplicht bedienbaar zijn via Rx en Tx. Een beetje hetzelfde als de hardware-console die PC's hebben.

[Reactie gewijzigd door blorf op 22 juli 2024 15:15]

klopt.
Management keuzes en dezelfde implementatie verschijnselen zoals met die mouse en de bios, of de "upgrades" van al die texteditors naar interpreted editors.

Het werkt allemaal in GNU/Linux maar de doorontwikkeling van die USB driver is een ramp. Net als de bluetooth stack, of ook de NTFS drivers. ACPI space gone AWOL.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:15]

Eigenlijk is USB een implementatie tegen de vrijheden van de gebruiker. Aangezien de functionaliteit van de interface amper fysieke ruimte kost zou het heel mooi en goedkoop verbeterd kunnen worden. Ik zou zeggen, maak alle poorten schakelbaar en zet er een leuke controller-chip achter die meer kan dan apparaten met het systeem doorverbinden als ze wat willen. Het is nu een heel mooi systeem, maar zonder knoppen omdat de industrie die controle niet wil weggeven. In verbeterde vorm zou het interessant kunnen worden om van meerdere computers een high-available all-round systeem te maken. Ik denk ook dat grote hardwarefabrikanten daar een beetje huiverig voor zijn.
klopt ook. Daar zijn keurmerk labels voor, vaak continentaal zoals EC en FCC.

En blijkbaar zijn die machtig genoeg aangezien Trump gerelateerde instituten in de ban deed. Toch wel een flinke mijlpaal in de embargo's, handel en tarieven oorlogen.

Ik vergelijk het met upnp en rss, ook 2 van die gekillde high-available all-round systeem technologiën. Naar mijn idee krijg je dan automatische een respons, zoals een high-frequency kernel.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:15]

Ben jij de broer van Rian van Rijbroek? :+
Nee, Ellie Lust de Tweede :+ :+
Daar ik toch al bezig ben coreboot aan de praat te krijgen op onze eigen hardware, lijkt het me een prima proof of concept om te kijken of ik daar DOOM op draaiend krijg :D

Tegen de tijd dat ik coreboot zelf aan de praat heb is deze payload draaien vast geen probleem.

[Reactie gewijzigd door s0ulmaster op 22 juli 2024 15:15]

We zien de uitgebreide videoreview mét geluid wel verschijnen... :+
Als ik genoeg tijd van de baas krijg :Y)
Als je kijkt naar de originele doom, dan kan je die niet meer compilen op moderne hardware omdat compilers minder strict waren. Nu weet ik niet hoe ver doomgeneric afwijkt van het oorspronkelijke, maar heb je geen schrik dat CoreBoot mogelijk onveilige code zo makkelijk aanvaard?
Ik weet niet, het draait in plaats van de fabrieks-BIOS. Volgens mij praktisch hetzelfde als DOS maar met heel beperkte resources. Er gaan zeker computers afvallen omdat ze niet standaard genoeg zijn, maar een geladen default sound-river is volgens maar een klein blokje RAM. Het is amper een driver te noemen, meer een omleiding in de syseem main-loop.

Het was overigens wel een probleempje met Doom en 4MB. Ik heb ooit 1MB bij gekocht omdat memmaker het net niet haalde. :+

[Reactie gewijzigd door blorf op 22 juli 2024 15:15]

Dat is alleen het scherm. Nog steeds indrukwekkend, maar geen volledig spel.
Zelfs niet eens het scherm, gewoon het omhulsel. Het scherm is gewoon eentje gekocht van adafruit en dat soort mods bestonden al in het verleden.
Prachtig, kwam mijn vriendin maar aan zetten met zo zwangerschap tester .
Gemiste kans om het versienummer op te krikken naar 4.666
6.66 is iets teveel van het goede.
4.0013 kon niet meer
D OO M

5.773 had ook gekunt:
4 + 16/10 + 16/100 + 13 / 1000

[Reactie gewijzigd door djwice op 22 juli 2024 15:15]

4.20 is dan dichterbij :p
Vergeet de Doom port naar HP48 niet.
Wordt Coreboot nou gebruikt op Chromebooks?
Nou, das ook toevallig, ben net DOOM eternal op mijn Steam Deck aant gamen haha.

Top game! Vroeger en nu.
leuk dat het kan, maar als het toevoegen van een game (op een heel brakke manier dan nog wel) de enige reden is waarom er een artikel over geschreven wordt, dan is het wel erg gesteld met de interesse in het project :/ (zelfde met de tesla-release indertijd)
Daar word al naar verwezen in de laatste alinea, je mist dasiro's punt, het gaat denk ik over het project zelf wat kennelijk niet helemaal op rolletjes loopt.
vooral Coreboot, want als je moet kiezen tussen tijd besteden als toeters en bellen zoals dit of een aantal extra moederbordmodellen die je installbase kunnen vergroten, dan zou de keuze toch eerder bij die laatste liggen. Hiermee trekken ze mss wat aandacht, maar wat ben je ermee als quasi niemand het kan draaien
ben ik wel met je eens.
voor Coreboot en UEFI/GPT was er ook altijd al veel discussie rondom GNU binutils en GNU M4. En sommige platforms hebben er sowiezo een handje van om slordig te zijn. De ene keer zus, de andere keer zo.

Ik zal zelf eens checken wat de tesla-release van Coreboot is dan...

edit: Tesla stopped committig to that repo on May 1, 2017 and Open Sourced with a single commit in Jan 7, 2020. Zal wel Musk's speeltuin zijn. De repo is ook scrambled, een zakelijke beslissing om reverse engineering tegen te gaan. En releases of onderhoud zijn geen vereiste voor de GPL.
https://github.com/teslamotors/coreboot/releases
The new code added on top of the Coreboot source tree is from Tesla Motors and Samsung. Samsung manufacturers the company's current full self-driving (FSD) chip.

The Coreboot code does reference a "Turbo TRAV" SoC and "Turbo Sentinel" motherboard as the new targets to which I haven't been able to find much on these codenames.

The Coreboot implementation is ultimately for initializing the hardware and booting the Linux kernel as a replacement to the conventional proprietary BIOS.

Tesla's public Linux kernel tree meanwhile continues tracking dated Linux 3.x and 4.x kernel branches for Intel and NVIDIA Tegra platforms.
See: https://www.phoronix.com/...n-their-electric-vehicles

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:15]

Op dit item kan niet meer gereageerd worden.