Beiträge von tlr

    download: Bitte melde dich an, um diesen Link zu sehen.

    News:

    • many cosmetic changes.
    • flash identification reports if it can't get into flash id mode.
    • changed 'R' command to read identity and cfi query in a more generic fashion.
    • found a really nasty problem where interrupt was not disabled during programming.
    • working SST support. (You need tixiv's Bitte melde dich an, um diesen Link zu sehen.).
    • implemented a much better Atmel 47-series odd byte work around.
    • rewrote the programming algorithm to work in 256 byte blocks for speed, much faster now!
    • all programming is automatically verified per 256 byte block to ensure that the programming algorithm works correctly (especially on the AT47BV161T)
    • error check and reporting was much improved for the program byte function.
    • handles "device not present" conditions more gracefully.
    • full source code included.


    Bitte melde dich an, um dieses Bild zu sehen.

    Bitte melde dich an, um dieses Bild zu sehen.

    Added patch 168 with win32 binaries.

    Bitte melde dich an, um diesen Link zu sehen.

    news:
    * Cycle exact border on/off implemented.
    * 8BPP chunky overscan implemented.
    * 8BPP chunky idle fetch implemented.
    22050 HERTZ, Symmetric Overscan, Spacelane & Wide Screen Slide works 100%.
    * Corrected some cycle timings in skip cycle and burst mode
    * ColorRam/character/bitmap/sprite bank emulation.
    * X11 fixes submitted by groepaz.

    Added patch 98 with win32 binaries (x64dtv.exe and x64.exe)

    Bitte melde dich an, um diesen Link zu sehen.

    news:
    * Burst mode emulation (again hard work by nojoopa)
    22050 HERTZ works in full speed.
    Blitter Scroll now has full frame rate on NTSC too.
    * Monitor supports simple wildcards ala CCSMON for hunt. (all targets)
    e.g h 0800 ffff 8d xx d4

    Added patch 90 with win32 binary.

    Bitte melde dich an, um diesen Link zu sehen.

    news:
    * Skip cycle emulation (hard work by nojoopa)
    Blitter Scroll is now in full frame rate.
    * Extended SID support
    22050 Hertz plays samples (but too slow as it requires burst mode)
    * badline disable
    * 38 column border size (8/8 on the DTV)
    * $00/$01 changed to DTV behaviour
    * many structural improvements
    (Ghost in the Machine works since patch 64)

    The project is now in a public subversion repository.

    Zitat

    Originally posted by CBM-Hörnchen
    Ps: Ich glaub mal, dass die wenigsten normalen Anwender die Lust haben sich das Teil selbst zusammenzupatchen/kompilieren.
    Dabei haben wir uns schon alle auf ein offizielles Vice Release mit DTV gefreut. :(


    There is a precompiled windows binary on the page. Just put it in your WinVice directory and clone the C64 folder to a C64DTV folder.

    Zitat

    Originally posted by Ebster
    funktioniert der kernal-patcher auch beim patchen schon gepatchter kernals? :roll:


    The kernal patcher contains a copy of the original C64 kernal and does a clean patch from that.
    It works as long as your current kernal works enough for it to run.

    download: Bitte melde dich an, um diesen Link zu sehen.

    • selectable DTV/Hummer mode. Hummer mode will have different fallback switches and different defaults.
    • made hardcoded video timing the default.
    • added selectable ZEE palette.
    • fixed the drive number >9 cosmetic bug.
    • changed the old soft kernal patch into a switch to select INTRO or DTVMENU as the default file to auto load.
    • added option to write ram kernal to disk. (W)
    • added option to write soft kernal loader to disk. (V)
    • full source code included.

    Bitte melde dich an, um dieses Bild zu sehen.

    Bitte melde dich an, um dieses Bild zu sehen.

    lallafa reported by mail that it works correctly with his DTV with SST flash.
    He flashed dtvmon + peiselullis kernal + replaced the original kernal.

    Has anyone else tested this? I would like reports on both the SST and Atmel flashes before releasing the final version.

    Below is a pre-release of the flash tool V1.0.
    I have tested flashing quite a lot on my AT47BV161T unit.
    It has been tested on the SST39VF1681, but not as much.
    Some tests has been done on AT49BV163A aswell. That one is similar to the AT47 so it should work mostly the same.

    Even though I already reflashed my kernal with it you should test in a non-critical part of the flash before doing any serious work.
    Please report success or failures here!

    download: Bitte melde dich an, um diesen Link zu sehen.

    • Working support for the SST39VF1681 flash. (You need tixiv's Bitte melde dich an, um diesen Link zu sehen.).
    • Much faster.
    • Revised programming algorithm for AT47BV161T based on more findings. Should be both faster and safer than 0.9a. This might even solve the problems Fröhn had on his unit.
    • All programming is automatically verified per 256 byte block.
    • Safer range checking of input values. Reverse range, out of range, ...
    • Can dump the product ID and CFI area to the buffer for easy testing.


    I'm going away on vacation for a couple of weeks now.

    If nobody finds any major errors I will release the real V1.0 when I get back.
    It will be slightly adjusted, mainly for cosmetics.
    Full source code will be included.

    Regards
    /Daniel

    Bitte melde dich an, um dieses Bild zu sehen.

    Bitte melde dich an, um dieses Bild zu sehen.

    Zitat

    Originally posted by linuxholgi
    Du mußt nur ein 47pF Keramik Kondesator an einen Pin vom Flash und VCC löten. Bei mir hat es auch mit einem 56pF Kondensator geklappt.


    Yes, this hardware fix was found by tixiv.

    See Bitte melde dich an, um diesen Link zu sehen. for tixiv's explanation.

    A new improved flash tool is coming in the near future.
    The AT47BV161T algorithm has been revised too so It might even fix the problems Fröhn was having with his unit.

    Zitat

    Originally posted by 1570


    I want to implement the DTV opcodes and memory banking next - I hope this is enough to get the emulation running with the DTV's standard FlashROM (i.e., support an unpatched DTV kernal and the INTRO program). The VICII stuff seems quite complicated indeed. I don't think I can implement that. I hope this isn't used by INTRO...


    I think you will get away with DMA + extra regs/bank switching for all of the original rom.
    You can probably run dtvmon on that too.

    Zitat

    Originally posted by 1570
    Für VICE 1.21 gibt's einen Patch, der eine einfache Version der DTV-DMA Engine implementiert. Das heißt, dass man damit schonmal Flash-Images für die 2MB Flash im DTV in VICE ansehen kann.

    Das DTV-Menü geht leider (noch) nicht, da es DTV-spezifische Opcodes benutzt und Unterstützung dafür in VICE bisher fehlt.

    Bitte melde dich an, um diesen Link zu sehen. (DTV-Hacking-Wiki auf picobay.com)

    Cool! :)
    There is quite a lot to implement for complete emulation, especially the extra VIC-II stuff.

    Changes:

    • The screen shot function allows selection of upper/lower case.
    • Fixed a problem where the 'F1' directory function would hang if no drive is present.
    • Corrected cosmetic issue where the wrong menu line was colored black when no alternate kernal was found.
    • Includes full source code


    Download: Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)

    Bitte melde dich an, um dieses Bild zu sehen.

    Bitte melde dich an, um dieses Bild zu sehen.

    Zitat

    Originally posted by Roderic McBrown
    I have just seen that i have two of these V3 DTVs :wand
    Are there any news about flashing the SST chip ?


    Nope, still haven't got a DTV with the SST chip.
    Haven't heard anything on my product id mode challenge lately.

    Zitat

    Would it be possible to revert the DTV to the AT chip by simply changing the chip ?


    Yes. I'll have to check on the part number though.
    AT47BV161T is not generally available, nor desirable. There are pin and software compatible variants.

    Zitat

    Originally posted by ranseyer
    i have messured 3K Ohm at ech connection (on the first dide too)
    -and in the other direction no connection...

    (i have bo XM1542 Cable, so my next test should be at the pc ?- I have done this test at the laptop... the results are comming tommorow...)


    The XM1541 cable uses all line except the one I use for D0 unfortunately...

    If this is still on your laptop, how come it shows $ff now, but something else earlier...
    This puzzles me a lot. Is the bios set to something that allow SPP? SPP+ECP/ SPP+EPP or something like that?
    It might be on always, but wouldn't hurt to look. :)

    The file is still transferred correctly during write?

    Zitat

    -sorry for stealing you time. (if you are interesstet in Video Disk Recorder (VDR) i will help you at easyvdr.de)


    No problem.

    Zitat

    Originally posted by ranseyer
    i did this (sorry i had your command in this post not with me, but i hope it should be the same)


    Hmm, it now reports only $ff (=all inputs are 1.) Very strange.
    This was your PC, right?

    The program tries to run the port in SPP mode. There could be bios settings that disable the SPP mode completly, but I was under the impression that SPP would still be possible to enable even in EPP or ECP mode.

    Have you checked the diode for D0? Is it working, or is it shorted?

    BTW, Have you ever tried a XM1541 cable or similar on any of these machines?
    If those don't work, this will probably not work either.


    If sending files is working but it still reports errors, then it is probably an error with the diodes. When "writing" they are not necessary other than for the ACK line and the checksum.
    It could be a short circuit in the diode for D0 for example, so changing it could be a good idea.
    It could also be that the laptop parallel port works in a different way than most PC's.

    If possible, test with your other PC first. Then change the first diode if it still doesn't work.
    Also try "writing" keymatrix.prg, and the "read" it back. ("dtvtrans rd keymatrix_rd.prg"), and attach the result here. (it should be identical)