Nach diversen Versuchen ein paar schwerwiegende Bugs zur Strecke zu bringen muss ich mir wohl oder übel eingestehen dass es nicht möglich sein wird den B-64 crossplattformtauglich zu halten.

Warum das ?
Angefangen hat das Elend damit dass unter OGl, was ja die Voraussetzung für alle Plattformen ausser Windows ist, die Grafikausgabe den Dienst versagte. Ich erhielt sowohl unter Windows OGl als auch unter Ubuntu nur einen weissen Bildschirm, die Pixmap wurde augenscheinlich nicht eingerendert. Dieser Fehler wurde mir auch von hamZta, D-Bug und Hyde unter Linux und Mac OSX bestätigt.
Nach einigem Hin- und her war ich in der Lage den Bug zu fixen indem ich in meiner Drawloop einen Drawtext-Befehl setzte. Mir ist immernoch schleierhaft wie der Bug entsteht, und auch die Lösung des selben ist mehr als mysteriös. Ich habe daraufhin auf bb.com einen BugReport verfasst, welcher bislang jedoch unbeantwortet blieb. Vielen Dank an dieser Stelle an hamZta der sich sehr bemühte den Bug einzugrenzen. Auch wenn wir den Fehler noch nicht gefunden haben scheint es jedoch ein Problem mit Pixmaps/OGl und der massiven Verwendung von Listen zu sein.

Nachdem ich nun einen Workaround hatte gab ich den Source wieder an meine Tester weiter, nur um festzustellen dass die Performance auf Non-Windows-Systemen absolut miserabel ist.
Habe ich unter Windows noch locker ausreichend FPS (sowohl unter DX als auch unter OGL), bricht Linux dem gegenüber um die Hälfte ein.
Ganz übel wird es dann unter OSX, hier läuft diie App grade mal mit 1-2 FPS. Auch dieser Einbruch ist mir völlig schleierhaft, da der B64 ausser etlichen RAM-Zugriffen und den Pixmap-Operationen nichts tut.
Meine Vermutung zielte also auf einen verbuggten OGl-Treiber unter BMax2D.
Hier sprang nun Btbn zu meiner Hilfe und schrieb mir binnen weniger Stunden ein rudimentäres Rendersystem mit der SDL. Nochmals vielen Dank hierfür.
Erste Tests mit SDL liefen auch sehr vielversprechend, unter Windows erlangte ich einen FPS-Zuwachs von ca. 5%.
Unter Linux jedoch ist die Performance wie gehabt. Ein Test am MAC steht noch aus, doch ich befürchte dort wird das Problem auch weiter bestehen.
Also scheint irgendetwas unter der Haube bei BMax unter Linux und OSX gewaltig gebremst zu werden was unter Windows fehlerfrei funktioniert.

Solange ich hier keinen Aufschluss erhalte werde ich leider keine Unterstützung für die beiden OS anbieten können, was sehr schade ist da einige der grössten 'Fans' des B64 auf diesen Systemen unterwegs sind.

Ich werde dennoch versuchen voranzukommen - stay tuned.

Sodale, es ist soweit. Ich präsentiere die erste Version des B-64 SDK, herunterzuladen hier:

B64-SDK V1.0 Win32

In diesem Set enthalten sind:

- Der B64 als solches, inklusive neu eingebautem Tracer und dem CharROM.
-Ein Optionenmenu in welchem die Vektoren des B64 sowie ein eventuell zu ladendes Programmmodul eingestellt werden können. Dies ist essentiell, denn wenn kein Programm im Speicher ist wird der B64 einfach sang- und klanglos abstürzen.
- Ein einfacher Compiler für 6510-Assembler welcher aus einer .asm-Textdatei ein ausführbares Programm-Modul (.a) erstellt.
- Zwei Beispielmodule in .asm und .a zum testen.
- Eine Doku für den B64 sowie für den Compiler.

All dies ist sehr rudimentär, da ich noch schwer am arbeiten daran bin. Desweiteren denke ich dass ich Leuten die verrückt genug sind sich mit dem Ding zu beschäftigen genug Enthusiasmus zutrauen kann dass sie im Netz nach Doku über den C64 schauen, da gibt es viele nützliche Infos zu finden. Passender Startlink ist in der Doku enthalten, auch die c64-WIKI kann ich nur empfehlen.

Was kommt nun als nächstes ?
Zum einen hoffentlich viel Feedback und Testcodes von euch. Mich würden vorallem Berichte über die Auslastung etc sehr interessieren.
Zum anderen möchte ich nun erste Funktionen für das zukünftige Kernal entwickeln, wobei ich hier erst mal nur Basics vorgesehen habe.


