ZXmore Fragen und Antworten

ZX-Team Forum
Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 05.07.2016, 17:13

siggi hat geschrieben:
PokeMon hat geschrieben:Die VDRIVE Schnittstelle wurde implementiert und müsste sich eigentlich so verhalten, wie es den Beschreibungen von siggi und der Interpretation des Quellcodes entnommen werden konnte, ...
Hallo Karl
ich habe mir mal den Treiber-Source angesehen. Mindestens ein Fehler ist drin, der aber erst bei der nächsten Version auffällt :D

Code: Alles auswählen

format zx81 as 'rom'
;LISTON
				// driver code for using vdrive software with ZXmaster
				// usually loaded at 8192 ($2000) but relocatable code for any address
vdrive:
	XOR	A		// entry point for command line usage (default entry point 8192)
	JR	.basic
	XOR	A		// entry point for BASIC program usage (default entry point 8195)
	JR	.basicp
	NOP			// version coding of vdrive driver code (version 0)
	LD	A,$FE		// entry point for assembly program usage (default entry point 8198)
.basicp:
	INC	A		// coded entry point in A, 0=command line, 1=basic program, -1=assembly program
.basic:
Der Einsprung bei 8198 erfolgt da, wo im Source das "NOP" steht (das die Versionsnummer sein soll), nicht da, wo der Kommentar steht (default entry point 8198). Derzeit passiert da nichts (weil NOP ausgeführt wird), bei nächsten Versionen kracht's dann irgendwann mal ...
Das ist kein Fehler, das ist Absicht.
Es gibt genügend 1 Byte Opcodes, die man da platzieren kann um eine Version zu codieren.
Muss ja nicht fortlaufend sein.

$00 NOP
$03 INC BC
$04 INC B
$05 DEC B
$07 RLCA
$09 ADD HL,BC
$0A LD A,(BC)
usw.usw.

In der Regel werden die Register sowieso durch den Funktionsaufruf früher oder später zerstört.
Und selbst wenn nicht, könnte man immer noch
LD A,A
LD B,B
LD C,C
usw. für Versionscodierungen verwenden.
Sehr wahrscheinlich wird es auch nicht so wahnsinnig viele Treiberversionen geben, falls überhaupt.
Möglicherweise wird mal eine falsche oder ungenaue Fehlermeldung angezeigt o.ä.

Was den FAST Modus betrifft, den muss man aus dem Treiber entfernen. Wenn Du das Konzept vom ZXmaster resp. Abfangen des NMI verstanden hast, wird Dir einleuchten, dass im FAST Modus generell keine Kontrolle durch den ZXmaster möglich ist. Sieht auch nicht so schön aus, das dauernde Geflacker, ich habe mal ein Video von dem USB auf Youtube gesehen, meine es war sogar von Dir. Ob FAST Mode nötig ist oder nicht, entscheidet im Zweifel der ZXmaster selbständig. Das Kopieren von Daten über Register ist generell umständlich, könnte aber trotzdem unterm Strich noch einen Tick schneller sein als der USB Treiber heute arbeitet. Das werden wir dann sehen.

Es wäre vielleicht auch gangbar, den direkten Aufruf der FAST Mode Routine CALL $02E7 und CALL $0207 auf einen Adresse im Treiber umzulenken und dort zu prüfen, ob Dein Programm auf einem ZXmaster läuft oder nicht und dann diesen CALL auf FAST wegzulassen. Der CALL auf $0207 ist nicht nötig, stört aber vermutlich auch nicht wenn das System schon im SLOW Modus ist. Ich werde dem USB Treiber (VDRIVE Treiber in diesem Fall) auch noch ein bisschen mehr beibringen an Kommandos um z.B. per Programm die Konfiguration auszulesen (auf welcher Instanz das Programm läuft, wieviel Speicher zugeteilt ist, etc.) oder auch um den ZXmore zu steuern wie ein/ausschalten von Speed Modus oder ähnliches. All das kann auch über den gleichen USB Treiber nur mit anderen Kommandos laufen. Das ist ja erweiterbar. Das kann ich mir ausdenken, Du kannst aber auch gerne Vorschläge machen resp. wir stimmen das dann ab. Dann kannst Du den ZXmore auch mit Deinen Programmen ein wenig steuern.

Was die Startadresse angeht oder generell aktivieren von VDRIVE Treiber oder deaktivieren je nach Konfiguration - das habe ich im ersten Moment mal weggelassen, wird aber auch in der nächsten Version kommen. Ich möchte eigentlich Konfigurationsdaten etc. auch in einem Unterverzeichnis speichern oder laden zwecks besserer Übersicht. Dazu muss das der ZXmaster aber auch erstmal können (Directory Wechsel). Das ist in der ersten Version jetzt noch nicht drin, kommt in der nächsten aber ganz sicher. Das macht halt alles auch recht viel Arbeit, das dürfte klar sein. Aber der ZXmore entwickelt sich halt.

Dass man die zu programmierende Zielinstanz auswählen kann, habe ich damals so vorgesehen. Das bedeutet aber nicht, dass es wirklich immer Sinn macht das Versionsupdate in Instanz 7 oder 6 zu machen. Da sich auch immer wieder Speicherstrukturen von einer Version auf eine andere ändern können, bedarf es doch häufig eines Kaltstarts. Dann eine Instanz 6 oder 7 mit ZXmaster aufzurufen (testweise) ist von mir jetzt so nicht vorgesehen. Diese Abfrage der Instanz kann eher anders herum bei einem Recovery Update sinnvoll sein um eine gecrashte ZXmaster Instanz wiederherzustellen. Dann kann ich das Programm in Instanz 1 (mit Switch) starten, und das Programm laden (ZXmore18.p oder ZXmore19.p) und nach Anweisung an einer bestimmten Stelle den manuellen Switch zurückdrehen.

Für dieses Recovery Update ist es halt notwendig das Programm (ZXmore18.p oder ZXmore19.p) irgendwie zu laden und dann geht das entweder nur über Audio (EAR) oder falls man hat auch über ein ZXpand o.ä. Letzteres hast Du ja glaube ich. Vielleicht geht sogar ein originales VDRIVE - kann ich jetzt so nicht beantworten.

Dass das Updateprogramm von mir ausgiebig getestet wurde, bevor ich das veröffentliche - in dem Punkt musst Du mir leider vertrauen. Falls es wirklich schief gehen sollte (was ich nicht glaube - außer man hat während der Programmierung einen Stromausfall o.ä.) kannst Du über das Recovery Update immer noch einen Rollback machen. Jungsi hat sich ja auch getraut. :wink:

@Jungsi
Die VDRIVE Schnittstelle ist sagen wir mal im Moment noch experimentell und mehr für Programmierung gedacht als tatsächlich für normale Anwender sinnvoll nutzbar. Was man machen kann, ist zunächst den Treiber programmieren. Idealerweise ins Flash ROM ab 8k:

1. Load Data über Tools Menü aufrufen
2. ZXMVDRIV.ROM:8192:1# (in dem Fall ist die Raute wichtig für Flash ROM, sonst wird es nur ins RAM kopiert)
3. in Instanz 1 anschließend in der BASIC Zeile eingeben:
PRINT USR 8192;"L DATEI.P"

Dann wird die Datei vom USB Stick geladen.
Das ist aber nur ein Ersatz, normalerweise ist das Laden über Doppelshift L viel einfacher.
Das ist halt eine Programmierschnittstelle oder eben auch für spezielle Programme, die was nachladen wollen.
Man kann das auch über das RAM laden, muss man aber entweder jedesmal neu eingeben oder man sichert die ganze Instanz für später in einer Datei.
Und man muss natürlich vorher die RAM Einstellung von 16k auf 8k ändern (Beginn des RAM).

Hat schon mal jemand die Backup/Restore Funktion ausprobiert oder das Laden/Speichern von Instanzen ?
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 07.07.2016, 00:08

