... aus dem Thread Hardware zur Sound3:

Quote by smed: Na, dann bist du ja bereit fuer dies hier: 68000: file00.m68 68008: file08.m68 Manuelle Startadresse: Basis +670hex Gruss smed

Hallo zusammen,
ich komm' ja nicht regelmäßig zum basteln und ausprobieren etc. kurzum, ich hab' da mal wieder ein paar Fragen:

Diese Datei, hier file08.m68 ... wie wird die geladen?
Ich bringe die über JADOS auf das System - bspw. auf Laufwerk S:
Aber wie dann weiter - ein einfacher Aufruf am Prompt führt zu einer Fehlermeldung "Falsches Kommando". Wenn ich smed richtig verstehe, muss die "Datei" ja auch über das GP "B = Starten" gestartet werden. Der Hinweis "manuelle Start-Adr. +670h verstehe ich so, dass wenn ich im GP bin und Editanf. mit $00000400 angegeben ist, dass ich dann bei "B = Starten" die Start-Adresse: $00000A70 angeben müsste. ... bin ich da auf dem richtigen Weg?
Doch damit die Datei (die Daten) dann auch gestartet werden, muss sie doch vorher in den RAM geladen werden ... und wie geht das?
Ist das dann der grundsätzliche Umgang mit .m68-Dateien??

Wo kann ich denn sowas eigentlich nachlesen?

Schöne Grüße
Daniel

-----------------------
retroniker

uups, Datei vorher umbenennen in file00.68k - ausfuehrbare Binaerdateien muessen in Jados das suffix .68k haben. Das suffix .m68 ist kein ofizielles Jados suffix.

Dann in Jados vom Prompt aus den Dateinamen (auch ohne suffix) eintippen das laed das File nach $400 und startet es.

Das file ist eigentlich ein relokatives rom image. Warum das ueber jados auch ab $400 startet weiss ich gerade auch nicht.

Jados Handbuch: https://nkcforum.de/ndr/software/soft68/index.html

gruss
smed

PS ich glaube auf der FPDG-GDP sieht die Scrollzeile links irgendwie anders aus als auf original GDP, auch der Hardwarescroll-Bug schlaegt wieder zu. Als workaround vor dem Laden ein cls absetzen.

PSS zum Beenden des Progrmms einfach ganz langsam die Hauptsicherung im Keller rausdrehen

-----------------------
NKC'ler seit 1984 (Pause zw. 1988-2017)
CPU68k,CPU68000,4xROA64,6xIOE,6xGDP,GDPHS,8xSBC2/3,HEXIO,6xKEY,UHR3,PROMER,CENT,SER,SOUND,CAS,6xBUS2,4xBUS3,3xPOW5V,2xTAST..und einen ArduinoMEGA mit auf dem BUS, und eine selbstgebastelte MEM960k und eine FPGA-GDP.

NKC - OpenSource since 1983

Hallo smed,
... alles klar.

Hab' mittlerweile soviel rumprobiert, dass ich viel dazu gelernt habe ... ehrlich wahr

Grüße

-----------------------
retroniker

Hallo,

das Hard-Scroll Problem ist kein Bug. Es ist nur die Folge unsauberer Programmierung. Wenn der Bildschirm gerade durch das GP gescrollt ist und dann in einem Programm der ClrScreen Befehl direkt an die GDP gesendet wird dann bleibt der Scroll natürlich wie er ist (weil außerhalb der GDP und vom GP verwaltet). Man muss beim Programmstart den ClrScreen Befehl vom GP aufrufen. Dann wird auch der Hard-Scroll zurück gesetzt und alles passt dann wenn man direkt via GDP zeichnet. Bei Programmen die das nicht einhalten muss man vor dem starten als Workaround den cls Befehl absetzen.

LG,
Andi

... ich wünsch' dir auch mal schon schöne Weihnachten und ein gutes neues Jahr ...


-----------------------
retroniker

Quote by andi: Hallo, das Hard-Scroll Problem ist kein Bug. Es ist nur die Folge unsauberer Programmierung. Wenn der Bildschirm gerade durch das GP gescrollt ist und dann in einem Programm der ClrScreen Befehl direkt an die GDP gesendet wird dann bleibt der Scroll natürlich wie er ist (weil außerhalb der GDP und vom GP verwaltet). Man muss beim Programmstart den ClrScreen Befehl vom GP aufrufen. Dann wird auch der Hard-Scroll zurück gesetzt und alles passt dann wenn man direkt via GDP zeichnet. Bei Programmen die das nicht einhalten muss man vor dem starten als Workaround den cls Befehl absetzen. LG, Andi

Hallo andi,
ich danke Dir für die Klarstellung, Erklärung und Problembehandlung (muss ich mal ausprobieren). Man könnte sich dann ja eine batch-datei mit den beiden Befehlen schreiben (ClrScreen + Programmaufruf).

