ML-Monitor (DTVMON)

Es gibt 30 Antworten in diesem Thema, welches 9.568 mal aufgerufen wurde. Der letzte Beitrag (24. September 2006 um 18:28) ist von peiselulli.


  • This could absolutely be doable. I'm not sure about the last one. You might have to slow down the drive code aswell.
    One work around could be to blank the screen if the bank is anything else that 0.

    There's another problem. To be able to blank the screen $d03c has to be modified to kill badlines.
    There is no way of reading $d03c, so if anything other than c64 graphics modes is used, it will be wiped (e.g 256 color mode).
    For c64 code it will work fine.

    On top of this, the segment 3 ($c000-$ffff) mapping does not work like intended, because the $01 mapping is not done on the processor view of the memory. It is instead done before segment mapping. The I/O registers at $d000-$dfff will thus disappear as soon as reg $f is changed from being $03.
    Another idea was to use $d100 mapping, but that maps as rom only, and the track buffer must be writable.

    Conclusion, go with my original approach, i.e relocate it to $4000. It seems pretty straight forward.
    I'll have a go at relocating and copying read sectors to ram using the blitter first, and then we'll see.

  • Actually I haven't tested hypra-save yet, so I don't know.
    I had some discussion on csdb about it an got recommended several pieces of software by Krill, Explorer and others.
    Most of those loaders/savers are of the IRQ allowing type. I.e not so fast but works with interrupts enabled.
    I looked at some code in old versions of Turbocopy which seem ok but not that fast.

    I'm not sure if turbo25 is flexible enough to be used inside dtvmon. It needs a whole track of buffer, and probably does not work with NTSC or multiple drives.
    Making a selectable kernal containing it would make sense though.

    My first test will be making a stand alone version of turbo25.

    Maybe you want to improve it and make it into a kernal?

  • Ok, relocation seems to be done. DMA mod partly done...

    BTW: found Bitte melde dich an, um diesen Link zu sehen. there is a disk attached to one of the posts with different speeders.

  • Zitat

    Originally posted by peiselulli
    i have done some other stuff now. look there !
    Bitte melde dich an, um diesen Link zu sehen.

    Ah. Good work!

    The DMA is working now, will package it tomorrow.

  • 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 :->

  • It's in my TODO list. It might even be feasible to clear the whole memory...
    I think DMA gets on cycle per 1 MHz clock, which means it would take about 2 seconds.

    Maybe split it into: 'c' clear lowmem (=$0800-$ffff) and 'z' clear all mem?

  • Zitat

    Originally posted by peiselulli
    Maybe a key for only overwriting the CBM80 string at 0x8004 (with TLR80 :->)


    :) Yes, that might be useful.

    Is this only needed for the alternate kernal, i.e should this option always start the alternate kernal aswell?

  • 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