Jump to content

tschak909

Members
  • Posts

    6,911
  • Joined

  • Last visited

  • Days Won

    6

Blog Comments posted by tschak909

  1. The NMI and IRQ vectors are described in any and all documentation about the 6502. These are addresses that are jumped to, when these events occur.

     

    The 6507 does not connect the NMI or IRQ lines to anything meaningful, so other than the BRK instruction in code (which generates an IRQ), the NMI and IRQ vectors are meaningless. The only one of any merit on the VCS is RESET, which is the address the 6507 jumps to when the processor is reset.

     

    -Thom

    • Like 3
  2. From 6502 Opcodes:

     

     

    So after the BIT command you'll use the branch commands BPL or BMI if you're checking the state of bit 7, and BVC or BVS for bit 6. Bits 0-5 do not get copied to a processor flag, so testing those bits is more involved.

     

    To further expand, in order to test those other bits, you would literally need to shift bits 0-5 left in order to test them with e.g ASL...

     

    -Thom

  3. The resulting display here is _very_ clean.

     

    That is to say, it is nicely centered on both CRT displays, as well as upscalers and CRT displays that try to make the best of a signal that is only "somewhat" compliant.

     

    See picture here: CJiEuxA.jpg

     

    And the vertical blank signals are turned off, NOT ONLY during VBLANK, but during the overscan. Why is this important? Because when a video signal is being generated, you see artifacts of various things, including the signal coming out of the horizontal blank (HBLANK) and the last little chirp of the colorburst signal. In my case, since I am using a display converter/upscaler to HDMI, I see the entire overscan area, including a chirp of the colorburst and a bit of noise in the back porch signal (which show up as very faint vertical bars along the left and right borders of the display)...

     

    Many games take liberties with the vertical timings, even though they generate a stable 262/263 (sometimes more, sometimes less) display, which causes the display to shift on an upscaler. And I've seen more than a few games that forget to turn off the vertical blank during overscan, leaving the artifacts I've mentioned above.

     

    -Thom

    • Like 1
  4. it CAN be as fast as assembler, particularly when the assembler is used to generate words. It does tend to show a bottom up coding style, however you can indeed flesh out general ideas of the program and evolve them over time.

     

    It is this bottom up "play with it approach", which evolves the tool you need for the task at hand.

     

    The lack of standard complex library functions isn't a bad thing. The bad thing in FORTH is when people do not properly abstract, making programs that are a mash of higher level and lower level words. Yes, it's legal, and FORTH will stay the hell out of the way. This is why Chuck Moore called traditional programming languages "Dampeners" and called FORTH an "amplifier" ... It is a direct reflection of the programmer's mind. If a programmer doesn't organize his thoughts, it will show up on the FORTH screens, for all to see.

     

    Now, I will say that I spend lots of my time in many different other languages, than FORTH. I love them all. C, C++, Objective-C, Smalltalk, Ruby, PHP, Perl, Python, Assembler for 6502, Z80, x86, PPC, ARM...BASIC... They have their weaknesses and their strengths, but I find myself liking FORTH on 8-bit micros like the Atari 800. Why?

     

    Because it's just the right balance of small, fast, and flexible. The interpreter clocks in at under 8K, and most applications once compiled only add a few K on top of that for the program code (not counting any data), and when I need really fast, I can make words that drop right into assembler.

     

    So sure, no standard set of stdio routines, but I will try to make my programs readable, after all, that is entirely within my control. :)

     

    -Thom

  5. Yes. David Sylvian has had quite the varied professional career, starting as the vocalist and principal songwriter for Japan (I recommend all of Japan's albums, as they show a marked progression of his vocal development within a very short period of time.)

     

    His work as the Japan-Reunited Rain Tree Crow is also quite good.

     

    I also love the work that his brother (Steve Jansen) has worked on throughout the years, including his 2008 release "Slope" which contains an excellent Sylvian guest appearance.

  6. I chose to load multiple character sets into memory, and change the CHBAS pointer at vertical blank. It takes up more memory, yes, but it will allow me to provide smooth animation for everything without sacrificing too many cpu cycles.

     

    -Thom

     

    I will try to use the smooth scrolling registers to move the invaders.

     

    Another approach to moving invaders is to have several different versions of the invader characters shifted by different amounts. As a simple example, if the invaders are 12 pixels wide and have two animation frames, you could have one animation frame drawn using the leftmost 12 pixels in a pair of characters and the other drawn using the rightmost 12. If there are four animation frames, then you could have invaders up to 10 pixels wide drawn in a two-character space or 18 pixels wide using a three-character space.

    The problem with that is you can run out of characters real quick; I think the A800 only has 128 chars to work with.

     

    Depends on what you're doing, I suppose.

  7. The code as is would execute 512 cycles faster (per page!) though, if you'd move the CRLP label just one line down.

    (Of course you should no longer trash the accu with "LDA $CD" for the next page, but rather use the X register for that check instead.)

    I'm pretty sure there's also no need for the two conditional branches if you swap the operands on the compare and load:

    	LDA $D5
    	CMP $CD
    	BCS CRLP
    

     

    oh wow, why can you do that?

     

    -Thom

  8. Well, I was thinking there might BE a need to fill sections of memory that do not begin on page boundaries (the atari usually crams its screen memory not exactly on screen boundaries, for example.) or should I just override that and move screen memory elsewhere myself???

     

    As for the routine, thanks for the tips.

     

    -Thom

×
×
  • Create New...