Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Kroko

Members
 View Profile  See their activity

  • Content Count

    429

  • Joined

  • Last visited

Posts posted by Kroko

  2. Posted

    I have compiled your first source and tested it on my

    krokodile cart. For me it seems to start just normal in

    100% of the cases.

     

    Maybe it would be a good idea to post the binary, then

    we are sure that everybody is testing the same thing.

     

    You only need to somehow put 1FF8 or 1FF9 on the

    adressbus. You should probably try a STA $1FF9. I

    would be interested if this changes something. The bus

    timing is differend while loading and storing AFAIK.

  3. Posted

    Here's a good idea for power resources and the cart ... Have an 1/8" jack coming off a wire from the cart that plugs into the Atari's DC power plug. Then, the regular Atari power supply could plug into the cart, and the cart would supply power for the Atari. This way there's no need for an extra adapter, which would be a pain.

     

    Prototype 2 doesn't need an extra adapter :D

  6. Posted

    I am still working on the Krokodile Cartridge, and I think it is time for a little update now.

     

    Krokocart_pt2_b.jpg

     

    I have changed a few things compared to the first design. One difference is, that it doesn't need an external power supply, when it is plugged into the 2600. In addition, it can now also be used as a Multicart. There are 4 different Multicart modes:

     

    Mode 1: 1K 2K or 4K (up to 127 Games)

    Mode 2: F8 Bankswitched (up to 63 Games)

    Mode 3: F6 Bankswitched (up to 31 Games)

    Mode 4: F4 Bankswitched (up to 15 games)

     

    It is possible to create custom MultiCart ROM-Images and download them to the device. The games can be selected with a menusystem that is part of the MultiCart image.

     

    And of course it supports standalone games. The downloading is done with a serial cable. Here is a summary of the current features:

     

    * 1K / 2K / 4K / Non Bankswitched Multicart (127 Games)

    * F8 / F8SC / F8 Multicart (63 Games)

    * F6 / F6SC / F6 Multicart (31 Games)

    * F4 / F4SC / F4 Multicart (15 Games)

    * 3F (up to 512K Rom)

    * 3E (up to 512K Rom and 32K Ram)

    * EF (Homestar)

    * FA

    * CV

     

    If we don't find lots of bugs during testing, I hope I can release it soon :D

  8. Posted

    Just Brainstorming:

     

    You are in Bank 2 and want to switch to bank 1

     

    FFF4: DEC $FE  

    FFF6: DEC $FE  

    FFF8: NOP (This byte should never be accessed, actually)  

    FFF9: RTS  

     

    when the processor is fetching the opcode from location FFF8,

    the bankswitching should take place more or less immediately. Depending on how the bankswitching logic is designed (what switching delay etc...), you switch before, during or after the fetch of the opcode.

     

    That means you could fetch

    a) the NOP from this bank (you fetch before the switch)

    b) the RTS from location FFF8 of the other bank (you already switched before the fetch)

    c) ? (i don't know what happens if you switch in the middle of the fetch) maybe you get a mix of RTS and NOP :-)

     

    So this code brings you to bank1, but you did not necessarily fetch the

    RTS. Can you try to replace your NOP with an RTS, so you can be sure that you fetch an RTS. I don't know how the emulators do the switching, but on real hardware you are only safe, if you have RTS two times.

     

    But now you have a second problem, that has to do with how a RTS is actually done by the microprocessor. Unfortunately the processor will not only fetch the RTS opcode, but will also do a dummy fetch of the NEXT byte which is at location FFF9 ! Now guess what happens :-) ... We are back in Bank 2 :-(

     

    A solution would be to put the RTS at FFF7. Then you would switch banks during the dummy fetch of the RTS (at least in theory :-)

     

    Here is what RTS does, step by step ( The PC+1 is the problem ...)

     

    +---------------+------------------+-----------------------+----------+

    | Cycle | Address Bus | Data Bus |Read/Write|

    +---------------+------------------+-----------------------+----------+

    | 1 | PBR,PC | Op Code | R |

    | 2 | PBR,PC+1 | Internal Operation | R |

    | 3 | PBR,PC+1 | Internal Operation | R |

    | 4 | 0,S+1 | New PCL-1 | R |

    | 5 | 0,S+2 | New PCH | R |

    | 6 | 0,S+2 | Internal Operation | R |

    | 1 | PBR,NewPC | New Op Code | R |

    +---------------+------------------+-----------------------+----------+

     

     

     

    And lets have a look at the Bank 1 code which should bring us to bank 2:

     

    FFF0: DEC $FE  

    FFF2: DEC $FE  

    FFF4: DEC $FE  

    FFF6: BNE $FFF9 (always taken unless FE happens to be zero...)  

    FFF8: RTS  

     

    I don't really understand why the BNE $FFF9 is needed .. but lets assume the branch is taken and we jump to FFF9. Then you switch banks again

    before, during or after the fetch of what is at FFF9. Shouldn't there also be an RTS at FFF9 ? You don't get a FFF9 on the databus, before the processor is fetching the opcode from there. But if it does so, its important whats in that cell. So i would try an RTS at FFF9 in both banks.

     

    I hope I didn't misunderstand what you want to do there ....

  10. Posted

    JMP JMP() JSR are all the same.

     

    jmp $D8D8 jumps to $D8D8

    jmp ($D8D8) jumps to $D8D8 (if you have $D8 in every cell)

     

    so the only problem would be if you get rubbish in case you switch, while the cpu is fetching the highbyte of the target, right ?

     

    But that is actually VERY unlikely ....

     

    Do you think it could be a good idea to watch databus bit 4

    and prevent the menu switch, when it is not set ?

  12. Posted

    Quote:  

    The single byte instruction opcode in bank 0 must have bit 4 set so the vectors wil jump to a rom location where the instructions are executed to reach the LDA instruction.  

     

    Ok, I see. You want to get 1,3,5,7,9,B,D,or F as the high byte of a jump. But would't that mean that Bit 0 has to be set ? Or am I missing something ....Wouldn't be funny if your jump target would be a ram adress or not adressing the rom ....  

     

    Damn, you are right of course its bit 4 :-) i was just a bit confused ...

  13. Posted

    All that is needed is a push button and the 1st 2K bank.

    1st 2K bank in 2K mode and 1st 4K bank in 4K mode, right ?

     

    The button will reset the latches so bank 0 is selected (in 2K mode).

    Should also work in 4K mode, shouldn't it ? You just have to fill 4K in 4K mode ... and put the menu in the second 4K bank .....

     

    The CPU is then going to execute the code in bank 0.

    Until it reaches the instruction that switches to the menu bank, right ?

    (which is LDA $0801)

     

    To prevent the CPU from a crash, bank 0 is filled with one single byte instruction including the CPU vectors.

    The vectors have to point to your LDA $0801, where you switch to the menu code, right ?

     

    The single byte instruction opcode in bank 0 must have bit 4 set so the vectors wil jump to a rom location where the instructions are executed to reach the LDA instruction.

    Ok, I see. You want to get 1,3,5,7,9,B,D,or F as the high byte of a jump. But would't that mean that Bit 0 has to be set ? Or am I missing something ....Wouldn't be funny if your jump target would be a ram adress or not adressing the rom ....

     

    What about indirect jumps ? Can you prevent indirect jumps to jump to ram ? Maybe only if the RAM location wich has the same address as the value of your opcode and the adress after contained a valid jump vector....Any ideas how to handle this ?

     

    I think the possibility for a crash is very small. I think I can bring down the odds even furter by using some different code

     

    Keep us informed. Even if it is not 100% safe, it may still work in most of the cases or fail only once per year :D .

  16. Posted

    The CPU is easy, because it has less pins than the other two :-)

    So the smallest of the 3 chips is the CPU.

     

    Here are some numbers that might help you:

     

    RIOT: CO 10750

    TIA: CO 11903

    CPU: CO 10745

     

    You should be able to find these numbers on the chips in your VCS.

     

    Kroko

  24. Posted

    Wow that was quick and it works well !

    Thanks :D

     

    Are PAL Gyruss rare, or why are you interested?

     

    Well, I don't own a lot of carts and I am not a collector. So I don't know if it is rare or not.

     

    The reason why I am interested is, because I want to play it on the real thing. The new version of my flashcart will not support E0 bankswitching. So the only way to play it is a non E0 bankswitched version.

     

    Gyruss actually was one of those games which made the decision not to support E0 bankswitching more difficult for me. But now that it is converted to F4, I don't worry too much about that :-)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...