Datasettenspiel mit höchster Datenrate

Es gibt 33 Antworten in diesem Thema, welches 5.655 mal aufgerufen wurde. Der letzte Beitrag (5. März 2016 um 15:52) ist von Unseen.

  • ...Es gab also nicht nur einen Threshold, sondern drei, so dass es vier mögliche Längen gab, was zwei Bit pro Puls entspricht....damit die häufigste Bitkombination auch auf den kürzesten Puls gemapped wird - das braucht man bei der Datasette nicht.

    Hat mal jemand sowas programmiert?

    Ja, inklusive Mappen der 2Bit-Längen je Block, beschleunigt ungemein. Das ganze Bestand aus einem Java-Programm, dass ein .prg in ein .wav umgerechnet hat, dem Loader dazu, und als Adapter diente der "übliche", der einen Kanal mit FLAG1 verbindet.
    Wollte noch einen besseren Adapter für $01 und Stereo basteln, aber das überstieg schon meine Hardware-Kenntnisse.
    Allerlei Timing-Diagramme und die Programme müsste ich noch haben, machen meiner Meinung nach aber heute keinen Sinn mehr. Wozu noch ein Signal auf 44.100 Hz beschränken, wo es doch diese kleinen Micro-Controller gibt?

  • Statt Loop wäre es vermtulich besser, den Loader dann zu übertragen, wenn die Motor-Leitung angeht, damit man nicht auf den nächsten Loop-Anfang warten muss.

    Das beißt sich mit meiner Idee, die Motor-Leitung als "Umschalter" zwischen Kommando- und Datenmodus zu verwenden, denn sie wird von den normalen Tape-Routinen natürlich auch verwendet. Wahrscheinlich muss man sich etwas Ausgefeilteres überlegen, um vom "Browser-Loader"-Modus in den schnellen Übertragungsmodus zu kommen - vielleicht so etwas wie eine magic-sequence auf der write-Leitung.

    Wenn man es schafft, einen Loader zu schreiben, der auf jeglicher CBM Hardware läuft (spricht etwas dagegen?)

    Dagegen spricht, dass die externe Hardware "wissen" müsste, an welches Gerät sie angeschlossen ist. Man bräuchte also DIP-Schalter, Jumper oder eine Taster+LED-Kombination, die es erlauben, das jeweilige Zielgerät einzustellen. Das wäre aber wieder recht kompliziert in der Bedienung und schreit formlich nach einer komplett abgefahrenen Forschungsarbeit die da lautet: Wie erkenne ich automatisch, an welchem Datasettenport ich angeschlossen bin? Irgendwelche Unterschiede zwischen C64, VC20, PET und 264-Serie wird es sicher geben...

    Allerlei Timing-Diagramme und die Programme müsste ich noch haben, machen meiner Meinung nach aber heute keinen Sinn mehr. Wozu noch ein Signal auf 44.100 Hz beschränken, wo es doch diese kleinen Micro-Controller gibt?

    Richtig; heute ist ein Microcontroller und eine SD-Karte billiger als die Hardware die man bräuchte, um sich mit einem gängigen Smartphone zu verbinden (da bleibt oft nur Bluetooth). Und da wir hier ohnehin von einem Kopfschussprojekt reden, welches vor Feature-creeping nur so triefen wird, wenn man einmal angefangen hat (siehe die Idee "automatisches Erkennen der Host-Maschine), kann man auch nie genug Rechenleistung haben.

    Jetzt wo Raspi3 und die neue Odroid-Generation raus sind, liegen ganz sicher viele Raspi-Boards ungenutzt in der Ecke herum. Die bringen schon alles mit, was man für das Projekt bräuchte: GPIOs, reichlich Rechenleistung und einen SD-Kartenslot. Und viel Platz für feature-creeping! "The internet is my tapedrive", anyone?

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Da würde ich gar nicht so sehr auf Syncronisation achten, sondern ich würde den C64 zum "Master" machen, und die externe Hardware bitweise auf Clock-Pulse warten lassen. So würde der C64 mit seiner ganz eigenen Geschwindigkeit auf den Datasettenport zugreifen, man könnte Screen und IRQs an lassen um Fortschritt anzuzeigen und Lalla zu spielen, und hätte trotzdem eine annehmbare Datenrate.

    1-Bit-Datenübertragung mit vom C64 vorgegebenem Takt, nach IRQ-Loader-Art: Check.

    Zitat

    Die Motor-Leitung ist sehr langsam, würde maximal zum "Modus-Umschalten" ausreichen.

    Evtl. erinnerst du dich, dass ich Einspruch erhoben habe als dein C64R-Konzept noch einen Schaltregler mit Enable zur Steuerung der Motor-Leitung vorgesehen hat? Der wäre nämlich nochmal langsamer gewesen und meine Modusumschaltung hätte nicht funktioniert.

    Motor-Leitung zur Modusumschaltung: Check - allerdings anders als du es dir denkst.

    Zitat

    Wie wäre es mit:

    - Motor aus = Datenmodus, also Daten werden vom oder zum C64 übertragen
    - Motor an = Kommando-Modus, also Informationen über "welchen Block will ich denn lesen/schreiben" werden ins Gerät übertragen

    Nee... Wenn man sowas in zuverlässig bauen will, muss man bei einem C64-Reset auch auf jeden Fall zurück in den Datasetten-artigen "Stream-Modus" zurückkehren, damit der Benutzer sofort mit Shift+Run/Stop sofort wieder das Starterprogramm laden kann. Meine Lösung besteht darin, die Motor-Leitung zu überwachen - bei einem Reset geht der mindestens so lange an, wie der Reset-Taster gedrückt wird und glücklicherweise ist das EInschalten des Motors die "schnelle" Operation.

    Ein Timeout (keine wackelde Leitung in den letzten x ms) käme zur Reset-Erkennung IMHO nicht in Frage, der Programmierer auf C64-Seite sollte seine wertvolle CPU-Zeit nicht mit solchem Verwaltungskram verschwenden müssen.

    Zitat

    Der Einfachheit halber würde ich write und sense verwenden, weil die beide im Prozessorregister liegen, was mit flotten zeropage-Kommandos bearbeitet werden kann.

    Verwendete Datenleitungen: Check. Ausserdem haben die den Vorteil, dass man die ganze Zeit über den I/O-Bereich abgeschaltet lassen kann.

    Die Read-Leitung finde ich recht unattraktiv, weil sie nur steigende Flanken erkennt und im CIA-ICR landet.

    Zitat

    Die externe Hardware wird so gebaut, dass sowohl eine steigende Flanke, als auch eine fallende Flanke als "nächstes-Bit-Impuls" akzeptiert wird, was einen Schreibzugriff pro Bit spart.

    Könnte man machen, hatte ich aber aus irgendeinem Grund vermieden.

    Zitat

    Wenn man dann noch die Schleife für ein Byte abrollt, dürfte sich eine recht flotte Übertragungsroutine ergeben.

    Der 2-Bit-Transfer ist dennoch ein gutes Stück flotter, der Code oben kommt auf unter 50 Taktzyklen pro Byte.

    Zitat

    Die Hardware kann weiterhin ein simpler Microcontroller sein, der auch das "Loader-Programm" über die Read-Leitung in Dauerschleife "einspeist", solange er keine write-Impulse erkennt.

    CBM-Kernal-Format-Loader: Check

    Die Umschaltung ist allerdings noch ein wenig aufwendiger als nur auf Write ein wenig rumzupulsen: Die Motor-Leitung wird als Taktleitung verwendet und bei jeder steigenden Flanke der Zustand der Write-Leitung abgefragt. Wenn die so gelesenen letzten 16 Bits einem von zwei Werten entsprechen, wird entweder in den "Fastloader-Modus" gewechselt, der einen einzelnen Speicherblock zum C64 sendet (erlaubt einen kleineren Initial-Loader im Kernal-Tape-Format) oder in den Kommandomodus, wo voller Zugriff besteht.

    Zitat

    Wer baut's ;-)?

    enthusi hatte die Idee und ich habe das vor längerer Zeit mal zusammengehackt:

    Zitat von git log

    commit 642fcbe535c566d867269c582b068edec5544792
    Author: Ingo Korb <ingo@akana.de>
    Date: Sat Sep 28 12:53:59 2013 +0200

    Initial import

    (falls sich jemand ans Cassiopei erinnert: Als dazu erstmals was im Netz zu lesen war, wartete ich gerade auf die Lieferung meiner ersten Prototyp-Platinen)

    Das ganze ist dann allerdings einige Zeit lang eingeschlafen bis wir es Ende letzten Jahres wieder ausgegraben haben um es etwas zu aktualisieren, polieren und zu kostenoptimieren (kleine ARMs sind inzwischen billiger als kleine AVRs). Ist allerdings noch nicht in einem Release-tauglichen Zustand, mir fehlt noch mindestens ein Feature um später irgendwie Firmware-Updates hinzuwürgen sowie ein UART-Zugriff auf den Kommandomodus, um den Speicher jenseits des C64 etwas flotter programmieren zu können.

    (oder bezog sich das "bauen" auf einen SMD-Bestücker? ;) )

    Oha, das bedeutet, dass man per shift+run/stop den Loader (der vielleicht sogar einen kleinen Browser enthält) im Standard-C64 laden kann, mit dem man dann blitzschnell Dateien lädt, oder? Coole Idee! Der Loader/Browser müsste halt möglichst klein sein, da er ja mit Standard-Tape-Routine geladen wird...

    Minimum sind der 192 Byte lange Tape-Header, der netterweise komplett im Kassettenpuffer landet und fast vollständig leer ist plus ein 2 Byte langes Programm, welches einen Vektor zwecks Autostart überschreibt und in den schon im Header geladenen Code reinspringt.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Dagegen spricht, dass die externe Hardware "wissen" müsste, an welches Gerät sie angeschlossen ist.

    Warum? Die Detektion könnte man in der Software ausführen, solange es möglich ist, ein Loader-Programm zu schreiben, das zunächst mal auf allen Geräten läuft.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Warum?

    Das Encoding ist für die jeweiligen Zielrechner unterschiedlich. Ein C64 kann ohne spezielle Software nicht die Tapes des jeweils anderen Computers lesen. Das gilt leider für alle Commodore-Tapes.

    Jens

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • Oh, das wusste ich nicht. Schade...

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Das beißt sich mit meiner Idee, die Motor-Leitung als "Umschalter" zwischen Kommando- und Datenmodus zu verwenden, denn sie wird von den normalen Tape-Routinen natürlich auch verwendet. Wahrscheinlich muss man sich etwas Ausgefeilteres überlegen, um vom "Browser-Loader"-Modus in den schnellen Übertragungsmodus zu kommen - vielleicht so etwas wie eine magic-sequence auf der write-Leitung.

    Ist die Motor-Leitung nicht sowas wie ein natürliches Erkennungsmerkmal der normalen Tape-Routinen? Wenn die externe Hardware Sense richtig setzt, dann wir beim Laden im Kernal-Modus der Motor angehen. Wäre auch gleich ein Prima Zeichen, um abgebrochene Übertragungen zu resetten.
    Noch ein paar Gedanken:
    -Blockweise übertragen, nach jedem Block kann dann wieder ein Kommando gesendet werden.
    -Die Read-Leitung an FLAG1 in $dc0d ist glaub ich nicht mit anderen Sachen verbunden. Ich sehe zwar grad keine Anwendung, aber vielleicht kann sie doch noch irgendwie für ein Signal an den 64er benutzt werden.
    -Kann man eigentlich 1 Eingang + 1 Ausgang auf der Erweiterungsseite + 1 Port aus $01 miteinander verbinden? Wenn $01 auf Eingang steht würde aus Sicht der Erweiterung alles normal funktionieren, was sie sendet kommt auch an ihrem Eingang an. $01 auf Ausgang müsste die Erweiterung bei bestimmten Werten feststellen können. Auch hier seh ich grad keinen Bedarf, nur so ein Gedanke...

    Minimum sind der 192 Byte lange Tape-Header, der netterweise komplett im Kassettenpuffer landet und fast vollständig leer ist plus ein 2 Byte langes Programm, welches einen Vektor zwecks Autostart überschreibt und in den schon im Header geladenen Code reinspringt.

    In 192 Bytes lässt sich schon einiges mehr als nur ein gekürzter Loader unterbringen.

  • Ist die Motor-Leitung nicht sowas wie ein natürliches Erkennungsmerkmal der normalen Tape-Routinen?


    Kann man es nicht durch einen Timeout lösen?

    Wenn Sense durch die externe HW per default gesetzt wird, ergäbe sich m.E. folgendes:

    Speed-Load: C64 setzt Motorsignal und überträgt zeitnah auf Write einen Ladebefehl. Externe HW startet schnelle Übertragung.

    Kernal-Load: C64 wartet auf Sense. Da es bereits gesetzt ist, setzt er das Motorsignal, aber sonst passiert erstmal nichts. Nach einem Timeout (1s?) weiß die externe HW, dass es das Loaderprogramm übertragen muss.

    Oder ist da ein Denkfehler drin? Ich bin auch noch nicht sicher, wie ein C64-Reset dann behandelt wird.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Mit der schnellste kommerzielle Loader bei Spielen duerfte am Ende einfach TurboTape gewesen sein.
    Wie z.B. bei Turrican. Auch da fluchte schon der ein oder andere wenn dann ab Level X nichts mehr geht... Einen 'bad block, please rewind' gab es DA naemlich nicht.

    Verschiedene Loader auf Seite A und B waren durchaus ueblich. Wenn auch eher selten am C64. Dafuer aber beim BBC micro, Electron und MSX die teilweise ja ohnehin unterschiedliche Baudraten von Haus aus anboten in ihrem ROM Loader.

    Was den Betrieb am Cassport angeht, da gab es ja schon einige:
    c2n232 z.B. welches auch sehr nuetzlich und schnell ist. Das habe ich viel fuer Maniac Mansion Gold eingesetzt.
    Bitte melde dich an, um diesen Link zu sehen.

    Ebenso Cassadapt welches auf Knopfdruck ein Alignment tool an den C64 schickt.
    Dieses hier genaugenommen:
    Bitte melde dich an, um diesen Link zu sehen.

    In 192 Bytes (bzw in 169) passt bereits ein kompletter TurboTape loader :)
    Bitte melde dich an, um diesen Link zu sehen.

    Gar nicht sooo selten, wurde etwas aehnliches ja auch benutzt.

    Die Idee, dass eine Erweiterung am CASSPORT auch per Shift+Run/Stop ladbar ist, hatte ich schon vor einer ganzen weile (ist ja auch naheliegend).
    Inzwischen hat Unseen das komplett entwickelt und umgesetzt. Funktionale Prototypen existieren und ich hoffe wir koennen demnaechst mal eine Anwendung vorstellen :smile:

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Mit der schnellste kommerzielle Loader bei Spielen duerfte am Ende einfach TurboTape gewesen sein.

    Ne, wie Bitte melde dich an, um diesen Link zu sehen. dokumentiert, ist der hier viel schneller: Bitte melde dich an, um diesen Link zu sehen.

    4.4 kBit/s vs 3.75 kBit/s oder so bei TurboTape...

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Man kann die Motor-Leitung auch als eine Art Reset-Leitung für die externe Hardware sehen: Falls irgendwie die Hardware im Sendebetrieb ist würde Motor alles abbrechen und wieder auf Empfang von Kommandos umstellen.

    $FDA3 ist die Init-Routine, die bei Reset und Restore läuft.
    FDD5: A9 E7 LDA #$E7 ; xx10 0xxxFDD7: 85 01 STA $01 ; 6510 On-chip 8-bit Input/Output RegisterFDD9: A9 2F LDA #$2F ; xx10 1xxxFDDB: 85 00 STA $00 ; Motor + Data out

    Ich will es nicht schwören, aber ich meine, während des Resets brummt der Datasettenmotor mal kurz, muss man mal prüfen. Wäre jedenfalls gut, um mit dem Motor-Signal die Hardware auf Empfang und durch diese dann Sense auf "Taste gedrückt" zu setzen. Bin mir jetzt aber nicht sicher, ob 1 in Motor wirklich heisst, das der dann läuft, oder ob das genau umgekehrt ist.

  • -Die Read-Leitung an FLAG1 in $dc0d ist glaub ich nicht mit anderen Sachen verbunden. Ich sehe zwar grad keine Anwendung, aber vielleicht kann sie doch noch irgendwie für ein Signal an den 64er benutzt werden.

    Hatte ich zwischenzeitlich mal als "Modul bereit für nächstes Byte"-Marker drin weil zB Schreibzugriffe auf den Speicher etwas länger dauern können, ist aber wieder rausgeflogen. Das Problem mit FLAG1 ist, dass es durch einen Lesezugriff auf das CIA ICR gelöscht wird, was für einige Lästigkeiten beim Umbau schon vorhandener Interrupt-Routinen verursachen könnte.

    Zitat

    -Kann man eigentlich 1 Eingang + 1 Ausgang auf der Erweiterungsseite + 1 Port aus $01 miteinander verbinden?

    Könnte man, aber wozu? Mikrocontroller-Pins sind üblicherweise einzeln in ihrer Richtung umschaltbar und wer die Leitung wann in welcher Richtung verwenden darf legt man im Protokolldesign fest. Das muss natürlich berücksichtigen, dass der C64 jederzeit geresetted werden könnte und dann so schnell wie möglich/sinnvoll die Orginal-Richtung wieder herstellen oder zumindest Pegel ausgeben (Low ist unkritsch, aktives High problematisch), bei denen der 6510-Port nicht zerstört wird.

    Zitat

    In 192 Bytes lässt sich schon einiges mehr als nur ein gekürzter Loader unterbringen.

    Genaugenommen sind es nur 171 freie Byte - in dem Block steht zB noch der Dateiname und ein paar Verwaltungsbytes wie Start- und Endadresse. "Gekürzt" würde ich den Loader auch nicht unbedingt nennen, der kann fast beliebig viele Daten ins C64-RAM laden, so lange die an einem Stück sind und er sich nicht selbst überschreibt. Am Ende werden noch ein paar Vektoren neu gesetzt und der Bildschirm eingeschaltet, damit das zu startende Programm eine möglichst "normale" Umgebung sieht.

    Wegen des 2-Bit-Transfers ist der Platzbedarf allerdings etwas höher als bei einem typischen Tape-Loader: Beim Tape kann man eine Unterroutine zum Einlesen eines Bits anlegen und die 8x aufrufen, der 2-Bit-Transfer braucht "entrollten" Code für ein komplettes Byte. Ich könnte zwar diesen Initialloader auch auf 1-Bit-Übertragung umstellen und evtl. etwas Platz rausholen, aber wozu wenn das Ding alles kann was ich an der Stelle brauche und es so schneller ist?

    Man kann die Motor-Leitung auch als eine Art Reset-Leitung für die externe Hardware sehen: Falls irgendwie die Hardware im Sendebetrieb ist würde Motor alles abbrechen und wieder auf Empfang von Kommandos umstellen.

    Genau das mache ich auch.

    Zitat

    $FDA3 ist die Init-Routine, die bei Reset und Restore läuft.
    FDD5: A9 E7 LDA #$E7 ; xx10 0xxxFDD7: 85 01 STA $01 ; 6510 On-chip 8-bit Input/Output RegisterFDD9: A9 2F LDA #$2F ; xx10 1xxxFDDB: 85 00 STA $00 ; Motor + Data out

    Bei einem Hardware-Reset hat sich zu dem Zeitpunkt das Modul schon längst wieder in den "Datasetten-Modus" (heisst in der Doku derzeit "streaming mode") zurückversetzt. =) Wenn der 6510 einen Reset-Impuls erhält, schaltet er seine I/O-Pins auf Eingang und mit der Schaltung im C64 entspricht das einem laufenden Datasetten-Motor.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Könnte man, aber wozu? Mikrocontroller-Pins sind üblicherweise einzeln in ihrer Richtung umschaltbar und wer die Leitung wann in welcher Richtung verwenden darf legt man im Protokolldesign fest. Das muss natürlich berücksichtigen, dass der C64 jederzeit geresetted werden könnte und dann so schnell wie möglich/sinnvoll die Orginal-Richtung wieder herstellen oder zumindest Pegel ausgeben (Low ist unkritsch, aktives High problematisch), bei denen der 6510-Port nicht zerstört wird.

    War nur so ein Gedanke, wie die Erweiterung unter Umständen erkennen könnte, dass am C64 was unerwartet auf Ausgang steht.
    Dann wäre es bei einem 1Bit-Protokoll mit Screen und anderem Schnickschnack sicher gut, Data als Takt und Sense für die Daten zu verwenden. So dürften keine verbundenen Ports je gleichzeitig auf Ausgang gehen.

    Ist Dein Ding mit Menü oder ohne? Wo kann man das denn mal sehen?

  • War nur so ein Gedanke, wie die Erweiterung unter Umständen erkennen könnte, dass am C64 was unerwartet auf Ausgang steht.

    Nee, Richtung erkennen geht nicht so einfach - da müsste man einen kontrollierten Strom auf den Pin geben bzw. von da ziehen und messen, wie stark der dadurch beeinflusst wird. Das ist etwas viel Aufwand.

    Zitat

    Dann wäre es bei einem 1Bit-Protokoll mit Screen und anderem Schnickschnack sicher gut, Data als Takt und Sense für die Daten zu verwenden.

    Ok, fertig! ;)

    Zitat

    So dürften keine verbundenen Ports je gleichzeitig auf Ausgang gehen.

    In gewissen Grenzen ist das kein Problem - mein Modul kann die Pins nur gegen Masse schalten oder per Pullup auf 1 heben. Beides ist für die I/O-Ports des 6510 kein Problem, auch wenn die gerade auf dem jeweis gegenteiligen Pegel stehen. Protokolltechnisch ist das ganze zudem noch so designt, dass der aktiv-auf-Masse-ziehen-Fall bei "umgedrehter" Richtung höchstens für einige dutzend Mikrosekunden auftreten kann um das ganze noch weiter zu entschärfen.

    Zitat

    Ist Dein Ding mit Menü oder ohne? Wo kann man das denn mal sehen?

    Mein Ding ist ohne Menü - die Idee war eher was in Richtung Easyflash 1 anzubieten, auf dem sich andere Leute austoben können. Die ursprüngliche Idee war sogar noch weiter eingeschränkt - als möglichst billiger externer Speicher mit 64 KByte Kapazität um den Expansionsport freizuhalten.

    Sehen kann man da nicht viel - die alten Prototypen waren kleine violette Platinen mit Tapeport-Stecker und SMD-Bauteilen, der aktuelle Testaufbau ist ein wenig Chaos auf einem kleinen Steckbrett und die noch nicht gelöteten neuen Prototypen sind wieder kleine violette Platinen mit Tapeport-Stecker und SMD-Bauteilen.

    Wenn gesteigertes Interesse besteht könnte ich auch noch eine SMD-freie Variante entwerfen, die wäre allerdings teurer und 16MBit-SPI-Flashchips im DIL8-Gehäuse sind in kleinen Mengen schlecht beschaffbar - Digikey würde die zB nur in 100er-Stangen abgeben.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.