Have Fun!

Nur eine kurze Meldung meinerseits. Ich habe heute den Compiler für den B64 'grob' fertig gestellt. Grob bedeutet dass er lauffähigen Code generiert, aber es gibt quasi keinerlei Komfort und auch nahezu keine Fehlerabfragen.
Nichts desto trotz bin ich stolz wie Otto, und nach ein wenig Finetuning werde ich auch eine Version zum Herumspielen veröffentlichen.

Beim Testen des Compilers bin ich dann noch nebenbei auf einen üblen Bug im Prozessor gestossen, den ich ausmerzen konnte. Auch hier wird mir hoffentlich der erste öffentliche Test die letzten Käfer zeigen.
Bevor ich jedoch den Startschuss erteile werde ich erstmal eine Dokumentation erstellen.
Viel zu tun, weiterhin. Ich freu mich drauf.

Okay, ein reduzieren der Updatehäufigkeit hat die Performance gerettet. Ich habe mich nun entschieden den CIA alle 10ms abzufragen, und den Interrupt-Zyklus auf 50 hz gelegt.
Ab nun ist es also wichtig eigene Programme - wenn nötig - mittels SEI vor einem Interrupt zu kapseln, da sonst der Vektor ab $FFFE angesprungen wird. Dies wäre derzeit noch fatal, da der B64 ja noch nicht über ein richtiges Kernal verfügt.

Das Testprogramm für die Chose ist mal wieder schön simpel:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Zuvor lade ich - dies geschieht derzeit noch 'hardwired' - ein Testbild in den Videospeicher. Wäre nicht nötig, sorgt aber für optische Abwechslung.

Rauskommen tut dann das hier dabei.
Wer die Cursortasten und/oder die Alt und Strg-Tasten bedient kann sehen wie die einzelnen Joystickachsen das Farbregister beeinflussen.

