Songs mit TB-303 Sound

Veröffentlicht am von
Antworten

Bereits vor vier Jahren habe ich in der kleinen Reihe „Herausragende Musikalben“ den monophonen Analogsynthesizer TB-303 der Firma Roland zu einem ernsthaften Musikinstrument für mich erhoben. Da ich in meiner frühen Jugend mal dazu genötigt wurde, auf andere Instrumente zu achten, fällt mir es relativ leicht – trotz Fokus auf etwas anderes – Instrumente beim Musik hören wahrzunehmen. – Zumindest bilde ich mir das ein. Deswegen fallen mir beim Hören meiner Audio-Playlisten, sowie anderer Musikquellen immer wieder Titel auf, bei denen ich den Sound einer – wenn auch nachgeahmten – TB-303 wahrnehme. Da es inzwischen schon einige Titel sind, die ich mir auch nicht alle merken kann, habe ich mir gedacht, dass ich sie in einem eigenen Blogbeitrag festhalte. Ich werde aber dennoch nicht gleich jeden Track aus dem Techno-Bereich der frühen 1990er Jahre festhalten, schließlich sind durch die TB-303 erst Sub-Genres wie der Acid-Techno entstanden. Mir geht es mit der Liste vor allem um den Einfluss, den der Klang einer TB-303 auf Musikproduzenten andere Musikrichtungen ausgeübt hat.
Außerdem werde ich nicht nur sklavisch solche Titel auflisten, bei der eine durchgängige Spur des Analogsynthesizers zu hören sind, einige – vielleicht kurze Samples reichen auch. – Vielleicht erneut sogar wieder moduliert. Diese Sample müssen, und können auch nicht immer von dem echten analogen Synthesizer der Roland sein. Nicht nur, weil deren Zahl zwischenzeitlich mal recht sehr gering gewesen sein dürfte, sondern weil auch andere Hersteller auf den Erfolgszug irgendwann mit aufgesprungen sind, und den TB-303 Klang mit in das Repertoire ihrer Synthesizer mit aufgenommen haben. Irgendwann wurden auch die Computer bereits so leistungsfähig, dass Software-Hersteller im Audio-Bereich entsprechende Software Sequenzer anboten. Und auch die Firma Roland selber dürfte dann eine modernere Variante der TB-303 neu vermarktet haben. Leider haben die Musikproduzenten nur in seltenen Fällen wirklich immer alle Synthesizer in den Veröffentlichungsinformationen ihrer Produktionen mit angegeben.

Ich habe mir auch mal vorgestellt, müsste ich heute in meinem Alter im Rahmen einer Weiterbildung, wie zum Beispiel ein Abitur an einer Abendschule, wieder Schulmusikunterricht besuchen, und sollte ich dann ein Referat oder eine Präsentation halten, in der ich ein Musikinstrument vorstellen soll, dann weiß ich, es wird die TB-303 der Firma Roland sein!

  • Daft Punk – Da Funk (1995)
  • Massive Attack – Protection (1995)
  • Madonna – Bedtime Story (1995)
  • Depeche Mode – Useless (1997)
  • Madonna – Ray Of Light (1998)
  • Fatboy Slim – Praise You (1999)
  • Leftfield feat. Africa Bambaataa – Africa Shox (1999)
  • Mirwais – Disco Science (1999)
  • The Chemical Brothers – Star Guitar (2002)
  • Herbert Grönemeyer – Mensch (2002)

Links:

Embeddable Linux Kernel Subset auf dem NuXT

Veröffentlicht am von
Antworten

