Dietrich hat geschrieben:

bernd hat geschrieben:Jetzt kommt eine schöne Aufgabe für SDX Profis. Auf der Webseite http://drac030.krap.pl/en-kmkjz-pliki.php gibt es einige Example programs.
Wie bekomme ich die Daten von den Videos und dem WAV-File auf die Festplatte übertragen? Ich benutze SDX 4.44 mit Aspect. Der Ordner mit den Files
ist als Laufwerk freigegeben, jedoch scheitert eine Datenübertragung dadurch dass SDX immer wieder nur die gleichen Sektoren kopiert.

Wird ein Verzeichnis gemountet, erwartet AspeQt, dass sich der ATARI das Inhaltsverzeichnis über Sektor 361-368 holt, und dann die gewünschte Datei sequentiell einliest. Beim Einlesen werden Sektornummern wiederverwendet (ich glaube es waren die Nummer 441-444). Das ist für ein ATARI-DOS kein Problem, aber SpartaDOS kommt damit nicht zurecht.

Gruß Dietrich (der AspeQt trotzdem toll findet)

Das wäre dann aber ein Mangel in AspeQt und nicht in SDX.

Falls man es nicht schafft, das über ein ATR zu lösen (wie beschrieben mit MakeATR), kann PCLink von KMK benutzen.

Bei mir gibt es Probleme mit IDE 2.0 unter SDX und high Speed Sio....
Bitraten über 60.000 gehen absolut nicht, da hängt sich das OS beim
schreiben auf. OS ist von Hias, Endgerät ist ein SIO2SD.
Bei MyDos funzt alles!
Wie sieht es bei Euch aus?

Viele Grüße,
Bernd

Vorsicht, das SDX hat eine eigene Highspeed-Routine - die Highspeed-Routine im OS greift also normalerweise nicht. Versuch mal, SDX zu überreden, die Original-SIO-Routine im OS zu benutzen (laut Doku, Seite 217 DEVICE SIO.SYS /A in der Config.sys) und probiere damit, auf SIO2SD zuzugreifen. Sofern SDX nicht die RAM-Speicherstellen benutzt, die die Routine im HIAS-OS braucht, um sich die SIO-Speed zu merken, könnte das dann klappen.

Gruß Dietrich

Hallo Dietrich,
guter Tipp, leider ging der richtig in die Hose
SDX und das BIOS V0.8 benutzen den gleichen Speeder. Im BIOS V0.8 kann ich ihn abwählen (USpeed SIO = off), dadurch läuft es auch unter MyDos mit Pokey0 (SIO2SD+Hias OS).
Aktiviert man USpeedSIO so ist bei Pokey 8 (59659.08) das Ende erreicht, genauso verhält es sich unter SDX. Mit dem Eintrag DEVICE SIO.SYS /A in der Config.sys Datei
koppelt sich das gesamte System vom SIO ab, es kommt bei allen Laufwerken nur noch die Fehlermeldung: 132 No device handler installed. Die Meldung erscheint unter dem Original XL OS
sowie dem OS von Hias. Scheint ein Bug in SDX zu sein.

Viele Grüße,
Bernd

Hallo Bernd!

Probier's mal mit "MAP 1 OS D1:", das scheint bei mir zu klappen (SDX 4.44, Hipatch im OS und AtariSIO mit Divisor 0).

Das MAP Kommando ist etwas seltsam, lässt man die Laufwerksbezeichnung (das "D1:" am Ende) weg, wird das angegebene Laufwerk (die erste "1") dem aktuellen Laufwerksbuchstaben zugeordnet. "MAP OS D1:" funktioniert auch nicht ("ERROR 170 File not found"). Aus der Man-Page werd' ich auch nicht so recht schlau. Etwas missglückt, meiner Meinung nach...

so long,

Hias

Hallo Hias,
klappt mit dem IDE2.0 Interface leider nicht. Die Umleitung erfolgt zwar, jedoch wird der HighSpeed Mode nicht aktiviert.
Die Übertragung erfolgt nur mit Standart.

Viele Grüße,
Bernd

bernd hat geschrieben:... es kommt bei allen Laufwerken nur noch die Fehlermeldung: 132 No device handler installed

