Posts from daybyter in thread "Heute so gecodet..."

Quote from drazil

Hört sich interessant an

Ist heute weniger interessant. Gibt Platinen bei ebay, um sowas zu bauen. Oder ein Adapter-Projekt für den TL866. Möchte mein Projekt aber halt fertig machen.

Heute gecoded: ne Menge Testprogramme für den Attiny2313, um zu verstehen, warum die nicht bei mir tun. So ganz langsam steig ich dahinter. Die Fuses von meinen Attinys waren auf 0,5 MHz Takt gesetzt. Hab ich mal auf 4 MHz korrigiert. Die Pin-Namen in dem AttinyCore für Arduino sind anscheinend falsch gesetzt? Als ich angefangen hab, mal die Ports direkt zu setzen, hat sich an den Pins was getan. Anscheinend sind die Defines in den Includes irgendwie falsch? Jetzt versuche ich was per Seriellem Port auszugeben, was noch nicht klappt. Entweder ist der Pin für den Seriellen TX auch falsch definiert (wäre schlecht), weil man den in der Hardware ja nicht ändern kann, oder die Lib kommt mit den 4 MHz nicht klar. Das teste ich in den nächsten Tagen weiter...

Quote from drazil

daybyter . Was hast du dann am Ende damit vor? Oder dient das nur zum reinen Technikverständnis?

Ich brauche diese Software für einen selbstgebastelten Eprommer für mcm 68766 Eproms. Die sind u.a. pinkompatibel mit c64 Roms. Brauchen aber 25 Volt zum Brennen, was ohne Tricks mit günstigen Brennern wie dem TL866 nicht geht. Deshalb eine Arduino Lösung.

Versuche Eprommer Software zu verkleinern, damit in einen Atmega 168p passt. Heute knapp 1kb Code und 200 Byte Daten gespart. So langsam wird es. Wobei es noch interssant wird, wenn Epromdaten übertragen werden. Die müssen in den dynamischen Speicher passen.

Quote from Diddl

Ich hab mal vor vielen Jahren was gemacht mit den Tiny 2313.
Vielleicht kannst du was abschauen was dir hilft ...

Please login to see this link.

Danke, aber eigentlich hatte ich ja meine Software schon. Aber der Controller lässt ja anscheinend keinerlei Code laufen. Morgen werd ich wohl mal paar Zeilen Assembler schreiben, einen Chip auf ein Steckbrett stecken und eine LED blinken lassen. Das muss ich erstmal ans Laufen bringen, um die Probleme zu verstehen. Im Moment geht ja nicht mal das Togglen der GPIO Pins.

Aber vielen Dank!

Testprogramme für Attiny2313 . Hab jetzt einen Stapel von den Dingern hier und keines mag ein Programm ausführen. Versuch das inzwischen auf das Minimum zu reduzieren um zu verstehen, wo es klemmt.

Die Dinger sind wohl ausgelötet, weil die Zinnreste an den Beinchen sonst keinen Sinn machen. Fuses waren seltsam gesetzt, aber das sollte behoben sein.

Versuch das momentan in C, aber vielleicht braucht es doch Assembler.

Ich versuche gerade die Ausgabe einer Pipelinestage meiner CPU so umzuleiten, dass ich 2 Befehle hintereinander abarbeiten kann, auch wenn der 2. Befehl das Ergebnis des 1. Befehls verwendet.

Hoffentlich bekomm ich vor dem Platzen noch so ein Projekt wo man 100k im Monat bekommt.

Die ganze Nacht KI Modell trainiert. So alle 2 Stunden geguckt, wie weit der Laptop ist. Erst heute Morgen 6:30 war er durch und dann kam ein Fehler in der Auswerte-Funktion. Verstehe jetzt, warum die KI-Entwickler soviel Geld bekommen.

Vielleicht haben hier auch einige diese Kolumne gelesen...

Please login to see this link.

RIP

Meinen ersten eigenen Code für ein PyTorch Projekt ans Laufen gebracht. Eigentlich nur den Teil wirklich neu geschrieben, der csv Daten in das Pandas DataFrame Format konvertiert, wie es yfinance liefert.

Es ist wirklich eine ganz neue Art von Programmieren für mich, wenn man keinen Algorithmus vorgibt, sondern dem System nur Daten gibt und eine Funktion, die den Fehler berechnet. Ab da muss das System selbst einen Lösungsweg finden.

Hab gelernt, dass mein Laptop nicht gut für KI ist, und man doch so eine Grafikkarte mit Cuda haben sollte, wenn es komplexer wird. Aber ich lerne ja noch.

Ich würde mal versuchen mindestens 1 Thread mehr zu benutzen. Bei Make wurden damals sogar 2*Kerne+1 empfohlen. Ich denke Du hast Einbrüche, wenn ein Thread fertig ist, und die Daten für den nächsten Thread aufgesetzt werden. Da hast Du dann wohl Aussetzer.

