eshu

Sorry for the necro-bump, but I don't suppose anyone had the 6502-VCS.xml file?

Never say never -http://atariage.com/forums/topic/224946-smooth-scrolling-playfield-i-think-ive-done-it/ I got burnt out on the back and forth of this with no CRT of my own to test it on, hopefully someone else will pick it up, or I'll get a CRT and have another crack myself...

Please tell me there is bus stuffing here?!?!?!? Edit: wow there isn't! Seriously amazed!!!

1. you can run code from RAM, but remember there's only 128 bytes of it. 2. Several of these locations probably do not have well defined behaviour as to what values you will "read" from, so are unlikely to reliably create runnable code that would allow you to execute from 0x80 through to 0x100 3. Not that I'm aware of, bugs in 2600 code are fairly rare, there isn't room for them 4. fairly common you seem to be intending to rely on there being a code execution bug in Stella which can be accessed from 6502 code, seems unlikely.....

Isn't this ultimately what has changed, I wasn't around, but have dug through a lot of the old posts etc.. on the stella mailing list, and it seems to me that at that time the target audience for any homebrew game was other programmers. Now there is an established audience of collectors/others interested in retro systems who either aren't interested in or aren't currently capable of programming. It turns out a lot of them couldn't give a stuff what constraints a programmer places on themself, or what hardware is plugging into the cart slot, the better the game, the better as far as they are concerned. Also maybe their nostalgia isn't just connected to playing the game, but opening the box, reading the manual, having a game your mates don't have etc... Hence the love for nicec packaging, limited editions etc... Now personally I can't understand why someone would program for the ARM on 2600, but they're a hell of a lot closer to me than 99.999999% of the population who would think it's a ridiculous idea to program in anyway for the 2600, so really we should probably just acknowledge that each 2600 programmer seems to place there own arbitrary constraints on what they want to do, mostly different for any given project, and get on with having fun making games/demos etc...

You're not alone, but I take a very much each to his own attitude - I've said it before, but it's basically "homebrew hardware". It doesn't interest me to see what the 2600 can do outside the confines of what was around during it's lifetime, but that doesn't mean I'm not impressed with what people have done with DPC+ etc.. I really think people are being hasty to say that the 2600 has been pushed as far as it can go, based on "normal" bankswitching etc.. I'm afraid I'm going to refer to a bunch of my own incomplete projects, I'm not trying to show off but obviously I know how they work etc... We only recently (in 2600 terms) got the 32 character routing going (see http://atariage.com/forums/topic/180632-32-character-text-display/?p=2281053),as the resp trick becomes better understood. I've also been having a lot of fun with RAM kernels (some people call them self-modifying, but normally the modification is done outside of the actual kernel), I think theres still a lot of potential in this - see: http://atariage.com/forums/topic/195210-very-early-wip-of-something-ive-been-working-on-for-ages/and http://atariage.com/forums/topic/223257-arkanoid-2600/?p=2985254 - I think circus atariage employs similar techniques. I started getting somewhere with the smooth scrolling playfield stuff ieposta mentions (see http://atariage.com/forums/topic/224946-smooth-scrolling-playfield-i-think-ive-done-it/) - tbh I got burnt out on it, will try to pick it up again once I have a CRT to test with.... Then theres also the great work RevEng has done on perceptual tuning and my own little contribution on just intonation - see http://atariage.com/forums/topic/247042-tia-perceptual-tuning/ All these are relatively recent, and I'd like to think have pushed the envelope just a little bit further...

I have a WIP from another thread..... brk0h.bin

Please bare in mind that I know essentially no music theory. The idea is to have a bunch of notes that are perfectly in tune with each other according to just intonation. There is a nice reference here with ratios for various modes: http://www.csufresno.edu/folklore/Olson/JUSTINT.HTM I think aeolian is by far the best suited to the TIA as there are only powers of 2 & 3 in the top part of the ratio. Here are my notes (baddum tish)... Aeolian: 1 9/8 6/5 4/3 3/2 8/5 9/5 E3 1/192 = 1/6 * 1/32 F3 1/180 = 1/6 * 1/30 ... A4 1/144 = 1/6 * 1/24 B4 1/128 = xxxxxxxxxx C4 1/120 = 1/6 * 1/20 D4 1/108 = 1/6 * 1/18 E4 1/96 = 1/6 * 1/16 F4 1/90 = 1/6 * 1/15 G4 1/80 = xxxxxxxxxx A5 1/72 = 1/6 * 1/12 B5 1/64 = 1/2 * 1/32 C5 1/60 = 1/2 * 1/30 D5 1/54 = 1/2 * 1/27 E5 1/48 = 1/2 * 1/24 F5 1/45 = xxxxxxxxx G5 1/40 = 1/2 * 1/20 A6 1/36 = 1/2 * 1/18 B6 1/32 = 1/2 * 1/16 C6 1/30 = 1/2 * 1/15 D6 1/27 = xxxxxxxxx E6 1/24 = 1/2 * 1/12 F6 2/45 = xxxxxxxxx G6 1/20 = 1/2 * 1/10 A7 1/18 = 1/2 * 1/9 B7 1/16 = 1/2 * 1/8 C7 1/15 = xxxxxxxxx D7 2/27 = xxxxxxxxx E7 1/12 = 1/2 * 1/6 F7 4/45 = xxxxxxxxx G7 1/10 = 1/2 * 1/5 A8 1/9 = xxxxxxxxx B8 1/8 = 1/2 * 1/4 ... E8 1/6 = 1/2 * 1/3 ... B9 1/4 = 1/2 * 1/2 ... B10 1/2 = 1/2 I guess the note names are non-standard here, the numbers should probably be increasing on each C rather than A...... The music is basically butchered from here: http://wiki.cs.princeton.edu/index.php/Green.ckbut that is clearly not in aeolian, I've just changed the G#s and F#s to Gs and Fs, which probably isn't the right thing to do?

Ahh the old won't work gambit, I fall for it everytime 32char3.bin

just to chuck my $.02 in - I had a good luck at https://en.wikipedia.org/wiki/Just_intonation a few years ago and I seem to remember you could get some pretty complete scales going in at least one key - none of my projects have actually got to the point where they're ready for music yet

seems like I never cleaned up the code.... heres some messy code 32char_upload.asm

I do want to get back to this at some point, as I think it's a realistic project for me to actually get done, but no sign of having the time to do so anytime soon Anyway I did get a little further than the last .bin I posted, so guess I may as well post up the latest while I'm here..... brk0h.bin

I got a reasonable way into a decent port when the whole flappy bird craze was kicking off - but it was going to take so many manually written kernels to get it done that I bailed out......I can't help myself from trying to get the most out of the 2600 and that generally leads to an absurd amount of coding required......anyway here is what it would have looked like: Attached bin is just the scrolling pipes.....I got a little further than this but nothing really to look at...... flappy9.bin

Theres an EFSC binary of mine in this topic - http://atariage.com/forums/topic/195210-very-early-wip-of-something-ive-been-working-on-for-ages/ Good luck

0-2 have a subpixel shift between them, so it's an imperfect 2 pixel scroll. The technique shifts the whole screen so placing a sprite on top of the playfield won't help identify the scrolling amount anymore than the checkerboard pattern which is already below the scroller in the current binary. Yes, the 2 pixel scroll should be twice as smooth as was previously possible, but a single pixel scroll would be twice as smooth again

Here is a 2px version with just kernels 1 & 3, I think this is right.. scrolltest3_alt_2px.bin

I think 1-3-1-3-1-3 is a perfect 2 pixel scroll. I can't remember if I did one with the _alt versions of the kernel, which so far seem to work on every setup except mine - I'll check and do a version using the correct kernels if I haven't....

Thanks again for testing. If you get a chance to swap 2600's between TV's it would be nice to know if theirs any difference - I'm erring on the side of it being differences in the TVs but would be nice to confirm. That blue/yellow ghosting is probably it scrolling less than a TV pixel, so that only the blue from the RGB phosphers is being lit on one side and the red and green from the other. Thanks Ed - doesn't look like much of an improvement, back to the drawing board I think.... Thanks for this - did you use a tripod or something? The pictures seem to be taken from an identical position which is handy! - nice idea with the postit to I hadn't noticed 3 & 1 where the same offset so that's handy to know. Im did some quick measuring and it looks like the drift is about half a 2600 pixel. I.E the difference from frame 0-2. A normal PF scroll, goes 4 2600 pixels at a time, so if we're scrolling 1 pixel at a time we need 3 intermediate steps - Kernel 0 is just a standard 2600 kernel with no use of RSYNC. I did at one point think the drift might be a whole 2600 pixel and tried removing one of the kernels, but no joy. As I mentioned above from measurements it looks like half a pixel. I have a few more ideas to try out to see if it's possible to fix the subpixel drift, or at least reduce it, but I'm going to be quite busy with work for the next week at least, so they're probably won't be any new updates for a while. In the meantime if anyone gets a chance I'd like to confirm that the "stabaliser_alt.bin" binary is stable and shows proper one pixel differences between each kernel.

Has anyone else had a chance to test the latest binary? Am really keen to know if stabalisation is working elsewhere, Ed - when you're back I'm really interested to find out if this works on your setup..... I've been working on a blog entry to try and get all the explanation in one place - hopefully should get something up tomorrow....

Thanks for testing - interesting - it looks like the top of the scroller is following the old pattern, so that #2 would be shifting a bit further, but the display is quickly bending into the correct position, I did some work last night to test the stabaliser on my setup but it didn't seem to be doing much, can I just confirm this is different/better than scroller2_alt.bin on your setup (I'm guessing/hoping that was exhibiting the subpixel drift?) - The pincuchioning/bend should hopefully be able to be fixed by moving the stabaliser further away from the scroll if this is effective on other setups.

garrr...there was a bug, some frames running at 263 scanlines - fixed.... scrolltest3_alt.bin

Hmm - that's a bit confusing, I don't think the colour burst should be added to the whole signal - it look slike something is at that point though.....I'll have a think over this for now.... Could you try the attached binary - This is an elongated version of the stabaliser, it should display all the different possible positions of the playfield. Using idfferent kernels that work on my system I can get this image stable and there doesn't appear to be any subpixel differences between the different positions, the idea was to send a version of this at the start and end of each frame.... stabaliser_alt.bin

I had an idea for something that might remedy the subpixel drift - I've rushed it through so theres every chance I've screwed up - but here is a version of scrolltest2_alt with "stabalisers" - could anyone that binary works well for give this a try and let me know if it's any better..... scrolltest3_alt.bin

Nice one - I know absolutely nothing about oscilloscopes, so I don't know what different types there are etc...but it seems to be possible to get a nice picture of the composite video signal (I guess you might have to take this from somewhere on the 2600 before the RF modulator?), or it might be possible just to look at the CSYNC signal from the TIA. I'd like to see how the binaries are affecting the HSYNC pulses. What I'm aiming for is to keep as close to the original signal as possible, but with the picture element shifted and the sync pulse remaining in the same position and of the same length.. If you look at the video I posted, or the wiki page: http://en.wikipedia.org/wiki/Analog_television You can see some scope shots on there... This site has a nice picture breaking the signal down: http://www.ntsc-tv.com/images/tv/sync-wf.gif I'm guessing scrolltest2_alt.bin would be the best of my binaries to work with for now, but you might want to see what is working best on your Atari first. Hopefully you should be able to click through the frames and see how the signal looks.... Edit: This looks like it might be useful - http://www.infernosoft.com/community/Tektronix1410/tvScanLine.html

Hi Joe, Thanks for testing - to be fair I think their will be colour issues with mine on a PAL system to - I'm deliberately using white for that reason at the moment. I'm still wondering if their is a way round the subpixel issues, but drawing a bit of a blank at the moment. The altx binary was really aimed at ieposta's setup as I see similar issues with that version of kernel #2 on my setup. The video from Ed's setup of scrolltest2_alt.bin is almost as good as the original binary on my system, but the jitter in kernel 2 seems a bit more pronounced. I literally didn't notice the subpixel issues at full speed, but they are there now if I look carefully/at a slow speed. The source code will be forthcoming once I've got this working as well as possible, as usual with my code it's a bit messy, just trying to get it working a.s.a.p. I can see from Thomas' binary in the debugger that it's a lot more elegant 6502 code - The code for mine is basically in this topic already though - see post #75:http://atariage.com/forums/topic/224946-smooth-scrolling-playfield-i-think-ive-done-it/page-3?do=findComment&comment=2983729 Also, when you tested Thomas' binary were the actual screens stable on slow motion? - just trying to figure out if stuff can be combined from both...