Da ich mich schon länger mit zwei PCs der 16 Bit x86 XT-Klasse beschäftige, – über das originale Schätzchen von IBM hatte ich aber bisher noch gar nicht geschrieben – kam ein Kollege vor ein paar Wochen mit dem Link zum ‚Embeddable Linux Kernel Subset‘ (kurz: ELKS) auf mich zu. ELKS ist relativ kurz gesagt in Projekt, das einen frühen Fork des Linux-Betriebssystems für Systeme mit Intel IA16-Architektur (16-Bit-Prozessoren: 8086, 8088, 80188, 80186, 80286, NEC V20, V30 und kompatible) bereitstellt. in Projekt, das einen frühen Fork des Linux-Betriebssystems für Systeme mit Intel IA16-Architektur (16-Bit-Prozessoren: 8086, 8088, 80188, 80186, 80286, NEC V20, V30 und kompatible) bereitstellt. Unterstützt werden Netzwerk, Grafik, ia16-elf-gcc, OpenWatcom C und ein eigener nativer C-Compiler, sowie die Installation auf Festplatten mit den FAT-Dateisystemen MINIX und MSDOS. Die Bitte war, auch auf der historischen Hardware-Klasse neben dem üblichen DOS auch ein für die Zeit der Architektur unüblich ein Linux zu betreiben.
Schnell habe ich mir von der GitHub-Projektseite das heruntergeladene, 1,44 MB große Floppy-Image auf eine Diskette kopiert, um es auf meinem NuXT mit NEC V20 Prozessor und 640 KiB RAM starten zu können. Die Installation auf ein durch eine CompactFlash Karte dargestelltes Festplattenlaufwerk hatte ich nicht mehr hinbekommen. Da auch bereits im Gegensatz zu den 360 und 720 KB Disketten-Images das vollständige Subset auf der 1,44 MB Variante Platz findet und die Diskette erfolgreich gebootet war, war somit die Machbarkeitsstudie mit dem derzeitigen ELKS in Version 0.8.1 erfolgreich abgeschlossen.

Jetzt am Wochenende hatte mich der Ehrgeiz aber erneut gepackt, und ich wollte es nicht unversucht lassen. Direkt bei dem erneuten ersten Versuch hat es geklappt und ich konnte das ELKS von der echten, 1,44 MB großen Diskette auf eine übrige 256 Megabyte große CompactFlash Karte installieren. Allerdings empfand ich zum einen die Formatierung der CF-Karte mit dem Minix-Dateisystem als nicht optimal, zum anderen hielt ich die 256 MB Karte grundlegend für zu groß. Irgendwo hatte ich schließlich noch eine ungenutzte 64 MB Karte, die mir in Bezug auf die Speichergröße für die Rechenleistung der XTs geeigneter erschien. Nur mit dem Versuch, die Installation von Diskette auf CF-Karte in Vernünftig durchzuführen, wurde zum Drama!:
Ich bekam sowohl beim Ausführen der Programme zur Bearbeitung und Formatierung des Zielmediums, als auch beim Kopieren der einzelnen Dateien des Subsets von Quell- auf Zielmedium Lese- und Schreibfehler. Ist die ganze Blockstruktur so empfindlich für Disketten? Ich habe also unterschiedliche 3,5″ HDD Disketten, anderer USB-Diskettenlaufwerke für meinen Internet-fähigen Computer, sowie ein anderes internes Diskettenlaufwerk für den XT ausprobiert, aber ohne Besserung. Auch das Ausprobieren der Images auf FAT32- statt der Minix Dateisystembasis ergab keinen Unterschied. Die Alternative war dann das stupide Kopieren der vorgefertigten Harddisk Images von der Projekt-Download-Seite. Das Problem dabei: sowohl die Images mit MBR, als auch ohne, ließen sich nicht booten, da das Boot-Flag in der Image-Geometrie fehlte. Nach stundenlangem Probieren hatte ich schließlich erst wieder Erfolg, nach dem ich mir unter einem Windows Computer einen USB-Stick für mehrere Floppy-Images erstellt und das entsprechende 1,44 MB Image hineingeladen hatte. Dies bedeutete aber auch, dass ich den NuXT einen Floppy-Emulator nur für diesen Zweck einbauen musste. Nur für den einen Zweck, das ELKS von einer „Diskette“ auf eine CF-Karte zu installieren, bedeutet dies sehr viel Bastelei. Ausführen der Festplattenprogramme und Kopieren der Dateien von USB-Stick verliefen dann ohne nennenswerten Lese- und Schreibfehlern.

Quelle: https://frankfurt.social/@sommteck/115091257215484879 (eigner Mastodon Feed)
ELKS Installation mit NuXT Versuchsaufbau

