Hallo Michael!

mp-one hat geschrieben:Deine Routine funktioniert super!! Vielen Dank für Deine schnelle Hilfe. Da sieht man, wo die Experten sitzen :D!

Danke, gern geschehn!

- wenn ich zu Beginn des TB-Programms POKE 106,176: GR.0 aufrufe, bleibt die 176 als RAMTOP doch auch nach GRAPHICS-Befehlen erhalten. Nur für den Fall, dass man RESET drückt, wird vom OS wieder die 192 nach Adresse 106 geschrieben. Oder gibt es nocht andere Fälle, die RAMTOP zurücksetzen, ein Sprung durch den RESET-Vektor, oder so?

Bei einem Reset (oder JMP $E474) wird RAMTOP wieder auf 192 (bzw. 160 im Fall von Atari Basic) zurückgesetzt, ansonsten bleibt es erhalten. Ausser natürlich, Du (oder ein anderes Programm) änderst es :-)

- woher kommt es, dass Du 16 Pages = 4K reserviert hast, die Routine selber ist ja nur knapp 1KB groß. Müssen da auch "gerade Grenzen" teilbar durch <xx>KB beachtet werden?

Das liegt am ANTIC bzw. am OS. Gib zB mal "POKE 106,190:GR.8:C.1:PL.0,0:DR.319,159" ein, dann siehst Du es :-)

Der ANTIC kann immer nur Blöcke von 4k ansprechen, und die Routinen im OS erzeugen bei Modi die mehr als 4k brauchen entsprechende Display Lists. Liegt RAMTOP nicht auf einer 4k Grenze gibt das Fehler.

Im Prinzip würden 2k genügen, wenn Du zB nur Graphics 0 (bzw. Modi die max. 2k brauchen) nimmst. Das oberste 1k muss frei bleiben, bei einem Reset landet dort der Graphics 0 Bildschirm - der Speicher wird gelöscht. Das Poke 106,176 kommt ja erst später. Darunter sind dann 1k für den Hisio Code (ab $B800), den Speicher von $B000-$B7FF kannst Du natürlich auch noch beliebig nutzen). POKE 106,184 geht also auch, aber mit einigen Einschränkungen.

so long,

Hias

mp-one hat geschrieben:Hallo Hias,

Deine Routine funktioniert super!! Vielen Dank für Deine schnelle Hilfe. Da sieht man, wo die Experten sitzen ! Ich habe erste Tests auf meinem 800XL mit SIO2USB durchgeführt. So wie es aussieht, steht jetzt eine Top-Möglichkeit zur Verfügung, auf Basis von Turbo Basic XL 1.5, Standard-Hardware (64KB), dem freien BeWe-Dos und großen Images Programme für den ATARI zu entwickeln. Ich werde zusehen, dass ich Deine Routine irgendwie sinnvoll einsetze und hoffe, dass sich auch andere Programmierer dafür interessieren.


Dazu aber noch mal folgende Fragen:

- wenn ich zu Beginn des TB-Programms POKE 106,176: GR.0 aufrufe, bleibt die 176 als RAMTOP doch auch nach GRAPHICS-Befehlen erhalten. Nur für den Fall, dass man RESET drückt, wird vom OS wieder die 192 nach Adresse 106 geschrieben. Oder gibt es nocht andere Fälle, die RAMTOP zurücksetzen, ein Sprung durch den RESET-Vektor, oder so? Hier gibt es auch ein Beispiel, wie man nach RESET BASIC-Befehle ausführen lassen kann: http://www.atarimagazines.com/compute/issue37/atari_reset_run.php

- woher kommt es, dass Du 16 Pages = 4K reserviert hast, die Routine selber ist ja nur knapp 1KB groß. Müssen da auch "gerade Grenzen" teilbar durch <xx>KB beachtet werden? Wie auch immer, ~30KB frei sind schon klasse und wenn's mal nicht reicht, lädt man eben dank HISIO800 turboschnell ein Programmmodul nach!

Beste Grüße und nochmals vielen Dank!!!

Michael

Hi,

eine Anregung: ich schlage vor im Programm erst zu prüfen,

a) ob schon HighSpeed besteht, dann braucht kein extra Speicher reserviert werden und keine Routine geladen werden

b) ob das (oder ein) Laufwerk überhaupt HighSpeed SIO versteht, sonst braucht auch kein Speicher reserviert und die Routine nicht geladen werden

wenn A+B getestet wurde, kann dann die HighSpeed SIO Routine vom Programm geladen werden. Oder man macht es eine Konfigurationseinstellung im Programm, dann der Besitzer des Ataris kennt sein System meist am besten und weis, ob er schon HighSpeed im OS hat oder eine extra Routine laden muss.

Ciao

Carsten

Moin Hias,

Das liegt am ANTIC bzw. am OS. Gib zB mal "POKE 106,190: GR.8: C.1: PL.0,0: DR.319,159" ein, dann siehst Du es

Ja, hab's getestet. Sieht ungut aus !

Der ANTIC kann immer nur Blöcke von 4k ansprechen, und die Routinen im OS erzeugen bei Modi die mehr als 4k brauchen entsprechende Display Lists. Liegt RAMTOP nicht auf einer 4k Grenze gibt das Fehler.

Ah ja, das hätte ich im Grunde auch selbst wissen müssen, hatte das (vor Jahren) mal im Profibuch gelesen.

