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

EricBall

Members
 View Profile  See their activity

  • Content Count

    2,361

  • Joined

  • Last visited

Posts posted by EricBall

  2. Posted

    More specfic on what Eckhard wrote about (Thanks for the link Eric!)...

    PAL throws NTSC $E all the way to the top. NTSC $F does not exist under PAL.

    Note: the 7800 (and probably the other Atari 8 bits) have a trim resistor which affects the color. Color is via a delay line tap and the resistor changes the delay and thus the color. So some of the differences may be due to how the trim resistor is set.

  3. Posted

    from Eckhard Stolberg:

     

    In MARIA mode the palettes of the NTSC 7800 and the PAL 7800 seem to be pretty much the same. The only difference is that PAL TVs don't have a tint control, and that the red-green balance (that's what 'tint' controls, right?) is fixed a bit on the greener side.

     

    I tried Atari's palette test program on my NTSC 7800 connected to a multi-standard TV. When I shift the tint slider so much toward the 'green' side that the turquises move down one row, then I get about the same palette as when I use Atari's palette test program on my PAL 7800 connected to the same TV.

     

    from Eric Ball

    There may be a slight difference in the CPU timing between PAL & NTSC, but there are the same number of cycles per line. The bigger difference is the frame refresh (50Hz vs 60Hz) and the number of lines per frame (312 vs 262) which means you have 50 more visible lines and need additional DLL entries. (Which is typically why NTSC games crash on PAL 7800s, due to a mis-triggered DLI, or show garbage at the bottom of the screen.)

     

     

    It's possible for a game to detect whether it is running on an NTSC or PAL system and adapt as required. The additional lines can either be blank or used to expand the play area.

    • Like 1

  5. Posted

    Here's an example of how to have DASM generate an .a78 file automagically:

           SEG     ROM
HEADER  ORG     ROMTOP-128
       DC.B    1  ; Header version
       DC.B    "ATARI7800"
       DS      7,32
       DC.B    "Cart title"
       DS      HEADER+49-.,0
       DC.B    $00,$00,256->ROMTOP,$00  ; data length
       DC.B    $00,$00  ; cart type
       DC.B    1  ; controller 1 type
       DC.B    1  ; controller 2 type
       DC.B    0  ; NTSC / PAL
       ORG     HEADER+100
       DC.B    "ACTUAL CART DATA STARTS HERE"
ROMTOP  ORG     $x000

; code & data here

       ORG     $FF80
       DS      120,0   ; 960 bit Rabin Digital Signature
       DC.W    ROMTOP + $07FF
