Wizzy on the 7800?

[+karri]

Hi guys,

 

I have been chatting with @gambler172 about retro stuff for a long time. Actually after we met in real life at eJagfest.

 

Currently I am working on a small adventure game called Wizzy for the Atari Lynx. As the 7800 appears to also have a 160 pixel wide screen mode I was wondering if it would be possible to create the game on that platform as well.

 

I know that there is much less colours available. But as the graphics would have the same resolution it would not be a job to re-draw everything just re-colour the graphics.

 

My code is mainly in cc65 and I found out that there was a cc65 port a few years ago for robots and kittens. Today I tried to create a new target for cc65 and it appers to compile it. The reason why I want to use cc65 is that I am familiar with overloading segments in the cc65. And if I undestands correctly there is 16k banks in 7800 that would work in the same way.

 

But I am a complete novice as 7800 is concerned. The game is more like a text game with a long storyline. There is just one character on screen plus a few enemies or npc's. Currently I am loading stuff from the cart whenever the animation changes or the girl moves around. So there is a lot of read-only data. Actually the whole point of the game is to navigate between independent instances of tilemaps.

 

The system uses only a joystick and two buttons. A third control for "next skill" could be useful in later episodes.

 

Before I dive too deep in this I wonder if this is realistic at all? Any pointers to the right direction are greatly appreciated.

 

Here is a small video of the first seconds of the game in progress.

[gambler172]

For next skill, maybe use SELECT ?

[+karri]

14 minutes ago, gambler172 said:

For next skill, maybe use SELECT ?

Nope. All the skills are already implemented and the animations are done. You only have the 1st skill which is the witch + broom. And throwing acorns of course.

 

The Opt1 button is used to flip through the skills. I hope it does not work on your build as Wizzy does not deserve any extra power yet.

 

Edit: Silly me! I misunderstood. Yes SELECT is probably a button I could use.

[+saxmeister]

There are several demos on this site showing the type of scrolling/tile based backgrounds like this. Even with a more limited color palette, in 160 modes you have several palettes to choose from, even if they only have 3 colors and 1 transparent.

 

The artwork may still need a bit of tweaking with the aspect ratio of the pixels on the 7800 vs the Lynx.

 

This would be a GREAT addition to the 7800 library.

[+Defender_2600]

Great job, and it would be very nice to have it on the 7800. Probably, that horizontal + vertical scrolling can be quite a challenge, I've seen something similar in 7800 Dark Chambers. Instead, 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. The 7800 palette has fewer colors than Lynx but you can still have up to 25 colors per scan line (only 16 on Lynx) and then have sprites / tiles with 3 colors or 12 colors + transparent. So, to save cycles, I'm imagining 160A + 160B mixed graphics, based on the circumstances. I don't see many objects on screen, so I would like to be optimistic about the feasibility.

[+Pat Brady]

44 minutes ago, karri said:

But I am a complete novice as 7800 is concerned. The game is more like a text game with a long storyline. There is just one character on screen plus a few enemies or npc's. Currently I am loading stuff from the cart whenever the animation changes or the girl moves around. So there is a lot of read-only data. Actually the whole point of the game is to navigate between independent instances of tilemaps.

 

The system uses only a joystick and two buttons. A third control for "next skill" could be useful in later episodes.

 

Before I dive too deep in this I wonder if this is realistic at all? Any pointers to the right direction are greatly appreciated.

 

 

Looks doable to me. Fewer colors than the Lynx, yes, but I think you can still make it look good.

 

The way I see it, you have 2 choices:

1. Learn the nuts and bolts of how the 7800 draws graphics (read the Software Guide repeatedly until it makes sense, which for me was about 5 times, maybe more) and write your own code to generate display lists.
2. Use 7800basic, have it handle the graphics, and include your game logic compiled by cc65 in assembly form. This does not necessarily mean much actual BASIC code, just some calls to the graphics routines and your code. The big disadvantage I see is that 7800basic consumes more than half of the 7800's built-in RAM. But if 1.5K is enough for you, this option will probably get you up and running faster than option #1.

 

Either way, don't hesitate to ask questions.

 

Graphically, the standard (I think) way to do this sort of thing is to use indirect 160A mode for the background and direct 160A or 160B mode for the player, enemies, and NPCs. In your case, each background region (ocean, road, grassland) will need a separate character map (so that each can have its own 3-color palette). The trees could also have separate character maps, or be done as direct mode objects on top of grassland.

 

The 7800 doesn't have any hardware support for scrolling, so you'll have to do that in software.

[+karri]

Does the 7800 has capability to flip graphics. I mean take a sprite going right and flip it to go left?

[+Defender_2600]

7 minutes ago, karri said:

