Umbringen hingegen würde ich am liebsten diejenigen die die paar cent für einen Sockel gespart haben und den DS1287 direkt eingelötet haben. Da könnte ich...
Stimmt, ein Sockel wäre da eine gute Lösung gewesen. Aber auch nur solange die Chips im Handel erhältlich sind. Zumindest kann man sie dann aber fürs Fräsen herausnehmen. Es ist schon sehr unangenehm, wenn man das Teil direkt auf der Platine bearbeiten muss. Ein Patzer und man durchtrennt ein paar Leitungen. 
Auffräsen und mit externer Knopfzelle versehen ist die einzig wahre Methode. Dieser "Chip" ist ja mindestens so dämlich wie die Batterie direkt auf die Platine löten (sieht man bei Euro PC, Euro PC II, Amiga 2000, etc. - von denen sind viele nur deswegen unbrauchbar).
Ich wäre dafür, die Firmen, die sich so etwas erlaubt haben, mit hohen Strafen zu belegen und für die Entsorgung der Boards zu sorgen. Alles das um ein paar Cents einzusparen ...
Wenn ich das Geld jetzt dafür hätte, würde ich zuschlagen.
Probier's mal mit:
Z84C0008PEG
oder
Z84C0010PEG
Evtl. lässt du PEG weg und hängst 'ne Wildcard an (*). Das sind die "neuen" Bezeichnungen. Die kann man mit jeweils maximal 8MHz und 10MHz takten. Ich weiß allerdings nicht, ob sie als Ersatz für einen U880 in Frage kommen - denke aber schon.
Und so manche 16-bit ISA-Karte funktioniert auch mit einem 8-bit ISA-Slot.
Hier mal eine Zusammenfassung der "erweiterten" Fähigkeiten des CRTCs:
Wow! Sehr gute Zusammenfassung. Danke schön!
Prodatron hat ganz recht. Die Anzahl der Nachkommastellen binär und dezimal kann unterschiedlich ausfallen.
0,1111011 binär ergibt z.B. 0,48046875 dezimal.
Andererseits spielt da auch die Rundung mit. Zahlen mit dezimal 9 Nachkommastellen sind häufig gerundet, denn ab 9 Stellen rundet BASIC. Eine Zahl mit 8 dezimalen Nachkommastellen ist aber nicht gerundet und entspricht daher der internen binären Darstellung gut.
Wobei da der Teufel auch im Detail liegt. Einerseits rechnest du mit PI und SIN-Werten, die (fast alle) irrational sind. Die lassen sich in keinem Zahlensystem perfekt darstellen.
Dann aber addierst du diese imperfekte Darstellung laufend, der Fehler pflanzt sich von den sehr niedrigen Stellen immer weiter zu höheren Stellen hinauf fort und wird schließlich bemerkbar. Das ergibt gelegentlich wahrscheinlich eine Rundung, die nur acht Stellen umfasst. Im nächsten Schritt wird dann aber bei derselben Zahl wieder eine irrationale Zahl draufaddiert, die wieder zu mehr als acht Stellen im Dezimalsystem führt und gerundet werden muss.
Das Ganze ergibt ein komplexes Zusammenspiel zwischen der ungenauen Zahlenrepräsentation in Computern, der eigentlichen Rechentiefe des Zahlenformats, der Rundung dieses internen Zahlenformats und der Umwandlung vom binären ins dezimale System (und umgekehrt).
Um für konkrete Beispiele eindeutige Gewissheit zu haben, was genau passiert, muss man wohl die Fließkomma-Algorithmen im Basic komplett verstanden haben, und dann Schritt für Schritt nachbilden können.
Das einzige, was Computer halt richtig gut können, ist ganze Zahlen zu addieren und zu subtrahieren. Den Rest macht er eher mau, aber halt sehr schnell. Und die Bits richtig zu interpretieren ist Sache der Algorithmen und Menschen, die diese erdenken.
Ist euch eigentlich auch aufgefallen, daß die Schleife nicht mehr mit dem Endwert durchlaufen wird ?
Der letzte ausgegebene Wert ist 9.90000001. Ein Durchlauf mit 10 findet nicht statt.
Stimmt. Der letzte Schleifendurchlauf kommt nicht mehr zur Ausführung, weil durch das Aufaddieren von 0,1 noch irgendwo ein paar Bits gesetzt sind. Beim Vergleich von der 10 aus der Schleife mit der 10 als Konstante stellt sich heraus, dass der Schleifenwert schon um einen ganz geringen Betrag größer ist als die Konstante 10.
Ich habe das mal mit FOR I=1 TO 10.1 STEP 0.1 geprüft:
Zahl: 10
Hexadezimal: 20 00 00 02 - Exponent: 84
Binär: 00100000 00000000 00000000 00000010 - Exponent: 10000100
Mit dem Taschenrechner ausgerechnet ergibt das den Wert: 10,000000007450580596923828125
Der Wert ist größer aus eine gerade 10. Die Prüfung, ob "10 = 10" ist schlägt deswegen fehl und der letzte Schritt wird nicht mehr ausgeführt. Deswegen soll man Fließkommawerte immer mit > oder < prüfen.
Noch zwei Schönheitsfehler sind im Programm:
40 PRINT "Zahl: ";i!
Das Rufzeichen deklariert die Variable als Fließkommazahl im Locomotive BASIC.
Und in Zeile 130 soll vor 2^32 natürlich ein Divisionszeichen stehen / .
Im BASIC vom CPC kann man sich die interne Darstellung recht anschaulich zeigen lassen, weil die Speicheradressen der Variablen mit dem Klammeraffen vor dem Variablennamen ermittelt werden können:
10 MODE 2
20 FOR i!=1 TO 10 STEP 0.1
30 a%=@i!
40 PRINT "Zahl: ";i
50 mant1%=PEEK(a%):mant2%=PEEK(a%+1)
60 mant3%=PEEK(a%+2):mant4%=PEEK(a%+3)
70 expo%=PEEK(a%+4)
80 PRINT:PRINT "Hexadezimale Darstellung:"
90 PRINT HEX$(mant4%,2);" ";HEX$(mant3%,2);" ";HEX$(mant2%,2);" ";HEX$(mant1%,2);" - Exponent: ";HEX$(expo%,2)
100 PRINT:PRINT "Binaere Darstellung:"
110 PRINT BIN$(mant4%,8);" ";BIN$(mant3%,8);" ";BIN$(mant2%,8);" ";BIN$(mant1%,8);" - Exponent: ";BIN$(expo%,8)
120 PRINT:PRINT "Formel fuer den Taschenrechner:"
130 PRINT "(0x";HEX$(mant4% OR &80,2);HEX$(mant3%,2);HEX$(mant2%,2);HEX$(mant1%,2);" * 2^32) * 2^";expo%-128
140 WHILE INKEY$="":WEND:CLS
150 NEXT i!Zwei Punkte dazu noch:
1) Das höchstwertige Bit in der Mantisse ist das Vorzeichenbit (0=positiv, 1=negativ). Um davon auf die richtige Darstellung der Mantisse zu kommen, ersetzt man dieses Bit immer mit einer 1. Die wird bei Fließkommazahlen eingespart und setzt dort das Vorzeichenbit, weil die erste Nachkommastelle bei der Mantisse IMMER eine 1 ist. (Manche Fließkommaformate dürften das nicht berücksichtigen, ich bin so einem noch nicht begegnet.)
Die binäre und hexadezimale Darstellung stellen also ein genaues Abbild der Zahl im Speicher dar, in der Formel für den Taschenrechner ist dieses Bit aber schon berücksichtigt.
2) Die Größe der Mantisse lässt sich im CPC nicht mehr wirklich korrekt darstellen. Deswegen habe ich mich entschieden in der Taschenrechner-Zeile die Mantisse hexadezimal anzugeben. Ihr braucht also fürs Errechnen des korrekt(er)en Ergebnisses mit dem Taschenrechner einen solchen, der Hexadezimalzahlen darstellen kann. Der Windows-Taschenrechner kann das (XP und 7 getestet).
Viel Spaß mit dem Testen!
PS: Probiert mal FOR i!=-10 TO -1 STEP 0.1
PPS: Es würde mich freuen, wenn jemand für andere BASIC-Dialekte ähnliche Programme schreiben könnte.
MaV
... da würde mich doch glatt interessieren, wie genau die unterschiedlichen BASIC-Dialekte im Vergleich sind. Auf meinem Apple //c sieht das Ergebnis wieder ein bisschen anders aus (siehe Bild).
MaV Welches BASIC ist denn vergleichsweise genau? BBC Basic vielleicht?
Und wie sieht es eigentlich in anderen Programmiersprachen aus. Ich werde das Programm am WE mal in Turbo Pascal und Apple Pascal eingeben und die Ergebnisse vergleichen.
Hm, gute Frage. Ich habe mit anderen BASIC-Dialekten kaum Erfahrung.
Eine kurze Recherche zu Apple führte mich zu dieser Seite:
http://www.txbobsc.com/scsc/scdocumentor/
Dort habe ich mich auf die Suche nach konstanten Fließkommawerten gemacht. Speziell PI ist interessant, weil es ja überall vorhanden sein muss. In S.EFEA kann ich
CON.PI.HALF .HS 81490FDAA2
und
CON.PI.DOUB .HS 83490FDAA2
finden.
Demnach würde PI die Bytefolge 82490FDAA2 haben. 82h ist der Exponent, der Rest Mantisse. Das fand ich insofern lustig, weil im CPC die Zahl haargenau so dargestellt wird, nur sind die 5 Bytes umgedreht: A2 DA 0F 49 82.
Also entspricht die interne Darstellung der Fließkommazahlen im Apple BASIC (von obigem Link) genau der vom CPC.
Wenn die Ergebnisse sich also unterscheiden, dann weil die Algorithmen dazu anders berechnen. Möglicherweise wird aber nur anders gerundet.
Von Turbo Pascal habe ich gelesen, dass das REAL-Format mit 6 Bytes rechnet, also wohl etwas genauer also der CPC und der Apple II. Bei anderen BASIC-Dialekten bräuchten wir die genaue interne Repräsentation, um Aussagen treffen zu können.
@
@Pentagon: Danke! 
Mal aus der CPC-Sicht, weil ich da zufälligerweise das Format inzwischen kenne. Aber auch grundsätzlich zur Zahlendarstellung:
0,1 lässt sich binär nur sehr schlecht darstellen, ebenso 0,2.
Die Mantisse im CPC ist vier Bytes lang, und die Umrechnung von 0,1 ergibt (,=wie gehabt im Deutschen .=Trennzeichen zur besseren Darstellung):
0,1100.1100.1100.1100.1100.1100.1100.1101
Ja, 0,1 binär ist periodisch (!). Und die letzte Stelle ist auch noch gerundet.
Der Exponent - also das 5. Byte im CPC - ist 125. Von dieser Zahl muss 128 abgezogen werden, ergibt -3)
(Mantisse als Ganzzahl) dividiert durch 2^(Anzahl der Bits in der Mantisse) * 2^(Exponent - 128):
(3435973837 / 2^32) * 2^(125-128)
Das ergibt also für die diese Zahl alleine schon einen recht hohen Fehlerfaktor. Rückgerechnet ins Dezimalsystem ist das:
0,10000000000582076609134674072266
In der Schleife wird jetzt 100 mal auf 1 die Zahl 0,1 addiert, aber eben das fehlerhaft dargestellte 0,1. Das führt irgendwann zu einem Rundungsfehler, der nicht mehr ignoriert werden kann.
WANN der Fehler auftritt hängt von der internen Genauigkeit der Fließkommazahlen ab, und davon wie gerundet wird.
Beim CPC hast du ungefähr eine Genauigkeit von 9 Dezimalstellen nach dem Komma (mal besser, mal schlechter). Andere BASICs liegen da vielleicht in etwa gleich.
Die Formatierung von Octoate zwingt BASIC anscheinend dazu, bei den Zwischenschritten jedes Mal zu runden. Was dann dazu führt, dass die Abweichung in der internen Darstellung von 0,1 nicht kumuliert.
Ein Step von 0.25 zum Beispiel muss problemlos durchlaufen, weil da auch das interne binäre Format eindeutig bleibt. Und wenn nicht, dann geh ich jede Wette ein, dass dieses BASIC dann einen Bug hat.
Na, so ganz würde ich das jetzt auch nicht unterschreiben. Midline Process oder Bloc Us waren ja auch Trakmo's, aber bei Batman Forever stimmt halt das Design.
Autsch! Midline Process zu vergessen ist unverzeihlich!
Bei Bloc Us muss ich zugeben habe ich das Detail übersehen, wobei ich mir die Frage stelle, wieso sie diesen Code nicht auch gleich bei Wake Up! eingesetzt haben.Die Screens haben nämlich überwiegend leer ausgesehen, und ein paar passende Grafiken dazugeladen hätte gleich mehr Eindruck gemacht.
Es gibt einiges zu sehen, das meiste sind allerdings Tech-Demos. Batman Forever ist und bleibt im Moment das einzige Trackmo.
Also ich würde sagen, für Werke der nahen Vergangenheit schaut mal nach bei:
Vanity
http://www.pouet.net/groups.php?which=10743
NoRecess
http://www.norecess.net/productions.html
und
Les Sucres en Morceaux
http://sylvestre.cpcscene.com/
(da wird viel mit Farben gespielt - auch mit dem Grünmonitor erlebt man Wunder)
Natürlich darf Odiesoft nicht fehlen:
http://www.odiesoft.de/amstrad/demos.html
Er macht halt leider nichts mehr, also schaut das alles Old-School aus.
MaV
Alles Gute auch von mir!!
Was bitte ist Gal und Pal?
Habsch noch nie gehört... Ist mir da was entgangen?
Autsch, das hat weh getan! Wie funktioniert denn das Bank-Switching auf dem CPC 6128? Der hat so nen Chip drin dafür.
Is'h wusste garned, dass man midm iMac koche kann?
Sie kann schon kochen, aber vor allem auch hart zuschlagen, wenn du's am wenigsten erwartest. Deiner Gesundheit zuliebe zeige ich ihr den Thread erst gar nicht. 
Ja, NetBeans für Mac gibt es.
Nein, ich kann da nicht mehr helfen. Mein MacBook hat jetzt mein Neffe, und der iMac gehört meiner Frau.
MaV
Huch, hier fehlt ja noch der Link zur Onlineversion der CPC Bibel: "Das Schneider CPC Systembuch".
Also, du hast nur mein Posting von der ersten Seite übersehen, aber das passt schon. Man kann das Systembuch eh nicht oft genug empfehlen. 
Zwei passende Links noch:
http://www.cpc-power.com/cpcdemos/
http://cpcrulez.fr/
Ganz ehrlich jetzt meine Meinung:
Bis auf Batman Forever gibt es keine vergleichbare Demo auf dem CPC.
Den alten Demos merkt man das Alter leider deutlich an. D.h. wenn du auf den Stil der frühern 90er stehst, wirst du leicht fündig.
Die aktivsten sind die Franzosen. Die sind technisch brilliant, aber darüber hinaus wird es bei ihnen dünn. Ein durchgehendes Thema in einer Demo mit gelungenen Übergängen von einem Effekt zum anderen findet man da kaum. Batman Forever haben manche Scener in Frankreich nicht gut weggesteckt, und deswegen ist speziell von deren Seite viel Kritik gekommen.
Vergleichbares ist vielleicht von Norecess (phreaks und dgl.) und Hicks gekommen (Gruppe: Vanity, z.B. From Scratch)
Hicks hat ja versprochen, dass er kontern wird. Aber da muss man Geduld haben. So eine Demo wird nicht von heute auf morgen gemacht.
Ach, und für französische Demos solltest du einen CPC mit CRTC1 haben. Die im deutschen Raum häufige CRTC0 kann die Effekte meist nicht zeigen.
Wenn du einen Grün-Monitor hast, probier mal ClimaxG aus. Sehr schön. (Wenn's stimmt ist bei Les Sucres en Morceaux auch ein Deutscher dabei, Exin. Ich kann mich aber irren.)
Soso... also ist Sun / Oracle dafür verantwortlich, dass die _hauseigene_ Portierung von Apple defekt ist?
Ich hörte da immer das Gegenteil, dass sie sich eben vor allem anfänglich sehr bemüht haben, bei der Java-Portierung, aber vielleicht liegen mir nur Apple-Jünger in den Ohren.
In meiner Aussage bestätigt fühle ich mich durch die Linux-Portierung, da geht's nämlich auch nicht besonders. Wobei Linux und Sound so eine Sache sind.
Mir scheint ich sollte aber eher auf deine Erfahrung hören.
(Kanga bitte kurz wegschauen .... und Apple benutze ich persönlich auch nicht mehr. )
Ich muss da mal ne Lanze fürs OS X brechen. Die haben da keine schlechte Java-Anbindung. Letztlich hängt's von Oracle (oder einst Sun) ab, warum der Sound nicht richtig rüberkommt.
Ein i7 Quad Core ist für eine simple Emu eh schon kompletter Overkill. Da müsste so ein Ding schon ohne großes Schwitzen gehen. Das sollte auch auf einem Atom 1.6 GHz mit ~50Hz laufen. Mit WinApe geht's jedenfalls, und ich vermute dass der Atom-Prozessor nicht komplett beansprucht wird.
Grafik spielt da überhaupt keine Rolle, weil bei Emulation mit Framebuffern gearbeitet wird. Die GraKas der letzten 10 Jahre (oder mehr) unterscheiden sich da überhaupt nicht mehr, die kämpfen bei der 3D-Implementierung um Markanteil.
Ich kann's aber DevilMarkus auch ned nachsehen, wenn er das Soundproblem (oder was es letztlich ist, was ned passt) eben nicht fixen wird. Woher die Hardware und Betriebssysteme kriegen, bzw. wieviel Freizeit will man denn damit killen?
Ist aber letztlich nervig.
PS: Ich mag ja Java nicht besonders, mache aber auch keinen Hehl daraus.
Grüß euch!
Das sind schon mal viele bekannte Namen gefallen. Bei mir geht's eigentlich auch durch die Bank. Gute Musik kann man in jeder Richtung finden, aber meine Waage pendelt in letzter Zeit wieder viel mehr zu härterem und eher 70er und 80er(in zufälliger Reihenfolge):
AC/DC
Metallica
Rush
Black Sabbath
Led Zeppelin
Deep Purple
Iron Maiden
Megadeth
Def Leppard
Mountain
Cream
Credence Clearwater Revival
Jethro Tull
Wolfmother
Kraftwerk
Neu
Gary Numan
Mike Oldfield
Jean-Michel Jarre
Alan Parsons Project
Ultravox
Philip Glass
NiN
Devo
The Prodigy
Kruder & Dorfmeister
OMD
Depeche Mode
Eurythmics (erstes Album!)
David Bowie
The Smiths
Stone Roses
Canned Heat
Chemical Brothers
Ich hab da sicher noch einiges vergessen, was "unbedingt" hinein sollte.
So fällt mir gerade ein: "Dead Can Dance" für den Gothic Touch und als einst vor langer Zeit Weltschmerz empfunden werden soll.
Gut das beruhigt. 68er werden's in Zukunft auch bei mir sein.
Und einen Toast auf Nilquaders Cojones! Küchengummi!
!!!!!!!
Nach ca. 50 gewechselten Riemen, könnt ihr mir glauben!!
xesrjb
Sorry, xesrjb. Dein Post habe ich beim Runterscrollen anscheinend übersehen.
Das heißt dann aber auch, dass die 3"-Laufwerke genug tolerant sind für 68 mm Riemen. Oder hattest du schon mal Probleme mit dem Lesen von fremden 3"-Disketten?
Ich habe den Manager in der neuesten Version 2.5 auf der Karte drauf. Leider lässt sich da aber nur der "Floppy Motor" an- und abstellen...
Hm, kann sein, dass es in der CPC-Software dafür keine Option gibt. Das Windowsprogramm, mit dem man die Diskettenformate auf *.hfe konvertieren kann, erlaubt da mehr, unter anderem auch die Lautstärke einzustellen:
SDCard HxC Floppy Emulator
Ich wünschte mir, die HXCDSDFE.CFG wäre eine reine Properties-Textdatei. Dann könnte man das auch gleich mit einem reinen Texteditor vornehmen.
@Sloopie: Wenn dich das schon auf dem CPC nervt, stell dir vor, wie's dir dabei mit dem Amiga geht. *klack* *klack* *klack* *ratter* *klack*
Hat schonmal jemand die korrekte Bezeichnung für das Teil gepostet:
flacher Riemen 68,0 x 0,6 x 3,0 mm
Jep, du hast im ersten Posting von Kanga die Maße überlesen:
71mm x 2,8 mm x 0,6 mm
68 mm x 3,0 mm x 0,6 mm wird höchstwahrscheinlich auch gehen. Die Abweichung von 3 mm ist allerdings schon signifikant, da wirst du alte Disketten oder solche anderer CPCs nur mehr bedingt lesen können. Also ist es wohl besser 71 mm zu suchen.
MaV
Das wir als CPC-User leider nicht direkt brauchen können, sondern auf die nächste durch 4 teilbare Taktzahl erhöhen müssen. Aber ansonsten ist die Tabelle super. Liegt hier auch schon seit dem Mittwintermeeting 2010 auf meinem Schreibtisch.
Auf die nächste durch 4 teilbare Taktzahl zu erhöhen, ergibt in manchen Fällen auch wieder ein falsches Resultat.
Beispiel von arnoldemu:
out (c),r -> laut Zilog = 4, 4, 4 ... das wäre also eine runde 12 und man würde denken, dass es dabei bleibt.
Tatsächlich aber wird wegen der CRTC noch ein Taktzyklus eingeschoben, der dann dazu führt, dass dieser eine auf ganze 4 aufgebläht wird. Also: 4, 4, 4 wird zu 4, 4, 1, 4 wird zu 4, 4, 4, 4. Aus 12 ursprünglich Zyklen werden dann 16.
out (n),a lässt sich andererseits dann wieder über die Daumenregel "Aufrunden auf ein vielfaches von 4" errechnen:
Zilog: 4, 3, 4 wird zu 4, 4, 4 also 12 Taktzyklen.
Zurück zum Thema:
Ich greife gerne auf das Schneider CPC Systembuch zurück - http://k1.dyndns.org/Vintage/S…C%20Systembuch/index.html
Ich hätt's gerne als richtiges Buch bei mir liegen. *neidigaufOctoateschau*
Danke für die freundliche Begrüßung!
Hier ist nicht der Tellerrand, hier kann man übers Buffet schauen
Wobei ich je nach Zuckerspiegel, wahrscheinlich dann eher aufs Buffet denn darüber schaue.
Danke! Danke!
Ich find's eh ned schlecht, dass wir auch in einem Forum präsent sind, in dem auch andere Retro-User beheimatet sind. Über den Tellerrand schauen hat niemandem geschadet, und zusätzlich weiß man gleich, wo man nachschauen soll, wenn man schnelle Hilfe für andere 8-Bitter braucht.
