Neues aus den Netzen

Besonders in verschiedenen Mailbox-Netzen findet man immer wieder interessante Informationen über alle möglichen Themen. So auch in den entsprechenden Atari-Rubriken. Bisher hatte ich (Michael Vondung) die diversen Informationen aus den Netzen immer in den jeweiligen Rubriken des Magazines verteilt. Nun findet Ihr alle News aus dem Maus- und Fido-Net nun in einer eigenen Rubrik. Die behandelten Themen sind völlig unterschiedlicher Natur und haben nur eines gemeinsam: Sie handeln von Atari-Rechnern und Atari-Software. Da ich pro Monat mehrere Megabyte Maus- und Fido-Nachrichten bekomme, kann die Rubrik auch etwas umfangreich werden. Aus diesem Grund folgt zu Beginn dieser Rubrik auch eine kurze 'Inhaltsübersicht' der Themen, die in diversen Mails angesprochen werden. Die Regelmäßigkeit dieser Rubrik hängt von meiner freien Zeit und vor allem von der Verfügbarkeit der Nachrichten ab. Am Ende der Rubrik findet Ihr übrigens eine Übersicht aller ereichbarer Maus-Boxen nebst Telefonnummer.

Folgende Themen werden in dieser Ausgabe angeschnitten:

Eine häufige Frage, die nicht nur bei sog. Anfängern auftritt, ist die nach dem Unterschied zwischen dem Begriff 'Baud' und dem Kürzel 'bps'. Die meisten DFÜ'ler sind der Meinung, daß das dasselbe ist. Auch in der Gruppe 'Atari ST' im MausNet kam diese Frage auf.

Matthias Hanft schrieb dazu folgendes:
'Baud' bezeichnet die 'Schrittgeschwindigkeit' auf der Telefonleitung, also die Anzahl der Zustandsänderungen pro Sekunde. Bei 300 bps war's noch einfach (auch bei 1200/75), da symbolisiert jedes Bit einen Ton bzw. eine Zustandsänderung, hier sind bps=Baud. Ab 1200 bps (V.22) werden immer mehrere Bits zusammengefaßt (ich glaube, zwischen zwei bei 1.200 und vier bei 9.600 [correct me if I'm wrong]) und als eine Zustandsänderung auf der Telefonleitung übertragen. Eine 'Zustandsänderung' ist die Änderung der Phase und/oder Amplitude des Carriers.

Soweit ich mich erinnern kann, geht's so (nagelt mich da aber jetzt nicht fest, die Zahlen müssen nicht genau stimmen, es geht nur ums Prinzip):

Norm bps Zusammengefaßte (gleichzeitig
übertragene) Bits pro Zustandsänderung		 Baud
V.21 300 1 300
V.23 1200/75 1 1200/75
V.22 1200 2 600
V.22bis 2400 4 600
V.32 9600 4 2400

'Trellis Coding' nimmt glaub ich sogar 5 Bits pro Baud bei V.32 (ergibt eine höhere Bitfehlersicherheit).

Die 'Baud' sind durch den Frquenzgang des Übertragungskanals begrenzt: Das analoge Telefonnetz überträgt 300 Hz - 3400 Hz, d.h. es hat eine Bandbreite von 3100 Hz, mithin lassen sich maximal 3100 Baud damit übertragen. Damit ist also die physikalische Grenze für High-Speed-Modems gesetzt. Verschnellern lassen sich die Dinger nur, wenn immer mehr Bits in ein Baud gepackt werden (man verzeihe mir diese 'lasche' Ausdrucksweise :-), aber im gleichen Maß müssen die Empfänger 'besser' werden, da ja z.B. bei 4 Bit/Baud schon 16 Carrierzustände auftreten können (im Hinblick auf Amplitude und Phase), die vom Empfänger unterschieden können werden müssen (müssen werden können? :-). Ohne moderne und teure Signalprozessoren in den Modems ist das nicht zu machen.