Ich werde mal abwarten, bis eine neuere Version als die aktuelle 0.8.1 zur Verfügung steht. Vielleicht wurden dann die vorgefertigten Harddisk Images mit einem Boot-Flag nachgebessert. Weitere Konfiguration, sowie Optimierungen werde ich mal separat behandeln. Hoffentlich dann mit den Eindrücken des eigenen IBM XT PCs. Hier nur die Kurzanleitung zur Installation von Floppy auf eine 64 Megabyte CompactFlash-Karte.

fdisk /dev/hda
  • n → neue Partition /dev/hda1 über das ganze Speichermedium
  • b → bootable Flag setzen
  • w → schreiben, dann q zum Verlassen
mkfs /dev/hda1 60000     # MINIX v1 erstellen
sys -M /dev/hda1         # ELKS + Bootloader installieren
echo "##" > /bootopts
echo "root=hda1" >> /bootopts
sync; shutdown -r

Links:

nGlide

Veröffentlicht am von
Antworten

In den erst kürzlich veröffentlichten Videos ‚PCI GeForce FX 5500‘, ‚Overlooked High Performance Windows 98 Retro GPU: GeForce 6600 GT‘ und ‚E8600 Windows 98‘ hat Phillip auf seinem YouTube-Kanal PhilsComputerLab fast schon nur beiläufig erwähnt, dass er für seine Retro Computer Builds neben dem regulären Grafiktreiber der verbauten Grafikkarten auch nGlide zusätzlich installiert. nGlide ist ein 3dfx Voodoo Glide Wrapper. Damit können Spiele gespielt werden, die für die 3dfx Glide API entwickelt wurden, ohne tatsächlich eine 3ffx Voodoo-Grafikkarte zu benötigen. Alle drei API-Versionen werden unterstützt: Glide 2.11 (glide.dll), Glide 2.60 (glide2x.dll) und Glide 3.10 (glide3x.dll). nGlide emuliert lediglich die Glide-Umgebung mit Direct3D und Vulkan. Der Glide Wrapper unterstützt auch hochauflösende Modi. – So die Beschreibung auf der Webseite von ZEUS-Software. Dass es die Glide-Wrapper gibt, ist bisher irgendwie an mir vorbeigegangen, aber neben nGlide gibt es seit sie schon einige Jahre. Hatte ich mir in den letzten beiden Jahren doch die Mühe gemacht, für die in meiner Sammlung enthalten Spiele, die als einzige 3D-Hardwarebeschleunigung Glide unterstützen, ein authentisches 400 Megahertz Pentium 2 System aus Scrapyard-Teilen plus auf eBay gekaufter Creative Voodoo 2 Karte zusammenzubauen. Man könnte jetzt sagen: „Das Geld für eine gebrauchte Voodoo (Beschleuniger) Grafikkarte hätte man sich eigentlich sparen können!“ – Nur so einfach ist die Kiste dann aber doch nicht! Ein Glide-Wrapper ersetzt in einem zeitgenössischen System auf Basis von Pentium 2, Pentium 3 oder einem AMD-Äquivalent nicht den richtigen 3dfx Hardware-Beschleuniger. Da die Wrapper eine Hardware-Ebene in Software nachbilden, braucht es einen entsprechend leistungsfähige 2,0 Gigahertz Prozessor. Im Gegensatz zu anderen verfügbaren Wrappern, die ich sowieso nicht ausprobiert habe, ist nGlide Software-seitig auch mit Windows XP und einer DirectX 9.0 Grafikkarte kompatibel. Es gibt auch das Gerücht, dass nGlide auch unter Windows 98 zum Laufen gebracht wurde, was bezüglich des Alters des Betriebssystems noch eine Stufe authentischer ist, werde es aber selber nicht ausprobieren.

