Wizzy on the 7800?

[Revontuli]

26 minutes ago, karri said:

Any comments for what it looks on a real 7800 is appreciated.

I gave the build a quick spin with my Concerto on the 7800 (after trying it on BupSystem).  The behavior between the emulator and 7800 seems pretty much the same, no obvious differences in graphics or performance from the minute or so I tried it, dirty tiles and all

 

I'm following this thread in part to see your approach to scrolling - I ended up sticking with the double buffer for my current projects, in part because it was easier to get my head around, but I realize I don't know Display List Lists as well as I probably should.  

 

Great looking game, by the way!

[+karri]

Thanks!

 

The vertical scroll is done by changing the pointers to different rows of the zones array.

 

Horisontal scroll is by manipulating the offsets of the tiles. And.... OMG!

I just realized that the offsets don't need to be in order. I don't need to copy pointers. Well, I will make a faster version tomorrow.

[+karri]

I might like to have a clock() function for adjusting character movements in the game. Is there some timers that support IRQ's? Or am I forced to use NMI only?

 

The reason I don't want to use NMI is speed related. My clock() should deliver 32 bit time to monitor when things get triggered in the storyline. The clock tick could be 60 Hz. I also plan to implement it in cc65 as it is for other targets.

 

And I want to use interruptors for TIA audio.

[RevEng]

I'm afraid Cheech and Chong have let you down here. The only natural source of a non-NMI interrupt on the 7800 is the BRK opcode. The Dragonfly Cart has it's sound chips optionally tied to the IRQ lines, but it's not universal. We usually use NMI for these sorts of thing.

 

There are 21792 6502 cycles in the visible portion of an NTSC frame, before DMA. If your DMA isn't excessive - and I don't see evidence it will be - a decent ballpark estimate is you'll have half of those cycles available to the 6502. A 32-bit clock implementation will be roughly around 30 cycles. (less if the wrap-point for the non-60 Hz bytes is just 256). In terms of proportion, we're talking around 0.2% of your available 6502 frame cycles. If you're worried about lengthy code for stuff that gets triggered by the timers, it would be best to check your clock outside of NMI in your main loop, and act there.

[TailChao]

4 hours ago, karri said:

I might like to have a clock() function for adjusting character movements in the game. Is there some timers that support IRQ's? Or am I forced to use NMI only?

 

The reason I don't want to use NMI is speed related. My clock() should deliver 32 bit time to monitor when things get triggered in the storyline. The clock tick could be 60 Hz. I also plan to implement it in cc65 as it is for other targets.

RevEng already got it - The only interrupt source you have on a stock console is NMI, so you'd have to use that as both your timing source and frame tick. But let's look into the clock() and frame update management for a bit.

 

You can probably approximate the global event system you want with an event queue which is processed early in your frame tick, but outside of the game loop. Something like this (excuse the broken C)...

void nmi(void)
{
    cld
    run_sound_driver();
    
    // update the global tick and then check which events are
    // expiring - obviously best if it's a sorted queue.
    //
    // simple on / off events could just involve setting a flag but
    // if you need something more dynamic and complex then a second
    // queue for the game loop to deal with below is probably best.
    clock_tick();
    events_check();
    
    // re-enable interrupts here in case our game tick
    // takes too long to update, so the sound driver and
    // event system will still run on the next nmi.
    cli
    
    if(!frame_busy)
    {
    	frame_busy = true;
        
        // act upon the events if required...
        events_dispatch();
        
        // ...then do other stuff
        update_objects();
        mine_bitcoins();
        kickstarter_fraud();
        
        frame_busy = false;
    }
    
    rti
}

void idle(void)
{
    // idle processes, outside of the nmi update.
    // you can asynchronously depack assets or similar here.
}

 

Moving your entire game tick into the nmi() update has other benefits like using your idle time ( outside of nmi() ) to do really slow asynchronous stuff like decompression.

Edited March 12, 2022 by TailChao

[+karri]

Thanks for the example code. As I generate two NMI's from the DLL so it should be steady and usable for my timing purposes. Right now I get Displaying screen and End of visible screen interrupts.

[RevEng]

33 minutes ago, TailChao said:

[...]

        // ...then do other stuff
        update_objects();
        mine_bitcoins();
        kickstarter_fraud();