Ab jetzt ist der B64 also zumindest bedingt programmierbar, quasi eine simple Videoconsole. Wer ein eigenes .a- file einfügen will, bitte gern.
Ein .a-File besteht aus der Startadresse in den ersten 2 Bytes (derzeit ist nur $20 00 sinnvoll, da der Reset des B64 dorthin verzweigt).
Danach steht dann das Programm in Byteform - im Quelltext oben der Teil zwischen der Adressangabe und dem Mnemonic. Alle legalen Opcodes des C64 können verwandt werden ( siehe dazu http://www.htu.tugraz.at/~herwig/6502/ ).
Das VRAM ist schon wählbar, zu beachten ist jedoch dass im gelieferten Test immer an $1000 die Testdatei geladen wird.
Ich werd die Tage mal eine erste Doku zu den Registern erstellen.

Nicht Central Intelligence Agency, nein.
Gemeint ist der Complex Interface Adapter, ein Baustein der für die Kommunikation des Rechners mit der Aussenwelt zuständig ist. Im C64 waren 2 Stück davon verbaut, der B64 hat nun einen, der allerdings nur das simpelste Kerngeschäft wahrnimmt: bislang ist die CIA hier nur ein simpler Taktgeber, der 60 mal pro Sekunde einen Interrupt auslöst. Als weitere Aufgabe wird schon ein simulierter Digitaljoystick abgefragt, der 4 Richtungen und 4 Feuerknöpfe hat.

Leider stosse ich immer mehr an Performancegrenzen von denen ich nicht weiß wie ich sie bekämpfen soll. Der Einbau des CIA in die Mainloop hat die Framerate des VIC von 25 auf 16 gedroppt - ich denke dass allein die Methodenaufrufe hier zur Bremse werden, und wenn ich die vermeiden wollte müsste ich alles neu und komplett prozedural schreiben, was ich weder will noch für sehr sinnvoll halte.

Ich werde also leider Leistungsgrenzen setzen müssen. Eine erste Idee wäre es den Takt aus dem CIA in die Mainloop zu verlagern und den CIA nur noch einmal pro x Millisekunden die Interface-Infos in das RAM schreiben zu lassen. Da wohl kaum ein Spieler im Millisekundenbereich mit dem Joystick agiert sollte das verschmerzbar sein.

...und so sieht das Bild im neuen Modus Extended MultiColor aus, der über 2 Pages FarbRAM je 4 aus 16 statt 4 aus 8 Farben pro 4*8 Pixel zulässt. So kanns doch bleiben, nicht wahr

Nebenbei hab ich noch ein paar kleinere Verbesserungen eingebaut, unter anderem kann man nun Programme und Bilder sowohl an feste als auch an variable Adressen laden.


Die Firma ihres Vertrauens nun auch auf 8-Bit

Sooo...
Nochmal ein paar Fehler ausgemerzt und einen Bildwandler geschrieben, der mir ermöglicht den MulticolorModus zu testen.
Was man deutlich sieht ist das die Palette doch sehr eingeschränkt ist, ich bin daher am überlegen ob ich die 4 freien Byte im FarbRAM für eine Paletteninfo nutzen soll. Mal sehen.
Aber erst dürft ihr mal sehen:



Des weiteren ist der VIC nun Taktzyklengenau angebunden. Jippieh!

So, wieder ein bissel weiter am VIC gebastelt. Jetzt beherrscht er mehrere Grafikmodi, unter anderem einen Farbtextmodus und die Hochauflösende Monochrom- sowie Farbgrafik.
Auch mein Assemblerbeispiel musste in diesem Zuge etwas erweitert werden:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Die Modi im einzelnen sind nun:
$01: Text, 21*12 Zeichen, Farbe aus dem VIC-Farbregister (Vordergrund/Hintergrund), Zeichen aus einer Page
$02: Farbtext, 21*12 Zeichen, Farbe aus FarbRAM hinter dem ZeichenRAM
$04: HIRES, 168*96 Pixel, 8 Pages VideoRAM, Farben aus VIC-Farbregister
$08: cHIRES, 168*96, 8 Pages VRAM, 1 Page FarbRAM (2 Farben pro Zeichengrosser Block(8*8 Pixel)
$10: MCOLOR, 84*96 Pixel doppelter Breite, 8 Pages VRAM, 1 Page FarbRAM, pro Zeichenblock 3 Farben (allerdings limitiert auf die Farben 0-7), eine Hintergrundfarbe aus dem VIC-Register.
$20 HICOLOR: 84*96 Pixel doppelter Breite, frei wählbare Farben, 16 Pages VRAM.

Der VIC selbst kann 16 fest definierte Farben darstellen, die Bildfrequenz wurde PAL-konform auf 25 hz reduziert. Da der Rasterstrahl selbst komplett emuliert wird kann man theoretisch auch so Spässe wie Rasterzeilenbalken etc. basteln.

Der HICOLOR-Modus ist noch nicht integriert, die anderen laufen soweit ich das beurteilen kann fehlerfrei.

Neues Bild hab ich noch keines, da ich die Grafikmodi derzeit mit Pixelmüll befülle, ich muss mir erst einmal ein Testbild in eines der unterstützten Formate konvertieren.


Desweiteren habe ich mir ein paar Gedanken zu Ein- und Ausgabe gemacht, sprich alles was die Kommunikation des Rechners mit der Aussenwelt angeht. ich werde wohl nicht umhin kommen eine virtuelle Floppy zu basteln

HURRA!

Mein erster ASM-Code hat einwandfrei funktioniert:
Code: [AUSKLAPPEN] [EINKLAPPEN]
diese 11 Byte Code sorgen dafür das der Bildschirm immer weiter durchrotiert wird. Das ginge auch mit 7 Byte, wäre aber so rasend schnell dass man nur noch Matsch auf dem Bildschirm sähe, daher habe ich eine Warteschleife mit eingebaut.
Schön zu sehen dass es funktioniert. Ich werde nun erstmal an den Grafikmodi weiterbasteln.

Der B-64 verfügt nun über einen funtkionierenden VIC (Video Interface Controller), wenn dieser bislang auch nur den 2 Farben-Textmodus beherrscht.
Ein kleines Bild dazu:


Ok, sicher nicht der Brüller beim Hinschauen, aber es steckt ne Menge dahinter. Die hier abgebildete Meldung existiert rein im Speicher des virtuellen Computers, und der VIC rendert das Bild 50 mal in der Sekunde neu ein (und benutzt dafür das Zeichensatz-ROM des C-64). Auf meinem Rechner erreicht die CPU dabei ca. 0,7 MHz Taktfrequenz bei einer Auslastung von 25%.
Ein Koppeln des VIC an die Befehlslänge der CPU steht noch aus, sollte aber keine wesentlichen Probleme ergeben.

Der VIC wurde auf eine Auflösung von 168*96 Pixel ausgelegt, da so eine Bildschirmseite ungefähr einer Page im Ram entspricht (252 zu 256 byte).
Nicht massig Platz, aber für ein paar nette Spielereien wird es langen.
Ich werde als nächstes den KERNAL rauswerfen und stattdessen eine Assembler-Routine schreiben die im sichtbaren Bereich ein Zeichen durchlaufen lässt, so als kleiner Test für den Vic und meine eingerosteten Assemblerkenntnisse.