Dazu kommt noch, daß Verfahren wie V.22(bis) weniger als die Hälfte der Bandbreite des Telefonkanals ausnutzen (eben nur 600 Baud von - theoretisch - 3100 möglichen, s.o.) und daher auf unterschiedlichen Frequenzen senden und empfangen können. Bei V.32 sind aber 2400 Baud mehr als die Hälfte von 3100, so daß beide Modems auf der gleichen Frequenz senden und jedes Modem für den Empfang der Gegenstelle vom Leitungssignal erst mal das abziehen muß, was es gerade selber sendet. Auch wieder ein Job für die Signalprozessoren. (Wobei die 3100 eh nur der theoretische Grenzwert ist, die Realität geht vielleicht bis 2500-2800 oder so.)

Anmerkung: Die 'bps' da oben in der Tabelle sind die maximal erreichbaren mit der jeweiligen Norm; übertragungstechnisch ließen sich ohne weiteres auch nur 300 bps mit V.32 übertragen (nur macht das eben keiner, und die Modems können's auch nicht, wozu auch).

So, jetzt ist die Verwirrung komplett, nur auf viel höherem Niveau :-)

Matthias Hanft, MausNet

Diskutiert wurde im MausNet in den vergangen Wochen auch das Thema 'Cache bei Quantum-Festplatten'. Von Benedikt Heinen (FidoNet) war dazu folgendes zu lesen:

Die Quantum Platte haben saemtlichst 64KB READ-Cache! Nur bei den neueren Typen sieht die Sache anders aus. Die 240LPS (kann ich nur empfehlen!!!) hat 256KB HardCache, der sich nach Aussagen von Quantum auf 64KB ReadCache & 178KB WriteCache verteilt. Das gleiche gilt auch für die 120LPS.

Geschwindigkeits-Unterschiede nach RateHD:

               DatenRate (kB/sec)

LPS52            950-1000
PD210S          1100-1150
120LPS          1250-1300
240LPS          1450-1500
(gemessen an MegaST 4 /ICD Micro bez. ICD-Advantage)
240LPS          1260-1300

(gemessen an MegaSTE 4/Atari-Controller) (Ich glaube, ich lasse mir noch von meinem Haendler den Controller austauschen, der Micro ist schneller und hat die eindeutig bessere Software ....)

Benedikt Heinen, FidoNet

Auch ein Thema war in den vergangegen Wochen 'TIFF-Konverter'. Holger Zuck (MausNet) schrieb zu diesem Thema folgendes:
Selbst wenn wir die freidefinierten Tags einmal weglassen, gibt es schon genug TIFF-Varianten:
TIFF-Spezifikation Version 5.0 definiert vier Klassen zum Speichern von Bilddaten:

TIFF-B Bilevel-Bilder
TIFF-G Graustufen-Bilder
TIFF-P Farbpaletten-Bilder
TIFF-R Farb-RGB-Bilder

Die Bilddaten selber liegen als Image Raster Block in freien Bereichen innerhalb der TIFF-Datei. Hier bestehen beim Abspeichern zwei Möglich- keiten:

Darüberhinaus erlaubt es die TIFF-Spezifikation auch, daß eine TIFF-Datei mehrere Bilder zugleich enthält (z.B. dasselbe Bild in verschiedenen Auflösungen, um mit der niedrigeren Auflösung schnelle Kontrollausdrucke machen zu können).

Schließlich sind noch mehrere verschiedene Kodierungsverfahren für die Kompression vorgesehen:

Macht alles in allem 'zig verschiedene Varianten. Dazu kommt noch ein eigentlich lächerliches Problem, nämlich das Abspeichern im Intel- oder im Motorola-Format. Dafür gibt es zwar im TIFF-Header einen Eintrag (Offset 00H = 'II' oder 'MM'). Ich kenne aber einige Programme, die dies als Abbruchgrund ansehen.

Fazit: Nie Annahmen machen, wenn man eine Konvertierung schreibt.
(Holger Zuck @ BB, MausNet)

Für alle Benutzer vom ZMODEM GEMSZRZ von Michael Ziegeler gab Gerhard Schneider (MausNet) einen wichtigen Hinweis:
Übrigens habe ich gerade eine PM von Michael bekommen: Leute, die eine Version >2.25 besitzen, können u.U. keine Seriennummer auf der Diskette haben (in einem File UPD.TXT); wenn sich diese direkt an ihn wenden (mit Adresse!), bekommen sie sie umgehend mitgeteilt.
(Gerhard Schneider @ N, MausNet)

