Posts by sailor

    Updated blogpost with information about emulation (MAME) , about the CPU speed when running Forum64 edition with latest ROMs and about the missing ramdisk in 1.3 / 1.3e.


    Thanks to you guys for the information.: thumbup:


    Hi,
    a little update at http://blog.worldofjani.com/?p=3460 :)


    2020-02: Added The Final Chesscard as The Final Cartridge 3 .crt image for debugging purposes.

    2020-02: Added english crom 1.3e, disassembled and translated into english.


    Thanks to Bart (Amon_RA on Twitter) for sending me a reproduced TFCC PCB by bwack. Also thanks for help in testing and verifying the crom 1.3e!



    It was quite some work to translate the 1.3 German into English, lots of references to take into consideration (do a binary compare to see :huh:).
    The Final Cartridge 3 .crt images are only for debugging, does not work in emulator.
    Perhaps it will help in developing support for TFCC in emulators.




    Not sure if it helps, but if the chesscard side("FCC-ROM") fails to initialize, the c64-ROM is programmed to display a black screen with white stripes... a black screen only might be the C64 ROM not starting up.


    Now I got a bit curious to test if the C64-ROM can be any valid cartROM.. in theory it should/could work, which might help to determine if the C64ROM-side is ok...


    hi,


    @kinzi, sorry I didnt get a notification of the PM, but I got a notification when I was mentioned in this thread.


    Interesting discussion, and there IS a bug with the CIA/U1/U2. I was notified by Trasher/FLT of the bug some time ago. He has made a custom version which is not public, I will try to see if i can get hold of that one.


    Just to clarify, the(my) original disassembly is identical to the original. The kernel detection version only replaces the kernel detection routine and no other changes have been made.


    I might have Ted's version in sourcecode. I can put it online.. and yes. there should be some kind of version handling of the sources instead of all patching(GitLab perhaps). I personally will not be having time for maintaining it though.


    I will notify Trasher/FLT of this thread too.


    //Jani

    Hi,
    Got a message to my blog, could someone test the statement below is correct?
    Regards
    Jani

    Quote

    Comment:
    Hi Jani,
    The interrupt test is expected to work on Diag586220, diag586220plus and diag586220plus_0.4. Status is changed if the user port dongle is attached or not.


    But then it seems OK in Diag-586220-SX-64-fixed, Diag-586220-SX-64-fixed-08-2017-Update and 586220ted even without harnesses.

    defective RAM does not have to be scorching hot.


    like @ADAC said, its common with RAM chip failure. Bad RAM can be a sign of bad PSU, make sure its ok before retrying.


    You could try to replace RAM with good known memory, swapping two chips is done pretty quickly.


    Dead Test would give you a good hint. If it manages to start the diagnostic, the machine is "alive". If Diag fails to start, then you got a bigger problem. It can take up to 10? or so seconds for it to start since it runs memorytest before displaying anything.

    It seems that it checks for the first byte in the charrom, and if that is not 0x3c it will give bad PLA.


    Gave it a quick look and I assume it tests the machine manages to switch ROM/RAM properly.... It requires the first byte of BASIC, KERNAL and CHAR to be untouched.


    You shouldn't have the byte to be checked($d000) to be 0x00 or there will be no differance in RAM or ROM...


    Don't have a solution for it currently, but hope this information helps atleast :)


    Edit: Didnt they(commodore) try to change the position of the "dot" of letter i when they worked on the C128 ? ... it caused Koala Painter to fail since it copied the font and filled the background instead of the dot. Not sure how the case is here though.

    Hi all, my german is second to none but google translate works :)


    The version by Ted is an extension where he added the chipset names for SX-64 ( they differ from C64).


    Original 586220 will give you BAD on charrom if that has been changed, my version will just show the checksum.


    ...did I understand correctly that changing the CHARROM will give bad PLA ? Is the CHARROM in question downloadable somewhere ?


    Regards
    Jani

    Hi,


    The original chesscard draws a lot of power, it does not always boot with an old psu. A modified C128 PSU works ok.


    After i changed to a custom switched PSU, it works ok. Never had any problems with the FCC64 edition.


    //Jani

    Having a kernal with banking would be really neat. (I have made a (unpublished) DTV kernal which has a toolmenu with filecopier,diskcopy,monitor and fastload. It banks in memory above 64K to fetch/exec code and returns to kernal when done.)

    It kind of boils down to free memory.. there is literally no free memory left (10 bytes or so, with reservation for F-key mods). I had a check for $8000 but IIRC the md64/71/81 ate the last of the memory at that point.. so, I had to choose to have a mem(cart)check or discard md64/71/81. Something has to go, to be able to add more functions.. In this case the MD64/71/81 seemed more useful. (The RS232 routines are removed, so nothing to optimize there.)


    I think both Tom-Cat and Wiesel have valid points here.


    On the second hand, I don't think it is a real life issue, or a very small one... what's the likelihood trying to debrick MMC while running Jaffydos ? ...but again on the other hand, it for sure could cause problems like Wiesel says. Totally valid.


    For (in)compatibility issues, i think the bigger problem would be Tape and RS232, which are both removed. In that case you should have a switchable kernal (like I assume many of them users have).


    But in the bigger picture, I don't think Jaffydos introduced an incompatibility, I think it introduced a compatibility with SD2IEC.


    thanks for the feedback, you got me thinking, so maybe I should revisit the idea of check at $8000 :)