Posts by Mafiosino

Quote from rayden

Andernfalls mit bit 1 "initialisieren":

Code

1. lda zeropageByte [3] ; clear bit 1
2. and #%00000010 [2]
3. sta zeropageByte [3]
4. lsr zeropageByte [6] ; shift to the right, carry flag contains now former bit 0
5. bcc nottin [2/3] ; carry is clear: do nothing
6. inc zeropageByte [5] ; carry is set: increase zeropageByte => current bit 0 becomes 1
7. .nottin
8. rol zeropageByte [5] ; rotate to the left, carry flag is shifted into bit 0

insgesamt 26/27 Taktzyklen und 14 bytes.

Freitags-brain-fart und ungestestet.

Ich glaube, du meinst and #%11111101, sonst hast du dein zeropageByte fast komplett zerstört.

Quote from 5ace

Quote from Mafiosino

Ich habe noch einen Vorschlag, inspiriert durch bernies erste Version und ayvazhzfs Version. Der ist aber auch ungetestet:

Code

1. ldx byte
2. inx
3. txa
4. and #%00000010
5. eor byte
6. sta byte

Die Idee ist, dass man sich das shiften spart und damit weniger Bytes braucht.

Ich denke, dass bspw. "xxxxxx11" nicht funktionieren würde, weil das inx das nächste Bit (Bit 2) beeinflusst.

Bit 2 kann nicht beeinflusst werden, da and #%00000010 alle Bits außer Bit 1 neutralisiert.

Ich habe noch einen Vorschlag, inspiriert durch bernies erste Version und ayvazhzfs Version. Der ist aber auch ungetestet:

Die Idee ist, dass man sich das shiften spart und damit weniger Bytes braucht.

Ich war in letzter Zeit viel unterwegs und deshalb kommt der Quelltext zu meinem Beitrag erst jetzt.

Ich muss zugeben, dass ich es diesmal etwas verkackt habe. Ich war der Meinung, dass ich in jedem Fall vorher die Daten durch Kopieren in Sicherheit bringen muss, weil ich zuwenig Platz zum Rangieren habe. Das stimmt aber nicht.

Ich brauche immer die Angaben, wo ungefähr gerade die beste Lösung liegt. Wenn ich zum Beispiel gewusst hätte, dass 43 Byte möglich sind, dann hätte ich gewusst, dass mein Ansatz falsch ist und es einen besseren geben muss. So habe ich nur meinen Ansatz mit Gewalt in den 4x Bereich gequetscht.

Die Compos machen mir immer viel Spaß. Aber ab einem gewissen Grad bin ich mir unsicher wegen der Regeln. Es war zum Beispiel vorgegeben, dass das Zielsprite gelöscht werden soll, obwohl es nach einem Reset auf 0 gesetzt wird. Mein Programm geht aber zum Beispiel davon aus, dass im Basicspeicher irgenwo in den ersten 256 Bytes drei Nullen stehen. Ansonsten stürzt es beim Laden ab. Davon kann man aber eigentlich nicht ausgehen. Der Speicher kann ja irgendwie belegt sein. Also wenn man "sauber" programmiert, muss man mein rts durch 3 Nullen ersetzen und mein Programm hat 51 Bytes.

Oh, da war ich knapp zu spät.

Am einfachsten geht es so:

Wenn du das x-Register vom Akku abziehen willst, dann geht das nur mit Zwischenspeicher:

Ich habe noch zwei Fragen:

1) Kann man davon ausgehen, dass die Register (A,X,Y) auf 0 initialisiert sind?

2) Kann man davon ausgehen, dass bestimmte ZP-Adressen gesetzt sind? Ich denke da so an $39/$3a mit der aktuellen Zeilennummer oder $2d/$2e, die direkt hinter das Programm zeigen sollen.

Quote from peiselulli

- Die Abfrage mit dem Index 0 wird nicht mehr benötigt, falls der Fall einmal aufgetreten ist. Dann wird die Abfrage gelöscht.

Ahh, verdammt. Ich glaube, der Punkt wäre es gewesen. Ich hätte die Abfrage, nach dem der Index 0 gefunden wurde, einfach löschen sollen, dann hätte ich mehr Platz zum Schleifenentrollen gehabt. Damit hätte sich mein Code entscheidend verschnellert.

Aber was solls. Eigentlich wollte ich gar nicht mitmachen. Dann habe ich gesehen, dass meine erste Lösung so etwa 20000 Zyklen gebraucht hat und ich damit gut im Rennen lag. Peiselulli hat zuerst, glaube ich, 25000 Zyklen angekündigt. Danke dafür. Auch für die 13500 Zyklen-Ansge.

Auf die kurze Version bin ich nicht gekommen, deshalb an die Gewinner.

Die Tabelle bucket liegt bei ce00. Es wird also ein and "#cf" gemacht. Das bedeutet, dass das and egal ist bei folgenden Werten: $00-$0f, $40-$4f, $80-$8f, $c0-$cf. Das sind zusammen 64 Werte.

