pavros

Here is an enhanced version of good old International Karate. 128k of RAM is recommended. Please try HELP for more info (available on 128k). ikee2014.xex

Great! Phaeron, thanks for so fast response. :-)

Hi Phaeron, I've noticed that combinations of Shift and any console key do not work on Altirra 2.40 and 2.50. It worked fine on Altirra 2.0. Could you please fix it?

Well, this idea is fine. Adding new backgrounds to IK is something I also thought about. And it wouldn't be so hard to do. Adding new ones to IK+ however would be much tougher. The animations are strongly dependent on positions of static objects on currently existing screen (altar, tree, water). So the animations would need to be prepared separately for each new background. It would cost a lot of time and I don't think I can afford. BTW, there is already a "night" mode in IK+, switchable with N/Control-N, though no stars nor moving comet are implemented. :-).

@Tezz: I understood you ask for not stopping the music while background is switched. I'm planning to add this feature to enhanced IK version I'm working on now. @Jose: I'm going to switch back to IK+ once I'm done with enhanced IK.

Recently I've prepared slightly improved versions of International Karate (IK) and World Karate Championship (WKC) games. It has been announced on Polish fora so far but I think it is a good idea to share it with wider audience. The most noticeable change is that they both are file (xex) versions and still contain all 7 backgrounds. I know that two file versions of WKC (with 7 backgrounds) existed earlier but both had some weaknesses. One required 130XE and in the other one the bottom of screen was broken a bit and POKEY sound of paused music was not turned off for a time of replacement of the background. Here is a list of features of improved versions (same in both IK and WKC): - required RAM size is 64k (original disk versions required only 48k and could run on Atari 800), - max allowed MEMLO is $2E00, due to that the games should start under any DOS or loader, - data of 7 backgrounds is crunched with exomizer and is stored under OS ROM while game runs, - entire code is crunched with exomizer which reduces lenght of xex file (and allows for such high MEMLO), - original loading screens are included (in case of IK there is one information added regarding game speed adjustment with X and 1-4 keys), - at beginning of game loading few checks are made against available RAM size, MEMLO, cartridge or Basic presence and error messages are displayed in format equal to the originals (original cassette versions had few checks like that), - games detect video system of the machine they run on and adjust their settings accordingly to run with correct speed, - it's possible to switch to "incorrect" video settings (for people used to slower WKC on PAL and faster IK on NTSC machines) with V key at any time and switch back to correct settings with Control-V, - correct draw handling in case of two-player game - referee says "DRAW" and the fight continues instead of being immediately broken (the draw is when both fight points and scores are equal for both players) One think to remind - to force switching to another background press sequentially A, D, Z and M, where M must be pressed when fighters are fighting/standing. ik.xex wkc.xex

I've put updated demo disk image, mads sources as well as detailed description on temperature-dependent GTIA delay in this thread: http://www.atariage.com/forums/topic/209927-delayed-gtia-functions-detailed-description/

Hi, Here is a detailed description of temperature-dependent "Delayed GTIA Functions" phenomenon. An image of demo disk as well as the source code for MADS is attached. This matter was discussed in several threads: http://www.atariage....bout-the-8bits/ http://www.atariage....s/#entry1652806 http://www.atariage....00#entry1676139 http://www.atariage....ft#entry1451706 http://www.atariage....ode-for-the-a8/ It comprises the VZI mode developed by @Bryan and presented here: http://www.atariage....00#entry1677517 DGF_description.pdf DGF_demo.atr DGF_sources.zip

I put the information on this forum on 2012 Dec 20th. Here it is: http://www.atariage....s/#entry2661408 Yesterday I simply updated the files on Polish forums (atarionline.pl and atari.org.pl). I just added 3 detectors and Bryan's VZI mode pictures (http://www.atariage.com/forums/topic/136706-internal-antic-and-gtia-schematics/page__st__100?do=findComment&comment=1677517). The description of entire DGF topic is coming soon.

There are two different ways for shifting GTIA9 and GTIA10 half of pixel. One is shifting CSYNC - same as I use for this DGI 320 - but you need to cause shifting every scan line (not every second one as for DGI). Second method is to shift only data (or actually the way how GTIA joins two 2bit chunks into one 4bit). This has been discovered many years ago and mentioned somewhere on this forum, but I can't find it now. I will prepare separate demo for both methods for G9 and G10.

Well, I don't know but perhaps not all machines are able to run into DGF. Rybags, please give it a try with hair dryer so that we will know if your machine is. I've tried it on 3 machines (manufactured in various periods of time) and effect was almost the same. During summer when I had real 29 C in the room I needed nothing but to wait 30 minutes to gain DGF. In other seasons it was like 2-4 hours, so I started to use hair dryer. Anyway the machines were always on a table without any covers.

Surrounding temperature must be at least 25 C deg. In such temparature it takes about 2-4 hours to warm up. In 29 C deg only 30 minutes. BTW It's actually surrounding air you need to warm up. The chips warm up themselves.