Anfangs war ich etwas verunsichert, ob an meiner GDP64HS vielleicht doch nicht alles i.O. ist. Irgendwann bin ich dahinter gestiegen, wie man diesen HW-Scroll manuell auslösen kann und war beruhigt, dass das erwartungsgemäß funktionierte. Schreibt man an Port 61 den Wert 0 (NULL), passiert nämlich gar nix - schreibt man den Wert 8, sieht man deutlich, dass sich da was tut.

... aber so hab' ich halt wieder was dazu gelernt ...

Vielen Dank Euch allen.
Schöne Grüße
Daniel

-----------------------
retroniker

Hallo,
Ja genau richtig.
Wenn ein Programm das für eine normale GDP ausgelegt ist und den Bildschirm direkt via GDP Befehl löscht bleibt das HW-Scroll Register wie es ist. Wenn das Programm aber den ClrScreen GP Trap aufruft wird beides gelöscht und alles passt - weil das GP ja weiss ob eine GDP64HS oder eine normale GDP64 im System ist.

LG,
Andi

Hi,
der Weihnachtsgruss benutzt keine GP Funktionen sondern greift direkt auf die GDP Ports zu. Daher auch die gesonderte 68000 und 68008 Version. Grund dafür war, das mein C cross-compiler für NKC damals sehr rudimentär war und nur auf Geschwindigkeit ausgelegt war und nicht auf Kompatibilität. TRAPs brauchen Zeit, und GP Grafikfunktionen sind teilweise sehr langsam - der Preis des GP 'Kompatibilitätslayers'.

Mittlerweile gibts Andi's gcc cross-compiler setup das auch die GP Traps beinhaltet - das Geschwindigkeits-Problem bleibt aber; für Leute die Ballerspiele programmieren wollen (wie ich).

Damals hatte ich auch keine GDP-HS daher auch keine Initialisierung des Hardwarescrollregisters.

Das war zu der Zeit wo ich dachte das die GDP64 für sowas wie zB SpaceInvaders viel zu langsam sei, und erst mal testen wollte was überhaupt geht. Heraus kam das einiges geht, und hätte es das SpaceInvaders für NKC schon 1984 gegeben - was ja technisch möglich war, hätte es den NKC evt in mehr Kinderzimmer geschafft und vielleicht einen VC20, ZX81, TI-99/4A, Spektrum oder Sinclair QL verdrängt. Der NKC hatte schon immer ein Software-Problem (C64, AtariST, Amiga und MAC nicht) und die meisten NKC Leute sind eher an Hardwarespielereinen interessiert, bzw wollen das Apollo-feeling a la HexIO.

Das file00.m68 file ist ein relokatives ROM Image mit GP Bibliotheks-header ($55 $AA $01 $80 ...). Wenn dies irgendwo ins RAM geladen wird (bzw. in ein EPROM gebrannt wird), kann das Programm über die Bibliotheksfunktion im GP gestartet werden. Die Startadresse ist Ladeadresse + 670hex. So habe ich das gemacht da ich damals auch noch kein Jados hatte und das ROM image direkt, mit einem ArduinoMega als zweite CPU auf dem BUS direkt ins RAM geschrieben habe, und dann (auch per Arduino) das Image über die GP Bibliotheksfunktion automatisch gestartet habe.

Nun aber habe ich Jados und wie ich vor ein paar Tagen zufällig herausgefunden habe: Wenn man das file00 (in .68k umbenennt und) mit Jados über die Komandozeile lädt, startet es auch korrekt - es scheint Jados erkennt beim start einen ggf. vorhandenen Bibliotheksheader, und startet entsprechend das Programm an der korrekten Einsprungsadresse. Evt. ist das irgendwo in der Jados Dokumentation auch so beschrieben, für mich war es jedenfalls neu. Wenn ich nach dem Laden mit Jados auf das GP wechsele und ab $400 'manuell' starte, crasht es erwartungsgemäß, auf $A70 klappts.

Ein beenden des Programms per ESC Taste ist nicht nötig da ja jedes Jahr Weihnachten ist und das Programm problemlos das ganze Jahr durchlaufen kann und auch soll.

Frohe Ostern!
smed

PS Weihnachstsgruss Quelltext: https://nkcforum.de/forumdrc/index.php?mode=viewthread&forum_id=4&thread=51&z=1#post17

-----------------------
NKC'ler seit 1984 (Pause zw. 1988-2017)
CPU68k,CPU68000,4xROA64,6xIOE,6xGDP,GDPHS,8xSBC2/3,HEXIO,6xKEY,UHR3,PROMER,CENT,SER,SOUND,CAS,6xBUS2,4xBUS3,3xPOW5V,2xTAST..und einen ArduinoMEGA mit auf dem BUS, und eine selbstgebastelte MEM960k und eine FPGA-GDP.

NKC - OpenSource since 1983

Hi smed,
vielen Dank für die ausführliche Erklärung.

Grüße Daniel

-----------------------
retroniker