Bezüglich des Mehrwertes der verfügbaren, kompatiblen Spiele muss ich aber deutlich differenzieren. Für viele PC-Spiele aus den Jahren 1996, 1997 und 1998, die durch nGlide unterstützt werden, ist dieses eine echte Alternative. Dies betrifft Titel wie Tomb Raider 1 oder Hexen 2, da es seinerzeit als ernstzunehmenden 3D-Beschleuniger nur die auf die Glide-API basierenden Karten mit Voodoo Chips gab. Das 1996 erschienene Tomb Raider besitze ich zwar nicht in meiner Sammlung, möchte es aber dennoch erwähnt habe, da es noch zu deren Glide-beschleunigten Titel zählt, die nicht unter Windows, sondern stattdessen unter MS-DOS ausgeführt wurden. Für nGlide ist hierfür also noch die Emulations-Ebene mit DOSBox nötig. Dasselbe gilt für das in der ersten Auflage ebenso für MS-DOS veröffentlichte Grand Theft Auto. Die im Jahr 1998 erschienen Titel ‚Popolous 3 – The Beginning‘, sowie das „Ur-“ Unreal sind zu meinem Leidwesen nicht mit nGlide kompatibel. Aus der Unreal-Reihe braucht es dann schon das im Jahr 1999 erschiene Unreal Gold oder Unreal Tournament. Bezüglich Popolous 3 von Bullfrog wäre ich darauf angewiesen, einen anderen Wrapper auszuprobieren, wenn ich nicht im Besitz der originalen Voodoo 2 Karte von Creative wäre. (Anmerkung: Es gibt einen Patch, der Software Rendering mit Direct 3D ermöglicht, lief unter Windows 7 aber nicht wirklich zuverlässig.) Ab 1999 wurden aber auch zunehmend mit Titeln wie Quake 3 Arena veröffentlicht, die als alternative 3D-Rendering API OpenGL anboten, oder wie bereits mit UT99 erwähnt, zunehmend mit Direct 3D ein besseres Software-Rendering anboten. Mit den von mir gespielten Titeln ‚Star Treck: Voyager – Elite Force‘ und Daikatana – beide im Jahr 2000 erschienen – konnte ich keinen optisch-qualitativen Unterschied ausmachen.

Wer die Geschichte der Grafikarten und 3D-Beschleunigern vor etwa 25 Jahren ein wenig mitverfolgt hat, hat ja mitbekommen, wie der Chip-Hersteller nVidia mit der TNT(2) Reihe deutlich an das Know-How der 3dfx-Chips aufgeholt, sowie letztendlich mit der Markteinführung der GeForce 256-Reihe, die dann auch technologisch deutlich überlegen war, vollständig den Rang abgelaufen hat. Der Rest ist dann nur noch Geschichte. nVidia hat im Jahr 2001 den Konkurrenten 3dfx aufgekauft und deren Marke liquidiert.

Links:

Hexen II

Veröffentlicht am von
Antworten

Mit fünfzehn Jahren begeistert von First-Person-Shootern im allgemeinen und den Veröffentlichungen von id Software im Speziellen, habe ich mir das von Raven Software entwickelte Hexen II von meinem Taschengeld nach einer Klassenfahrt-Rückerstattung im Frühjahr 1998 gekauft. Ein Ego-Shooter technisch basierend auf der ersten Quake-Engine mit leichten Rollenspielelementen hatte es mich gereizt spielen zu wollen. Aber mangels eines eigenen für das Spiel leistungsfähigen Computers, konnte ich es immer nur auf fremden Systemen für nicht länger als zwei Abende anspielen, sodass ich auch nicht über den ersten, – für Rollenspiele typisch – mittelalterlich anmutenden Kontinent Blackmarsh hinauskam. Als ich dann endlich mir einen eigenen Computer zugelegt hatte, auf dem Hexen II auch flüssig spielbar gewesen wäre, verlor ich aufgrund der dann doch stark überholten Spiele-Engine und Grafik das Interesse daran. Mit der Doomsday Engine für Intel-basierende Macs hatte ich mich vor acht, neun Jahren dann doch durch Hexen II vollständig durch geballert.

Da ich aber nun seit geraumer Zeit wieder ein aus Scrapyard-Teilen zusammengeschusterten Pentium II System mit einer Creative Voodoo 2 Grafikbeschleunigerkarte besitze, wollte ich es nun doch einmal vollständig wieder auf einigermaßen authentischer Hardware durchspielen.
Bei Hexen II reist man mit seiner Spielfigur auf vier unterschiedlichen Kontinenten, die unterschiedlichen historischen Zeit- und Kulturräumen nachempfunden sind: das mittelalterliche Europa in Blackmarsh, Mesoamerika in Mazaera, das Alte Ägypten in Thysis und die griechisch-römische Antike in Septimus. Nach dem Sieg über die Generäle trifft der Spieler in Blackmarsh auf Eidolon selbst und muss ihn in seiner Kathedrale besiegen.

