Bmack36

You can still access the RF or composite output for the Exp Mod 1 after putting in an F18a. You won't get CV games on the RF/composite since the TMS is removed, but the 2600 will use that output since it doesn't go to the through the F18a.

Correct distance. Too close and the snake will bite. Too far and you will land on the snake.

You can jump over the snake. You just need to make sure to jump from the correct location so that it doesn't bite you.

Not sure who the poster is there, but I question their capabilities to create a core if they think the Mister and Phoenix CV cores are the same. I also like how he is concerned with Phoenix "taking others work and using it in their product" when that is the exact purpose of open source. Now it is completely different using open source code in a closed source project, but that is not the case.

145,852

107,808

22,660

12,393

29,610

28,000

23,808

47,100

25,550

https://archive.org/details/YieArKungFu The controls are the similar/same as the MSX version as far as I can tell.

68,200

Congrats Dugger! Thanks for the nod. Sorry I couldn't participate this season, I started a new job in Jan and haven't had much extra time.

Just as a heads up, the following ports are used on the Phoenix, so if you are using these ports for different purposes it is possible for games to have some weird issues. -- Extended I/O Ports -- -- Port CPU Data -- -------------- -- >50 WWWWWWWW (W) WSG / SGM-PSG Address Write -- >51 WWWWWWWW (W) WSG / SGM-PSG Data Write -- >52 RRRRRRRR (R) WSG / SGM-PSG Data Read -- >53 xxxxxx_W (W) 0 = SGM disable, 1 = SGM enable -- xxxxxxW_ (W) 0 = SGM Sound AY-8910, 1 = SGM Sound SEX-7264 -- -- >54 xxxxWWWW (W) 32K RAM bank select, 0000 is ignored -- xxxxRRRR (R) current bank -- -- >55 xxxxxxxx (R) Loader disable, PoR re-enabled ROM loader -- xx__xxWW (W) Banking scheme -- 00 None, physical cartridge, other bits ignored -- 01 MegaCart: bank is address access >FFC0+bank -- 10 SGM: Bank is data written to >FFFF -- 11 Atari: >FF80, >FF90, >FFA0, >FFB0 ??? -- xxWWxx__ (W) Select the upper memory operation: -- 00 32K Upper Internal RAM, ignores bank scheme -- 01 32K Expansion ROM, uses bank scheme -- 10 32K Upper Expansion RAM, uses bank scheme -- 11 32K Cartridge ROM, ignores bank scheme -- -- >56 xxxxxx_W (W) SD-card CE_n (AKA SS_n), 0=enable -- xxxxxxW_ (W) SD-card speed, 1=400KHz, 0=12MHz -- RxxxxxRR (R) SD-card card-detect, bit >80 1=card inserted -- -- >57 WWWWWWWW (W) SD-card Data Write -- RRRRRRRR (R) SD-card Data Read -- -- >58 00001000 (R) Machine ID, Phoenix = 8 -- -- >59 xxxWWWWW (W) MegaCart memory size -- other 512K -- 11111 512K, 32 16K-banks -- 01111 256K, 16 16K-banks -- 00111 128K, 8 16K-banks -- 00011 64K, 4 16K-banks -- 00001 32K, 2 16K-banks (same as original cart) -- -- >7F xxxxxxWx (W) 0 = 8K SGM RAM, 1 = 8K CV BIOS --

Just as another point of reference on the subject of RAM initialization

The added call to Controller_init resolves the issue.

So the issue appears to be that the controller initialization is referencing uninitialized RAM. Changes were made to Phoenix's initial RAM state so it would not have an issue with Risky Rick which looks for specific things in the uninitialized RAM like multiple 00s in a row. So the Phoenix initial ram state has some FFs in the ram. When you run these games through the Atarimax (which initializes all RAM to 00) the game runs as normal. If you hit the reset button on the Phoenix (returns ram to initial phoenix ram state), the problem comes back (Atarimax was not power cycled so ram was not initialized to 00s). The conclusion then is there something wrong with reading in the initial controller state that is not properly initializing the controller ram space.

Is the INITRAM a BIOS routine or a separate function? If so can you say what is it doing.

-

Although there may be some difference in the firmware, the fact that no other games, official or homebrew, other then EA games show this issue makes me think something is being done differently in the controller initialization code. Since the game works properly once a button is pressed it isn't an issue with reading the controller in general and just an initialization issue. What we know: -On bootup on a Rev 8 firmware there are no controller buttons actuated (ie no inputs/no buttons depressed) when running controller test roms -No other games display a controller press when booting up -When loading Cavern fighter the game appears to think a button is pressed -The game correctly identifies and reacts when the button is actually pressed and starts working correctly afterwards even through a new game -This would lead me to think something is happening in the controller initialization that is different then any other game. If we can find out what this difference in initialization implementation is, we can determine what in the firmware would affect this initialization code.

No you can't use anything before Ver 8 on 2nd Gen as the video interface is different.