ACS nicht für Pure Pascal

Rainer Esser schrieb, daß ACS nur für Maxon Pascal angekündigt sei, nicht aber für Pure Pascal. Daraufin wurde er von Andreas Goetzke gefragt, woher er denn diese Information hat. Folgende Anwort kam von Rainer Esser:

Dazu waren extrem aufwendige Recherchen und viele hundert Telefonate nötig ;-).
Im Ernst : In früheren ST Computern stand immer drin :
'ACS arbeitet derzeit mit Pure C und Turbo C zusammen. Weitere C Compiler und andere Programmiersprachen wie z.B. MAXON Pascal sind in Vorbereitung.' Daraus kann man wohl schließen, daß ACS erst für MAXON Pascal angepaßt wird. Wie ich schon vorher geschrieben habe, ergibt sich daraus der Punkt, daß MAXON wohl erst für den eigenen Compiler anpassen wird und nicht das Konkurrenzprodukt noch damit stärken wird. (Dies ist meine Meinung die aber nicht unbedingt die Meinung von Maxon sein muß).

Weiterhin kann es möglich sein, das ACS direkt auf beiden Compilern läuft. Bleibt noch mein vorsichtiger Kommentar ob überhaupt angepaßt wird.

Erklärung dazu : In Heft 5/92 steht bei der ACS-Werbung : 'ACS arbeitet derzeit mit Pure C und Turbo C 2.0 zusammen'

Es steht also nichts mehr über Anpassungen an andere Sprachen drin. Deshalb habe ich vorsichtig formuliert.
(Rainer Esser, MausNet)

GFA-Basic 4.0 in Sicht?

Nichts beschäftigt GFA-BASIC-Programmierer in der letzten Zeit so wie die Frage, wie es denn mit 'ihrer' Sprache weitergehen mit. Sicher ist auf jeden Fall, daß der Interpreter nicht mit MinT zusammenarbeit und so mit hoher Wahrscheinlichkeit auch nicht mit MultiTOS funktioniert. GFA- Compilate sind davon nicht unbedingt betroffen. Ulf Dunkel schrieb zu diesem Thema folgendes:

Frank Ostrowski versprach mir am Dienstag telefonisch, die Accessory- Status-Abfrage in ~APPL_INIT() (=Register a0-Abfrage) mit einzubauen, und - tüchtig über einen Interpreter mit GEM-Oberfläche nachzudenken.

Sein Hauptargument gegen die GEM-Oberfläche war bisher, daß seine Ausgaberoutinen im Editor dann zu langsam würden:

Und da dies unter TOS 1.0 (!!!) wohl zu langsam wäre, war er bisher bei seiner Merkwürdig-Oberfläche geblieben. (Grenzenloses Kopfschütteln meinerseits...)
(Ulf Dunkel, MausNet)

Atari-Geschäftszahlen weiter im Minus

Zwar befindet sich die Mehrheit der Atari-Anwender im Falcon-Taumel, aber in der letzten Zeit mehrten sich auch die Stimmen im MausNet, die der Meinung sind, daß die CeBIT-Vorführung des Falcons ein Bluff war. Zweifelsohne gibt es kleine leistungsfähige Boards, die man in ein Atari- Gehäuse einbauen könnte. Gerüchte über Gerüchte also (wobei ich allerdings ein Gespräch mit dem Atari-Journal-Redakteur Kai-Uwe Wahl führte, der mir u.a. definitiv bestätigte, daß Entwickler-Falcons auch schon in Deutschland angekommen sind... freuen wir uns also auf die Atari-Messe)

Eine Tatsache dagegen sind die Verluste in der Atari-Bilanz. Michael Mies schrieb vor kurzem:
Für alle Liebhaber von Hiobsbotschaften:
Atari Corp., New York (USA), hat im ersten Quartal des Geschäftsjahres 1992 den Nettoverlust gegenüber dem Vergleichszeitraum des Vorjahres von 1,987 Millionen Dollar auf 13,848 Millionen Dollar ausgeweitet. Der Umsatz veringerte sich von 63,4 Millionen Dollar auf 44,1 Millionen Dollar.
(aus PC Magazin 22/92)

