Hallo Besucher, der Thread wurde 498k mal aufgerufen und enthält 7022 Antworten

letzter Beitrag von sparhawk am

Der MEGA65-Laber-Stammtisch

  • Was fehlt denn deiner Meinung nach noch Grundlegendes im ROM? :gruebel

    Wie du weißt, ist das aktuell ein Moving Target. Vor gefühlten zwei Wochen hat man im Freezer keine D81 mounten können. Geht gar nicht. Und eine Unterstützung von D64 fände ich wichtig für eine V1 des ROMs (gerade für den C64-Modus). Außerdem hätte ich gerne eine funktionierende 1351-Unterstützung (statt dem Rumgehüpfe, das wir aktuell haben). Das wiederum ist wichtig für GEOS oder GoDot und andere Anwendungen.


    In Sachen BASIC 65 ist ja hier im Forum auch der eine oder andere Vorschlag gekommen, was noch hinzugefügt werden sollte. Da gibt es aber sicherlich Berufenere als mich.


    Ich bin einfach dafür, dass man da eine Liste macht von gewünschten Features. Aber auch Bugfixes von schon vorhandenen Features, die einfach nicht (gut) funktionieren und dann daraus eine Roadmap entwickelt. Und dann wissen wir alle, wo wir uns hinbewegen und können hoffentlich Punkt für Punkt abhaken und haben schließlich eine V1, die dann fürs erste Mal gilt.


    Inzwischen können und sollen BitShifter & Co gerne die Roadmap für eine V2 des ROMs erstellen und loslegen. Ich will einfach nur mehr Struktur, mehr Zielstrebigkeit und weniger (gefühlte) Beliebigkeit. Der gezeigte Eifer darf ruhig bleiben, der gefällt mir!

  • naja zyklische Code Reviews nach den Sprints haben schon was mit Qualitätssicherung zu tun …

    Agile Entwicklung fordert keine Code Reviews nach einem Sprint. Ich vermute mal du meinst die Retrospektive, aber die hat nichts mit Codereview zu tun, sondern damit festzustellen was im Sprint gut oder schlecht lief. Bezieht sich aber nicht auf guten oder schlechten Code, sondern eigentlich mehr auf die Zusammenarbeit oder andere Ereignisse. Codereview wäre Teil des Sprints und sollte im Idealfall Bestandteil der Definition Of Done sein. Bei uns ist das zum Besipiel verpflichtend bevor ein Branch gemerged werden kann.


    Zitat

    aber es geht bei Agilität auch darum wie man seine Kunden frühzeitig in diese Entwicklungszyklen einbindet um nicht am Kunden vorbei zu entwickeln :whistling:

    Das stimmt.

  • Gleichzeitig sollten wir uns darüber im Klaren sein, dass das Kernteam erst mit der Einführung von Charge Nr. 1 ausreichendes Feedback zu neuen Funktionen erhält, die in der künftigen Kern-ROM erwünscht sind. Es muss also ein Gleichgewicht herrschen.

    Eigentlich hätte ich gedacht dass diese Funktion das DevKit hatte. Ich bin davon ausgegangen dass die ersten verkauften Einheiten dann dem finalen Endprodukt entsprechenwürden. Gut, ich persönlich habe kein so grosses Problem damit, weil ich versuche auf der Hardware zu arbeiten. Solange die Floppyfunktionen über die Standardkernel calls funktioniert ist mir alles egal. Mehr brauche ich nicht. :D

    Zumindest wenn sich die Hardware nicht mehr verändert. Wenn ich dann aber lese dass sich z.B. das ColorRAM verschiebt dann wäre das natürlich schon ein grosses Ärgerniss.

  • Aber auch Bugfixes von schon vorhandenen Features, die einfach nicht (gut) funktionieren und dann daraus eine Roadmap entwickelt. Und dann wissen wir alle, wo wir uns hinbewegen und können hoffentlich Punkt für Punkt abhaken und haben schließlich eine V1, die dann fürs erste Mal gilt.


    ... Ich will einfach nur mehr Struktur, mehr Zielstrebigkeit und weniger (gefühlte) Beliebigkeit.

    Hier bin ich voll bei dir! Ich habe mich in den letzten Monaten schon öfter gewundert, dass es für das MEGA65-Projekt keinen Fahrplan gibt (zumindest keinen nach Außen kommunizierten). Wenn ich hin und wieder bei Discord so quer- und mitlese, entsteht öfter mal der Eindruck, dass selbst das Team nicht so recht weiß, was als Nächstes entwickelt wird. Und Paul oder Bit Shifter manchmal den Rest des Teams mit vollendeten Tatsachen überrascht. :)


    Die Geduld mancher wäre vermutlich etwas strapazierfähiger, wenn die Käufer überhaupt wüssten, in welche Richtung die Reise geht und welche Zeiträume man dafür abgesteckt hat. ;)

  • Die Floppybefehle werden in der nächsten ROM-Version entfernt und durch Steuerbefehle für die Kühlplatte fürs Bierglas ersetzt. :bgdev

    Das würde mich nicht überraschen! :bgdev


    Wie man das vom C64 gewohnt ist, arbeitet man sowieso mit der Hardware. Für Tastatturabfragen habe ich mittlerweile eine sehr gute Bibliothek die auch genauso auf dem C64 und C128 funktioniert.Für den MEGA65 muss ich die nur erweitern damit sie auch mit unterschiedlichen Taktfrequenzen funktioniert, aber das geht ja über die CIA Timer und wird dann auch am C64 und C128 wieder so funktionieren.


    Die Floppyfunktionen sind natürlich ein anderes Kaliber. Dafür eigenen Routinen zu schreiben, die dann zuverlässig das Filesystem abbilden, ist schon sehr aufwendig, da habe ich aber auch keine Lust um mich dafür einzuarbeiten.

    Für alles andere was man so braucht, z.B. Zahlen umwandeln (ausser Gleitkomma), Strings einlesen und ausgeben usw. das habe ich alles schon auch ohne ROM Unterstützung. Da bin ich also zum Glück nicht darauf angewiesen. :D

  • Was fehlt denn deiner Meinung nach noch Grundlegendes im ROM? :gruebel

    Weißt du, was noch eine tolle Sache wäre? Eine gescheite Implementation der SD-Karte. Das gehört vermutlich nicht zum ROM, aber das sollte trotzdem angegangen werden. Denn wir sollten uns nicht ständig um allfällige Fragmentierungen Sorgen machen müssen. Dieses Problem gibt es bei SD2IEC ja meines Wissens nach ja auch nicht. Dafür wäre eine aktive Unterstützung (Basic 65-Befehle) von Unterverzeichnissen auf der SD-Karte nett. Und: Timestamps für Files nach dem Muster von CMD. Jetzt, wo wir bald alle funktionierende RTCs haben wäre das schon ein Highlight.

  • Vielleicht waere eine generelle "Missing Features"-Liste / Roadmap eine gute Sache. Es wird ja gerne um Hilfe gebeten, aber vielleicht funktioniert das ja sogar besser, wenn die Community weiss, welche Baustellen es noch gibt. Damit meine ich nicht auf feingranularer Ebene, also in Form von Issues und Bugs usw, sondern eher so die groesseren Brocken.

  • Gleichzeitig sollten wir uns darüber im Klaren sein, dass das Kernteam erst mit der Einführung von Charge Nr. 1 ausreichendes Feedback zu neuen Funktionen erhält, die in der künftigen Kern-ROM erwünscht sind. Es muss also ein Gleichgewicht herrschen.

    Eigentlich hätte ich gedacht dass diese Funktion das DevKit hatte. Ich bin davon ausgegangen dass die ersten verkauften Einheiten dann dem finalen Endprodukt entsprechenwürden.

    Leider hat es so nicht geklappt.


    Angesichts der Tatsache, dass praktisch keine DevKit-Käufer Hardcore- oder kommerzielle Entwickler waren.


    Vielmehr waren sie Sammler, YouTuber und bestenfalls Hobby-Entwickler.


    Wie hier besprochen:


    YouTuber retroCombs kauft DevKit

  • Ja. es ist still um RetroCombs geworden. Früher war er noch sehr aktiv, wollte viel wissen, und hat auch eine handvoll Mega65 Videos rausgebracht. Einige Funktionen wurden speziell für ihn angepasst, wie das ‚Combs Flag‘ beim Kreis zeichnen. Inzwischen bringt er nur noch Videos von anderen HW Spielereien. Vielleicht ist aber auch gerade Sommerpause, oder es liegt daran das er nur über neues berichten möchte, wie vielleicht über einen 80x50 Zeichen Modus.

  • Ja. es ist still um RetroCombs geworden. Früher war er noch sehr aktiv, wollte viel wissen, und hat auch eine handvoll Mega65 Videos rausgebracht. Einige Funktionen wurden speziell für ihn angepasst, wie das ‚Combs Flag‘ beim Kreis zeichnen. Inzwischen bringt er nur noch Videos von anderen HW Spielereien. Vielleicht ist aber auch gerade Sommerpause, oder es liegt daran das er nur über neues berichten möchte, wie vielleicht über einen 80x50 Zeichen Modus.

    Targas … das ist gut gesagt.


    retroCombs ist ein MEGA65-Enthusiast, also wünsche ich ihm alles Gute.


    Mein Punkt war einfach, dass ein winziger Bruchteil der 100 DevKits an hartgesottene, kommerzielle Entwickler verkauft wurde.


    Somit, sind die Käufer von Batch #1 das Beta-Testfeld – und als Vorderkante Frühzeitige Anwender ist das ein fairer Umstand. Hoffentlich zeigen sie den Pioniergeist und tragen mit ihrem geschätzten Benutzerfeedback dazu bei, die weitere Verbesserung und Entwicklung des Produkts voranzutreiben.

  • Das mit dem verschobenen ColorRAM wurde ja inzwischen wieder rueckgaengig gemacht und die letzten ROM-Versionen vom Filehost geloescht. Fuer den 80x50 Modus wurde, wie im Discord geschrieben, eine andere Loesung gefunden. Das neue ROM wird nun intern ein paar Tage auf Herz und Nieren geprueft und nach Freigabe zum Download angeboten. Ich denke, dass dieses ein guter Schritt ist.


  • Ich zitiere einfach mal aus dem Discord:


    Zitat

    [23:33] Bit Shifter:

    I've finished my work on the final ROM and programmed a solution for attribute/colour RAM usage, that is backwards compatible
    to the ROM version 920371 and all before. This is:
    Colour RAM can be used in all text modes with a base address of $FF8.0000.
    In 40x25 and 80x25, you can alternatively use the mirrored base address $1.F800.
    In 40x25, you can alternatively use the mirrored base address $D800.

    Please don't use ROM versions 920372/73/74, where a non compatible base address was in use.

    The new ROM is currently tested by some experts and will be published, if stability is confirmed.