EricBall
-
Posts
2,427 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by EricBall
-
-
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:
- I don't believe there is a high level language for the 7800 like bB for the 2600.
- The TIA is fundamentally easier to understand that MARIA. (Playfield + sprite registers versus display list.)
- It takes more code on the 7800 than the 2600 to get something other than a black screen.
- Stella has a built-in debugger, I don't believe any of the 7800 emulators have any significant debugging capabilities.
- More 2600 sample code available.
- I don't believe there is a high level language for the 7800 like bB for the 2600.
-
When you say "zero experience in programming", do you mean:
- 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.)
- 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.
- 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.)
- 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.
-
2
- 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.)
-
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.
-
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.
-
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.
-
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.
-
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.
-
If the ball is moving more than 1 pixel per frame, but less than one tile per frame, then you first do a simple bounding box to see if the ball is inside the tile. Then you do a line intersection between the line the ball is moving along and each of the tile's sides.
-
In Atari 2600 homebrews converted to ColecoVision Pixelboy suggested Skeleton+. If a CV programmer wanted to try, I could provide the source code. Of course there would be a lot of work recoding 6502->Z80, TIA 160x192 -> TMS 256x192 graphics and TIA -> SN76489A sound.
-
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?
-
The 7800 uses the same sound processor as the 2600. There is an audio input on the cartridge connector which was used by a couple of cartridges which included a POKEY (from the 5200).
Attached is a set of samples for all of the "notes" which the TIA can create.
-
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
-
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.
-
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.
-
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.
-
With the renewed interest in 7800 Development, I've created Atari 7800 Programming with the info I previously had in the Atari 7800 Programming wiki. If anyone is interested in contributing (or culling info from AA) please let me know.
-
1
-
-
The DPPH & DPPL registers give the 16 bit address of the first display list list entry. Each DLL entry follows the previous in memory. Each DLL entry contains a 16 bit address of the first entry in the display list used for OFFSET+1 lines (the DLL "zone"). (Each display list entry follows the previous in memory.) Each direct mode display list entry contains a 16 bit address of the bottom right sprite data. The current OFFSET value is added to the high byte of the bottom right address to get the address of the current line sprite data. After each line, the current OFFSET value is decreased, unless it is zero in which case MARIA uses the next DLL entry.
Each sprite uses one (or more) display list entries. Sprites wider than 32 bytes need more than one entry in a single display list. This is also try for sprites which wrap around horizontally. Sprites which span more than one DLL zone (typically 8 or 16 lines), either because they are tall or moving vertically, need more than one display list entry in multiple display lists. Dynamically building display lists is a lot of work and takes a lot of time.
-
Now, if I could only figure out how to do a full screen playfield
Except the 7800 doesn't have a playfield. It does, however, have indirect or character mode where the display list entry points to a string of characters (tile indexes).
-
Easy stuff first (i.e. answers exist in the forum)
I also don't quite understand the difference between the Display List and the Display List List. I have read the documents that GroovyBee has mentioned over and over...which ends in me scratching my head going, "huh?"
I guess I'm just wanting to understand what each does specifically how I go about building the lists. I mean, what determines how they are built? I know there are the documentations that talk about it, but I was hoping that some here would share their experiences with them.
Sample 7800 source code using (ZP,X)
In all respect to the 7800, I'm surprised someone hasn't created a BASIC like program for developing 7800 programs in a similar fashion that batari BASIC has done for the 2600.It's a time & effort issue. Maybe if you want a tool like batari BASIC you can assist GroovyBee with his toolset.
-
This assembler language to me has no real plain and simple function to each line
No, each opcode is well defined and performs a very distinct operation. However, because each opcode is very simple, you need many of them to accomplish each task. So k = i + j would break down into at least three instructions in 6502 assembly:
LDA i ' load the byte in RAM with the label i into the accumulator ADD j ' add the byte in RAM labeled j to the accumulator STA k ' store the accumulator to the RAM address lableled k
(Labels are handled by the assembler and would need to be defined elsewhere.) Now imagine what a more complicated operation would be. Writing in assembler requires you to think in small steps.
what commands you need to do to activate and call upon the particular chips such as maria tia and so on, also worry about memory and hunderds of other things.All of the chips are controlled via specific memory addresses. So STA WSYNC writes a byte to a memory address used by MARIA which causes it to halt the 6502 until the start of the next line. And yes, although the assembler will do a certain amount of work for you (turning labels in to addresses, instructions into binary values, etc) you, as the programmer, are responsible for most of the work.
What order does the assembler language start?I'm not sure what you are asking. On startup the 6502 reads the address stored at the reset vector (I can't remember the specific address offhand) and starts executing at that address. On the 7800 that's the BIOS ROM which displays the Atari logo then tries to determine whether the cartridge is a 2600 or 7800 cart then executing the cart. But to start learning 6502, you might want to try Assembly In One Step.
why then not a atari 7800 have a grapics engine, or the code is the engineYou need to remember the 7800 was first released in 1984 and it contains only 4K of RAM and the CPU runs at 1.79MHz, i.e. a thousand times slower than today's computers and a million times less RAM. The 7800 does have a graphics engine - the MARIA chip, which is capable of displaying hundreds of sprites onscreen and can create a display without the processor having to update it every line like the 2600. What the 7800 doesn't have is a graphics library (other than the one Groovy Bee created for his use). But that's a good thing because you can write your code optimized for your game rather than dragging in functions and features which you aren't using.
-
There's a type in there Eric, because that's an invalid addressing mode. To match the description you need to use "STA ($7B),Y".
Quite correct. What I gave is not a valid NMOS 6502 addressing mode. STA ($7B,X) is a valid mode but does the add before the address fetch.
-
Assembler is the human readable version of the processor's native language. A good 6502 example is:
STA ($7B,Y)
Which translates to:
1. read the two bytes stored at hexadecimal memory addresses $7B and $7C as a 16 bit value (LSB first)
2. Add the current value of the Y register to the 16 bit value
3. Store the current value of the A register using the 16 bit value as an address
Assembler is termed a "low level language" - each instruction is a very small & simple step in the program. An Atari 7800 game will contain thousands of instructions. And each instruction (i.e. STA) can be used for multiple functions. In the above example the instruction may be creating or updating a 7800 Display List or changing which character is displayed onscreen, or ... Without comments to provide context determining what each instruction does (on the macro level) is extremely difficult. (Which is the main challenge of disassembling a game.)
The power of assembly language is there is nothing between you and the hardware. You are in complete control of the CPU. But that also means you need to create code for everything. The Atari 2600, 5200 & 7800 don't have bitmap displays. To display something onscreen you have to feed the graphics processor (the TIA, GTIA & MARIA respectively) the required data (and, in the case of the 2600, at the correct time). There's no plot(x,y) command, just a lot of STA instructions.
I understand your disappointment with the sound capabilities of the 7800. For compatibility GCS (the creators of the 7800) included the TIA from the 2600 (which provides graphics, sound & paddle inputs on the 2600). For cost reasons Atari didn't include the POKEY from the 5200 (which provides sound & paddle inputs). Thus the 7800's sound is the same as the 2600: 5 bit frequency divisor (32 "pitches") and 4 bit LFSR selector (10 "waveforms") which produce around 200 usable "notes". But the notes aren't like a piano, nor is there a lot of ability to generate sound effects.
I also wouldn't expect to accomplish anything, other than learning some basic assembly, in 5 days. But if you're up to the challenge, I'd recommend starting with the 7800 Software Guide. It gives all the details of the 7800 hardware and Display Lists.
-
As everyone else has indicated, to start programming any PC and an emulator will get you going. Start simple and add complexity over time which should avoid the problem of the emulator doing more than the console is capable of, at least at the beginning. (Starting small and incremental enhancements is also good to keep up your enthusiasm & drive.) And once you have something working, reach out to the community. You may not have a RAM cart, but others do and many will help at least sanity test your work in progress.
However, I have to ask - if you have no assembly experience, why start with the 7800? You are probably better off starting with something which can be programmed at a higher level and with better documentation and a larger homebrew community. batari Basic for the 2600 comes to mind. The problem with the 7800 is it requires a lot of code to get something to appear onscreen. The 2600 is a little easier in that respect (although some code is required to make a stable screen).
-
Note: don't use WSYNC outside of the DLI, if you have a DLI.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
interested in programming for the 7800
in Atari 7800 Programming
Posted
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.