Ach ja: wie ist die Speicherauslastung? Kannst Du da evtl Rechenzeit gegen Speicher tauschen?

Oh man...peinlich...der Mann heisst natürlich John Carmack. Nicht Jahn...

So....u.a. bisserl weitergecoded an dem Plexer. Heute hab ich angefangen, eine Idee umzusetzen, an der ich schon eine Weile brüte. Und zwar hab ich mal in einem Jahn Carmack Interview gehört, dass sie auf dem Apple 2 die Sprites nicht an den Zielort kopiert haben, sondern das Sprite mit einem Programm gemalt wurde, weil das schneller war.

Diese Idee wollte ich auch für meine virtuellen VICs verwenden, indem ich den Code zum Kopieren der VIC Register einfach mit in die Struktur mit den VIC Daten packe. Ich hab das jetzt mal als ca65 Macro gelöst, indem ich also eine Abfolge von

lda Please login to see this link.

sta $d001

lda Please login to see this link.

sta $d003

lda Please login to see this link.

sta #d005

... usw hab.

Jeder der Please login to see this link. Werte wird überschrieben mit dem Wert des jeweiligen VIC Registers. Dafür hab ich mir einige C-Funktionen zum Testen geschrieben. Im Raster IRQ wird dann einfach die Adresse der Struktur eingetragen, und der virtuelle VIC kopiert sich in den physikalischen VIC. Der Hauptvorteil ist die Ersparnis von einem Taktzyklus pro Registerwert, weil man halt nicht mehr

lda <virtueller VIC Register Adr>

sta <physikalisches Register Adr>

machen muss, sondern

lda #<wert>

sta <physikalisches Register Adr>

machen kann.

Im Moment seh ich mal wieder nur 2 Reihen Sprites auf dem Bildschirm, aber das Timing ist jetzt halt auch etwas anders, und mein Code ist nicht wirklich getestet. Braucht halt noch einiges an Arbeit.

Mein Ansatz ist ja viel einfacher als eure Multiplexer, wo man x Sprites wahlfrei positionieren kann. Ich habe den Bildschirm vertikal einfach in Bereiche unterteilt und habe quasi einen virtuellen VIC für jeden Bereich. Wenn der Rasterstrahl den Bereich erreicht hat, werden die Register des virtuellen VIC in den physikalischen VIC kopiert.

Was ich programmieren möchte ist ja so ein ganz einfacher Shooter. Das Raumschiff des Spielers ist im unteren Bereich, die Feinde sind im oberen Bereich, so dass diese 2 Bereiche sich nie überlappen werden. Nur die Schüsse sollen von unten nach oben fliegen und kommen daher in beide Bereiche.

Ist nur so ein kleines Spassprojekt, um ein wenig c64 coden zu können.

Wenn ich mal mehr Zeit hab, muss ich mal wieder Software Sprites coden. Ich find das spannend. Aber gerade freu ich mich, dass ich 3 Reihen mit 8 Sprites sehe...

Dieser Artikel war sehr hilfreich:

Please login to see this link.

Damit hab ich nämlich verstanden, dass ich die Y Koordinate zu spät gesetzt hab. Muss auch mal konsequent die Taktzyklen in meinem Code zählen.

Aber das wird mit den Jahren schon noch werden...

Bisserl weiter gemacht am Multiplexer und da passieren Sachen die ich nur staunend beobachten kann.

Ich hab jetzt 3x 8 Sprites übereinander angezeigt und die ersten 2 Reihen werden nicht immer angezeigt. Wenn ich nun aber die 3. Reihe horizontal auseinander ziehe, also den Abstand zwischen den Sprites erhöhe, tauchen plötzlich die Sprites darüber teilweise auf.

Da muss ich noch einiges lernen, bis ich durch den Code steige.

Das hört sich spannend an. Du bist wohl viel weiter als ich. Ich kerne jeden Tag etwas neues dazu.

Ich bastel gelegentlich an einem Ballerspiel und brauch mehr als 8 Sprites für die Gegner und Schüsse.

Ist für c64 in cc65 und Asm geschrieben.

Weiter an meinem 1. Sprite Multiplexer gecoded. Das Thema ist wirklich nicht so ganz trivial. Zumindest nicht für alte Leute.

Bastle ja immer wieder mal an einem Schiessspiel in C und ASM und hab mal angefangen meinen Gegnern ein ganz klein wenig Intelligenz einzuhauchen. Im Moment hauen sie eigentlich nur ab, was wohl clever aber auch langweilig ist. Das muss besser werden. Hab aber festgestellt, dass es gar nicht so einfach ist ChatGPT in so 50 Zeilen 6502 Assembler nachzuprogrammieren...