Beiträge von BernhardAusdemWald

    Ich hatte immer die LOAD FUnktion im Verdacht aber das hat keinen Einfluss.

    Es sieht nach einem klassichen Tmining Problem aus. Irgendwas verhindert in Einzelfällen das Einschalten des Raster IRQ

    Ich bau ein mini programm zum testen nur mit dem Teil. Danach geb ich auf....:emojiSmiley-25:

    Du kannst mal folgendes probieren, das hatte ich aus der Dokumentation zu ULoad3 von MargerValp: den IRQ zwei Zeilen früher auslösen, und dann aktiv auf die aktuelle Zeile warten, wo Du umschalten willst.

    Ja, das hatte ich in einigen Demos gesehen und mich gefragt warum. Eigentlich ja nur bei den klassichen, die nicht $314 ständig ändern aber auch in den anderen.

    Bitte melde dich an, um diesen Link zu sehen.

    Ja, danke Dir, schon richtig.

    Mir ist nicht klar nach was ich da schauen soll. Denn wenn es nicht funktioniert, bzw die Bits nicht gesetzt sind: Ich weiss nicht wieso in diesem einen Fall es nicht passiert.

    Alles sieht normal aus.

    Es ehrt mich dass ihr glaubt ich wäre in der Hardware der Kiste so firm. Bin ich leider nicht.

    für den Fall, dass jemand nochmal reinsehen will: Hier eine Minidemo die ab und wann nicht tut:

    Argl.. so langsam gehen mir jegliche Ideen aus.

    - Programmstart von $0801 mit Basic header auf $c000 verschoben. nix. (ggf Speicherbereiche? Overwrites?)

    - die clear color ram und clear bitmap funktionen ausgeschaltet. nix (ggf overwrites?)

    - load routine ($FFD5) ausgeschaltet. nix. Da scheint es weniger zu kommen, kann aber subjektiv sein.

    - die copy bitmap funktion ausgeschaltet. nix (ggf overwrites?)

    - verwendete zeropage Adressen verändert. nix

    Ich hatte immer die LOAD FUnktion im Verdacht aber das hat keinen Einfluss.

    Es sieht nach einem klassichen Tmining Problem aus. Irgendwas verhindert in Einzelfällen das Einschalten des Raster IRQ

    Ich bau ein mini programm zum testen nur mit dem Teil. Danach geb ich auf....:emojiSmiley-25:

    Sorry, ich mus leider noch einmal hier nach Hilfe fragen, bin mit meinem Latein am Ende.

    Das Problem: In ca. 20% der Fälle scheint der Raster IRQ nicht richtig initialisiert zu werden. Der Bitmap Map Modus wird eingeschaltet aber der IRQ ab Zeile 186 kommt nicht?

    Das kann man auch an der Rahmen farbe sehen. (Siehe shots). Das passiert zufällig an allen 6 möglichen Iterationen des Vorspanns, auch gleich am Anfang.

    Ablauf:

    - Start im Textmodus

    Loop:

    - Datei Laden

    - Raster IRQ starten Bitmap/Textmodus

    - Ausgabe Hires Bitmap und Text, Warten (Press any key)

    - Raster IRQ aus, Bitmap Modus an.

    -> zu Loop .

    Das Ganze wird 6x durchlaufen und funktioniert eigentlich. Ich hätte ja gesagt, dass es am doppelten Umschalten liegen könnte (2x Bitmap an) oder ggf noch ein IRQ kommen könnte. Dazu habe ich Schalter eingebaut, die eine Adress abfragen und dann die IRQ Routinen nichts machen. Dann noch ein Wairtframe (60 lines) eingebaut. Keine Änderung.

    Bitte melde dich an, um diesen Anhang zu sehen.    Bitte melde dich an, um diesen Anhang zu sehen.


    Hier der Code:

    Ich bab mal die Kommentare der Vorbilder zusätzlich dringelassen.

    ;------------------------------------------------

    ;-- Init Split Gfx mode

    ;--

    RASTERIRQLINE_INITGFX = 0

    RASTERIRQLINE_INITTEXT = 186

    RASTERLINE_ADR = $D012 ; current raster line

    IRQFLAGREG_ADR = $D019 ; interrupt flag reg

    frame = $d020 ; frame color

    border = $d021 ; border color

    InitSplitGfxMode

    sei

    ; set address for own raster IRQ function

    lda #<HandleRasterIRQ ; set interrupt vectors, pointing to interrupt service routine below

    sta $0314

    lda #>HandleRasterIRQ

    sta $0315

    ; set raster line

    lda #RASTERIRQLINE_INITGFX ; set rasterline where interrupt shall occur

    sta RASTERLINE_ADR

    lda $D011 ;Zur Sicherheit auch noch

    and #%01111111 ;das höhste Bit für den

    sta $D011 ;gewünschten Raster-IRQ löschen

    lda $D01A ;IRQs vom VIC-II aktivieren

    ora #%00000001

    sta $D01A

    LDA #%01111111 ; switch off interrupt signals from CIA-1

    STA $DC0D

    cli

    rts

    ;------------------------------------------------

    ;-- Exit Split Gfx mode

    ;--

    ExitSplitGfxMode

    sei

    ; set old service routine

    lda #<KRNL_IRQ

    sta $0314

    lda #>KRNL_IRQ

    sta $0315

    ;IRQs vom VIC-II deaktivieren

    lda $D01A

    and #%11111110

    sta $D01A

    cli

    rts

    ;------------------------------------------------

    ;-- Handle Raster IRQ

    ;--

    HandleRasterIRQ

    ; Check if VIC triggered an interrupt (bit 7=1 of $d019)

    lda IRQFLAGREG_ADR

    bmi executerasterirq

    ; Load interrupt control reg. This will clear all interrupts

    lda $DC0D

    cli ; enable interrupts

    jmp KRNL_IRQ

    executerasterirq

    sta IRQFLAGREG_ADR

    lda RASTERLINE_ADR

    bne inittxt ; raster is not 0

    ; is GFX mode at line 0

    lda #$00 ; black

    sta frame

    sta border

    jsr InitBitmapMode

    ; init next raster irq

    lda #RASTERIRQLINE_INITTEXT

    sta RASTERLINE_ADR

    jmp exit

    inittxt

    lda #$02 ; red

    sta frame

    sta border

    jsr InitTextMode

    ; init next raster irq

    lda #RASTERIRQLINE_INITGFX ; set rasterline where interrupt shall occur

    sta RASTERLINE_ADR

    exit

    pla

    tay

    pla

    tax

    pla

    rti

    ;------------------------------------------------

    ;-- Init bitmap mode

    ;--

    InitBitmapMode

    lda $D011 ; bitmap mode on

    and #$9f ; %1 00 11111

    ora #$20 ; %0 01 00000

    sta $D011

    lda $D016 ; hires/multicolor mode select

    and #$EF ; set hires %11101111

    sta $D016

    lda $D018

    lda #$18 ; select bitmap location. %00011000

    sta $D018 ; screen ram at 1*1024 = $0400. bitmap at $2000

    lda $DD00 ; select VICII bank in CIA2 PortA

    ora #$03 ; %00000011 Bank 0

    sta $DD00

    rts

    ;------------------------------------------------

    ;-- Init text mode

    ;--

    InitTextMode

    lda $D011 ; text mode on

    and #$9F ; % 10011111 clear ECM BMM

    sta $D011

    lda $D016 ; multicolor mode off

    and #$EF ; % 11101111 clear MCM

    sta $D016

    lda #$14 ; %0001 010 x see above, screenmem at $0400, charset at $1000

    sta $D018

    lda $DD00 ; select VICII bank in CIA2 PortA

    ; and #$FC ; %1111100 (AND not needed, OR below sets all bits)

    ora #$03 ; %00000011 Bank 0

    sta $DD00

    rts

    detlef: Entschuldige, ich sehe dass du Recht hast und ich hier wirklich zu sehr schwarz-weiss male. Ich hab das mit den Peeks nur erwähnt weil ich davon ausgehe, dass jemand, der mit Assembler anfängt schon etwas mit dem Basic auf dem C64 , und dann damit auch mit diesen Befehlen anfangen kann. Dieses Verständnis könnte man dann ja in eine Einführung in eine Hands-on Einführung in Assembler mit einfließen lassen.

    Aber wie man hier im Thread nachlesen kann, haben das mit dem AND und OR auch in Basic einige nicht verstanden. Was ich wiederum verstehen kann, weil das in Dezimal ohne die ensprechendend Grundlagen einfach schwer verständlich ist.

    Das wäre doch eine gute Gelegenheit, das im Assembler-Kurs so zu erklären, dass man es nachher auch in Basic verstanden hat.

    Wie wäre es mit allen Ansätzen?

    Ich glaube einer der Knackpunkte der Diskussion ist es den Königsweg zu finden. Aber der sieht für jeden anders aus.

    Eine, in der man sofort Ergebnisse am Bildschirm sehen kann, wenn man Bits setzt, ohne vielleicht den Background verstanden zu haben.

    Eine Erklär-Bär Version in der versucht wird es heranführend zu beschreiben.

    Eine mathematische, die den Hintergrund der Zahlensysteme beleuchtet.

    Alle natürlich von klein nach groß erklärend. So kann man dort einsteigen, wo man was nicht kapiert hat und so tief wie man will.

    Am besten noch ein paar kleinere Demos und Probearbeiten dabei.

    Ja das ist irsinnig Aufwand..:whistling:

    An für sich nicht so schwierig. Man schaut sich einfach nur an, wann ein Lämpchen leuchtet. 0=aus, 1=an. Lämchen seien A und B.

    AND: Nur wenn beide Lämpchen leuchten, leuchtet auch der Ausgang, also nur wenn A AND B (AND ist ja das englische Wort für und)

    OR: Wenn A OR B leuchtet (oder eben beide), leuchtet der Ausgang (OR ist ja das englische Wort für oder)

    Ich fand das Beispiel mit Lampen und Schaltern immer sehr "einleuchtend", auch das Treppenhaus- Licht mit drei Schaltern sehr sinnvoll.

    Das erklärt nicht direkt die Bits setzen, liefert aber hoffe ich eine gute Grundlage, insbesondere wenn man dann Transistoren erklärt und dann geht man in die Logik.

    Dort wird der Loader ins BASIC eingehängt und kann vom Prompt und Programmen aus normal per LOAD benutzt werden.

    Er wohnt dann im RAM unter dem ROM, nimmt also BASIC-Programmen keinen Platz weg, und auch der sonst übliche "Erweiterungsbereich" bei $C000..$CFFF bleibt frei.

    Aber... wenn Du das Spiel in BASIC programmierst UND einen Splitscreen haben willst, muss das ja sowieso hier und da mit nativem Maschinencode vermischt werden, oder?

    Klingt super! Vor allem $C000 natürlich.

    Jaein, der Vorspann frisst ja schon durch Hires und die VIC Banks 8K plus ColorRAM, die hab ich eh nicht mehr. Das wird in einem getrennten Programm stattfinden, das ich irgendwie noch in einen Loader integrieren muss.

    Daher kann ich da auch noch etwas freier agieren und der IRQ loader wäre wahrscheinlich gut umzusetzen.

    Beim BASIC Teil hab ich aber bereits 10KB Grafik- und Tondaten unter das BASIC ROM geschoben:thumbsup::saint:

    Gut zu wissen, das Spiel verwendet nur PETSCII, Charset und Sprites.

    Ich bin gerade dabei mir für den BASIC Spiel Teil etwas zusammen zu frickeln, dass Bilder nachgeladen und zusammengebaut werden...aus einem Sprite Tileset :S

    Das ganze Theater liegt darin begründet, dass ich tatsächlich den Orginal Core Game-Code aus 1984 weiterverwende...=O

    Bitte melde dich an, um diesen Anhang zu sehen.

    (CALIRA III - Work in Progress - (c) 2024)

    Danke für die schnelle Antwort!

    Ich habe mir Deinen Loader angesehen, Top dokumentiert! Ich bin immer wieder positiv verwundert wie viele C64 Assembler Profis sich hier tummeln, Hammer!

    Leider ist ein Grossteil des Spiels in BASIC, praktisch die gesamte Game Logik und die ist gross (kompletter BASIC Speicher ist voll).

    Das bereitet immer wieder sehr kompliziertes herumbasteln und auch wenn ich zustimme das Ganze wäre auch in Assembler gut zu machen: Das hat Gründe... dazu evtl mehr später im Forum.

    In der jetzigen Phase der Entwicklung möchte ich nicht so viel Aufwand dort investieren. Wichtig ist den Vorspann zu haben für die Stimmung, gerade für die Tester.

    Ich denke ich schalte dazu einfach nur einen Modus ein und lade dann weiter.

    Danke Dir!

    Wenn ich das jetzt richtig verfolgt habe, ist es nicht möglich während des Ladens die Bildschirm-Modi zu ändern?

    Heisst wenn ich den "Adventure Modus" Splitscreen nutze, oben Hires unten Text, dann kann ich damit nicht laden, auch nicht per IRQ loader?

    Ich müsste ja ständig im VIC umschalten. (Dementsprechend läuft es gerade auch nicht...)

    Die Loader sind mir z.Z. alle eine Numemr zu heftig, ich möchte nur ein möglichst einfaches Intro mit Bild und Text und wollte vermeiden eine lange Ladepause oder loading screen mittdendrin zu haben.

    Wer könnte das beantworten?

    Danke für jedes kurze statement!

    Ich habe zwei mögliche Fehlerquellen ausgemacht:
    1. In den Instruktionen steht, dass man die VIC-Bank (während des Ladens?) nicht mit $DD00 ändern soll. Diese wird aber in meinem Programm gleich zu Beginn geändert (zu $4000). Ich habe es mit $DD02 versucht, aber das hat nicht geklappt. Es hat sich nichts geändert.

    Ich weiß nicht ob man mit der 3D-Grafik und der Tastatursteuerung die Adventures actionlastiger aussehen lassen wollte oder ob man damit noch eine andere Zielgruppe erreichen wollte.

    Es war eben die Zeit, wo der 3D-Beschleuniger-Hype losging. Es war auch eines der ersten Spiele, die zwingend einen 3D-Beschleuniger benötigten. Da waren viele Entwickler der Ansicht, daß man Spiele, die das nicht nutzen, nicht mehr verkaufen könnte. Solche Argumente hört man desöfteren aus Interviews jener Zeit.

    Was das allerdings nicht erklärt, ist diese unsägliche Steuerung. Spiele wie Normality, Ankh oder die ganzen Telltale-Spiele haben es ja letztendlich gezeigt, daß Point'n'Click durchaus mit 3D-Grafik funktioniert. (Normality allerdings mit einem Doom-ähnliche Softwarerenderer)

    Ich bin froh, daß man da bei Grim Fandango immerhin eine Point'n'Click-Steuerung beim Remaster nachgereicht hat. Sehr schade, daß es die bei Escape from Monkey Island nicht auch gibt.

    Die Ansicht dasss man Spiele nicht mehr verkaufen kann, kommt nicht unbedingt von den Entwicklern, sondern vom Publisher und darüber wieder von den Kunden!

    Es war tatsächlich so, dass alles wo nicht 3D draufstand nicht mehr lief, zu der Zeit. (Ausnahmen gab es). Der Unterschied zwischen "nicht mehr lief" ist nicht schwarz/weiss zu sehen. Die Verkaufszahlen reichten einfach nicht mehr für break-even. Die Tatsache dass 3D sehr schlecht altert und longtime 2D mehr Charme hat (i.d.R) war unbekannt.

    Ist uns so passiert:

    - 2D Spiel vorgestellt: Publisher "Warum macht ihr das nicht in 3D? (Kaufen wir nicht)"

    - 3D Spiel released: Publisher "In 2D wäre das besser gewesen, warum habt ihr denn 3D gemacht?..." (Mordgedanken...)

    3D war für alle neu. Etablierte Steuerungen gab es quasi kaum. Und: 3D war ein einormer Aufwand! Keine Tools, keine Erfahrungen, keine Bibliotheken, keine Designguides, keine 3D Editoren (Grafik / Level). Der Grossteil musste selbst erst entwickelt werden.

    Das kostet unglaublich viel Zeit und Geld.

    Da bleibt weniger Zeit für das Design und es entstehen Fehler die man nachher zwar auch sieht aber nicht mehr ändern kann, selbst wenn man wollte. Keine Zeit mehr, kein Geld mehr.

    Ja, dieses Konzept, den Protagonisten einfach in eine Sitation hineinzuwerfen scheint wirklich immer gut funktioniert zu haben. Jedenfalls war es beim ersten Teil von "Runaway - A road adventure" ebenfalls so.

    Was lernen wir daraus? - Es braucht gar nicht unbedingt immer so viel Hintergrundinformationen über einen Charakter, um ihn als Protagonisten zu einer Identfikationsfigur zu machen. Weniger ist oft mehr und es bleibt mehr Platz für die Fantasie des Betrachters/Spielers.

    KLUGSCHEISSEN ON:

    "Fish out of water" kommt aus dem Writing Bereich:

    Bitte melde dich an, um diesen Link zu sehen.

    Das ist ein interessantes setting, da man als Spieler zu Beginn genau das ist. Also quasi ein doppelter Fisch, einmal der Character in ungewohnter Umgebung und der Spieler in neuer Spielumgebung. Klappt fast immer.

    Du kannst ja einfach auch POKEn ohne LISTING. Bleibt alles im Speicher und kann aufeinander aufbauen (Sofern man die Kiste nicht abschiesst wg Tippfehler)

    Ich verstehe jetzt immer noch nicht das Problem. markusk2020 fängt erstmal mit dem Direktmodus auf S.5 an. Dann macht er das in ein Listing. Das finde ich aber auch nicht falsch. Ein Listung hat den Vorteil, dass ich es abspeichern kann. Außerdem kann ich Änderungen vornehmen, falls ich etwas falsch gemacht habe. Klar kann man auch direkt mit einem Listung anfangen. Aber das erste Beispiel ist noch so einfach und kurz, da finde ich das schon OK. Markus arbeitet sich Stück für Stück vor. Zu große Schritte wären für einen Anfänger vielleicht schon zu viel.

    Aus meiner Sicht eins nach dem anderen: Direktmodus -> Listing und nicht Listing -> Direktmodus -> Listing. (Später ist das nicht wichtig nur am Beginn)

    Problem gibt's keins, kann man alles machen. Stichwort Anfänger, wie oben diskutiert und Zielgruppe.

    Oder:

    Bitte melde dich an, um diesen Link zu sehen.

    Das geht aber doch im Assembler gar nicht. Zumindest ist mir da nix bekannt. Spätestens wenn BNE etc. kommen, ist damit auf jeden Fall Schluss.

    Das bezog sich direkt auf Seite 1 den zweiten Satz des PDF "Wenn wir unseren C64 einschalten können wir sofort in BASIC programmieren."

    Können wir, aber auf Seite 3 des PDF: "Und das ist überhaupt kein Problem, denn dies können wir aus Basic heraus mit dem BASIC Befehl

    POKE 5376,162 durchführen."

    Das machst Du auf Seite 4 auch dann (Bild), das ist der Direktmodus und nicht das Listing.

    Du kannst ja einfach auch POKEn ohne LISTING. Bleibt alles im Speicher und kann aufeinander aufbauen (Sofern man die Kiste nicht abschiesst wg Tippfehler)

    Ja, bin genau bei Dir. Es ging mir um die Balance.

    Ohne Kontext war auch nicht gemneint, nur so viel Kontext, dass Anfänger mitkommen können. Kontext der 8 Stunden später mal wichtig werden könnte ist auch nicht gut.

    Moderne Kurse lassen dem Lernenden die Wege offen: Willst du jetzt mehr über den Hintergrund oder weiter Experimentieren?

    Wie habt ihr denn bisher so versucht in die Thematik reinzufinden und was waren die Gründe warum ihr dann wieder aufgegeben habt euch damit zu beschäftigen?

    Für mich ist ein großes Problem, daß man in Assembler nicht ohne weiteres Text ausgeben kann. Wie soll ich denn sehen, wenn was schiefläuft, wenn ich nichtmal mit "PRINT" ("printf", "writeln" oder was auch immer) die Werte von Variablen oder von mir aus Registern ausgeben kann?

    Und schon das grundlegende "Hello World" ist erstmal gar nicht möglich. Wo also anfangen?

    (In dem Spectrum-Video oben wird eine Entwicklungsumgebung namens "ZX Spin" benutzt, in der man im Debug-Modus die Assemblerbefehle in einem großen Programm schrittweise ausführen kann, und dann die Werte aller Register in einem speziellen Fenster angezeigt bekommt. Sowas bräuchte man wohl mindestens. (Daran war damals, 1982, aber gar nicht zu denken. Vermutlich hatten das professionelle Entwickler aber schon auf ihren Workstations. Aber halt nicht der "gemeine Harry" :) .))

    Das kann man gar nicht oft genug betonen: Fast jeder Kurs fängt mit irgendwelchen Erklärungen zu Binär, Op Codes, 2er Komplement und Zahlensystemen an. Das, ganz ehrlich, interessiert gerade am Anfang niemanden (pauschale Vermutung)!

    Und ich halte es auch nur begrenzt für sinnvoll, 2er Komplement ist blanker Unsinn in der Phase.

    Ich fand es hier ganz gut dass dies kaum vorkommt.

    Einfach machen: Mit einfachsten Mitteln direkt in den Bildschirm und in die Register! Man muss sofort was sehen und Erfolge bekommen und das gilt nicht nur für die angeblich "heutige Jugend", das ist mir Anfang 80er auch schon so gegangen.

    Zum Debuggen:

    Ja, das IST ein Problem. Aber dank Entwicklungsumgebungen und Emulator kann man das umgehen. Nur ist das auch zu Beginn recht komplex.

    Daher: Ich finde es gerade sehr spannend auch hier wieder alternative Lösungswege aus den 80ern und 90ern auszugraben:

    - Log Ausgaben:

    Werte direkt in den Screen: A=1 B=2 (Zeichen in ASCII Tabelle suchen), diese entweder direkt oder korrespondiert als Marker ausgeben.

    - Einzelschritt Modus:

    Immer in kleinen Schritten durch das Programm, nie zu viel testen in Assembler. Kleine Blöcke. RTS setzen mittendrin.

    - Fortschrittsmarker

    Wo ist das Programm gerade, bis wohin lief es und ab wann nicht mehr? Screen, Farben, Bildschirm Rahmenfarbe als Signalfarbe nutzen.

    - Modular

    Das Programm in kleine Blöcke aufteilen. Bevor man später größere Zusammenhänge bearbeitet, das Problem in kleine Teile bereits im Konzept aufteilen.

    - Nicht optimieren

    Und wenn es noch so blöd aussieht und offenbart dass die Mathekenntnisse gegen Null gehen: Egal! Wen interessierts? Wenn die Software läuft kann man in späteren Iterationen optimieren.

    - OS nutzen

    Du kannst mit dem Kernel schon etwas ausgeben, am Anfang würde ich den noch nicht abstellen. Es gibt dort eine Reihe nützlicher Funktionen.

    - Details!

    Assembler verzeiht nichts! Jede kleine Abweichung in einem Befehl kann stundenlanges Suchen nach sich ziehen!

    Beispiel: STA verändert keine Flags, LDA schon! (Zero, Negative). Das kann in einer Schleife dysfunktional werden wenn nach einem DEY noch ein LDX,LDA,LDY folgt vor BNE / BEQ, zum Beispiel bei Schleifen die auf den Punkt ohne Null runterzählen sollen.

    Daher: Lernen genau auf die Befehle und Adressarten zu schauen! z.B. Bei LDA <ADRESSLABEL das # vergessen?)

    Wie man das einem Anfänger beibringt ohne zu desillusionieren wäre noch eine Aufgabe...

    - Talk to the duck!

    Sinnvolle Methode kann sein: Talk to the Duck -> Lest eurer Ente (oder was auch immer) genau das vor was der Befehl tun soll und kontroliert ob das auch so dort steht.

    Bitte melde dich an, um diesen Link zu sehen.

    btw Hello World ist wirklich sehr einfach! Es liegt nur daran wie man es erklärt bekommt. Aber ich weiss was Du meinst: ja

    Erst einmal finde ich die Idee sehr gut und das Thema ist auch mutig und sehr interessant. Die Umsetzung hat mir auch gefallen. Hier meine Kommentare soweit ich erst einmal gekommen bin.

    Viele haben ja schon etwas beigetragen, ich beschränke mich dann auf den Rest, der mir aufgefallen ist.

    Zustimmen kann ich, was viele gesagt haben: Doing! Einfach POKE und los geht's, auch wenn man zu dem Zeitpunkt nicht versteht was dahinter eigentlich steckt. So haben wir auch angefangen.

    Für den Beginn würde ich nicht sofort in ein Listing einsteigen sondern den Direktmodus nutzen und kurz erläutern.

    Schließlich wird dieser für viele Aufrufe vorher genutzt.

    Vielleicht ist das für den Schluss gedacht, aber ich habe kein Inhaltsverzeichnis gefunden. Dieses würde ich bei solchen Dokumenten dringend empfehlen, da man darüber direkt in Themen springen will, u.a. später zum Nachschlagen. (PDF Seitenleiste)

    Das kannst Du mit z.B. Word oder Libre automatisch erzeugen lassen aus den Überschriften.

    Ich finde auch es sind zu wenige Kapitel vorhanden, bzw. diese sind zu lang. Unterpunkte wären wichtig.

    Grundsätzlich verstehe ich noch nicht ganz für welche Zielgruppe das Dokument gedacht ist. Einerseits werden absolute Grundlagen erklärt, andererseits Fachbegriffe nicht erläutert. Das Wort "CPU" zum Beispiel ist mit Sicherheit nicht jedem heute noch bekannt. Manchmal Deutsch manchmal Englisch. (Prozessor?)

    In diesem Zusammenhang steht auch das "Sie". Es wirkt heutzutage sehr offiziell, während das Dokument eher locker geschrieben ist.

    Das gilt auch für die Verwendung von "Maschinensprache" und "Assembler. Letzteres ist eh leider mehrdeutig, da dieser auch für Software verwendet wird (Nicht nur hier, sondern allgemein). Verwirrend finde ich das dann auf Seite 3 wo es um das "Nicht merken" geht, der Unterschied der beiden wird mir zumindest nicht klar.

    Du beschreibst zwar einen Zilog Z80 aber im Dokument habe ich kein Wort über MOS, 6502 oder 6510 gefunden.

    Ich bin mir nicht 100% sicher, aber in den Publikationen die ich kenne, wird der Stackpointer nicht als Register gelistet. Wer weiss mehr?

    Warum wird mit der Speicherzelle 5376 begonnen? Ich finde eine gerade Zahl wäre sinnvoller, das wirkt recht merkwürdig in Dezimal. Ich würde auch nicht so oft zwischen den Zahlensystemen wechseln zu Beginn, sondern immer eins nach dem anderen einführen. Binär z.B. ist an der Stelle erst einmal nicht so wichtig.

    Ab Ende Seite drei wird der Kern Deiner ganzen Arbeit beschrieben, die direkte Programmierung in den Speicher. Insgesamt finde ich das bereits sehr gut verfasst und ist wie gesagt etwas, das heute garantiert so (meines Wissens) nach auf keiner Maschine mehr denkbar ist. Das herauszustellen, ein Gerät direkt zu anzusprechen, ist ein USP.

    Das, finde ich zumindest, ist auch nicht verständlich genug erklärt. Dass nun der Prozessor einen Befehl aus dem Speicher ausführt, der dort hinterlegt wird. Hier würde ich mehr Arbeit investieren, bzw. wenn das die meisten (Nicht Programmierer? -> Zielgruppe?) verstanden haben, habe ich nichts gesagt.

    Ich finde den Ansatz über das Schreiben in den Bildschirm (Seite 4 ff) schon ganz gut aber ich würde auch hier noch ein bisschen mehr auf einzelne Punkte eingehen. Vielleicht den üblichen Weg einschlagen, erst etwas in den Bildschirm zu POKEn und dann den BASIC Befehl POKE in 6510 1:1 umsetzen.