NMI     DC.W    DLLNMI ; DLI interrupt handled
RESET   DC.W    START   ; execution start
IRQ     DC.W    IRQRTI ; IRQ can be triggered by the cart, point to an RTI instruction

    There may be some updates, but this will give you the basics.

  6. Posted

    The number of lines displayed is dependent upon the display list list. For NTSC the total number of lines in the display list list must be >= 243 (262-19), while for PAL it must be >= 293 (312-19). However, some of those display list list entries may point to a display list which only contains the 2 byte end of display list entry, in which case nothing is displayed on the number of lines given in the display list list entry.

  8. Posted

    I know that in the past emulators didn't track how many cycles MARIA used, I don't know whether current emulators track CPU cycles versus MARIA cycles. The only way MARIA could corrupt registers is via a DLI which doesn't properly preserve them.

     

    I remember in SpaceWar! 7800 I had a DLI in the first inactive zone which would just set a flag then RTI. The main code would loop on that flag instead of MSTAT. I guess you could do away with that and pop the SR & PC off the stack and make the ISR the start of the routine. Wouldn't be a bad idea to have the ISR check a flag to see if the previous frame had completed first.

     

    https://sites.google.com/site/atari7800wiki/ has some info on cycle counts and DLIs.

  9. Posted

    One immediate suggestion would be to try to eliminate the JSR OBJECTCOLL. Yes, it means you can use RTS to get back to the DOCLOOP, but it's costly in CPU cycles. You may have to use Branch+JMP sequences, but that's still faster than JSR+RTS. You can then also pull back the BEQ DOCNEXT into the OBJECTCOLL logic.

     

    How big are your objects & velocities? Is bounding box good enough or do you need pixel perfect? Can shots collide? You may want to have one set of routines for shots and another for other objects. Test the shots versus the other objects and the objects only against each other.

  10. Posted

    I don't believe there is a high level language for the 7800 like bB for the 2600.
    I'll have to disagree on that. I've been using "C" and my own assembly language games library for a couple of years now. My games Wasp!, Worm!, Harry's Hen House, Fruitarian, Monster! and Halloween are all developed using it.

    Let me correct that. There is no publicly available HLL for the 7800. Not to say that you have any obligation to make your toolchain available to others, but your personal toolchain doesn't help the OP achieve his programming dreams. Thus, if he wants to program the 7800 in anything other than ASM, he will need to develop the necessary tools.

  11. Posted

    So, I'm getting the sense that the 7800, for a beginner, is tougher to write for than the 2600?

    In my personal experience, yes; for the following reasons:

    1. I don't believe there is a high level language for the 7800 like bB for the 2600.
    2. The TIA is fundamentally easier to understand that MARIA. (Playfield + sprite registers versus display list.)
    3. It takes more code on the 7800 than the 2600 to get something other than a black screen.
    4. Stella has a built-in debugger, I don't believe any of the 7800 emulators have any significant debugging capabilities.
    5. More 2600 sample code available.

  12. Posted

    When you say "zero experience in programming", do you mean:

    1. You have no programming experience whatsoever. If so, there are far, far better places to start than the 7800. (Maybe batari Basic if you want to work on a console rather than a PC.)
    2. You have programming experience, but only with high level languages. Again, you might want to start somewhere else. IMHO the 7800 is tough to use because you have to write a lot of code to get things happening on screen.
    3. You've programmed in assembly, but not in 6502. See #2, although if you have experience in more than one ISA then picking up the 6502 isn't too bad. (Until you discover the index registers are only 8 bit.)
    4. You have 6502 experience, but have never programmed any games. I'd advise reading through the documentation linked to in the first thread before setting your heart on making a game for the 7800.

    I know this may sound discouraging, but the only way a game gets done is if you want to do it and are willing to put in the time and effort and work through a lot of challenges.

     

    Finally, my thoughts on your game ideas:

    • WWI dogfighter
      The 7800 GPU is sprite based with some tile abilities. There is no bitmap mode like the Apple ][ or C64. So anything on-screen has to be pre-rendered, not drawn with lines (ala vector graphics). Thus stuff which has to be at multiple angles is going to use up a lot of memory.
    • Super Mario Bros port
      Ahh.. the desire of many a 7800 fan. Although it might be possible to create a SMB style game on the 7800 (and even possibly re-use some NES assets), there's just too many differences between the systems to make a port feasible. See my comparison of the 7800 and the NES.

    • Like 2

  13. Posted

    I do know how to solder, are there any guides to specifically check for these?

    Using the circuit diagrams as a guide, follow the traces from TIA pins 2,5,7,8 and 9 (TSYNC, TLUM1, TLUM2, TLUM0 and TCOL respectively, see the far right side of the middle of the diagram) and check each component along the way for bad solder joints or other evidence of faults.

  14. Posted

    Do you see similar problems with other 2600 games? The 7800 uses some external circuits to combine the TIA and MARIA video outputs. Maybe you have a bad component or connection somewhere.

    There is slightly, but not nearly as bad, how would I check that?

    Do you have the tools and ability to make the repairs? (i.e. how are you with a soldering iron and circuit schematics?) If you don't (or don't know someone who does) then your options may be to either live with the problem or buy a replacement. If you are interested in making the repairs, the schematics for the 7800 are in the Atari 7800 Archives.

  16. Posted

    Are more tools necessary than CC65 is able to provide in order to facilitate coding in C??

     

    It all depends on what "coding in C" means. Obviously the 7800 doesn't have I/O which would fit stdio.h, so that's kinda out. The C compiler would also have to do the following (off the top of my head):

    1. Provide a peek & poke to modify the TIA, MARIA and RIOT registers. (Although I guess this could be done with pointers.)

    2. Handle the 7800 memory map (zero page $40-$FF, RAM space, ROM space)

    3. Put code & data on the correct ROM addresses (for holey DMA)

     

    But it's certainly possible to use C to develop for the 7800. Much of 7800 code is basically data movement. And it's certainly possible to describe the Display List as a C structure.

     

    Of course, it's tough to match the space & speed of hand coded assembly.

  17. Posted

    Huh, this is the first time I've heard of this problem. (Or is it... hmm, vague memories of a complaint.) There was a bug in the original release of Skeleton+ (and maybe in the Activision compilation) where the YOU WIN screen would roll because I messed up the scanline counter. This was corrected in later carts.

     

    I don't think the source for Skeleton+ was ever released. The source for Skeleton (possibly an early version) might be in the Stellalist archives.

     

    However, I might be able to track down the source code and make a patch. I just happen to be transferring my backups to a new 2TB external drive.

  20. Posted

    There's a slightly later version of it on this page. I did not due a compare to see what changed however.
    I'd say its a different document entirely ;).

    The front matter is certainly different between the March 84 and the October 84 documents, but there's a lot of common stuff. However, I haven't looked hard enough to confirm that everything in the March 84 document is in the October 84 document.

     

    Huh, it looks like there was a planned 68K bus version. For arcade games maybe?

  22. Posted · Edited by EricBall

    Let me see how quickly I can help you develop your text display. I'm going to work backwards from the graphics data. The target is a 40x25 monochrome text display using 8x8 1bpp characters.

     

    On the 7800, graphics data is stored as follows:

    1. most signficant bit is leftmost pixel

    2. each line is stored on a separate page

    3. the last line is stored on the first page

    4. graphics data is stored on even 2K (8 line) or 4K (16 line) segments

     

    So, for your text display, each character is made up of 8 bytes which will be stored at $F000 - $F7FF. For example, the letter F (ascii $4F) would be:

    $F04F  $00  ; ........