132 ist nicht "No Device Handler installed", sondern "Bad CIO command". Der Fehler kommt, wenn das CIO mit einem Kommandobyte < 3 aufgerufen wird. Das ist ein Programmierfehler und darf daher eigentlich niemals auftreten.

Bernd hat geschrieben:SDX und das BIOS V0.8 benutzen den gleichen Speeder

Aha, dann ist wohl die Highspeed-Routine im SDX deaktiviert und SDX ruft das normale SIO auf, das dann wiederum den Aufruf auf das PBI-ROM umleitet, wo offenbar ein Highspeed-Treiber drin ist - allerdings kein besonders guter, wenn schon bei 8 Schluss ist. Aber woher weiß SDX, dass es seine eigene Highspeed-Routine nicht benutzen soll?

Hias hat geschrieben:Das MAP Kommando ist etwas seltsam, lässt man die Laufwerksbezeichnung (das "D1:" am Ende) weg, wird das angegebene Laufwerk (die erste "1") dem aktuellen Laufwerksbuchstaben zugeordnet.

Das ist ganz logisch: Wenn ich ein SpartaDOS-Kommando ohne Laufwerksangabe "Dn:" eingebe, dann wirkt das auf das aktuelle Laufwerk (das im Prompt angezeigt wird). Ist "D2:" das aktuelle Laufwerk, so ist MAP 1 SIO D2: dasselbe wie MAP 1 SIO, d.h. alle Zugriffe auf D2: gehen auf das physische LW 1.
Die Reihenfolge der MAP-Parameter finde ich allerdings seltsam, ich würde eher erwarten: MAP <logisches Laufwerk> <physisches Laufwerk> <modus>, also z.B. MAP D2: 1 SIO (statt MAP 1 SIO D2:).

Dietrich hat geschrieben:Aha, dann ist wohl die Highspeed-Routine im SDX deaktiviert und SDX ruft das normale SIO auf, das dann wiederum den Aufruf auf das PBI-ROM umleitet, wo offenbar ein Highspeed-Treiber drin ist - allerdings kein besonders guter, wenn schon bei 8 Schluss ist. Aber woher weiß SDX, dass es seine eigene Highspeed-Routine nicht benutzen soll?

Lt. Walter sollte ein "DEVICE SIO.SYS /A" in der Config.sys das bewirken, getestet habe ich das aber selber noch nicht.

Ansonsten sollte auch das MAP Kommando funktionieren. IDE Interface habe ich keines, nur mit SIO geht das aber gut.

Wichtig ist nur, daß das entsprechende SIO Device (zB D1:) nur als SIO Gerät existiert (nicht auch als PBI Partition) und daß die Highspeed SIO Routine im IDE Interface deaktiviert wurde. Dann sollte das wie folgt ablaufen:

Durch das "MAP 1 OS D1:" nimmt SDX die OS Routinen für Zugriffe auf D1:. Das OS checkt erst mal alle PBI-Geräte durch, ob sie sich für D1: zuständig fühlen (deshalb ist es auch wichtig, daß weder die Highspeed Routine im IDE Interface aktiviert ist noch eine Partition auf D1: gelegt wurde). Übernahm kein PBI Gerät, verwendet das OS die "normale" (serielle) SIO. An dieser stelle klinkt sich dann auch mein Highspeed Patch ein, mit dem original OS gibt's 19200 bit/sec, mit meinem Patch bis zu 126kbit/sec.

Hias hat geschrieben:Das MAP Kommando ist etwas seltsam, lässt man die Laufwerksbezeichnung (das "D1:" am Ende) weg, wird das angegebene Laufwerk (die erste "1") dem aktuellen Laufwerksbuchstaben zugeordnet.

Das ist ganz logisch: Wenn ich ein SpartaDOS-Kommando ohne Laufwerksangabe "Dn:" eingebe, dann wirkt das auf das aktuelle Laufwerk (das im Prompt angezeigt wird).

Ah, ja, OK, so gesehen ist das Verhalten wieder konsistent. Logisch würde ich es zwar nicht nennen (bei DIR, COPY macht das ja evtl. Sinn, bei MAP hätte ich halt eher erwartet daß "MAP x OS" zB das gleiche wie "MAP x OS Dx:" ist oder so), ist aber auch egal.