Da ich mir schließlich in den letzten Tagen nach längerer Zeit erneut einen Gesamteindruck über alle Missionen im Spiel gemacht habe, hier mein Fazit: Blackmarsh ist für mich optisch die am ansprechendste Welt, in der die integrierten Rollenspielanteile ebenso gefühlt am ausgeprägtesten sind. Es ist aber schließlich auch die Welt, mit der ich mich aus Gründen auch am meisten beschäftigt habe. Am wenigsten hatte mich hingegen Thysis angesprochen, da ich Level-Landschaften im Kontext vom alten Ägypten, sowie Pyramiden im allgemeinen eher langweilig finde. Wie bereits zu Anfangs erwähnt, hat mich Hexen II basierend auf der ersten Quake-Engine als fünfzehner noch fasziniert und begeistert, empfinde ich das Spielprinzip heute als sehr eintönig. Das mag sicherlich auch daran liegen, dass ich vor zwei Jahren mit The Elder Scrolls: Oblivion zum ersten mal ein richtiges Rollenspiel gespielt habe, wo viel mehr Abwechslung und Spieltiefe vorhanden sind.

Links:

MS-DOS Speicheroptimierung auf dem Monotech NuXT Turbo PC

Veröffentlicht am von
Antworten

Vor gut zwei Jahren hatte ich meinen Monotech NuXT Turbo PC vorgestellt. Ein Design für einen Turbo XT aus dem Jahr 2019 nach aktueller ATX-Spezifikation mit wahlweise Intel 8088 oder NEC V20 CPU, Intel 8087 FPU, eingebauten XT-IDE Controller, und und und! Ausgestattet ist es aber auch mit 832 KiB RAM aufgeteilt auf zwei ICs in DIP-Gehäuse.

englischdeutsch
UMAUpper Memory Areaoberer Speicherbereich
HMAHigh Memory Areahoher Speicherbereich
Vollständige Nutzung des konventionellen Speichers

In der Zeit bis jetzt hatte ich den PC unter MS-DOS ausschließlich mit den 640 KiB konventionellen Speicher genutzt, was bedeutete, dass das gesamte DOS-Betriebssystem, sowie alle aktiven Treiber nur diesen verwendeten und im Zweifel für Anwendungsprogramme, beziehungsweise für Spiele nicht mehr ausreichend RAM zur Verfügung steht. Jetzt habe ich mich aber mal hingesetzt und den noch zur Verfügung stehenden, sogenannten Upper Memory Area (kurz UMA, deutsch: ‚oberen Speicherbereich‘) aktiviert, konfiguriert, sowie versucht zu optimieren, damit mehr konventioneller Speicher für Programme und Spiele zur Verfügung steht. Schließlich hat Monotech Vintage PCs auf der mit MS-DOS vorinstallierten, sowie mitgelieferten CompactFlash-Karte auch gleich die passenden Treiber und Tools wie USE!UMB und DOSMAX beigefügt.
Abzüglich der 640 KiB konventionellen Speicher stehen mir also von den physischen 832 KiB grundsätzlich noch 192 KiB Upper Memory Area zur Verfügung. Dieser ist wiederum in sechs 32 KiB große Upper Memory Blocks (UMB) aufgeteilt. Über den auf dem NuXT Mainboard aufgelöteten 6-fach Dip-Switch lassen sich die einzelnen Blöcke stufenweise aktivieren. Allerdings muss ich hier beachten, dass es Erweiterungskarten für den ISA-Bus gibt, die auch den oberen Speicherbereich nutzen. Das wären neben Speichererweiterungskarten, Netzwerkkarten mit oder ohne Boot ROM, Karten mit eigenen Option ROMs wie HDD-/FDD-Controller auch EGA und VGA Grafikkarten wie die auch bei Monotech Vintage PCs mitgelieferte ‚Onboard PC/104 VGA Card‘. Das heißt, dass ich den ersten 32 KiB Block UMB nicht aktivieren kann, da es sonst zu einem Konflikt kommt und ich keine Grafikausgabe bekomme. So bleiben mir also effektiv nur fünf Blöcke mit zusammen 160 KiB als oberen Speicherbereich. Wirklich mehr als genug um die ersten 640 KiB konventionellen Speicher zu entlasten.
Dank der kurzen Anleitung im ‚NuXT Turbo PC‘ Handbuch, den originalen Dateiversionen der autoexec.bat und config.ays, sowie etwas Selbstoptimierung habe ich den verfügbaren Speicher für ausführbare Programme nun von 548 auf 625 KiB erhöht. Dies habe ich erreicht, in dem ich erst einmal überhaupt mit dem USE!UMBS.SYS Treiber den oberen Speicherbereich für MS-DOS zur Verfügung gestellt habe. In diesen wurden dann bereits einige Teile vom MS-DOS Betriebssystem, der Teriber für den USB2ISA Adapter und der Maus SYS-Treiber verschoben.