$F14F  $60  ; .##.....
$F24F  $60  ; .##.....
$F34F  $60  ; .##.....
$F44F  $7E  ; .#####..
$F54F  $60  ; .##.....
$F64F  $7E  ; .######.
$F74F  $00  ; ........

    The 7800 supports direct sprites, where the address in the display list entry points to the graphics data, and indirect sprites (also called characters or tiles) where the address in the display list entry points to a list of indexes which are then used to address the graphics data. For your text display we will use indirect addressing as it is then possible to create a standard memory mapped text display where each byte in memory is displayed as a single character onscreen. The display will be stored at $2200 - $25BF (40x24 bytes).

     

    On the 7800 a set of lines of graphics are described by a display list (stored in RAM) which is made up of display list entries. For your text display each active line contains two 5 byte display list entries and a 2 byte display list terminator. For example, the display lists for the first two rows of text would be:

    $2600  	$00,$60,$22,$0C,$00, $14,$60,$22,$0C,$50, $00,$00
$260C	$28,$60,$22,$0C,$00, $3C,$60,$22,$0C,$50, $00,$00

    The format of each 5 byte entry is: address LSB, mode byte, address msb, width, horizontal position. So for your text display you will need 24 display lists with the correct address for the start and middle of the line. (The width is limited to 32 characters, so each line is broken into two 20 character segments.)

     

    Graphics processing on the 7800 starts with the display list list which is a series of 3 byte entries which point to the display list and the number of lines to use for the list. The format of each 3 byte entry is: control byte (number of lines), address MSB, address LSB. The display list list also contains entries for offscreen lines. For your text display, the display list list would be:

    $2780	$0F,$26,$0A, $08,$26,$0A
$2786	$27,$26,$00, $27,$26,$0C, $27,$26,$18, $27,$26,$24
$278C	$27,$26,$30, $27,$26,$3C, $27,$26,$48, $27,$26,$44
...
$27CE	$0F,$26,$0A, $09,$26,$0A

    Once all of the display lists and display lists list are created in RAM, the MARIA registers are set to start the display:

    $20  $00  ; BACKGRND = black
$21  $0F  ; P0C1 = white
$2C  $27  ; DPPH = LSB of display list list
$30  $80  ; DPPL = MSB of display list list
$34  $F0  ; CHARBASE = MSB of indirect graphics
$38  $00  ; OFFSET = always zero
$3C  $C3  ; CTRL = 320 1bpp, monochrome, 1 byte per character, DMA enabled

    Your ROM also needs to set the following values:

    $FFF8           DC.W ROMTOP + $07FF
$FFFA	NMI     DC.W DLLNMI
$FFFC   RESET   DC.W START
$FFFE   IRQ     DC.W IRQRTI

  23. Posted

    It was you as I recall that mentioned there being 227 PAL color clocks per scanline (which, as I stated in the previous post, corresponds precisely to 454 MARIA clocks). How the external PAL clock of 4.43 MHz affects things, again, I have no clue, since I don't have any PAL hardware or any way of measuring any of this stuff.

    On an NTSC 7800 a single 14.3181818MHz (4x NTSC colorburst) crystal is used to generate both the MARIA (and thereby the pixel and CPU/TIA) clocks. The color output is this clock divided by 4 and hue/phase via a tapped delay line (same as the TIA in the 2600). However, the PAL 7800 uses a separate 4.433MHz PAL colorburst crystal to generate the color output. TVs are relatively tolerant of variations in signal timing, but not in colorburst frequency or phase (especially PAL). Curiously the schematics for both the NTSC and PAL 7800s have a 14.31818MHz crystal, which is different than the 14.1875MHz measured by nichtsnutz. It would be interesting if someone could open a PAL 7800 and see if they can read the frequency off the crystal.

  24. Posted

    In simple terms, the DL is what happens vertically on the screen (in 8 or 16 line zones). It points to several DLLs which is what happens horizontally on the screen. Therefore for a single level, the DL is usually setup and left alone. The appropriate DLL is rewritten everytime something changes in that zone - If the player moves up from zone 7 to zone 6, he gets removed from the zone 7 DLL and put in the zone 6 DLL. If the player moves right on the screen, the entry in the zone 7 DLL changes to show the new horizontal location. The DLL is created so farthest things are first and nearest are last in line.

    Hi Harry. A good explanation except you've reversed DLL and DL. The Display List List entries point to Display Lists which are then used to display several lines. And if a sprite moves between zones the Display List entry for that sprite is put in the appropriate Display List.

  25. Posted · Edited by EricBall

    With the advent of G2F and 160C in the "NES vs" colour section the nod should now go to the 7800 when displaying static screens.

    I think both of those graphics modes fall into the same class as the Amiga Hold-and-Modify (HAM) mode - great for static, pre-rendered graphics, not very useful for an actual game. (Then again, Tower Toppler uses artifact color intelligently, so never say never.) Also, I'm not sure that similar effects couldn't be generated on the NES.

     

    Mind you, I don't think the stock NES could do an 8way scroller like my game Dungeon! at 25 colours per scan line either.

    Umm... The NES PPU has a total palette of 25 colors: background + 4 sprite palettes of 3 colors + 4 tile palettes of 3 colors. Each sprite could use any of the 4 sprite palettes and each group of 2x2 8x8 tiles could use any of the 4 tile palettes. So it's certainly possible to use 25 colors on a single scan line. 8 way scrolling would require extra RAM in the cartridge, but it's fully supported in hardware.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...