Hi Karl
PokeMon hat geschrieben: Was den FAST Modus betrifft, den muss man aus dem Treiber entfernen.
?
Im Treiber (in dem kleinen Codeteil, den ich mir angesehen hatte) ist kein FAST-Modus drin! Oder meintest Du den aufrufenden UFM?
Wenn Du das Konzept vom ZXmaster resp. Abfangen des NMI verstanden hast, wird Dir einleuchten, dass im FAST Modus generell keine Kontrolle durch den ZXmaster möglich ist.
Na dann soll halt Dein Treiberteil ein CALL SLOW direkt vor der Endlosschleife absetzen und die Welt ist in Orndung: der Master kriegt seinen NMI und im UFM muß ich nichts ändern. Das ist genauso harmlos, wie wenn ich im BASIC 20 mal SLOW hintereinander aufrufe.
Es wäre vielleicht auch gangbar, den direkten Aufruf der FAST Mode Routine CALL $02E7 und CALL $0207 auf einen Adresse im Treiber umzulenken und dort zu prüfen, ob Dein Programm auf einem ZXmaster läuft oder nicht und dann diesen CALL auf FAST wegzulassen.
Ich will den UFM auch nicht systemabhängig machen, denn ich bin froh, daß ich ihn trotz C in 5K untergebracht habt, damit er auch mit einem dicken USB-Treiber noch in einen 8K Block passt.....
Was die Startadresse angeht oder generell aktivieren von VDRIVE Treiber oder deaktivieren je nach Konfiguration - das habe ich im ersten Moment mal weggelassen, wird aber auch in der nächsten Version kommen. Ich möchte eigentlich Konfigurationsdaten etc. auch in einem Unterverzeichnis speichern oder laden zwecks besserer Übersicht. Dazu muss das der ZXmaster aber auch erstmal können (Directory Wechsel). Das ist in der ersten Version jetzt noch nicht drin, kommt in der nächsten aber ganz sicher. Das macht halt alles auch recht viel Arbeit, das dürfte klar sein. Aber der ZXmore entwickelt sich halt.
Wie schon geschrieben: ich halte nichts davon, daß der Master die Adresse des Treibers kennen muß, denn ich will ihn jederzeit da hinschieben, wo er gerade nicht stört. Deshalb mein Vorschlag, die Master-Aktivierung per CALL ins ROM (auf eine HALT-Anweisung) zu verlegen, damit es von überall her aufgerufen werden kann. Statt in der Endlosschleife wartet dann der Treiber durch ein HALT im ROM auf den NMI und die Einmischung des Masters. Und über die RETURN-Adresse auf dem Stack kann der auch an beliebige Stellen zurückhüpfen zum aufrufenden Programm.
Vielleicht könnte man das ja auch als allgemeinen Aufruf des OS (=Master) verwenden und über Registerinhalte die Art der Funktion (USB-Treiber, Taktumschaltung, ...) mitgeben. Vielleicht könnte man die Register analog wie bei Systemaufrufen im CP/M verwenden ....

Gruß
Siggi
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 07.07.2016, 00:36

Siggi,

ja ich meinte natürlich den UFM. Mir ist halt unklar, wieviel vom USB133.txt Programm UFM und wieviel der eigentliche Treiber ist. Ich schalte definitiv keinen FAST Mode ein, zumindest nicht in meinem Treiber. Was der ZXmaster dann macht, ist seine Sache. Für das Laden eines Programmes ist definitiv FAST Mode erforderlich, weil der komplette Speicher beschrieben wird, da darf kein Display aktiv sein. Beim SAVE wird aus Kongruenz natürlich auch FAST Mode verwendet, damit der geschriebene Bereich nicht während des Speicherns geändert werden kann. Für das Navigieren auf dem USB Stick ist aus meiner Sicht kein FAST Mode notwendig.

Den SLOW Mode kann man natürlich im ZXMVDRIV.ROM Treiber aktivieren. Ist aber im Ergebnis unschön, weil es auf jeden Fall flackert wenn erst FAST Mode und dann danach direkt wieder SLOW Mode aktiviert wird. Sinnvoller wäre es, den FAST Modus nicht zu aktivieren. So aufwändig ist das nun auch wieder nicht für Dich, immerhin musst Du ja Deinen UFM irgendwie mit dem ZXMVDRIV Treiber verschmelzen. Im Ergebnis sind das vielleicht nur 20 Bytes die Du dafür brauchst und die hart codierte Adresse $02E7 kannst Du mit Find & Replace ersetzen durch eine eigene resp. ein Label in Deinem Programm.
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 07.07.2016, 01:31

siggi hat geschrieben: Wie schon geschrieben: ich halte nichts davon, daß der Master die Adresse des Treibers kennen muß, denn ich will ihn jederzeit da hinschieben, wo er gerade nicht stört. Deshalb mein Vorschlag, die Master-Aktivierung per CALL ins ROM (auf eine HALT-Anweisung) zu verlegen, damit es von überall her aufgerufen werden kann. Statt in der Endlosschleife wartet dann der Treiber durch ein HALT im ROM auf den NMI und die Einmischung des Masters. Und über die RETURN-Adresse auf dem Stack kann der auch an beliebige Stellen zurückhüpfen zum aufrufenden Programm.
Vielleicht könnte man das ja auch als allgemeinen Aufruf des OS (=Master) verwenden und über Registerinhalte die Art der Funktion (USB-Treiber, Taktumschaltung, ...) mitgeben. Vielleicht könnte man die Register analog wie bei Systemaufrufen im CP/M verwenden ....

Gruß
Siggi
Siggi,
durchdenk das bitte nochmal in Ruhe. Ich halte das alles für sehr theoretisch. Jederzeit überall hinschieben wo er nicht stört, verlangt relozierbaren Code. Das ist beim UFM133.txt nicht der Fall, wäre eine vermutlich recht aufwändige Umstellung und braucht sicher mehr zusätzlichen Platz als der Einbau einer simplen Abfrage, in welchem Kontext der UFM läuft (normaler ZX81 oder ZXmore). Wobei - wenn Du beides miteinander verschmilzt braucht es nicht eine solche Abfrage. Dann gibt es halt eine fertig kompilierte Version für ZX81 und für ZXmore so wie Du aktuell fertig kompilierte Versionen für 8k, 32k, 40k usw. hast.

Und dass man den Treiber ständig hin und herschiebt im Speicher, halte ich auch für etwas theoretisch. Man überlegt sich halt einmal, wo man das hinhaben will und dann konfiguriert man sich die Instanz. In der neuen Version kannst Du die komplette Speicherkonfiguration sogar in einer .BAK Datei speichern für später/Wiederholung etc. Du kannst ja sogar ein Backup vom gesamten ZXmore machen. Da ist schon deutlich mehr Komfort als bei irgendeinem anderen ZX81. Wenn der Speicher so wahnsinnig knapp ist, muss man sich sowieso fragen, ob man nicht lieber gleich auf den UFM verzichtet wenn der ZXmore das alles von Haus aus kann OHNE den Speicher der Instanz zu benutzen. Dann hättest Du auf einen Schlag 8kB frei. Also sobald die anderen Funktionen wie Datei löschen, Verzeichniswechsel etc. implementiert ist.

Ich mache ja viele Zugeständnisse zwecks Kompatibilität - aber ob das erforderlich ist scheint mir sehr fragwürdig. Man könnte auf einen HALT Befehl springen, über einen Weg dann eine Konfigurationsadresse austüfteln und dann anschließend VDRIVE auf dieser Adresse aktivieren. Den Treiber müsstest Du trotzdem auf diese Adresse laden und anschließend alle Befehle von dort ausführen. Das wäre sozusagen am Anfang ein zusätzlicher Initialisierungsfall, der eine Adresse mitteilt, auf der VDRIVE installiert wurde (ggf. zusammen mit UFM oder anderen Programmen). Da ich vom ZXmaster keinen Zugriff auf das ZX81 ROM resp. den benutzten Funktionen habe, wäre mehr auch gar nicht möglich.

Beispiel:
Adresse $009B steht ein HALT Befehl
Darauf müsstest Du am Anfang einen CALL machen und die Adresse mitteilen wo der Treiber liegt.
Z.B. mit folgender Codesequenz:

Code: Alles auswählen