Die Reihenfolge der MAP-Parameter finde ich allerdings seltsam, ich würde eher erwarten: MAP <logisches Laufwerk> <physisches Laufwerk> <modus>, also z.B. MAP D2: 1 SIO (statt MAP 1 SIO D2:).

Entweder das oder "MAP <logisches Laufwerk> [<optional Modus>] [<optional physisches Laufwerk>]". Hauptsache mit dem logischen Laufwerk ganz vorne :-)

"MAP D1:" zeigt das Mapping von D1: an
"MAP D1: 2" mappt D1: auf D2: um
"MAP D1: OS" ändert Zugriffsmodus für D1:
"MAP D1: OS 2" setzt Zugriffsmodus und mappt um.

Oder irgendwie so ähnlich halt.

@Bernd: Ich hatte gestern noch mal kurz die SIO Routine in SDX mit Divisor 2 getestet: SDX 4.44 hängt sich bei mir da auch hart weg (und zwar schon beim allerersten Zugriff, zB "DIR D2:" direkt nach dem Booten). Hatte das vor einigen Monaten schon mal an die Entwickler gemeldet, werde Trub' noch mal eine Mail schicken.

so long,

Hias

Dietrich hat geschrieben:Aha, dann ist wohl die Highspeed-Routine im SDX deaktiviert und SDX ruft das normale SIO auf, das dann wiederum den Aufruf auf das PBI-ROM umleitet, wo offenbar ein Highspeed-Treiber drin ist - allerdings kein besonders guter, wenn schon bei 8 Schluss ist.

I am not able to check it myself, because I cannot program my PC to use faster serial transfer than 3xSIO (i.e. divisor 8 ), but I have reports that the "USpeed SIO" in IDE Plus BIOS 0.8 handles SIO transfers up to divisor 0, i.e. 126 kbps. This was reported for SIO2SD and SIO2PC.

KMK hat geschrieben:

Dietrich hat geschrieben:Aha, dann ist wohl die Highspeed-Routine im SDX deaktiviert und SDX ruft das normale SIO auf, das dann wiederum den Aufruf auf das PBI-ROM umleitet, wo offenbar ein Highspeed-Treiber drin ist - allerdings kein besonders guter, wenn schon bei 8 Schluss ist.

I am not able to check it myself, because I cannot program my PC to use faster serial transfer than 3xSIO (i.e. divisor 8 ), but I have reports that the "USpeed SIO" in IDE Plus BIOS 0.8 handles SIO transfers up to divisor 0, i.e. 126 kbps. This was reported for SIO2SD and SIO2PC.

Hi KMK,
i Have trouble with SDX and the kmk2 interface. USpeed SIO is off, HighSpeed OS is from Hias.

[CONFIG.SYS]
DEVICE SIO.SYS /A

After booting the system and make DIR, I get the error - 132 No device handler installed.
With "MAP D1: OS 1" the speed is only standart and not high speed.

Can you help me?

Many greetings,
Bernd

Bernd hat geschrieben:[CONFIG.SYS]
DEVICE SIO.SYS /A

After booting the system and make DIR, I get the error - 132 No device handler installed.

Please list your entire CONFIG.SYS. Error 132 you're getting suggests that SPARTA.SYS is not loaded.

Hi KMK,
I make a mistake - SPARTA.SYS was not the first device in the config.sys - now it´s running. I have another problem.

Aktiv OS from Hias,

[CONFIG.SYS]
DEVICE SPARTA.SYS
DEVICE ATARIDOS.SYS
DEVICE SIO.SYS /A

I want to load with SIO-HighSpeed but with the command "SIO.SYS /A" it´s work only in normal SIO Mode.
Did you have an idear?

Greetings,
Bernd

Hi Bernd

I don't have any idea. SIO /A means that the SpartaDOS X SIO driver is not loaded at all, instead a stub-driver is loaded which does not do anything besides calling the ROM-based SIO via the JSR $E459. If you get 19200 bps only, then it suggests that Hias' SIO patch is somehow not enabled.

Hi Konrad!

KMK hat geschrieben:I don't have any idea. SIO /A means that the SpartaDOS X SIO driver is not loaded at all, instead a stub-driver is loaded which does not do anything besides calling the ROM-based SIO via the JSR $E459. If you get 19200 bps only, then it suggests that Hias' SIO patch is somehow not enabled.

I can't reproduce this problem here, as I don't have an IDE 2.0+.