Here it is. The demo of effect based on shifting CSYNC. There are several graphic modes we can gain out of it. The whole family I called DGF - Delayed Gtia Function. The hi-res one is DGI - Delayed Gtia Interlace. I'm planning some simple demo for the others too. In the Knight demo press 1 or 2 for subpictures, 3 for both interlaced - DGI, 4 or 5 for DGX (DGI + real tv interlace). CRT tv and s-video connection is strongly recommended. First you need to run DGF INIT and warm up the chips. Don't hesitate to use hair dryer for fastest effect (3 minutes). I'm attaching source codes for mads. DGF_demo.zip DGF_Init_src.zip Knight_src.zip

There is one more thing and maybe it's good time to share it. I've discovered it in June 2009 and made several mircroprograms to check the nature of the effect. Then I've given it up because of lack of time. This year I've started again and currently working on a demo showing the effect on quite advanced picture. The thing is related to the first entry on Rybags' list above and actually is about delaying GTIA functions of one color clock. The most important is possibility to delay CSYNC signal output. The unwanted side effect of delaying CSYNC is delaying PMG output however due to that we get possibility to check if GTIA is ready to allow control over CSYNC. We can just use collission detection agains playfield. Playfield data output is not delayed ever. The fastest method for switching GTIA to such mode takes in best cases about 40-50 minutes and it depends on temperature of the chip. By switching I mean achieving a state of stability where we have ability to delay CSYNC at any time (any scan line). Now the most interesting. When delaying CSYNC (one color clock) every second scanline we gain average screen shift of 1/2 color clock. This is because all the video/tv devices try to smooth HSYNC out. Knowing this we can achieve interesting interlace mode by mixing two screens in 4 or 15 ANTIC mode with all PMG underlays and resulting in high resolution. I have some proposals of name of such interlace mode: DSI - Delayed Sync Interlace HHI - Horizontal High resolution Interlace I will upload the demo when it's ready.

Ah, yes! I also forgot about tape rate detection. As far as I remeber it's two bytes $55,$55 preceding each block of data and AUDFs are adjusted according to detected rate. Yes, this must be an explanation why tape IO was still working. Thanks guys.

OK. Maybe it was POKEY's tolerance which allowed correct cassette IO with 2MHz clock but in that case it would be like at least +11%. Anyway, difference between 1.78 and 1.79 should not matter at all. Which POKEY pin is base clock input BTW?

Hi, Cassette IO should be fine. Some years ago I replaced 14.18MHz oscillator in my 130XE with 16MHz one just to check if it can run on 2MHz CPU clock. I worked perfectly and noticable faster which I could check listening to some musics (TV sync was broken of course). Loading from cassette worked fine for standard 600 baud as well as for 6000 (Blizzard Turbo system, common in Poland). Seems like POKEY has its built-in internal clock 1.78MHz which is not dependent on any external signals.

35, Poland. My father bought me Atari 130XE + XC12 in 1987 when I was 12. Pavros

Here are direct links to sound track files .sap and .xex.

MrFish, thanks for testing. Your description gives me some clue.

I'd like to inform about new IK+ build available on project page in Downloads section. This information was also revealed in this thread. In Downloads section on project page you can also find game's sound track as .sap and .xex file (see at the bottom). Build 0284 changes: 1. Added gong and ball sounds (for 'deflecting balls' round). 2. Introduced NTSC compliance. It required disabling dolphin and double-bird background animations when music is on. 3. Corrected tempo of sound track (removed irregularities existing in original C64 player). 4. Keyboard handler temporarily enhanced for sound testing (keys B, G, F). Full description of keys is on the project page. New keys added in current build are: B - (temporary) Fires ball sound. G - (temporary) Fires gong sound. F - (temporary) Increases gong's frequency. Gameplay did not change. Press START to continue fight when it stops. Continuation possible up to 20000 points. In NTSC mode fighter animation is slower. Turning music off helps a little. Please test new build on real NTSC machine if anyone has it. I've only tested using emulators.

Yes, that's true. Just edited my previous post.

POKE 41114,16:POKE 41115,173 .. but there will be "4k boundary crap", as Heaven said, in 118th scan line

Survey summary All the measurements concern PAL computers only. Similar thread I've created on Polish forums AtariOnline and AtariArea. Here is a table of results got from the forums as well as done by myself: X Y 11 17 12 12 15 17 17 24 13 9 14 17 11 15 8 8 23 24 10 18 16 17 20 20 29 28 12 8 15 18 15 18 The number of results is not high which makes conclusions may not be fully true. However the conclusions are as follows: 1. 8 lines above and 8 lines below standard 240 are visible to all (256 lines in total). 2. 15 lines above standard 240 are visible most often. 3. 17 lines below standard 240 are visible most often. 4. For simplicity we could assume that 16 lines above and below standard 240 are visible most often (272 lines in total). 5. 24 lines above and 24 lines below standard 240 is the maximum where we can display anything according to PAL system norm (288 lines in total). That number of lines is mostly seen on Commodore 1084 and Philips 8833 monitors (depends on adjustments). This limitation actually concerns only the bottom of the screen and the limitation for top of the screen is only for keeping symmetry. Just to remind, in additional lines only sprites (PMG) can be displayed and sprite DMA does not work there. The details can be found in my article about Atari screen border (in Polish, unfortunately). Here is a link to an example how additional lines can be used on C64. Only sprites are used there as well. Thanks Irwin for the link.

Good idea!