Does the 7800 has capability to flip graphics. I mean take a sprite going right and flip it to go left?

Unfortunately no.

[+karri]

17 minutes ago, Defender_2600 said:

Unfortunately no.

Ouch! In the scenery I do extensively use flipped 16 bit tiles. One designed tile is used in 4 ways.

 

Well, I do the graphics design in Tiled and planned to have tiles that the hardware supports. So I may need to reduce variations based on how much memory I have. It is only eye candy. It does not affect the game.

 

Luckily I have very few different tiles per level.  The same patterns are repeated a lot. But if you look at the ground structure every tile with pebbles is flipped to make the illusion of a lot of variety.

 

What I don't know is if there is a way to have enough bytes in the rom for everything I have planned. I wanted to have up to 8 frame animations. Currently there is animations front/back/left/right. There is also lots of actions like idle/run/attack/die and the same when flying on the broom.

 

Which leads me to another question.

 

I found some schematics with an 8-bit latch for extending the address bus. This is apparently the so called "bank switching". It sounds more like rom switching to me. As there is only 4k of RAM I would like to use the data from the rom directly. Is there some doc explaining how to use a 512k rom space on a 7800?

[+Defender_2600]

43 minutes ago, karri said:

Ouch! In the scenery I do extensively use flipped 16 bit tiles. One designed tile is used in 4 ways.

 

Well, I do the graphics design in Tiled and planned to have tiles that the hardware supports. So I may need to reduce variations based on how much memory I have. It is only eye candy. It does not affect the game.

 

Luckily I have very few different tiles per level.  The same patterns are repeated a lot. But if you look at the ground structure every tile with pebbles is flipped to make the illusion of a lot of variety.

 

What I don't know is if there is a way to have enough bytes in the rom for everything I have planned. I wanted to have up to 8 frame animations. Currently there is animations front/back/left/right. There is also lots of actions like idle/run/attack/die and the same when flying on the broom.

 

Which leads me to another question.

 

I found some schematics with an 8-bit latch for extending the address bus. This is apparently the so called "bank switching". It sounds more like rom switching to me. As there is only 4k of RAM I would like to use the data from the rom directly. Is there some doc explaining how to use a 512k rom space on a 7800?

 

"The Bankset bankswitching scheme is a 7800 homebrew-era invention. ...

 

Compared to SuperGame scheme, the Banksets scheme allows for more overall ROM storage, enables 100% of the cart address space to be dedicated to the display of graphics, and does away with the need to interlace code and graphics within ROM...."

 

 

Edited February 25, 2022 by Defender_2600

[+karri]

I assume that the 7800 emulators already support some bankswitching. Is it so?

 

Nice. In wizzy I can also take the approach to make every section of the game as a standalone chapter so there is no need to get into the extra complexity of bank switching right away. The downside is that you cannot choose in which order to tackle the missions if the missions are on separate carts. Wizzy would be geared up in the order I decide in this case.

 

At least the first mission could be coded for 7800 as an standalone experiment. Who knows what happens next...

[RevEng]

9 hours ago, Pat Brady said:

Use 7800basic, have it handle the graphics, and include your game logic compiled by cc65 in assembly form. This does not necessarily mean much actual BASIC code, just some calls to the graphics routines and your code. The big disadvantage I see is that 7800basic consumes more than half of the 7800's built-in RAM. But if 1.5K is enough for you, this option will probably get you up and running faster than option #1.

To be fair, a page and a half of ram is actually used by 7800basic. The rest of that memory is used for the DLs and DLL, and you might just need DLs and DLL for an assembly game too.

[+karri]

1 hour ago, RevEng said:

To be fair, a page and a half of ram is actually used by 7800basic. The rest of that memory is used for the DLs and DLL, and you might just need DLs and DLL for an assembly game too.

I was hoping to code my stuff in C and go with #1.

 

I just finished creating an atari7800 target to the cc65 compiler as there are some libraries I want to use in cc65 just to speed up my own work. But I start with compiling "robots and kittens" on it as it was the only example I found in C.

 

Currently "robots and kittens" compiles after some edits.
$ ld65 -t atari7800 -o wizzy.a78 keys.o machinetype.o vblank.o text.o font.o rfk7800.o atari7800.lib
ld65: Error: 1 unresolved external(s) found - cannot create output file
 

The unresolved external may be related to that I have not set up the encryption segment yet. Later...

[+Pat Brady]

2 hours ago, RevEng said:

To be fair, a page and a half of ram is actually used by 7800basic. The rest of that memory is used for the DLs and DLL, and you might just need DLs and DLL for an assembly game too.

 

Yes of course, though I didn't know the exact breakdown for 7800basic and neither of us knows how big @karri's hand-written DLs will be.

 