CALL $009B
DEFW <ADRESSE VDRIVE>
- fortgesetztes Programm -
und anschließend die entsprechenden CALLs in den selbst geladenen ZXMVDRIV Treiber anspringen
Diese Adresse ließe sich dann auch nicht im laufenden Betrieb ändern, weil ich nicht in der NMI Routine x-verschiedene Adressen abfragen kann, also nicht $009B (ob sich was geändert hat) und die VDRIVE Adresse zusätzlich. Da sind Register knapp, Zeit knapp, usw. Apropos Zeit knapp - aus technischen Gründen wird die VDRIVE Adresse auch nur bei jedem zweiten MARGIN abgefragt. Insofern funktioniert das mit einem einfachen HALT auch gar nicht, es sei denn, Du synchronisierst das auch noch mit top/bottom margin. Oder machst ggf. eine Schleife, aus der Dich aber nur der ZXmaster wieder befreien kann. Etwa so:

Code: Alles auswählen

CALL $009B
JR $FB
DEFW <ADRESSE VDRIVE>
- fortgesetztes Programm -
und anschließend die entsprechenden CALLs in den selbst geladenen ZXMVDRIV Treiber anspringen
Irgendwie ist das alles von hinten durch die Brust ins Auge und in meinen Augen wenig sinnvoll. Immerhin bewegt sich Dein Treiber auch nicht von alleine an die Adresse und Du musst zumindest Kopieren, eher sogar aber eine andere Version laden an eine neue Adresse. Und das Ganze nur, weil es Dir zu viel Arbeit ist die VDRIVE Option zu aktivieren und die entsprechende Adresse anzugeben ? Ist da unterm Strich so viel gewonnen ?

Ich würde einmal eine vernünftige Konfiguration machen, dass unter siggi.bak oder wie auch immer speichern und entweder bei Bedarf laden (da wird dann auch die VDRIVE Adresse mit gespeichert) oder gleich vor dem Ausschalten Backup und beim Einschalten Restore wählen. Da sparen wir uns beide einen Haufen Programmier- und Testaufwand und Speicher. :wink:

*edit*
Es wäre vermutlich sogar möglich im laufenden Betrieb die Adresse des VDRIVE zu ändern oder zu deaktivieren (mit $0000 z.B.) weil ich nur die aktuelle Adresse in der NMI Routine abfrage und später prüfe, ob der Stack (Returnadresse) auf den JR $FE Befehl im VDRIVE Treiber zeigt. Da könnte man noch eine Abfrage auf $009B hinzufügen. Ich halte das aber trotzdem für wenig sinnvoll.
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 07.07.2016, 07:54

PokeMon hat geschrieben:
siggi hat geschrieben: Wie schon geschrieben: ich halte nichts davon, daß der Master die Adresse des Treibers kennen muß, denn ich will ihn jederzeit da hinschieben, wo er gerade nicht stört. Deshalb mein Vorschlag, die Master-Aktivierung per CALL ins ROM (auf eine HALT-Anweisung) zu verlegen, damit es von überall her aufgerufen werden kann. Statt in der Endlosschleife wartet dann der Treiber durch ein HALT im ROM auf den NMI und die Einmischung des Masters. Und über die RETURN-Adresse auf dem Stack kann der auch an beliebige Stellen zurückhüpfen zum aufrufenden Programm.
Vielleicht könnte man das ja auch als allgemeinen Aufruf des OS (=Master) verwenden und über Registerinhalte die Art der Funktion (USB-Treiber, Taktumschaltung, ...) mitgeben. Vielleicht könnte man die Register analog wie bei Systemaufrufen im CP/M verwenden ....

Gruß
Siggi
Siggi,
durchdenk das bitte nochmal in Ruhe. Ich halte das alles für sehr theoretisch. Jederzeit überall hinschieben wo er nicht stört, verlangt relozierbaren Code. Das ist beim UFM133.txt nicht der Fall, wäre eine vermutlich recht aufwändige Umstellung und braucht sicher mehr zusätzlichen Platz als der Einbau einer simplen Abfrage, in welchem Kontext der UFM läuft (normaler ZX81 oder ZXmore).
Eben nicht!. Das ist ein sehr praktischer Fall, denn UFM und USB-Treiber V1.33 laufen derzeit bei 8K, 16514, 32K und 40K. Und das nicht aufwändig: beim USB-Treiber gibt man in ASDIS die neue Laufadresse ein und assembliert neu, beim UFM erzeuge ich alle Versionen auf einen Schlag innerhalb einer Batch-Datei (mit verschiedenen ORG-Adressen)
Und dass man den Treiber ständig hin und herschiebt im Speicher, halte ich auch für etwas theoretisch.
Und das eben auch nicht: ich hatte zuvor beschrieben, wie ich bei der (Weiter-)Entwicklung des UFM mit 2 unterschiedlichen Versionen auf verschiedenen Adressen zugleich arbeite. Ich "schiebe" da zwar nicht, lade mir eine passende Version aber da hin, wo ich sie gerade brauche (wo sie nicht stört)
Man überlegt sich halt einmal, wo man das hinhaben will und dann konfiguriert man sich die Instanz.
Eben das will ich nicht, denn das brauche ich derzeit ja auch nicht. Bisher habe ich alle Freiheiten und will mir nicht für jede USB-Treiber nutzende Applikation X Konfigurationen (für X Laufadressen) erstellen, die jede nur eine Treiberinstanz unterstützen, ich aber u. U. 2 nutzen will ...
Ich mache ja viele Zugeständnisse zwecks Kompatibilität - aber ob das erforderlich ist scheint mir sehr fragwürdig. Man könnte auf einen HALT Befehl springen, über einen Weg dann eine Konfigurationsadresse austüfteln und dann anschließend VDRIVE auf dieser Adresse aktivieren.
Wieso eine Konfigurationsadresse "austüfteln"?
Vorgehensweise wäre: Annahme: HALT im Rom steht auf Adresse 0815:
NMI kommt und Master wird wach:

Code: Alles auswählen

POP Caller-Adresse
Wenn Caller-Adresse=0815: huchu, das war ein OS-Aufruf durch eine Applikation:
{
  POP Applikationsadresse
  Wenn OS-CALL = USB-Treiber (ist derzeit der eizige, da fällt die Auswahl nicht schwer, also gehts erstmal immer hier weiter, (ansonsten: OS-CALL-Code könnte in Register A stehen)) :
  {
       call USB-Funktion des MASTER
       Schalte BASIC-ROM wieder ein
       JUMP Applikationsadresse (zurück zum aufrufenden Treiber)
  }
}
; REM: normales NMI-Handling
Und der Code im Treiber wäre dann so:

Code: Alles auswählen

 ld a, OS_CALL_USB_TREIBER ; derzeit noch unnötig, aber damit's zukunftskompatible ist ....
 call SLOW; damit NMI an ist
 call 0815; OS aufrufen
....
Und das kann von jeder Adresse aus erfolgen ...
Beispiel:
Adresse $009B steht ein HALT Befehl
Darauf müsstest Du am Anfang einen CALL machen und die Adresse mitteilen wo der Treiber liegt.
Der Treiber HAT schon mitgeteilt, wo er liegt: seine Adresse liegt auf dem Stack als Return-Adresse des Calls. Die wird (wie oben beschrieben) aber nur zum Rücksprung gebraucht, nicht zur Selektion der auszuführenden Funktion.
Diese Adresse ließe sich dann auch nicht im laufenden Betrieb ändern, weil ich nicht in der NMI Routine x-verschiedene Adressen abfragen kann, also nicht $009B (ob sich was geändert hat) und die VDRIVE Adresse zusätzlich.
Es müßte nur die 0815 bzw. $0098 geprüft werden, nicht die "VDRIVE-Adresse", allenfalls ein OS-Call-Code im A-Register .....

Wie auch immer: selbst wenn ich den UFM anpasse: ich hatte ja schon geschrieben, daß viele andere Applikationen auch den USB-Treiber benutzen. Sollen die alle angepaßt werden? SOUND/TURBOSOUND-Player, DIA/HIRES-Bild-SHOW? Und MOVEALL läuft fast immer im FAST, ruft also auch MEFISDOS und USB-Treiber im FAST auf. Selbst wenn ich UFM anpasse: das Problem kommt an anderer Stelle wieder .....
Und an anderer Stelle rufen BASIC-Programme den Treiber auf: sollen die nun alle auf einen M/C-Aufruf umgebaut werden müssen?

Gruß
Siggi
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 07.07.2016, 12:34

