eshu

Please don't take this the wrong way - I'm just intrigued, what is the donated money spent on?

I was just saying on another thread how interesting it is how different peoples attitude to writing homebrew is. As mos6507 pointed out the issue goes right back to the original developers: It's also interesting that the different developers had very different attitudes to various effects on the 2600, activision achieved some amazing things while almost completely avoiding flicker while atari achieved some great results with "intelligent" flicker. I don't think there is any need to think one point of view is superior to another, they are just different. From a personal perspective it's the TIA that drew me towards the 2600 - it's a truly unique and intrigueing part of the 2600's architecture, and I think there's still a bit of juice left in the old girl yet - I think it can still be pushed further than it ever has been before. But it's this that draws me towards writing original games (disclaimer: I'm not a "completer-finisher" so don't expect anything soon ) which can be more tailored to the limitations and features of the TIA. From my limited understanding of display lists I understand there are also unique opportunities on the various atari systems which use these. I'm also a terrible perfectionist when it comes to these things and the scale of 2600 (small) gives me the best chance of ever actually finishing anything. Again this is just my opinion but I do find it mad that people talk about sales. Like many others on these boards I'm sure, some of my work involves coding in assembler. If I was to charge for a job that required the same amount of time, and was of the same technical level as writing a worthwile game for the 2600 (in assembler)- I would expect the cost to go into tens and more likely hundreds of thousands of dollars. Of course anyone wants as many people as possible to play and enjoy there game - but why not just post the binary for free, then if your game is at all interesting, your bound to get a fair few people to at least try it. If anyone's motivation for writing homebrew is financial gain then they are doing the wrong thing. I can understand that some people are also producing the hardware themselves and so have to take on certain financial burdens to do so, but if they can afford the time to write the thing I don't see how they could not be able to afford to take a small financial loss. That is an amazing quote and probably sums up far more eloquently than I could most of what I wanted to say on the subject EDIT: I also wanted to mention Dungeon, which certainly couldn't be called a port and seems to be getting some pretty good feedback on the forums.

That's great! I hope everything works out well. Looking forward to the next release, even if it takes a while. Indeed excelent news!! I do understand this, I just hadn't dared to dream anything as good as the Blargg filters would be coming any time soon. That's exactly why I thought this topic would be ok on the programming forum. It's not just about avoiding problems - you can also take advantage of the way the image is processed to gain the appearence of extra colours, less jagged graphics etc.. It's not relevant to the 2600 because of the horizontal resolution, but one of the most impressive effects achieved this way is artifacting: http://www.atarimagazines.com/compute/issue25/033_1_GRAPHICS_8_IN_FOUR_COLORS_USING_ARTIFACTS.php I'm not sure, but I think it might be a form of "color bleed": http://blargg.fileave.com/ntsc-parameters/

I think this is getting a bit off-topic now (as in I don't think grafixbmp should be discussing the intricate details of TV simulation when he could be working on the Castlevania port which I'm hoping to one day play on my VCS) so I've started another thread here: http://www.atariage.com/forums/topic/153033-tv-simulation/ To grafixbmp, I just want to say again that I think the work you have done so far is very impressive. I think your point of view is just as valid as anyone else's and let's be honest most be people wouldn't think writing a game for a 30+ year old system is a normal thing to do anyway - you have to work towards your own vision, you'll never have the motivation otherwise. As much as other people can be impressed with your work, no-one else will feel the satisfaction you can get from seeing your game on the VCS.

That library does look pretty sweet, but I think it is based around processing a single image at a time - so it wouldn't do anything for the phospher effect that is often used on the VCS. It would be great if someone could integrate it with the work that has already been done, but I don't think that would be a particularly easy task. I haven't seen a VCS on a CRT for quite a while but I didn't think the new functions in Stella made that bad an approximation if it - I definitely think it's a lot better than just having the alt-p option for phospher effect which I think pretty much just merges two frames.

Now, now - I'm certainly not accusing anyone of cheating . I think it's unlikely that many people where doing a video mod back in '81, but I guess it's not impossible. The way a picture display's on a television isn't necessarily a hinderance, some developers used it to their advantage, I used to think the wheels on the cars in enduro where rubbish until a recent version of stella came out.... The article here: http://www.bogost.com/games/a_television_simulator.shtml seems to indicate that flicker is worse on modern televisions? The only TV we have in our house is a big LCD screen which does some strange things to the VCS signal, I think it interprets it as interlaced or something but I get a very jagged picture so I don't use the real thing for development as much as I would like, at some point I think I will have to try and get an old CRT to use it with...

Been watching this thread for a while, and am impressed with your progress so far... I think you'll find that it's the "closest" colour combinations which blend well, so for instance colour $00 and $0F mixed will produce approximately the same colour as $06 mixed with $08 but the second combination will do so with less noticable flicker. Because the colours in NTSC are based on a colour wheel I think you can also quite easily measure the "closeness" of hues - the colours with the smallest differences in both hue and luminance will blend the best. I think the hues sort of rap around from $F to $1, so $E0 is about as "close" to $F0 as $10 is. It's interesting to see how different peoples attitude to writing stuff for the 2600 is. Some people are only interested in things that could have been released back in the day, and others not. I've seen it a lot of times when people where talking about the Chimera project which never came about in the end, but I think the work formed the foundation for the Harmony/Melody cart, but this is the first time I've seen it with regards to tv sets! I'm still playing around with stuff so I don't know if I'll ever get a complete game written - but I always want to write something from a "what if" point of view, like what if this game had been released before the crash, or what if it had been released while the NES was putting the final few nails in the 2600's coffin. So I wouldn't want to use an effect that wouldn't have worked so well back then. But I don't think my point of view is in any way better than yours, I just find it interesting how different people look at it.