Das "beq *-4" oder "beq *+5" ist natürlich nicht mehr lesbar, aber ich brauche mich dann beim Schleifen-Entrollen nicht mehr darum zu kümmern. Ich habe das vergessen wieder auszubauen, als ich das Listing hier gepastet habe.

Das war sauknapp am Ende, aber ich hab's versucht.

Glückwunsch peiselulli

Meine eingereichte Version ist nicht mehr lesbar. Deshalb zeige ich hier zwei Programmversionen, die vielleicht nützlich sind.

Version1, kurz und einigermaßen schnell, einer Bucketsort:
Identical: 17607 cycles
Random Data: 18939 cycles (average of 100 runs)
Fixed Data: 18936 cycles (with duplicates)
Fixed Data: 19218 cycles (no duplicates)
Ascending: 19218 cycles
Descending: 19218 cycles

67 Byte

Hier ist eine Version, die das Prinzip meines eingereichten Beitrags deutlich macht:

Descending: 14877 cycles
Fixed Data: 15091 cycles (no duplicates)
Identical: 15127 cycles
Ascending: 15387 cycles
Random Data: 15407 cycles (average of 100 runs)
Fixed Data: 15442 cycles (with duplicates)

Jetzt muss man nur noch die Schleifen entrollen. Ich habe auch noch 64 mal den tya; sta bucket,x durch shy bucket,x ersetzt und 128 Zyklen gespart:

Ich habe es das ganze Wochenende probiert aber wahrscheinlich doch nicht geschafft, den Rekord von peiselulli zu knacken.

Mit normalen Mitteln lande ich bei der zufälligen Sortierung bei 13.7xx .
Ich habe jetzt eine Version eingereicht, die irgendwo im Bereich 13xxx liegt. Manchmal ist sie schneller und manchmal langsamer als die vorgegeben 13.500 Zyklen. Ich frage mich, was für ein Zufallszahlengenerator bei dem Testprogramm auf der Webseite verwendet wird. Nach 100 Durchläufen liegt der Durchschnitt mehrere Hundert Zylen auseinander.

Mein Programm verwendet einen reinen Bucketsort mit verketteten Listen. Das heißt, ich muss mühsam den Nullzeiger vom Element mit der Position 0 unterscheiden. Das könnte bei einem Countingsort vielleicht einfacher sein. Ich bin schon gespannt auf die anderen Programme.

Bei dreckiger Programmierung fällt mir noch etwas ein. Ich hätte beinahe den Befehl LAS bucket,y zusammen mit tsx, txs und pla, pha verwendet. Wäre das eigentlich erlaubt gewesen? Wie auch immer. Das hat es dann leider doch nicht gebracht. Schade, ich habe den Befehl LAS (opcode $BB) noch nie irgendwo sinnvoll in Verwendung gesehen.

Quote from peiselulli

Um Mafiosino zu motivieren (und damit ich nicht den nächsten Wettbewerb austragen muss )

Danke peiselulli, jetzt bin ich tatsächlich motiviert

Ich frage mich nur, wie ich noch 1000 cycles wegoptimieren soll? Aber ich habe ja noch Zeit.

Ich gebe noch nicht auf, ich kann es noch schaffen zweiter zu werden (hinter Roland).

Ich hatte eigentlich schon abgegeben. Aber nach der Liste von Acorn muss ich noch mal ran, da seine Werte knapp besser als meine sind.

Danke Acorn. Ich hätte sonst nichts mehr gemacht.

Aber jetzt wird es wirklich schon sehr dreckig. Ich denke auch schon über illegal codes nach.

Villeicht motiviere ich noch jemanden mit meinen aktuellen Zahlen.

Ich habe nach den letzten Beiträgen doch noch zwei Fragen.

1.) Ich benutze eine Tabelle mit 256 Einträgen, die mit 0 initialisiert werden müssen. In den Regeln steht, dass das Programm 4 mal aufgerufen wird und dabei stabil laufen soll. Danach wird das Programm 100 mal neu geladen und mit anderen Werten 4 mal neu gestartet. Im Augenblick lösche ich die Tabelle mit einer unrolled loop und brauche daher ungefähr 4*256=1024 cycles. Ich könnte mir 1000 cycles sparen, wenn ich mein Programm um 4*256 0 Bytes erweitere, und bei jedem Start die Zeiger auf die Tabelle 256 Bytes verschiebe. Ist so etwas erlaubt?

2.) Ich finde, das Programm ist schwer zu testen. Die Anzahl der Zyklen kann ich mit dem Programm von peiselulli und auf der Webseite von ALeX checken. Kann ich davon ausgehen, dass die Webpage einen Fehler augibt, falls die Daten nicht korrekt sortiert sind?

