Posts by BladeRunner

Das feuchte Höschen hat sich gelohnt. Ich werde wochenlang nicht richtig ansprechbar sein. Perfektes Timing vorm Weihnachtslockdown.

Da der Kickstarter schon 2015 gescheitert ist, wohl eher bei Null

In diesem Fall wohl eher:
Veni, Vidi, VICE, (Ultimate, Chamaeleon, EasyFlash) ...

Ich finde es auch schön dass mit dieser eigentlich eher unbedarften Anfrage eine Lücke in den generellen Moduldefinitionen geschlossen werden konnte, denn das FunctionEprom kann man ja frei bestücken, auch mit eigenen Tools. Schön

Super, ich danke Dir! Da ich nicht wirklich die Sid-Emu benötige ist mir das recht gleich und ich bin gern bereit es davon zu testen.

EDIT: Schumi hat mir ein Kompilat des gepatchten Vice zukommen lassen, und darunter funktioniert das Modul absolut einwandfrei.

Ich muss einfach mal loswerden wie cool ich es finde: Von Fragestellung bis Lösung in so kurzer Zeit, per PM und hier in kurzer Zeit ein halbes Dutzend User die sich aktiv einbringen. Das ist einfach nur genial, Daumen hoch

Danke für den Tipp, hab ihn mal angeschrieben.

Hallo,
ich wollte die passenden Links eigentlich noch selbst posten, bin derzeit aber krankheitsbedingt nur begrenzt am Rechner.
Schumi / GroePaZ hat den Patch gestern in Windeseile erstellt. Wenn ich es richtig verstehe ist damit die Moduldefinition gepatcht, da anhand der Größe des Moduls entschieden wird ob ein Function-Eprom eingebaut ist oder nicht. Ein Praxistest steht noch aus, ich muss auf einen Vice-Build warten der die Änderungen enthälht, da ich nicht fähig bin das selbst zu builden.
Ich habe gestern auch noch MarkusC64 kontaktiert, er will die geänderte Modulerkennung auch in die Ultimate-Firmware einpflegen, kann wegen des Platzmangels auf dem FPGA aber nicht garantieren dass es dür die Version ohne + noch reicht. Ich hoffe sehr darauf, da ich eine ebensolche besitze, und das Modul macht ja vorallem Sinn wenn man die Experimentierschlatungen aus dem Buch an den Userport hängen kann.
Desweiteren hat Schumi auch schon gesagt er wolle sich ansehen ob der den passenden Support auch für's Chameleon integriert kriegt.

Ich bin hin und weg wie flott das gefunden, analysiert und gefixt wurde, und daher hier auch noch von mir ein ganz großes Danke an alle Beteiligten,
Vor allem Schumi und markusC64 für ihren programmiertechnischen Sachverstand und den Eifer den sie an den Tag gelegt haben.

Ich werde, sobald ich wieder etwas fitter bin, die kompletten Unterlagen zu der Buchreihe einscannen und die Diskimages , das gefixte CRT und die Bücher der Allgemeinheit in der Wolke zur Verfügung stellen.

Ich glaube dass da viel Potential für interessante Experimente drin steckt, vielleicht kann der ein oder andere sich damit noch ein paar Schöne Nachmittage machen

Wenn sich nun noch jemand findet der in der Lage ist die Amiga-Disks umzuwandeln: Perfekt.
Auch die Windowsversion von PAKMA werde ich noch hochladen, ich habe wie gesagt die volle Zustimmung des Rechteinhabers erhalten, was ich eine sehr noble Geste finde.

Edit:
Auch cool wäre wenn sich jemand der Leute die sich mit Easyflash auskennen vielleicht eine Easyflashversion erstellen könnte. Dann wäre so ziemlich jeder UseCase abgedeckt.
Das passende .crt / bin hänge ich schonmal an.