[...]

Your 7800 code is way more enterprising than mine. ?

[+saxmeister]

@karri I am anxiously watching this as your work progresses. I really think this could bring a strong game to the platform.

 

While watching, I couldn't help but notice your profile photo. Has anyone told you that you resemble a young Peter Capaldi circa "The Lair of the White Worm" era? (see image below) Just an observation during all of this coding goodness.

[+karri]

1 hour ago, saxmeister said:

@karri I am anxiously watching this as your work progresses. I really think this could bring a strong game to the platform.

 

While watching, I couldn't help but notice your profile photo. Has anyone told you that you resemble a young Peter Capaldi circa "The Lair of the White Worm" era? (see image below) Just an observation during all of this coding goodness.

Thanks. The only famous guy I have been told to sound like is Mark Levengood. We obviously come from the same small Swedish speaking community. Whenever I go to Sweden people say that I sound just like the Moomin character.

 

Wizzy is going to be a very typical RPG. So the emphasis is on the story. I have it mostly in my head and plan to write it while I am coding it. The first part is already written "The book of Suvi". But the game still lacks 3 events of the story. Perhaps it is ready in late summer.

 

As the story is kind of long I may release the game one part at a time. This would also give me time to tackle the hardware for the final game.

 

On the Lynx platform I am aiming for a special cart with 2M flash. On the 7800 I may go with one large bank switching cart for the first part.

[gambler172]

Hi Karri

on the emulator your latest file works well, but on real hardware with my Dragonfly cart not.....do not know why?

[+karri]

1 minute ago, gambler172 said:

Hi Karri

on the emulator your latest file works well, but on real hardware with my Dragonfly cart not.....do not know why?

Does your Dragonfly support 48k images?

 

It may also be due to the interrupts. I will code the next version without interrupts. 32k is also still possible.

[gambler172]

Hi Karri

 

Do not worry....i tried on my Concerto cart....and it works very well.

So it is a problem of Dragonfly

 

Great work. 

[+Muddyfunster]

1 hour ago, gambler172 said:

Hi Karri

 

Do not worry....i tried on my Concerto cart....and it works very well.

So it is a problem of Dragonfly

 

Great work. 

I tried it on my PAL console with my Dragonfly and it works fine.

 

 

 

[gambler172]

11 minutes ago, Muddyfunster said:

I tried it on my PAL console with my Dragonfly and it works fine.

 

 

 

sure....Karri used PAL....worked on my Pal sytem also.. 

So the demos worked....

[Eagle]

16 minutes ago, Muddyfunster said:

I tried it on my PAL console with my Dragonfly and it works fine.

On my PAL console works fine as well. 

Looks like no NTSC signature for me.

 

@gambler172 check this one with the signature.

wizzyNTSC.a78

Edited March 12, 2022 by Eagle

[+karri]

1 hour ago, Eagle said:

On my PAL console works fine as well. 

Looks like no NTSC signature for me.

 

@gambler172 check this one with the signature.

wizzyNTSC.a78 48.13 kB · 2 downloads

So what is the way to make a NTSC signature? Currently I use

 

sign7800 -w wizzy.a78

 

Besides, I did a cleanup build with a few optimisations. It appears to be what I was wishing for.

 

I try to look for the time for the first two frames and then decide if it is PAL or NTSC.

 

wizzy.a78

[Eagle]

31 minutes ago, karri said:

So what is the way to make a NTSC signature? Currently I use

 

sign7800 -w wizzy.a78

This is correct but somehow you missed signature for last file.

 

 

[+karri]

It took me half the day to fix graphics and choose colours. But now I am happy with the 4 colour background.

 

The binary signature got lost from the Makefile when I created a branch on my repository. But now it should be back!

wizzy.a78

 

The next step is joystick support so that you can go some way without having to click on every step. I assume that 7800 can use diagonal directions in the same way the Lynx does.

[gambler172]

Hi Karri

this looks great.     

[+karri]

There may be a slight delay with the joystick and clock drivers. The cc65 maintainers have still not accepted my new atari7800 target to cc65. And I don't want to push in a new drivers to a target that does not exist.

 

