Heute so gecodet...

  • Aha, habe jetzt mal nachgesehen,

    Arduino (Plattform) schrieb:

    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?
  • Hier eine Seite die mit der Grafik Lib arbeitet und sogar noch was dazu programmiert hat:
    crawlingrobotfortress.blogspot…cs-engine-on-arduino.html

    Das ist die Lib (ein Fork von Adafruit's GFX library) Hat das gleiche API nur halt schneller.
    github.com/XarkLabs/PDQ_GFX_Libs

  • 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.
  • lemon03 schrieb:

    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.
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 102 Bücher bzw. 28.009 Buchseiten mit Z80/8080/8085 Power
  • 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 ( :wand )
    • 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. :thnks:
    twitter.com/dec_hl - Acht C64 haben auch 64-Bit...
  • SuperIlu schrieb:


    Danke nochmal an @oobdoo, @daybyter, @JeeK und @utz fuer ihren Input und Tritte in die richtige Richtung. :thnks:
    Ich? Mehr als "Man kann nie genug Z80 zuhause haben" kann das aber nicht gewesen sein. 8|
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 102 Bücher bzw. 28.009 Buchseiten mit Z80/8080/8085 Power
  • 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).


    daybyter schrieb:

    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 :)
    twitter.com/dec_hl - Acht C64 haben auch 64-Bit...
  • Man kann ja einfach mal die cp/m conout Funktion implementieren und sich bei der Registerbelegung an die cp/m Konventionen halten?

    gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm#Section_5.2

    oder hier ganz unten:

    cpcwiki.eu/index.php/Programmi…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 ?
    Hier könnte ihre Signatur stehen!
  • 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-Quellcode

    1. #include <stdio.h>
    2. #include <stdlib.h>
    3. #include <stdint.h>
    4. #include <string.h>
    5. #ifdef _WIN32
    6. #include <io.h>
    7. #include <fcntl.h>
    8. #endif
    9. uint8_t bitmap[8000];
    10. uint8_t color1[1000];
    11. uint8_t color2[1000];
    12. char buf[256];
    13. enum modes
    14. {
    15. M_BITMAP,
    16. M_COLOR1,
    17. M_COLOR2
    18. };
    19. enum modes mode = M_BITMAP;
    20. int main(void)
    21. {
    22. #ifdef _WIN32
    23. setmode(fileno(stdout),O_BINARY);
    24. #endif
    25. size_t nextidx = 0;
    26. while (fgets(buf, 256, stdin))
    27. {
    28. char *start = strstr(buf, ".db");
    29. if (!start) continue;
    30. start += 4;
    31. char *val = strtok(start, ",");
    32. while (val)
    33. {
    34. uint8_t byte = (uint8_t)atoi(val);
    35. switch (mode)
    36. {
    37. case M_BITMAP:
    38. bitmap[nextidx++] = byte;
    39. if (nextidx == 8000)
    40. {
    41. nextidx = 0;
    42. mode = M_COLOR1;
    43. }
    44. break;
    45. case M_COLOR1:
    46. color1[nextidx++] = byte;
    47. if (nextidx == 1000)
    48. {
    49. nextidx = 0;
    50. mode = M_COLOR2;
    51. }
    52. break;
    53. case M_COLOR2:
    54. if (nextidx == 1000) break;
    55. color2[nextidx++] = byte;
    56. break;
    57. }
    58. val = strtok(0, ",");
    59. }
    60. }
    61. for (nextidx = 0; nextidx < 8000; ++nextidx)
    62. {
    63. if (!(nextidx % 8))
    64. {
    65. putchar(color1[nextidx >> 3]);
    66. putchar(color2[nextidx >> 3]);
    67. }
    68. putchar(bitmap[nextidx]);
    69. }
    70. }
    Alles anzeigen

    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:

    Quellcode

    1. .import vic_bitmap
    2. .import vic_colram
    3. .import init_decruncher
    4. .import get_decrunched_byte
    5. .zeropage
    6. temp4: .res 1
    7. dataptr: .res 2
    8. .code
    9. dio_loadbitmap:
    10. lda #$0
    11. sta temp4
    12. sta dataptr
    13. sta col1ptr
    14. sta col2ptr
    15. lda #>vic_bitmap
    16. sta dataptr+1
    17. lda #>vic_colram
    18. sta col1ptr+1
    19. lda #$d8
    20. sta col2ptr+1
    21. jsr init_decruncher
    22. dlb_loop: jsr get_decrunched_byte
    23. bcc dlb_cont
    24. rts
    25. dlb_cont: dec $01
    26. col1ptr = *+1
    27. sta $ffff
    28. inc $01
    29. inc col1ptr
    30. bne dlb_col2
    31. inc col1ptr+1
    32. dlb_col2: jsr get_decrunched_byte
    33. col2ptr = *+1
    34. sta $ffff
    35. inc col2ptr
    36. bne dlb_bitmap
    37. inc col2ptr+1
    38. dlb_bitmap: jsr get_decrunched_byte
    39. ldy temp4
    40. sta (dataptr),y
    41. inc temp4
    42. beq dlb_next
    43. lda temp4
    44. and #$7
    45. bne dlb_bitmap
    46. beq dlb_loop
    47. dlb_next: inc dataptr+1
    48. bne dlb_loop
    Alles anzeigen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von zrs1 ()

  • 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...
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • zrs1 schrieb:

    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...
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • ZeHa schrieb:

    Tja, wenns um Z80 geht wills auf einmal wieder keiner gewesen sein :bgdev
    Nene, so ist das nicht zu verstehen. :motz: :D


    SuperIlu schrieb:

    Kinders, ich hab extra in meinen Thread von damals geguckt und alle namentlich genannten Personen haben was beigetragen.
    Welcher Thread?
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 102 Bücher bzw. 28.009 Buchseiten mit Z80/8080/8085 Power