But with SDX 4.44, default CONFIG.SYS and redirecting Dx: to use OS with the MAP command everything is working fine here (stock 800XL with my highspeed patched OS plus ramdisk).

We'll have a look at it at the Fujiama, then we should be able to tell more. Maybe it was just some minor config issue.

so long,

Hias

Eine Lösung des Problems hat Hias auf der Fuijama gefunden.....Es funktioniert mit der Standart SIO Config.sys und meinen Einträgen.
Nach dem Booten "MAP 1 OS D1:" eingeben, anschließend die Tastenkombination SHIFT-CONTROL-S drücken, dann funzt es mit dem Pokey Divisor 0 ~ 127KBIT

HIAS, so etwas kann man nur bei einem Meeting "Fujiama" lösen.

Bernd

Bernd hat geschrieben:... anschließend die Tastenkombination SHIFT-CONTROL-S drücken...

Nur der Vollständigkeit halber: Mit der Tastenkombination wird die Routine in Hias's OS zurückgesetzt.

GoodByteXL hat geschrieben:

Bernd hat geschrieben:... anschließend die Tastenkombination SHIFT-CONTROL-S drücken...

Nur der Vollständigkeit halber: Mit der Tastenkombination wird die Routine in Hias's OS zurückgesetzt.

Und hier die Erklärung was genau schief gegangen ist:

Der Highspeed Patch belegt am Anfang des Stacks ein paar Bytes (ab $0108 in der aktuellen 1.30er Version, ab $0100 in den vorherigen Versionen). Damit der Patch nicht versehentlich wichtige Daten dort überschreibt überprüft er ob das erste Byte dort 0 ist. Bei einem Wert ungleich Null wird die originale SIO Routine aus dem OS verwendet (dieses Byte verwendet der Patch auch zum Abschalten der Highspeed Routine per Shift+Control+N).

SDX (oder einer der Treiber?) scheint nun diesen Bereich ebenfalls für (temporären?) Code zu verwenden, es stehen also Werte ungleich Null drin und der Highspeed Patch wird deaktiviert.

Mit Shift+Control+S wird das "Enable Byte" und die direkt darauf folgende Speed-Tabelle auf 0 gesetzt - also in den Zustand in dem der Stack normalerweise nach dem Einschalten ist. Es wird damit der Highspeed Code verwendet und vor jedem Zugriff erst mal die maximale Geschwindigkeit der Laufwerke ermittelt.

Mit Shift+Control+H (zum Einschalten des Highspeed Codes) würde die Speed-Tabelle der Laufwerke 1-8 nicht zurückgesetzt werden, der Patch denkt sich "oh, für die Laufwerke habe ich die Geschwindigkeit schon ermittelt", und nimmt den alten Programm-Code von dort als "Speed-Bytes". Das Ergebnis wäre dann wohl recht seltsam :-)

so long,

Hias

HiassofT hat geschrieben:Der Highspeed Patch belegt am Anfang des Stacks ein paar Bytes (ab $0108 in der aktuellen 1.30er Version, ab $0100 in den vorherigen Versionen). Damit der Patch nicht versehentlich wichtige Daten dort überschreibt überprüft er ob das erste Byte dort 0 ist. Bei einem Wert ungleich Null wird die originale SIO Routine aus dem OS verwendet (dieses Byte verwendet der Patch auch zum Abschalten der Highspeed Routine per Shift+Control+N).

SDX (oder einer der Treiber?) scheint nun diesen Bereich ebenfalls für (temporären?) Code zu verwenden, es stehen also Werte ungleich Null drin und der Highspeed Patch wird deaktiviert.

SDX only uses the stack area at init time (cold or warm reset), but it does not touch anything below $0110. So any data stored at $0100 or $0108 should be safe through the DOS initialization. I also don't recall any driver loading anything at $0100, they usually load at $0400-$06FF. BUT: the SDX formatter also uses stack area to hold display data. Moving it out of there would not be a trivial task (because there is no place where to move it to), but I was already thinking about it several times.

Gtx
KMK

Sö ...
Nachdem ich auf der Fujiama gesehen hatte, dass es offenbar Probleme mit dem Hias OS Patch, IDE V2 und SDX gibt und ich das Mangels Hardware nicht richtig nachvollziehen konnte, habe ich mir gerade eben ein Mini-SIO-2-PC(USB) zusammengestöpselt und getestet.