Systemteile und Treiber wurden in hohen und oberen Speicherbereich verlagert

Neben dem oberen Speicherbereich (UMA) kann in der config.sys auch noch der hohe Speicherbereich (HMA = High Memory Area) aktiviert werden. Das Programm DOSMAX sorgt dafür, dass weitere Teile des MS-DOS Betriebssystems nun in den zusätzlich zur Verfügung stehenden hohen Speicherbereich geladen werden. DOSMAX selber wurde natürlich zuvor in den oberen Speicherbereich geladen. Für den hohen Speicherbereich wird anscheinend aber wieder ein Teil des oberen Speicherbereichs genutzt. Zumindest werden mir mit dem Programm mem.exe wieder nur 123 KiB gesamt UMA angezeigt, der HMA wird leider nicht aufgezeigt.
Bei immer noch so viel zur Verfügung stehenden oberen Speicher habe ich mir auch mal das MS-DOS eigene Programm doskey.exe gegönnt und in die Startkonfiguration hinzugefügt. doskey.exe ist ein kleines Programm, welches eine Commandline-History für die aktuelle DOS-Sitzung seit Systemstart bietet.

Seit Aktivierung der Upper Memory Area zeigt das DOS-Programm mem.exe als insgesamt zur Verfügung stehenden Speicher nun 1024 KiB an. Dies stimmt insofern, als DOS mit dem entsprechenden aktivierten Speicherbereich die Menge auch verwalten und nutzen kann, allerdings kommuniziert DOS – zumindest beim NuXT – nicht mit dem BIOS, sodass der Wert nicht mit dem physisch zur Verfügung stehenden Speicher korrespondiert. Es geht stattdessen nur davon aus, dass 1024 KiB RAM zur Verfügung steht. Sieht man sich das Board Layout des NuXTs unter Verwendung des Handbuchs an, so scheint der physisch zur Verfügung stehende Arbeitsspeicher aus zwei 512 KiB D-RAM Speicherbausteine zu bestehen. – Was in Summe 1024 KiB sind. Da aber über die DIP-Schalter nur bis zu sechs UMBs à 32 KiB zusätzlich zu dem konventionellen Speicher zugeschaltet werden können, können praktisch auch nur maximal 832 KiB Gesamspeicher genutzt werden. Das ist MS-DOS hier nicht in der Lage exakt zu prüfen. Außerdem werden laut dem NuXT Handbuch noch Teile des UMAs für den Video-RAM (MDA, CGA, EGA oder VGA), für das XT-IDE Universal BIOS, sowie für das System BIOS genutzt. Der Power On Self Test zählt unabhängig davon trotzdem nach wie vor nur den gesamten konventionellen Speicher von 640 KiB hoch. Der zusätzlich konfigurierte hohe, sowie obere Speicherbereich – sprich die gesamten 832 KiB – sieht das BIOS anscheinend gar nicht.

Aufschlüsselung, welche Programme im konventionellen, sowie oberen Speicherbereich liegen.

Links: