eshu

Here's the version they played on the show... paranoid_zph_wip.bin

Awesome thank you - I wonder if this is why it's quite so jittery on my real system, my problem is I can't get rid of my paddle jitter, so I assumed it was just that...

many years since I last signed in and progress is slow, but may as well post an update bin of wheree I'm at so far.... paranoid_0.14b(NTSC).bin

do you actually mean medium copies or close copies - the demo in the cribbage squares looks like it's 4 copies next to each other, e.g. P0 and P1 both set to two close. If you only want red and black, it is better to set the P0 and P1 to background colour and draw inverted sprites over BG and PF with e.g. BG set to red and PF to black - I hope that makes sense....

So, it’s 160x192 with a screen ratio of 4:3, it’s quite common to mock things up in 320x192 with double width pixels as this is closer to 4:3 than 160x192

Random idea - would it be possible to bruteforce every single possible input state for every frame in an accelerated emulator - seems highly parallelizable etc...

http://atariage.com/forums/topic/90210-atari-os-finished/

Have you looked at TIA Tracker? - http://atariage.com/forums/topic/250014-tiatracker-a-new-sound-routine-and-sequencer-application/

Nice one

If you tell me the address I'll have a quick look in stella debugger - but I would guess VSYNC just happens to be being set there, and most TV's are ok with that - does it also get turned off at cycle 15? - It probably should be set straight after WSYNC for three scanlines i.e. lda #%00000010 sta WSYNC sta VSYNC sta WSYNC sta WSYNC lda #0 sta WSYNC sta VSYNC

WSYNC and VSYNC work quite differently. WSYNC waits for the horizontal blank/sync period so leaves you at cycle 0 VSYNC is used to set a signal, but doesn't wait for anything - so STA VSYNC is just a normal 3 cycle operation from that point of view In an emulator I would expect that you would want to synchronize what you are displaying based on when bit one of VSYNC is set high

I noticed you posted a lovely mockup of a Mortal Kombat game in another thread so I'm guessing you're talking about that? I'm pretty sure the setup you have there would be impossible without flicker. There are a few tricky ways to re-use sprites, but none of them give you complete control. I'm struggling to put together a good description of what you can do with the "RESP trick" but it's really not practical for moving full size sprites around etc... also I don't think it's very practical to use with double size sprites (I think maybe if you change from single width to double width at just the right time it might work? but it would be a lot of overhead). I've thought before it might be possible (but tricky) to use a similar setup to that which I used in http://atariage.com/forums/topic/195210-very-early-wip-of-something-ive-been-working-on-for-ages/for a beat-em-up - that uses a player and ball/missile for each player. You could use for instance P0 and BL for player 1 and P1 and M0 for player 2 - but you'd need to be able to change COLUP0 (The colour of P0/M0) at any given cycle and ensure that P0 and M0 were always at least 3 pixels apart......you could use double size players this way......

Wow - didn't think I'd be able to find this: https://drive.google.com/file/d/0Bxv0SsvibDMTcHNXalEtYkVtU00/view- learnt as a child from books from the library - seems like Usborne's released pdf's of all there cool computer books from the 80s: https://usborne.com/browse-books/features/computer-and-coding-books/

http://atariage.com/forums/topic/47479-atari-programming-workshop-chapter-links/

How about using both P1 & P0 double size and different colours like SpiceWare does for the dragon in Medieval Mayhem?? - I'm sure theres a nice post about it somewhere but I can't find it....

So the missile (M1) is also being moved - something like: 0000XX 000XX0 00XX00 00XX00 000XX0 0000XX but shown as: 0000X0 000X00 00X000 00X000 000X00 0000X0 So I don't think it's an off by one pixel, but it could be off by one machine cycle......I haven't looked at the code for literally years, so I wouldn't like to promise that the old Stella TIA core had it right......I have the source code on an old HDD somewhere, so as Thomas suggests I should maybe try to build a version that works on normal Harmony at some point, if I remember correctly the bank switching etc.. was pretty tight and it wouldn't be as straightforward as you might think to change the bank switching scheme..

Not sure if you read the whole thread etc.. , but I thought my comment made it clear it doesn't work properly/universally - but there's at least a lead as to how a smooth scrolling playfield might be achieved. Difficult to know what you mean by flickering in this context, but the likelihood is your TV doesn't like the various butchered signals being sent out by the VCS.....

Nice - the screenshot looks perfect - if I get some time and am feeling brave I might try to build from source

Hi again Ok - I think this one is a regression from the old core, but I've never run the binary on a real machine - someone might be able to now with a harmony encore? it's an EFSC rom, the menu pointer is made up of a missle, and is supposed to be two pixels wide, I think NUSIZ1 should get changed just in time.....on old Stella it shows up 2 pixels wide, but just 1 on the test release. The relevant code is run out of zero page, it should be executed from about scanline 179 "scanline b1" in the Stella debugger will get you there, then it's the STX NUSIZ1 run from A6 long005.bin

Wow - quick work! Yep - the 32 char demos etc.. all look right to me now I'm afraid I really don't know either of these - some of the more hardware oriented members might have a better idea from the schematics.....

Not really sure if this should be in the 6502.ts thread or this one, but it's TIA stuff so I hope it's ok here.... I thought I'd try some of the 32 character routines on 6502.ts - these are the ones that expose the issue with extra copies when using multiple RESP0/RESP1 on stella - it looks like the TIA core in 6502.ts gets that bit right - but it seems slightly off with the first copy of P0 (which is actually the second copy to the TIA as the first isn't drawn) on one of the RESP hits. DirtyHarry - a bunch of relevant binaries and pictures of the behaviour on real hardware can be found starting here: http://atariage.com/forums/topic/180632-32-character-text-display/page-2?do=findComment&comment=2280849

Hi DirtyHarry My first guess would be timers - It's using TIM64T and INTIM to judge when to leave a kernel (as well as other stuff) that it looks like it's getting stuck in........I suspect the bug is made to look worse than it really is as things go a bit mad if it doesn't leave that kernel when it's meant to.......... Edit: In case it helps - I think (and it's pretty much pure guesswork) that the problem is probably occuring at: F10C: LDY INTIM F10F: CPY ram_C0 F111: BEQ LF100 (all in Bank 0) if INTIM is off, even by one, it will carry on this part of the kernel and bad things will happen.....

Hi - great news about the TIA core upgrade I hope it's ok to pre-emptively raise an issue here that I think I've at least tried to raise with the old core before....It's difficult to tell if it will be fixed by the new core as the roms I have to hand to demonstrate the issue have other problems in 6502.ts....It's an issue with RESMP0 (/RESMP1) it's been ages since I looked at it but I suspect it relates to the the interpretation of the following passage in the Stella Programmers Guide: I have a feeling that the issue is the TIA core in Stella interprets "center of it’s corresponding player" literally where it should probably be "4 pixels to the right of it's corresponding player", so that the location doesn't move for a double sized player etc... but it does in Stella - see http://atariage.com/forums/topic/223257-arkanoid-2600/page-3?do=findComment&comment=2985254for example binary.

fair dos - I stand corrected - probably made an assumption based on cost/board used in the store....still a significant amount more rom etc...

To be fair the solidcorp / kickstarter version was using old era tech (I think 8k rom with standard bankswitching) where the AA version is DPC+ I think?