Wenn das so weiter geht, darf man wohl fragen, wie lange uns Atari noch erhalten bleibt.
(Michael Mies, MausNet)

Dazu ist allerdings anzumerken, daß fast alle Computerfirmen derzeit recht große Verluste einfahren... Atari bildet hier keine Ausnahme.

Volker Söhnitz (Virendetektor) zum 'Wolf-Virus'

Vom 'Viren-Guru' Volker Söhnitz gab's in den vergangen Wochen einen neuen Update seinen Programmes 'Virendetektor'. Außerdem kamen wieder Gerüchte über einen alten, aber mutierten Virus auf, die von V. Söhnitz selbst produziert wurden. Er schreibt dazu:

Hi,
vor einigen Wochen habe ich - bezugnehmend auf ein Hardware-Problem, bei dem sich der Arbeitsspeicher des ST von 2,5 MB gelegentlich auf 640 KB 'verkleinerte' - auf den o.g. Virus hingewiesen. (Inzwischen hat sich übrigens wohl herausgestellt, daß in diesem Fall kein Virus, sondern ein Hardwaredefekt für diesen Effekt verantwortlich war.)

Zur Erinnerung: Dieser Virus halbiert das verfügbare RAM, bis zu dreimal und deinstalliert sich nach der dritten Infektion wieder. Er kopiert sich auf den Bootsektor von Drive A und B, unabhängig davon, ob dieser bereits ausführbar ist. Unfreundlicherweise meldet sich der Virus beim Booten mit exakt der gleichen Meldung, die auch Sagrotan-Immunisierungs-Bootsektoren ausgeben ('Kein Virus im Bootsektor'), selbige werden auch gnadenlos überschrieben. Zusätzlich besitzt der Bootsektor weiterhin die für MS-DOS- Disketten typische Kennung in den ersten drei Bytes!

Auf eine Nachfrage hatte ich hier öffentlich geantwortet, daß Sagrotan natürlich erkennen wird, daß es sich bei diesem Virus nicht um den eigenen Immunisierungs-Bootsektor handelt und daß Sagrotan mit Hilfe seiner Bootsektoranalyse zumindest einen Virenverdacht melden sollte. Ich hatte dies allerdings leider nicht selbst ausprobiert (ASCHE, bringt mehr Asche...)!

Diese Aussage ist nämlich bedauerlicherweise F A L S C H !

D.h. Sagrotan 4.17 meldet bei der Überprüfung einer mit diesem Virus befallenen Diskette zwar nicht den eigenen Immunisierungs-Bootsektor, um den es sich ja auch nicht handelt, aber es kommentiert diesen Virus mit:

_ Der Bootsektor ist ausführbar, da die Prüfsumme $1234 beträgt.
Es handelt sich um eine MS-DOS-Diskette.
Es wird eine Sicherheitsüberprüfung des Bootprogramms durchgeführt.
Das Bootprogramm trägt kein Merkmal eines Virusprogrammes._

Eine ähnliche Meldung ('absolut keine Virenmerkmale') spuckt auch Poison 1.6 aus; wie die Autoren dieses Programms glaubhaft versichern, soll die Analyseroutine in der nächsten Version jedoch deutlich zuverlässiger arbeiten.

