Moin Moin,

dl7ukk hat geschrieben:Das wäre ja mal einen Versuch wert, bloß ich habe keinen XL/ XE mit Freddy und wüsste auch nicht welcher Quarz (QRG) dort verbaut ist - 14,187576 ??. Wenn das an dem ist, sollte ich mal Quarze suchen.

Dann müsste es aber mit einem NTSC XL/ XE gehen. Das könnten wir z.B. auf der Fujiama testen. Sicher bringt jemannd sein NTSC Gerät, wenn wir mal anfragen.

Ich werde es gern probieren, wenn ich endlich mal die Zeit habe, mein SDRIVE zusammenzubauen - da kam ich bisher einfach nicht zu. Vielleicht ist ja jemand schneller mit diesem Test.

Einen Quarz mit dieser Frequenz zu bekommen ist nahezu unmöglich. Ich habe in Deutschland nahezu alle Distributoren und Händler durch, Best Electronics & andere U.S. Atari Händler haben auch keine mehr.

SONY hat in den 80er eine Videokamera gebaut, die diesen Quarz auch verwendete, aber auch darüber bin ich nichts mehr geworden.

Es gibt nur noch 2 Optionen, nein 3.... erstens, alte XL/XE mit Freddie notschlachten - sehr unschön. Oder bei diesen Hongkong-Chipdealern probieren... da habe ich mal eine Anfrage gemacht und bekomme - zum Glück habe ich eine seperate EMail-Adresse verwendet - seitdem stündlich ca. 5 Mails mit Ankaufsangeboten und schlechtem Englisch. Bisher nichts konkretes dabei.

Mein aktuell letzter Versuch, diesen Quarz zu bekommen, liegt bei einem U.S. Elektronik-Distributor, den ich aber noch davon überzeugen muß, mich als Privatmann ausnahmsweise zu beliefern. Sollte ich darüber tatsächlich an diese Quarze kommen, werde ich sie natürlich auch den Abbuc-Membern anbieten.

Gruß, Jürgen

Hallo @tfhh,
die Idee mit dem Quarz ist nett, wird aber nichts bringen.
Da die USART-Schnittstelle des ATMEGA von dem Quarz abhängt ist mit einem "falschen" Quarz eine fehlerhafte Übertragung vorprogrammiert.
Die USART erreicht eine Fehlerquote von 0,0% bei einer Taktfrequenz von:
1,8432 MHz bis 57,6kbps
3,6864 MHz bis 230,4kbps
7,3728 MHz bis 230,4kbps
11,0592 MHz bis 230,4kbps
14,7456 MHz bis 230,4kbps
18,4320 MHz bis 230,4kbps

Es stellt sich die Frage wie es dennoch mit der Taktfrequenz von 14,31818 MHz übertragen lässt, man kann es mit einer internen Verzögerungen relativ das ganze stabil halten was leider nicht sicher ist.
Was möchte ich damit sagen? Eine Änderung des Quarzes auf 14,187576 MHz wird nur Fehler produzieren, es könnte nur mit einer Anpassung der Firmware wieder korrigiert werden.
Eine kleine Aufgabe für dich: teste erstmal das Original mit einem NTSC-Rechner dann weist du es.

Mit freundlichen Grüßen

HardwareDoc

Moin Moin,

Hardwaredoc hat geschrieben:Hallo @tfhh,
die Idee mit dem Quarz ist nett, wird aber nichts bringen.

Da bin ich mir nicht ganz sicher. Der Takt der USART hängt direkt vom Systemtakt des ATMega ab. Folgendes Fragment habe ich im Sourcecode gesehen, Datei SDRIVE.C im Verzeichnis \SRC\HW

Code: Alles auswählen

//F_CPU = 14318180
//UBRR = (F_CPU/16/BAUD)-1
//BAUD = (F_CPU/16/(UBRR+1)
//Pokey_frq = 1789790
//BAUD = Pokey_frq/2/(AUDF+7)      //(16bit register)

#define US_POKEY_DIV_STANDARD   0x28      //#40  => 19040 bps
#define ATARI_SPEED_STANDARD   (US_POKEY_DIV_STANDARD+6)   //#46 (o sest vic)

