Diddl, hast Du zufällig ein testbares Release des UCBuilder in der Veriosn 1.13?
Leider nein.
Das Wetter ist zu gut.
Und das Motorrad schreit zu laut um Aufmerksamkeit.
Aber du bist der erste der eine neue Version kriegt! 
Posts by Diddl
-
-
Der UC-Builder v1.13 kommt so langsam in Fahrt.
Neu:
- neue Cartridge Type: Hucky-64 - Typ 7 - Option --H64
- neue Datei Type: UCF File
- UC Image Dumper (generiert UCF Dateien aus einer Image Datei)
Ein UCF File ist quasi alles, was hinter einem Menüpunkt im UC-Menü steht:
- Programm Name
- Hilfetexte
- Start Option
- Load Option
- Cartridge Einstellung beim Start
- das Programm selbst
Das UCF File beinhaltet alles was der UC Loader braucht um das Programm zu starten.
Der UC-FB wird UCF Files auch direkt von Floppy Disk oder SD starten können, genau so wie die CRT Dateien.
In einem CSV File kann man UCF Dateien genauso einfach einbinden wie CRT Dateien.
Der Name kann, muss aber nicht geändert werden.
Das reduziert eine CSV Zeile zu:
-; UCF; Pfad\Datei.UCF
Display MoreCode- /* ---- UCF File Header ----
- Bytes: $0000-000F - 16-byte signature "UCF FILE" (padded with space characters)
- 0010-0011 - File header length low/high Byte format
- 0012-0013 - UCF File version (high/low, presently 01.01)
- 0014-0016 - File length - 24 Bit - low/high Byte format
- 0017-0018 - Load address - low/high Byte format
- 0019 - startType: - 1=RESET, 2=RUN, 3=SYS, 4=READY
- 001A-001B - Start address - low/high Byte format
- 001C - count of menu help lines
- 001D - Load Type: - 1=LOAD, 2=URAM, 3=UROM, 4=XROM
- 001E - Cartridge Config Byte (UC format)
- 001F - filler
- 0020-00xx - Menu Name\0, Menu Help1\0, Menu Help2\0, Menu Help3\0
- 00yy-zzzz - content
- */
-
Bin mal gespannt, wann die Mitsumi Köpfe so selten werden, das die Preise ins Bodenlose dafür schiessen
Glaube ich eigentlich nicht.
Die Bedeutung von Floppy Laufwerke hat sich relativiert.
Es gibt schon so viele Ersatzlösungen die perfekt funktionieren ...
-
Dann wird es auch im nächsten Update in der GUI unterstützt!
Ich bleibe für meine Freunde von der Win10-Opposition auch erstmal weiter auf dem .NET 4.5.2
früher konnte man bei den Microsoft Compilern sagen, ob man mit oder ohne Runtime compilieren möchte.
Ohne Runtime war zwar viel größer, aber man musste nie die passende Runtime installieren.
Geht das heute mit dem .Net Zeugs nicht mehr?
--
Da lobe ich mir Pelles-C.
Ein kleines EXE, ein einziges File und es läuft von Win-XP bis Win-10 ohne irgendwelche Dinge.
-
Wird auch ein Alias H64 möglich sein, wie Du es bei MD und EF hast?
Ja, das richte ich so ein.
-
Eine bestückte Karte kann ich dir für lau zukommen lassen.
Beschreibung findest du hier:
Super, EPROM habe ich genügend da.
Wenn ich die Platine da habe, kann ich es testen.
DP64 im GUI dann bitte auch berücksichtigen, das wäre dann ModulType=7 (Option: -7)
Display MoreCodeDas kommt dann gleich mit der neuen Version des UC Builder (v1.13)
Kann ich dir aber auch gerne nochmal in Kurzform aufschreiben 😃
Nicht nötig, deine Doku ist ausgezeichnet.
-
Dann Pack doch noch gleich die 64K Karte von Hucky mit ins GUI
Könnte ich machen, hab aber kein solches Ding ...
Wer mag das dann testen?
-
Übrigens, kann man in der GUI eigentlich auch EasyFlash und MagicDesk auswählen als Ziel Format?
-
Ja, aber mir stellt sich die Frage, ob das immer zuverlässig ist. Was wenn jemand die nur temporär bei sich gespeichert hat und dann bei Verwendung der Projektdatei diese Pfade nicht mehr existieren?
Naja ich meine ...
... wenn sich jemand ein WORD Dokument verschießt oder löscht, dann ist es eben weg.
Anderer Vorschlag.
Du generierst als "Projekt" ein komplettes ZIP File, wo alles drin ist was man benötigt.
Das wäre gelöst, wenn man das Programm komplett aus dem EPROM neu generieren und in eine Liste übernehmen würde, die von der GUI eingelesen wird.
OKay ich guck mal ob ich es am WE fertig kriege ...
-
Das wäre eigentlich ne viel coolere Lösung, als eine Projektdatei, finde ich?
Naja, das eine schließt ja das andere nicht aus.
Die Idee einer Projektidee finde ich nach wie vor klasse.
Da hättest du auch die Pfade zu den original Dateien etc. etc.
Das Image Analyse Tool hat andere Vorteile.
Wenn man ein UC Modul ausliest, also das EEPROM meine ich, dann könnte man die einzelnen Programme weiter verwenden.
Angenommen ich finde 5 UC Images.
Und ich möchte ein Programm aus dem ersten und zwei Programme aus dem zweiten und aus den anderen auch jeweils eines ...
... dann kann ich mir simpel mein eigenes UC Modul basteln, wo nur das drin ist, das ich gerne in meinem Lieblingsmodul habe.
-
Klingt gut. Du könntest die Dateien im EPROM dann im collections/current aus dem Image heraus anlegen?
Ich könnte die Dateien benennen wie der Menüpunkt gestartet wird (A-Z, 0-9) und ablegen da wo das Imagefile ist. Oder optional per Schalter einen Pfad vorgeben lassen, wo die Dateien gespeichert werden.
Das CSV kann ich fast vollständig rekonstruieren aus der Image Datei. Wobei es geht noch besser. Die Programme könnte man in einem speziellen Format speichern. Wie es auch bei den CRT Dateien ist, die haben einen Header wo alles wesentliche drin steht. Quasi ein "Program Object" wo Name, Startvorgaben und alles weitere enthalten ist. Bei Wiederverwendung in einer CSV Datei gibt es einfach einen speziellen Dateityp. Genau wie bei CRT.
-
Du meinst ein fertiges Image, durch den UCBuilder erstellt in die Liste laden?
Wenn wir das wollen, kann ich das unterstützen.
Ein fertiges Image in den UC Builder laden und ich bekommen die Einzelprogramme + ein CSV File
Quasi ein UC-Analyzer statt UC-Builder ...
-
-
Ich brauche dann natürlich auch kein Menü, keine SID-Hintergrundmusik und ähnliches.
Beim UC Builder geht das automatisch.
Wenn du nur EIN Programm konfigurierst, dann läßt der automatisch das Menu weg und startet das Programm sofort.
Der UC Builder kann für alle gängigen Modul Typen (UC, Magic Desk, EasyFlash) ein EPROM Image generieren, das Menü sieht überall gleich aus.
Der UC Builder braucht weder Python noch sonst irgendein Runtime.
Es genügt ein Windwos PC.
-
Ein ByteMaschine CPU Board für Motorola 6809 bzw. Hitachi 6309.
Was kann man damit so machen?
Im wesentlichen kann man damit dasselbe machen wie mit jedem SBC wie zB. dem KIM1 ...
... sich mit der CPU beschäftigen.
Hier halt die 6309 statt der 6502.
Es gibt IO (Inputs, Outputs, LED, serielle Schnittstelle, SD Card).
Und natürlich RAM (512K) und ROM (512K).
Man kann es auch als CPU Tester verwenden.
Das CPU Board wird einfach aufgesteckt.
Jede CPU hat ihren eigenen ROM Bereich.
-
Ein ByteMaschine CPU Board für Motorola 6809 bzw. Hitachi 6309.
-
Zum Sammeln ok, aber zum Benutzen? Eine 16 MB REU, oder gar 32 MB REU, kriegst du nicht gefüllt, wenn du nicht auch noch irgendwo ein passendes Massenspeicher-Medium hast. Die 1541U hat eben beides und ist daher lohnenswert.
Diese REU hat ein SD Card Slot.
Und spielt auch sonst noch einige Stückchen ...
-
Dann erklär mir mal bitte, wie ein REU Nachbau (!) immer interessanter werden kann, wenn immer mehr Hardware auf den Markt kommt, die eine REU ab Werk frei Haus emuliert?
Genau ...
... emuliert.
Wozu brauchst du denn einen C64?
Wenn man doch eh den ganzen C64 samt REU im VICE emulieren kann?
Es ist halt ein Hobby.
Und jede Hardware bringt ein Stück Vergangenheit zurück.
Und es macht richtig Spaß!
-
Ich meinte nur, Du sagtest mal, dass Du evtl. nochmal ne 1MB Version machen willst.
Ja wenn man richtig viel braucht ist eh ein EF3 das optimale Ding.
Ansonsten gibt es keine Spiel das nicht in 512K passen würde.
-
Ein FE3 löst alle vic-20 Probleme ...
ja, ich weiß
Irgendwann hoffe ich mal, die Funktionsweise dieser Dinger soweit zu verstehen, dass ich selber auch mal was basteln kann. Und beim Verstehen hilft alter Schrott halt besserJa, das stimmt, das kann dein Verständnis verbessern.
Im Falle des VIC20 ist es sehr einfach.
Was willst du wissen?
Woran scheitert es?
Was verstehst du nicht?
Kann ich was tun, damit du es besser verstehst?
