Mode 15 PAL Blending?

[emkay]

Xuel. Great to see a professional approach to game development.

 

@ Creature XL. Attached is my display/sample play kernel from the intro of a game conversion. With this procedure I reduced the resolution of the ripped sample data down to 7.8Khz to play at the correct rate over 2 scanlines. I'm intending next to play at 15.6khz every scanline. I've attached a non kernel example so you can hear the original sample before the resolution was reduced. This should be how the final procedure will sound.

The correct tune is missing

[Tezz]

The correct tune is missing

JT Music player is in progress

[Heaven/TQA]

Tezz maybe I am little bit confused. are you using a loop (=kernel) to play samples+G2F stuff or are you using IRQs? If so... what happens in VBL time?

[Tezz]

Tezz maybe I am little bit confused. are you using a loop (=kernel) to play samples+G2F stuff or are you using IRQs? If so... what happens in VBL time?

The sample player and display kernel is a two part irq (in zp), the display kernel consists of a command jump list which is manually timed burning dummy cycles.

[emkay]

JT Music player is in progress

 

Well, let's hope the "Digitrack" technique will find it's way into a final POKEY Tracker.... Imagine an "Digi-bass-channel" .... while POKEY plays programmed sounds like those:

 

http://www.youtube.com/watch?v=cOMEyN9KCvs

 

.... playing the "real tune" for that game ...

[Rybags]

I once made a hacked RMT executable with a digital channel, so it's entirely possible.

 

For playback in a graphics kernal like this, it becomes a bit harder. Something like LDA SAMPLE_DATA,X / STA AUDC1 within the kernal would be the way to go. Have the VBlank routine adjust the "SAMPLE_DATA" part of the instruction - the sample data being the actual Audf value rather than a packed sample value.

 

For fixed repeating waveforms this is entirely feasible. For one-shot samples, they could be kept in memory in that inefficient unpacked form - the cost is 5 bits per byte, the top 3 bits could be used for other data which is used elsewhere within the program.

[Creature XL]

For playback in a graphics kernal like this, it becomes a bit harder. Something like LDA SAMPLE_DATA,X / STA AUDC1 within the kernal would be the way to go. Have the VBlank routine adjust the "SAMPLE_DATA" part of the instruction - the sample data being the actual Audf value rather than a packed sample value.

 

My first attempt in using samples in Col16-mode using 16KHz sufferd in updating the "SAMPLE_DATA" part. Because there are more then 256 scan-lines per frame (aka next VBI).

That I wanted to try 8KHz next time I can spent some time with it. Despite someone else might have made more progress already. I somehow have to do it all my self.

[Rybags]

In my experience if you increase the bit-depth of a sample it can compensate for a lower sample rate.

 

Possibly you could have a system where 8 KHz is used but 2 voices are used to give perceived 5-bit depth. Each voice could be done on alternating scanlines.

 

That reminds me - some time back analmux mentioned some new techniques to give more bit depth. Like playing a super-high frequency normal pure tone in 1.79 MHz mode to create a new lowest significant bit of depth - ie play the tone at volume level 1 and a square wave should average out to 0.5 volume.

[Creature XL]

In my experience if you increase the bit-depth of a sample it can compensate for a lower sample rate.

 

Possibly you could have a system where 8 KHz is used but 2 voices are used to give perceived 5-bit depth. Each voice could be done on alternating scanlines.

 

The reason for my interest in sample playback was because of the usage of one timer IRQ for the gfx mode. To make up for the loss of a sound channel I want to use it for digis.

So loosing a 2nd channel for making the digi sound better is not an option

I am confident that it can be used pretty well for low notes. Check the "Morons Intro" of MJO. The (sawtooth) buzzer is a digi as well. Although I am using the "AMIGA style" sample-playback (modifying the timer frequency to alter pitch).

 

I have a simple music replayer of my own in development in parallel, so it shouldn't be hard to integrate the digi playback. However, the replayer is WIP. ATM it can only play one voice (you can hear in the above mentioned intro and in the upcomming "Morons Intro 2" which will be in front of "HAR'em final".

 

Nonetheless, would be cool if we could play 5 bit digis

[Xuel]

You can use pulse width modulation to get almost seven bits of precision but it requires resetting STIMER constantly so it's not possible to play normal sound on the other channels at the same time. There's also a high frequency hiss that might be unappealing.

 

I was introduced to the PWM technique by phaeron's demo here. I made some emulator streaming examples of PCM and PWM for comparison:

 

pcm.zip

pwm.zip

 

Source and full song on github.

[emkay]

Has anyone tried to bring GTIA in ?

The slight delay of the 2nd chip could help forming waves.

Or to build the base of a pcm signal, plus pokey's bit combinations...

[Rybags]

PWM is out of the question if doing a graphics kernal as well.

 

GTIA - personally I'd give it a miss. The single bit is about equivalent to toggling volume 0/8 on a Pokey voice, and you instantly make the product useless on 400/800.

[emkay]

PWM is out of the question if doing a graphics kernal as well.

 

