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

KrunchyTC

Members
 View Profile  See their activity

  • Posts

    192

  • Joined

  • Last visited

 Content Type 

Posts posted by KrunchyTC

    cc7800, a C compiler dedicated to the Atari 7800

    in Atari 7800 Programming

    Posted · Edited by KrunchyTC

    On 6/15/2023 at 5:25 PM, Defender_2600 said:

     

     

    full 160B 4bpp, up to 5 (160B) sprites in the same horizontal area (this has been tested) :

     

    I still have questions. Would this zelda demo still be possible with game logic present?

     

    Also, the Bomb Jack example above, could the back ground be done in 160B? if not, what is the difference between the two besides color?

    cc7800, a C compiler dedicated to the Atari 7800

    in Atari 7800 Programming

    Posted

    4 hours ago, bsteux said:

    Have you played Atari today ? Here is a 60 fps shmup for the Atari 7800 (well, not really, it's just the beginning of it, but well... it runs at full speed !).

    Nothing really new this week, as this is just an integration of the previous developments in order to check that everything fits in...  In the end, it's a rather complete basis for developing a shmup : the code manages the FIFOs for bullets, enemies, explosions, the collisions, the music (Pokey & TIA for sound effects) and the scrolling background. And the gameover (I'm proud of this one with the big skull). It just lacks the enemy spawning (I just spawn a single boss) and the level design (it's YOUR work as game developers).

    The result is that all the stuff takes approximately 70% of CPU available (in NTSC and 60fps), so there is still room for completing the game. On the other hand, it terms of ROM space, it's already very tight.

    Indeed, this is the first time I'm using cc7800 to make a true supergame (128KB ROM with bankswitching). The memory layout is the following (each bank is 16kB) :

    - Bank0 (or default bank) is the one that is fixed at 0xC000 => 0xFFF (in the ROM layout, it's indeed the last one. cc7800 manages this for you). It contains most of the code (including RMTPlayer for the Pokey Music) and 4kb of sprites that will be used throughout the game (spaceship, gameover, the bullets, digits for scoring...). In the end, Bank0 is almost full (there is still ~2kb of ROM available, 4kb if you remove POKEY RTMPlayer support).

    - Bank1 to Bank6 contain the level definitions and are mapped from 0x8000 to 0xbffff on demand (when you jump into a banked function, there is automatic bankswitching). I've only included the definition for 1 level, but the bank is almost full (4kb for the tiles definition, 4kb for the sparse tileset definition (the actual layout of the background), 4kb for the enemy sprites (here only 1 160B big boss sprite), 2.7Kb for the Pokey music and 1.3kb for the enemy management code). There is no room anymore for the spawning of enemies. Solution ? Reduce the music size - nice music but too fat - and reduce the tileset definition by reusing parts of the layout. 

    - Bank7 contains the initialization code (palettes definitions, multisprite library init, etc), which helps to reduce bank0 usage. A splash screen would perfectly fit there...

     

    In attachment, you will find :

    - The latest version of cc7800, with several bankswitching related bug corrected.

    - 2 tested ROMS :

             . one with RAM at 0x4000 (with a vertical scrolling in immediate mode), no pokey and a lot of CPU available

             . the other with Pokey at 0x4000 (with music, but background drawing in indirect mode). Less CPU available, but not that bad indeed.

    - The C source code of the Shmup game (let's call it Power Shmup 7800)

    - The yaml and png to be used with sprites7800 and tiles7800 to generate the graphics code.

     

    In order to compile the full thing, type in cc7800 directory (from the github repository) : 

    cc7800 -g -v -Iheaders -Iexamples -DMULTISPRITE_USE_VIDEO_MEMORY examples/example_shmup.c

    to get the the immediate mode vertical scrolling, and 

    cc7800 -g -v -Iheaders -Iexamples -DPOKEY_MUSIC examples/example_shmup.c

    to get the one with some Music. The 2 options are not compatible yet, since both of the them use the 0x4000 precious memory bank (Concerto doesn't support 0x450 Pokey at the moment).

    (the -g flag generates the .asm and .lst files, the -v generates a verbose output with the full memory layout. Very very instructive. You need to understand this if you want to go further).

     

    You can also compile with -DDEBUG flag to see the CPU available on screen.

     

    Next time ? The use of sparse tiling to draw the background of a single screen game.

     

    gameover.png

    shmup.png

    shmup_enemies.png

    cc7800-0.2.15-x86_64.msi 1.59 MB · 1 download example_shmup_pokey.a78 128.13 kB · 1 download example_shmup_vmem.a78 128.13 kB · 1 download shmup.yaml 3.62 kB · 1 download example_shmup.c 23.71 kB · 1 download

    Thats awesome! Hope this evolves into a full game. Need more shmups!

    • Like 1

    7800 Serial Number List

    in Atari 7800

    Posted

    2 hours ago, Crazymoon67 said:

    comp modding a low serial is probably not a good idea its worth more OG ill buy the modulator off you if you want to sell it it should have a date code on it from 6/84.

    Agreed.

     

    Do we know which models were the ones that were locked up in a warehouse for 2 years? and which ones were manufactured after Atari sold the first batch?

    cc7800, a C compiler dedicated to the Atari 7800

    in Atari 7800 Programming

    Posted · Edited by KrunchyTC

    8 hours ago, bsteux said:

    From what I've read on the web (I've neither tested the game nor looked at the code), it's not considered a bad port. Double dragon is even cited as one of the best games on the Atari 7800 (well, there aren't many to be honest) https://neovideohunter.wordpress.com/2018/01/13/atari-7800-review-double-dragon-activision-1989/. From what I've seen, it looks like it was programmed by seasoned guys (given the specificity of the Atari 7800 and the lack of tools at this time). The upper part of the screen is in 320 mode, and it's using 160A sparse tiling mode for the background (with many palettes). Not so bad. The characters are ugly. They should have been using 160B mode, but they probably couldn't afford it (probably need to reuse the same graphics with different palettes due to the limited ROM available). And in contrary to the NES, a 2 players game is available ! From a technical point of view, it makes sense. Is it really that bad at playing ?

    Yeah I mean, it's an ok port for sure. it could have been better, like the fact there is no actual scrolling (slow and very coarse). Could have looked miles better, but as you said, they probably couldn't afford it (Jack Tramiel).

    • Like 1

    320 mode colours question

    in Atari 7800 Programming

    Posted

    13 minutes ago, RevEng said:

    It's worth spelling out that the shared bus impacts the 7800 resources in two ways... The first impact is lost cycles for the 6502, and the second impact is the shared address space, which limits the amount of graphics you can arbitrarily display in any one zone.

     

    As Trebor pointed out, Souper and Banksets remove the second impact entirely, since Maria gets a separate address space of graphics rom, independent from the 6502.

     

    The first impact is less of a big deal once you get to working with the 7800. You pre-bake stuff into the DLs to allow minimal updates. You use frame buffering so you don't have to partition cpu time into visible and non-visible buckets. You schedule events when needed rather than running them every frame. You optimise, pre-compute, and get a little clever about how you do things.

     

    The 7800 port of Petscii Robots has nearly the whole screen's worth of 6502 cycles to dma, but it runs about as fast as other Petscii Robot ports on systems without DMA penalties. Those other systems aren't holding things back - they're running flat out. We just had to optimise things a bit.

     

    I'm sure I'm coming across as cranky, but I get tired about reading about how terrible the shared bus is - the nes pundits like to bring it up a lot whenever one of these stupid vs threads comes up. Its kind of like complaining about how hard it is to keep a motorcycle upright at slow speeds. It's an issue I guess, if you can't hack it. 🤷

    Yeah, I get what you are saying. It does get brought up a lot. And I'm glad that it's not that big of an issue, as many programmers have said.

    • Like 1

    320 mode colours question

    in Atari 7800 Programming

    Posted

    21 minutes ago, Trebor said:

    We see overcoming, or at least working around of, weakness with mappers such as Souper and Bankset, tools such has 7800basic and cc7800, along with a slew of additional items.  The 7800 did not have the resources allocated to it, back in the day, as its contemporaries were provided.  For both software and hardware aspects of the system, relatively recent developments have really helped level the playing field more evenly; though each platform will still have their respective native strengths and weaknesses regardless.

    Ah, that makes sense. It's too bad the 7800 didn't have the resources it needed back in the day, which may have made it more attractive to 3rd parties. which probably explains why games looked, and performed the way they did.

    320 mode colours question

    in Atari 7800 Programming

    Posted

    4 hours ago, EricBall said:

    I'm a little late to the party, but I recently updated my Atari 7800 Programming website with a complete explanation of the 7800 graphics modes including P#C# to bitmapping (in the sub-pages)

    https://sites.google.com/site/atari7800wiki/graphics-modes/palette-sprite-bits

    https://sites.google.com/site/atari7800wiki/graphics-modes/palette-sprite-bits/320a

    https://sites.google.com/site/atari7800wiki/graphics-modes/palette-sprite-bits/320b

    https://sites.google.com/site/atari7800wiki/graphics-modes/palette-sprite-bits/320c

    https://sites.google.com/site/atari7800wiki/graphics-modes/palette-sprite-bits/320d

     

    In those docs, it mentions the shared bus being the 7800's biggest weakness, which is well known. But how much can that weakness be overcome through optimization?

    320 mode colours question

    in Atari 7800 Programming

    Posted

    1 hour ago, Muddyfunster said:

    I decided a long time ago that 320 modes are a bit like my wife shopping....best left alone and nothing good will come from me getting involved.

    I kind of agree. the 160 modes still look spectacular, and uber colorful to boot! 

    2600+ w/7800 support

    in Atari 7800

    Posted

    On 8/28/2023 at 9:17 AM, Atari_Warlord said:

    I agree and the original controller also made my hand cramp.  I always wanted an original CX40 with two buttons.  The second button could go on the front below the regular button.  It may need a switch to change modes, I count 4 options:

     

    1. Both Active (Default)

    2. Switch the function of each button (Only affects two button games)

    3. Only top button Active

    4. Only front button Active

    I found that holding the Proline controllers sideways minimized hand cramping. And makes them easier to use IMO.

    7800 hardware facts

    in Atari 7800 Programming

    Posted · Edited by KrunchyTC

    Ah, more insight on that generation of consoles! Thanks! And yes I agree, knowing a ton more about each console now, I used to think the 7800 was the worst by a wide margin. But realize its much closer to the SMS. Which is pretty amazing to me after thinking otherwise for over 2 decades.

    7800 hardware facts

    in Atari 7800 Programming

    Posted · Edited by KrunchyTC

    12 hours ago, bsteux said:

    Using bitmaps saves on sprite usage (wrt indirect access / tiling), but definitely eats into the foreground sprite count. Indeed, Maria doesn't distinguish between background and foreground, and even doesn't know about sprites. It just displays objects in order, either in immediate mode (aka sprite or bitmap mode), on in indirect mode (aka tiled mode), until it has finished or there is no DMA cycles left on the line... Completely different from the NES, but very flexible and keen to display big "sprites", bitmaps, or many small sprites at your will... The main drawback (to me) is the 6502 speed bottleneck to fill the display lists, and the memory layout which is very special and limiting (except with bankset bankswitching, which requires to handle the HALT line on cart).

    https://segaretro.org/Sega_Master_System/Hardware_comparison#:~:text=The Master System is also,same reasons (see above).

     

    I was reading through this page, and I think a lot of the info on this page is wrong based on what I've been told here. It says the 7800 can only display 12 colors per zone/scanline (I thought it was 25, correct me if I'm wrong), it doesn't have tile compression, can't do smooth scrolling, and can't do backgrounds without crippling performance.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...