Beim erneuten Auslesen waren die Fehler augenscheinlich weg, vielleicht nur mangelhafter Kontakt eines Pins. Das Modul tut es eingesteckt ja auch.
Herr Professor Heuer hat mir sein gesamtes Material zur Verfügung gestellt. Er selbst nutzt die Sachen nicht mehr, er ist mittlerweile jenseits der 80 und geniesst seinen Ruhestand. Ich bin mehr als dankbar dass er auf meine Mails überhaupt geantwortet hat, aber ich möchte ihn jetzt nicht mit vielen Fragen Bombardieren, zumal das Grundmodul ja das von Commodore hergestellte und vertriebene Comal80 ist. Er war sehr freundlich in seiner Korrespondenz, erwähnte aber auch dass er aufgrund diverser Krankenhausaufenthalte nur begrenzt Zeit gehabt habe um mir zu antworten.
Und seine Bitte das Material nach Auslesen wieder zurück zu senden kann ich auch nur zu gut verstehen. Das ist de facto sein Lebenswerk was er über 20 Jahre und mehr aktiv entwickelt hat (Dem Paket lag auch eine PAKMA-Version für Windows bei).
Er hat ausdrücklich seine Genehmigung erteilt Scans und Diskettenimages zu veröffentlichen.
Das würde ich auch gern als lauffähiges Komplettpaket tun, aber dazu braucht es halt ein Image für EF/ Ultimate um alles nutzen zu können.
Die erste Version lief noch mit Simons Basic, auch dafür habe ich Literatur und Diskimages erhalten.

Im Anhang das ausgelesene Eprom, welches sich nach Ausbau übrigens als 64k herausgestellt hat (27c512).
Leider scheint es schon nicht mehr ganz intakt zu sein, ich werde noch einen zweiten Ausleseversuch starten. Ab $8000 sollte das zweite Programm liegen, da ist aber von $8010-801f nur FF drin, weshalb zB der Name des Autors zerstört ist. Mit ein bissel Glück betrifft es aber nur den Text und nichts vom Programm selbst.

EDIT: Wenn ich das Eprom entfernt habe und die Cartridge starte erhalte ich die normale Comal 2.01 Einschaltmeldung.

EDIT 2: Erneutes Auslesen hat den Fehler behoben, die Zeile ist da. ich hänge das auch mal an.

Das auslesen selbst ist kein Problem, das Reverse engineering der Platine schon, zumal ich nicht daran löten darf und somit viele Traces nur raten könnte. Mit der Implementation einer neuen crt-Definition wäre ich endgültig überfordert. Mein Ziel / Wunsch wäre aber in der Tat das Ganze per Easyflash oder Ultimate zum Laufen zu kriegen.
Wäre das Modul nicht eine Leihgabe würde ich es mit Freuden zur Analyse weiterreichen, ansonsten kann ich nur hoffen dass hier jemand das Comal80 Modul besitzt und bereit wäre es mit meiner .bin vom Eprom zu testen und vielleicht sein Modul zu analysieren.

