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

    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.

  4. Posted

    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?"

    Display List List Help

     

    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

    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.

  5. Posted

    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 engine

     

    You 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.

  7. Posted

    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.

  8. Posted · Edited by EricBall

    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).

  9. Posted

    I thought writing to the color registers during on-screen rendering of line RAM was supposed to result in color stretching, whether or not the color reg being written to was actually in use. But I don't see any. Is this behavior not properly emulated on the emulators, or does somebody know something I don't?

    I haven't kept up on 7800 emulator accuracy, but it's certainly possible that:

    1. writing color registers doesn't cause color stretching, or

    2. writing color registers causes stretching on real hardware, but isn't emulated correctly

    3. writing color registers causes stretching on real hardware and in current emulators

     

    Of course, if the side effect only occurs under some circumstances (i.e. only while DMA is active) then you may get a combination of all three possibilities.

  12. Posted · Edited by EricBall

    Hi guys:Does anyone have any alternate examples of reading the paddles and/or the driving controllers on the 7800? I have the tech demo (I think it's Eric's) and have attached it here. It seems to work fine, as long as there is *nothing* else going on (nothing else on the screen, etc.) which unfortunately doesn't help me with what I am working on.I have also done a search for code on reading the Driving Controllers but came up empty.I am moving an object back and forth along the bottom of the screen (like 'Breakout') and right now I am using the joystick, which doesn't feel right.Thanks,Bob

     

    Hmm... I can't think of a more efficient way to read the paddles than presented. Are you sure the problem is MARIA DMA? You should have (113.5 - 15.5 ) * 4 = 392 clock cycles per line to play with.

     

    I think I also did some 7800 sample code for driving controllers. Those worked better sampling per zone IIRC. Yep, see: my blog May 10, 2005

     

    The problem is that (again just like the 2600), the full range of the paddles lasts for up to two frames worth of video (hence why most or all games only use half the paddle turn range). The original way they were used was simply to watch for the trigger to hit as you went down the screen for a pong game.The best way might be a hsync interrupt in each line (or every 2 or 4 or 8 lines if you need less precision), but whatever you do it will probably eat up some CPU time.Compared to this, driving controllers are much easier to read.

     

    The problem with doing the paddle reads via a DLI is resolution. With standard 8 line zones you only get 200/8 = 25 positions. Smaller zones give you more resolution but require more work outside of the display since each sprite requires multiple DL updates. Smaller zones also means less CPU time per zone, which is the problem Bob is having.

     

    Starting the paddle capacitor charging at the end of the frame would shift the paddle to the center.

  13. Posted

    I wonder whether the GCC document timings were for the original prototype and the Atari document reflects optimizations made to later revisions. In nearly all cases the Atari timings are less than the GCC times (ignoring the Indirect/Character Map confusion). The only exception is the 5 byte header which is either 10 or 12 cycles.

     

    Now if I were to design it to maximize the DMA time per line while providing the 7 post-HSYNC CPU cycles:

    HSYNC start, CPU enabled, wait 7 CPU cycles (28 MARIA cycles), wait for CPU to finish bus access to start DMA (5-9 MARIA cycles), fetch headers (2 cycles per byte), fetch character map (3 cycles), fetch graphics (3 cycles per byte). Continue until last possible cycle given worst case shutdown (13 cycles). If DMA finishes early, enable the CPU.

     

    It might be possible to get more info by scoping the HALT pin.

  14. Posted

    One other item - WSYNC is not compatible with DLI. My first 7800 apps would STA WSYNC then test MSTAT for VBI. But then I figured out that STA WSYNC halts the 6502 so the DLI doesn't kick in as early. Additionally I think MSTAT is later than necessary. So I started using the DLI to flag the end of the frame and just have the mainline test for the flag without WSYNC.

  17. Posted

    I'll have to plug in my 7800 & CC2 and give this a try. There's no hard limit in MARIA which would restrict you to 192 active lines - you could try and display up to 243 although overscan will probably kick in somewhere between 200 and 240. You could also try scaling the level section down by 75% so it will fit onscreen. (Or get really tricky and have a virtual screen and scroll the DLLs depending on the player's position.)

  18. Posted

    I have a question...Since the 5200 and 7800 share similar processors...why couldn't one take a 5200 game and port it over the 7800 for learning purposes? I understand that there would be a lot of work to be done like address changes, setting up DL and DLLs, the graphics, but wouldn't the assembly code be similar? Just and idea.

    A game is made up of main two types of code - code which is responsible for getting stuff displayed, and code which is more display independent. (There's also code which does other I/O like user input and sound, but that's typically a much smaller piece.) You'd think it should be possible to somehow swap out the display dependent code, but unless the game was written with that in mind, you will probably find even the "display independent" code is structured to make the "display dependent" code as easy as possible. This might be something as simple as whether the GPU can reflect a sprite or whether Y=0 is the top or the bottom of the screen, but can be as challenging as bitmap versus tilemap backgrounds.

     

    Additionally, trying to reuse code for porting without the original commented source code will be much more difficult. Not only will you have to create a reasonable disassembly, but you will need to reverse-engineer the context of each piece of code.

  19. Posted

    As stated earlier, I plan to use a PC for 7800 programming. Here is what I have so far... Crimson Editor + 7800 Emulator + DASM

    Is there anything I'm missing?

    Nope. With that you just need time and desire to start working. Graphics tools might help once you get beyond the "get something one the screen" phase and into the "make it look pretty" phase. However, you may find it just as easy creating sprites by hand rather than trying to use tools which don't speak 7800.

     

    What I was thinking about attempting was using a ST emulator with all the development software Atari created. This stuff is available online. Would this attempt work?

    Maybe. I don't know if anyone else has gone that route. It might be easier or hard than the DASM+emulator route.

     

    Another approach to gaining knowledge of 7800 programming I thought about was learning the 2600 first. Even if it is another console, it might shed some light on developing 6502 assembly language skills.

    The advantage of the 2600 over the 7800 is it's easy on the 2600 to get something on the screen. 3 lines of VSYNC+VBLANK and 262 lines of playing with TIA registers. While the 7800 you have to set up your display lists and your DLLs and then hope you didn't forget something or you're staring at a blank screen wondering what you did wrong. The nice thing about the 7800 is once you get that working most of the programming is data movement and AI, while on the 2600 you get into display kernel programming trying to update those TIA registers ahead of the beam.

     

    Oh, I almost forgot...would anyone know how to test PC based 7800 programming efforts on a real 7800? This is mainly to test for any differences between an emulator and real hardware. Thanks again!

    Ask. There are people on the forum with the right hardware (i.e. CC2) to help out.

  20. Posted

    But in order to do that, developers have to exercise a little humility, and give up some creative control. That's sometimes been a challenge, I think. But the best homebrews (ports included) that I've seen produced tend to come from developers who are keen listeners and who are very responsive to feedback. A game like Oystron was molded like a sculpture. Most of the chisel marks were put there by the feedback from Stellalist. Some of the less enjoyable homebrews (and I won't name names) were victims of developers who would either veto suggestions or never ever opened up their games for feedback to begin with.

    Skeleton had that problem. I wasn't very receptive to feedback and was blinded to the "purity of my vision". I think Skeleton+ is more what Skeleton could have been if I had listened.

     

    And although johnnywc gives some excellent reasons to do a port, I think there are some significant downsides to ports:

    1. Copyright & Trademarks. Although they may be old and possibly even forgotten, you really don't want to have your creation taken away from you because you're infringing on someone else's IP.

    2. Although the 2600 has been pushed far beyond Pong & Combat, it still has limits. An original game can be reworked to fit what the 2600 can do, while a port will either die or suffer greatly in the translation.

  21. Posted

    I do not have a PSP, although I do have a PS3 and a DSlite.

     

    From what I've read, the PSP Go is a step backwards from the PSP w/UMD. About the only advantage of the PSP Go over the PSP is the smaller size (when closed). But the disadvantages are numerous:

    1. no older / used / rental games
    2. smaller screen
    3. more expensive (smaller) flash memory
    4. unknown durability of slide-out controls
    5. smaller form factor may be less comfortable
    6. various roll-out screwups

     

    And the PSP w/UMD is capable of downloading games, just like the PSP Go. So if you've been putting off buying a PSP, I'd recommend scooping up a PSP w/UMD before they're gone.

  22. Posted

    ok, to do what I would like (the DIG DUG improvement) is it a hack of the original game or do I need to program it from scratch?

     

    It depends on how easily the code can be modified to meet your requirements and how willing you are to compromise your dreams. Think of it this way - at one end of a line is Dig Dug unmodified; at the other end is your dream. To move one end requires effort; the other end requires sacrifice.

     

    The disassembly is probably a good place to start. That will give you a base to start modifying. At some point you may decide "you can't get there from here" and start from scratch. But the experience of modifying the base won't be wasted. You will better understand what you need to create in order to meet your dream. And you still may be able to use some parts of the original you modified.

  23. Posted

    can I smell elitism?? :D

     

    First - how much is your time worth? Whether it's minimum wage, $200/day or $45/hour, the programmer should be paid a reasonable amount for the time they will put into the project.

     

    Second - how many hours did you expect it would take to create your dream game? Several of the responders have created 2600 games so don't assume their estimates are excessive.

     

    Multiply the two numbers together and you have a price. Make your offer and see whether you get a response. But don't be surprised if no-one who doesn't share your dream and passion takes you up on the offer.

     

    Now, if the game can be created in bB then the task becomes easier. But bB has many limitations, so it's not always possible to create a given game with bB. (And not all games can be created on the 2600 because of it's limitations, no matter how skilled the programmer.)

     

    Personally, I'd take GroovyBee's recommendation. Take your desire and passion and make the game yourself. All of us started somewhere.

  24. Posted

    If I want a programmer to do a game for me (2600 one) how much is that going to cost me?

    A guy recently paid me US$45/hour for a small bit of coding. Even at minimum wage rates your cost for something coded from scratch will probably run into the thousands of dollars.

     

    You given a better indication of what you are wishing for, now how much are you willing to spend to see it made?

  25. Posted · Edited by EricBall

    C:\DASM>dasm 78db.s -f3 -o78db.bin -l78db.lst

     

    "78db.s" is what I called the source file that I downloaded from Dan Boris's 7800 tech page. I don't know exactly the significance of the "-f3", but the "-o78db.bin" results in an output file "78db.bin" that can be loaded into the 7800 Prosystem emulator. I also don't know if it is necessary to type the "-l78db.lst" part or not.

    The -l78db.lst creates a list file, which will show you the specific address & bytes your code assembled to. It's not required if you write bug free code. :) Similarly, -f3 specifes the error message verbosity. IIRC -f3 is almost required to get any useful info.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...