Posts by SvOlli

    Moin!


    Ich bin gerade dabei, mir einen PC zusammen zu bauen, dessen Schwerpunkt "Emulation / Emulatoren" sein soll. Dabei bin ich zu der Erkenntnis gekommen, dass VICE doch eine original C64 Tastatur haben sollte. Also nahm ich mir einen ESP32, den ich noch rumliegen hatte, und habe mir damit dann eine Bluetooth Tastatur gebaut. Bluetooth deshalb, weil das VICEboard als optionale zweite Tastatur laufen sollte. Optional bedeutet, dass man sie gut weglegen können muss, also sollte sie schnurlos sein. Und das lässt mit Bluetooth und einem ESP32 für 5-10 Euro am einfachsten bewerkstelligen.


    VICEboard_open.jpg


    Die Firmware dafür ist natürlich Open Source, und u.a. auf GitHub (https://github.com/SvOlli/VICEboard) zu haben. Sie funktioniert für mich soweit recht gut, allerdings ist sie noch nicht 100% Feature-complete. Das wichtigste was noch fehlt, ist eine dynamische Konfiguration der ESP32 I/O Pins, so dass man die Kabel so anlöten kann, wie sie am besten passen. Das kann man zur Zeit nur beim Compilieren ändern, ein Tool zum Testen der Pins liegt separat bei. Außerdem will ich noch das Einschalten parametrisieren. Die Tastatur schaltet sich nach Inaktivität aus, nach wieviel Sekunden kann man konfigurieren. Momentan geht sie in Deep Sleep und wird per Restore-Taste angeschaltet. Ich will aber auch noch ein Power Off einbauen, dann muss sie über einen extra Taster (Reset am ESP32) eingeschaltet werden.


    Die Konfiguration findet über die serielle USB-Schnittstelle des ESP32 statt. Man kann also die Parameter mit einem Terminalprogramm setzen, ähnlich wie beim C64 Reloaded MK2. (Danke an Jens für die Idee.) Man kann so z.B. Timeouts fürs Ausschalten einstellen, welches Tastencodes die Sonderfunktionen CTRL + Fx schicken oder auch die Helligkeit der Dual-LED: statt Vorwiderstände zu nutzen, machen ich das per PWM in Software.


    Falls sich das jemand nachbauen will, helfe ich gerne. Je nachdem wie die Resonanz ist, werde ich die noch offenen Punkte früher oder später in Angriff nehmen. Auf der GitHub-Seite sind noch ein paar Bilder mehr.


    Viel Spaß,

    SvOlli

    8MB was pure marketing talk. The specification of the RAM Expansion Control register only allowed for two banks of 512K each. There are still a couple of bits undefined, so more might be possible, but for the final state of the machine it was 1MB only. (Docs backing this up are available at https://github.com/MEGA65/c65-specifications ) 8M or maybe just 4M might have been included at a later state, as the register still has some bits unused.

    Also there is no completed Basic 10. The most current ROM known so far (dated 911001) still contains several ?NOT IMPLEMENTED ERRORs.

    Was mich übrigens mehr interessieren würde als das Gemecker, dass die Hardware nicht in jedem C64 läuft (das kann ich weder etwas für, noch kann ich das beheben), wäre Rückmeldungen, wie die Software funktioniert. Ich vergaß zu erwähnen, dass sie auch mit einem RR-Net MK1 und MK2 funktioniert, sofern das "Trägerboard" ein Action-Replay ROM spielen kann und einen Clockport hat.


    Über Rückmeldungen in welcher Hardware-Kombination die Firmware benutzt wurde und mit welchem Erfolg würde ich mich freuen.
    Meine Tests waren bisher
    - RR-Net MK3 direkt in einem C64c
    - RR-Net MK3 direkt in einem C64 Reloaded MK1
    - RR-Net MK3 direkt in einem C64 Reloaded MK2
    - RR-Net MK3 über ein Nordic Replay im C64c
    - RR-Net MK3 in einem Chameleon, sowohl Standalone, in Docking-Station als auch im C64c


    Der aktuelle Stand macht in keinem der Fälle Probleme. Einen älteren Stand habe ich auch schon mal auf einem MMC-Replay mit RR-Net MK2 laufen sehen.

    Nein, mir hat die Dokumentation im Wiki gereicht: die Beschreibung, wie das ROM ein- und ausgeblendet wird, und die Dokumentation des Netzwerk-Chips. Einzig wie das EEPROM programmiert wird, wurde mir per Email erklärt.

    3x so langsam? Warum das denn????

    Einen Faktor von 2.28 als 3 anzugeben finde ich schon etwas gewagt.


    Codenet ist deshalb langsamer, weil der Code generisch angelegt ist, und nicht nur darauf ausgelegt, nur dieses eine Protokoll zu unterstützen. Ich muss z.B. um ein Datenpaket aus der Hardware zu lesen mit 16 Bit Pointern arbeiten, statt einfach nur mit mit einem 8-Bit Offset.


    Wo im alten Code folgendes steht:
    LOOP:
    LDA DATA
    STA BUFFER,X
    INX
    CPX BUFFERSIZE
    BNE LOOP


    Sieht das bei mir wie folgt aus:
    LOOP:
    LDA DATA
    STA (BUFFERVEC),Y
    INC BUFFERVEC
    BNE NOHI
    INC BUFFERVEC+1
    NOHI:
    LDA BUFFERVEC
    CMP BUFFEREND
    BNE LOOP
    LDA BUFFERVEC+1
    CMP BUFFEREND+1
    BNE LOOP


    (Das Beispiel ist stark vereinfacht.)


    Natürlich ist das deutlich langsamer (16 zu 27 Takte im best case). Der Code ist aber für DHCP und TFTP notwendig, weil die Pakete deutlich grüßer sind als 256 Bytes. Mehr Logik ist auch nötig bei der Bewertung von Paketen. Was tun, wenn während des Codenet Transfers noch ein TFTP Upload gestartet wird? Ignorieren, klar, aber auch eine solche Abfrage kostet Zeit. Bei jedem einzelnen Paket, das reinkommt.


    Und ich habe beim Programmieren mehr Wert darauf gelegt, dass der Code kompakt und wartbar bzw gut erweiterbar ist. Speed war nicht der primäre Fokus. Denn Software, die auf einem C64 zwar benutzbar, aber nicht mehr erweiterbar ist, gibt es schon genug.


    Wenn Dir das Codenet bei der neuen Firmware zu langsam ist, hast Du jetzt zwei Möglichkeiten:
    1) weiterhin die alte Firmware nehmen
    2) den Code schneller machen, und mir einen Patch schicken. Das ist das schöne bei Open Source: man kann mehr machen als nur meckern. ;) Ich hatte diese Möglichkeit nicht, als ich mit meinem Code angefangen habe.

    Läuft damit auch noch WarpCopy64 fehlerfrei und schnell?

    Ich habe selbst kein WarpCopy laufen, aber schon positive Rückmeldungen bekommen.


    Außerdem habe ich eben nochmal kurz Transferzeiten gemessen. Es wurde jeweils eine Datei von $0801-$FFFF übertragen. Gemessen wurde auf der Sendeseite mit dem Shell-Befehl "time". Das RR-Net MK3 lief in einem Chameleon.


    Codenet:
    Alte Firmware:3.55s
    Neue Firmware: 8.10s
    Neue Firmware, Chameleon Turbo: 0.63s


    TFTP:
    Neue Firmware: 5.21s
    Neue Firmware, Chameleon Turbo: 0.48s


    Ich glaube nicht, dass die neue Firmware irgendwelche Kompatibilitätsprobleme lösen wird. Was ich allerdings beim Coden festgestellt habe ist, dass ich weniger Probleme hatte, wenn ich die Karte über den Clockport betrieben habe.

    Moin!


    Ich habe in den letzten Jahren mal etwas Freizeit damit verbraten, eine neue Firmware für das RR-Net MK3 zu basteln. Angefangen hat das Ganze mit einem Disassembly der Original-Firmware, und ich habe so lange Codeteile ausgetauscht, bis nichts mehr vom Original übrig war. Mittlerweile hat sie einen Zustand erreicht, dass auch Individual Computers sie so gut finden, dass sie einen offiziellen Download im Wiki zur Verfügung stellen.


    Was macht die neue Firmware besser?
    - läuft nicht nur, wenn man die Karte direkt in den Expansionsport steckt, sondern auch in eigentlich allem, was Retro-Replay ROMs kann und einen Clockport hat: Nordic Replay, Chameleon, etc.
    - läuft in der Retro-Replay Konfiguration auch mit RR-Net MK1 und MK2.
    - nutzt den Turbo-Modus vom Chameleon
    - kann jetzt auch Netzwerkconfig via DHCP holen
    - kann weiterhin Codenet
    - kann außerdem noch TFTP
    - ist quelloffen, kann also auch von anderen verbessert werden
    - beim Erzeugen der Firmware können noch ein paar Parameter eingestellt werden (Default IP, MAC, Verhalten beim Reset)
    - die empfangenen und gesendeten Pakete werden auf dem Bildschirm angezeigt (Wireshark für ganz ganz arme)


    Was macht die neue Firmware nicht so gut?
    - Weil ich Pakete mit bis zu 640 Bytes lesen kann oder besser muss (für DHCP und TFTP) ist der Datentransfer etwas langsamer geworden
    - und man kann nur noch Daten ab $0800 hochladen, statt $0400


    Zu finden sind die Downloads unter: http://wiki.icomp.de/wiki/RR-Net#Downloads


    Wichtig: das hier ist kein offizieller Support-Thread, sondern der Autor steht unverbindlich für Fragen zur Verfügung.


    Viel Spaß damit,
    SvOlli

    “I was going to ask, can we use the existing cc65, or do we need a special build?”

    The CPU support is in ca65, and you can still use cc65 in c64 mode without problems, but if for using c65/mega65 features you'll need to expand cc65. If you want to go this way, I suggest starting with a C65 mode, that will enable running binaries from C65 BASIC. If that one works, you'll can think about expanding the compiler itself to use the new 65ce02/4502/4510 instructions.

    From my experience with implementing the 4510 support in ca65, I can tell you that you should support the C65 as the primary target instead of the MEGA65.

    “I've managed to get my MEGA65 to boot, though I couldn't figure out how to mount disk images, but didn't really have the time to dig in.”

    GO 64
    SYS49152

    As for the toolchain to use: if you're writing assembler there has been some effort on several assemblers to include the 4502/10 instruction set: 64tass, acme, ca65 are all decent assemblers supporting all instructions of the CPU, Orphis also does, but that's a pain in the a** from the users point of view.

    But the work of migrating software to a non-1541 kind of drive has already been taken care of. Look for software modified to run on the sd2iec or the 1581.

    Also if I take a look around at demoparties, I didn't see anyone using a disk drive any more. 1541-ultimate or Chameleon are used with disk images. Even for the the C128 with burst mode there is a patched version of the sd2iec for that.

    “Nobody knows wether the C65 supports the burst mode of the 1571?”

    Sure we do. Take a look at: https://github.com/MEGA65/c65-…ster/c65manualupdated.txt

    The chapters starting at lines 13586 and 13657 state the burst load exists, but burst save doesn't.

    Nevertheless, I can see the desire for wanting JiffyDOS or something alike. (I'm asking for parallel cable support in the Chameleon constantly, to get SpeedDOS/DolphinDOS running.) But this should be something that can be taken care of as a community effort after the release. Something like a github-repo containing different flavours of the firmware, as there are a lot of ways the kernal can go, as the mass of patched C64 kernals shows...

    The loading speed of the MEGA65 from a D81-Image is blazing fast: if you read a file that span the whole disk just using kernel routines, it will take about 15 seconds.

    Only cause for using Jiffy would be "legacy" hardware like a 1541, mostly for "migrating software". For 3.5" floppies would will most probably use the internal drive, SD-card readers like the Atmega based ones are rather pointless, because the MEGA65 is also planned to have SD card support.

    Imho, a good solution would be either a community-patched kernel or a program that patches the kernel during runtime. I'd also suggest to go for an open source reimplementation of the JiffyDOS serial line protocol, because of the copyright.

    Also note, that the internal floppy would not benefit from any *DOS floppy speeder, as it is not connected via a bus (serial or other), but running as a different configuration of the C65 CPU. I also remember reading a statement of one of the engineers of the C65 that the floppy is rather slow due to that design and that there's not much room for improvement.

    The C65 is lacking support for tape on all levels:
    - no connector, not even conducting paths on the board
    - the io-port $00/$01 was moved from 6510-CPU to VIC-III and only support the lowest 3 bits (ROM banking), bits 3-5 (which were used for tape) are "dropped"
    - the C64 kernel got all tape routines removed

    And why would you still want tape? You've got a floppy drive built in.

    I noticed that the Keyrah V2 has some serious ghosting issues. We were trying to play Mario Bros with 2 players and it was possible to block the second player from going left when the first player did something like "move up+right and pressing fire" (it wasn't the exact problem, but is was something like that...)

    @LGB: as you can see from the kernal message, it is not unexpanded, but seems to be maxed out.

    I've been digging through the docs of both 65816 and 4510. If the 16 bit features of the SuperCPUs 65816 are used, porting would be rather a rewrite. The 65816 is capable of way more stuff, where as the 4510 is slightly faster running 65sc02 code (the codeset both CPUs can execute).

    And to be honest: if I would have to design a computer state at '91 and had to choose one of the 6502 descendants, it would have been the 65816. 4510 would have come in second.

    The ROM has to be licensed. What will be included depends on that license.

    I hope, we will be allowed to put up a github repo containing source code that can be assembled to a complete firmware image (hopefully together with a test-suite that shows if a change/extension to the firmware "behaves well").

    I'd also like to add a few gimmicks to the C64-mode as well, like some way to show a directory without losing your program. (Right now, I favor a load"$",8,1 will be hijacked and prints out the directory right after writing "loading". I've seen this in one of the many modified kernals for the C64.)

    I just dug through my ROM dumps:

    910111.bin: THE COMMODORE C65 DEVELOPMENT SYSTEM
    910429.bin: THE COMMODORE C64DX DEVELOPMENT SYSTEM
    910523.bin: THE COMMODORE C64DX DEVELOPMENT SYSTEM
    910626.bin: THE COMMODORE C64DX DEVELOPMENT SYSTEM
    910828.bin: THE COMMODORE C64DX DEVELOPMENT SYSTEM
    911001.bin: THE COMMODORE C65 DEVELOPMENT SYSTEM

    So it looks like they changed it and then back again.

    Since this machine is surpassing the C65 by far, so imho C64 Mark II or anything alike is out of the question. The name MEGA65 is quite matching, and leaves also space for other similar projects.

    Let me give you an example: on the 2600, the clock is divided by 3 by the TIA. Let's say, you build a version with a control register, that lets you drop that divider and clock the CPU three times as fast, include options to run games from cartridge and mass storage alike, you'll get a 2600 on steroids, maybe a MEGA2600, or MEGA26. So if something like this will happen as a successor, there would already be a brand to build upon.

    If it can be made it a Commodore MEGA65, it would be fine, if the price is fair. On the other hand, as a compromise, just having a licensed C= key on the keyboard would also be cool, if the name Commodore is too expensive.

    P.S.: the Mega65 claims to be (at least almost) 100% C65 compatible. Since a PAL C65 is not 100% compatible to an NTSC C65, I'm asking: which one?

    This is not about the output, but about the timing:

    frames per second: 50 on PAL, 60 on NTSC
    C64 cycles per line: 63 on PAL, 65 on NTSC
    VIC-II total lines: 312 on PAL, 263 on NTSC

    When you're coding effects that are close to the hardware, you can't just switch from one system to the other. E.g. almost all demos for the C64 run on PAL hardware only.

    There is something that I stumbled over today.

    Is the Mega65 an NTSC or a PAL machine, or can it run both?
    I'm not thinking about the video-output, but the differences like frames per second, lines per frame and cpu cycles per line.

    If it can run both, how is decided which mode is active?

    Greetings,
    SvOlli