Siggi,
Du musst doch Deine Programme sowieso anpassen.
Zumindest kannst Du nicht die Adresse 8198 o.ä. anspringen sondern dann besagte Adresse $009B.
Zum Beispiel, da musst Du Deine Programme doch auch ändern.

Das zweite Problem ist, ein HALT reicht nicht aus weil nicht sichergestellt ist, dass bereits beim nächsten NMI auf VDRIVE geprüft wird.
Das ist auch performancetechnisch schwierig zu handeln, ich bin froh einen stabilen Weg implementiert zu haben.
Da hängt das gewissermassen wie andere Sachen auch in der Keyboardroutine resp. ist damit verknüpft und wird nur bei jedem zweiten Margin aufgerufen.

Das dritte Problem ist, dass ich die Daten aufbereitet brauche. Ich kann im ZXmaster nicht den ZX81 Stack auswerten weil sich kein ZX81 Code im ZXmaster ROM befindet. Du wirst nicht darum herumkommen, ein Stück Code in Deine Programme zu integrieren (ZXMVDRIV.BIN). Ich habe mal Deine in USB133.txt dokumentierte Schnittstelle (Funktionen) implementiert. Das was Du Dir jetzt hier wünscht, ist eine vollkommen neue Schnittstelle. Und wenn Du Dir Deine Treiber fertig konfigurierst, kannst Du das ja hier auch tun. Auch im Batch. Du kannst übrigens auch den ZXMVDRIV im ASDIS neu kompilieren. Musst Du nur Deine Source anpassen resp. den Treiber hinzufügen.

Und wenn Du im A Register Funktionen übergeben willst, ist das auch etwas was nicht konform ist mit USB133.txt
Du kannst mich nicht erst auf diese existierende Schnittstelle verweisen und dann nach Implementierung eine andere Schnittstelle fordern.
Kannst Du schon aber dann hätte man gleich was Neues ausdenken können (was wiederum nicht kompatibel zum Vorhandenen ist).

Was ich nicht verstehe, dass Du niemals in Erwägung gezogen hast und eine Art Memorymanagement zu realisieren wo was liegt - zumindest für Deine eigenen Programme. Von denen es ja offenbar einen Haufen gibt. Von fast jedem Programm oder Treiber gibt es mindestens 3 Versionen für 3 verschiedene Adressbereiche. Ich denke die wirklichen Nutzer kann man hier an einer Hand abzählen und dass da wirklich jeder weiß, was er wann auf welche Adresse in welcher Reihenfolge laden muss um welche Wirkung zu erzielen halte ich auch für fraglich.

Die Programmierung ist aufwändig genug - ich kann da nicht noch für alle möglichen Anwendungsfälle Individualprogrammierung anbieten. Zumal Du es selbst könntest wenn Du wolltest. Und schließlich sind es ja auch Deine Programme und nicht meine. :wink:
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 07.07.2016, 15:03

PokeMon hat geschrieben:Siggi,
Du musst doch Deine Programme sowieso anpassen.
Zumindest kannst Du nicht die Adresse 8198 o.ä. anspringen sondern dann besagte Adresse $009B.
Zum Beispiel, da musst Du Deine Programme doch auch ändern.

...

Das dritte Problem ist, dass ich die Daten aufbereitet brauche. Ich kann im ZXmaster nicht den ZX81 Stack auswerten weil sich kein ZX81 Code im ZXmaster ROM befindet. Du wirst nicht darum herumkommen, ein Stück Code in Deine Programme zu integrieren (ZXMVDRIV.BIN). Ich habe mal Deine in USB133.txt dokumentierte Schnittstelle (Funktionen) implementiert. Das was Du Dir jetzt hier wünscht, ist eine vollkommen neue Schnittstelle. Und wenn Du Dir Deine Treiber fertig konfigurierst, kannst Du das ja hier auch tun. Auch im Batch. Du kannst übrigens auch den ZXMVDRIV im ASDIS neu kompilieren. Musst Du nur Deine Source anpassen resp. den Treiber hinzufügen.

Und wenn Du im A Register Funktionen übergeben willst, ist das auch etwas was nicht konform ist mit USB133.txt
Du kannst mich nicht erst auf diese existierende Schnittstelle verweisen und dann nach Implementierung eine andere Schnittstelle fordern.
Kannst Du schon aber dann hätte man gleich was Neues ausdenken können (was wiederum nicht kompatibel zum Vorhandenen ist).
Hi Karl
da hast Du was anders verstanden, als ich es gemeint habe:
die Schnittstelle des bisherigen USB133-Treibers soll unverändert bleiben und über 8192 aufgerufen werden, damit alle existierenden Programme lauffähig bleiben. Und nur in dem Treiberstückchen von Dir, das auf 8192 beginnt, liegt die spezielle Anpassung auf ZXMaster:
Einschalten SLOW, damit NMI läuft
ggf. Laden des A-registers für OS-Function-Code (damit man für weitere/zukünftige OS-Calls gerüstet ist)
Sprung ins ROM auf $009B (oder 0815 :wink: )

Ich habe keine neue Schnittstelle aus Sicht des Anwendungsprogramm gefordert (also immer noch PRINT USR 8195; "S ebbes"), nur die Schnittstelle zum Aufruf des Masters will ich ohne Notwendigkeit einer Konfiguration der Ablageadresse des USB-Treibers haben. Und über die Inhalte des Z80-Stacks, wo die ganzen Call-Adressen draufliegen, müßte das gehen. Den kannst Du ja auslesen, auch ohne ZX81-ROM. Der müste ja die Struktur wie bei einem "normalen" NMI haben. Oder etwa nicht?

Gruß
Siggi

Nachtrag: die Sache mit dem OS-Function-Code sollte nur vereinfachen, zu erkennen, aus welchem Grund der Master anspringt. Wenn das über den HALT über eine Adresse im ROM passiert (118 in einer Datentabelle!), die sonst nicht "ausgeführt" wird (weil kein Opcode, sondern Datum aus Sicht des ZX81-ROM), dann ist klar, daß es der USB-Treiber war (egal wo er gerade liegt, seine Adresse also nicht "konfiguriert" sein muß!), weil ja sonst keiner auf dieser Stelle "läuft". Eigentlich ist damit alles klar, auch ohne zusätzlichen OS-Function-Code in A.
Der OS-Function-Code im A könnte nur später zur Unterscheidung eines USB-Treiber-HALTS von einem anderen OS-Call (Umschaltung Taktfreqzenz) dienen, der auch über dieses HALT erfolgen könnte ...
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 07.07.2016, 17:14

Siggi,
Du siehst ja selbst, dass Du dafür Änderungen in Deinem Programm einbauen musst.
1) musst Du woanders hinspringen
2) musst Du den HALT Befehl mehrfach anspringen (in einer Schleife bis der ZXmaster bereit ist, kann in diesem oder im nächsten Frame sein)
3) musst Du dann selbst den String auswerten, weil ich das nicht machen kann in der ZXmaster Instanz.

Minimum müsstest Du mir einen Pointer auf den fertigen String "L DATEI.P" geben, wenn Du alles auf den Stack legen willst.
Denn irgendjemand müsste ja diesen Codeteil auch noch ausführen:

Code: Alles auswählen

        RST     $20             // read parameters
        CALL    $0F55           // calculate expression of parameters
        LD      A,($4001)
        ADD     A,A             // check bit 6, result type, 0=string, 1=numeric
        JP      M,$0D9A         // stop with error
Aber das ist für mich eine zweite Schnittstelle neben den Einsprüngen auf 8192,8195,8198.
Und was die Steuermöglichkeiten angeht - ja könnte man über Register machen.
Wäre aber auch über die gleiche Schnittstelle mit einem Textstring möglich.
Z.B. ": RC" für Read Config.

Man könnte vielleicht auch zwei HALT Befehle nacheinander direkt in Deinem Treiber aufrufen. Dann hätte man a) das Problem mit der Schleife gelöst (mehr als 2 HALT werden nicht nötig sein) und b) sind zwei aufeinanderfolgende ausgeführte HALT ungewöhnlich genug um hier zu erkennen, dass ein Eingriff vom ZXmaster gewünscht ist. Kommt glaube ich extrem selten vor, zumindest ist mir dazu noch kein Code begegnet. Das läßt sich recht einfach prüfen und das Programm kann man dann gezielt nach dem zweiten HALT fortsetzen. Dann wäre überhaupt keine Einsprungadresse im ROM notwendig.

