Hallo Besucher, der Thread wurde 7,7k mal aufgerufen und enthält 30 Antworten

letzter Beitrag von peiselulli am

ML-Monitor (DTVMON)

    First of all, sorry for posting in English. I am not so good at writing in German, though I can (mostly) read German fine. :)


    I have released an improved version of my ML-monitor.
    Hope you find it useful!
    /Daniel


    DTVMON 0.2 (info page here)

    • Boot Menu.
    • Installs as resident at $018000-$01BFFF.
    • Handles full memory banking (ram and flash).
    • Additional DTV V2/V3 opcodes.
      SAC #imm ( Set ACcumulator mapping )
      SIR #imm ( Set Index Register mapping )
      BRA rel ( BRanch Always )
    • Some documentation included. (original HESMON 1.1 documentation: here)
    • NTSC version for the Hummer Game included.
      (needs patched kernal (scroll to bottom) for I/O to work correctly)


    Download: dtvmon-0.2.zip

    I have patched your version 0.5 to add the possibility to run alternate kernals.
    On my DTV, I have added the EXOS V3 kernal to speed up loading from disk.


    With this patch, a kernal can be flashed at 0x1fe000 and activated via boot menu.
    (like the ROM switches on the real C64 that the most users had in the past)


    Because of my patch is done really nasty, I think you can add this feature in some of your next releases of your DTVMON


    Here is my little patch:


    Cool!
    I was thinking about it, but haven't added it yet. Maybe it's time to update the monitor.


    Does EXOS V3 work fully with the DTV? ( i.e does both load and save work reliably?)
    Some savers seem to have timing problems on the DTV as there is a slight timing difference somewhere.


    Could you also post the kernal?

    hmmm.... exos v3 works fine on my dtv...


    ...although I am not sure if it even has a fast - SAVE routine (haven't tested that, yet)


    but the loader works fine.


    I also made a litte fix for the f-keys, and mapped the f7 (directory function) to f3,
    cause f7 doesn't work on the keyboard
    (I know, it's mapped to the second fire-button, but it's more usefull on the keyboard)

    Ah, that explains it. I've only seen savers that fail.


    I'm a bit interested to include fast load/save into dtvmon. I've had a look a Krill's load/save which looks good. The saver fails, but I think a single nop will fix that.


    One issue is that many people run dtvmon with 64hdd or 1581's, so switching the turbo on/off must be easy.
    Probably the default has to be settable somewhere, or non 1541 owners will go nuts. ;)


    Any of you don't have any other loaders/savers to recommend? It has to run from ROM.

    I have tested a program called "hypra save". It seems to work on my DTV.
    It was published in the old days from the 64er magazine. But with 6 Blocks I think it is to big to fit into a kernal containing a fast loader, too.
    The fast loader of EXOS was one of the fastest loaderss I knew in these old days. Perhaps your loaders are faster, I don't know it.


    I have also added a small fastloader from the same disk I had the hypra save from. But it is not very fast in comparison to the one in EXOS.
    I knew that there was a kernal with hypra-load and hypra-save all together in a rom in these days but I could not find it in the internet now.


    By the way : I have tried to disable the screen blanking of the EXOS rom and disables the bad lines of the DTV vie the corresponding extra DTV registers. The loader itself works, but they do some terrible thing with the lower 2 bits of $dd00 so the vice base was shifted elsewhere during loading.

    Zitat

    Originally posted by peiselulli
    I have tested a program called "hypra save". It seems to work on my DTV.
    It was published in the old days from the 64er magazine. But with 6 Blocks I think it is to big to fit into a kernal containing a fast loader, too.
    The fast loader of EXOS was one of the fastest loaderss I knew in these old days. Perhaps your loaders are faster, I don't know it.


    I have also added a small fastloader from the same disk I had the hypra save from. But it is not very fast in comparison to the one in EXOS.
    I knew that there was a kernal with hypra-load and hypra-save all together in a rom in these days but I could not find it in the internet now.


    Thanks, I'll check them!


    Zitat

    By the way : I have tried to disable the screen blanking of the EXOS rom and disables the bad lines of the DTV vie the corresponding extra DTV registers. The loader itself works, but they do some terrible thing with the lower 2 bits of $dd00 so the vice base was shifted elsewhere during loading.


    Yes, I know. It is pretty common to mess up $dd00.
    I tried to do this on the loader on one of Rolands demos, which I believe is a hacked out EXOS loader and ran into the same problem.


    There was a turbo called 25x turbo, which just says "Imported by BKS Odenwald" when started. That one is really fast. The code is pretty evil though. I don't think it would be trivial to port it to ROM code.

    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 ?

    My initial idea was to include this into dtvmon, making it a full utility rom, much like the AR is.
    No freezer though. ;)
    There is nearly 8Kb left in dtvmon, so this would be no problem.


    If you want to do it by a kernal patch calling some other part of the rom, I would not use $d101 bank switching.
    There is no way to switch back to what it was, as it is unreadable, and it must reside on $xxa000-$xxc000.


    Better is to use the segment mapper to switch in a ROM segment at $c000-$10000 (or $4000-$8000 to avoid the I/O registers).
    This could be $1fc000-$200000, which includes your patched kernal.
    Accessing memory below rom is can be efficiently done by using dma after reading each block from disk and vice versa.


    I added your kernal activation functionallity to dtvmon btw. And added a couple of more features aswell. Expect a new release soon. :)

    New version:

    • screen shot function activated by holding '<-' + reset.
    • an alternate kernal at $1fe000 may be activated by pressing 'K'.
      (suggested by peiselulli)
    • the video mode maybe toggled back and forth between PAL/NTSC.
    • exiting to basic without doing new is selectable by pressing 'Q'.
    • the stand alone binaries are now compressed.
    • the original DTVMENU can be loaded by holding the right button.
    • nicer look.


    Download: dtvmon-0.7.zip



    Zitat

    Originally posted by peiselulli
    Works great. My version is history now ... :juhu:


    I appologize. ;)


    I've attached the turbo. I did some disection of it earlier.
    It is very evil on $dd00, and it uses ATN, so it works badly with multiple drives.
    Fast though!


    I especially like the pre-M-W-coded drive bootstrap. :)

    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 ?

    Zitat

    Originally posted by peiselulli
    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.


    You probably analyzed the init, but I write it down anyway so I don't have to look it up myself the next time I forget it. ;)


    Init:

    • There is no init except setting up the load vector.
    • The load vector points to $014b.
    • The routine at $014b copies some kernal routines ($ed00-$f0ff) to ram under kernal and then jumps to $e406.
    • At $e406 the filename is checked for '$' and device numbers below 8, at which it skips out to $f4a6 for normal load.
    • $e42c, print searching...
    • $e433 loader init starts.


    Loader:

    • $e457 copy bootstrap to drive
      At $e817 the drive code is stored, pre-M-W-encoded. Each command is terminated with a $ff marker, and the last command is terminated by an additional $ff marker.
      This code is just a small bootstrap ($0706-$075f) waiting for the rest of the code.
    • $e489 copy the real drive code by high speed transfer.
      Copies the code $e000-$e405 (inclusive) to $0300-$0705, resulting in code from $0300-$075f.
      The drive then jumps to $04af.
    • $e4b2 speed load the entire track 18 for fast file finding.
    • $e4d1 find the file with wild cards.
    • $e529 file found, t/s to $b4/$b5
    • $e542 print loading
    • $e549 check for invalid track. Luxury! :)
    • $e55c send track number
    • $e566 load entire track.
    • $e56d sector out of range for track?
    • $e573 load sector data from track buffer until the track changes, after each loop call $e59c to flush the buffer to memory.
    • $e593 file loaded, flush buffer by calling $e59c a last time.
    • $e599 exit out, done.


    Load entire track at $e725:

    • $e725, inialize sector count, set number of sectors to $a3. Start on sector 0.
    • $e742, call $e61f to get one block in two halves from drive to $fe00/$ff00 and merge it into $e900+sector number using the two 32 byte tables at $e7ab and $e7cb. Checksum to $d7.
    • $e748 add interleave 3.


    The transfer routine at $e61f seems very cycle exact indeed, but it works. :)
    I wonder if it works on NTSC.


    Anyway, as this starts by transferring sector 0, I believe there is room for improvement.
    It could send whatever sector was just read assuming it wasn't read before.


    Zitat

    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 ?


    This is part of the drive code for data transfer. I haven't examined it more yet.


    Anyway, it looks possible to modify this for residing in another segment, say $4000-$6000. It could then like I suggested above reside in the same segment as a patched kernal, e.g $1fc000-$200000, or in RAM $xxc000-$xxffff. With some modification, DMA could be used for data transfer.


    I attached the turbo split into its parts.

    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 was thinking the same when I went for a walk just now. It's a good idea. Maybe I'll try and make a patch version for ram just to test it.


    Zitat

    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 ?


    This is a good idea, very clever!
    A quick test in dtvmon says it works perfectly! :)


    Only works with bank 0 though, but that should be enough for loading files from basic.

    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 ?