Posts by Larry

    Das ist nicht original so. Da hat jemand eine Platinenverlängerung drangebraten :)

    Die Kabel vorne sind auch nicht Serie...


    Bitte um Vorschläge.

    Versuch mal die Kontakte mit einem Radiergummi auf beiden Platinenseiten zu säubern. Die Kontakte werden damit ruck zuck blank.

    Wenn das auch nichts mehr bringt, dann müssen hier unsere Forums Hardware Spezies weiterhelfen.

    Wäre es dann nicht einfacher, gleich die erlaubten Zeichen zu übergeben?

    Ja das ist dann so herum ja eine Whitelist. Eine Blacklist wäre die Zeichen zu übergeben, die ungewollt (verboten) sind.

    Ist letztlich eine Frage des Aufwands für den Coder und User. Wenn ich nur ein Zeichen ausschließen will, wäre eine Whitelist eher unpraktisch. Andersherum wenn ich nur A-Z und 0-9 und !"# haben will, macht eine Whitelist mehr Sinn.

    Meine Meinung.

    Ja meinte ich ja -> kompletter Zeichensatz entweder groß oder klein. Und dann, wenn und wie der User es braucht, einzelne Zeichen aus dem jeweiligen Zeichensatz ausschließen.

    Das kann ja je nach Anwendungsfall unterschiedlich sein. Der Eine braucht diese Einschränkung gar nicht ein Anderer evtl. das @ Zeichen, der nächste Pi etc. pp. oder er will nur Buchstaben und Zahlen.... you name it.


    Edit: also eine Userdefinierte Zeichen-Whitelist bzw. Blacklist

    Gerne die komplette Bandbreite. Zur Not für die C*BASE Leute, wenn das "@" oder ggf. andere Zeichen (auf Vorgabe?!) exkludiert werden könnten, da evtl. bestimmte Zeichen BBS Funktionen (sog. MCI Codes) auslösen könnten.

    Vielleicht als Idee / Anregung:

    Convert nach PETSCII unter Auswahl ob Zeichensatz mit Großbuchstaben oder eben den mit kleinen Buchstaben. Das wäre dann für BBS PETSCIIs interessant, da hier meistens mit dem Zeichensatz der kleinen Buchstaben gearbeitet wird. Export in ein SEQ File wäre noch top.

    Uploads sind nun auch alle durch. Auch hier wie bei den Downloads, alle Terminal Programme funktionierten außer HandyTerm und CCGMS 2020/21.

    Zusätzlich habe ich auch mal ZTerm 1.0f ausprobiert, aber leider funktionieren auch hier keine Up- / Download mit Punter Multitransfers (mehr).

    Gerade noch mal ein paar Testläufe gemacht:


    - mit CCGMS 2019 und Ultimate funktioniert die Kommunikation VICE 3.5 (Standard Speed rund 1MHz) per Userport zu tcpser (2400 Baud) noch. Damit funktionieren auch Punter Multiup- und downloads

    - mit CCGMS 2020 und 2021 keine Chance.


    Kann das einer von euch mal Gegenprüfen, ob CCGMS ab der 2020er Verision mit VICE noch funktioniert ?


    Uploads mit den anderen Terminals folgt.

    Aber was ist CCGMS 2001?

    Das ist eine alte Version von Onslaught. Hat als "Specialfeature" ANSI ja / nein und ein Chatwar Feature on / off (nie ausprobiert was das kann oder sein soll). Hatte ich zufällig auf einem D64 Image da.

    Sollten beide auch nicht gehen so müßte man mal Alwayz kontaktieren

    Alwyz macht nichts mehr mit CCGMS. Sein BBS ist ebenfalls offline.

    Kann die beiden Versionen aber gerne noch mit VICE 3.5 ausprobieren. Ein U2 habe ich leider nicht und das U64 wird für den Test für's BBS gebraucht.

    Es wird langsam mal wieder Zeit für ein kleines Update.

    Nachdem ich vor einigen Monaten mir auch ein Ultimate64 Elite besorgt habe, wurde heute mal die BBS Software damit ausprobiert. Es gibt ja schon zwei C64 BBS die auf einem Ultimate laufen und das gar nicht mal schlecht :)

    Allerdings haben beide mir von Problemen mit Punter Filetransfer berichtet. Also frisch ans Werk uns mal ein paar Downloads laufen lassen.


    Folgende Programme kamen zum Einsatz:

    - Striketerm 2014

    - CCGMS 2021

    - CCGMS 2001

    - HandyTerm 8.6

    - SupeRes Term 9.0

    - CGTerm 1.72b

    Alles in VICE 3.5 und tcpser, zusätzlich CCGMS 2021 als CRT im EasyFlash 3 in meinem C64C.

    Auf BBS Seite mein eigener C*BASE 3.1 Mod mit 48 MHz, die für den Punter Transfer nicht auf 1 MHz runtergetaktet werden.


    Ergebnis:

    - Leider bekam ich mit CCGMS 2021 keine Verbindung zu tcpser hin. Somit konnte ich keine AT - Befehle eingeben, nicht wählen, letzlich nicht testen.

    Deswegen CCGMS 2021 auf's EF3 gepackt, in den C64, Wifi Modem dran, keine Besserung, d.h. keine Kommunikation mit dem Modem -> fail (frag mich was da falsch läuft ?!)

    - CCGMS 2001 funktionierte perfekt. Keine Probleme mit Multi Downloads

    - Striketerm ebenso mit Protokoll "Multi-Punter"

    - HandyTerm versucht den Transfer zu starten, sendet aber "G" anstatt "GOO", weswegen das BBS nicht erkennt, daß das Terminal loslegen will -> fail

    - SupeRes Term funktionierte perfekt.

    - CGTerm 1.72b kann kein Multitransfer. Single Transfers mit Punter funktionieren damit aber auch.


    Wenn ich noch weitere Terminal Programme ausprobieren soll, bitte meldet euch :)

    Uploads werden morgen getestet. Für heute Nacht ist erstmal schluß :)

    OK, dachte wg. Threat Titel, dass hier auch ein SL am Start ist.

    Baudrate muss auf beiden Seiten gleich eingestellt sein, genau wie parity, Stop bits etc. normalerweise 8n1.

    Keine Ahnung wie das 38400 am Userport machen soll. 19200 ist das schnellste was ich am C64 am Userport gesehen habe.

    Egal versuch mal den C64 auf 2400 Baud zu bringen. Versuch mal mit CHR$(6) anstatt 5.

    Das funktioniert so leider alles nicht. Das liegt nicht an eurem tollen Code JeeK und EgonOlsen71 , sondern schlicht weg an der Tatsache, das das BBS Programm damit zu groß wird. Es wird der wenige mir zur Verfügung stehende RAM Bereich überschritten. Das führt nach compiling mit Blitz Compiler zu Laufzeitfehlern. :schreck!:


    Daher habe ich mir einen anderen Weg überlegt wie es funktionieren könnte. Das Transferprotocol X-Modem(1K) bringt die Routinen für die CRC16 Berechnung ja schon mit. Der Code liegt zwar im Bereich ab $b900, also unter dem BASIC ROM, kann aber mittels BBS Kernal Bordmitteln vom BASIC Programm aus angesprochen werden.

    Den oben schon gebildeten String lege ich in einem BBS Buffer Bereich bei $cf00 ab. Nun muss ich "nur noch" das Protokoll dazu bringen, diesen Bereich einmalig für die CRC16 Berechnung zu verwenden.

    Auweia.... jedenfalls ist der BASIC Teil damit in knapp 7 Codezeilen erledigt. Der ML Part mit dem ich das X-Modem Protokoll beackern muss ist noch gedanklich in Arbeit...


    Für Interessierte, so siehts gerade aus:


    Die hier nicht aufgeführten _str2buf und _createis packen den Inhalt der Variablen i$ aus dem Variablen Speicher in den BBS Buffer bei $cf00, bzw. wieder zurück von $cf00 in die Variable i$.

    HOLY MOSES/ROLE wird ggf. wissen was ich meine.... alter BBS Coder.


    EDIT: Sorry keine Zeilennummer in o.g. Codeschnipsel, da ich inzwischen nur noch mit BPP vom Henning arbeite.

    Wow, danke. Mal sehen ob das noch vom Platz her in den CBASE BBS Code rein passt und ob damit ein Filetransfer zustande kommt.

    Der läuft in dieser Form 1 Minute 48 Sekunden. Compiliert immer noch 21 Sekunden

    Das ist echt langsam selbst bei 21 Sekunden. Das würde eine SCPU oder TC64 / Ultimate64 zwingend vorraussetzen um niemanden mit langen Wartezeiten zu vergraulen.

    Jedenfalls vielen Dank für Deine Unterstützung.

    Nein fertige Testfälle bzw. Ergebnisse habe ich leider noch nicht. Die ASCII Chars für den Filenamen etc. sind in einem Bereich von 0-255. D.h. höchster Wert von 256*ASCII Code ist max. 65280 (r).

    Diesen könnte ich in Hi und Lo Byte auftrennen per:


    rm=int(r/65536):rl=r-rm*65536:rh=int(rl/256):rl=rl-rh*256


    Das ist analog zu X1, X2 und X3 aus Deinem Beispiel.

    In einem Quellcode Kommentar findet sich noch dieser Satz:

    //The high byte of the CRC is located in byte 132. The CRC is calculated only on the data packet bytes (4 - 131).

    Ich glaube das wird mir in BASIC langsam zu umständlich.

    Einen Teil von EOR habe ich versucht aufzulösen, bekomme aber nach dem 2. Schleifendurchgang in Zeile 30 einen Illegal Quantity Error:


    Code
    1. 10 cr=0
    2. 20 p$="file,p"
    3. 21 o$=chr$(1)+chr$(0)+chr$(255)+p$
    4. 25 for i=len(o$) to 131:o$=o$+chr$(0):next:rem o$ für CRC16 Berechnung aufbauen
    5. 30 for i=1 to 131:y=asc(mid$(o$,i,1)):cr=(cr or 256*y)-(cr and 256*y):print cr:next

    EDIT: Hmmm "OR" kann nur Werte von -32768 bis 32768. Außerhalb dieses Bereichs gibt es o.g. Fehlermeldung.

    Mit dem 3. Schleifendurchlauf wird das Zeichen chr$(255) durchlaufen, was bei 256*255 den Wert 65280 ergibt, d.h. weit weg von 32768.

    D.h. "XOR in Basic 2.0" aus dem C64 Wiki hilft mir hier auch nicht weiter. :/

    Danke. Das BBC BASIC Beispiel sieht da schon ganz gut aus.

    Allerdings gibt es in BASIC 2.0 keinen EOR oder XOR Befehl.

    Deswegen speziell diese Zeile macht mich gerade wuschig:

    Code
    1. crc%=crc% EOR 256*?addr% :REM EOR with current byte
    2. oder Komplett Code komprimiert:
    3. FORA%=mem%TOmem%+num%-1:S%=S%EOR256*?A%:FORB%=1TO8:S%=S%*2:IFS%AND&10000:S%=S%EOR&11021:NEXT:NEXT

    Die komprimierte Variante würde ich evtl. so in BASIC V2 übersetzen mit fehlendem EOR Part:


    Code
    1. FOR A=1 TO 131:S=S... ?!? :FOR B=1 TO 8:S=S*2:IF (S AND 65536) THEN S=S.....?!? :NEXT B:NEXT A