Posts by Larry

Quote from atomcode

Ich würde heute allerdings bei einem Loader und Entpacker lieber Ladebalken benutzen.

Aber INC $d020 ist so schön einfach zu programmieren

Das D.A.I.S.Y. Cartridge hatte damals ein Freund von mir, der mit noch ein paar anderen Jungs aus unserer Schule in einer Gruppe war.

Wenn ich das richtig in Erinnerung habe, hatte das Teil ein rotes Gehäuse.

Mit der mitgelieferten Software hatten wir dann ein paar Heavy Metal Samples aufgenommen und damit rumgespielt.

Ein Metal Song, Songname und Interpret leider nicht mehr bekannt, hatte im Refrain den Text "Silicon Brain Power Voices of Crime" oder so ähnlich, mit dem wir ein kleines Demo gemacht hatten.

Leider ist auch das Demo i.L. der Zeit verschwunden.

Wenn also von euch jemand irgend ein Intro / Demo etc. von "Silicon Brain" hat, bitte bei mir melden !

Edit: Das könnte von "Helloween" gewesen sein.

The Magic Roundabout, oha.... RIP !

Quote from WebFritzi

Kann man auch mal nachfragen beim Programmierer, IMHO. Frechheit!

Zu geil.... ich schmeiss mich weg

Sorry aber welcher Spieleknacker /-kopierer hat je den Programmierer gefragt, ob er das darf.

Btw. Who Cares ist IMHO ein Fake Label irgend einer Cracker Gruppe, bzw. eines einzelnen Crackers.

Da YMODEM-batch inzwischen ganz gut läuft, dachte ich mir "mal eben" auch die streaming Variante YMODEM-g einzubauen.

Im Gegensatz zu XMODEM 1K oder YMODEM-batch wird bei den "-g" Transferprotokollen nicht jeder übertragene Datenblock vom Empfänger ACKnowledged, d.h. der Datentransfer ist wesentlich schneller.

Die Datenpakete werden gestreamt also vom Sender einfach "rausgeblasen".

Nachteil von YMODEM-g ist, tritt ein Fehler (Bad Block) während der Übertragung auf, wird die Übertragung abgebrochen. Der Empfänger muss auch schnell genug sein, um die Datenpakete zu speichern.

Desterm, Novaterm und Striketerm erlauben daher auch nur den Transfer über ein RAM Laufwerk wie REU, RamLink etc.

Der Empfang auf meinem BBS mit YMODEM-g funktioniert in ersten Testtransfers soweit ganz gut. Das Senden von Daten (download), geht dagegen voll in die Hose. Das U64 mit dem Hyperspeed Kernal sendet einfach zu schnell, und zwar so schnell, dass z.B. Novaterm zum Teil abstürzt.

Ich hoffe das mit XON / XOFF Flowcontrol in den Griff zu bekommen, bisher allerdings erfolglos....

Ach ja noch ein Update: Als RSS Feeds gibt es inzwischen auch von CSDB aktuelle Releaselisten von Demos, Music, etc.

Und die ersten Onlinegames sind verfügbar.

Keine Atempause, Geschichte wird gemacht. Es geht voran....

Würde mich als Interessent für eine (am besten bestückte) Platine anschließen...

Hallo Endurion,

wie willst Du denn die Daten speichern ? Per SAVE $ffd8 oder wie bei einem z.B. SEQ File per OPEN und PRINT# $ffd2 ?
Kernal SAVE funktioniert z.B. so (alter Hi-Score Saver Routine von mir):

Man kann das File mit einem Filecopy Programm (z.B. FCOPY von CMD) von SD2IEC auf Disk / Diskimage kopieren, oder in anderer Richtung von Floppy in ein Image auf SD2IEC.

Dann hat sich das P00 Header Problem erledigt. Was nicht geht ist, kopieren am PC via USB etc. pp.

Die Arbeit hatte ich vor kurzem auch, als alle Files im BBS von SD2IEC auf's U64 umgezogen sind.

Mit Turbo (U64 / SuperCPU / TC64) kann man bestimmt ein paar Jahre Rechenzeit gut machen

pcollins war heute noch einmal so nett ein kurzes Video zu drehen. Vielen Dank dafür !

Zu sehen ist dieses Mal wie man in meinem BBS zum aktuellen RSS Feed vom Forum64 gelangt.

Der RSS Feed wird ca. alle 10 Minuten aktualisiert.

Autopause nicht vergessen einzuschalten, sonst muss man schnell lesen (oder Capture in den Buffer Speicher und offline lesen...).

Am besten mit einem PETSCII tauglichen Terminal im 40 Zeichen Modus connecten.

ASCII / ANSI ist leider noch Baustelle.... Das sieht von C*BASE emuliert leider suboptimal mal.

Es ist vollbracht. 3 Tage lange Files von SD2IEC auf SoftIEC kopieren.... kein Spaß.

Jedenfalls läuft ab heute mein BBS auf einem Ultimate64 Elite.

