Vorstellung: C64 BBS Raveolution

Es gibt 297 Antworten in diesem Thema, welches 54.134 mal aufgerufen wurde. Der letzte Beitrag (26. Mai 2025 um 13:42) ist von Larry.

  • Heute gab es mal wieder ein kleines Update im BBS Code. Als Sysop oder U/D-Op, d.h. mit entsprechenden Userrechten, kann man Files von Disk dem UD- Directory Listing (eigenes SEQ File) hinzufügen. Mit dem Command Pfeil links + Dateinummer oder Dateiname wird entsprechender Eintrag, wie bei einem herkömmlichen Upload, der UD- Liste hinzugefügt. Bei einem Datei upload wird der User gefragt, ob der Upload automatisch auch im Subboard bekannt gemacht werden soll. Diese Option fehlte bisher beim anfügen einer Datei direkt von Disk. Das ist nun eingebaut und ein kleiner weiterer Schritt Dinge im BBS Betrieb automatisieren zu können.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • So ganz langsam fange ich wieder an VICE zu mögen. Das liegt daran, dass ich nun endlich wieder am PC meine Änderungen an C*BASE ordentlich testen kann.

    Vorbei sind die Zeiten wo man mit quälenden 2400 Baud über den Userport verzweifelt versucht einen Connect hinzubekommen.

    Endlich läuft das wieder mit Swiftlink bzw. sogar Turbo232 und SuperCPU.

    Ich hoffe die CMD-HD und im Idealfall auch die RamLink Emulation läuft dann auch noch stabil. Könnte man fast ein 2. Board auf machen :D

    2 Jahre mit hin und her kopieren auf echte Hardware ohne halbwegs debuggen zu können und läuft es doch wieder nicht waren richtig nervig. Deswegen kamen in letzter Zeit auch verhältnismäßig wenig Updates am BBS Code oder den Modulen / Protokollen drum herum.

    Danke an die Macher von VICE.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Heute mal wieder den Abend ziemlich frei gehabt und schon gibt es wieder was Neues für's BBS.

    Bei allen nicht "Cyborg Mod" basierten C*BASE Versionen, jedenfalls die, die mir bekannt sind, gibt es keine automatisch erzeugten User Rankings. Die kann man nur manuell erzeugen, entweder als SysOp oder als User im Bereich der Games / Doors. Da kann es dann schon mal vorkommen, dass die Rankings 2 Jahre nicht aktualisiert werden :schande:

    Das musste dringend ein Ende haben. Deswegen werden die User Rankings nun mit den Mitternachts Routinen gestartet, sofern das vom SysOp überhaupt gewünscht ist. Gesteuert wird das über eine Parameter Tabelle, in der zusätzlich auch der Aufrufrythmus vorgegeben werden kann, sowie die Anzahl Tage die für die aktiven (!) User für die Top 10 gewertet werden sollen.

    Gewertet wird eine Mischung aus Anzahl Posts (in den Subs) und dem Up- / Downloadverhältnis. So kann man sich als User auf die eine oder andere Art in die Charts pushen. Der SysOp ist aus der Wertung ausgenommen.

    Beispiel: Es können nun z.B. alle 30 Tage die Top 10 nachts erstellt werden und zwar nur von den Usern, die innerhalb der letzten 365 Tage das BBS angerufen haben. Die Zeiträume sind frei wählbar. Somit gibt es keine "Top User Leichen" mehr, die zwar vor Jahren mal sehr aktiv waren, aber aktuell eben nicht mehr.

    Das ganze funktioniert nun erst einmal nur von der technischen Seite. Jetzt muss die Top10 Liste noch optisch schön gemacht werden. Ich hoffe bis zum Wochenende das Update auf meinem BBS rüber schieben zu können.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • So ab Freitag geht es mit den Userrankings auf dem BBS los. Dann werden im 7-Tages Rhythmus die Top User neu ermittelt.

    Viel interessanter ist aber ein "kleines" Code Update. Damit andere SysOps, die ebenfalls meinen C*BASE Mod verwenden wollen, sich beim aufsetzen des Systems sich keine Gedanken darüber machen müssen welches NMI File (also der Treiber für die RS232 Schnittstelle) sie nehmen sollen, wird das nun im Boot File automatisch erledigt. D.h. je nach RS232 Hardware (Userport / Swiftlink / Turbo232 / Silversurfer) und Adressbereich ($de00 / $df00 beim Swiftlink / T232) wird automatisch erkannt was am Rechner angeschlossen ist und der Treiber wird von Disk geladen und aktiviert.

    Man muss vorher beim Setup nur noch auswählen mit wieviel Baud das BBS laufen soll und ob der Carrier normal oder invertiert ist. Fertig.

    Warum hat man das damals nicht schon so gemacht, anstatt allen C*BASE Neu- Sysops den letzten Nerv damit zu rauben? Naja besser spät als nie.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Auf CSDb, gibt es ein kleines Weihnachtsgeschenk von mir.

    Wer wissen möchte, wie so ein BBS programmiert ist, kann sich gerne auch den unaufgeräumten Quellcode, bzw. den "soweit ich konnte kommentierten ML Code" anschauen.

    Vielleicht ist ja die eine oder andere Idee für das eigene Projekt ganz Interessant für euch.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Frohes neues Jahr zusammen.

    Den Jahreswechsel habe ich genutzt fürs "groß Reinemachen" im BBS.

    DIRBitte melde dich an, um diesen Link zu sehen. mit den neuesten Uploads ist für 2024 neu gemacht worden, und das Userlog wurde von 110 verwaisten Accounts befreit.

    Jeder der seit 730 Tagen, also 2 Jahren nicht mehr auf meinem BBS war ist rausgeflogen.

    Falls jemand von euch dabei war, und der Login nicht mehr funktionieren sollte, dann bitte wieder neu anmelden und Feedback an den SysOp nicht vergessen, sonst wird das nichts.

    Beim login kann man mit "L" sich die Userliste anzeigen lassen, falls man unsicher ist, ob der eigene Account noch vorhanden ist, oder nicht.

    Auf CSDb gibt es zudem noch ein kleines Neujahrs Geschenk. Ein keines Tool von 1985 um die überschüssigen Bytes nach einer X-Modem Dateiübertragung zu entfernen.

    So und nun zurück an die Arbeit.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Hallo, ich hab heute mal reingeschaut. Hab mir zwar schon ein paar C64 BBSen angeschaut, aber bin immernoch ein Noob in der Benutzung. Was ich nicht verstehe: wie funktionieren up- und downloads? Ich hab mich heute per VICE und CCGMS verbunden. Aber sonst auch auf dem realen C64 mit rr-net und guruterm.

    Bitte melde dich an, um diesen Link zu sehen./tilde.town/~mischk/linktree.html

    Abonniere meinen Newsletter:

    Bitte melde dich an, um diesen Link zu sehen.

  • Beide Seiten gleiches Protokoll, vom Hauptmenü mit "u" in die UL/DL Sektion, "$" um Directory anzuschauen, "dx" (x = Filenummer im Dir), wenn Meldung kommt Filetransfer starten, den Download im Terminal starten, fertig.

    Gruß & Kuss zum Wochenschluss,
    Holy Moses/Role

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um dieses Medienelement zu sehen.

  • wie genau startet man den Download dann im Terminal?

    Bitte melde dich an, um diesen Link zu sehen./tilde.town/~mischk/linktree.html

    Abonniere meinen Newsletter:

    Bitte melde dich an, um diesen Link zu sehen.

  • Guruterm besitzt keinerlei Filetransfer-Funktion wenn ich mich recht innere, und bei CCGMS wäre "F3" für Download (bezogen auf mein obiges Beispiel) die richtige Wahl.

    Und für Upload in der BBS mit "u" in den UL/DL-Bereich, beide Seiten gleiches Protokoll einstellen (BBS wechseln mit "t", CCGMS mit "F7" und dann "p" meine ich), in BBS "u" und Return (dann, wenn verlangt, Filename eingeben für die BBS), wenn BBS sagt "Transfer starten" im CCGMS "F1" für Upload, Filenamen eingeben/aussuchen und los... :thumbsup:

    Gruß & Kuss zum Wochenschluss,
    Holy Moses/Role

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um dieses Medienelement zu sehen.

  • danke :)

    Bitte melde dich an, um diesen Link zu sehen./tilde.town/~mischk/linktree.html

    Abonniere meinen Newsletter:

    Bitte melde dich an, um diesen Link zu sehen.

  • Wenn Du X-MODEM möchtest, musst Du das bei Dir im Terminal und (!) im BBS auswählen.

    Gruß & Kuss zum Wochenschluss,
    Holy Moses/Role

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um dieses Medienelement zu sehen.

  • Wenn Du X-MODEM möchtest, musst Du das bei Dir im Terminal und (!) im BBS auswählen.

    Yep, soweit alles richtig. Kleine "Besonderheit" bei mir: Es gibt X-Modem, das Alte mit 1Byte Checksum und "X/Y-Modem" was folgende Protokolle in sich vereint: X-Modem CRC, X-Modem1K, Y-Modem batch

    Das BBS nimmt dann automatisch "das richtige" Protokoll, abhängig davon ob du Multitransfers machen willst (Y-Modem batch) oder Single File Transfer mit CRC (128 Byte Transferblockgröße) oder 1K (1024 Byte Transferblockgröße).

    Wo wir schon mal beim Thema sind, hier wieder was Neues aus der Rubrik "Heute so reverse engineert", oder "heute so decompiliert".

    Ich habe in den letzten 2 Jahren so ziemlich alle X-Modem Varianten durch genommen inkl. Y-Modem-g (streaming). Wo ich bisher noch nie dran gegangen bin ist WXMODEM. Das ist Windowed X-Modem, sprich es wird nicht jeder Transfer Block einzeln übertragen und acknowledged, sondern es gibt ein "Fenster" von 1 bis 4 Transferblocks je 128 Datenbytes, die in einem Rutsch acknowledged werden können. Sollte dabei einer der 4 Blocks einen Übertragungsfehler haben, wird der erkannt und neu übertragen. Das ist also so in etwa X-Modem 0,5K nur besser :)

    Nova- / Striketerm hat WXModem an Bord, allerdings nur um Daten zu empfangen, kein Upload. Nicht schlimm dachte ich mir, es gibt ja noch andere Terminal Programme mit WXModem, "WXTerm" zum Beispiel.

    Also flott WXterm mit dem Decompiler von Stephan Scheuer verwurstet und das ML File mit dem Transferprotokoll in VS-Code importiert. Dann fing der Spaß an, ohne Doku oder sonst was, aus dem ML Code wieder was Assemblierbares zum machen, mit Labels, Kommentaren etc. 2 Tage Arbeit um dann festzustellen, dass das WXMODEM da auch nur Receive kann und kein Send, bzw. bei Send nur X-ModemCRC und altes X-Modem als Fallback.

    Super. Warum hat damals das keiner zu ende gebracht mit Upload Möglichkeit am C64 ? Gab es da irgend welche plausiblen Gründe für ?

    Dann bin ich leicht gefrustet auf die Suche gegangen, was es damals denn noch so seltsame Transferprotokolle gab. Heraus kam das "Rainbow Transferprotokoll". Habt ihr da schon mal was von gehört, oder es vielleicht sogar benutzt ?

    Ich habe 2 Terminal Programme gefunden, die das haben, T-Term und Touchterm. Wahrscheinlich muss es auch ein BBS Programm gegeben haben, dazu konnte ich bisher aber nichts herausfinden.

    Leider können beide Terminals nur mit Userport Modems aus der 16xx Serie umgehen. Unter VICE habe ich damit keine Verbindung zu tcpser hinbekommen, um das Rainbow Protokoll einmal ausprobieren zu können.

    Daher hier die 2. Frage: Kann ich irgendwie ein 1670 Modem am Userport in VICE mit tcpser ans Laufen kriegen ? Und wenn ja, wie ? Bisher sprechen die nicht miteinander. Weder Dial noch Autoanswer oder sonst etwas geht.

    Touchterm (3.5) habe ich dann auch durch Stephan's Decompiler laufen lassen, um irgendwelche Anhaltspunkte zu bekommen, wie das Protokoll angesteuert wird.

    Auch hier von ML Code zu Assemblierbaren "Source" Code mit VSCode ohne irgendwas an Doku scheint sich zu einem mittelschweren Projekt zu entwickeln.

    Wenn also jemand Lust hat an WXMODEM und oder Rainbow (von Deep Pan Software 1985) mitzuarbeiten, bitte melden. Ich habe gehört Reverse Engineering macht Spaß :D und alleine Spaß haben macht nur halb so viel Spaß.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

    Einmal editiert, zuletzt von Larry (9. Januar 2024 um 12:34)

  • Da Du ja gerade am decompilieren bist gleich eine Frage:

    Die älteren Modems werden ja noch nicht über AT-Kommandos gesteuert, sondern die Parameter werden über Schalter eingestellt, also Originate/Answer und Bell/CCITT, sowie die baudratenabhängigen Modulationsverfahren.

    Aber wie wird gewählt? Das müsste doch über eine Handshake-Leitung und somit über einen Portpin des Userports gehen. Nur welchen?

    Hast Du da schon etwas herausgefunden?

  • Hast Du da schon etwas herausgefunden?

    Nicht so wirklich. Ich hatte auch mit AT Kommandos versucht was zu reißen, ging aber nicht. Obwohl "1670/Hayes" mir was anderes suggeriert hatte.

    Ich kann dir aber den decompilierten BASIC Code geben, vielleicht bringt dich das weiter ? Ich konzentriere mich jetzt erst mal auf das Transferprotokoll damit das bzw. die beide im Idelafall mit C*BASE laufen.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Da Du ja gerade am decompilieren bist gleich eine Frage:

    Die älteren Modems werden ja noch nicht über AT-Kommandos gesteuert, sondern die Parameter werden über Schalter eingestellt, also Originate/Answer und Bell/CCITT, sowie die baudratenabhängigen Modulationsverfahren.

    Aber wie wird gewählt? Das müsste doch über eine Handshake-Leitung und somit über einen Portpin des Userports gehen. Nur welchen?

    Hast Du da schon etwas herausgefunden?

    Wählen über Handshake-Leitungen? Was für Modems waren das denn? :gruebel

  • Das müssten eigentlich alle rein analogen Userport-Modems sein, die programmgesteuert abheben bzw. wählen konnten. Also alle ohne eigenen Prozessor und AT-Kommandos.

  • Das müssten eigentlich alle rein analogen Userport-Modems sein, die programmgesteuert abheben bzw. wählen konnten. Also alle ohne eigenen Prozessor und AT-Kommandos.

    Achso, also C64-spezifische Modems. Hast du mal ein Beispiel?