Im Prinzip würden 2k genügen, wenn Du zB nur Graphics 0 (bzw. Modi die max. 2k brauchen) nimmst. Das oberste 1k muss frei bleiben, bei einem Reset landet dort der Graphics 0 Bildschirm - der Speicher wird gelöscht. Das Poke 106,176 kommt ja erst später. Darunter sind dann 1k für den Hisio Code (ab $B800), den Speicher von $B000-$B7FF kannst Du natürlich auch noch beliebig nutzen). POKE 106,184 geht also auch, aber mit einigen Einschränkungen.

Ok, in die 2K von $B000-$B7FF kann man ja noch einiges reinpacken.

Was mir noch aufgefallen ist: der Patch scheint nicht richtig im ATARI800Win zu laufen. Wenn man in TB oder auch BeWeDos "DIR" eingibt, wird kein Directory mehr angezeigt und man kann keine Files mehr laden (ERROR 170). Das ist unabhängig vom ein- oder ausgeschalteten Emu-internen SIO-Patch. Dieses Problem ist aber nicht so wichtig, da man auf dem Emu durch den internen SIO-Patch das Geschwindigkeitsverhalten unter HiSpeed genauso abschätzen kann. Also da keine Zeit reininvestieren.

Gruß,

Michael

cas hat geschrieben:Hi,

eine Anregung: ich schlage vor im Programm erst zu prüfen,

a) ob schon HighSpeed besteht, dann braucht kein extra Speicher reserviert werden und keine Routine geladen werden

b) ob das (oder ein) Laufwerk überhaupt HighSpeed SIO versteht, sonst braucht auch kein Speicher reserviert und die Routine nicht geladen werden

wenn A+B getestet wurde, kann dann die HighSpeed SIO Routine vom Programm geladen werden. Oder man macht es eine Konfigurationseinstellung im Programm, dann der Besitzer des Ataris kennt sein System meist am besten und weis, ob er schon HighSpeed im OS hat oder eine extra Routine laden muss.

Ciao

Carsten

Hi Carsten,

ich würde zunächst so vorgehen, dass ich bei Programmstart oder in einem kleinen PreLoader eine Abfrage für den Anwender einbaue.

Wie könnte man denn sicher erkennen, ob HS aktiv ist bzw. ein Laufwerk es unterstützt? Prüfen, ob der SIO-Vektor verändert ist, die Übertragungsrate prüfen, etc.?

Gruß,

Michael

Hi Michael!

mp-one hat geschrieben:Was mir noch aufgefallen ist: der Patch scheint nicht richtig im ATARI800Win zu laufen.

It's not a bug, it's a feature :-)

Im Ernst: das ist ein bekanntes Problem mit den Emulatoren. Die emulieren alle den Pokey nicht richtig, deshalb glaubt der Patch, daß eine 1050 Turbo dranhängt. Das führt dann dazu, daß bei AUX2 immer Bit 7 gesetzt wird, statt Sektor 1 sieht dann der Emulator einen Sektor 32769. Wenn man ein ATR mit weniger als 32769 Sektoren im Emu verwendet, gibt's (wahrscheinlich) einen Fehler 144, bei einem ATR mit 65535 Sektoren liefert der Emu dann falsche Daten.

Kurzum: dagegen kann ich nichts machen, das ist ein Bug in den Emus.

ich würde zunächst so vorgehen, dass ich bei Programmstart oder in einem kleinen PreLoader eine Abfrage für den Anwender einbaue.

Das würde ich auch vorschlagen, ist die beste Lösung.

Wie könnte man denn sicher erkennen, ob HS aktiv ist bzw. ein Laufwerk es unterstützt? Prüfen, ob der SIO-Vektor verändert ist, die Übertragungsrate prüfen, etc.?

Garnicht. Zumindest nicht 100% zuverlässig.

Beispiel: User verwendet eine Black-Box (oder ein anderes Festplatten-Interface) und hat D1: auf einer Harddisk. Zusätzlich hat er eine Floppy auf D1: konfiguriert und die Blackbox so konfiguriert, daß Zugriffe auf D2: auf die D1: Floppy umgeleitet werden. Wenn Du also direkt eine Floppy per SIO ansprichst (zB mit meinem Patch) siehst Du nur die Floppy (die meldet sich ja als D1:), nicht aber die Blackbox (DOS bzw. das OS im Atari sehen ja die Floppy als D2:).

So eine Konfiguration ist übrigens garnicht so selten, denn damit kann man problemlos ohne irgendwelche Schalter umzulegen sowohl Platte als auch Floppy benutzen - bei Software, die nicht mit der Platte klarkommt (zB Spiel mit Kopierschutz) konfiguriert man einfach im Blackbox Menü die Floppy auf D1: oder steckt die Blackbox komplett ab.

so long,

Hias

HiassofT hat geschrieben:Hi Michael!

It's not a bug, it's a feature

Im Ernst: das ist ein bekanntes Problem mit den Emulatoren. Die emulieren alle den Pokey nicht richtig, deshalb glaubt der Patch, daß eine 1050 Turbo dranhängt. Das führt dann dazu, daß bei AUX2 immer Bit 7 gesetzt wird, statt Sektor 1 sieht dann der Emulator einen Sektor 32769. Wenn man ein ATR mit weniger als 32769 Sektoren im Emu verwendet, gibt's (wahrscheinlich) einen Fehler 144, bei einem ATR mit 65535 Sektoren liefert der Emu dann falsche Daten.

Kurzum: dagegen kann ich nichts machen, das ist ein Bug in den Emus.

Hallo Mathias,

ok, damit kann man leben. Ich werde jetzt mal einige Tests machen und mal ermitteln, wie lange solche Operationen wie Anlegen, Öffnen, Suchen, usw. mit größeren Dateien so dauern und welche Dateigröße für den ATARI noch handelbar ist.

Beste Grüße,

Michael