XS-1541 JAVA-API beta release

BlackJack · 13. Dezember 2009

Diddl: Beim ersten Vorschlag kommt zum Zug, dass in Enums die Werte echte Objekte sind, und nicht einfach nur Zahlen wie in C. Man kann denen also Felder und Methoden verpassen. Dass man sie trotzdem mit ``==`` und ``!=`` vergleichen kann, liegt daran, dass es "Singletons" sind, also in dem `Enum`-Konstrukt genau ein Exemplar von jedem Typ angelegt wird und damit in der Implementierung zum Beispiel effizient die Speicheradressen verglichen werden können.

Die Frage nach den ``friend``\s verstehe ich nicht? Bezog sich das auf den zweiten, alternativen Vorschlag? Virtuell sind in Java *alle* Methoden.

Wie sieht das eigentlich mit dem BusType aus -- gibt es Laufwerke, die mehr als einen Typ unterstützen? Wenn nicht, wäre das IMHO auch besser bei den konkreten Typen für die Laufwerke aufgehoben als in einem Enum.

Diddl · 13. Dezember 2009

Methoden für Enums, ist fast wie ne Klasse in der Klasse?

Zitat von BlackJack

Wie sieht das eigentlich mit dem BusType aus -- gibt es Laufwerke, die mehr als einen Typ unterstützen? Wenn nicht, wäre das IMHO auch besser bei den konkreten Typen für die Laufwerke aufgehoben als in einem Enum.

Die Bustype ist spezifisch für das Laufwerk. Ich kenne kein Laufwerk das IEC und IEEE hat. Rein technisch wäre es vorstellbar, und es hat auch schon Umbauten von 1541 auf IEEE-488 gegeben.

Evt. kommt noch eine Bustype dazu, die vom 1551 Laufwerk. Aber im Moment wird das noch nicht unterstützt vom XS-1541.

Diddl · 13. Dezember 2009

So, alles geändert.

Würde es auch Sinn machen alle anderen Floppy Eigenschaften (wie Anzahl Spuren, Sektoren pro Spur, ...) auch als abstrakte Funktionen in der Floppy Klasse zu definieren?

Denn jetzt kann man das im Konstruktor einfach weg löschen bzw. beim Definieren einer neuen FloppyType einfach weglassen. Wenn es abstrakte Funktionen gäbe

abstract public int getTracks();
abstract public int[] getSectors();
abstract public int getBusType();
abstract public int getReadMode();
abstract public int getTransfer();

wäre der Coder der neuen Floppytype gezwungen alles zu definieren?

BlackJack · 13. Dezember 2009

Diddl: Das ``enum`` selbst ist schon eine Art Klasse in der Klasse. Hätte man ja auch in einer eigenen Datei anlegen können. Das ``enum`` definiert so etwas ähnliches wie eine nach aussen abstrakte Klasse vom Typ `Enum` und die Aufzählungskonstanten darin sind Exemplare davon. Die können erst einmal nur was die `Enum`-Klasse aus der Standardbibliothek bereitstellt, aber man kann eben noch zusätzliche Felder und Methoden hinzufügen. Sogar spezifisch für die einzelnen Konstanten.

http://java.sun.com/j2se/1.5.0…guide/language/enums.html

Aber wie schon gesagt, der Laufwerkstyp und der Bustyp gehörem IMHO nicht unbedingt in ``enum``\s sondern in die konkreten Klassen, die ein Laufwerk modellieren.

Diddl · 13. Dezember 2009

Der Konstruktor in der Floppy Klasse sieht nun so aus:

Code

public Floppy(XS1541 xs1541, int device)
{
super();
this.xs1541 = xs1541;
this.device = device; // device number, usually 8 to 15
// DATA FROM FLOPPY DEVICE (INHERITED CLASS)
tracks = getDefTracks();
sectors = getSectors();
busType = getBusType();
readMode = getDefReadMode();
transfer = getDefTransfer();
// DATA FROM INSERTED DISK
diskName = ""; // DISK NAME :: FROM LAST DIRECTORY READ
diskFree = 0; // DISK BLOCKS FREE :: FROM LAST DIRECTORY READ
floppyIdentification = "";
}
abstract public String getTypeString(); // GET NAME OF FLOPPYTYPE
abstract public int getDefTracks();
abstract public int[] getSectors();
abstract public BusType getBusType();
abstract public ReadMode getDefReadMode();
abstract public Transfer getDefTransfer();
abstract public void setReadMode(ReadMode rm);
abstract public void setTransfer(Transfer trsf);

Alles anzeigen

Und die F_1541 Klasse sieht nun so aus:

Code