Insgesamt klingt das aber eher nach der eierlegenden Wollmilchsau. :o
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 08.07.2016, 20:20

PokeMon hat geschrieben:Siggi,
Du siehst ja selbst, dass Du dafür Änderungen in Deinem Programm einbauen musst.
1) musst Du woanders hinspringen
2) musst Du den HALT Befehl mehrfach anspringen (in einer Schleife bis der ZXmaster bereit ist, kann in diesem oder im nächsten Frame sein)
3) musst Du dann selbst den String auswerten, weil ich das nicht machen kann in der ZXmaster Instanz.
Hi Karl
das sehe ich ganz anders. Und da wir offensichtlich unterschiedliche Sichtweisen haben und Benennungen nicht klar sind, will ich hier mal meine Sprechweise benennen und die USB-Softwarearchitektur mal als Bildchen bringen. Denn ich verstehe nicht, was Du mit "Änderungen in Deinem Programm" meinst. Statt von "Programm" allgemein spreche ich lieber von "Treiber" oder "Applikation".

Hier also das Bildchen, wie Hardware, Treiber und Applikationen zusammenspielen:

Code: Alles auswählen

--------------------------------------------------------
           Applikations-Schicht

                   UFM.C
                   MOVEALL.P
                   TURBOPLAYER.P
                   DIASHOW.P
                   ....

+--------- USB-Schnittstelle 8192/8195/8198 - ------------+
|                                                         |
|                     Treiber-Schicht                     |
|                                                         |
|                   |                  |                  |
|                   |                  |                  |
| ZXMore USB Treiber| VDRIVE PIO       | VDRIVE Sparifc.  |
| (im Zx81-Kontext) |    USB Treiber   |    USB Treiber   |
|                   |    V1.33         |                  |
|                   |                  |                  |
|                   |                  |                  |
+-------------- Hardwarenahe-Schicht --+------------------+
|                   |                  |                  |
| ZxMore USB Treiber| PIO-SPI-Interface| Sparinterface    |
| (im ZxMaster-     | VDRIVE Hw/Sw     | VDRIVE Hw/Sw     |
|      Kontext)     |                  |                  |
|  USB Hw/Sw        |                  |                  |
|                   |                  |                  |
|                   |                  |                  |
|                   |                  |                  |
+-------------------+------------------+------------------+
     ZXMore                ZX81              ZX81NU
Die "Applikationen" "sehen" nur die Treiber-Schicht und müssen nur die "USB-Schittstelle 8192/8195/8198" bedienen können, müssen aber nicht wissen, welche Hardware (PIO-Interface, Sparinterface, MxMore-USB-Interface) "darunter" liegt und welche Eigenheiten diese haben. Und sie müssen auch nicht wissen, wie die Daten "unterhalb" der "8192/8195/8198" weitergereicht werden: ober per Bit-Banging, per NMI, Wurmloch oder durch Beamen: das muß keine Applikation wissen, nur der passende "Treiber".

Die "Treiber" müssen zur Applikation hin die "USB-Schittstelle 8192/8195/8198" bedienen. Und müssen zur Hardware hin deren Eigenheiten bedienen und die von der Applikation gewünschte Funktion an die Hardware weiterreichen. Sie dürfen nicht annehmen, daß die Applikation irgendwelche Eigenheiten der Hardware kennt und diese berücksichtigt. Sie müssen sich selbst darum kümmern: Bits bereitstellen, Würmer füttern, NMI einschalten, Scotty rufen :wink:

Nun zum ZXMore-Treiber. Dies ist der Teil der nach meinem Verständnis im ZX81-Kontext (siehe Bild) die "USB-Schittstelle 8192/8195/8198" bedient (derzeit nur die Teilmenge LOAD und SAVE):

Code: Alles auswählen

format zx81 as 'rom'
;LISTON
				// driver code for using vdrive software with ZXmaster
				// usually loaded at 8192 ($2000) but relocatable code for any address
vdrive:
	XOR	A		// entry point for command line usage (default entry point 8192)
	JR	.basic
	XOR	A		// entry point for BASIC program usage (default entry point 8195)
	JR	.basicp
	NOP			// version coding of vdrive driver code (version 0)
	LD	A,$FE		// entry point for assembly program usage (default entry point 8198)
.basicp:
	INC	A		// coded entry point in A, 0=command line, 1=basic program, -1=assembly program
.basic:
	PUSH	AF		// save entry point
	RST	$20		// read parameters
	CALL	$0F55		// calculate expression of parameters
	LD	A,($4001)
	ADD	A,A		// check bit 6, result type, 0=string, 1=numeric
	JP	M,$0D9A 	// stop with error
	JR	$FE		// endless loop till command is processed from ZXmaster
	POP	AF
	RLCA			// copy bit 7 into carry
	LD	A,($4000)	// get already error code but keep flag register :-)
	JR	NZ,.basip	// jump if basic/assembly program entry for quite output
	INC	A		// check if error occured and get correct error code
	JR	NZ,.baserr
	RST	$08		// success message and back to BASIC
	db	$FF
.basip:
	JR	C,.mcode	// jump if assembly program option
	INC	A		// retrieve error code
	LD	($4032),A	// and store in SEED variable (16434)
	RST	$08		// return to BASIC with no error (hidden in variable)
	db	$FF
.mcode:
	INC	A		// retrieve error code
	LD	($4032),A	// and store in SEED variable (16434)
	LD	A,$FF		// clear system error code for continue assembly program (hidden error)
	LD	($4000),A
	RET			// return to calling program
.baserr:
	LD	B,0		// just cleared as BC is used for string length while not more than 255 bytes
	CALL	$0AC8		// get runtime address through calling official ZX81 BASIC routine
.bascalc:
	LD	DE,errnodisk-.bascalc	// get offset to error message
	CP	$07
	JR	Z,@f			// no disk error
	LD	DE,errnofile-.bascalc
	CP	$03
	JR	Z,@f			// no file error
	LD	DE,errsyntax-.bascalc	// offset to syntax error (default)
@@:	ADD	HL,DE		// calculate real address from runtime address and offset
	LD	C,(HL)		// read length of string
	INC	HL
	EX	DE,HL		// start address of string in DE, length in BC
	CALL	$0B6B		// official print string routine from ZX81 BASIC rom
	EX	DE,HL		// get back address to return to BASIC with error code
	JP	(HL)		// finish
errsyntax:
.cnt:	db	.end-.beg	// size of message
.beg:
	dbzx	'SYNTAX ERROR'	// message
.end:
	RST	$08		// return to BASIC
	db	$00		// BASIC error code 1
errnofile:
.cnt:	db	.end-.beg
.beg:
	dbzx	'FILE NOT FOUND'
.end:
	RST	$08
	db	$02		// BASIC error code 3
errnodisk:
.cnt:	db	.end-.beg
.beg:
	dbzx	'DISK NOT FOUND'
.end:
	RST	$08
	db	$06		// BASIC error code 7
Nach meinem Kenntnisstand wird die 8192/8195/8198-Schnittstelle damit erfüllt. Allerdings wird in diesem Treiber eine Eigenheit der Schnittstelle innerhalb des "ZXMore-Treiberteil im ZX81-Kontext" und dem "ZXMore-Treiberteil im ZxMaster-Kontext" noch nicht abgehandelt: diese Schnittstelle funktioniert nur bei aktivem NMI und somit im SLOW-Mode. Während andere USB-Treiber (für PIO oder ZX81NU) über die 8192/8195/8198-Schnittstelle im SLOW und FAST aufgerufen werden können, setzt der ZxMore-Treiber voraus, daß "oben" bekannt ist, daß er nur im SLOW-Modus (mit aktiven NMI) laufen kann und auch so aufgerufen wird. Aber diese Annahme ist falsch.
Das kann einfach behoben werden, wenn der "ZXMore-Treiberteil im ZX81-Kontext" selbst auf SLOW schaltet.
Das war einer meiner Verbesserungswünsche.

Meine weiteren Vorschläge betrafen aber nur die Schnittstelle zwischen "ZXMore-Treiberteil im ZX81-Kontext" und "ZXMore-Treiberteil im ZxMaster-Kontext", die derzeit nur funktioniert, wenn der ZxMore "konfiguriert" ist und die Treiberadresse kennt.