noch nicht, das wollte ich aber heute abend noch angehen.
Was gegen deine These spricht ist die Tatsache dass ja schon das ComalModul selbst 64 KB groß ist, noch ohne das gesteckte Funktionseprom. So groß ist auch das .crt: 4 Bänke à 16KB. Das 32kb Eprom kommt ja noch dazu, ist aber in der .crt-Beschreibung bei unusedino nicht erwähnt.
Daher ja auch die Frage ob das überhaupt erweiterbar ist. Wenn man eine Websuche nach dem Comal80 Modul macht findet man auch Bilder vom "Stock"-Modul (zb hier: http://www.z80.eu/cartridges.html ), und da ist der Epromslot nicht bestückt.
Auf der site wird auch explizit erwähnt dass das Comal 2.01 ein 64kb Modul ist.
Die 32kB vom Eprom müssen also wohl separat eingeblendet werden. Ich hab es nicht wirklich mit Schaltungen und leider auch keinen Schaltplan gefunden, anhand dessen ich mir genauer erklären könnte wie das Eprom da drauf sattelt.

Habe mir das .crt mal genauer angesehen, dass sind nur die 64 kb des Comal80 Moduls, anscheinend wird auch kein eingesetztes Eprom mit angenommen.
Nun ist hier: http://unusedino.de/ec64/technical/formats/crt.html der aufbau des Moduls beschrieben, aber auch hier kein Hinweis auf die Erweiterung mit einem Eprom. Kann mir da irgendwer helfen? Besteht überhaupt die Möglichkeit einen Weiteren CHIP einzubinden. Die Adresslogik auf dem Modul hängt an einem demux an den Ausgängen B2 und B3, wobei B2 an der Programmierspannung des Eproms(?) anliegt und B3 am /CE, falls das irgendwas hilft.
Ich würde das Ding wirklich gern in digitaler Form für die Nachwelt archivieren, weiß aber halt leider nicht wie.

Hallo,
ich bin über einen freundlichen Kontakt an ein PAKMA-Modul gekommen.
Dieses ist wohl ein Comal80 Modul welches um Funktionssoftware in Form eines Eproms erweitert wurde. Leider darf ich das Modul nicht behalten, es ist die freundliche Leihgabe des Professors der es dereinst entwickelt hat und sein persönliches Exemplar, was er gerne wieder hätte.
Nun meine Fragestellung:
Es gibt ja das Comal-Modul als Easyflash-CRT. Ich könnte das Eprom auslesen, das ist kein Problem, gibt es nun eine Möglichkeit die Binärdaten in das CRT einzupflegen? Geht es per direkter Binärkopie in das Image hinein? Wenn ja, ab wo liegen die Daten des "normalen" Eproms in der CRT so dass ich sie überschreiben kann.
Ich darf leider nicht die anderen Bausteine auslöten um sie auszulesen, das Modul muss original bleiben.

PAKMA wäre sicher sehr interessant, ich habe auch die komplette Literatur dazu erhalten, die ich einscannen und hochladen möchte, sowei auch die Arbeitsdisketten die mitkamen.
Mir wurden auch PAKMA-Versionen für den Amiga geschickt, da bin ich allerdings noch nicht sicher wie ich die zu .adf wandeln kann.
Ich fänds sehr schade wenn diese Software verloren ginge.
Anbei ein paar Bilder von dem Modul. Interessant finde ich auch dass ich in der Commodore Bauteileliste die ROMS die auf dem Modul verbaut sind nicht gefunden habe. Gibt es davon schon binäre Abbilder? Lässt sich ein Eprom unter Umständen im eingebauten Zustand durch abgeifen der Pins auslesen? oder beschädige ich damit uU das Modul?

Cool, danke!
Wirst Du den Source auch veröffentlichen?

Nö, es hängt nicht vom Wert im Akku ab. Du weisst doch in dem Moment wo du den Code schreibst ob Du auf größer oder kleiner prüfen willst.
Und statt eines if a>b fügst Du in deinen Code dann halt ein if b<a ein und schwupp hast du eine Vergleichsoperation eingespart.
Der Code selbst ist ja unabhängig vom Wert der Später im Register steht.
Es muss einem halt nur beim Schreiben des Codes bewusst sein dass ein < einem > vorzuziehen ist.

Nope, wenn man es auf Assemblerebene betrachtet.
> : BPL +BNE
>=: BCS
< : BCC
<=:BMI
= : BEQ
<>:BNE

Alles ausm Kopf und ich bitte um Verzeihung wenn da was hakt, aber wenn ich es recht entsinne ist es in der Tat so dass der Vergleich auf Größer der einzige ist der zwei Vergleiche Benötigt, da hier gecheckt werden muss ob das Ergebnis nicht negativ ist und dann noch ob es ungleich null ist.
Das gilt natürlich nur für 65xx, andere Architekturen mögen andere Befehle haben, und lässt sich einfach umgehen indem man auf < prüft mit vertauschten Argumenten.

dann wäre meine Frage wann sie das erledigt? Zwischen den Sektoren?

Naja, wenn die Floppy mit 300 rpm dreht bedeutet dass dass der komplette Track 5 mal pro Sekunde am Schreibkopf ist. macht bei einer angenommenen Nutzlast von um die 8kb inklusive aller Header etc. 40kb/s die da durchflutschen. Ein einzelnes bit hat also 1/(8*40*1024) = ca. 3 ms zeit geschrieben zu werden, sprich 3 Zyklen der Floppy. So viel zeit ist das nicht um da nebenbei was anderes zu erledigen, oder?

Quote from M. J.

Desweiteren arbeiten moderne Schnellader so, daß während des Lesens der GCR-Daten von Diskette bereits eine Vordekodierung (also Umwandeln von GCR-Code in normale Bytes) vorgenommen wird. Mir ist zur Zeit kein Verfahren bekannt, daß analog dazu während des eigentlichen Schreibens die letzte Kodierung in GCR-Bytes vorgenommen wird.

Quote from M. J.

Gleichzeitig Routinen für schnelles Dekodieren (Lesen) und Kodieren (Schreiben) von Daten in den kleinen Speicher der Floppy reinzupacken, halte ich für schwierig.

Hm - und wenn man den Sektor jeweils schon im C64 auf GCR umrechnet und erst dann sendet, das sollte doch einiges bringen, oder?
Die Idee die mir da vorschwebt darf im Speicher des C64 durchaus ein paar KB belegen, da es ja um Nutzdaten ginge, nicht darum ein komplettes Speicherabbild zu sichern.

Und es sollte doch theoretisch auch nicht so viel Overhead sein vor der benötigten Operation (r/W) den passenden code für diesen Zweck in die Floppy zu laden, oder?

Bliebe noch die Sache mit dem Interleave, da ist sicher nicht viel zu machen. Und der Speicher der 1541 ist da auch ein Problem. Wenn aber die Daten ja als steter vorcodierter Stream ankämen sollte auch das wieder zu vernachlässigen sein, oder?

Ein kompletter Track mit 21 Sektoren hätte GCR-Codiert 6720 Byte (21sec*256byte*10bit)/8bit, das würde zB unter das Kernal passen. Ich weiss jetzt nicht wie die Floppy die Daten Zwischen den Sektoren einpflegt, ob das automatisiert geschieht oder auch in Software, aber dann könnte man diese Nutzdaten nötigenfalls auch ncoh mit in den Speicher packen und direkt senden. Ich bin leider technisch nicht sehr versiert und habe keine Ahnung ob ich da was übersehe, aber so sollte doch zumindest der Floppyinterne Flaschenhals (GCR-Kodierung) umgangen werden können. Und wenn man dann noch wie weiter oben angeführt einen anderen Handshake für die Übermittlung nimmt müsste man doch theoretisch am Stück übertragen können bis der komplette Track geschrieben ist, oder habe ich da einen Denkfehler?

Wenn du der Floppy nicht aktiv mitteilst dass sie in den 41er Modus umschalten soll wird sie beim booten am c128 im 71er Modus starten und darin auch beim umschalten auf den C64 bleiben.
Den Beweis hat MacB ja schon angetreten, bei ihm läuft es problemfrei.

Die Floppy schaltet nur bei einem Hardreset um, oder wenn sie explizit dazu angewiesen wird, was aber beim autobooten des c128 in den c64 Modus nicht geschieht.

Quote from Vm

Also ich kann im x64sc.exe 1571 einstellen, allerdings ist sie danach definitiv im falschen Modus. Mit LOAD"NEW",8 und RUN startet TT64 über dieses Basicprogrämmchen einwandfrei.

Finde den Fehler: x64sc.exe ist *nicht* der c128...

Danke schon mal für eure Antworten, ich werde damit mal ein bissel experimentieren.
Es gibt keinen akuten Anlass, es ist mehr akademisches Interesse. Die Speedloader sind ja weit verbreitet, es war mir nur aufgefallen dass kaum jemand versucht hat ein wirklich schnelles save zu implementieren, und da stellte sich mir die Frage ob es da Limitierungen gibt die bei einem Fastloader nicht existieren. Grade der o.g. Mafiosinolader ist ja einfach schweineschnell, und wenn man das mit einem Tracksave ähnlicher Güte kombinieren könnte hätte man eine interessante Möglichkeit on the fly größere Datenmengen zu bearbeiten. Da braucht es halt beides in schnell, laden wie speichern.