public class F_1541 extends Floppy
{
public F_1541(XS1541 xs1541, int device)
{
super(xs1541, device);
}
@Override
public String getTypeString()
{
return "1541";
}
// FOR STANDARD FORMAT
public int getDefTracks()
{
return 35;
}
// FOR NON STANDARD FORMATS (1541 only)
public void setTracks(int tracks)
{
if (tracks >= 35 && tracks <= 42)
this.tracks = tracks;
}
@Override
public int[] getSectors()
{
int[] secs = { 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21 // 1..17
, 19, 19, 19, 19, 19, 19, 19 // 18..24
, 18, 18, 18, 18, 18, 18 // 25..30
, 17, 17, 17, 17, 17 // 31..35
, 17, 17, 17, 17, 17, 17, 17 // 36..42
};
return secs;
}
@Override
public BusType getBusType()
{
return BusType.IEC;
}
@Override
public ReadMode getDefReadMode()
{
return ReadMode.WARP;
}
@Override
public Transfer getDefTransfer()
{
return Transfer.S2;
}
@Override
public void setReadMode(ReadMode readMode)
{
// ALL READ MODES ALLOWED
this.readMode = readMode;
}
@Override
public void setTransfer(Transfer transfer)
{
// NO BURSTMODE ALLOWED
if (transfer == Transfer.S1 || transfer == Transfer.S2 || transfer == Transfer.PAR || transfer == Transfer.STD)
this.transfer = transfer;
}
}

Alles anzeigen

BlackJack · 13. Dezember 2009

Diddl: Warum klemmt eigentlich bei Kommentaren im Quelltext bei Dir immer die Shift-Taste!?

Was Sinn in der konkreten Klasse macht und was in der Abstrakten hängt davon ab, wieviele konkrete Klassen sich den Code sinnvoll teilen können. Wenn ich losprogrammiere ohne grossartig alles vorher zu planen, dann mache ich das in der Regel anders herum: Ich weiss ich brauche mehrere verschiedene Klassen mit der gleichen Schnittstelle, also definiere ich ein Interface dafür. Dann implementiere ich eine konkrekte Klasse, die dieses Interface anbietet. Und wenn ich dann beim implementieren weiterer Klassen merke, dass die gleichen oder zumindest ziemlich ähnlichen Code enthalten werden, ziehe ich den in eine gemeinsame abstrakte Basisklasse hoch.

Der Kommentar im `Floppy`-Konstruktor "(INHERITED CLASS)" ist falsch, weil die Daten ja von einem Exemplar der Unterklasse und nicht von einem Exemplar einer geerbten Klasse kommen. Ansonsten muss man die Sachen, die nicht vom Default abweichen können, doch nicht unbedingt in der `Floppy`-Klasse in Feldern speichern. Man kann sie doch jederzeit über die "Getter" bekommen. Abkürzungen finde ich persönlich übrigens nicht so toll. "Def" statt "Default" spart nich wirklich viel ein, aber man muss halt im Zweifelsfall erst rätseln ob das für "Default", "Defined", oder vielleicht sogar etwas anderes steht. Mit Mehraufwand beim Tippen kann man bei IDEs mit Autovervollständigung auch nicht argumentieren.

Bei so Sachen wie `setTracks()` und `setTransfer()` würde ich Ausnahmen auslösen und illegale Werte nicht einfach ignorieren.

`setReadMode()` und `setTransfer()` könnte man zum Beispiel in die abstrakte Klasse verlegen und den konkreten Klassen zum Beispiel eine `getAllowedTransfer()`-Methode geben, die ein `EnumSet` liefert.

Diddl · 15. Januar 2010

So endlich flutscht es auch bei hoher Datenrate mit dem Java RXTX!

Alle Beispiele im Netz die ich gefunden habe machen es falsch. Es wird ja auch viel gejammert über das RXTX. Der Clou ist, man muss nur "BufferedInputStream" verwenden anstatt wie überall propagiert den "InputStream".

Jetzt noch ein paar Dauertests und die erste Release Version kann raus ...

Draco · 15. Januar 2010

Das Problem an den Beispielen im Netz ist, daß sie überwiegend von Noobs per Cut&Paste verteilt werden.

jackdaniels · 15. Januar 2010

Zitat von Diddl

Der Clou ist, man muss nur "BufferedInputStream" verwenden anstatt wie überall propagiert den "InputStream".

bei mir gingen ja vorher schon die hohen datenraten! hatte ich dir ja gesagt... müsste aber nachschauen wie ichs gemacht habe! ich hatte die beispiele direkt von der rxtx homepage genommen meine ich!

zumindest war es von anfang an kein problem die hohen baudraten zu nutzen

Draco · 16. Januar 2010

Der "BufferedInputStream" sollte sich eigentlich nur auf den Datendurchsatz auswirken. Prüfe mal, ob Hardware Handshaking verwendet wird.

Diddl · 16. Januar 2010

Zitat von jackdaniels

zumindest war es von anfang an kein problem die hohen baudraten zu nutzen

Die 115200 an sich sind ja auch nicht das Problem. Erst wenn man mehrere KB in einem Satz ohne Pause sendet. Bei S1 und S2 entstehen zwischen den Sektoren immer kurze Pause, da geht es noch ohne BufferedInputStream.

Zitat von Draco

Der "BufferedInputStream" sollte sich eigentlich nur auf den Datendurchsatz auswirken. Prüfe mal, ob Hardware Handshaking verwendet wird.

Nö, kein Handshaking: 115200, 8, N, 1

Es ist Fakt, es werden einfach Zeichen verschluckt, obwohl der Empfangsbuffer auf 16KB gesetzt ist und die Datenmenge weit drunter liegt.

Wenn ich den Code zurück baue habe ich sofort wieder diesen Fehler. Das habe ich ausprobiert.

Aber egal, jetzt geht es ja endlich einwandfrei.