Würde die Treiberadresse nicht statisch (per Konfiguration) dem ZxMaster mitgeteilt werden, sondern dynamisch (zur Laufzeit des Treibers per Call ins ROM, wodurch dessen Laufadresse auf dem Z80-Stack liegt und dort vom ZxMaster ausgelesen werden könnte) dem ZxMaster zukommen, wäre der ZXmore genauso flexibel hinsichtlich einer geänderten Laufadresse des Treibers wie es ZX81 und ZX81NU derzeit schon sind.

Weder die 8192/8195/8198-Schnittstelle, noch die Applikationen wären davon betroffen, das passiert alles nur innerhalb des ZxMore-Treibers.

Bleibt es bei der statischen Konfiguration wie derzeit, funktioniert die 8192/8195/8198-Schnittstelle dennoch. Nur die Flexibilität hinsichtlich Treiber-Adressänderungen ist minimiert ...

So, ich hoffe daß nun meine Sichtweise klarer ist und bisherige Mißverständnisse damit behoben werden können. Sollte dennoch was unklar/mißverständlich sein, können wir gern mal telefonieren. Das wäre wohl einfacher, als weiter das Forum zu strapazieren ...

Gruß
SIggi
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 08.07.2016, 22:35

siggi hat geschrieben: Die "Applikationen" "sehen" nur die Treiber-Schicht und müssen nur die "USB-Schittstelle 8192/8195/8198" bedienen können, müssen aber nicht wissen, welche Hardware (PIO-Interface, Sparinterface, MxMore-USB-Interface) "darunter" liegt und welche Eigenheiten diese haben. Und sie müssen auch nicht wissen, wie die Daten "unterhalb" der "8192/8195/8198" weitergereicht werden: ober per Bit-Banging, per NMI, Wurmloch oder durch Beamen: das muß keine Applikation wissen, nur der passende "Treiber".

Die "Treiber" müssen zur Applikation hin die "USB-Schittstelle 8192/8195/8198" bedienen. Und müssen zur Hardware hin deren Eigenheiten bedienen und die von der Applikation gewünschte Funktion an die Hardware weiterreichen. Sie dürfen nicht annehmen, daß die Applikation irgendwelche Eigenheiten der Hardware kennt und diese berücksichtigt. Sie müssen sich selbst darum kümmern: Bits bereitstellen, Würmer füttern, NMI einschalten, Scotty rufen :wink:
Telefonieren bringt da glaube ich nicht viel mehr. Ist ein Forum nicht genau für diesen technischen Part da ?
Da kann man zumindest was nachlesen, Code posten, usw.

Deine Betrachtungsweise hat einen Schönheitsfehler. Der ZXmore bedient jetzt schon die o.g. 8192/8195/8198 Schnittstelle wenn man mal vom reduzierten Funktionsumfang und dem fehlenden SLOW Mode absieht. Der ZXmore Treiber kann sozusagen mehr als alle anderen Treiber, er ist relozierbar. Vorteil: Du brauchst nur einen Treiber resp. eine Version. Das ist bei den existierenden Treibern wohl nicht der Fall - zumindest nicht beim USB133.txt. Da hast Du verschiedene Versionen für verschiedene Adressbereiche. Oder kompilierst sie auf Bedarf. Derzeit brauche ich also gar nichts ändern und bin dabei mit 8192/8195/8198 ebenbürtig (bis auf derzeit nur LOAD und SAVE implementiert).

Weiterhin unterschlägst Du hier, dass sich diese Treiber auch auf einem ZX81 oder ZX81NU nicht von alleine installieren. Du musst also auch diese System nach Wunsch konfigurieren. Ggf. sogar Speicher aufrüsten (je nachdem was Du noch so laden willst) usw.usw. Das nenne ich mal Grundkonfiguration. Dass es Dir zu viel Arbeit ist EINMALIG im ZXmore eine solche Grundkonfiguration vorzunehmen (Festlegen der VDRIVE Adresse pro Instanz im Menü) finde ich ehrlich gesagt eigenartig. Das ist genauso flexibel wie einen Treiber für ZX81 oder ZX81NU laden oder auf eine andere Adresse laden.

Es ist nun nicht so, dass ich Deine Ausführungen nicht verstehe, ich bin nur anderer Meinung als Du. Du propagierst z.B. eine strikte Trennung von Treibern und Applikationen, die Du aber selbst auch nicht einhältst. Nehmen wir mal das USB133.txt welches Du hier als "Dokumentation" gepostet hast - da verschmilzt Du nicht nur Treiber und UFM miteinander sondern nutzt sogar die Einsprungpunkte in anderer Form. Die Applikation wird auf Adresse 8192 gestartet und der BASIC Aufruf wird auf Adresse 8201 verbannt. Damit verletzt Du Deine Regeln hier gleich zweimal und Deine Argumentation erscheint mir hier eher willkürlich:

Code: Alles auswählen

          8000     JP UFM         C3B88B
          8003     JP USB2        C30481
          8006     JP USB3        C31581
          8009     JP USB1        C30B81
Und dass der Treiber auf SLOW Mode umschaltet kann man ja noch reinbringen. Da reicht ein CALL auf $0207 im Treiber bevor die Schleife JR $FE ausgeführt wird - erfordert aber eine Anpassung des Offsets. Genau dafür ist die Versionsnummer (derzeit NOP) im Treiber. Wird es dann bei der nächsten Version geben. Neue Features werden bei neuen Produkten oder Weiterentwicklungen meistens dankbar aufgenommen, aber es darf sich auch nichts ändern. Wenn ich einen Benziner fahre aber trotzdem darauf bestehe, dass dieser genauso nagelt wie der vorherige Diesel, dann wird's halt manchmal schwierig. :wink:
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 08.07.2016, 23:18

Jetzt habe ich das Video wiedergefunden.
Da wird zwar der Network File Manager vorgestellt, da flackerts beim Navigieren aber vermutlich genauso wie beim VDRIVE (was ich nicht da habe).
https://www.youtube.com/watch?v=Y4PRiQq5VZs

Übrigens ist das mit dem SLOW oder FAST Mode aus meiner Sicht eine Sache, die der Driver handeln sollte und nicht die Applikation. Also in dem Fall ist es eigentlich richtig, dass der ZXmore den FAST Mode nicht einschaltet, wenn er ihn nicht braucht. Das ist aus meiner Sicht eher ein Designfehler weil der FAST Mode sicherlich nur aus technischen Gründen gewählt wird (weil das VDRIVE oder dessen Implementierung das braucht) und nicht weil das wahnsinnig prickelnd aussieht (siehe Video ab 1:10).

Wie bereits geschildert ist es für einen Aussenstehenden schwer zu erraten wieviel von USB133.txt Treiber ist und wieviel Applikation. Es spricht aber aus meiner Sicht viel dafür, den FAST Mode in den Treiber zu verlagern. Wenn man sich mal die Videos zum ZXpand ansieht, da kann man ja flackerfrei navigieren. Wäre doch mal eine Verbesserung. Beim Laden vom Netzwerk (später, so ca. 3:10) flackert es ja auch nicht wenn man in den Directories navigiert. Wahrscheinlich, weil die Netzwerkkarte (WIZ Modul) auch keinen FAST Mode braucht.
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 09.07.2016, 09:30

PokeMon hat geschrieben: Übrigens ist das mit dem SLOW oder FAST Mode aus meiner Sicht eine Sache, die der Driver handeln sollte und nicht die Applikation.
Heisser Tipp von mir: es macht auch Sinn, in Applikationen den FAST-Mode einzuschalten: sie läuft dann viel schneller (z. B. MOVEALL) :mrgreen:
Wenn man sich mal die Videos zum ZXpand ansieht, da kann man ja flackerfrei navigieren.
Wenn Du Dich näher mit dem ZXPand beschäftigst, dann merkst Du schnell, daß man zwar flackerfrei navigieren kann, aber im FAST-Mode nichts sieht. Auch Charlie hat es nicht für notwendig erachtet, den SLOW-Mode einzuschalten, obwohl der User was sehen will :roll:

Gruß
Siggi
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 09.07.2016, 09:50