No I'm an "agile developer" which of course isn't just management speak for the same thing.....hmmm.... http://en.wikipedia.org/wiki/Agile_software_development

Yeah, I must be missing a plugin or something. I wonder why the examples I posted links to work with my Firefox setup? Thanks. I've edited the original post to the correct case, can you copy and paste the whole thing into a new file and try it again...I'm pretty sure it should work, but if that doesn't I'll have another look...

They basically use the same method, but I didn't get my cases right.... If you change: y.obj.stop(); -> y.obj.Stop(); x.obj.rewind(); -> x.obj.Rewind(); x.obj.play(); -> x.obj.Play(); The example I posted earlier will work as well across browsers as the code in those articles you posted, I think it will need the quicktime plugin for firefox to work though....

<HTML> <HEAD> <TITLE>Sound over area test</TITLE> <script> var old_n=0; function getObj(name) { if (document.getElementById) { this.obj = document.getElementById(name); this.style = document.getElementById(name).style; } else if (document.all) { this.obj = document.all[name]; this.style = document.all[name].style; } else if (document.layers) { if (document.layers[name]) { this.obj = document.layers[name]; this.style = document.layers[name]; } } } function playsound(n) { if (old_n!=0) { var y=new getObj("snd_" + old_n); y.obj.Stop(); } old_n=n; var x=new getObj("snd_" + n); x.obj.Rewind(); x.obj.Play(); } </SCRIPT> </HEAD> <BODY> <IMG SRC="http://www.randomterrain.com/bbfiles/randomterrain-keyboard-t04-988.png" USEMAP="#soundmap" border="0"> <MAP name="soundmap"> <AREA shape="rect" coords="0,0,32,128" href="#" onmouseover="playsound(1)"/> <AREA shape="rect" coords="32,0,64,128" href="#" onmouseover="playsound(2)"/> </MAP> <div style="position:absolute; top:-100"> <EMBED id="snd_1" src="http://simplythebest.net/sounds/WAV/sound_effects_WAV/sound_effect_WAV_files/cow.wav" MASTERSOUND loop=false autostart="false" width="0" height="0"/> <EMBED id="snd_2" src="http://simplythebest.net/sounds/WAV/sound_effects_WAV/sound_effect_WAV_files/bird_1.wav" MASTERSOUND loop=false autostart="false" width="0" height="0"/> </div> </BODY> </HTML> That is a simple demo that should work on IE, with two sounds being triggered by moving over the first two white keys (the co-ordinates aren't perfect).....

if I get a chance later I'll try to knockup an imagemap that plays sounds...I wasn't quite clear if you wanted the user to click to play the sound or just move the mouse over?

Don't know if this will be any use, but since you haven't got any other replies this might get you started.... Playing sounds in a web browser without flash is a bit hit and miss, here is a very simple example which works ok in IE.... <bgsound src="silence.wav" name="sound" loop="1" /> <button style="margin:20px;padding:30px" onclick="sound.src='aud/2sexy.wav';">2Sexy</button> <button style="margin:20px;padding:30px" onclick="sound.src='aud/heart.wav'">Heart</button> <button style="margin:20px;padding:30px" onclick="sound.src='aud/hidarlin.wav'">Darlin'</button> The "silent.wav" silent audiofile in the first line is needed to allow the sounds to play more than once due to some strange bug in IE... To get the sounds to play when you click or move over certain parts of the image, the easiest method will almost certainly be to use a HTML "image map" - you should be able to find more info on google - but this tutorial should have everything you need: http://www.javascriptkit.com/howto/imagemap.shtml Anyway hope that helps....

eduardo, I don't want to rain on your parade but you seem to be working on the basis of some seriously flawed assumptions. A gameboy probably doesn't have the horsepower to emulate a 2600 let alone a 7800. Saying all you need for emulation is an eeprom is non-sensical. An eeprom is used to hold code, writing the code for an emulator is a serious undertaking, you need to emulate each part of the target system (CPU, Graphics, Sound). There is as far as I know no core hardware which is the same on both systems, so you will need to emulate in software each part. Consider as an example SNES emulators, even the most efficient can just about run at real time on a 486 at 66mhz, which is roughly 10 times more powerfull than the SNES it is emulating. The only time a system is able to emulate another that is anywhere near as powerfull as it, is when some of the core hardware is the same across the systems. For instance the Atari ST could have a decent stab at Apple Mac emulation because they both used the same CPU, and the sound and graphics hardware in Mac's was not particularly powerfull. P.S.: Do any ST users remember "PC Ditto"

Have you had a look at the SkipDraw code - skipDraw on MiniDig, think that's the most similar method to yours and is as efficient as possible...

It really depends on how you're doing these things for example if the sprite is limited to 128 scanlines vertically it can be drawn in 7 cycles if it is stored with a lot of wasted memory: LDA Sprite,y STA GRP0 11 cycles with less wasted memory, but the sprite data must be placed in the centre of a page. LDA Sprite,y AND Mask,y STA GRP0 Or more cycles with less restrictions with SkipDraw. Also there are a few tricks with colours. If you need complete freedom it should take 7 cycles to do a colour change (No masking required as random colour doesn't matter when theres nothing there): LDA Colour,y STA COLUP0 However, sometimes you can relate the colours to the graphics - something I am working on at the moment uses only 3 extra cycles for the colours: LDA Sprite,y AND Mask,y STA GRP0 SAX COLUP0 (SAX is an illegal opcode which stores A & X) I have X permenantly set to 0x0F in this kernel.

Have you considered losing PF0, part of it will be obscured if you're using HMOVE's anyway. You can get 4/5ths of the screen just updating PF1 & 2 twice each... P.S. This is my first post, so hello to everyone, excelent forum here....