Mein Programm braucht im Augenblick 16816 Zyklen bei den sortierten Listen und 16631 bei zufälligen Listen. Ich bin mir aber nicht sicher, ob es immer korrekt läuft.

Ich habe das Programm jetzt auf meinem Blech C128D getestet. Außer einem 20 read error 18 0 gleich am Anfang, weil die Diskette noch nie formatiert war, gab es keine Fehlermeldungen.

1ST1:
Also dies Kommando

dd if=/dev/sda of=/dev/sdb

Copy the contents from the if= drive /dev/sda to the of= drive /dev/sdb.

müsste schon reichen. Bei mir heißen die Harddisks wirklich so wie im Beispiel. Das wird sicher Stunden dauern, also werd ich das über Nacht laufen lassen.

Ich habe die große Platte über USB angeschlossen, falls das einen Unterschied macht.

Ich verstehe noch nicht, was Größenanpassung heißt. Hat das irgendetwas mit der Sektorgröße zu tun, ober meinst du, dass ich meine C:\-Partition vergrößere?

guidol
Ich habe die neueste stable Live-CD von GParted gebrannt, die Debian-Version. Macht es einen Unterschied, ob ich die Ubuntu-Version nehme? CloneZilla bricht ab und sagt, dass auf der Zielplatte nicht genug Platz vorhanden ist. Liegt es an meinem Rechner: HP Elitebook 8530p?

Ich will bei meinem Notebook die Festplatte, Hitachi HTS545025B9A300, 250 GB, auf eine neue kopieren und die alte Festplatte damit ersetzen. Die neue Festplatte ist eine Samsung/Seagate ST1000LM024 1TB. Ich habe Ubuntu und Windows 7 auf dem Rechner.

Ich habe schon einige Programme zum Klonen ausprobiert, aber bis jetzt keinen Erfolg gehabt. Viele Programme melden, sie hätten Probleme mit der Sektorgröße. Es soll von 512 Bytes pro Sektor auf 4096 Bytes pro Sektor kopiert werden.

Wie kopiert man die eine Festplatte auf die andere? Ich habe schon Acronis True Image 2010, den Seagate DiscWizard, CloneZilla und einige andere Demoversionen von Klonprorgrammen aus dem Internet ausprobiert und keinen Erfolg gehabt.

Vielleicht hat noch jemand Vorschläge? Kann man Partitionstabelle von Hand erstellen und dann mit irgendwelchen Linuxkommandos die Sektoren kopieren?

So, ich habe den Fastloader jetzt angepasst. Das heißt konkret, dass $1c0b in der Floppy nicht mehr verändert wird.

Außerdem werden auf der Computerseite $dd01 und $dd03 auf #$ff gesetzt. Das bedeutet, dass die Datenleitungen des User-Ports auf Ausgang geschaltet werden und auf logisch 1 gesetzt werden. Laut Sauhund kann dabei nicht viel kaputt gehen, außer die Ausgänge schalten noch irgendwelche anderen Sachen, die am Userport hängen.

Ich habe das Programm auf einem echten C128db und im vice mit x64 getestet. Ich hoffe das Programm funktioniert jetzt auch auf alten Floppys. Ich kann das leider nicht selber testen.

Ich habe keine Ultimate, deshalb kann ich den Loader nicht anpassen. Ich will aber versuchen, den Loader auf die ganz alten Floppys anzupassen. Das geht aber nicht auf die Schnelle. Dazu müssen in den Floppy-Routinen 4 Zyklen für einen Zugriff auf $1c01 gespart werden. Da muss ich mir noch was überlegen.

Ich habe auf csdb noch einen Hinweis von Krill gefunden:

Quote

This is kinda broken. The code relies on $dd01 being set to $ff, but this is never done, so it crashes.

After loading the loader, enter POKE 56577,255: POKE 56579,255, then run, then load the desired program.

Also gartenzwerg, probier mal print peek(56577) aus. Wenn da nicht 255 herauskommt, dann tipp die beiden pokes von oben nach dem Laden des Fastloaders ein.

Der Fastloader benutzt meines Wissens nach keine illegalen Codes auf der Computerseite. Könntest du sonst nochmal überprüfen, ob der Computer ein geändertes Betriebssystem installiert hat? Vielleicht haben sich im ROM Einsprungadressen geändert oder ich überschreibe irgendwelche wichtigen Parameter.

Das andere Problem, das von alexi gemeldet wurde, scheint dagegen klar zu sein. Ich habe extra die Latchkontrolle von Port A in $1c0b abgeschaltet, damit ich ich mir einen Zugriff auf $1c01 sparen kann. Ich lese von 5 Bytes eigentlich nur 4. Aber jetzt wird mir langsam klar, warum das in der Floppy so umständlich mit einem Zwischenspeicher von Port A gelöst ist: Weil es in den allerersten Geräten nicht anders ging. Es ist leider nicht so einfach möglich, die Routinen so einfach umzuschreiben, aber vielleicht fällt mir nochwas ein.