siggi hat geschrieben:************************* Beitrag zu Update auf 1.9 umgebettet aus dem Info/Updates-Thread *********************************

Ich habe den Update von 1.8 nach 1.9 probiert (aus Instanz 1): habe erstmal Instanz 7 aktualisiert -> geht nicht. Dann habe ich Instanz 5 aktualisiert -> geht nicht. Instanz 5 habe ich mehrfach probiert, ging aber nie. Von Instanz 0 habe ich deshalb mal die Finger gelassen ...

Beim Power-ON habe ich die SHIFT-Taste gedrückt. Aber es ist nicht erkennbar, ob sie erkannt wurde (keine Änderung der Ausgabe des Master V1.8 ). Ist das so korrekt?

Hat sonst noch jemand ein Update (erfolgreich) durchgeführt?

Gruß
Siggi
Habe heute den Update der Instanz 0 gemacht. ZXmore 1.9 läuft hoch, aber die Instanzen 1-7 booten nur, wenn sie mit "CtrlOff" konfiguriert sind. Shift-Drücken beim Power-ON und beim Reset haben nichts daran geändert. Kriege einige der toten Instanzen aber per Drehschalter zum Laufen.

Ich hatte nach Update auf 1.8 die unnötig gewordenen Kondensatoren wieder ausgebaut (damit hat 1.8 gearbeitet). War das zu früh???

Was kann ich noch probieren?

Gruß
Siggi
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 13.07.2016, 14:26

Hallo siggi,

im ersten Moment habe ich keine konkrete Idee.
Ich vermute mal, die IO Adresse wurde nicht geändert.
Mir den Kondensatoren dürfte das nichts zu tun haben.

Funktioniert im ZXmaster sonst alles ?
Lassen sich die Menüfunktionen aufrufen ?
Debugger, LOAD/SAVE (in Speicher ab $8000 per Default), Backup/Restore ?

Das einzige, was sich geändert hat in Instanz 0 ist die Größe der Firmware aber aktuell immer noch 11k.
Wenn Du Instanz 1 mit RAM von 16-64k wählst, startet es dann ?
Was ist denn konkret an Optionen gewählt (außer ggf. CtrlOff) ?

Du könntest versuchsweise mal das ZXpand anschließen und Instanz 1 über Drehschalter wählen, das Update als Recovery durchführen mit ZXMORE19.p oder auch ggf. zurück auf ZXMORE18.p. Hängt/hing sonst irgendwelche Hardware dran während des Updates ?
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 13.07.2016, 15:11

Hi Karl
beim Update war nichts angeschlossen, I/O-Adresse unverändert A3.
Master läuft, Debugger und LOAD und Backup gingen ohne Fehler

Auch mit Instanz 1 mit 16-64K ändert sich nichts:
3,2 MHz, 16-64K CtrOn-> bootet nicht mit Master, läuft aber in Drehschalter-Position 1
3,2 MHz, 16-64K CtrOff-> bootet mit Master
Anlog verhält sich Instanz 2 bei 6,5 MHz

Instanz 5 und 7 laufen auch nicht mit Drehschalter, die hatte ich ja schon zuvor nicht mehr ans Laufen gekriegt (nach Update mit Master V1.8 )
Kann ich die mit ZXPAND in Instanz 1 und Drehschalter fest in Instanz 1 denn mit ZXMORE19.P aktualisieren?

Gruß
Siggi

PS: Ach ja; R24 und R25 habe ich gebrückt
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 13.07.2016, 15:29

siggi hat geschrieben: Instanz 5 und 7 laufen auch nicht mit Drehschalter, die hatte ich ja schon zuvor nicht mehr ans Laufen gekriegt (nach Update mit Master V1.8 )
Kann ich die mit ZXPAND in Instanz 1 und Drehschalter fest in Instanz 1 denn mit ZXMORE19.P aktualisieren?

Gruß
Siggi

PS: Ach ja; R24 und R25 habe ich gebrückt
Hmmm komisch.
Ja, Du kannst in Instanz 1 das Programm auswählen, musst Dich für "Recovery Update" entscheiden und dann nach Anweisung im passenden Moment den Drehschalter auf 0 stellen und dann nochmal eine Taste drücken um den Programmiervorgang auszuwählen. Müsste so hinhauen. Wahlweise 1.9 oder auch zurück zu 1.8. Die Widerstände dürfte nichts ausmachen. R24 habe ich aktuell selbst überbrückt und R25 ist auch unproblematisch.

Dass Instanz 5 und 7 nicht mehr gehen nach Programmierversuchen dorthin, dürfte glaube ich verständlich sein. Kannst Du von Instanz 0 aber auch neu programmieren mit
LOAD und "ZX81MORE.ROM:0#" - wenn ich es aus dem Kopf richtig hinbekomme - steht aber auch auf der Hilfemaske.

Versuch mal auch 6.5 MHz - ich bin nicht sicher ob ich mit 3.25 MHz tatsächlich getestet habe. NTSC habe ich aber getestet (der Jumper über der Taste 2). Kannst ja auch mal einen Test damit machen.
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 13.07.2016, 17:09

Hallo Karl
bei 6,5 MHz ist's genauso: hatte ja schon geschrieben, daß sich Instanz 2 analog verhält.

Habe nun mit Drehschalter in Pos. 1 von ZxPand gebootet und ZXMORE19 geladen (;X: ZxPand ROM aus).
Dann Recovery-Update aus Instanz 1 der Instanz 0. Programmiervorgang geht aber nicht nach Plan, denn Led blinkt nicht (vermutlich wegen Drehschalter auf 1) nachdem ich START eingehackt hatte. Habe dann Drehschalter auf Verdacht auf 0 gestellt (LED aus) und SPACE gedrückt. Nix passiert, Led bleibt aus. Nach weiterem SPACE meldet sich der Master (vermutlich immer noch der alte). Das ganze habe ich mehrmals probiert ...

