Posts by mc71

Ich würde es anders formulieren: Man _kann_ keine Lücken in der Datei haben, weil das Kernal keine Idee davon hat wie es damit umgehen soll. Es gibt ja außer Startadresse und Dateilänge auch keinerlei Informationen über die einzelnen Blöcke in der erstellten Datei. Lösung, wie gesagt: Den Programmblock beim Start selbst an die gewünschte Stelle kopieren; ich bilde mir sogar ein, daß manche Cruncher-Tools das automatisieren können, wenn man ihnen mehrere Binärdateien verfüttert.

Bonuspunkte gibt es, wenn der Startcode beim erneuten Aufruf erkennt, daß er schon kopiert hat und ein weiterer Kopierdurchgang zu Datenverlust führt.

Here we go:

Drei Seiten in 300 dpi als TIFF in Fax-Kompression für erträgliche Dateigrößen. Die Seiten sind bis auf die Screenshots eh sw-LineArt, aber ich brauche die hohe Auflösung, weil das Listing fünfspaltig(!) abgedruckt ist. Die Screenshots und die paar Zeilen mit Bildschirm-Steuercodes kann ich mir bei Bedarf gerne nochmal ansehen, ob das der Scanner geschreddert hat oder ob das schon im Druck Matschebrei war...

Die paar Listing-Zeilen auf der ersten Seite oben gehören zum vorherigen Artikel, aber ich hab's einfach mal dringelassen.

(Ich hatte ja was zu 74-TTL und 4000-CMOS erwartet, aber 'jede Stunde, jede Klasse' tut auch. Und: Der 84er-Jahrgang der ELO stand eh auf meiner Jagdliste fürs Osterkörbchen, mein erstes Heft von 'damals' war nämlich erst die 11/84 mit dem C64-Voltmeter. Reiner Zufall, daß die Anfrage hier so gut dazu paßt...)

Heft ist gerade angekommen, die fraglichen Seiten sind vorhanden- ich werfe es nachher gleich auf den Scanner. Zum Glück hat die ELO normales A4-Format, anders als die Sonderhefte.

Quote from Claus

da man den naturgemäß extrem schlecht zu lesenden Maschinencode bis ins letzte Detail verstehen muss.

Die Interpreter sind ziemlich gut zu lesen- ich spreche sowohl Z80 als auch 6502 fließend, und es gibt hervorragend kommentierte ROM-Listings. Aber Maschinensprache funktioniert so völlig anders als Python oder C, daß eine 1:1 Umsetzung eher geradebrechten Code ergäbe und man besser einen Interpreter für den jeweiligen Assemblercode schreibt. Und das, was da hinten raus kommt, muß dann auch eerstmal vom 'Grafikspeicher' auf SQL oder whatever umgesetzt werden. Erst recht beim C64, der Grafik und Sound mit PEEK und POKE eröedigt.

Aber moment mal, das alles gibt es ja schon mit VICE und Z80.EXE (oder was die Kids heute dafür nehmen)

Also ja: man kann es machen, aber man würde es nicht machen, weil es kein gutes Ergebnis bringt. Ein halbwegs guter Emulator ist übrigens deutlich mehr 'Strafarbeit', aber kann halt auch wesentlich mehr.

Schau Dir mal SmallBASIC an:

https://smallbasic.github.io/

https://sourceforge.net/projects/smallbasic/

Kommt, glaube ich, mehr aus der Spectrum-Ecke und hat inzwischen einige Tricks dazugelernt, die es damals noch nicht gab (ebenso wie die Rechner, auf denen es läuft), aber das 'Feeling' ist geblieben.

Das war eine Sonderbauform nach Kundenwunsch, die auch nach dem Ende von Commodore niemand aufgegriffen hat. Kupplungen, wie Du sie suchst, hat es nie gegeben.

Bei 40/80poligen IDE-Kabeln hätte ich auf 'codierte' Stecker getippt und einfach mal beide Adapter auf 'Master' gesetzt.

