"plush disk system" ... problemchen


  • Innovating
  • 2116 Views 14 replies

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • "plush disk system" ... problemchen

    Hallo zusammen !
    bin nun seit Tagen an einem, sag jetzt mal "project", beschäftigt .... ich benutze disk loader system von plush, da ich nicht wirklich das Verständnis für irq loader habe ... folgendes problem, der loader mit depack funktion geht soweit (2bit depack variante #03) (auch +H squeezer, selber effekt) , nehme ich z.B einen screen mit border oben/unten offen habe noch einen split oben irgendwo (bei #$34 z.B) bischen sprite fliegt rum ... also nix tolles, dann geht der loader .... habe ich aber meinen Hauptscreen, da wird nun bischen gfx (egal ob ich koala, draz, fl benutze) geht das auch noch, so nun habe ich mehrere splits + sprites + gfx ... erster split immer noch bei (#$34) und ein "bischen" fade in hier und da ... zb. sprite border usw ... und schon kakt mir der loader ab, er init zwar und springt auch auf den track/sector aber zerstört sich selbst (zumin.wird gfx buggie und steht alles) und alles schmiert ab ....
    habe das jetzt halt so gelöst, da ich bislang noch ganz andere probleme hatte, das ich nach dem "hauptscreen" in meinen loader part springe, indem halt nur der border oben/unten offen ist und bischen sprite im border hängen, dann geht das auch ....

    zum hauptpart :

    es werden keine zero pages benutzt( habe auch mal $dd00 spielereien weggelassen), alles läuft über tabellen und labels .... habe lediglich den ersten split bei #$34 dann bei #$60und usw. border halt f8 .... das nachzuladende packet überschneidet sich nicht mit hauptpart, geht ja auch vom "loader part" aus, das hängt irgendwie mit der faderei zusammen, vermute ich, verbrate auch ein bischen rasterzeit indem ich etwas mit dem farbram reinflashe), wird aber von einem der unteren splits angesteuert ... also alles erst ab dem "ersten" split ....

    meine Frage nun :
    möchte ja natürlich das alles vom Hauptpart aus geladen wird, wegen wartezeit und überhaupt um coding einzusparen, ist das zu wenig rasterzeit fürn loader ? bzw.kommt der damit nicht klar weil er irgendwie am anfang checkt wieviel und wo er noch rt hat, und sich das dann überschneidet mit dem fading .... oder oder .... loading setzete ich nach dem cli vom irq einsprung und d012 init bei $00...
    so, wäre wie immer dankbar, das ganze ist im moment alles andere als motivierend, da es mich von meiner eigentlcihen arbeit der gfx slaverei abhält .....
    ..... gruss inno ....
  • ok, werde ich nochmals alles überprüfen ob ich nicht beim weglassen von dd00 irgendwas übersehen habe (habe ich ja oben geschrieben) .... lt.kurzbeschreibung von dem disksys, steht zudem : d011+vic bank not influenced ... ?!? hatte ich zu anfangs als geht interpretiert ... mal sehen...melde mich nochmals ...
  • d011+vic bank not influenced ... ?!?


    das soll heissen das es dem loader a) egal ist wie $d011 und $dd00 stehen (manche wollen die badlines an bestimmten zeilen zb) und b) das er die register nicht verändert wärend er lädt. ABER wenn du wärend der loader im hauptprogram läuft im irq $dd00 änderst kann es konflikte geben (das ist übrigens bei vielen älteren loadern so). teilweise kann man drumherum arbeiten indem du am anfang deiner irq routine $dd00 liesst und am ende wieder den alten wert zurückschreibst....ob das aber mit plushdos geht weiss ich nicht, den hab ich noch nie benutzt.
  • Argh, plushdos. eine antiquität. bitte mail an mich für einen aktuellen loader. :) (krill at plush punkt de)

    was die loaderprobleme angeht, keine ahnung. zu wenig zeit oder dd00-spielereien sollten nich das problem sein, solang die bits 2-7 nich angefaßt werden. der io-bereich muß natürlich eingeschaltet sein. der loader kommt ohne probleme mit extrem wenig rasterzeit aus, er braucht dann einfach nur deutlich länger.

    grüße,

    gunnar.
  • ja, ach.. mal gucken. dafür muß zuerst mal dick doku her, und das is n haufen arbeit. aber ich hab mir letztens nen server klargemacht, um da nen buildservice drauf laufen zu lassen, daß sich die armen user nich mit dem assemblieren des loaders rumplagen müssen. jetzt fehlt nur noch die muße, um das ding mal zu coden.. :)
  • ok, thx ... @sauhund + @krill ...<-- habe dich übrigens bereits angeschrieben :) ... nunja, beim testen vom $dd00 "weglassen" hatte ich die switcherei zwischen #$03 + #$02 beide auf #$02 gesetzt....mmmmpf , nach den Antworten zufolge ging das natürlich auch nicht, wenn ich die komplett weglasse, also am anfang vom loader init setze geht das natürlich ... .... ich muss nun das ganze zusammen mit bank 1 + 2 also bit 1 und 2 irgendwie zum laufen bekommen



    !!! wird alles natürlich crediert, wenn es kein prob.für euch ist :) ....
    gruss inno !



    ** edit : habe mail erhalten !

    The post was edited 2 times, last by Innovating ().

  • hello again, habe neuen (anderen) loader als source damals bekommen, ich habe mich nicht weiter mit beschäftigen könnnen, da wird wohl cygwin, ca65, pucrunch usw benötigt um daraus den loader zusammen packen ... leider habe ich vom erschaffer keine antworten mehr erhalten ... :nixwiss:.. , kenne mich mit dem krahm auch nicht wirklich aus (loader erst recht nicht, nie mit befasst), kann sich das mal jemand anschauen und versuchen den loader zu erstellen ? ich brauche "nur" so ne art init und loader adresse am ende, am besten alles ab $c300 ($c-d$)

    beste grüsse Innovating

    The post was edited 2 times, last by Innovating ().

  • Ich habe einfach Dreamload2.3 genommen.
    Lässt sich spuer Customizen, braucht nur 512Byte und auch dd00 spielereien sind über dd02 möglich... wird in den Docs beschrieben...

    Und zum packen bzw. entpacken nehme ich exomizer, da is ein einfacher Entpack-Source dabei.
    Das ist zwar dann zwar hintereinander also kein entpacken während dem einladen, aber es läuft super gut.
    Vorallen Dingen kann man auf dem PC crunchen und dload customizen. Das machts insgesammt einfacher, wenn man eh crossdevelopt.


    Gruß,
    C.Joke

    PS.: bei Fragen einfach fragen...

    The post was edited 2 times, last by CJoke ().

  • danke fürn tip, allerdings möchte ich schon einen der beim laden entpackt und das alles recht fix, (wenn das mit dem dreamload alles schnell und gut geht, also wartezeit beim entpacken, rt ?) vielleicht ist doch jemand da um sich das mal anzuschauen .... ?

    gruss Inno

    The post was edited 2 times, last by Innovating ().

  • Naja, es sind alle Sourcen da.
    Im Prinzip war/bin ich zu faul. So fies sind die Wartezeiten dann auch nicht,
    je nach dem wieviel Zeit der IRQ nebenbei halt lässt.

    Ein entsprechen Source für decrunchen beim Laden gibts beim exomizer.
    Und der Source vom DreamLoad is auch dabei...
    Sollte also gehen.
    Eigentlich muss man ja nur gucken wo Dreamload die Daten in den Speicher schreibt und an der Stelle dann Exomizer aufrufen.

    Gruß,
    CJ
  • Users Online 1

    1 Guest

  • Tags