Wo gibt's die Version 1.8, damit ich damit nochmal probieren kann? EDIT: Hab's gefunden, aber Recovery-Update auf 1.8 geht nicht (wie oben vermutet ist der alte Master noch drin
Bei 60 Hz gleiches Verhalten ...

Neue Erkenntnis: die CtrlOn Instanzen (derzeit 2 und 3) zeigen kein Bild, reagieren aber korrekt auf Doppelshift: habe DS-0, DS-L, DS-R geprüft und es klappt, aber es kommt kein Bild in der Instanz selbst (nur im Master).

Gruß
Siggi
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 13.07.2016, 19:08

1.8 sollte genauso funktionieren.
Hast Du die geänderte Version benutzt ?
Da war mal ein Bug drin, dass das Flash nur in den ersten 8k gelöscht wurden vor dem Programmieren, habe ich aber mit dieser Version hier behoben:
http://forum.tlienhard.com/phpBB3/viewt ... 834#p23568

Das andere ist mysteriös - muss ich mal schauen was das Problem sein könnte.
Schombi hat aber auch auf Version 1.9 upgedatet - oder war es Jungsi ?
Da hat es offenbar geklappt. Ich muss heute abend mal selbst testen.
Es gibt andere Displayroutinen - die sind aber nur beim Multitasking aktiv.

Sonst jemand die neue Version im Einsatz ?
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 13.07.2016, 19:19

Ja, ich habe die aktuelle 1.8-Version aus dem Forum benutzt.
Aber wie beschrieben klappt der Recovery-Update mit Drehschalter nicht so wie im Prog beschrieben (Led blinkt nicht, alter ZXMaster weiter vorhanden) ....

Gruß
Siggi
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 13.07.2016, 19:39

Zeigt der Monitor ein gültiges Signal, wenn Du sozusagen blind zwischen den Instanzen umschalten kannst ?
Hast Du eigentlich die Möglichkeit, den Inhalt des Flash ROMs zu prüfen ?
Mit einem Programmiergerät ? Wäre ein SST39SF040.
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 13.07.2016, 21:56

Ja, der Monitor regt sich nicht über ein fehlendes Signal auf. Ich kann durch die CtrlOn-Instanzen per DS durchschalten und wieder zum Master (DS-0). Und wenn ich DS-R eingebe, zappelt das Bild auch kurz. Der Reset der Instanz wird also durchlaufen. Und im Master sehe ich die durchgeschalteten Intanzen mit * als "running" angezeigt.

Flash kann ich im Moment nicht prüfen. Da die Instanzen aber mit CtrlOff und per Drehschalter laufen, scheinen die ROMs in Ordnung zu sein.
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 16.07.2016, 15:58

So - das Problem ist geklärt. Hier die Lösung:

Man hat die Möglichkeit, Konfigurationen der Instanzen mit anderen Speichereinstellungen, Geschwindigkeit, etc. in das Flash ROM dauerhaft zu speichern. Die werden dann nach jedem Neustart automatisch gelesen. Durch eine Änderung von Version 1.8 auf 1.9 die im Wesentlichen mit dem Multitasking Modus zu tun hat, haben sich die Videotreiberadressen geändert. Insofern kann ein Effekt auftreten, dass die Instanzen mit einem leeren Bildschirm angezeigt werden wenn die Konfigurationstabelle auf ältere Bildschirmtreiberadressen zeigen.

Jetzt kann man die Konfigurationsdaten (Instanzentabelle) im Flash ROM nicht einfach durch SHIFT-Reset löschen. Es wäre ja kontraproduktiv, wenn diese Tabelle zurückgesetzt würde, nur weil man den Rechner in den Reset Modus versetzt. Oder weil der ZXmore länge Zeit nicht eingeschaltet war und dann automatisch einen Kaltstart durchführt. Aber vor allem um das voneinander zu trennen, also Reset und Instanzenkonfiguration zu löschen, habe ich eine zusätzliche Tastenkombination dafür vorgesehen und nur vergessen, diese zu dokumentieren. :oops:

Man kann die Tabelle im Flash löschen, wenn man SHIFT und C drückt während Power-On oder während man den Reset-Taster drückt. Das wäre beim Update auf 1.9 zu empfehlen. Es sind jetzt auch nicht so viele Einstellungen, dass sich hier eine Übernahme der Konfigdaten und Konvertierung in ein aktuelles Format lohnen würde. Da muss man dann jetzt einmal durch.

Also wenn Probleme mit nicht sichtbarem Bild in ZX81 Instanzen auftaucht, einfach SHIFT-C und Reset drücken und anschließend in den Edit Modus gehen (E) und Konfiguration (ggf. nach Änderung) mit Write (W) neu ins Flash schreiben. Ein direkter Lösch Modus ist jetzt nicht vorgesehen und hat auch seine Gründe. Mit SHIFT-C-Reset kann man auch ggf. mit einer Default Konfiguration das System starten ohne eine dauerhaft gespeicherte Instanzentabelle zu löschen. Sozusagen ist SHIFT-C-Reset nur eine temporäre Lösung.

Wer nie individuelle Konfigurationsdaten mit Edit/Write gespeichert hat, ist von dem hier geschilderten Problem nicht betroffen.

Lösung:
SHIFT-C und Reset, danach die erstellte Default Konfiguration mit Edit/Write in Instanz 0 neu in Flash ROM speichern
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 10.08.2016, 21:17

Heute habe ich mal mit ZeddyNet (IRC.P) und Multitasking mit dem Zxmore gespielt. Und sehr seltsame Effekte gehabt. Sind sie bei Euch reproduzierbar?

Konfiguration:
Instanz 1 mit 3,25 MHz und Ram ab 8K (für IRC.P und ZeddyNet)
alle weiteren Instanzen Ram ab 16K und 6,5 MHz (für Interceptor-Programm)

Ich habe IPCONFIG in Instanz 1 gestartet und dann IRC.P und mich in den Chat eingeloggt (siehe Log-Files: siggi-test)
Dann habe ich in Instanz 2 und höher das Intercep.p Programm geladen (RUN 9005 zum Starten im SLOW-Mode)
Dann habe ich in Instanz 1 auf Multitasking geschaltet (DS-M)

Beobachtungen: In Instanz 1 verschwindet der Text, nur schwarze und weiße Blöcke sichtbar. Schaltet man Multitasking ab, sieht man wieder den Text (alles LORES)
Zudem: der Text, den man in Instanz 2 oder mehr eintippt, wird von Instanz 1 in den Chat gesendet und taucht dort im Log-File auf.
Das sieht dann so aus: http://irc.zxq.de/zxteam-aktuell.log

Code: Alles auswählen

[2016-08-10 19:17:01 CEST] * siggi-test quit (EOT)
[2016-08-10 20:46:18 CEST] * siggi-test joined
[2016-08-10 20:46:48 CEST] <siggi-test> m2instanz 1
[2016-08-10 20:47:39 CEST] <siggi-test> 3instanz 3
[2016-08-10 20:48:30 CEST] <siggi-test> 0
[2016-08-10 20:50:17 CEST] <siggi-test> 31ddddkkk
[2016-08-10 20:50:22 CEST] <siggi-test> 00111
[2016-08-10 20:51:03 CEST] <siggi-test> 000
[2016-08-10 20:51:07 CEST] <siggi-test>  

"instanz 3" habe ich in Instanz 3 eingetippt, nachdem ich dahin umgeschaltet habe (die erste 3)
"instanz 1" habe ich in Instanz 2 getippt, nachdem ich Multitasking eingeschaltet hatte (das "m") und auf Instanz 2 geschaltet hatte.
Die weiteren 0011 sind Umschaltungen von Instanzen, die brav in den Chat geschickt werden :D

Zudem ist mir aufgefallen: das Interceptor-Programm bricht oft kurz nach Start mit einer Fehlermeldung ab: Syntaxfehler, weil ein paar Bytes einer Zeile im BASIC-Programm zerschossen wurden. Ist mir nur auf dem Zxmore passiert ....

Gruß
Siggi

Nachtrag: Ach ja: IRC.P ist ja ein mit Z88DK compiliertes Programm mit eigener LOWRES Display-Routine
irc.P
(12.79 KiB) 16-mal heruntergeladen
INTERCEP.P
(9.12 KiB) 18-mal heruntergeladen
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Benutzeravatar
PokeMon
User
Beiträge: 4125
Registriert: 31.08.2011, 23:41

Re: ZXmore Fragen und Antworten

Beitrag von PokeMon » 10.08.2016, 21:48

Also im Multitasking Modus werden eigene Bildschirmtreiber verwendet.
Es ist daher möglich, dass Bild im Text Mode mit eigenen Videotreibern nicht korrekt angezeigt wird.
Sofern das Standard DFILE verwendet wird, sollte das aber eigentlich nicht auftauchen.
Tastatureingaben sollten nur in das aktive Fenster landen.
Ich sehe mir das gerne mal die Tage im Detail an.
Wer seinen Computer ehrt, lebt nicht verkehrt.

Benutzeravatar
siggi
User
Beiträge: 1780
Registriert: 06.12.2005, 08:34
Wohnort: D, Hessen, Ranstadt-Dauernheim
Kontaktdaten:

Re: ZXmore Fragen und Antworten

Beitrag von siggi » 10.08.2016, 23:04

PokeMon hat geschrieben:Also im Multitasking Modus werden eigene Bildschirmtreiber verwendet.
Es ist daher möglich, dass Bild im Text Mode mit eigenen Videotreibern nicht korrekt angezeigt wird.
Sofern das Standard DFILE verwendet wird, sollte das aber eigentlich nicht auftauchen.
Z88DK hat eigene Display-Routine, benutzt aber Standard-DFILE
Tastatureingaben sollten nur in das aktive Fenster landen.
Soweit die Theorie :wink:
Hier sieht man schön im Chat-Logfile, was ich so gemacht habe:

Code: Alles auswählen

[2016-08-10 20:54:05 CEST] <siggi-test2> 012klintercep.p
Mit "012" habe ich durch die Instanzen 0, 1, 2 geschaltet(DS-0, DS-1, DS-2).
Mit "K" habe ich mich vertippt: DS-K macht ja nix.
MIT "L" (DS-L) habe ich ein LOAD (in aktueller Instanz 2) des Programmes "intercep.p" durchgeführt.

Der NSA ist sicher häppy, daß alles, was ich am ZxMore treibe, im Chat-Logfile landet :mrgreen:

Gruß
Siggi
Mein ZX81-Web-Server: online seit 2007
http://zx81-siggi.endoftheinternet.org/index.html

Antworten

Wer ist online?

Mitglieder in diesem Forum: siggi und 3 Gäste