DOM waren keine SSD, das war 'nacktes' Flash mit IDE-Stecker; ohne Treiber fürs Defekt-Management und Wear-Leveling waren die unbrauchbar, ohne gepatchtes BIOS konnte man davon nichtmal booten. Gab es auch als DOC 'Disc on Chip' für den ROM-Sockel.

Quote from 64erGrufti

bei alten Elkos bis 70er/80er war das nicht so. Deren Werte passten sogar heute noch.

Hier lauert eine fiese Falle: Wenn ein Elko elektrisch 'leckt' (also einen hochohmigen Widerstand zwischen den beiden Platten aufweist und keine Ladung mehr dauerhaft halten kann), dann stört das viele Meßgeräte derart, daß sie eine zu hohe Kapazität angeben. Der Elko ist dann nicht 'besser als neu', sondern Carport und allenfalls durch eine Neu-Formierung zu retten. Also immer auch den Leckstrom bestimmen!

14-Segment-LED taugen nur sehr eingeschränkt als Ersatz für die 12-Segment-Panaplexe: bei letzteren ist der obere und untere Querbalken in zwei Teile geteilt, bei ersteren nicht. Für ein lesbares Display müßte man also den ganzen 'Zeichensatz' neu stricken.

Zur Strombuchse: Ich meine mich an ein erstaunlich kleines 'sti-no' (stinknormales) AC-Netzteil zu erinnern, und mit dem roten Knopf verpasst man dem Ding einen General-Reset inklusive Löschen aller Daten, z.B. wenn er sich beim Wechsel der Stromausfall-Überbrückungs-Batterien verhaspelt hat... leider will mein Exemplar derzeit nicht gefunden werden. Von daher kann ich noch nichtmal sagen, ob ich neben der Bedienungsanleitung auch irgend einen brauchbaren Schaltplan habe/hatte; die Ebay-Anzeige redete damals aber tatsächlich auch von einem geplanten Umbau zum 'Junior-Computer' (Reality-Check: Nein. Nicht wirklich. Die Geräte sind einfach _zu_ verschieden.

Zur PIA: Die gab es tatsächlich neben den gängigen Varianten 6821 (Motorola) und 6520 (MOS) auch als 6820 (das Ur-Modell) und 6521. Es gibt Unterschiede im Detail, die einen Austausch gegen einander verhindern können, aber im Prinzip ist das viermal der gleiche Chip.

Der immer wieder genannte Z80 steckte übrigens im Nachfolgemodell CTI 1008, mit 50% mehr Tasten, einem größeren und eleganteren Gehäuse aus einem durchgehenden weißen Blech zwischen den Holz-Seitenwangen anstelle der Alu-Profile, und einem Endlosband-Kassettenlaufwerk als Datenspeicher anstelle des Batterie-Packs (das im Bedarfsfall stets leer gewesen sein dürfte). Sieht dem 2000er tatsächlich etwas ähnlich, wenn man nicht allzu genau hinschaut...

Quote from tux64

Suche hier Programmierer, die

Hallo!

Thema dieses Threads ist "Ist es möglich eine Blockprogrammierung für C64-BASIC zu erstellen?" Für die Suche nach Programmierern mach bitte ein neues Thema auf.

Außerdem möchte ich Unseens Einwand nochmal aufgreifen: Soll der User das erzeugte BASIC-Programm jemals lesen und verstehen können, oder geht es 'nur' um das Programmieren an sich?

_Rechnen_ kann ich das auch locker im Kopf. Nur für die Zwischenergebnisse hätte ich dann doch gern ein Blatt Papier und 'nen Bleistift, bitte danke...

Quote from TurboMicha

Wat ist "WANT SIN" ?

(falls das noch jemand interessiert...?)

Der Interpreter will wissen, ob Du die trigonometrischen Funktionen wie SINus etc. haben willst. Antworte mit Y für yes oder N für no. Wenn nicht, gibt er einige wertvolle RAM-Bytes frei. Das konnte einem schonmal die Anschaffung einer weiteren 4K Memory Card ersparen, die anfangs durchaus einige schmerzhafte Hundert-Dollar-Scheine kostete.

Danach kommen je nach BASIC-Version noch mehr solcher Spar-Optionen, bis hin zur Abschaltung der ganzen Gleitkomma-Rechnung. Und natürlich sollte man ein derart gekürztes BASIC wieder auf Lochstreifen stanzen, damit man die nicht gebrauchten Routinen gar nicht erst laden muß. Denn die Kisten hatten ursprünglich ja bestenfalls einen ausgemusterten Fernschreiber oder einen Kassettenrecorder als Massenspeicher... Diskettenlauferke waren durchaus erhältlich, aber für die meisten Hobbyisten unerschwinglich.

Nein.

Das Programm ist auf Verständlichkeit getrimmt, nicht auf Tempo.

Der Rippen-Backstein kam erst nach Produktionsende des VC20 raus; die schwarzen stammen m.W.n. aus der Nachproduktion von Plus/4 aus 1987/88 (als die 'Lernpakete' bei Aldi, Kaufhof und Co. unerwartet erfolgreich waren)

Die 'Tütkeile' für C64 und VC20-cr waren von Anfang an C64-hellgrau-farben. Es gab allerdings in 1982 und nur für USA eine erste Serie C64-Netzteile im verschraubten schwarzen Gehäuse (ähnlich dem alten zweipoligen VC20-Netzteil). Vorteil: Die lassen sich leicht reparieren. Nachteil: Die gehen sehr schnell kaputt und grillen dabei den Rechner- weswegen sie schon damals den Spotznamen 'black brick of death' weg hatten... die haben aber mit der gerippten vergossenen Versiom nix gemein.

Fun Fact: Commodore hat die Artikelnummer nie geändert, weder für die schwarzen Türkeile aus 1984 noch für die 87er Rippenquader, egal ob runder oder quadratischer Stecker. Daher die Verwirrung.

Fun Fact 2: Was wir 'C64-Netzteil' nennen wurde tatsächlich für die überarbeitete 'cost reduced' Version des VC20 konstruiert- knapp drei Monate bevor der C64 überhaupt 'erfunden' wurde...

Quote from Unseen

Der DIN-Stecker sieht eher nach Atari ST aus.

Yep. I third that. Obwohl... einige Atari-PCs hatten auch diesen Floppy-Stecker...

Quote from xp1313

wie es innen aussieht,

Vermutlich (aus Erfahrung mit anderen externen Floppys): ein Trafo, zwei Spannungsregler, zwei Standard-Diskettenlaufwerke und ein Stück Platine, das das Datenkabel auf den Shugart-Bus umverteilt. Elektronik: wahrscheinlich keine. Und die beiden Schalter fummeln nur ein wenig mit den Drive Select Pins herum.

Meist hat es bei den Dingern noch nichtmal für ein Schaltnetzteil gereicht.

Radio Eriwan sagt: Im Prinzip ja, aber...

- die Schleife wird 16mal ($10-mal) durchlaufen (Zähler in $fb)

- der Vektor steht dann auf $1e00, der letzte Wert von der Floppy steht in $1dff.

Klar ist das in diesem Fall Erbsenzählerei, aber genau solche Ungenauigkeiten verzeiht ein Computer nicht.

In der Zeile unmittelbar vorher?

ldy #0 lädt eine Null ins y-Register; in Zeilen 29-31 wird y um eins hochgezählt und solange 'geschleift' bis y auf $20 steht. Die Werte landen also in 1c00...1c1f. Zuletzt wird noch der Vektor $fe/$ff um $20 erhöht für den nächsten Durchgang (wo y wieder bei 0 beginnt)

Oh wie hübsch. Ein Spectrum-Emulator!

Die FBAS-Mischerstufe im Modulator macht so viele Farbreste daß ich am 1084 fast stabiles Farbbild aus Luma bekomme... vgl. 'Modulator rauswerfen'-Thread.

Der Zeichensatz steht im normalen OS-ROM mit drin. Beim XL und XE gibts sogar einen zweiten 'internationalen' mit Umlauten usw.

Der vom 5200 sollte passen- sieht plausibel aus, hab's aber nicht auf Detail-Änderungen geprüft.