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

    The extra RAM was not the problem with Bang!. What SvOlli fails to mention is that he didn't tell the audience at the competition that extra RAM is used. So people saw the demo, compared it to other VCS demos they know (none of which so far has used extra RAM) and voted accordingly.

     

    Using extra features in itself is not cheating of course, and I doubt anyone said this (or would say this). Personally, I find it unfortunate because as Thomas says it fragments an already tiny scene, but I can also understand that it's fun to use the SARA chip.

    • Like 1

  2. Posted

    I've only taken a very quick look at your source, but if I see this correctly, lines 164/165 (dex; bne Draw_Screen) only loops over setting the playfield, never doing a check again if the player should be drawn (and the value of x is probably not what you want either). Try to replace it with "dey; bne CheckActivatePlayer" instead.

     

    There are lots of other optimizations to be made, but that's for later. :)

  3. Posted

     

    Haha, thanks for the link! That Java solution is hilarious, and some of the other contests (display 42!) are very cool, too. :-D I was following the obfuscated C contest for a while (http://www.ioccc.org/), but that's getting too oldskool...

     

    Damn, now I'm wasting time reading that site instead of coding my next demo or *gasp* work...

  4. Posted

    I am a software developer who, after all development got offshored, is forced to do business analysis.

     

    Ouch. :(

     

    I'm an IT security researcher, among other things doing malware reverse engineering and analysing embedded devices. Programming the VCS isn't very different from that. For example, malware uses tricks like self-modifying code or jumping into the middle of an instruction to make reverse engineering harder. My latest VCS kernel does both, although not for obfuscation, but to squeeze out more cycles. :D

  5. Posted

    Damn you slick Assembly geniuses. You make we batariBasic-dependent game programmers look like lazy idiots.

     

    Amazing demo!

     

    Thanks, but don't forget that we demo programmers can cut more corners, fake heavier and don't have to take care of so many things like unexpected input from players (or any input at all). In the end, we only have to concentrate on one specialized effect per screen, which makes it a lot easier.

     

    I for one have the highest respect for you game programmers!

  7. Posted · Edited by Kylearan

    You are a genius! Great work so far. ;-)

     

    ...it's not perfect yet, however. :-D On my PAL Jr. and a Grundig CRT, the scrolling is a bit jerky. It looks like it does scroll a little bit every step (opposed to skipping one step, then scrolling two pixels), but somehow it looks like the scrolling distance is a bit different each time and not exactly one pixel. I hope that makes sense somehow; it's hard to describe.

     

    What's also very weird is that step (kernel?) #2 sometimes fails to display the number correctly. Most of the time it works, but maybe one out of ten times, the "2" and the first square below it gets distorted, like the object is displayed some pixels to the left and then shifted one pixel to the right each scanline until it has reached its correct position, showing the rest of the object scanlines normally. That doesn't happen for the other kernels, and for kernel #2 only sporadically, with no discernible pattern.

     

    If needed, I could try to make a video of this. What would help testing though would be a version where we can manually trigger the next kernel, e.g. by pressing a button or so. Right now, even with the slow scrolling speed, it's a bit hard to see on my TV set how far each kernel scrolls exactly, or how the distorted number for kernel #2 looks like. Being able to manually advance the scrolling by one pixel would be nice.

  9. Posted

    Hi,

     

    I have just released a new demo for the PAL VCS on the Revision demo party. You can find it here, if you are interested:

     

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

     

    Direct download link: ftp://ftp.scene.org/pub/parties/2014/revision14/demo_oldskool/tim1t_cluster.zip

     

    I would like to thank you all for being such a great resource of information and help, especially Omegamatrix, SeaGtGruff, Thomas Jentzsch and Spiceware. This is my first production for the VCS, and almost every time I had a question, I would search this forum first and invariably find an answer to it by one of you a couple of years ago already. :) This demo wouldn't have been possible without you.

     

    (And to pre-emptively answer Thomas Jentzsch: I know I have 3 frames with a scanline count of != 312, which I will fix in the final version. Right now I'm terribly exhausted and glad I met the deadline at all. ;) )

     

    -Kylearan

    • Like 5

  10. Posted

    I don't think this works I'm afraid - if [TrafficCacheStart+TrafficOffset0]=%11000000 and [TrafficCacheStart+TrafficOffset1]=%00000000 then it will have both cars enabled where only the first should be (where [address] is the contents of memory at address)

    Ah you're right. Somehow I misunderstood the meaning of these variables. Sorry for the confusion, my bad. I shouldn't post when I'm at work. ;)

  11. Posted · Edited by Kylearan

    Sorry for the triple post, but I have another one. ;)

     

    If you could use Y instead of X, you could make TrafficOffset0 and 1 the low bytes of pointers into TrafficCacheStart, using an additional 2 bytes of RAM. Then instead of

     

    	ldx TrafficOffset0
	lda TrafficCacheStart,x
    you could do

     

    	ldy #0
	lda (TrafficOffset0),y
    which saves you nothing for the first access, but 2 cycles for every subsequent access if you keep Y at zero. So eshu's solution becomes

     

    	ldy #0
	lda (TrafficOffset0),y
	bpl NoCar0
	lda (TrafficOffset1),y
	and #%01000000
	beq Car0NoCar1
	lda #%01110111
	bne StoreCache