Ich entschuldige mich für die falsche Information und werde in Zukunft keine derartigen Vermutungen mehr äußern, ohne diese auch nachgeprüft zu haben. :-(
(Volker Söhnitz)

HD-Disketten in normalen (DD-)Laufwerken

Die meisten Anwender, die schon einmal versucht haben, HD-Disketten in einem normalen 720-KByte-Laufwerk zu benutzen, werden die Erfahrung gemacht haben, daß es dabei zu Problemen kommt. Ein Bekannter Armin Schrecks scheint diese Erfahrung auch gemacht zu haben, was A. Schreck dazu veranlaßte, im MausNet einmal nach diesem Phänomen zu fragen. Nachfolgend nun zuerst die Frage und dann die Antworten anderer Maus'ler.

Von : Armin Schreck @ B (Fr, 29.05.92 17:26)
Also!
'n Kollege hat sich 100 HD-Disketten (zum Preis von DD-Disketten) für einen MEGA-2 (mit normalem Laufwerk) gekauft. Kann mir 'mal jemand sagen, wieso der Rechner die NICHT korrekt bzw. überhaupt nicht formatieren kann (weder vom Desktop aus noch mit HCOPY17s)?

Ich dachte immer, daß

  1. eine unformatierte Diskette KEINE Spuren und Sektoren besitzt, sondern daß
  2. dieses beim Formatieren aufgetragen wird, so daß
  3. für den Rechner im Rohzustand praktisch nur eine einheitliche 'Magnetscheibe' existiert, so daß
  4. er/sie/es gar nicht den Unterschied zwischen HD und DD erkennen kann (oder besitzen die einen erkennbaren Unterschied in der 'Feinheit' der Magnetisierung?), und daß
  5. ein MEGA-2 auch keine hardwaremäßige Erkennung für HD-Disketten besitzt (z.B. Abtastung der 2. Öffnung).

Also: wie/was macht diese beknackte System (mit TOS 1.02) mit den Disketten? Muß ich z.B. die Steprate oder die Anzahl der Spuren und Sektoren verändern oder wie geht's hier weiter?
Danke und Tschüß, Armin

Von : Sevo Stille @ F (Sa, 30.05.92 13:42)
AS> 4. er/sie/es garnicht den Unterschied zwischen HD und DD erkennen
AS> kann (oder besitzen die einen erkennbaren Unterschied in der
AS> 'Feinheit' der Magnetisierung?). Aber heftig! Das ist wie mit Normal- und Chromkassetten auf dem Kassettenrecorder, da sind ganz unterschiedliche Aufsprechströme fällig! Selbst wenn du sie formatiert bekämst, sie wären niemals sicher und zuverlässig!!!!
Versuch sie an jemanden mit HD-Laufwerk zu verkaufen!!!
viele Grüße
Sevo

Von : Hans-Ch Eckert @ B (Sa, 30.05.92 09:29)
HD- und DD-Disketten unterscheiden sich auch im Material der Beschichtung.
Gruß, Ripley

Von : Frank Daufenbach @ RS (Sa, 30.05.92 20:58)
Hallo Armin,
es ist möglich, daß du mit deiner Vorahnung recht hast.
AS> 4. er/sie/es garnicht den Unterschied zwischen HD und DD erkennen
AS> kann (oder besitzen die einen erkennbaren Unterschied in der
AS> 'Feinheit' der Magnetisierung?).

Einige Kollegen hatte die gleichen Schwierigkeiten und beim Nachforschen festgestellt, daß HD-Disketten wegen ihrer hohen Schreibdichte eine höhere Magnetisierung des Schreib/Lesekopfes brauchen. Dieses können anscheinend viele DD-Laufwerke nicht. Mit meinen (Teac und Epson) habe ich noch keine Schwierigkeiten dieser Art gehabt.
mfG Frank

Angekündigte Oxyd-Produkte

Es tauchten auch vereinzelt Gerüchte auf, daß es bald ein OXYD III geben wird. Bestätigen konnte das allerdings (bisher) niemand. Von Bernhard Artz kam zu diesem Thema aber folgende Ergänzung:

Von : Bernhard Artz @ RS (Fr, 29.05.92 09:24)
Gerüchten zufolge soll noch in diesem Jahr folgendes von Dongleware erscheinen: ( Laut Händlerpreisliste ! )

MfG
Bernhard

Papyrus-Demo verfügbar

Der Vertrieb von Papyrus wirbt mit dem Slogan 'Die freundliche Textver- arbeitung'. Außer diverse Zeitschriften-Redaktionen und 'Früh-Käufer' konnte dies bisher noch niemand testen, wenngleich die Testergebnisse in den Fachmagazinen durchweg positiv waren. Nun endlich gibt es auch eine Demo dieser Textverarbeitung. Armin Schreck schrieb im MausNet dazu folgendes und gibt auch (für DFÜ'ler) gleich eine Bezugsquelle an:
Von : Armin Schreck @ B (Sa, 30.05.92 23:40)

_>An Papyrus bin ich auch interessiert. Meine Fragen:

Gibt es schon eine Demoversion?_

Ja, seit gestern in @ Berlin! Macht einen SEHR GUTEN Eindruck!

1026 ST TOS PAPDEMO.LZH 506579 36:56 1 1.00 29.05.92
Textverarbeitung/Editor, Demoversion
Demo zur Textverarbeitung papyrus
einzige Einschränkung: im Ausdruck werden gelegentlich 'e' gespiegelt

Ciao Armin

Anmerkung der Redaktion: Mittlerweile müßte das Demo bei Ralf zu haben sein.

TV-Modul für Lynx :-)

Als Beweis, daß es in Mailboxnetzen oft locker und flippig zugeht, seien die nächsten Nachrichten angeführt. Andreas Klengler (FidoNet) fragte an, ob es ein TV-Modul für die Lynx gibt. Eine Antwort kam von Frank Brodmuehler (ebenfalls FidoNet):

AK> Hallo Leute,
AK> ich habe einen Lynx . Kann man den auch als MINI TV wie z.B. bei
AK> Game Gear benutzen. Schreibt mir doch mal 'ne PM

Kein Problem .... Man kaufe sich einen Casio Farb-LCD Fernseher (DM 198) Und klebe ihn mit doppeltem Klebeband auf die Rückseite deines LYNX. Für Lynx I nehme man 5 cm doppelseitiges Klebeband. Fuer Lynx II reichen 4,5 cm. Jetzt braucht man nur noch einmal um den Lynx rumgehen um auf die andere Seite zu kommen und schon kann man Fernsehen. Das hat den Vorteil gegenüber der Game Gear Lösung, daß gleichzeitig ein Benutzer spielen kann (im Gegensatz zur Game Gear Lösung bei der der Modulschacht durch das TV Teil (merkwürdigerweise auch 198.-) belegt ist) während der andere weiter fernsehen kann. Nur bei Klax ist ist der fernsehende User gezwungen die vertikale Lage anzunehmen weil das Spiel den LCD Bildschirm im Querformat nutzt.

Das TV Teil ist überigens auch zu anderen Formaten (CASIO, Sharp Philips) kompatibel. Die alle NICHT den Modulschacht belegen. Es muss nur teilweise die Länge des Doppelklebebandes angepasst werden. (Frank Brodmuehler, FidoNet)

Marvin pleite

Oliver Siffrin (FidoNet) hat am 18.05. in einer Mail folgende Nachricht gepostet:

Hallo liebe Atarianer... Wie ich jetzt am Wochenende von einem Bekannten erfahren habe, ist die Fa. Marvin aus der Schweiz neulich pleite gegangen.
Hoffentlich trifft es nicht zu viele von euch.
Dies habe ich auch nur erfahren, da das Scannerinterface, welches mein Bekannter bei Richter gekauft hatte (welcher ja Marvin Produkte vertreibt), kaputt gegangen ist und daraufhin zu Marvin eingesandt worden war.
Das Interface liegt nun irgendwo bei Marvin 'rum und kann nicht mehr so einfach wieder rausgeloest werden...
Die Fa. Richter hat schon einen Anwalt eingeschaltet.
Wie der Service mit den verkauften Marvin Produkten weitergehen soll, ist mir nicht bekannt. Tolle Aussichten...
(Oliver Siffrin, FidoNet)

Ob diese Sache zutreffend ist, kann ich nicht bestätigen, da zum gegenwärtigen Zeitpunkt in der Fachpresse darüber noch nichts zu lesen war. Wer von einer Marvin-Pleite betroffen wäre, kann sich ja mal an Richter wenden.

So, das war's für diesen Monat. Die Rubrik ist ja recht umfangreich ge- worden. Ich hoffe, es war für jeden etwas interessantes dabei.

Interessant fände ich einige Meinungen zu dieser Rubrik. D.h. falls es niemanden interessiert, wäre die Arbeit umsonst und ich könnte mir den Zeitaufwand sparen. Also: Meinungen zu und über diese Potpourri-Rubrik bitte an Timo.

(Zusammengetragen und kommentiert: Michael Vondung)


Aus: STraight Up 09 / 1992, Seite
Links
Copyright-Bestimmungen: siehe Über diese Seite