Wizzy on the 7800?

[+karri]

Just for info... I opened a pull request for adding atari7800 to cc65.

 

If you feel like giving some advice or contributing then here is the link.

#805 Atari7800 target by karrika · Pull Request #1692 · cc65/cc65 (github.com)

 

To get a local copy you can go to my repo at karrika/cc65 at atari7800 (github.com)

Then click in the green CODE button and choose download.

 

In linux you can build the compiler with:

cd cc65
make
sudo -s
PREFIX=/usr/local make install

I hope to get some "Hello World!" program implemented soon.

 

At least the Robot Finds Kitten compiled nicely on the new atari7800 target in cc65.
It also appears to run ok in the emulator.

 

rfkcc65.a78

[Trebor]

Hey karri..  just a heads-up, the same cc65 project and version of Robot Finds Kitten was converted and performed in 2005 with the code available on SourceForge.   

 

Thomas Mathys
Robot Finds Kitten | Jun 19, 2005 | Done

 

 

Hello World has also seen a couple of ports already: 

 

Eagle

Hello World (MADS Version) | Apr 16, 2021 | Done

 

Propane13

Hello World (Demo) | Nov 07, 2009 | Done

 

Just trying to prevent duplication of efforts, if you're looking to port something not done previously.  Regardless, if similarly porting of "Hello World" assists with a better understanding of the system and how to program for the platform, please don't let that deter your efforts.

[+karri]

7 minutes ago, Trebor said:

Hey karri..  just a heads-up, the same cc65 project and version of Robot Finds Kitten was converted and performed in 2005 with the code available on SourceForge.   

 

Thomas Mathys
Robot Finds Kitten | Jun 19, 2005 | Done

 

 

Hello World has also seen a couple of ports already: 

 

Eagle

Hello World (MADS Version) | Apr 16, 2021 | Done

 

Propane13

Hello World (Demo) | Nov 07, 2009 | Done

 

Just trying to prevent duplication of efforts, if you're looking to port something not done previously.  Regardless, if similarly porting of "Hello World" assists with a better understanding of the system and how to program for the platform, please don't let that deter your efforts.

 

Thanks for the links. I am hoping to use the TGI-graphics layer for the game. It would make it a bit easier for me, perhaps.

 

So what I am aiming at is a system where I can code the graphics like:

 