Car0NoCar1:
	lda #%01110000
	bne StoreCache
NoCar0:
	lda (TrafficOffset1),y
	and #%01000000
	beq StoreCache
	lda #%00000111
StoreCache:
	sta PF1Cache
    for 27 cycles worst case.

  12. Posted

    Oh, and if you add an "and #%11000000" before the "tax", your look-up table only needs 4 bytes instead of 256, for an additional 2 cycles (for a total of 25 cycles). The downside is that your four bytes have to be stored exactly at location 0, 64, 128 and 192, but if you have other data or code that you can store inbetween, this is very much doable and should be fastest (and in the ideal case even the smallest) solution.

     

    My cycle counts assume that the look-up table is aligned to $100, by the way.

  13. Posted

    If you have the luxury of too much ROM (probably not, but who knows...), you could use a look-up table. Something like...

    ldx TrafficOffset0
lda TrafficCacheStart,x
ldx TrafficOffset1
ora TrafficCacheStart,x
tax
lda LookUpTable,x
sta PF1Cache

    Uses constant 23 cycles in all cases, but uses also 256 bytes of ROM for the look-up table. :P

     

    And in case the numerical ranges of TrafficOffset 0 and 1 are <16 and can be packed into one byte, this becomes even faster (16 cycles, or 14 if you can spare y as well).

  15. Posted

    Wouldn't the listing tell you up to what point it is working?

    It shows over 20 "label mismatches" with line numbers and addresses, yes, but the labels it complains about are at completely different places in the code. Some of them are declared in the "ORG $80" variable section, and some of them are (local) .labels used for branches. But these labels are not in the part of the code where a "jmp .test; $ALIGN 100; .test" removes the problems. (Instead of that "$ALIGN 100" workaround, removing some lines of code there would remove the problem as well, but of course I need that code.)

     

    @Thomas, the problems with posting source code are a) it's huge (several thousand lines of code in several banks) and I haven't found any logic behind the problem yet for isolating a simple test case, and b) it's the demo I will hand in for the competition at the Revision demoparty, so I'm not ready to show it publicly yet. :-/

     

    If I ever find out how I can trigger this with a simple test case, I will post it here of course.

  17. Posted

    DASM has problems when addresses change during assembly. Do you have conditional assembly blocks?

    No, except for what's in macros.h and ARPM_Bankswitch.h (see below).

     

    Also, what's the ORG of your code?

    I use the ARPM_Bankswitch.h macros by Robert Mundschau, and use several banks. I also use multiple "ORG $80; var ds 1; ..." declaration blocks to declare different sets of variables for different kernels. Might this be a problem? (Worked until now)

  18. Posted · Edited by Kylearan

    Oh my, dasm is still very broken. I never should have used it for my project, it drives me crazy... maybe we should pin a thread about its problem and weird idiosyncrasies for newbies like me, to warn them. (Are there any better alternatives, for Windows?)

     

    Now dasm aborts assembly again with nonsensical "label mismatch" errors which all worked before. Unfortunately my project is so big and I don't really understand the issue, which makes it hard to isolate the problem and post a test case. So let me at least try to describe what's happening when:

     

    I have a larger chunk of code where essentially I do several "lda #<label; adc ZPvarA; sta ZPVarB + LabelA - LabelB + 1". No branches in there; a jmp and a bcc a couple of bytes before, and the next branches happens a lot of bytes later, but not in this larger chunk. Suddenly assembly failes, complaining about lots of label mismatches which for the most part have nothing to do with this part of the code.

     

    If I add a "jmp .test; ALIGN $100; .test" inbetween, suddenly all works again.

     

    Argh! Good thing I don't (yet) have to fight for every byte and can use silly workarounds like this. I hope this won't come up more often.

  20. Posted

    How sensitive are TVs to infrequent, small variations in number of scanlines?

     

    I see Thomas notifying other people when their kernels have variable scanline counts, and found a few discussions on rolling screens on TVs so I guess it's fairly important to have a constant scanline count. So far my PAL kernels manage to generate a constant 312 scanlines according to Stella. The only problem is when I switch from one Kernel to another, which only happens every 30 seconds or so. Then there is one single frame with a different number of scanlines, before it will be 312 again next frame. Is this single frame already enough to cause screen rolling?

     

     

    Related question: Debugging (or even detecting) scanline variations is hard if the number of scanlines only varies in one single frame every 20-30 seconds. Is there some way to tell Stella to break if the number of scanlines in a frame deviates from a specific number? Or to generate a trace/log of scanline counts, so I can see the number of scanlines per frame and find out in which frame the number varies?

     

    How do you debug this kind of problem?

     

  22. Posted

    Regarding your #4 bug, are you sure when you used -v4 it didn't actually create a binary?

    No, I'm not sure actually - after testing -v1 and -v2, I assumed higher levels will only output more stuff in addition to lower levels and would fail for the same reasons. I will test more thoroughly.

     

    Windows, Linux, and OS X x86 32-bit binaries are in the .zip file attached below.

    Thanks a lot! I will test them tomorrow and report back.

  23. Posted · Edited by Kylearan

    Hi,

     

    There are at least three [bugs] that I can think of from the top of my head.
    [...]
    2. Sometimes the assembler produces several hundred bogus label mismatches in early passes but successfully assembles in later passes (I fixed it by suppressing errors until the final pass, but the code isn't very good.)

    3. Sometimes when in the second pass, a negative branch target may differ from its location in the first such that seems to be <-128 bytes away. If DASM would just complete the pass, it would find that the branch location also moved such that it would resolve properly, but instead it triggers a fatal assembly error.

     

    Sorry to necro this old thread, but I've run into both bugs as well. Are there any fixes or workarounds for this? Right now, I'm unable to continue development which is very frustrating. :(

     

    I've also discovered two more possible bugs, one probably related to the bugs above:

     

    4. When I ran into the branch bug (3.), I wanted to see what was going on and increased verbosity (-v1 to -v4). The result was that dasm throws label mismatch errors after the first pass which were not there before with -v0! In fact I have code that assembles correctly with -v0 but will throw an error with -v1 or above. Just increasing verbosity should in no way affect assembly!

     

    5. There is no lda (nn),x addressing mode on the 6502, only lda (nn),y. But instead of throwing an error, dasm silently assembles lda (nn),x into lda (nn,x)! That cost me an hour of my life until I spotted this in Stella's debugger.

     

     

    I'd greatly appreciate any tip how to circumvent bug 2. and 3., or if someone could post their private build of dasm that fixes those. Otherwise I would be forced to port 3 banks of code to another assembler, which would be a lot of work. :(

     

    EDIT: I'm using dasm 2.20.11 on Windows 7, by the way.

     

    -Kylearan

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...