Hi
MKloader kenne ich jetzt nicht.
Aber die Homepage vom FE3 ist da:
https://oe7twj.at/index.php?title=Final_Expansion_3
Fragen zu den LOADER Dateien kann ich auch beantworten, falls dann noch Fragen offen sind ... 
Posts by Diddl
-
-
Es gibt Multikernal, wo die Auswahl des Kernal mit der RESTORE Taste läuft, die zweifarbige LED unterstützen.
Dann kannst du die LED sinnvoll nutzen in deinem C64 ...
-
Sowas gibt es fertig, nennt sich FiFo, z.b. AM7201, da sind dann gleich ein paar Byte (512) mehr als "Puffer" mit drin...
Der Clou ist die einfache Ansprache vom C64 aus.
Bei dem AM7201 müsste man da schon etwas tiefer in die Trickkiste greifen.
Und es dient auch, meine CPLD Kenntnisse zu trainieren.
Aber ziemlich cool das Teil, danke für den Tipp!
-
Wasn datt ?
ATF Testplatine ?
... die in einen C64 gesteckt wird und Folgendes macht:...
Von allem ein bisschen ...
... bisher war das seit Wochen ein Sauhaufen aus Drähte, Lochraster und Steckboard -- nun etwas kompakter
Was kann man damit tun (allgemein):
- ja genau - ATF Testplatine - Prototyp - Logik Entwicklung (das 8Bit Baby gibts ja leider nicht mehr)
- man kann damit einfach neue Dinge entwickeln und testen (CPLD -- C64)
Im Speziellen ist es aber ein Highspeed Datenkanal:
- Verbindung zu einem anderen Computer System (in meinem Fall ein Arduino)
- Kommunikation parallel (8 Datenleitungen, 2 Handshake)
- alternativ geht auch SPI, aber das ist für alte Systeme weniger geeignet
- es wäre auch eine Alternative Anschlussmöglichkeit für ein WiC64
Naja, wie der Userport, was ist der Unterschied:
- bidirektional -- zumindest aus Sicht des C64
- Handshake erfolgt automatisch (der CPLD macht das)
- jedes System weiß, ob das andere System die Daten abgeholt hat
Technisch gesehen sind es zwei Buffer Bytes (Empfangsbuffer, Sendebuffer) und zwei Flags, ob die Buffer leer sind oder befüllt.
Wenn der C64 ein Datenbyte liest, wird automatisch das Empfangs Flag gelöscht (Empfangs Buffer leer).
Wenn der C64 ein Datenbyte schreibt, wird automatisch das Sende Flag gesetzt (Sende Buffer befüllt).
Die Flags können vom C64 gelesen werden.
Es kann ein IRQ ausgelöst werden, wenn der Sendebuffer leer ist oder der Empfangsbuffer voll (ist aber sinnlos, weil langsam durch IRQ overhead).
Das andere System kann alles sein:
- zb. win (spezielles) WiC64
- ein beliebiger Prozessor (Z80, 6809, ein anderer 6502, ...)
- ein Controller (Atmel, Arduino, ...)
- ein Homecomputer
- ein USB Shield (FT232H)
Aus Sicht des C64 ist die Kommunikation einfach ein Schreib- (POKE) oder Lesebefehl (PEEK).
-
Platine ...
-
Ich hab mir jetzt auch einen Adapter bestellt.... gut Ding will Weile haben oder wie heißt es.
Ich auch.
Da ich mit dem Gedanken spiele, die FLASH und das SRAM auch in SMD zu machen, habe ich mir diese (und einige andere) Adapter bestellt für meinen T56.
TQFP, PQFP, SOP-44, TSOP-48, TSOP-56, bessere PLCC
BGA brauch ich (noch) nicht ...
-
Das Seltsame ist, dass es SMD-Sockel für SOP16 gibt, aber SOP20... nix nada..
Aber es gibt den 16v8 auch in PLCC, hab ich da und auch die Sockel.
Beinahe hätte ich die 1.5 mit dem gemacht.
-
Das Problem mit dem ATF16V8 in SMD liegt hauptsächlich in der Entwicklung
Ja!
Genau diese Sorge hatte ich auch.
Ich habe mit mir gehadert und überlegt, sinniert, ob ich mir einen DIL Sockel anlöten soll mit 20 Drähte.
Aber die Faulheit hat gesiegt.
GAL Logik eingetippt.
Jedec generiert.
Jedec Programmiert
GAL eingelötet, und ...
... hat auf Anhieb funktioniert.
Glück gehabt, ist nicht häufig so (bei mir).
-
aber nicht ohne Adapter.... hmpf -
Die kosten nur ein paar Euros:
https://de.aliexpress.com/item/32923571704.html?
Meiner sieht exakt gleich aus.
Damals hätte es den T56 mit und ohne Adapter gegeben.
Hab die Adapter auch genommen ohne zu wissen, dass ich sie mal brauchen würde.
-
Wieso 48 Pin?
Welche 48 Pin?
-
Welche Package-Form hat der ATF16v8 IC ?
Ich denke es ist wohl SO-20
https://www.reichelt.de/at/de/…16v8bql15-su-p291742.html?
Wie hast du den geflasht, wieder mit fliegender Verdrahtung?
Mein T56 hat einen SOP Adapter, da passt das rein und lässt sich testen und beschreiben.
Derselbe Adapter funktioniert auch zum testen der LS-273 D-Latch. (SO-16).
Du bist einfach zu schnell mit deinen Weiterentwicklungen
, da komme ich gar nicht mehr hinterher.Schau mal, Magic Flash mit 1 MB ...
-
Sieht gut aus!
Wenn Sie de für SMD entscheidet, bitte wisst, dass es 74x16273 (Chip 273 in einem Chip) gibt. Es kann immer noch sinnvoll sein, zwei 74x273 zu verwenden, da eine 273 in der Regel weniger als die Hälfte einer 16273 kostet, aber es spart Platz auf deiner Cartridge.
Danke, ich wusste gar nichts von diesem 16 Bit D-Latch.
-
Hab die UC-1.5 SMD nochmal optimiert:
- standardmäßig laufen EPROM der Typen: W27C010, W27C020, W27E040
- über Brücken kann man nun auch FLASH Speicher nutzen: AM29F040
- über weitere Brücken kann man A19 auf Pin 1 legen und damit 1MB adressieren: 27C080
-
Universelle Magic Cart umdesigned auf SMD - TTL und 1 MB Chips (27C080).
Im Prinzip wie die Marina 64 nur gehen auch Flash Speicher.
Magic Cart kompatibel:
- 27C512
- 27C010
- 27C020
- 27C040
- 27C080
- 29F010
- 29F020
- 29F040
- Magic Lock wählbar
-
Mal sehen ob ich eine UC-1.5 Platine mit SOT-28 hin bekomme.
Eigentlich lohnt sich das nicht.
SOP28 to DIP Adapter und gut.
-
Ich sehe gerade, die SRAM mit 32K in SMD (SOT-28) kosten ja fast nichts: 60 Cent!
Da hat es natürlich im Bestellfinger gejuckt ...
Mal sehen ob ich eine UC-1.5 Platine mit SOT-28 hin bekomme.
Von der Löterei her müsste das eigentlich auch gehen, -für mich.
-
Coole Sache, gefaällt mir.
Schade dass die Anzahl der BASIC Token so beschränkt ist.
Sonst könnte man, die passende Modul Hardware vorausgesetzt, beliebig viele Befehle hinzu fügen.
Das Modul müsste natürlich banking beherrschen und sich unsichtbar machen können.
So hätte man dann die ganzen 38K RAM für BASIC und auch die üblichen Bereiche ($C000) wieder frei.
Theoretisch, wenn es flexibel gemacht ist, könnte man ein oder mehrere Befehle als Modul sehen.
Die Befehlserweiterung Module könnte man automatisiert zusammen stellen.
Jeder könnte sich dann "sein persönliches" BASIC zusammenstellen.
-
Ngngng wäääh
strik : Kann ich den Bootloader auch für das Xum1541 nutzen?
Die USB Controller brauchen das nicht, die haben von Haus aus einen Bootloader ...
-
XUM 1541 und XU15.41 sind zwei völlig unterschiedliche Geräte.
Das hast du richtig in Erinnerung.
Das XUM verwendet einen Atmel Controller der hardwareseitig mit USB kann.
Der kann vollumfänglich mit OpenCBM inklusive Burst Modus und Nibble Copy.
Das XU verwendet einen Atmega der am USB Bus Bit banging macht.
Da gehen nur die grundsätzlichen Dinge.
Technisch völlig unsinnig da wegen ein paar Euro zu sparen.
-
Ach, da habe ich vollstes Vertrauen!
Gut, ich sende dir die Dateien gleich heute Abend nach der Arbeit.
