Posts by peiselulli

    Yes, the normal kernel boots always, because it checks for DTV80, I think.
    The alternative kernal has the CBM80 stuff, so clearing the string would be nice.


    You can try it with the "lode runner" file you have already downloaded.
    In the alternative kernal, no prompt "64K RAM System" from the reset is printed
    after running.


    I think it is a good idea to clear the string when running an alternativ kernal

    One time I could "resurrect" the drive on the DTV.
    I have done the test with the attached file above in this thread.


    EXOS : no problem
    Turbo25 : no problem
    Your Speedloader : ?load error


    I have all tested 3 times.


    My 1541 is a very old drive with the serial "DA 5 08712", "MADE IN W.GERMANY"


    But I don't know if I can do the test for you once again (sniff :-< )

    I think about a broken soldering of the IEC females. there seems some ground missing.
    And that could be the reason why it still works with the XE-154 cable because of the
    software is holding a line at ground that is unconnected else. Maybe I look tomorow for this.

    Vielleicht war das ein Effekt, den ich auch habe, seitdem die Tastatur dran ist:
    Wenn ich das Gerät einfach nur einschalte, ist es manchmal im NTSC-Modus,
    zumindest, was die Bildwiederholfrequenz angeht. Wenn ich immer gleich einen Reset
    hinterherschicke, läuft er dann wieder normal.

    Hmm, I have problems to load a special file.
    The loader ends with "?load error". Sometimes the drive is recalibrating.
    I have formatted the disk (it was nearly full before) but the same things happens.


    Maybe it is the file (I have attached it) ?


    BTW, with EXOS and normal load functions no problem.

    Files

    I have a nice feature for your next release of DTVMON:
    What about clearing memory (perhaps only the CBM80 stuff at 0x8004) ?
    Some games uses this vector and if I go via "DTVBOOT" into my alternative Kernal,
    than strange things can happen.


    I clear know the memory with DTVMON, but it can be more easier to handle.
    And is fastly done :->

    Nice !


    I think I can remeber when I see at first so much speed while loading.
    I think my Version of "Wintergames" has such a fast loader.
    But I don't know if this was a feature of the cracked version ...


    ADD:
    OK. I have not done an look to your Headline.
    It was a feature of the cracked version

    Hmm, bei mir nicht !
    Da ich das jetzt nicht testen kann (icch habe eine DTV 3 Version), versuch mal, mit den Verzögerungen rumzuspielen.
    Ab 0xff00 liegen nach dem Entpacken ein paar "lda ($4b,x)" und ein abschließender "RTS".
    Das ist die Zeitschleife, die ich dazu gepackt habe.
    Änder da mal ein bischen mit rum (mal welche dazu, mal welche weg).


    An dem Ergebnis bin ich sehr interessiert ...


    P.S. : Am einfachsten ginge das, wenn Du die ungepackte Version mit dem "DTVMon"
    reinlädst. Normal liegen die Daten leider an Adressen, wo der VIC etc. residiert.

    So, das nächste Games ist fertig.
    Einer meiner Lieblingsklassiker !


    Ich habe die Version so umgebaut, daß man mit den Knöpfen A-D
    alles einstellen kann.


    Zusätzlich wird der Joystick in Port 1 nur gebraucht, wenn
    man den Zweispielermodus ausgewählt hat.


    Viel Spaß !

    Files

    • archon.prg

      (46.35 kB, downloaded 14 times, last: )

    The "only basic" idea is better than nothing but not so good for games
    that uses the normal disk functions (and I think out aim must be to replace them) if there
    has modified the $dd00 lower 2 bits (for displaying a picture, for example).
    So I looked for the code that stores at 0xdd00.
    my idea is to modify the code BEFORE starting the fastloader with the current
    setting of $dd00 lower two bits.


    So I have build up a table where the $dd00 address is used with STA, STX and STY:


    ------------------------------------------------------------------
    STA at address | value for store loaded
    ------------------------------------------------------------------
    e48c | lda #03 at e48a
    e61b | lda #03 at e619
    e621 | lda #0b at e61f
    e781 | lda #0b at e77f
    e79a | ? (comment follows)
    e7a7 | lda #03 at e7a5
    ------------------------------------------------------------------
    STX at address | value for store loaded
    ------------------------------------------------------------------
    e78b | ldx #03 at e77d
    ------------------------------------------------------------------
    STY at address | value for store loaded
    ------------------------------------------------------------------
    e641 | ldy #00 at e63f
    ------------------------------------------------------------------


    now the comment (the other cases are trivial to modify):


    the code for the store is the following (at e78e)


    ldx #$04
    lda $ff ; line marker
    lsr $bd
    ror
    lsr $bd
    ror
    lsr
    lsr
    sta $dd00
    dex
    bne e790 ; jump to marked line


    This must be the function (the only one ?) that sends data to the 1541.
    I don't know how time critical this is. Maybe and "and #0x ; or #0x" can be inserted here ?
    And what is the role of the byte in $ff ?

    another possibiliy could be the following:


    Let the code as it is (on 0xe000 to ffff with all its buffers)
    This code is copied (via dma for faster transfer) to a free RAM area of the DTV
    (maybe 0x1fa000).
    then, when entering the loader, switch via bank switching 0x1fa000-01bffff to 0x00e000 to 0x00fffff. Then the code can run nearly unchanged.


    The only thing to change is then the block copy, this can be made like you suggested via DMA to the place where the data has to load to.


    by the way (because of the bad $dd00 handling):
    Have you tested what happened if the lower two bits are switch to input via
    $dd02 ?

    I have done a little look at the fastloader.
    It seems the it reads some coded data from the drive and stores
    it at 0xfe00 and 0xff00 undecoded. Then the data is calculated to the "real" data at 0xfd00.
    But the stuff synchronizing the C64 prozessor with the drives's processor is very confusing.
    It seems that this stuff must be very cacle exact.


    There seems to be some drive code at 0xe000 and the C64 code begins at 0xe406.
    All stuff that is needed ends at 0xe900.


    Is the stuff at the beginning ($e000) that it seems to be ?
    When I look at it it looks like datas that are endcoded for the data transfer to the 1541,
    to avoid encoding it on the fly ?

    some thoughts about the size of the fastloaders for DTV
    before today I thought that the fastloaders to build into the kernal must be small because they have to fit in the space that we got from disabling the tape and rs232 routines. But this is not really true !


    Instead of making them fit into the kernal, we can put it into a replacement Basic rom that is switched via $d101 in the time we are loading and saving to disk !
    That offers additional 8K of ROM code. I think there is enough place for different fastloaders, too. Perhaps something like an autodetection detects if we have a 1541, 1581 and then select a special fastloader for the different drives.
    The positive feature of that is that there is enough place to leave the DTV flash loader functions where they stay now !


    Any opinions about that ?