while (tgi_busy()) ;
tgi_setcolor(COLOR_WHITE):
tgi_bar(0,0,159,121);
tgi_setcolor(COLOR_BLACK);
tgi_outtextxy(10, 10, "Hello World!);
tgi_spritexy(10,20, wizzy);
tgi_updatedisplay();

 

So I would just like to put the DLL stuff under the hood and write the logic in C. So I am trying to find out if I can run the same C-code on the Lynx and the 7800 to some extent.

 

[+Pat Brady]

2 hours ago, karri said:

Thanks for the links. I am hoping to use the TGI-graphics layer for the game. It would make it a bit easier for me, perhaps.

 

So what I am aiming at is a system where I can code the graphics like:

 

while (tgi_busy()) ;
tgi_setcolor(COLOR_WHITE):
tgi_bar(0,0,159,121);
tgi_setcolor(COLOR_BLACK);
tgi_outtextxy(10, 10, "Hello World!);
tgi_spritexy(10,20, wizzy);
tgi_updatedisplay();

 

So I would just like to put the DLL stuff under the hood and write the logic in C. So I am trying to find out if I can run the same C-code on the Lynx and the 7800 to some extent.

 

If you're looking for an existing TGI implementation on the 7800: I doubt that exists.

 

If you're thinking about implementing TGI yourself: IMO a full-fledged TGI implementation will be a lot of effort, will be overkill for Wizzy, will require at least 8K of on-cart RAM for a frame buffer, and will probably run you out of CPU time when you start to use it.

 

If your Wizzy Lynx code uses TGI (or pseudo-TGI) functions only to draw backgrounds, sprites, and text, and maybe a few shapes at fixed locations, then I think it is probably feasible to implement the functions you need and re-use a lot of your existing Wizzy code. (I'm assuming you don't use functions like tgi_settextscale() or tgi_ellipse() with variable parameters.) But in order to do implement those functions, you need to be able to do at least Hello World in low-level C (or assembly).

 

How's it going with the Software Guide?

 

[+karri]

I skip all I don't need in TGI. On the Lynx there is a full TGI in the repository. But I link in  custom TGI with no text functions, no lines. I also add tgi_ioctl methods for sprites.

 

Wizzy graphics looks best as hand tuned 4 colour gray shaded. So it may be 160 x 121 screen that I aim for. No palette tricks. The charm in this game is good animations and the story. Not to squeeze out performance or wow effects.

[+karri]

It is obvious that I need to pass a few bits of success between levels in Wizzy. Could the high score function be used?

 

Is the high score chip in the console, some removable media, on the cart?

 

At a minimum one byte would be ok.

 

Found out that this stuff is rare. So I may go for passwords at the end of a level. Or if some giant bank-switching cart is common I could go for that.

 

What kind of binary release would be usable on a real console? I don't plan a real cart release on the 7800.

[RevEng]

Any format that saw commercial usage will be supported pretty well by emulators, flash carts, and homebrew cart boards. This would be 32k (flat), 48k (flat), 128k supergame, 144k supergame. Most of these will have some cart-ram or pokey sound-chip variants that will be well supported. There are more formats that were used commercially, but nobody has used them for homebrew AFAIK.

 

While HSC isn't practically an option on real hardware, it's available in emulation. If save data is needed on real hardware, the common go-to is the savekey device, though be forewarned that 7800 emulators don't support it. (AFAIK)

[+karri]

Thanks for the info. Looks like the 144k supergame with banks 6 and 7 in fixed locations and switching banks 0..5 in on demand would be just what I was hoping for. The TIA sound may be good enough for sound effects. You can always just listen to Spotify for background music  

[+karri]

I would like to have a 160 pixel scanline represented by 10 map indices. If I understand the indirect character mapping correctly I can only reference 2 bytes with one index. My tiles are 16 pixels wide and with 2 bits per colour I need 4 bytes.

 

Is there some nice trick available to point the byte index to a 32 bit wide tile?

 

The only trick that comes to mind is to double the indices on the scanline to point to two 8 pixel tiles (left + right side of my 16 pixel tile).

 

Which brings me to another topic. Is there a way to start the drawing from a negative hor position? Like drawing first 6 pixels outside the display area and putting just 10 pixels on screen.

 

The DLL and DL are in RAM. Same with the map index table. What about the tile data (graphics bytes). Do they have to be in RAM or can they be in ROM?

[RevEng]

For "tiles" bigger than 2 bytes of graphics, you can either do as you propose and use 2x double-wide indexes, or you can use sprites-as-tiles. The former is easier if the graphics all use the same palette, the latter allows each tile to use a different palette. (with the disadvantage that the character/tile index is distributed in the DL entries)

 

For negative positions of DL objects, just use x=255 (-1), x=254 (-2) etc.

 

The graphics data can be in ROM, even by Atari/GCC standards. (In theory, a fast underlying device can support all of this stuff in ROM, but this is less well tested with all of the various hardware carts. It also may be complicated by stuff like gate delays on certain cart address lines.)

[+karri]

I have to simplify the tiles a lot to get a level to fit.

 

One tile (16 x 16 pixels) can be 16 pixels high. But it consumes two indices of the map.

 

Currently I have two blocks of mapped tiles. On that you can walk on and one that blocks the way.

 

 

Did I just find the limit for mapped tiles on the 7800?

So if my tile starts at 8F00 and goes down to 8000 it only allows me to have one byte per tile for every line.
Does this 2 bytes per tile trick limit my character tiles to 128 tiles only? Or can I specify a secondary area for the other bytes?

 

So if the CTRL registers specify 2 bytes per index and CHARBASE points to the first entry of the tile graphics. Can maria fetch up th 512 bytes of data in pairs. Or is it limited to 256 bytes (indices 0..127)?

 

 

[RevEng]

The double-wide setting doesn't affect how graphics are indexed, so no, you don't get an extra block of graphics. Double-wide just instructs Maria to automatically grab and display the next byte of graphics after it has displayed the one referenced by the tile index. 7800 tiles are just character set graphics, with the same 256 byte character index limitation as other 8-bit machines.

 

If you need more that 256 bytes worth of graphics, then you need to use sprites as tiles. It adds a bit more complexity in terms of update, but the approach has the bonus of allowing a unique palette designation for each displayed spite-tile. (in addition to not constraining you to only using 256 bytes of graphics, or 256 total tiles.)

[+karri]

5 minutes ago, RevEng said:

The double-wide setting doesn't affect how graphics are indexed, so no, you don't get an extra block of graphics. Double-wide just instructs Maria to automatically grab and display the next byte of graphics after it has displayed the one referenced by the tile index. 7800 tiles are just character set graphics, with the same 256 byte character index limitation as other 8-bit machines.

 

If you need more that 256 bytes worth of graphics, then you need to use sprites as tiles. It adds a bit more complexity in terms of update, but the approach has the bonus of allowing a unique palette designation for each displayed spite-tile. (in addition to not constraining you to only using 256 bytes of graphics, or 256 total tiles.)

Thanks. I hope to use sprites only for character animations. It will be a challenge for me anyway. So I will continue to cut down the graphics to just 128 different 8 x 16 pixel tiles (2 bits per pixel).

 

The 16k banks would have all the graphics for the level and also the code for the level. I believe it is the bank at $8000 that can be switched. So one bank could have:

4k for the tiled background

4k for the index map (64 x 64 tiles) to specify the playfield of this level

8k for animations, texts and code.

 

With 5 switchable banks I could create one part of the game.
- outside the castle
- inside the castle
- the dungeon under the castle
- Call to arms

- final encounter of level 1

 

 

 

[+Pat Brady]

2 minutes ago, karri said:

Thanks. I hope to use sprites only for character animations. It will be a challenge for me anyway. So I will continue to cut down the graphics to just 128 different 8 x 16 pixel tiles (2 bits per pixel).

 

Wait! Before you do that: the 7800 doesn't have a limit on the number of sprites. In fact you will notice that the Software Guide never uses the word "sprite." When @RevEng and others say "sprite" they really mean any object drawn in direct mode.

 

In your case, since your background tiles are 4 bytes wide, you can draw them in direct mode with almost no penalty. And if you go that route, you can make however many tiles you want.

[+karri]

16 minutes ago, Pat Brady said:

 

Wait! Before you do that: the 7800 doesn't have a limit on the number of sprites. In fact you will notice that the Software Guide never uses the word "sprite." When @RevEng and others say "sprite" they really mean any object drawn in direct mode.

 

In your case, since your background tiles are 4 bytes wide, you can draw them in direct mode with almost no penalty. And if you go that route, you can make however many tiles you want.

That is a good point, but the RAM is also quite limited so I was hoping to save sprites for the animated stuff. After all the background is only eye candy - not important.

 

So I assume that I could use index 0, 2, 4 to get tiles 0, 1, 2. And if I use index 1 I get the 2nd half of tile 0 and the left part of tile 1 (in 2 bytes mode).

 

Then  I could also re-use the 8 pixel tiles to get two 16 pixel tiles.

 

 

The 16k banks would have all the graphics for the level and also the code for the level. I believe it is the bank at $8000 that can be switched. So one bank could have:

4k for the tiled background

4k for the index map (64 x 64 tiles) to specify the playfield of this level. I have to extend this to a 24 x 12 RAM window for display as the tiles are only 8 pixels wide.

8k for animations, texts and code. (It is easy to have segmented code overlapping the memory space in cc65).

 

With 5 switchable banks I could create one part of the game.
- outside the castle
- inside the castle
- the dungeon under the castle
- Call to arms

- final encounter of level 1

 

All good games are released as a trilogy. So I can then just release the rest of my 7 part trilogy on some larger magic cart in the future.

[+karri]

I did manage to squeeze the tilemap to half. But I have to draw the trees and flower separately later. Not too bad. Usually there is only 3 trees visible at most. With 6 acorns, Wizzy, a npc and a spider. Perhaps even a speech bubble with some text. I have no experience of how much memory or time this takes - yet...

[+Pat Brady]

1 hour ago, karri said:

That is a good point, but the RAM is also quite limited so I was hoping to save sprites for the animated stuff. After all the background is only eye candy - not important.

 

It's certainly possible I'm missing something, but since you have a relatively small number of zones and dynamic objects — meaning player, enemies, NPCs — I think you should be okay on RAM. By my quick calculation (8 zones, 11 160A tiles across, up to 4 160B dynamic objects per zone), doing everything in direct mode, the DLs will total 536 bytes. Going up to 10 zones increases it to 670 bytes. This is all of the headers. And, doing it this way you shouldn't need any RAM for playfield map translation. And, as RevEng mentioned, this way each tile can have its own palette.

 

The DLL is another ~50 bytes.

 

Obviously I don't know how much RAM you need for game logic and state.

 

Quote

So I assume that I could use index 0, 2, 4 to get tiles 0, 1, 2. And if I use index 1 I get the 2nd half of tile 0 and the left part of tile 1 (in 2 bytes mode).

 

I believe so, though haven't tried it myself. Come to think of it, I may have done that by accident at some point.

[gambler172]

Hi Karri.....looks good so far.

[+karri]

Thanks for all help. I see the point in managing the background by having indices in the DL. But on the Lynx I have a certain logic with sprites that look up their data from a table in RAM. There is also some effects that I use for smoothly moving Wizzy away from the center of the screen to maximize the playfield in front of her. So I start by trying to have a very similar architecture.

 

I also tried colours already, and they look nice. Perhaps I go with some limited light colour map. Or use some tinted monochrome visuals.

 

The good thing is that there is no dead-line...

 

I am also writing a small book about this game. During this week I learned to bind a book by hand. It was easy and quite fast after all. Next week I hope to learn how to create the title in gold letters on artificial leather cover.

 

The story of Wizzy will also be available in PDF format. It helps playing the game as you get some background info of the storyline.

[+Defender_2600]

2 hours ago, karri said:

After all the background is only eye candy - not important.

 

Absolutely it's your baby, but if another opinion matters to you, I see good potential in your game and I think it would be perhaps a missed opportunityi f it looked like a Game Boy while the depth of color on screen is a strong point and distinguishing feature of the 7800. I think people would appreciate the eye candy.

 

Edited March 4, 2022 by Defender_2600

[+karri]

12 hours ago, Defender_2600 said:

 

Absolutely it's your baby, but if another opinion matters to you, I see good potential in your game and I think it would be perhaps a missed opportunityi f it looked like a Game Boy while the depth of color on screen is a strong point and distinguishing feature of the 7800. I think people would appreciate the eye candy.

 

I assume that I start by using the character maps. If I get the animations sorted out then I can come back to the backgrounds.

 

On the Lynx I started with real time cart loading during the play to allow me to use larger animations. Some of there animations are 12 frames long. Like the Swedish chef in the castle. I want to ditch it as soon as Wizzy walks away to make room for animations of the bard and the king. On the Lynx I can throw away stuff. But on the 7800?

 

[TailChao]

On 3/3/2022 at 12:52 PM, RevEng said:

The graphics data can be in ROM, even by Atari/GCC standards. (In theory, a fast underlying device can support all of this stuff in ROM, but this is less well tested with all of the various hardware carts. It also may be complicated by stuff like gate delays on certain cart address lines.)

I don't think this should be considered theory anymore. If a flash cartridge or production board doesn't accommodate Maria's fetch speeds for both textures and Display Lists - it's a compatibility issue. Large flashes in the 55 to 70ns range have been affordable for years outside of the current chip shortage.

 

 

20 hours ago, Pat Brady said:

In your case, since your background tiles are 4 bytes wide, you can draw them in direct mode with almost no penalty. And if you go that route, you can make however many tiles you want.

You can also take this further and divorce the background rendering sizes from your underlying tile data, so when the background is drawn its textures are batched together to use the minimum number of Display Lists. You only need a new Display List entry when the palette changes or the textures aren't sequential in memory, and since each Display List takes 8 cycles to parse - you're gaining ~10 pixels of fillrate on each use for 160A or 320B.

 

 

5 hours ago, karri said:

I assume that I start by using the character maps. If I get the animations sorted out then I can come back to the backgrounds.

 

On the Lynx I started with real time cart loading during the play to allow me to use larger animations. Some of there animations are 12 frames long. Like the Swedish chef in the castle. I want to ditch it as soon as Wizzy walks away to make room for animations of the bard and the king. On the Lynx I can throw away stuff. But on the 7800?

This this where you'll hit constraints with Atari's stock cartridge designs. The 7800 works best when most of your consumable data (both code and graphics) are always available in ROM or can be unpacked to a large segment of memory. So it's better suited to data management schemes as you'd use on the NES, SMS, Genesis, etc. rather than an aggressive, dynamically load as much as possible setup which is great for the Lynx.

 

If the graphics are for an asset which doesn't need to move vertically (i.e. doesn't need Holey DMA) then you can use the SuperCart's expansion RAM at $4000 - $7FFF and dynamically load new graphics in there. There's also the option of keeping your graphics in the swappable ROM bank at $8000 - $BFFF but now you're limiting how that can be used for object code.

 

If you're managing a LARGE amount of assets which need to be drawn flexibly and have a lot of object code, then it's time to start looking into Banksets or SOUPER.

Edited March 5, 2022 by TailChao

[RevEng]

5 hours ago, TailChao said:

I don't think this should be considered theory anymore. If a flash cartridge or production board doesn't accommodate Maria's fetch speeds for both textures and Display Lists - it's a compatibility issue. Large flashes in the 55 to 70ns range have been affordable for years outside of the current chip shortage.

Fair - not theory - since it's been done before with R+V. But certainly one can't assume all current homebrew boards are capable of it, so the GCC caution should hold until you've confirmed your target hardware is capable of it.

[+Defender_2600]

On 2/24/2022 at 10:09 PM, Defender_2600 said:

... that lynx graphic could be almost identical on the 7800, you just need to double the vertical resolution in order to get square pixels, therefore from 160 * 102 to 160 * 204.

 

On 3/2/2022 at 5:32 AM, karri said:

So it may be 160 x 121 screen that I aim for.

 

As a side note, I would just suggest to consider the real pixel aspect ratio so that, as far as possible, this beautiful graphics do not look wide on real hardware.

 

 

 

 

 

 

 

 

 

 

 

 

[+karri]

I am also trying to map the colours from Lynx to the 7800. Here is a map I did.

 

The small square samples are the closest colour I found on the 7800 palettes. The values are hue-luminance pairs.

These values are trying to mimick the Dawnbringer 16 colour palette. I hope I git the values right.