I thought I was generally positive towards 7800basic. It's certainly been used to produce a bunch of good games quickly lately.

[+karri]

3 minutes ago, Pat Brady said:

 

Yes of course, though I didn't know the exact breakdown for 7800basic and neither of us knows how big @karri's hand-written DLs will be.

 

I thought I was generally positive towards 7800basic. It's certainly been used to produce a bunch of good games quickly lately.

I appreciate the mention of the 7800basic. I was just browsing it to see what kind of sprite formats are supported. You seem to go with png. In sp65 I have been using pxc images for the input bitmaps. But the sp65 has tools to pick out slices of the animation and write them in some usable format. The Lynx literal format is close enough with 2-bit colours so I may pick that format. I should be able to use the same sprite sheets and just pick out the colour mapping with the pen=0273 directive. It would create a 4 colour sprite from colour indices 2,7,3 and transparent automatically. Good enough for a first demo.

 

I can then build the C-objects of the sprites from the Makefile.

buildsprites: king.pcx
        $(MAKE) addsprite SLICE=23,30,15,18 ID=kingidle0 AX=11 AY=17
        $(MAKE) addsprite SLICE=87,31,15,17 ID=kingidle1 AX=11 AY=16
        $(MAKE) addsprite SLICE=151,32,15,16 ID=kingidle2 AX=11 AY=15
        $(MAKE) addsprite SLICE=215,31,15,17 ID=kingidle3 AX=11 AY=16
        $(MAKE) addsprite SLICE=279,30,15,18 ID=kingidle4 AX=11 AY=17

addsprite:
        $(SP) -r king.pcx --slice $(SLICE) -c lynx-sprite,mode=literal,ax=$(AX),ay=$(AY) \
                -w $(ID).c,ident=$(ID),bytesperline=8

/*
 * This file was generated by sp65 2.13.9 from
 * Slice of king.pcx (15x18, 17 colors, indexed)
 */

#define kingidle0_BPP          4
#define kingidle0_WIDTH        15
#define kingidle0_HEIGHT       18
static unsigned char kingidle0[] = {
    0x04,0x98,0x01,0x58,0x01,0x04,0x9D,0xD9,
    0x58,0x04,0x9D,0xD9,0x58,0x04,0x9D,0xD9,
    0x58,0x04,0x9B,0x31,0x58,0x04,0x9D,0x91,
    0x58,0x04,0x9A,0x25,0x80,0x04,0x12,0x42,
    0xC0,0x04,0x9B,0xBA,0x58,0x04,0x12,0x42,
    0xC0,0x04,0x9B,0xBD,0x80,0x04,0x9B,0xDD,
    0x80,0x04,0x9B,0xBD,0x80,0x04,0x9C,0x45,
    0x80,0x04,0x9E,0xC5,0x80,0x04,0x9C,0x45,
    0x80,0x04,0x9C,0x58,0x00,0x04,0x85,0x88,
    0x00,0x01,0x07,0x8D,0xD8,0xC8,0x43,0x1B,
    0x00,0x07,0x8D,0xD8,0x88,0x63,0x1B,0x00,
    0x07,0x85,0x8C,0x84,0x32,0xB0,0x00,0x07,
    0x83,0x08,0x86,0x32,0xB0,0x00,0x06,0x11,
    0x0C,0x61,0x62,0x00,0x07,0x92,0x2A,0x88,
    0xE1,0x63,0x00,0x08,0x9A,0x22,0xA8,0x8E,
    0x16,0x20,0x00,0x08,0xD3,0xA2,0x2A,0xB2,
    0xAD,0x80,0x00,0x08,0x12,0x49,0x59,0x84,
    0xB1,0xB0,0x00,0x08,0x13,0xC5,0x58,0x4B,
    0x2B,0x00,0x00,0x08,0xA3,0xDB,0xAB,0x09,
    0x65,0x60,0x00,0x06,0x13,0x8D,0x61,0x62,
    0x00,0x06,0x1C,0x09,0xA1,0x62,0x00,0x07,
    0xBC,0x44,0xC4,0x0B,0x58,0x80,0x07,0x84,
    0x0D,0x22,0xB6,0x30,0x00,0x04,0x2D,0x90,
    0x00,0x03,0x50,0x00,0x01,0x07,0x95,0x85,
    0x8C,0x84,0x30,0xB0,0x00,
};

Putting this stuff in correct format to the correct place for the DL and DLL's is still a bit of a mystery... But I have time  There is no dead-line!

[+karri]

Yes! I got the first program compiled and encrypted. But the emulator refuses to run it. It complains about a missing a78 header. Is the specs for that available somewhere?

 

Sorry. I found the topic just a few topics later in the forum. So I downloaded the latest asm version.

 

