Dreamload für MMC64!

Es gibt 98 Antworten in diesem Thema, welches 21.413 mal aufgerufen wurde. Der letzte Beitrag (13. September 2007 um 22:52) ist von BastetFurry.

  • Zitat

    Original von sauhund
    ich persönlich frag mich an der stelle warum "man" sich so sträubt das bischen kernelkompatibilität ins bios zu bauen, das kann nun echt nich so schwierig sein


    Da täusch' Dich mal nicht. Ich persönlich halte das für nicht durchführbar. Sicher könnte man die Vektoren für LOAD/SAVE umbiegen. Das taugt aber nur als nette Spielerei. Spätestens, wenn die Software direkt auch CHRIN, CHKOUT u.a. zugreifen will, guckt man wieder in die Röhre. Diese ganzen Sachen im BIOS unterzubringen, halte ich für unrealistisch.

    Naja, man soll zwar nie "nie" sagen. ;) Aber zur Zeit bin ich persönlich mit den vorhandenen Möglichkeiten und der Aussicht auf das kommende. sehr zufrieden.

    Jedem das seine. :)

    CU
    Kratznagel

  • Zitat


    Ich bin mir jedoch auch bewusst, dass fruchtloses rumgebashe immer der leichtere Weg ist, weil schön einfach.

    soso, rumgebashe. wo denn? falls du dich dunkel erinnerst - das mit der kernelunterstützung war DER punkt den "wir" schon bevor jens überhaupt ein einziges mmc64 produziert hat angemerkt haben. *imho* ist das ein killerfeature was das ganze von einer netten spielerei zu einem wirklich benutzbaren massenspeicher machen würde - und auch der grund warum das iec2ata teil dagegen anstinken kann.

    Zitat


    Da täusch' Dich mal nicht. Ich persönlich halte das für nicht durchführbar. Sicher könnte man die Vektoren für LOAD/SAVE umbiegen. Das taugt aber nur als nette Spielerei. Spätestens, wenn die Software direkt auch CHRIN, CHKOUT u.a. zugreifen will, guckt man wieder in die Röhre. Diese ganzen Sachen im BIOS unterzubringen, halte ich für unrealistisch.

    warum? klar ist das ein bischen arbeit, und wenn es richtig gut werden soll würde man auch eine menge testen müssen - aber für unrealistisch halte ich das auf keinen fall. den kram testweise für meinen seriellen fileserver zu implementieren hat mich 2 tage gekostet oder so, wenn man die fat routinen eh schon hat sollte das kein grosses thema sein - mal abgesehen davon das man eventuell was stricken müsste das mit möglichst wenig ram im c64 auskommt (das es da nich zumindest ein paar kb buffer auf dem cartridge gibt war imho eine dumme idee, das würde vieles sehr viel einfacher machen)

    Zitat


    Wie gesagt, es ist Deine Entscheidung, das MMC64 nicht zu benuzen, was auch völlig OK ist. Nur, wie gesagt, was genau bringt Dir diese Diskussion dann hier?

    sagen wir mal so, würde es eine lösung geben die kernel-kompatibel ist würde ich mindestens zwei von den teilen sofort bestellen :)

  • Zitat

    Original von sauhund

    soso, rumgebashe. wo denn? falls du dich dunkel erinnerst - das mit der kernelunterstützung war DER punkt den "wir" schon bevor jens überhaupt ein einziges mmc64 produziert hat angemerkt haben.

    Welche Diskussion meinst Du? Auf der RCC04? Da ist nicht wirklich etwas sinnvolles bei rausgekommen, sorry... Außerdem hat das Ganze immer noch nicht das geringste mit Dreamload zu tun, wogegen Du momentan hier teilweise dagegenwetterst.

    Zitat


    *imho* ist das ein killerfeature was das ganze von einer netten spielerei zu einem wirklich benutzbaren massenspeicher machen würde - und auch der grund warum das iec2ata teil dagegen anstinken kann.

    Geschwindigkeitsmäßig kann das IEC2ATA nicht mal ansatzweise gegen das MMC64 "anstinken". Wie gesagt, Kernel Lösungen gibt es teilweise bereits. Außerdem ist IEC2ATA auch nicht DIE perfekte Lösung, da Fastloader trotzdem nicht drauf funzen. Wenn schon ´ne IEC Lösung, dann richtig. Ferner: nenn mir mal eine Hardware auf dem C64 (23 Jahre alte Retro Maschine) , die keine "nette Spielerei" ist. ;)

    Zitat


    warum? klar ist das ein bischen arbeit, und wenn es richtig gut werden soll würde man auch eine menge testen müssen - aber für unrealistisch halte ich das auf keinen fall. den kram testweise für meinen seriellen fileserver zu implementieren hat mich 2 tage gekostet oder so, wenn man die fat routinen eh schon hat sollte das kein grosses thema sein - mal abgesehen davon das man eventuell was stricken müsste das mit möglichst wenig ram im c64 auskommt (das es da nich zumindest ein paar kb buffer auf dem cartridge gibt war imho eine dumme idee, das würde vieles sehr viel einfacher machen)

    Gut, wenn das so einfach ist, dann sollte es doch kein Problem für einen C64 Software Crack sein. Ich habe jedem, der Hilfe will, meine Hilfe angeboten, JEDER kann mich anmailen, und er bekommt Sourcecode von mir. Die ersten alternativen Biose, die ich gesehen habe, sahen schon vielversprechend aus. Nur weil die Situation JETZT noch nicht perfekt ist, heisst es nicht, dass es auch so bleiben wird. Bleiben wird sie durch Maulhelden, die nix besseres zu tun haben als andere Projekte niederzumachen.

    Zitat


    sagen wir mal so, würde es eine lösung geben die kernel-kompatibel ist würde ich mindestens zwei von den teilen sofort bestellen :)

    Schön und gut, aber wie gesagt: was hat das mit Dreamload zu tun?

    3 Mal editiert, zuletzt von Oliver_A (18. Januar 2006 um 23:49)

  • Zitat

    Original von Oliver_A
    Schön und gut, aber wie gesagt: was hat das mit Dreamload zu tun?


    das frag ich mich als aussenstehender auch....
    -----------------------------------------------------
    fassen wir zusammen :

    es gibt Programme die mit dreamload ausgestattet sind....
    diese programme können in naher zukunft per converter automatisch zu einen MMC-file gewandelt werden...
    solange es diesen konverter nicht gibt, gibt es aber schon mal paar programme die per hand angepasst wurden...

    soweit so gut (find ich jedenfalls, auch wenn ich kein mmc hab *g*)
    ------------------------------------------------------------------
    kommen wir nun zu dem was ich "zwischen den Zeilen" dem Thread entnommen hab...

    alle bisherigen Programme mussten "per Hand" ans mmc angepasst werden, das wird also in naher zukunft entfallen...
    diese lösung zu programmieren war einfacher als ein "richtige" unterstützung von Load/save Befehle, ganz einfach weil die leute sich mit dreamload gut genug auskannten...
    diverse Leute finden das MMC nicht so toll und machen das hier auch wieder deutlich das irgendwas in der Vergangenheit nicht optimal gelaufen ist...
    ----------------------------------------------------------------------------
    und nu ? oder hab ich was vergessen...?

    so long FighterXXS
    der Pirat der die Aufregung nicht so ganz nachvollziehen kann :wink:

  • Zitat


    Welche Diskussion meinst Du? Auf der RCC04? Da ist nicht wirklich etwas sinnvolles bei rausgekommen, sorry.

    ja, da ist nix bei rausgekommen weil "das muss mit kernel gehen" und "die amis wollen das das mit geos geht" geflissentlich überhört und ein eingebauter sid player für toller befunden wurde.... jedem das seine :)

    Zitat


    Geschwindigkeitsmäßig kann das IEC2ATA nicht mal ansatzweise gegen das MMC64 "anstinken". Wie gesagt, Kernel Lösungen gibt es teilweise bereits.

    also wem jiffydos geschwindigkeit zu langsam ist dem kann man imho nicht mehr helfen...alles darüber hinaus ist doch echt völlig wurst, wenn juckt das obs statt 3 nun 4 sekunden braucht (oder so).

    Zitat


    Außerdem ist IEC2ATA auch nicht DIE perfekte Lösung, da Fastloader trotzdem nicht drauf funzen. Wenn schon ´ne IEC Lösung, dann richtig.

    ehrm. fastloader (abgesehen von jeweils aufs drive angepassten speziallösungen wie zb dreamload) funktionieren mit keinem IEC device ausser mit einer 1541/1571, das ist kein argument.

    Zitat


    Gut, wenn das so einfach ist, dann sollte es doch kein Problem für einen C64 Software Crack sein. Ich habe jedem, der Hilfe will, meine Hilfe angeboten, JEDER kann mich anmailen, und er bekommt Sourcecode von mir. Die ersten alternativen Biose, die ich gesehen habe, sahen schon vielversprechend aus. Nur weil die Situation JETZT noch nicht perfekt ist, heisst es nicht, dass es auch so bleiben wird. Bleiben wird sie durch Maulhelden, die nix besseres zu tun haben als andere Projekte niederzumachen.

    ich mache niemanden nieder, ich übe nur imho berechtigte kritik. und bevor du irgendwen als irgendwas titulierst solltest du dich vielleicht auch mal zumindest rudimentär informieren was derjenige schon gemacht hat bzw macht, sonst kann das böse nach hinten losgehen. auch mit leuten deren meinung man nicht mag kann man durchaus sachlich diskutieren.

  • Zitat

    Original von sauhund

    ja, da ist nix bei rausgekommen weil "das muss mit kernel gehen" und "die amis wollen das das mit geos geht" geflissentlich überhört und ein eingebauter sid player für toller befunden wurde.... jedem das seine :)

    Mmmhmm, jepp, alles klaro! ;) Ich wette, die Hälfte wusste zu dem Zeitpunkt noch nicht einmal richtig, wovon wir überhaupt reden.

    Außerdem (zum 3. male?): es gibt bereits ein KERNEL kompatibles BIOS, funzt halt nur mit dem RR.

    Zitat

    also wem jiffydos geschwindigkeit zu langsam ist dem kann man imho nicht mehr helfen...alles darüber hinaus ist doch echt völlig wurst, wenn juckt das obs statt 3 nun 4 sekunden braucht (oder so).

    Man kann mit dem MMC64 durchaus viel mehr machen, als einen Geschwindigkeitsrekord aufstellen, wie schnell man die 64K im C64 voll machen kann. Den Rest überlasse ich Deiner Fantasie. ;)

    Zitat

    ehrm. fastloader (abgesehen von jeweils aufs drive angepassten speziallösungen wie zb dreamload) funktionieren mit keinem IEC device ausser mit einer 1541/1571, das ist kein argument.

    Eben, deshalb muss zwangsweise für die meisten Spiele/Demos immer gepatched werden. Ist schon ein Argument, wie ich finde. ;)

    Zitat

    ich mache niemanden nieder, ich übe nur imho berechtigte kritik.

    Solange Kritik nicht ins Niveau "kann man in die Tonne kloppen" abdriftet stimme ich dem prinzipiell zu. Würdest Du das toll finden, wenn ich Deine Arbeit so titulieren würde?

    Zitat


    und bevor du irgendwen als irgendwas titulierst solltest du dich vielleicht auch mal zumindest rudimentär informieren was derjenige schon gemacht hat bzw macht, sonst kann das böse nach hinten losgehen.

    Tituliert habe ich niemanden. Ich habe eine generelle Aussage gemacht, die, wie ich finde, durchaus ihre Berechtigung hat. Dass Du Dir selber den Schuh anziehst, und mir hier plump drohen willst, macht die Sache auch nicht besser, ganz im Gegenteil.

    Ich kann mich dazu nur wiederholen: Ich habe jedem, der Hilfe will, meine Hilfe angeboten, JEDER kann mich anmailen, und er bekommt Sourcecode von mir.

    Zitat


    auch mit leuten deren meinung man nicht mag kann man durchaus sachlich diskutieren.

    Ja, das kann man durchaus, auch völlig am Thema des Threads vorbei. Jetzt fehlt nur noch die selbstkrische Erkenntnis bei uns Beiden.

    3 Mal editiert, zuletzt von Oliver_A (19. Januar 2006 um 01:27)

  • Zitat

    Original von Oliver_A
    Du hast nicht verstanden, was Dreamload ist. Dreamload ist ein Treiber System, welches ein Standard Interface für Dateioperationen zur Verfügung stellt. D.h. mit der Anpassung von Dreamload an das MMC64 unterstützt das MMC64 jetzt alle Spiele/Demos/Anwendungen, die an Dreamload bereits angepasst wurden, man braucht keinen MMC64 spezifischen Code mehr. Das einzige, was Doc Bacardi noch releasen muss ist ein D64 nach DFI Converter, danach kann prinzipiell die Party steigen. Kannst Dich ja schon mal solange mit Elvira 2 vergnügen. ;)

    habe ich es nicht verstanden? das schreibt bacci:

    ---------------
    65coupei6 wrote:
    So on the Dreamload. If I get what you are saying is that we will be able to play multiload load games? Instead of making a D64 disk image it will be a dfi disk image

    Yes, exactly that's it! There will be a tool somewhere soon to convert .d64 images to .dfi archives. If the game uses DreamLoad>=2.7 (the version with MMC64 driver), it will run on MMC64. The example is just a converted test program. No code was modified, and it runs on MMC. :)

    ---------

    also alles was mit dem code VOR 2.7 gepqatcht ist wird nie gehen..da hilft auch der converter nicht.


    Zitat

    Original von Oliver_A
    Ist immer leichter, die Arbeit von Anderen herabzuwürdigen, als selber etwas konstruktives beizutragen.

    mache ich das?
    im grunde ist DREAMLOAD ja eine feine sache, aber es bringt im moment nicht da nun IMMERNOCH KEINE multifile games gehen....ausser man patcht jetzt welche.

    ich wünsche mir halt eine lösung um schon von fastloadern befreite games zu nutzen... .. .


    T.


    EDIT: ich habe jetzt auch mal den ganzen rest gelesen...whooow! wasnstress!
    ich schliesse mich dem sauhund an und bekräftige nochmal meine meinung:

    solange das MMC64 nicht mit kernel-load&save's umgehen kann ist es nun mal ein uselessPieceOfHardware. war es möglich ? bloss noch nicht gecodet? weiss ich nicht mehr ... zumindest sowas sollte ein massenspeicher für den c64 schon haben ansonsten sollte er (noch) nicht verkauft werden ... also ich brauch's SO nicht...
    daran ändert auch DREAMLOAD nichts. ... danke

    Einmal editiert, zuletzt von tecM0 (19. Januar 2006 um 01:22)

  • Zitat

    Original von tecM0

    mache ich das?

    Yepp,

    Zitat


    solange das MMC64 nicht mit kernel-load&save's umgehen kann ist es nun mal ein uselessPieceOfHardware ...

    damit würdigst Du Die Arbeit von all den Leuten hier herab, die Bereits ihre Zeit und Mühe investiert haben, hier etwas aufzubauen. Kritik ist berechtigt, aber das ist keine Kritik mehr. Das ist dumpfes herumgebashe.

    Traurig wenn man bedenkt, dass dieser Thread eigentlich eine positive Nachricht beinhaltet.

    3 Mal editiert, zuletzt von Oliver_A (19. Januar 2006 um 01:37)

  • Zitat

    Original von Oliver_A

    Yepp,

    oh mann, ok...FEIN GEMACHT! prima hardware! echt!
    man kann sich aber auch anstellen. im grunde versuche
    ich nur mal eine antwort aus euch/dir rauszukitzeln
    ob ein "normales" kernelgeloade machbar, angedacht
    oder gar in arbeit ist !? aber egal ... .. . im moment
    verschanzt man sich hinter:

    DREAMLOAD ... kommt nun...prima. was schön wäre wenn bacci das teil
    wirklich so bauen könnte das er z.b. den loadercode extra nachladen
    würde und man dann dieses file austauschen könnte um neue "treiber"
    für zukünftige devices zur verfügung zu stellen. ansonsten macht sich
    bestimmt auch nienand die arbeit und patcht nochmal alle coolen games :(

    EDIT: da fällt mir ein...den loadercode des loaders sollte er dann schon
    mit einem simplen kernelLoad machen können ... wo wir wieder beim
    problem sind an dem auch DL nix ändert.

    T.

  • Zitat

    Original von Oliver_A
    damit würdigst Du Die Arbeit von all den Leuten hier herab, die Bereits ihre Zeit und Mühe investiert haben, hier etwas aufzubauen. Kritik ist berechtigt, aber das ist keine Kritik mehr. Das ist dumpfes herumgebashe.

    Traurig wenn man bedenkt, dass dieser Thread eigentlich eine positive Nachricht beinhaltet.

    taschentuch?
    ich habe diese/meine meinung dazu auch schon oft hier hinterlassen.
    sag' halt das normales load&save nie gehen wird...dann mache ich mir
    auch keine gedanken mehr um das MMC64 und du hast wieder deine
    ruhe vor dem dumpfen rumbasher =)

    T.

  • Zitat

    Original von tecM0
    oh mann, ok...FEIN GEMACHT! prima hardware! echt!
    man kann sich aber auch anstellen.

    Solange es einem nicht selber trifft, kann man das immer sagen.

    Gut, dann mache ich jetzt folgendes: derjenige, der es schafft, eine Kernel Laderoutine für das MMC64 zu implementieren bekommt von mir ein MMC64 aus meinem persönlichen Fundus geschenkt. Ferner bekommt jeder, der das machen will, Sourcecode und andere Hilfe von mir. Weitere Infos werden folgen...

  • Zitat

    Original von Oliver_A
    Solange es einem nicht selber trifft, kann man das immer sagen.

    ich produziere in zeiten in denen ich nicht hier im forum bin 8)
    software damit ich mir was zu essen kaufen kann. kannst du dir
    vorstellen wie kunden "bashen" können? das ist manchmal echt
    hart aber man härtet sich auch ab. also nimm's als ansporn und
    nicht als beleidigung auf, ok?

    machen wir's so: ich kaufe jetzt ein MMC64 und schicke dir täglich
    eine mail a'la

    "hallo,
    load und save geht nicht.
    bitte diese funktionalität möglichst zeitnah zu verfügung
    stellen.

    danke,
    MFG..."

    * spääsle*8)


    T.

    Einmal editiert, zuletzt von tecM0 (19. Januar 2006 um 01:59)

  • Zitat

    Original von tecM0
    ich produziere in zeiten in denen ich nicht hier im forum bin cool
    software damit ich mir was zu essen kaufen kann. kannst du dir
    vorstellen wie kunden "bashen" können? das ist manchmal echt
    hart aber man härtet sich auch ab. also nimm's als ansporn und
    nicht als beleidigung auf, ok?

    Ich gebe zu, dass ich noch einiges an Erfahrungen Sammeln muss. Mein Problem ist, ich nehme solche Sachen schnell sehr persönlich, weil ich jemand bin, der sehr genau auf die Worte und Gesten achtet, die verwendet werden (weil es etwas ist, was ich ebenfalls sehr gezielt einsetze).

    Naja, was einem nicht umbringt...

    4 Mal editiert, zuletzt von Oliver_A (19. Januar 2006 um 02:18)

  • Zitat

    Ich gebe zu, dass ich noch einiges an Erfahrungen Sammeln muss. Mein Problem ist, ich nehme solche Sachen schnell sehr persönlich, weil ich jemand bin, der sehr genau auf die Worte achtet, die verwendet werden. Das Ganze hier könnte man von da her eigentlich als Übung ansehen. ..

    auf die worte achten muss schon sein aber sich daran festbeissen bringt nichts...lieber am problem knabbern: eine lösung besänftigt jeden "basher" in "0,nichts"
    besser als eine "also nich' in den ton"-debatte! :D

    ach ja da war ja noch was...das problem:

    Zitat

    Gut, dann mache ich jetzt folgendes: derjenige, der es schafft, eine Kernel Laderoutine für das MMC64 zu implementieren bekommt von mir ein MMC64 aus meinem persönlichen Fundus geschenkt. Ferner bekommt jeder, der das machen will, Sourcecode und andere Hilfe von mir. Weitere Infos werden folgen...

    ist es theoretisch überhaupt machbar? du kennst doch die hardware!

    was noch nett wäre wenn du 10-20 MMC64's für leute die keins&kein geld aber zeit
    haben (gibt's bestimmt!) zur verfügung stellst. sie sind solange kostenlos bis
    eine lösung oder eine "das geht nicht"-meldung da ist...dann muss es bezahlt oder
    zurückgeschickt werden. der gewinner dürfte es dann natürlich 4free behalten :P
    und wenn es tatsächlich eine lösung gibt sind die 19 restlichen bestimmt auch
    verkauft .... ... .. . 8)

    weiterhin wäre ein BLOG (ihhh...ein trend...whäääää) nett wo alle leute ihre fortschritte posten können.

    (oh wie schön wären MMC64,IEC2ATA,.... BLOGs wo die entwickler nach einer coding-nacht posten "so...bett...nix geht" ... :P o.ä. posten .... bigBrother suckt aber geekWatch hat was...ich finde sowas würde entwickler und anwender mehr bei der stange halten ... naja...egal...)

    T.


    T.

    Einmal editiert, zuletzt von tecM0 (19. Januar 2006 um 02:31)

  • Ich denke, man sollte an diese Dinge etwas konstruktiver herangehen. Das MMC64 ist jetzt seit noch nicht mal einem dreiviertel Jahr auf dem Markt, und dennoch hat sich in dieser Zeit schon viel getan.

    Wem eine Sache nicht gefällt, der sollte sie ändern. Wem eine bestimmte Software fehlt, der sollte sie schreiben. Habe ich schließlich auch getan, genau wie andere auch. Warum sind wir denn C64-User? Weil wir die Dinge selber in die Hand nehmen können, wenn wir es wollen. Davon lebt letztendlich unsere ganze Community.

    Würde niemand mehr aktiv mitmachen, wäre die Szene schnell am Ende (und wir wahrscheinlich alle reine Windows-User ;) ).
    Klar ist, dass sich nicht alle aktiv an einem bestimmten Projekt beteiligen können/möchten. Trotzdem sollte niemand die Werte verkennen, die ein einzelner beisteuert. Auch wenn es nur kleine Schritte sind: Am Ende kommt oft etwas großes heraus. Und das ist es was zählt. Pessimismus ist hier fehl am Platz.

    Und letztendlich wird niemand gezwungen, eine bestimmt Software einzusetzen. Nur sollte man bedenken, dass andere vielleicht sehr zufrieden mit dieser Software sind und deswegen nicht gleich alles mit harschen Worten schlechtreden. Denn das wirkt auf andere provokativ und bringt der Sache überhaupt nichts.


    Puh, das artet hier ja schon seit diversen Postings in eine Grundsatzdiskussion aus. Das war von mir eingentlich nicht beabsichtigt. ;)

    Wie dem aus sei, ich bin weiterhin gespannt, was die Zukunft für Software bringt und bleibe optimistisch.

    CU
    Kratznagel

  • Zitat


    Außerdem (zum 3. male?): es gibt bereits ein KERNEL kompatibles BIOS, funzt halt nur mit dem RR.

    ich weiss, das halte ich aber für keine saubere lösung, das muss auch ohne gehen, finde ich :) das RR brauche ich davon abgesehen für andere sachen :=P

    Zitat


    Eben, deshalb muss zwangsweise für die meisten Spiele/Demos immer gepatched werden. Ist schon ein Argument, wie ich finde.

    ja, aber wie gesagt macht auf kernelvektoren patchen mehr sinn - dann ginge es nämlich mit beiden (und mit dem network drive vom TFR, und mit meinem seriellen fileserver, und evtl mit noch mehr basteleien, und mit zukünftigen sachen die ebenfalls auf die kernelvektoren aufsetzen auch). speziallösungen sind immer die schlechtere wahl. warum man zb nicht dreamload auf die kernelvektoren aufsetzt, zumindest was load/save und chrin/chrout angeht versteh ich auch nicht wirklich, DAS dürfte nun wirklich kein problem sein.

    die sache ist halt -und das bitte ich nicht als rumgebashe aufzufassen- das das dingen solange es nicht mindestens so kompatibel wie die cmd-hd zb ist für sehr viele anwendungszwecke unbrauchbar ist und bleibt, das ist der punkt um den es geht.

    edit: was genau ist denn da überhaupt das problem? der grosse und schwierige teil, nämlich die behandlung der FAT ist doch schon da und funktioniert ja wohl auch ganz gut, und files laden kann man ja im browser auch - da ist es doch zu einem kernel-kompatiblen load nur noch ein kurzer schritt. chrin sollte dann im nächsten schritt eigentlich auch drin sein (wie gross sind die blöcke die man da lesen muss? kann man evtl, wenn auch langsam, nicht byteweise lesen?). mit den beiden sachen würde dann schon ne menge altes zeug prima klappen. save und chrout sehe ich ein das das eklig ist, aber bestimmt nicht unmöglich :) ich würde an der stelle die -ja schon vorhandenen- FAT routinen für den grössten, schwierigsten, und auch fehlerträchtigsten teil der übung halten....den rest haben doch schon zig leute vorher zigmal für irgendwelche andren gehackten kernels gebastelt, selbst ich hab das leidlich hingekriegt für den fileserver :)

    Einmal editiert, zuletzt von sauhund (19. Januar 2006 um 05:29)

  • Zitat

    Original von sauhund
    die sache ist halt -und das bitte ich nicht als rumgebashe aufzufassen- das das dingen solange es nicht mindestens so kompatibel wie die cmd-hd zb ist für sehr viele anwendungszwecke unbrauchbar ist und bleibt, das ist der punkt um den es geht.

    Gut, das ist berechtigte und konstruktive Kritik.

    Zitat


    edit: was genau ist denn da überhaupt das problem? der grosse und schwierige teil, nämlich die behandlung der FAT ist doch schon da und funktioniert ja wohl auch ganz gut, und files laden kann man ja im browser auch - da ist es doch zu einem kernel-kompatiblen load nur noch ein kurzer schritt.

    Das Problem was ich auf dem ersten Blick sehe ist jetzt die Frage, welche Speicherbereiche man am sichersten für Bios Variablen und Banking Routinen verwenden kann. Die FAT Routinen müsste ich dann so umschreiben, dass sie ein Minimum an Speicher verbrauchen würden (momentan benutze ich Buffer, um die Geschwindigkeit zu erhöhen).

    Zitat


    chrin sollte dann im nächsten schritt eigentlich auch drin sein (wie gross sind die blöcke die man da lesen muss? kann man evtl, wenn auch langsam, nicht byteweise lesen?).

    Blöcke sind mindestens 512 Bytes gross, aber das ist kein Thema, da man nach X-Bytes ein Abbruch Kommando zur Karte senden kann.

    Zitat


    mit den beiden sachen würde dann schon ne menge altes zeug prima klappen. save und chrout sehe ich ein das das eklig ist, aber bestimmt nicht unmöglich :) ich würde an der stelle die -ja schon vorhandenen- FAT routinen für den grössten, schwierigsten, und auch fehlerträchtigsten teil der übung halten....den rest haben doch schon zig leute vorher zigmal für irgendwelche andren gehackten kernels gebastelt, selbst ich hab das leidlich hingekriegt für den fileserver :)

    Und genau das war auch der Grund, warum ich damit gerechnet habe, dass irgendjemand sich daran ransetzen würde. Ich weiss, ich könnte mich auch daran ransetzen, und es selber versuchen (werde ich auch höchstwahrscheinlich bald machen - ich habe es selber satt), aber ich habe mir gedacht, dass es so viele Leute gibt, die schon seit Urzeiten Kernels gepatched haben, die bekommen das viel schneller hin als Du. Helfe ihnen bei der FAT und MMC Implementierung, und das Thema sollte eigentlich gegessen sein...

    Das Problem ist: ich kenne die C64 Hardware (und viele andere Hardwarearchitekturen, ich hab das MMC64 sogar für mich für die PC-Engine portiert) in- und auswendig, aber ich habe mich noch nie mit dem eingebauten Kernel beschäftigt. Wisst ihr eigentlich, wie lange ich gebraucht habe, um herauszufinden, dass man Blöcke mit dem U2 Kommando (natürlich NICHT B-W...) schreibt, und das Tracks mit 1, Sektoren mit der 0 beginnen??? Da war ich schon kurz davor, meine Floppy aus dem Fenster zuschmeissen. =)

    Kurz: ich kann Hardware Designen und in Assembler coden, aber was die Kernel Strukturen angeht bin ich ein n00b.

    Naja, ich werde das mal austüfteln, und schauen, wie man das hinbekommen kann. Auch wenn ich wahrscheinlich dabei ne Menge Anfängerfehler machen werde.

    Ich werde zuerst damit beginnen, den Browser aus dem RAM startbar zu machen, und dann ein neues BASIC Kommando (BROWSER) kreieren, welches den Browser aus dem SYSTEM64 Verzeichnis lädt und startet. So habe ich dann schon mal eine einfache Plattform, um zum einen am Kernel herumzudoktorn, zum anderen aber immer den Browser mit seinen eigenen FAT Routinen habe.

    2 Mal editiert, zuletzt von Oliver_A (19. Januar 2006 um 12:00)

  • *seufz* ihr wißt schon, dass ihr gestern abend die GANZE Zeit aneinander vorbeigeredet habt, oder ? (so um die 20 postings hätten nicht sein müssen, wenn ihr konstruktiver :gruebel und weniger emotional :motz: gepostet hättet....)
    und die Moral von der Geschicht : voreilige postings lohnen nicht *gggg*

    so und nun können TecMO und sauhund an einen Wochenende zu Oliver fahren, damit die dann zu dritt die Kernel-Umsetzung zusammenbasteln können *vfg*
    ( wenn sie es körperlich und geistig unversehrt überleben, haben sie auch wahrscheinlich Erfolg.... )

    :<<<<<>>>>:

    so long FighterXXS
    the friendly pirate :wink:

  • War fast schon irgendwie lustig die ganzen Beiträge zu lesen :P :rolleyes: :D

    Ich bin jedefalls mit der MMC64 und mit dem neuen Dreamload total zufrieden 8)
    Ich freue mich über jedes Plugin :D =)

  • also mal ganz ohne Aggressionen o.ä.
    Ich finde das MMC64 ein gutes Stück Hardware. Der Transfer von D64, die man ja an der Dose nach belieben zusammenstellen kann war nie bequemer und dass Singlefile Spiele, Appz und Demos auch funktionieren finde ich ebenfalls sehr angenehm. Ausserdem ist die Entwicklung der Plugins doch noch am Anfang, wer weiss was da alles noch kommt. Sprüche wie das Teil sei sinnlos finde ich völlig daneben. Für wen es keinen Sinn macht, soll seine 50€ behalten und sich dafür ein 386er Notebook für den Datenaustausch neben seinen Cevi stellen, da hat doch keiner was dagegen.
    Ist irgendwie traurig, dass die Leute hier, genau wie in der "Amiga-Szene" sich dauernd sinnlos zoffen müssen und so eine Randgruppierung (Classic-Computing) immernoch gespalten wird. Ich freue mich einfach, dass noch neue Hardware auf den Markt kommt.
    Ich hätte mir auch niemals eine SuperCPU gekauft um dann 3 Demos drauf laufen zu lassen aber die Idee finde ich trotzdem interessant.

    Sorry wenn das jetzt etwas langweilig war alles, bin müde :)