Diese Sockel sollte es im Elektrofachhandel noch geben.
Die arme SCPU, die ist ja echt runtergerockt.
Ich habe auch eine Rev. 1D. Die hat z.B. original eine rote LED oben.
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ß
-
ARC 3 als 128er Version gibt es doch schon von John Wilson. Die hat er am 10.12.2020 gebaut.
PS: Die C64 Version kommt gleich mit Loading Picture, Docs, Solution als Komplettpaket auf CSDB...
-
Ist doch richtig. Swiftlink ist doch eine serielle Schnittstelle am Userport.
Öhmm nö. Swiftlink kam schon immer in den Expansionsport.
-
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.
-
Auf der Webpage von D.Kahlin steht:
QuoteOver5 is targetted for the plain c64, c128 in c64 mode and vic20 only. It additionally requires (and supports) only a user port serial adapter and a null modem cable
Also nix mit Swiftlink ?!
-
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.
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:
Display MoreCode- ;Y-Modem needs to transfer Filename in Transfer-Block #0 instead
- ;waiting for "C" from receiver
- _ymdwtc: get#5,a$:if a$<>"c" then goto _ymdwtc
- ;send SOH 00 FF foo.c NUL[123] CRC CRC -> 131 Bytes + 2 CRC16 Bytes = 133 Bytes. Then add chr$(13) for str2buf Routine
- ;no Filesize in Bytes or modification Date send (TODO)
- i$="{CTRL-A}"+chr$(0)+chr$(255)+p$:for i=len(p$) to 131:i$=i$+chr$(0):next:i$=i$+g$
- ;write i$ to output Buffer $cf00. BASIC ROM Routine $b08b search string
- ;strip closing g$ (->chr$(13)) from i$
- ;call crc16 Routine from Protocol. $c718 and get i$ back from Outputbuffer
- sys 45195 o$:r=256*peek(781)+peek(780):gosub _str2buf:i$=left$(i$,len(i$)-1):sys 50968:gosub _createis
- ;send File+crc to Modem
- _ymdsndfn: print i$;:print#5,i$;
- ;wait for ACK / "C"
- get#5,a$:get#5,b$:if a$=chr$(6) and b$="c" then goto _17481
- ;cancel "CAN" from receiver ?
- if (a$=chr$(18)) and (b$=chr$(18)) then ab=1:goto _17482
- ;resend
- goto _ymdsndfn
- _17482: -> abbruch Routine...
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.
-
EgonOlsen71 : Ja habe ich auch gerade entdeckt. Nur wie bekommt man das in BASIC 2.0 aufgelöst ?
Die 2. Schleife habe ich bewusst noch weggelassen, um erstmal den 1. Teil der Schleife ans Laufen zu bekommen.
-
Einen Teil von EOR habe ich versucht aufzulösen, bekomme aber nach dem 2. Schleifendurchgang in Zeile 30 einen Illegal Quantity Error:
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:
Die komprimierte Variante würde ich evtl. so in BASIC V2 übersetzen mit fehlendem EOR Part:
