Posts by guidol

    Ian hat jetzt 2 Binarys auf Github gehabt fuer serial

    Quote

    Added Pico_1140_UART

    Modified version that links the console and DL11 to UART0 and UART1 on the pico board. (Speed 115200).
    Pins: TX/RX on GPIO 0/1 and 20/21.


    Die 115.200 Baud Version ist aber schon der 9.600Baud Version gewichen...wobei die Darstellung mit 115.200Baud eh nicht schneller ist ;)

    Bis jetzt gibt es davon nur die .UF2-Binarys

    Ausserdem wurde die Auswahl des Imagetyps in den Open-Dialog (für Image Open) bzw. in den Save-Dialog (für Create new emtpy Image) verschoben.

    HobbyProgrammer Da bin ich eben gut reingefallen ;) Beim 2ten lesen habe ich es dann verstanden.

    Kann man dies evtl. so anpassen, dass das "Oeffnen" des Image ausgegraut ist, solange man keinen Image-Type ausgewaehlt hat?


    Ansonsten ist man wieder im Hauptscreen und sieht nur die 2 leeren Felder :(


    PS: Copy (Export) eines .BAS aus dem Image hat gut geklappt. :)

    pdp11gy  spoofy

    Mit dem Minor-Update zum Ende Januar hat Ian 2 USB-CDC Terminals eingebunden, aber damit klappen beim Compile meine Aenderungen nicht mehr fuer die serielle Version :(


    In der dl11.cxx werden dann aktiv die CDCs abgefragt:


    Somit weiss ich nicht, wie ich damit umgehen soll. Die tud_cdc_n_xxx Befehle sind glaub auch noch in einer anderen Datei.


    Mal sehen on es nochmal eine neuere serielle Versio geben wird.


    Fuer die Ian-SPI-Config habe ich mal das .UF2 mit 250Mhz kompiliert, aber nicht mehr so viel optische Aenderungen gemacht, da Ian schon einige uebernommen hatte und dies so auch Ok fuer mich war ;)

    Eigentlich kannte ich als CPMBox (so aus dem Gedaechtnis) nur einen Amstrad PCW-Emulator (CP/M Box von Habisoft)

    aber heute fand ich CPMBox v1.0.1 von Hein Pragt

    Ein Z80-MBC2 Emulator fuer Windows in 32- oder 64Bit.


    Nach dem Verzeichnisinhalt - der portable Anwendung - sieht es so aus, als nutzt er die normalen Disk-Images des Z80-MBC2.


    Die Ausgabe erfolgt auf einem virtuellen monochrom Monitor :)




    Hein Pragt hat mit dieser Ausgabe auch noch einen Apple-1 und TRS80 Emulator ;)

    In hw_config.c:

    In deinem versionen ist spi1 und das funkt nich bei mir.

    Beim Source habe ich auch eine Version fuer einen SPI0 den ich nutze (die RunCPM-SPI-config) und dann gibt es noch die hw_config fuer ein RC2040 Board (da habe ich gerade nicht im Kopf ob es SPI0 oder SPI1 ist - sind aber torzdem evtl. andere Pin-Nummern als bei Dir, denn SPI0 & SPI1 haben ja verschiedene Pin-Moeglichkeiten)

    Ist das schon im git? Oder hast du Quellcode für den seriell Konsole Version, weil ich habe einige Veränderungen in meine Version und muss selbst kompilieren.


    Im git von Ian Schofield ist die serielle Version nicht vorhanden :( Die hatte ich fuer pdp11gy und mich erstellt.

    Den Source haenge ich an.
    Die Baudrate wird mit der set_uart.h bestimmt.

    Aufgrund der Tatsache, dass die Emulation die Ausgabe "bremst" merkt man aber nicht so viel Unterschied zwischen 9600 oder 115.200 Baud ;)


    BTW: Aus Neugier - was hast Du denn fuer Dich geaendert am Source? :)

    Ich nutze Putty unter mein Linux, und wenn ich mache Pico reset, dann seriell Port auf Linux geht weg und Putty danach auch.

    Das passiert bei Nutzung des USB-Port. Mit puTTY (oder kiTTY) unter Windows bleibt das Fenster inaktiv bestehen (ich weiss nicht ob es dazu eine Einstellung gibt). D.h. man kann nach dem Reset das Fenster per Tastendruck wieder aktivieren, wenn es den selben virtuellen COM-Port nutzt.


    Alternativ muesstest Du dann eine Version der Emulation nehmen, die den seriellen Port auf Pin 0/1 nutztund einen TTL-seriellen Adapter nutzen.

    Wenn Du den Pico resetest, bleibt durch den Adapter der COM-Port (bzw. unter Linux /dev/ttyUSB0) ja bestehen, da der Adpater nicht mit resetet wird durch den Reset des Pico.

    Kann man im Design einen Reset-Schalter implementieren, damit man den USB nicht vom Rechner trennen muss?

    spoofy Ja ein Reset-Schalter ist sehr leicht zu implementieren - einfach einen Reset-Button zwischen Pin 28 und 30.
    Ich hab einen steckbaren direkt auf dem Breadboard - normale haben 4 Pins, aber es gibt die auch passend mit nur 2 Pins mittig.




    Ctrl-E gibt es leider nicht bei dieser Umsetzung von SimH, da das ganze komfortable Interface aus Speichergruenden ausfaellt im Pico.


    Aber ich bin zufrieden mit dem Reset-Taster. Einfach druecken und schon hat man wieder das Startmenu ;)

    Teste armbian fuer den Rockchip RK3188 auf meinem Radxa Rock mit RK3188 CPU.

    Radxa selber hatte damals beim Kernel 3.0.96+ den Support beendet.
    Hier beim Kernel 5.10.96 wird noch nicht die ganze Hardware unterstuetzt (onboard Ethernet bekommt keine IP und wenn dann nicht nutzbar). USB-Etheret geht.


    So ;) mein ATMEGA32A als DIP ist nun drin im Z80-MBC2



    Die Vorbereitung war soweit gut, nur hatte ich bei den Breadboard-Kabeln nicht ganz die Farben zur Hand wie auf dem Bild und ich wollte die Kabel am UNO nicht so verdrehen, deshalb habe ich die Kabel-Farben dann am ICSP-Port des Z80-MBC2 entsprechend anders eingesteckt.



    Fuers flashen des Bootloaders habe ich - nach der Anleitung - den SDCard-Adapter, die RTC und den TTL-Seriellen-Adapter abgezogen.


    Entgegen der Anleitung musste ich fuer den Bootloader nicht nur den ATMega32 auswaehlen als Board und den "Arduino ISP (MightyCore)" als Programmer - es klappte erst als ich dem ATMega32 dann den COM-Port (COM33) des Arduino UNO (der Arduino ISP spielte) zuordnete, weil die Arduino IDE vorher immer ueber einen (nicht angewaehlten) STK-500 flashen wollte.



    Nach dem Flashen des Bootloaders konnte ich die abgesteckten Komponenten wieder anstecken und den ATMega32A-PU per TTL-seriell mit dem .INO - ueber die Arduino-IDE - versorgen.



    Beim ersten Boot blinkte die gruene LED, weil dem Z80-MBC2 die Grundkofiguration fehlte (was er booten soll und ob die Autoexec an/aus ist bzw. die Uebernahme von Datum/Uhrzeit aus der RTC stand auch an)


    Beim zweiten booten hing das System dann an der Ausgabe "IOS: Z80 is running from now"

    weil wohl der Kontakt zum SDCard-Adapter nicht ganz gegeben war(?)
    Ich reinigte dessen Kontakte und steckte den Adapter neu ein - und auch die SDCard habe ich im Adapter nochmal raus/rein-gesteckt.


    Danach bootete der Z80-MBC2 wieder ganz normal.
    Ich finde, dass die 2 kleinen Platinen fuer SDCard und RTC schon sehr wackelig drauf stecken.
    Ich steh mehr auf die doppelreihige Verbindungsart, da dies etwas mehr Stabilitaet gibt.

    eher umgekehrt ;) das beige Zeug ist anfälliger irgendwie. ich denke mal, die Zusammensetzung der schwarzen Gehäuse ist anders. Beim Mac TV der LC 5xx Serie ist es auch so, die sind etwas robuster als die beigen Varianten.

    Bei der Black-Commodore Serie ist es anders herum (C16, Plus4 aund 1551) - da broeseln laut Berichten die Gehaeuse fast beim ansehen... :(

    Fabio Defabis teilte mir mit, dass in meinem .HEX der serielle extended RX-buffer nicht aktiviert ist, weil dazu muss man in der
    \AppData\Local\Arduino15\packages\MightyCore\hardware\avr\2.1.3\boards.txt in Zeile 944

    Code
    32.menu.LTO.Os.compiler.cpp.extra_flags=

    gegen

    Code
    32.menu.LTO.Os.compiler.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128

    austauschen und neu compileren, dann bekommt man beim Boot auch die Meldung zum

    extended serial RX-Buffer

    Vorbereitendes PinOut-Bild fuers flashen des Bootloaders auf dem ATMEGA32-PU ;)
    (Wobei ich bei adafruit den Treiber fuer meinen USBtinyISP v3.0 gefunden habe, denn ich musste meinen UNO von amforth erst mal befreien - d.h. neuen Bootloader schreiben)


    Da ich demnaechst meinen SMD-ATMEGA32


    gegen eine echte DIP-Version (ATMEGA32-PU) tauschen wil, bereite ich mich schon mal vor und habe das IOS - I/O Subsystem - S220718-R240620 nochmal frisch compiliert mit dem letzten aktuellen
    MightyCore Release v2.1.3 vom 04.07.2021
    Ich dachte das macht evtl. Sinn, da der 04.07.21 neuer ist als das Release-Datum des IOS 24.06.20



    Das compilierte .HEX haenge ich mal als .ZIP an.


    Also Info das Log vom Upload in der Arduino-IDE (nach dem compile):



    wahrscheinlich interessiert's außer guidol wirklich niemanden: Es gibt nun auch eine SPO256 Emulation auf der PicoMite: https://www.thebackshed.com/fo…opic.php?FID=16&TID=15431

    Ist Dir bekannt, das die RC2040-Emulation (also RC2014 auf dem Pico) schon eine ganze Weile eine SPO256-Emulation in der RC2040 Emualtion hat? ;)


    Ian Schofield hat zum Jahres-Start direkt ein groesseres Update "rausgehauen" ;)
    Dies bootet nun auch direkt RL02 Images (auch wenn man beim Start auch neben dem RL02 File nach einem RK05 gefragt wird).


    Ich habe die Optik wieder angepasst und eine USB und seriell (9600 Baud) Version erstellt.


    Kleine Aenderung meinerseits:
    Die Auswahlanzeige fuer die Files zeigt nun nicht mehr die .DSK Dateien, sondern *.R*


    Das habe ich gemacht, weil meine Disk-Images nun *.RK05 und *.RL02 heissen.
    Wer also auf einmal keine Disk-Images mehr angezeigt bekommt, sollte seine umbenennen.

    Bis knapp 2.5MB sind es eher RK05-Images und RL02-Images haben eher 8MB-10MB


    Sorry, I might have missed it, but where did you get the keyboard?

    see the first post (on page 1) of this thread:

    Quote

    alte Tastatur aus einem Texas Instruments Silent 700 ASR Electronic Data Terminal wäre perfekt!

    Mein KIM1 RevA hatte seit Ewigkeiten vom Vorbesitzer einige Kabel dran, die ich heute abgeloetet hab.
    Nach dem abloeten sah er aber noch nicht so nett aus, da noch Loet-"Flux" von damals dran war, also wenn ich schon mal dabei bin - habe ich ihn etwas aufgehuebscht durch entfrenen des Flux, Reinigung des Connectors / der weissen Ceramic-Chip / des Crystals und vorsichtig die Platine inkl. Logo geputzt ;)
    So kommt er nun sauber ins Jahr 2023 :)


    So :) hier fuer pdp11gy eine serielle .UF2-binary-Version mit 9600 Baud


    Ich musste dafuer noch etwas die UART-Init-Reihenfolge umstellen.

    D.h. nach dem

    stdio_init_all();

    was wohl trotz Baudrate-Vorgabe standardmaessig 115.200Baud initialisiert

    gebe ich noch einen full_init fuer die serielle Schnittstelle hinzu

    stdio_uart_init_full(UART_ID, BAUD_RATE, UART_TX_PIN, UART_RX_PIN);


    Um nicht in 3 Dateien die Baudrate anpassen zu muessen, habe ich eine set_uart.h erstellt,

    die per include in die getline.cxx, kl11.cxx und die Pico_1140.cxx eingebunden wird

    #include "set_uart.h"


    Code
    // We do set UART number and speed
    #define UART_ID uart0
    #define BAUD_RATE 9600
    
    // We are using pins 0 and 1, but see the GPIO function select table in the
    // datasheet for information on which other pins can be used.
    #define UART_TX_PIN 0
    #define UART_RX_PIN 1


    Getestet habe ich die 9600 Baud Version auch wieder mit dem serial2Telnet-Adapter, den man ja auch von 115.200 auf 9600 Baud runter-konfigurieren kann :)


    So viel langsamer sieht er Bildschirmaufbau garnicht aus - haette ich nicht erwartet.

    Aber RunCPM ist da viel flotter in der Bildschirmausgabe ;)