Neu mit dabei ist ein kombiniertes X- / Y-Modem Transferprotokoll, also X-ModemCRC, X-Modem1K und Y-Modem batch in einem.

Das alte X-Modem mit 1 Byte Checksum musste draußen bleiben, bzw. steht weiterhin als eigenständiges Protokoll bereit.

Alle anderen Protokolle wurden überarbeitet und zerschießen jetzt auch nicht mehr den Online-Timer. D.h. User mit Timelimit haben auch nach einem Filetransfer nicht wieder mehr Zeit als vorher.

Also neues Kommando im U/D Bereich ist "H" womit man die hottesten Files aus dem jeweiligen Directory sich anzeigen lassen kann. Also h15 zeigt die letzten 15 Files an (analog zum "Z" Kommando in anderen C*Base Versionen).

In den Libraries (Lib2) gibt es nun einen RSS Feed vom Forum64. Danke an emulaThor für die Unterstützung.

Autopause funktioniert nun auch in anderen Bereichen, wie Userlist, Libraries etc.

Mit Sicherheit habe ich jetzt irgendetwas wichtiges vergessen aufzuzählen. Die meisten Änderungen und vor allem Bugfixes sind eh "unter der Haube" und mehr für den SysOp und die Systemstabilität und für's U64 interessant.

Online Games sind leider noch nicht fertig geworden. Das ist eine der nächsten Baustellen.... Es gibt weiterhin noch viel zu tun.

Wenn jemand Lust hat PETSCII Bilder oder auch vor allem ASCII / ANSI Bilder für mein BBS zu machen, bitte meldet euch !

Y-Modem batch läuft nun und wird dieses Wochenende auf dem BBS einziehen zusammen mit ein paar weiteren Neuigkeiten....

Umsetzungen für andere C*BASE Mods sind bereits in Arbeit....

pcollins war so nett ein Video dazu aufzunehmen:

Y-Modem batch uploads auf dem Testsystem

Übrigens ist heute "Geburtstag". 3 Jahre ist das RaveolutionBBS nun wieder online.

Das Problem mit dem U64 Ultidos ist zum Glück schnell behoben worden.

Trotzdem würde mich nach wie vor brennend interessieren, ob IEEE-488 am U64 funktioniert.

Guckst du hier

Rat Look gibt's bei ebay .... hahaha

600+ $ + Versand/Zoll und "Unikat Beule".

Hallo zusammen,

ich würde evtl. gerne an meinem U64 ein IEEE-488 Interface anschließen um damit z.B. ein PetSD nutzen zu können. Beides habe ich noch nicht gekauft und möchte mich vorab hier erst einmal schlau machen.

Gibt es schon Erfahrungswerte, ob ein IEEE-488 generell am U64 funktioniert ? Bzw. gibt es Fallstricke worauf ich beim Kauf achten sollte. Oder kann ich die Idee komplett vergessen ?

Grund für die Frage: Ich suche nach einer Alternative für ein schnelles Laufwerk am U64, ohne SoftIEC zu nutzen (da mir das am BBS Probleme macht und auch aktuell nicht sonderlich schneller speichert als normal).

Wow... richtig gut geworden !

Da kommt so'n auch haben will Gefühl auf.

Irgendwie finde ich beim Directory vom SD2IEC nicht das Byte, wo die MOD 254 Info stehen soll.

Als Beispiel habe ich ein File, 10 Blocks groß, mit insgesamt $0914 (2324) Bytes (lädt von $0801 bis $1115).

Das File ist nicht in einem .Dxx Image sonders direkt auf der SD Karte.

Hier die Hardcopy wo das File noch in einem D64 Image ist:

Das Directory der SD Karte habe ich mal mit LOAD"$",8 geladen und dann als Datei mit SAVE"DIRECTOY",8 auf Disk gespeichert.

Diese Dir Liste sieht dann im DirMaster so aus:

Bei $08a1 beginnt der DIR Eintrag von o.g. File. Als Rest von MOD 254 müsste ich 38 Bytes haben also hex. 26.

Die sehe ich aber irgendwie leider nicht.

Hilfe ?!

Unseen :

Dann hab ich Dich und die Doku irgendwie missverstanden. Kannst Du mich erleuchten und ggf. 2 kleine Beispiel BASIC Code Zeilen schreiben, um zu zeigen wie es richtig geht ?

Oh cool. Und mit welchen Laufwerkstypen funktioniert das ?

Ich hatte gestern Abend wenig Glück, die Byteabfrage beim SD2IEC über das Directory zu ermitteln. In der SD2IEC Doku (von Unseen verlinkt) genannten Floppycommandos DI / DR / DW hatte ich gestern nicht ohne Floppy Errormeldung oder Absturz vom SD2IEC hinbekommen. Ggf. gehe ich da gleich nochmal ran, denn die Files Byte für Byte lesen mit SD2IEC ist arg langsam.