#define US_POKEY_DIV_DEFAULT   0x06      //#6   => 68838 bps

#define US_POKEY_DIV_MAX      (255-6)      //pokeydiv 249 => avrspeed 255 (vic nemuze)

/*
#define SIOSPEED_MODES   9   //pocet fastsio_mode=0..8
#define US_POKEY_DIV_DEFAULT   US_POKEY_DIV_7
#define ATARI_SPEED_DEFAULT      ATARI_SPEED_7

//sio 1x standard
#define US_POKEY_DIV_STANDARD   0x28      //=> 19040 bps
#define ATARI_SPEED_STANDARD   46         // normal speed
//=46 => F_CPU/16/(46+1) = 19040

//sio2x
#define US_POKEY_DIV_2      0x10         //=> 38908 bps
#define ATARI_SPEED_2      22            // sio2x speed
//=22 => F_CPU/16/(22+1) = 38908

//Happy
#define US_POKEY_DIV_3      0x0a         //=> 52641 bps
#define ATARI_SPEED_3      16            // happy
//=16 => F_CPU/16/(16+1) = 52640

//Speedy
#define US_POKEY_DIV_4      0x09      //=> 55931 bps
#define ATARI_SPEED_4      15         // speedy TOTO FUNGUJE
//=15 => F_CPU/16/(15+1) = 55930


Ein Beispiel aus diesem Code für Pokey-Divisor 10.

Basis (bezogen auf Formel hier im Thread) beim ATMega = (14318180/16) = 894886 (abgerundet)

SDrive Baudrate beim Divisor 10 ist also 894886 / (10+7) = 52640 bps

Das Ganze beim PAL-Atari:

Pokey PAL Baudrate Basis 886735 (siehe Hias´ Ausführungen, 1,77 MHz Systemtakt / 2).

XL Baudrate (PAL) bei Divisor 10 ist also 886735 / (10+7) = 52160 bps.

Das sind schon mal eine Differenz von 480 bps, ein knappes Prozent.

Es ist also erkennbar, daß bei >90000 bps die Fehlerrate an die 2% geht und damit den USART-Toleranzbereich verläßt.

Von daher müßte der Sourcecode meines Erachtens NICHT verändert werden, da die hinterlegten Formeln zur Berechnung der SIO-Speeds an sich ja korrekt sind. Nur der Systemtakt und die daraus resultierenden Taktfrequenzen für den USART weichen von denen eines PAL-Ataris ab.

Gruß, Jürgen

Hallo Christoph!

Hardwaredoc hat geschrieben:die Idee mit dem Quarz ist nett, wird aber nichts bringen.
Da die USART-Schnittstelle des ATMEGA von dem Quarz abhängt ist mit einem "falschen" Quarz eine fehlerhafte Übertragung vorprogrammiert.
Die USART erreicht eine Fehlerquote von 0,0% bei einer Taktfrequenz von:

Die Fehler bei den "standard" RS232 Bitraten (19200, 38400, 57600 etc.) sind hier ziemlich egal, wichtig ist, daß der Atmel die Pokey-Bitraten möglichst genau trifft.

Eine kleine Aufgabe für dich: teste erstmal das Original mit einem NTSC-Rechner dann weist du es.

Mein SDrive liegt immer noch in Einzelteilen in der Bastelkiste, aber ich habe einen weiteren Test mit dem SIO2SD und meinem NTSC 800XL (C77 und C78 entfernt) gemacht:

Divisor 2 läuft, Divisor 1 gibt Framing Errors. Da dürfte also noch irgendwas anderes schiefgehen...

Zurück zu den Bitraten: Die meisten UARTs sollten eine Abweichung bis zu maximal +/- 5% tolerieren (das ist aber wirklich die maximale, theoretische Obergrenze - idealerweise sollte man unter 1% bleiben).

Ein bisschen Hintergrund Info dazu: Die meisten UARTs synchronisieren ihre internen Zähler beim Beginn des Startbits. Dann sampeln sie in der Mitte jedes Bits das Eingangssignal. Insgesamt wird pro Byte 10 mal gesampelt (Startbit = low , 8 Datenbits, Stopbit = high). Beim Stopbit wird nun überprüft, ob es wirklich high ist, wenn nicht wird ein Framing Error gemeldet.

Stimmen Sende- und Empfangs-Rate exakt überein, wird immer in der Mitte jedes Bits gesampelt. Bei einer Abweichung von zB 1 % wird das Startbit bei 49.5% gesampelt, Bit 0 bei 48.5%, ... Bit 7 bei 41.5% und das Stopbit bei 40.5% - ebenfalls noch gut im grünen Bereich (analog bei Abweichung in die andere Richtung, dann sind es eben 50.5% bis 59.5%).

Mit dem nächsten Startbit werden die Zähler wieder neu synchronisiert, die Abweichung summiert sich also nicht über mehrere Bytes hinweg auf.

Geht man bis 5% Abweichung rauf, geht es beim Stopbit schief - dann wird das Stopbit entweder ganz am Anfang oder ganz am Ende gesampelt - das kann gerade noch klappen, geht aber meistens schief. In der Praxis hat man ja keine 100% idealen Signalflanken, also sollte man lieber etwas mehr Spielraum lassen.

Soweit die Theorie zu den meisten UARTs. Der Pokey funktioniert zwar ähnlich, aber ein kleines Detail macht einen riesen Unterschied:

Bei Experimenten habe ich entdeckt, daß der Pokey nicht genau in der Mitte jedes Bits, sondern 5 Taktzyklen nach der Mitte sampelt. Bei langsamen Bitraten (zB Divisor 40, also 94 Zyklen pro Bit) macht das so gut wie keinen Unterschied. Aber bei hohen Bitraten (zB Divisor 2, 18 Zyklen pro Bit) bewirkt das, daß die Toleranz nach oben (also Sender läuft schneller als Pokey) geringer wird. Die Toleranz nach unten (also Sender langsamer als Pokey) ist dagegen höher.

Kurzum: es ist besser, wenn man beim Pokey die nominelle Transferrate nicht überschreitet - bleibt man geringfügig darunter ist man auf jeden Fall auf der sicheren Seite.

Insofern ist natürlich ein "NTSC" Quarz im SIO2SD/SDrive für einen PAL Atari alles andere als ideal. Umgekehrt wäre es besser, noch besser wäre die Übertragungsrate etwas niedriger als die nominelle PAL Rate anzusetzen.

Ein kleines Rechenbeispiel:

Bei Divisor 3 ist ein Bit 20 Atari-Zyklen lang. Mit NTSC Quarz beginnt das Stopbit 100.57µS nach dem Beginn des Startbits und endet bei 111.75µS. Der PAL-Atari sampelt das Stop-Bit 109.96µS nach dem Beginn des Startbits. Das geht sich anscheinend (gerade) noch gut aus.

Bei Divisor 2 dauert das (NTSC) Stopbit von 90.51µS bis 100.57µS, der PAL-Atari sampelt bei 99.24µS - das ist anscheinend meistens zu knapp und es kommt zu einem Framing Error.

Ich habe dann noch Tests mit AtariSIO gemacht:

Bei Divisor 2 liegt die nominelle Pokey Rate bei 99432 bit/sec (NTSC) bzw. 98525 bit/sec (PAL).

Beim NTSC Atari bekomme ich bis 99632 bit/sec eine stabile Übertragung, beim PAL Atari bis 98963 bit/sec.

@Christoph: weisst Du zufällig wie der UART im Atmel genau arbeitet? Es ist ja seltsam, daß Divisor 1 auch nicht auf dem NTSC Atari klappt (das könnte aber natürlich auch ein elektrisches Problem mit den Signalflanken sein).

so long,

Hias

Hallo,
nur zur Info:

die 14.1875 PAL Oszillatoren gibt es bei darisus.de.

http://darisusgmbh.de/shop/product_info ... S-TTL.html

Gruesse

Moin,

nichtsnutz hat geschrieben:Hallo,
nur zur Info:

die 14.1875 PAL Oszillatoren gibt es bei darisus.de.

http://darisusgmbh.de/shop/product_info ... S-TTL.html

Gruesse

So nichtsnützig biste ja nicht

Vielen Dank für die Info, ich habe gleich mal 10 Stück geordert...

Und übrigens: Der Anbieter hat auch noch 74LS95... *hinweis*

Gruß, Jürgen

nichtsnutz hat geschrieben:die 14.1875 PAL Oszillatoren gibt es bei darisus.de.

Vielen Dank für die Info!

Das sind übrigens keine normalen Quarze sondern fertige Oszillatoren. Der Ausgang des Oszillators muss dann mit XTAL1 vom Atmel verbunden werden, XTAL2 bleibt frei und die Kondensatoren entfallen ebenfalls. Wenn ich das Atmel Datenblatt richtig gelesen habe, müssen ausserdem die CLKSEL Fuses alle auf 0 programmiert werden.

@tfhh: gib' bitte Bescheid, wie das SDrive mit den Oszillatoren läuft, wenn Du sie hast. Ich würde vermuten, daß Divisor 2 dann auch geht. Es wäre sehr interessant ob Divisor 1 auch noch klappt, Divisor 0 wird aber ziemlich sicher nicht gehen, zumindest nicht ohne Änderungen an der SDrive Software (siehe auch das README im aktuellen Highspeed Patch).

so long,

Hias

Moin Hias,

HiassofT hat geschrieben:

nichtsnutz hat geschrieben:die 14.1875 PAL Oszillatoren gibt es bei darisus.de.

Vielen Dank für die Info!

Das sind übrigens keine normalen Quarze sondern fertige Oszillatoren. Der Ausgang des Oszillators muss dann mit XTAL1 vom Atmel verbunden werden, XTAL2 bleibt frei und die Kondensatoren entfallen ebenfalls. Wenn ich das Atmel Datenblatt richtig gelesen habe, müssen ausserdem die CLKSEL Fuses alle auf 0 programmiert werden.

@tfhh: gib' bitte Bescheid, wie das SDrive mit den Oszillatoren läuft, wenn Du sie hast. Ich würde vermuten, daß Divisor 2 dann auch geht. Es wäre sehr interessant ob Divisor 1 auch noch klappt, Divisor 0 wird aber ziemlich sicher nicht gehen, zumindest nicht ohne Änderungen an der SDrive Software (siehe auch das README im aktuellen Highspeed Patch).

Danke für die Infos, da ich noch längst nicht firm in Sachen ATMega bin, werde ich erstmal einen Standard-Quarz aus einem meiner XE´s entfernen und in den XE einen der neuen Oszillatoren einsetzen. Später teste ich dann mit geänderter Schaltung.

Vermutlich komme ich am Wochenende dazu, daß SDRIVE zusammenzubauen, dann werde ich gleich mal Dein neuesten Patch flashen und das Zusammenspiel testen.

Gruß, Jürgen

Wozu so Schlechtwetter (nur knapp über 10 Grad, dazu Dauerregen) doch gut sein kann: heute hab' ich endlich mein SDrive fertig zusammengebaut und danach hab' ich noch die Firmware so gepatcht, daß auch Pokey Divisor 0 läuft :-)

Hier ist eine erste Vorabversion der gepatchten SDrive Firmware:

http://www.horus.com/~hias/tmp/sdrive-hias-090530.zip

Einfach das SDrive.hex und SDrive.eep programmieren. Der Source ist selbstverständlich auch mit dabei.

Am Code habe ich übrigens nur eine Kleinigkeit verändert: Beim Senden wartet das SDrive nun bis das Byte komplett übertragen wurde und macht erst dann im Code weiter. Eigentlich wollte ich danach (zumindest bei höheren Geschwindigkeiten) eine kleine Pause zwischen den Bytes einfügen, aber das war (bei mir) garnicht nötig. Es läuft auch so :-)

Bitte gebt mir Bescheid ob die Firmware bei euch auch läuft, ich werde dann auch mit Raster Kontakt aufnehmen, damit er die Änderungen (wenn sie denn stabil funktionieren) in seine SW Version mit aufnehmen kann.

so long,

Hias

Hallo Hias,

prima das Du Dein Sdrive fertig hast.

Den AVR habe ich geflasht und probiert. Leider geht es bei mir immer noch nur bis Pokey-Div 03/ 89000. Bei mehr schrapelt der Xe so vor sich hin. Ich hatte nur allerdings nur einen XE ohne! Biospatch. Mein XL steht auf Arbeit und da werde ich es heute Nacht auch nochmal probieren.

Vorgegangen bin ich wie folgt.

Hisio.com und Sdrive.com auf ein MyDos 4.53 ATR
Hisio.com => AUTORUN.AR0
Sdrive.com => AUTORUN.AR1

booten

im Sdrive mit <u> Geschwindigkeit verstellt
mit <Q> raus ..... und Schrapel, schrapel

Ich muss mich erstmal hinlegen, 17:30 fängt die wieder Arbeit an.

Hallo Hias,

dein Patch läuft bei mir bis zum Pokey Divisor 1 (112000).
Mit Divisor 0 wird leider nicht mehr gebootet.
Damit ist SDrive jetzt schneller als SIO2SD......

Viele Grüße,
Bernd

Hallo,

man gut das ich Mittags immer wach werde ....

Ich habe den Sdrive Patch nochmal ausprobiert und er läuft natürlich. Bis 01/112000 geht es wunderbar :!: :!: (Ich war wohl heute Morgen doch zu fertig)

Wahrscheinlich kann ich das Sdrive nicht richtig bedienen. Jedenfalls komme ich nur mit einem Kaltstart raus. Ab und an lande ich im Basic, was ja schon gut ist ... Ist ja auch egal. Ich habe beim Sdrive die Speed geändert, das ganze in der Sdrive config gespeichert und dann mit Autorun.sys das ART gebootet und läuft, na klar es läuft.

Bei Pokey "0" und Diag schrapelt der XL rum, liest wohl auch ein paar Sectoren (gr. LED blinkt unregelmäßig) und nach einer Weile kam eine Fehlermeldung. Aber Diag.* werde ich heute Nacht nochmal ausgiebig testen.

Hallo Andreas&Bernd!

Vielen Dank für's Testen!

Vom Divisor 0 würde ich auch lieber die Finger lassen, das Timing dazu ist wohl zu knapp. Mit einem anderen Quarz könnte es aber evtl. funktionieren.

Es wäre interessant wenn einer von Euch ein Oszi an die SIO Input Leitung klemmen könnte und das serielle Timing der original Firmware mit dem Timing der gepatchten (zB bei Divisor 3) vergleichen könnte. Ich hab' ja leider immer noch kein Oszi...

Ich vermute, daß das Stop-Bit geringfügig verlängert wird, das Start-Bit und die Datenbits sind gleich lang wie bisher. Dadurch ist die Wahrscheinlichkeit höher, daß der Pokey keinen Framing-Error meldet. Allerdings kann es das auch ziemlich schiefgehen, wenn beim letzten Datenbit (Bit 7) der Drift schon zu gross ist. Dann kann es passieren, daß Pokey das Stop-Bit statt Bit 7 sampelt und damit falsche Daten empfängt ohne einen Framing Error zu melden.

Bei Divisor 1 sollte es einigermassen sicher sein, auch mit dem 14.318MHz Quarz und einem PAL Atari.

Wieso Divisor 1 mit der original-Firmware auf einem NTSC Atari nicht läuft ist mir zZt aber noch ein Rätsel. Eigentlich sollte das nämlich funktionieren...

so long,

Hias

Hallo Hias,

eine Messung mit dem Oszi kann ich zur Zeit leider nicht machen da das Gerät woanders gebraucht wird.
Dafür habe ich das Quarz ausgetauscht. Original waren es 14,31818 - neu sind es 14,187576.
Nun kommt der Hammer Divisor 0 - 128000 läuft mit deinem veränderten Atmega OS.
Schnell noch überprüft - Das Original OS streikt dabei.



Fehlt noch ein intensiv Test.

Viele Grüße,
Bernd


PS: Die %-Anzeige von Numen reagiert wie ein Sekundenzeiger beim laden.

Hallo Andreas

dl7ukk hat geschrieben:Hisio.com und Sdrive.com auf ein MyDos 4.53 ATR
Hisio.com => AUTORUN.AR0
Sdrive.com => AUTORUN.AR1

AUTORUN ist nicht notwendig. Hisio.AR0 und Sdrive.AR1 funktioniert genau so wie AUTORUN.AR0 und AUTORUN.AR1. Dafür sagt Hisio.AR0 und Sdrive.AR1 mehr über den Inhalt.

Tschüß

Mathy (der hofft das Hias sich die SIO2SD Software auch noch vorknüpft)

Mathy hat geschrieben:Mathy (der hofft das Hias sich die SIO2SD Software auch noch vorknüpft)

Hallo Mathy,
da müssen wir uns noch in Geduld üben. Der Quellcode vom SIO2SD ist noch nicht veröffentlicht.
Angekündigt war es schon vor längerer Zeit........

Zurück zum SDrive.....

Hier wird Crownland bei 128000 geladen..

Bernd

Moin Bernd,

Bernd hat geschrieben:Dafür habe ich das Quarz ausgetauscht. Original waren es 14,31818 - neu sind es 14,187576.
Nun kommt der Hammer Divisor 0 - 128000 läuft mit deinem veränderten Atmega OS.
Schnell noch überprüft - Das Original OS streikt dabei.

Das wundert wohl niemanden

Schön, dann war meine Vermutung offenbar nicht so abwegig...

Was anderes: Du schriebst, Du hast Deinen ATmega mit dem Galep programmiert... was ich da zu beachten? Ich bekomme es nicht hin - oder liegt es daran, daß ich nur einen Galep 3 habe?

Der ATMEGA8 ist bei mir in der Liste - aber das EEPROM kann nur 512 Bytes sein, keine 1024 Bytes. Ich habe trotzdem testweise die EPROM-Datei ab Offset 0x0000 geladen und das EEPROM-File ab 0x2000. Programmieren tut er aber nur bis 0x21FF, also fehlen da Bytes.

Der so programmierte ATmega funktioniert nicht, nur die erste LED (Read, grüne LED) leuchtet und geht beim Drücken auf RESET aus, aber mehr passiert nicht.

Was muß ich beachten? Ist bei den Fuses etwas zu beachten?

Jede Hilfe wird gern genommen.

Danke, Jürgen

tfhh hat geschrieben:Der ATMEGA8 ist bei mir in der Liste - aber das EEPROM kann nur 512 Bytes sein, keine 1024 Bytes. Ich habe trotzdem testweise die EPROM-Datei ab Offset 0x0000 geladen und das EEPROM-File ab 0x2000. Programmieren tut er aber nur bis 0x21FF, also fehlen da Bytes.

Hallo @tfhh,
ich weiss nicht welchen ATMEGA du benutzt aber der ATMEGA8 hat:
-8kB Flash
-512B EEPROM
d.h. Programmdatei 0000h-1fffh und EEPROM 2000h-21ffh.

Mit freundlichen Grüßen

HardwareDoc

Hallo Bernd!

Bernd hat geschrieben:Dafür habe ich das Quarz ausgetauscht. Original waren es 14,31818 - neu sind es 14,187576.
Nun kommt der Hammer :shock Divisor 0 - 128000 läuft mit deinem veränderten Atmega OS. :bounce:
Schnell noch überprüft - Das Original OS streikt dabei.

Super! Vielen Dank für den Test!

Könntest Du bei Gelegenheit mal checken wie hoch das SDrive mit original OS rauf kommt? Ich würde auf Divisor 2 tippen, so wie der NTSC Atari mit dem alten Quarz.

Inzwischen habe ich den SDrive Fix noch ein wenig verbessert: Bis Divisor 4 wird der bisherige Code verwendet (also Senden in einem Rutsch), ab Divisor 3 wird dann mein zusätzlicher Code verwendet. Das beschleunigt die Übertragung bei "normalen" Geschwindigkeit wieder, durch meinen Patch ist die Geschwindigkeit geringfügig gesunken.

Werde noch ein wenig testen und dann morgen die neue Version hochladen.

so long,

Hias

Hallo @Hias,
habe gerade meins mit deiner Firmware versehen und ohne den Quarz zu ändern geht Divisor 0 problemlos.
Echt SUPER !

Mit freundlichen Grüßen

HardwareDoc