Ergebnis:
Mit einem 130XE (320K-CS) oder 800XL (320K-CS) und ATARI-OS unter SpartaDOS X 4.44a läuft die SIO-Verbindung zum PC mit AspeQt bis POKEY Divisor 3 völlig problemfrei.
Die UltraSpeed-Funktion des IDE V2 muss dabei abgeschaltet bleiben.
Erst bei POKEY Divisor 2 synchronisiert das System nicht mehr.

Fazit:
Man braucht also nicht unbedingt ein gepatchtes OS, um schneller als 3xSIO Daten zwischen PC und ATARI bewegen zu können. Mit SDX 4.4x ist man ebenfalls schnell. Der Datendurchsatz liegt mit POKEY Divisor 3 und 512-Byte-Sektoren bei ca. 6,2 KByte/s - das IDE V2 ist bis zu 15x so schnell bei 512-Byte-Sektoren. Der Datendurchsatz hängt dabei ganz wesentlich vom IDE-Drive ab.

GoodByteXL hat geschrieben:Sö ...
Nachdem ich auf der Fujiama gesehen hatte, dass es offenbar Probleme mit dem Hias OS Patch, IDE V2 und SDX gibt und ich das Mangels Hardware nicht richtig nachvollziehen konnte, habe ich mir gerade eben ein Mini-SIO-2-PC(USB) zusammengestöpselt und getestet.

Ergebnis:
Mit einem 130XE (320K-CS) oder 800XL (320K-CS) und ATARI-OS unter SpartaDOS X 4.44a läuft die SIO-Verbindung zum PC mit AspeQt bis POKEY Divisor 3 völlig problemfrei.
Die UltraSpeed-Funktion des IDE V2 muss dabei abgeschaltet bleiben.
Erst bei POKEY Divisor 2 synchronisiert das System nicht mehr.

Fazit:
Man braucht also nicht unbedingt ein gepatchtes OS, um schneller als 3xSIO Daten zwischen PC und ATARI bewegen zu können. Mit SDX 4.4x ist man ebenfalls schnell. Der Datendurchsatz liegt mit POKEY Divisor 3 und 512-Byte-Sektoren bei ca. 6,2 KByte/s - das IDE V2 ist bis zu 15x so schnell bei 512-Byte-Sektoren. Der Datendurchsatz hängt dabei ganz wesentlich vom IDE-Drive ab.

Korrektur & Ergänzung:
Weitere Tests haben ergeben, dass nicht nur die SIO-Routine aus SDX 4.4x sehr leistungsfähig ist, die SIO-Routine im BIOS des KMK/JZ IDE V 2.0 Plus ebenfalls. Mit o.a. SIO2PC(USB)-Interface kann ich problemlos Bootdisks bis POKEY Divisor 0 booten, z.B. unser Club-Magazin. Das alles funktioniert wunderbar mit dem originalen ATARI-OS im XL/XE.

Die Zusammenarbeit mit SDX funktioniert ebenfalls bis POKEY Divisor 0 für Lesen und Schreiben !!!

Ich hatte gestern parallel Windows Updates laufen und vermute, dass mein Stromspar- & Büro-PC deswegen nur bis NMI 3 synchronisieren konnte.

Mit dem Tool RWTEST von KMK misst man auf meinem System bei POKEY Divisor 0:

DOS writing: 7873.795069 B/sek
DOS reading: 10243.3384 B/sek
DOS average: 9058.5667 B/sek

Das ist der effektive Datendurchsatz unter SDX 4.44a beim Schreiben und Lesen in einem dafür angelegten File von 64KByte Größe auf einem 32MB-Image bei abgeschaltetem ANTIC-Zugriff.

Mit SysInfo messe ich eine RAW-Performance von 10KByte/sek bei DMA ON und DMA OFF. Da scheint die Grenze erreicht zu sein und die Anzeige von ASpeQt mit 125494 Bit/sek sieht ebenfalls ganz eindrucksvoll aus.

Alles mit dem normalen ATARI-OS auf einem 320K-CS-XL bzw. XE mit SDX 4.44a, KMK/JZ IDE V 2.0 Plus und einem SIO2PC(USB) mit FT232R Breakout Modul.