GTIA - personally I'd give it a miss. The single bit is about equivalent to toggling volume 0/8 on a Pokey voice, and you instantly make the product useless on 400/800.

 

People sometimes should make a cut. It's also no problem on other platforms, to use "newer" hardware, to have the benefits... As you know the most powerful music comes from "C64 II " not from the "C64" ...

 

As both chips work different, they might give the resulting pulse with a timed offset. GTIA has a fixed timing, POKEY can have various timings. It could help to remove noise, and/or could be used to make digi FX just like flanger, using the timing offset between the 2 chips.

[Xuel]

Another demo, this time with 512 characters:

 

http://youtu.be/oG_z2V_o1Tw

 

Huge thanks to Sim Piko for generously granting permission to use his SAP in this demo.

 

Thanks to popmilo for on-the-fly character set swapping.

 

Thanks again to Jose Pereira for reduced color swapping.

 

Binaries and source on github.

Edited December 9, 2012 by Xuel

[Synthpopalooza]

Could you work up an NTSC version, using the DLIST 96-112 trick I mentioned earlier?

 

That looks awesome by the way.

Edited December 9, 2012 by Synthpopalooza

[potatohead]

Are you fucking kidding me? Seriously great demo! Kick ass! :thumbsup: :thumbsup: :-o

[popmilo]

Another demo, this time with 512 characters:

...

 

Huge thanks to Sim Piko for generously granting permission to use his SAP in this demo.

 

Thanks to popmilo for on-the-fly character set swapping.

 

Thanks again to Jose Pereira for reduced color swapping.

Thank you man for this awesome demo !

 

Should be enough motivation for something from our side

[emkay]

Another demo, this time with 512 characters:

 

http://youtu.be/oG_z2V_o1Tw

 

Huge thanks to Sim Piko for generously granting permission to use his SAP in this demo.

 

Thanks to popmilo for on-the-fly character set swapping.

 

Thanks again to Jose Pereira for reduced color swapping.

 

Binaries and source on github.

 

 

Things get closer

 

Fullscreen with big moving objects. It's actually one right now , but it looks impressive

 

 

Well, Enemies and collectables were missing

 

Mario is already "Gr. 7" .... but it doesn't take the needed details away, caused by the huge screen and available colours.

Edited December 9, 2012 by emkay

[flashjazzcat]

Bloody hell - just noticed this latest demo. Brilliant!

[jvas]

A new era in 8bit Atari gaming is coming?

[Synthpopalooza]

There's only one problem:

 

World 4-1 to 4-3 has that dude in the clouds tossing down porcupines. The aspect ratio of the original has him on the top of the screen while Mario is at the bottom. How would this work in the revised part-screen ratio in this graphics mode?

[José Pereira]

Synth just porting gameboy color version same need for up scrolling... But as underground levels respect screen high then the problem it's memory as you will need another engine.

Undergound levels go well in antic4 just pmg for Mario.

[Xuel]

@Synthpopalooza, @José Pereira

 

I played with Super Mario Bros Deluxe on the Game Boy Color a little. It is nearly identical to the original but at 160x144 instead of 256x240. Like Jose says, it employs vertical scrolling if you jump too high. Level 1-1, at least, is slightly redesigned so that the decorative clouds are lower. To help see content that would be visible at the original resolution, you can press the up and down buttons to scroll vertically and Select to scroll horizontally. For level 4-1, it clamps the enemy clouds to the top of the screen so that you can always see them. It allows the clouds to go to their original altitude if you jump to a high enough platform. On the Atari you'd have to clamp them even lower since the effective resolution of PAL blending mode is only 160x120.

 

In any case, I'm pretty sure that the poor little Atari doesn't have enough horse power to do all the sprites and game logic of Super Mario Bros at full frame rate even in a normal graphics mode, let alone a CPU-heavy display kernel mode like PAL blending. It would be interesting to see a profile of the NES version in terms of time spent on tiles, sprites, music and game logic. The NES gets a lot of help from the hardware for sprites and tiles which means it can have more complex game logic. My demo uses up nearly all vertical blank time for tiles and music as it is, leaving very little for soft sprites or game logic. It spends all four players and a lot of memory on Mario and he can't even move vertically which is needed to keep the important parts of the map visible on a smaller resolution screen. For example, I don't like how the ground disappears when you jump in my Ruff and SMB demos.

 

That's not to say I won't keep trying to find other uses for PAL blending or even keep banging my head on SMB. More memory can solve lots of problems, so maybe targetting 1088K or above is the way to go?

[popmilo]

Agreed.... It's too early to spend time thinking about stuff like that...

 

Let's first get some notion about how many sprites can we move over this type of screen and how much time is left for game logic...

 

ps. Additional ram is allowed

[Rybags]

A vertical size chop + narrow mode might be the way. And use Timer IRQ with direct vectoring via $FFFE rather than kernal or DLI.

Of course it'd still likely mean no NTSC versions.

 

Possibly the next step could be 25 FPS double-buffered rendering. Sure, most games look crap that way but if there's lots of detail + colour going on, the annoyance factor is reduced, e.g. Wolf3D concept demo.