About TIA music... I have a Nord Grand at home and it has a way to create music by recording your own samples and assigning the result to the keys. So in theory I could create an instrument and jam using two fingers (for two sound channels). The other possibility is to learn to use some tracker.

 

I do have a small C-implementation of ABC music. It has a fairly small footprint. I also have tools for

jamming on the keyboard -> midi -> abcmusic -> Lynx

 

Any advice on sounds?

 

The sounds I need:

- footsteps

- enemy alert sound

- pick up stuff

- mount on broom

- exit broom

- shoot

- cast spell

- lots of spell sounds (ice, wind, falling rocks, fire)

 

Some small melodies in tune would be nice too.

 

Perhaps the best would be some fairly generic tool that could be used on multiple sound chips. Handy Music?

 

I just stumbled on Slocum Tracker. This could be the tool for TIA sounds.

[+karri]

Also playing around with memory management.

 

Segment list:
-------------
Name                   Start     End    Size  Align
----------------------------------------------------
EXEHDR                000000  00007F  000080  00001
ZEROPAGE              000040  000059  00001A  00001
DATA                  001800  001835  000036  00001
BSS                   001836  001BFE  0003C9  00001
R000                  004000  00959F  0055A0  00001
L000                  00B000  00DFFF  003000  00001
CODE                  00E000  00F219  00121A  00001
RODATA                00F300  00F310  000011  00001
STARTUP               00FF35  00FF6D  000039  00001
ONCE                  00FF6E  00FF79  00000C  00001
ENCRYPTION            00FF7A  00FFF9  000080  00001
VECTORS               00FFFA  00FFFF  000006  00001

 

 

Currently I have my level-dependent code in R000 (for level 000) and my graphics in L000 (tiles + tilemap).

 

I assume that the holey RAM means that it would make sense to keep the graphics in some order like:
L000:

- tilemap first, so that holey zones will not get data below $8000 (The tilemap is always $1000 long)

- then all the graphics
 

For the code for the level R000 I would like to put it in memory not seen by MARIA so that I won't use up graphics space.
I would prefer to have R000 and L000 on top of each other so that I can swap both at the same time. For the time being I put it at $4000.

 

What about the top stuff like STARTUP, ONCE, ENCRYPTION and VECTORS?
I assume that everything could be swapped away except the VECTORS (NMI interrupt). Is the vector even in memory? Or is it just in a hardware register somewhere?

 

So many questions... So much I don't know.

[RevEng]

I haven't personally used it, but tiatracker was created to address shortcomings with Paul Slocum's tracker. (I personally use the 7800basic built-in mml-based tracker)

 

I put together a small tia sfx library which anyone is welcome to take from, modified or not. There's a browser-based emulation link in that thread, so it's easy to check if there's anything there for you.

 

With supergame bankswitching the last bank (c000-ffff) doesn't get switched, so don't worry about the vectors. If you're using rom at @4000, then it would be non-switched as well. Rom from 8000-bfff is where the switched-in bank lives. The consequence of that layout is you need to keep your code in 16k buckets, so your R000 starting and 4000 and ending at 959f isn't going to work with supergame.

[+karri]

Thanks!

 

This means that all Wizzy animations must fit in the resident memory. The 12k is already consumed by the background. The last 4k is for the spider animations 

 

But if the top permanent 16k can hold the Wizzy animations for Maria plus C-libraries for the CPU then it may work.

[+karri]

Small problems with EMU7800. For some reason the NMI interrupts don't seem to trigger if nothing changes. I can get an interrupt by pressing a key but my assumption to get a steady flow of interrupts to be used as a clock() source seem to work only if I press a key. When the system sits idle nothing moves. Could it be an emulator optimisation issue? Or is my code bad?

[+karri]

On 3/14/2022 at 4:01 PM, RevEng said:

With supergame bankswitching the last bank (c000-ffff) doesn't get switched, so don't worry about the vectors.

So this means that the encryption makes the F000 block unusable for graphics as you cannot set the offset to F. Do you usually use the F000-FF79 area for data structures required be MARIA? Like the DLL, DL, zones?

 

Edit: silly me. The DLL structures are rw so they go into RAM. How can the MARIA chip parse the stuff if it does not see below $8000?

 

NP: I read through the docs one more time. Only the holey's require the raster data to be above 8000.