Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Kylearan

Members
 View Profile  See their activity

  • Content Count

    210

  • Joined

  • Last visited

Posts posted by Kylearan

  1. Posted · Edited by Kylearan

    Obfuscation was used for games on traditional computers like the Apple II or the C64 as a counter-measure against piracy; I've seen titles from as early as 1982 that were heavily obfuscated, and I guess there are even older titles that used that technique. Same for even older arcade machines. But obfuscation techniques like semantic NOPs, jump into the middle of instructions, opaque predicates, VM packing etc. always come at the expense of ROM, heavily so if they should be actually useful. Other techniques, like decryption on the fly, need RAM. Both ROM and RAM are very scarce resources on the VCS, so I heavily doubt they were used back then.

     

     

     

    This seems unlikely, given the widespread "recycling" and even outright copying of code between and across game companies

    Note that obfuscation techniques can only make reverse engineering harder, not outright prevent it. There are games on the C64 or Apple II that use an INSANE amount of layered obfuscation techniques, and they were always cracked regardless. Same with modern PC games or obfuscated malware. Obfuscation can only slow down a dedicated reverse engineer.

    • Like 1

  2. Posted

    Ah sorry, I should have been clearer. What I meant was:

     

    Assume I have a working routine which uses the RESP trick to display extra copies. Now I modify that routine so that the main copy is positioned slightly different, let's say 1 pixel to the left. That means only the HMP value to position the main copy is different, but the RESP strobes happen at the same cycles as before. Will the extra copies be displayed 1 pixel to the left as well, because the position of the extra copies depends on the position of the main copy? Or will the extra copies stay where they were in the unmodified routine, because their position depends on the timing of the RESP strobes (which haven't changed)?

  3. Posted

    Hi,

     

    I know that if you set NUSIZ to e.g. "three copies close" and hit RESP at the right moments after the main copy has been displayed, you can get extra player copies displayed. (Correct?)

     

    Are the positions of the extra copies relative to the position of the main copy, or relative to the time of the RESP strobes? I.e., if I position the main copy 1 or 2 pixels left or right via HMOVE, will the extra copies be shifted as well, or will they appear in the same place as before because the RESP strobes happen at the same cycles?

     

    I have to admit then when googling for this, I got confused by all the hardware details regarding timers, start signals etc...

     

    Thanks!

  7. Posted · Edited by Kylearan

    Higher level editing would be fantastic, especially with built-in TIA emulation. Looking forward to how this unfolds. Would this be a Windows app?

     

    I'm developing TIATracker under Windows, but I'm using only Qt and SDL, both of which are platform independent. So this should run under Linux and OS X as well, although I haven't looked into the details of how this works exactly yet.

  8. Posted

    any more I've missed?

     

    One important weapon is missing IMHO: Good tools that actual musicians can use. I find it amazing that the VCS is 38 years old already, and yet almost everyone is still coding music in source code using Paul Slocum's mature, but also somewhat limited player. I feel that even with the TIA's limitations, an experienced chip musician would be able to do much better music if there were user-friendly tools helping him to focus on creating instruments and actual composing, without the need to understand programming.

     

    My current goal is to change that. I have already developed a music player that supports instruments with ADSR envelopes, patterns of arbitrary length, "overlay" custom percussion instruments and more, at the price of a bit more ROM and RAM (right now ~200 bytes of ROM and 9 bytes of RAM, less if certain features are not used). At the moment I'm developing a tracker with (hopefully) a musician-friendly GUI that provides as much help as possible for dealing with the TIA's pecularities. For example, it supports a combined, virtual "Pure" distortion value that combines AUDC values 4 and 12, which when the song is exported to asm will get split automatically into two separate instruments. In addition, I'd like to incorporate Thomas' Tune2600 routines, and this Perceptual Tuning article already gives me some ideas how to improve that. :)

     

    The tracker uses Stella's sound emulation routines, and the instrument editor is finished already (see screenshot). Both player and tracker will be open source; release is slated for Easter 2016. I hope this will help to bring in some more "real" musicians who show us what the TIA chip is really capable of. ;)

     

    One can dream...

    post-35905-0-47312700-1450899597_thumb.jpg

    • Like 3

  13. Posted

    For those interested in the demoscene, I've released a new VCS demo this weekend:

     

    http://www.pouet.net/prod.php?which=65838

     

    You can also find the full source code there. I guess the main cube effect is not really relevant to you game developers, but maybe you find the extra-wide hi-res scroller interesting.

     

    Note: The source is not in dasm format; it's for KK's very nice compiler/linker k65 which will be released publicly soon. But since the format is really close to assembly, you shouldn't have much trouble reading it.

     

    • Like 6

  16. Posted

    Hi,

     

    when searching for F4 bank switching, most sources I found use the BIT or LDA instruction to switch banks, e.g. BIT 1FF4 or LDA 1FF4,x. However, the BIT instruction doesn't preserve flags.

     

    Will it also work (reliably) with STA, e.g. STA 1FF4? It works with Stella, but does it work also on real hardware?

     

    If it works, what's the reason for people using BIT or LDA instead?

     

    Thanks,

     

    -Kylearan

     

  18. Posted

    Great stuff, looks very promising! And I second ZackAttack, I think two-line kernels look perfectly fine. But as you said yourself, I guess you'll be forced to do that anyway during further development.

    I've got some simple shading going on the platforms, but this demo (I forget which I grabbed that screenshot from)

     

    That's my demo TIM1T (here). :)

    has way better shading, and texturing. I'd love to steal that, but they've got two colors going on the same line and I'd need three, and enemy birds might wind up in PF*, which wouldn't be all bad since then they could potentially be much larger. Not sure how I'd juggle that. Stuff people do blows me away.


    Comparing games to demos is not fair to you game programmers. We demo guys can cut more corners and avoid troublesome situations, which for game programmers is way harder to do because they have to allow more freedom to the players.

     

    For example, in my second demo Ascend (here), I have another fake raycasting-like effect (the first effect after the title screen), several 3D boxes rotating around themselves and each other. But note that I don't have smaller boxes in front of larger boxes, and thus avoid having to display more than one color per scanline...

     

    Anyway. I'm really looking forward to your progress!

     

    • Like 1

  21. Posted

    Hi,

     

    if I read the HMOVE table at http://www.qotile.net/minidig/code/hmove.txt right, it shouldn't make any difference if I do a STA HMOVE at cycle 0 (e.g., immediately after a STA WSYNC) or cycle 1, correct? Is it known if this behavior is compatible over different 2600 models?

     

    In particular, I would like to move P0 and P1 8 pixels to the right (HMPx=0x80), but in my kernel the STA HMOVE might happen either at cycle 0 or cycle 1. Making sure it would always happen at cycle 0 would cost me >300 bytes of ROM, which I would like to avoid. ;-)

     

    I know that HMOVEs at cycle 73, 74 or 75 behave differently on some models, but does anyone know if a HMOVE at cycle 1 is fully compatible with all 2600 models?

     

    Thanks,

     

    -Kylearan

     

     

     

  24. Posted

    Hi,

     

    great project you have going on there!

     

    I really wish I could change the colors for each scanline, but I haven't found a way to squeeze the cycles needed into the kernel. Almost, but not quite: I can find enough time to change COLUP0 or COLUP1, but not both :)

     

    There are two ways to do that.

     

    1) Invert your graphics, and set COLUP0 and COLUP1 to black. Set the playfield to mirrored (register CTRLPF), and put playfield graphics behind the sprites (that works because your logo is centered on the screen). That way, the playfield graphics will "shine through" where your logo is, and you only need to set one color (COLUPF) per scanline.

     

    2) Here's a 48 pixel kernel that sets both COLUP0 and COLUP1 (caution: written off the top of my head, and thus untested):

    .loop:
	ldy lineCount		; 3
	lda colors,y		; 4
	sta COLUP0		; 3
	sta COLUP1		; 3	
	lda data_1,y		; 4
	sta GRP0		; 3
	lda data_2,y		; 4
	sta GRP1		; 3
	lda data_3,y		; 4
	sta GRP0		; 3
	lda data_6,y		; 4
	sta tmp			; 3
	lax data_5,y		; 4
	lda data_4,y		; 4
	ldy tmp			; 3
	sta GRP1		; 3
	stx GRP0		; 3
	sty GRP1		; 3
	sta GRP0		; 3
	nop			; 2
	nop			; 2
	dec lineCount		; 5
	bpl .loop		; 2/3

    If I haven't miscounted, the kernel should be exactly 76 cycles. Since it lacks a sta WSYNC, you need to enter it exactly at the correct cycle so the sta/stx/sty sequence matches the player placement. And if you don't like undocumented opcodes (lax loads the value in A and X simultaneously, so you save a tax), you can change it into a lda/tax and remove one nop instead.

     

  25. Posted

    Nevertheless there is huge a gap between 2K ROM/128 bytes RAM and e.g. 32K ROM/1K RAM. So oldschool is a too broad term for a competition. Probably each compo should define clearly what the restrictions are.

    Agreed. But the problem is that the VCS demo scene is too small, so the few VCS demos that are released per year have to be put in the general "oldschool" or "wild" category, or otherwise there would be no competition. Fragmenting that even more (4K vs. 32K etc.) is, unfortunately, not an option.

     

    The only exception is SillyVenture in December, which is an Atari-only demo party and has its own 2600 category with fixed and clear rules (max 32 kB ROM, no extra cartridge RAM or DPC allowed.) There at least people don't have to compete with C64, Spectrum or even Amiga demos, and that's where I will release my next demo. I hope there will be some competition. :)

     

    If however all the fine folks from AtariAge would code a demo inbetween games, that would change the situation completely. ;) (But then you could say we demo sceners should code a game inbetween demos...)

     

    Anyway, back to coding; 4 parts finished, 4 to go!

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...