I assume that 32k carts are the "normal" ones. Would it be a good default a78 header in the cc65 compiler? You can always overrun the header file later.

 

I wonder if someone could have a look at my map file.

 

Now I get strange bars on the screen.

 

Here is also the text.s file that creates the display lists. It is in C but I added the asm version with C-commands in comments.

 

 

 

text.s

rfk.a78 rfk.map

[RevEng]

Yes, 32k is "normal", though 48k and the larger supergame bankswitch formats aren't unusual.

 

I'm pretty sure your a78 header is fine - I stripped it and reapplied it with 7800header, which is well-tested, and the result is identical - so the problem is elsewhere. I'm not really familiar with building a7800 roms with cc65, so I'm not sure where the issue actually is.

 

4 hours ago, Pat Brady said:

I thought I was generally positive towards 7800basic. It's certainly been used to produce a bunch of good games quickly lately.

I didn't take offense, but I didn't want people thinking the memory usage was out of hand either.

 

The 7800basic coders can also tune the DL memory usage with build options, so there's even opportunity for them to take some of that memory back if not-needed.

[RevEng]

It looks like the 6502 vectors are all pointing to 0xFFFF.

[+karri]

2 minutes ago, RevEng said:

It looks like the 6502 vectors are all pointing to 0xFFFF.

Nice! Thank you!

 

The cc65 is actually using the interruptor technique. I totally forgot about it. Will fix it tomorrow.

[+karri]

Now I am starting to get garbage on screen.

 

 

Not really what I was hoping for. But the garbage reacts to the joystick which is cool.

 

Oh, I am not able to sign the cart after the reset vector was fixed.  It claims that the reset vector points outside the hash area. Where should it point? Currently it points to $8000

[RevEng]

The hash area is determined by the high nibble at FFF9. Right now it's set to "Fx" (F7) so the hash area is from F000-FFFF. You can either use a start vector somewhere in this space, and jump to your real start, or you can extend the hash area to 8000-FFFF by setting it to 8x. The former approach is likely preferred, because the game cart will boot faster.

[TailChao]

Uh-oh, another Lynx developer migrating to the 7800 

Since you're rolling your own toolchain for cc65, a few things...

 

12 hours ago, karri said:

Ouch! In the scenery I do extensively use flipped 16 bit tiles. One designed tile is used in 4 ways.

The lack of flipping is a huge limitation, especially compared to what Suzy can do - but Maria has some neat tricks. My favorite is the ability to do primitive clipping on tall graphics by masking the draws across Display List zones. It's a lot like the Jaguar's Object Processor actually...

 

Easiest way to think of the render setup is that Maria's view of the address space is just a giant texture and the fetch cursors are her read address as $YYXX. Many of the optimization techniques for framebuffer systems apply here - in that you want to batch your draw commands when possible. So you'll gain a lot of performance by reducing not just the fillrate, but also the draw command parse overhead.

 

 

12 hours ago, karri said:

I found some schematics with an 8-bit latch for extending the address bus. This is apparently the so called "bank switching". It sounds more like rom switching to me. As there is only 4k of RAM I would like to use the data from the rom directly. Is there some doc explaining how to use a 512k rom space on a 7800?

While the traditional Atari SuperCart and newer Banksets scheme have already been suggested above - I'm going to recommend trying SOUPER based upon your Lynx heritage. This allows paging of character graphics anywhere in ROM or RAM, and expands the latter with an extra 32KB in the cartridge. Also, the BupChip audio will seem awful familiar from using HandyMusic and its SASS scripts.

[+karri]

Thanks!

 

I started my journey yesterday so all this is a bit much to digest. Is there a SOUPER cart available with BupChip audio?

 

The HandyMusic is still in active use in Wizzy.

--
Cheers,

Karri

[TailChao]

9 minutes ago, karri said:

Thanks!

 

I started my journey yesterday so all this is a bit much to digest. Is there a SOUPER cart available with BupChip audio?

The most difficult part of the migration for me was learning to stop using 65C02 instructions like PHX, PHY, etc - it was the first time I worked with a normal NMOS 6502, haha.

 

There's some leftover development boards if you need to use SOUPER + BupChip on the real thing right now, we can sort something out if you decide to go down that road but I suggest trying it in BupSystem first to make sure it does what you want. Support for the mapper is also in the MiSTer's 7800 core and an alternate version of the BupChip audio (which uses a prerendered PCM stream instead of doing it all live on a microcontroller) will be included in @SainT's upcoming 7800GD and (hopefully) backported to the MiSTer.

 

Some of the tooling is a little wonky but not nearly to the degree HandyMusic was.

[+karri]

My first goal is to get some feel for the console. I don't feel like starting with very rare add-ons right away. The 7800GD with better audio could be a realistic cart.