Könnte man am Arduino mit Display wohl auch laufen lassen. Hab letztes Jahr eine schnelle Grafik lib gefunden.
Hallo Besucher, der Thread wurde 308k mal aufgerufen und enthält 2099 Antworten
letzter Beitrag von oobdoo am
Heute so gecodet...
- syshack
- Unerledigt
-
-
Aha, habe jetzt mal nachgesehen,
Zitat von Arduino (Plattform)Arduino bringt eine eigene integrierte Entwicklungsumgebung (IDE) mit, die auf Wiring IDE basiert. Dabei handelt es sich um eine Java-Anwendung, die für die gängigen Plattformen Windows, Linux und MacOS kostenlos verfügbar ist. Sie basiert auf der IDE von Processing, einer auf die Einsatzbereiche Grafik, Simulation und Animation spezialisierten Entwicklungsumgebung. Die Arduino-IDE bringt einen Code-Editor mit und bindet gcc als Compiler ein. Zusätzlich werden die avr-gcc-Library und weitere Arduino-Librarys eingebunden, die die Programmierung in C und C++ stark vereinfachen.
Der würde also C++ Code anständig schlucken?
-
Ja, ich hab da schon C++ Code hinzugefügt.
-
Hier eine Seite die mit der Grafik Lib arbeitet und sogar noch was dazu programmiert hat:
http://crawlingrobotfortress.b…cs-engine-on-arduino.htmlDas ist die Lib (ein Fork von Adafruit's GFX library) Hat das gleiche API nur halt schneller.
https://github.com/XarkLabs/PDQ_GFX_Libs[Externes Medium: https://www.youtube.com/watch?v=8nZam2jpIqw] -
Aha, wenn ich das so überblicke, wird mein Code damit fast vollkommen überflüssig. Denn alle Funktionen, die ich rund um und für die Console Klasse und der Ausgabe geschrieben habe, sind dort schon vorhanden. Das in deutlich fortschrittlicheren Code. Und was will ein Arduino mit einer Klasse Windows-Konsole? Ich hätte also nichts mehr zu tun, weil ja alles schon geschrieben wurde.
-
84 Farbtöne in der Konsole. Kommt nicht an einen Plus/4 ran, oder? Man könnte sie noch untereinander mischen, aber dann gibt es keine Schattierungen mehr.
[Externes Medium: [media]https://www.youtube.com/watch?v=6NOxQ45rG6E] -
Mhm, 84 Farbtöne in der Konsole. Kommt nicht an einen Plus/4 ran, oder? Man könnte sie noch untereinander mischen, aber dann gibt es keine Schattierungen mehr.
Video nicht verfügbar.
-
Wieder eingefügt
...sorry, ich hätte das Ding nur umbennen müssen, stattdessen hatte ich es glöscht und neu hochgeladen
-
Nicht nur heute, sondern die letzten Wochen/Monate: Der ROM-Monitor fuer meinen Z80-Selbstbau ist fertig und im ROM (aka EPROM).
Ich habe eine zweite Platine aufgebaut (ich wollte im Fehlerfall nicht alles nochmal verkabeln, siehe unten). Das Ganze laeuft jetzt erst mal mit 1MHz und einer 4800er baudrate .Neben der Initialisierung von Timer und UART kann man damit RAM lesen/schreiben, kopieren, loeschen und ein wenig zwischen den Zahlensystemen hin&her konvertieren.
Das wichtigste ist aber das ich jetzt Daten aus einem I2C-EEPROM nachladen kann und somit mein Entwicklungssytem beiseite legen kann (hoffentlich).
Das oben ist das Entwicklungssystem. Oben links der Arduino-Nano basierte RESET und CLOCK Generator, rechts der Arduino Mega basierte ROM-Emulator. Die beiden wurden ueber ein Python-GUI ferngesteuert. Systemtakt war 10kHz, die Baudrate 600.
Rechts der Logic-Analyzer fuer den Systembus, links der fuer I2C und UART.Meine naechsten Plaene:
- Test der restlichen Hardware (ROM/RAM-Bankswitching ist ungetestet).
- Ein kleines Snake-Game schreiben um den Einsprung in die ROM-Routinen zu testen (Console, etc).
- Anschliessen eines SwinSID ueber den Busadapter und gucken ob man den zuverlaessig ansteuern kann.
- Zusammenbauen und Anschliessen meiner Atmega-basierten AV-Schaltung.
- Die zwei fehlenden Pull-Ups im Layout nachruesten ( )
- Ueberarbeiten des Layout um SwinSID und AV-Ausgang auf der Platine zu haben.
- Moeglicherweise mehr RAM durch Bankswitching.
- Finden eines Loesung fuer die Tastatur...
- Mal CP/M angucken: wie viel ich da tun muss um ein funktionierendes BIOS fuer zu bauen.
Danke nochmal an @oobdoo, @daybyter, @JeeK und @utz fuer ihren Input und Tritte in die richtige Richtung.
-
-
Ich glaub auch, dass ich mit Tale verwechselt werd. Der hat sicher mehr Tipps gegeben, als ich...
Aber so ein winziges BIOS als z80 Kurs? Mal ne Funktion schreiben, die ein Zeichen ausgibt, oder so?
Wär das nix fürs Forum? -
Tja, wenns um Z80 geht wills auf einmal wieder keiner gewesen sein
-
Nein, Nein! z80 ist toll!
Da schlägt halt nur unsere angeborene Bescheidenheit durch...
-
Kinders, ich hab extra in meinen Thread von damals geguckt und alle namentlich genannten Personen haben was beigetragen.
An den Z80 bin ich selber schuld! Als ich das Projekt angefangen habe hat mir ein kurzer Blick auf iehBaeh gereicht um zu wissen das ich fuer den Preis von einem 6502/6510 drei bis vier Z80 haben kann (und das sogar fabrikneu).
Aber so ein winziges BIOS als z80 Kurs? Mal ne Funktion schreiben, die ein Zeichen ausgibt, oder so?
Wär das nix fürs Forum?Meinst du das CP/M BIOS? Ist das nicht etwas zu speziell als 'Einsteiger Kurs' gleich eine CP/M Portierung zu machen?
Zudem ich ja erst einmal rausfinden muss ob CP/M ueberhaupt auf meiner verfrickelten Hardware laufen wuerde -
Man kann ja einfach mal die cp/m conout Funktion implementieren und sich bei der Registerbelegung an die cp/m Konventionen halten?
http://www.gaby.de/cpm/manuals…22htm/ch5.htm#Section_5.2
oder hier ganz unten:
http://www.cpcwiki.eu/index.ph…ogram_for_CP/M_using_BDOS
Also in Register C die CONOUT Konstante 2, dann das Ascii Zeichen in Register E und ein call 0005h ?
-
Nicht heute, ist n paar Tage her ...
Ein kleines quick&dirty Tool, das ein mit Multipaint (csdb) als Assembler source exportiertes Multicolor Bild in ein Binär-Format konvertiert, bei dem die Farbinformation "multiplexed" ist, also immer ein Byte Screen RAM, ein Byte Color RAM, dann 8 Bytes Bitmap:
C- #include <stdio.h>
- #include <stdlib.h>
- #include <stdint.h>
- #include <string.h>
- #ifdef _WIN32
- #include <io.h>
- #include <fcntl.h>
- #endif
- uint8_t bitmap[8000];
- uint8_t color1[1000];
- uint8_t color2[1000];
- char buf[256];
- enum modes
- {
- M_BITMAP,
- M_COLOR1,
- M_COLOR2
- };
- enum modes mode = M_BITMAP;
- int main(void)
- {
- #ifdef _WIN32
- setmode(fileno(stdout),O_BINARY);
- #endif
- size_t nextidx = 0;
- while (fgets(buf, 256, stdin))
- {
- char *start = strstr(buf, ".db");
- if (!start) continue;
- start += 4;
- char *val = strtok(start, ",");
- while (val)
- {
- uint8_t byte = (uint8_t)atoi(val);
- switch (mode)
- {
- case M_BITMAP:
- bitmap[nextidx++] = byte;
- if (nextidx == 8000)
- {
- nextidx = 0;
- mode = M_COLOR1;
- }
- break;
- case M_COLOR1:
- color1[nextidx++] = byte;
- if (nextidx == 1000)
- {
- nextidx = 0;
- mode = M_COLOR2;
- }
- break;
- case M_COLOR2:
- if (nextidx == 1000) break;
- color2[nextidx++] = byte;
- break;
- }
- val = strtok(0, ",");
- }
- }
- for (nextidx = 0; nextidx < 8000; ++nextidx)
- {
- if (!(nextidx % 8))
- {
- putchar(color1[nextidx >> 3]);
- putchar(color2[nextidx >> 3]);
- }
- putchar(bitmap[nextidx]);
- }
- }
Das kann man dann direkt beim Laden schön von oben nach unten darstellen -- ich jage es noch durch den Exomizer und verwende dann den folgenden Code mit dem Exomizer Stream decruncher:Code- .import vic_bitmap
- .import vic_colram
- .import init_decruncher
- .import get_decrunched_byte
- .zeropage
- temp4: .res 1
- dataptr: .res 2
- .code
- dio_loadbitmap:
- lda #$0
- sta temp4
- sta dataptr
- sta col1ptr
- sta col2ptr
- lda #>vic_bitmap
- sta dataptr+1
- lda #>vic_colram
- sta col1ptr+1
- lda #$d8
- sta col2ptr+1
- jsr init_decruncher
- dlb_loop: jsr get_decrunched_byte
- bcc dlb_cont
- rts
- dlb_cont: dec $01
- col1ptr = *+1
- sta $ffff
- inc $01
- inc col1ptr
- bne dlb_col2
- inc col1ptr+1
- dlb_col2: jsr get_decrunched_byte
- col2ptr = *+1
- sta $ffff
- inc col2ptr
- bne dlb_bitmap
- inc col2ptr+1
- dlb_bitmap: jsr get_decrunched_byte
- ldy temp4
- sta (dataptr),y
- inc temp4
- beq dlb_next
- lda temp4
- and #$7
- bne dlb_bitmap
- beq dlb_loop
- dlb_next: inc dataptr+1
- bne dlb_loop
-
Die letzten Tage so gecodet: SSaM - Sam's Journey Savegame Manager. Der wichtigste Teil, das EEPROM Lesen/Schreiben/Interpretieren hat am kürzesten gebraucht, File I/O schon länger (habe ich in der Form noch nie implementiert), aber am deutlich längsten das Userinterface. Eigentlich hätte ich die Reihenfolge genau umgekehrt erwartet...
-
Eigentlich hätte ich die Reihenfolge genau umgekehrt erwartet...
Ist doch die berühmte 20/80 Regel (20% der Funktionalität brauchen 80% des Codes/Aufwands)
Auch schön dargestellt im zweiten Bildchen hier
-
Auch schön dargestellt im zweiten Bildchen hier
Sehr gut, kannte ich in dieser Variante noch nicht und hängt jetzt in meinem Büro ! Ich dachte nur bei mir wären die 20% die 80% der Arbeit brauchen das EEPROM-Handling...
-
Tja, wenns um Z80 geht wills auf einmal wieder keiner gewesen sein
Nene, so ist das nicht zu verstehen.
Kinders, ich hab extra in meinen Thread von damals geguckt und alle namentlich genannten Personen haben was beigetragen.
Welcher Thread?