Posts by Prodatron


    Schlechte Idee. Das Netzteil des CPC ist sowieso schon recht schwach. Besser 5V aus dem Symbiface rausholen (aber dann wirklich nur die CF-Karte damit versorgen) oder (noch besser) ein kombiniertes 5V/12V-Netzteil nehmen.


    Leider haben die neueren Versionen den zweiten Strom-Ausgang nicht mehr aufgelötet, weil es in der Vergangenheit zu oft zur Verwechslung mit dem Strom-Eingang gekommen ist (und somit zur Zerstörung des SF2). Den 5V-Ausgang müßte man sich dann selber aufs SF2 löten.


    CU,
    Prodatron

    Zuersteinmal: Ja, es funktioniert!! :juchee: :juchee:


    Es gab eine ganze Reihe an Problemen, die uns das Leben am Samstag schwer gemacht haben:
    - Netzteil war zu schwach
    - irgendwas war mit der Gehäusekabelkonstruktion komisch
    - Stefans CPC hat eine Macke, die auch bei Spielen zum Absturtz führten


    Heute wurde das SF2 dann ganz normal angeschlossen an einem funktionierenden CPC + stärkeres Netzteil + CF-Cardreader, und alles fluppte wunderbar! Der CPC spielte dann fröhlich Videos und dödelte gleichzeitig PT3-Sounds.


    Ich werd's gleich heute später am Abend oder morgen früh nochmal an meinem ausprobieren. Wenn da auch alles klappt, dann würde ich die neue Runde für eröffnet erklären.


    @Sloopy:
    - Das Netzteil könnte mit seinen 0,6A zu schwach sein. Nach unseren Erfahrungen am Samstag würde ich da lieber auf Nummer sicher gehen und ein stärkeres suchen. Wenn ich mich richtig erinnere, hat das jetzige vom Stefan 2A. Das SF2 selbst benötigt ja schon 0,5A, wenn dann noch ein CF-Adapter und eine Maus hinzukommt, könnten die 0,6A schon nicht mehr ausreichen.
    - Bisher ist mir nicht bekannt, das ein CF-Adapter nicht funktioniert. Ich schätze mal, daß Deiner auch laufen wird.


    CU,
    Prodatron


    *EDIT* Sorry, hatte das mit der Stromversorgung gar nicht gesehen. Ich kenne bisher nur Adapter, die auch einen Stromanschluß besitzen und benötigen. Vielleicht kann da jemand was genaueres sagen, warum die einen einen Stromanschluß haben und die anderen nicht? *EDIT*

    Wenn das Laufwerk "seine eigenen" Disketten lesen/formatieren/schreiben kann, dann hört es sich so an, als wäre die Track-Position des Schreib-/Lesekopfes verstellt.
    Der Kopf bewegt sich dann zwischen den korrekten Trackpositionen. Das Problem gibt es wiederum beim CPC auch und tritt z.B. auch auf, wenn man an der Mechanik herumdocktert. Beim CPC verwende ich den Trick, daß, wenn der Kopf wild herumfährt, ich in dem Moment das Gerät ausschalte. Lustigerweise ist der Kopf dann beim nächsten Einschalten wieder richtig positioniert.
    Leider kann das beim HitBit-Laufwerk (hat das eigentlich Direktantrieb ohne Riemen? Der VG soll nämlich angeblich auch einen Riemen haben) natürlich völlig anders sein... :(


    CU,
    Prodatron

    Mit SD->CF-Adaptern hab ich noch keine Erfahrung.


    - SD-Karte: Serielle Ansteuerung, eigenes Protokoll
    - CF-Karte: Parallele Ansteuerung, IDE-Protokoll


    CF-Karten (Compact Flash) sind ja quasi kleine IDE-Laufwerke, hier ist nur ein recht einfacher Adapter nötig, in den dann ein IDE-Kabel reingesteckt wird.


    CU,
    Prodatron

    Gute Frage, das hätte ich auch gleich noch erwähnen sollen:


    Das SYMBiFACE II benötigt ein Netzteil, das 7-35Volt DC liefert (hat einen eigenen Spannungsregler onboard) und bis zu 500mA abkann.


    Ich würde irgendwas zwischen 9V und 12V empfehlen. Bisher hatte ich ein altes PC-AT-Netzteil verwendet und mir hier die 12V geschnappt. In Zukunft werde ich aber wohl ein normales kleines Schaltnetzteil nehmen, da hat man ja auf die Dauer genug von rumliegen.


    IDE-Festplatten und CF-Karten mit Adapter sollten fast alle laufen. SymbOS unterstützt keinen CHS-Mode mehr, "nur" noch den schnelleren LBA-Modus (Adressierung der Sektoren auf einer Festplatte). Es kann daher sein, das ganze alte IDE-Platten (aus den 90ern) nicht mit SymbOS laufen.


    Nach einem praktischen Gehäuse, wo am besten ALLES zusätzliche reinpaßt (SYMBiFACE II, Netzteil, externes 3,5" Drive und Festplatte/CF-Karte) such ich auch noch. Sowas wäre echt genial, dann müßte man neben CPC und Monitor nur noch diese Box mitschleppen, wo noch die Kabel für SF2 und Floppy raushängen. Hatte mir früher schonmal mehrere angeguckt, aber nie eines besorgt. Wäre jetzt auch mal an der Zeit...
    Das SF2 hat die Maße 16cm x 10cm (ist glaub ich so eine Euro-Standardgröße).


    CU,
    Prodatron

    Z80 und R800 Emulator für den Z80/R800 von Nyyrikki:
    http://www.msx.fi/nyyrikki/software.html
    (siehe "Z80/R800 emulator for Z80/R800" ganz unten)


    Mehr über den Pac-Man Emulator für den CPC (kein April Scherz) gibt es hier:
    http://www.cpcwiki.eu/forum/news-events/april-fool/


    Der CPC-Emulator für den Enterprise:
    http://www.ep128.hu/Ep_Games/L…trad_CPC_Program_Pack.htm
    (Übersicht aller lauffähigen Programme; der Enterprise kann den CPC-Screen 1:1 nachbilden; der Rest wird per Wrapping der Betriebssystem-Vektoren emuliert)


    CU,
    Prodatron

    Ist das ein fantastischer Vortrag!! Da kann man richtig neidisch werden, denn ich denk mal, für den Z80 hat das noch keiner gemacht...? Michael Steil ist einfach genial!

    Der Begriff "Offline" würde ich nichtunbedingtmit Computerspielen zusamenbringen - Offline klingt für mich immer nach "stromlos" - also Brettspiele, Fussball... so sachen sind für mich "offline"


    Also ich find den Begriff offline passend. Deine Unterscheidung wäre für mich eher "analog" und "digital". Fußball und Dein Pac-Man Brettspiel ist analog und das elektronische Original Pac-Man ist digital :)


    CU,
    Prodatron

    Coole Idee, das als Listings für die Load auszulegen!
    @TheArt: Beides gute Vorschläge, bei denen quasi nichts gerechnet werden muß, sondern andere Techniken zum Einsatz kommen müssen (Schleifen und Arrays bzw. Rekursion)!


    CU,
    Prodatron

    Die Benchmark-Liste am Anfang dieses Threads ist viel zu lang und speziell (laß mich raten: für Dein FutureOS ausgelegt ;) ), als daß jemals auf allen Systemen die Ergebnisse vollständig und vernünftig zusammenkommen würden.
    Fast kein 8bit-System kann von Haus aus 400kb große Dateien laden. Und warum überhaupt 400kb? Wie wär's mit 10MB oder 100MB? Das macht dann auch keinen Unterschied mehr, da es eh bei den meisten Ram-Konfigurationen gestreamt werden muß.
    Was genau bedeutet Laden und Speichern? Fragmentierte Datenträger oder nicht? Sequentielles oder Random Read/Write? Wie oft im Jahr löscht man am CPC 512 Dateien gleichzeitig (muß dann wohl eher realitätsfern heißen)? Was für Directories sind eigentlich gemeint und welche Informationen sollen ausgegeben werden?


    Ein für 8bit-Systeme ausgelegter Massenspeicher-Benchmark sollte schon etwas allgemeiner gehalten werden, damit man überhaupt die Chance bekommt, die Systeme zu vergleichen:
    - Formatierung: wieviele KB/s werden durchschnittlich formatiert?
    - wieviele KB/s werden im Durchschnitt gelesen, geschrieben?
    - Spezialfall: 30KB große Datei in einem Stück laden/speichern (mehr nicht, weil es sonst wieder mit den Problemen beim Vergleichen anfängt)
    Falls man noch mit professionelleren/moderneren Rechnern vergleichen will:
    - Sequentielles Read/Write, Random Read/Write über verschieden große Dateien


    Das war es auch schon. Mehr Fälle zu unterscheiden führt nur dazu, daß es am Ende sowieso nichts wird, weil keiner das alles zusammenträgt.


    Der Sinn des Druckerbenchmarks erschließt sich mir überhaupt nicht und die Textausgabe ist wieder viel zu speziell:
    - welcher Bildschirmmode?
    - dürfen die anderen dann ihren Textmode nutzen oder müssen alle im Bitmap-Mode arbeiten?
    - das mit den 524288 Zeichen hattest Du damals schon im Computer Flohmarkt Anfang der 90er als Benchmark für Dein FutureOS angepriesen :mrgreen: (mit der gefakten Textausgabe), aber ich denke z.B. 10.000 Zeichen reichen völlig aus ;)
    - Fudeln (immer das selbe Zeichen kopieren) gilt natürlich nicht


    Also allgemeine Massenspeicher-Read/Write-Benchmarks fänd ich interessant (bisher weiß ich z.B. nur, daß der C64 da sehr lahm ist, der CPC sehr schnell, aber was ist mit Diskettenzugriff beim Spektrum, Atari 8bit usw.?). Bei der Textausgabe würde man halt nur Äpfel mit Birnen vergleichen.


    Ich fänds auch viel witziger, wenn man die Ausführungszeiten verschiedener Programme in zwei Disziplinen vergleichen würde:
    - mit den Standard Basic-Interpretern der jeweiligen Systeme
    - auf jedem System jeweils hardcore-optimiert (dann natürlich in Assembler)
    Ein Apfelmännchenprogramm, das z.B. eine 100x100 Pixel große Grafik plottet, hielte ich tatsächlich für sehr geeignet, man könnte dann noch weitere Beispiele nehmen, bei denen nicht so extemst gerechnet werden muß.


    CU,
    Prodatron

    Die arithmetischen Befehle funktionieren alle nur mit dem Akku, weshalb er hier tatsächlich weggelassen werden kann. Das ist wohl, wie TFM sagte, aus 1.) Einspargründen und 2.) Kompatibilitätsgründen zum 8080 erfolgt.
    Recht hast Du bei den Bit-Shift- und Rotate-Befehlen. Hier gibt es quasi alles für alle Register, aber bei denen, die den Akku betreffen, fehlt quasi das Leerzeichen zum Parameter (blöd ausgedrückt). Da ist es allerdings auch so, daß die Befehle für die anderen Register länger und langsamer sind.

    Vielleicht ist der Z80 so gesehen sogar ein Schritt weg von der "reinen Lehre" der maschinennahen Programmierung?


    Ich würd einfach sagen, Z80-Assembler versucht die maschinencode-nahen Mnemonics ala 8080/6502 mit allgemeineren parametrisierten zu ersetzen, achtet aber noch halbwegs darauf, daß man beim Programmieren noch daran erinnert wird, daß es hier teilweise im Ergebnis Unterschiede gibt. Denn bei allen Befehlen läßt sich trotzdem noch recht gut erkennen, wieviele Bytes sie z.B. benötigen (zb: RLA und RL H, statt RL A und RL H).
    Bei den x86ern ist das viel heftiger. Da geht's tatsächlich viel stärker weg vom maschinennahen Programmieren (im Vergleich zum Z80 - es ist viel komplexer durchzublicken, was der Assembler am Ende aus dem Code macht).


    CU,
    Prodatron

    Ganz genau. Die Assembler-Sprache der Z80-CPU ist die erste, die ich kenne, bei der man nicht mehr auf die Art des Befehls und der Quellen/Ziele achten muß, sondern mit allgemeinen Parameter- und Befehls-Schreibweisen arbeiten kann, auch wenn am Ende ganz andere Befehle codiert werden. Das unterscheidet sie vom 6502 und 8080 und macht sie einfacher erlernbar, was ich als großen Vorteil sehe. Ein Techniker mag vielleicht anmeckern, daß es ja tatsächlich ganz verschiedene Befehle/Operationen sind, die nicht alle gleich geschrieben werden dürften (z.B. mit LD), aber schließlich soll mir ja ein Assembler die Codier-Arbeit abnehmen, anstelle, daß ich sie quasi schon im Vorfeld durch unterschiedliche Schreibweisen leisten muß. Das scheint Faggin wohl als erster richtig erkannt zu haben (oder gab's zu der Zeit schon andere?).


    CU,
    Prodatron

    Sehr lustige Diskussion, auch wenn sie herzlich wenig bringt! :D
    Ob Load/LD (Z80) oder Move/MOV (x86) war mir immer relativ egal. Hauptsache man kann die selbe Befehlsschreibweise für alle Richtungen verwenden. Es werden nunmal immer Bytes und Words hin- und hergeschaufelt, ob jetzt von Speicher zum Prozessor oder andersrum, das weiß der Assembler nunmal selbst und kann es dann entsprechend übersetzen. Was ich echt blöd finde, ist, wenn zwischen Load und Store unterschieden wird oder der Befehlsname selbst schon das Register enthält, anstatt daß dieses als Parameter angehängt wird. Letzteres sorgt für eine durchgängig sauberere einheitliche Schreibweise und ein schnelleres Erlernen. Da hat Faggin im Vergleich zum 8080- und 6502-Assembler super Arbeit geleistet.
    Klar ist z.B. intern LD (DE),A ein völlig anderer Befehl als LD (HL),A, aber für den Programmierer ist es viel einfacher und sauberer, wenn er hier die jeweils gleiche Schreibweise mit üblichen verständlichen Parametern verwenden kann.


    CU,
    Prodatron

    Nach 3 Tagen mein erster Eindruck:
    - Dienstag: Aufbauen war lustig! :) (auch wenn es viel länger gedauert hat als gedacht)
    - Mittwoch war der erste Messetag, nur für Aussteller, Presse und sogenannte "Fachbesucher". Ich fand's teilweise total nervig obwohl im Vergleich zu Donnerstag noch kaum was los war (was nichts heißt bzw. relativ ist, wie Andreas schon geschrieben hatte). Vielleicht brauchte man den Tag zum Eingewöhnen, aber irgendwie liefen da auch ziemlich viele komische Leute rum (von wegen "Fachbesucher" - ha - ha - ha :cursing: ).
    - Donnerstag: Erster Messetag für alle. Um Punkt 10 Uhr wurden die Hallen regelrecht überschwemmt. Aber der heutige Tag war verdammt cool! Trotz des riesigen Andrangs empfand ich die Leute (von kleinen Kindern, sehr vielen Jugendlichen, Schülern usw. bis zu älteren Semestern) viel disziplinierter als am Tag zuvor! Das war heute schon der Wahnsinn! Alle Bereiche von unseren Retro-Ständen waren dauerbesucht, teilweise völlig überrannt. Auch wenn viele nicht mehr wissen, wie man einen Joystick hält, so haben doch alle fleissig an unseren alten Kisten gedaddelt. Die Leuten standen regelrecht Schlange, um Kangas analoges Pac-Man spielen zu können! KITT wurde in Schüben immer wieder komplett umdrängt und zigtausendfach fotografiert, aber im Gegensatz zu gestern wurden diesmal trotzdem nicht die Absperrbänder umgeschmissen.
    Auch wenn es schon echt anstrengend ist, so hat es heute richtig Spaß gemacht, mit allen unseren Retro-Computing-Kollegen der anderen Organisationen/Vereine diesen Stand zu betreiben! Ich bin echt froh, wieder in der Szene zu sein und freu mich auf die nächsten 3 Tage :)


    CU,
    Prodatron