News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_redbox

Multiple screens of 1 pixel in height

Started by redbox, 20:02, 30 May 11

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

redbox

I saw this on the Pouet forum:


"With a screen height of 1 pixel, you can have multiple "screens" between two VBLs. This needs careful timing, but you can select almost freely the starting address for each line. It's the key of most effects you can do on the CPC. That's why demos often consist of plasmas and wobblers, these are super easy to do. Batman Forever does a much better use of it, and mixes it with software rendering effects to get impressive results. Almost everything in the demo uses this."


Anyone got a source code example of this so I can see how it's done?

arnoldemu

Quote from: redbox on 20:02, 30 May 11
I saw this on the Pouet forum:


"With a screen height of 1 pixel, you can have multiple "screens" between two VBLs. This needs careful timing, but you can select almost freely the starting address for each line. It's the key of most effects you can do on the CPC. That's why demos often consist of plasmas and wobblers, these are super easy to do. Batman Forever does a much better use of it, and mixes it with software rendering effects to get impressive results. Almost everything in the demo uses this."


Anyone got a source code example of this so I can see how it's done?
that's the r4=0, r9=0 effect.
I'll see if I can find some code for it.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

redbox

Quote from: arnoldemu on 09:16, 31 May 11
that's the r4=0, r9=0 effect.
I'll see if I can find some code for it.

That would be great  :)

sigh

Does this method work similar to how rasters work, splitting the screen into different modes to gain more colours and different resolutions?
How memory intensive is this? Effectively, each line could have it's own colour and mode?

Executioner

Quote from: sigh on 11:59, 18 June 11
Does this method work similar to how rasters work, splitting the screen into different modes to gain more colours and different resolutions?

You can split modes and change the palette, but you can do that on every scan line without using this at all.

QuoteHow memory intensive is this? Effectively, each line could have it's own colour and mode?

The main limitation with using this method is that the vertical line count (which normally goes from 0 to 7) and allow the display of data at addresses with non-zero bits 13, 12 and 10 (eg. c8xx..ffff) will not occur, so you're restricted to using 1/8th of the total available memory for screen display. This means you only have 8K of unique address space to play with and some of that you'll probably need for interrupts unless you use IM 2. 8K could be fine though if you're displaying the same scan line multiple times, and if you display it 4 times, your whole screen could be only 4K.

ralferoo

Quote from: arnoldemu on 09:16, 31 May 11
that's the r4=0, r9=0 effect.
I'll see if I can find some code for it.
That'd be really useful for me too. I'm struggling to get consistent behaviour between crtc types 0 and 2 and the emulator. Ironically, most stuff I've read says that crtc type 2 is the "worst" and yet it seems to do exactly what I'm expecting and usually the same as WinCPC/Winape. CRTC type 0 seems to be the least compliant and I've not managed to get a 1-line repeated screen going with it, only 2-line.

What I'm actually trying to do is:
* process data (currently a empty loop) with interrupts disabled
* wait for vsync
* clear the interrupt ack flag (out #7f8d)
* enable interrupts and halt (triggers immediately due to disabled interrupts until now
* line vsync + 2 clears the raster counter, doesn't interrupt as r52 < 32
* halt, so i'm on line 54
* disable interrupts again
* change screen height to 1
* waste some time (will be rendering here)
* at end point in frame, change screen height to number of lines left, so i get a border and vsync pulse
* repeat

But, on CRTC 0 this goes very wrong. It's closest to working with R4=1, R6=2, R9=0 but obviously that repeats 2 lines of data over and over...

A current snapshot of my code is at http://www.ranulf.net/vsyncint.asm (assuming we're allowed external links)

Executioner

As far as I'm aware, the only thing you really need to look out for is that CRTC type 1 will change base address at any time during the first character of a screen (VCC=0, VLC=anything). You need to pre-set the base address for each row between the horizontal displayed (R1) and the horizontal character count (R0). R6 shouldn't matter so long as it's not zero.

arnoldemu

Quote from: ralferoo on 23:05, 20 July 11
That'd be really useful for me too. I'm struggling to get consistent behaviour between crtc types 0 and 2 and the emulator. Ironically, most
welcome to cpcwiki.

I would not trust an emulator too much with timings problems like these.
Winape is good, but none are 100% accurate.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

krusty_benediction

Winape is NOT good at all when working on such things.

Experiments can work very well in Winape whereas on a real CPC, overflow occur in CRTC registers and 1/3 of the screen displays border.
So, when doing full screen line to line splitting, it is mandatory to test on real hardware.

Winape will be of a great help to count the nops of the routines (to assert they take 64 nops) and verify if the screen is a 50HZ (i.e., one frame=39*8*64 nops).


Executioner

Quote from: krusty on 10:37, 21 July 11
Winape is NOT good at all when working on such things.

I've never claimed it was 100% accurate, but it works on well over 99% of demos, so it must be quite accurate.

QuoteExperiments can work very well in Winape whereas on a real CPC, overflow occur in CRTC registers and 1/3 of the screen displays border.

Which registers are you talking about and when do they overflow? Post a reply explaining the actual problem(s) and I'll attempt to fix them.

I'm sure many people have done many screen splits before using WinAPE and had them work on the real hardware. I know I have.

Cheers,

krusty_benediction

Quote
I've never claimed it was 100% accurate, but it works on well over 99% of demos, so it must be quite accurate
Don't worry, it was not an attack.
It is enough for games or watching already coded demos, but not for demos coding when very precise timing is required.


QuoteWhich registers are you talking about and when do they overflow? Post a reply explaining the actual problem(s) and I'll attempt to fix them.

Great.
Sadly, as I have corrected my code, I have nor more reference to it.
I know there was a similar pb with first version of barcatraz (http://pouet.net/prod.php?which=57046) maybe GRIM as always the faulty code.

In my case, it was also when doing such kind of split screens with stable routines: I never waited the VBL signal.
After setting R4 and R9 to 1, I waited too much (I think) before setting them to 0.
On emu, the screen worked perfectly.
On CPC/CRTC 0, there was border for 1/3 or 2/3 of top screen.

Please note I am not a CRTC master, so I cannot be more precise.
Maybe I misused the term overflow.


I though you will never modify again winape.
If you do it, could you look at http://code.google.com/p/cpcsdk/source/browse/trunk#trunk%2Flibstsound to use the same tables for sound emulation ?
Sound accuracy is far better than actual winape emulation.
Once again, if you want to improve CRTC/PSG/FDC emulation, I think Grim would be happy to share its really impressive knowledge.



Executioner

Quote from: krusty on 16:05, 26 July 11
I know there was a similar pb with first version of barcatraz (http://pouet.net/prod.php?which=57046) maybe GRIM as always the faulty code.

Do you mean Grim may still have the faulty code?

QuoteIn my case, it was also when doing such kind of split screens with stable routines: I never waited the VBL signal.
After setting R4 and R9 to 1, I waited too much (I think) before setting them to 0.
On emu, the screen worked perfectly.
On CPC/CRTC 0, there was border for 1/3 or 2/3 of top screen.

It may be in the timing of the original setting, or maybe the maximum values are wrong for some registers (eg. no of counted bits in VCC). It'd be handy to have the problem code.

QuoteI though you will never modify again winape.
If you do it, could you look at http://code.google.com/p/cpcsdk/source/browse/trunk#trunk%2Flibstsound to use the same tables for sound emulation ?
Sound accuracy is far better than actual winape emulation.
Once again, if you want to improve CRTC/PSG/FDC emulation, I think Grim would be happy to share its really impressive knowledge.

I've actually finally released 2.0A18 in the last day and it has got some significant changes to the sound emulation. So in the last couple of versions there's been changes to PSG and FDC. Hopefully it won't be half as long before the next release.

McKlain

Quote from: Executioner on 04:13, 27 July 11I've actually finally released 2.0A18 in the last day and it has got some significant changes to the sound emulation. So in the last couple of versions there's been changes to PSG and FDC. Hopefully it won't be half as long before the next release.

Now it sounds different, but it is still not right. The noise sounds too high (still an octave high?) and the center channel volume is too high too. If you have the time, check the song attatched and the recording made from the stereo output of my 464:

http://soundcloud.com/mcklain/take-off

TFM

Does the Stereo change the Sound in addition? Or did you switch off any kind of equalizers etc.?
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

McKlain

The sounds is sampled on the computer straight from the 464 output, no filtering, equalization or dynamics proccessing applied. Just plain normalization to maximize the sound input.

TFM

Quote from: mcklain on 17:26, 27 July 11
The sounds is sampled on the computer straight from the 464 output, no filtering, equalization or dynamics proccessing applied. Just plain normalization to maximize the sound input.

Hmmm... it would be great if we would have a kind of "system" to exactly determine how the sound is supposed to sound. One could use a oscilloscope, but I doubt this would be enough. As data sheets of the PSG are not enough.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

McKlain

Yes, we could go as deep as that, but you don't need rocket science to notice that the sound emulation is not right yet. It's quite noticeable.

Executioner

Quote from: mcklain on 13:39, 27 July 11
Now it sounds different, but it is still not right. The noise sounds too high (still an octave high?) and the center channel volume is too high too.

I double-checked the noise frequency against numerous sources. Unfortunately, I don't currently have access to my real CPC. You should record the output from a simple SOUND command with various noise values. eg. SOUND 1,1,100,15,,,1 through to SOUND 1,1,100,15,,,31 to compare to a real CPC. If it is out by an octave, then all the other emulators including MAME must also be.

The centre channel has the same weight as both left and right, it's a simple addition to convert three channels to stereo (A + B, B + C) or the addition of all three for mono (A + B + C). Are you saying that channel B is actually quieter on a real CPC than both the other channels?

QuoteIf you have the time, check the song attatched and the recording made from the stereo output of my 464:

I will listen to them both. I'll let you know what I think.

McKlain

Mmmm... one thing that I was just testing in Arkos. If you change the master clock of the song to 2MHz (like if you were composing for an atari st) the noise frequency doubles (well, everything doubles in fact).

Executioner

I'm just in the process of recording a WAV file directly from WinAPE (this uses the WinAPE sound), and a WAV file from ST-Sound (I'll have to download the latest version also since I currently have v5.5 with LP off) so I can actually compare the two waveforms. You are right that WinAPE does seem louder on the drum channel (B I think).

Executioner

ST-Sound 5.51 is completely different to 5.5 (5.5 had completely the wrong frequency output on the notes). In the test recordings I've just made, WinAPE is closer to your real CPC output when recording a mono WAV file than ST-Sound 5.51. I need to convert your m4a to WAV so I can compare at a lower level.

Grim

QuoteThe centre channel has the same weight as both left and right, it's a simple addition to convert three channels to stereo (A + B, B + C), [...]
It isn't. There are coefficients to take into account. Here are the theoretic ones (calculated from the CPC schematic) and those of my own CPC (calculated from a blurry scopeshot :).

Executioner

Quote from: Grim on 01:33, 28 July 11
those of my own CPC (calculated from a blurry scopeshot :) .

From these, A=67% and B=32%, in other words left=A*.67 + B*.32 or normalising by dividing through by .67, left=A + B * 0.477, which is close enough to left=A + B/2. So if I just half B and add to both channels, it should be about right (in stereo). For mono, each channel has the same weight.

Grim

Quote from: Executioner on 02:13, 28 July 11
So if I just half B and add to both channels, it should be about right (in stereo).
Yep, A+B/2 should be OK for playing chiptune I believe. But for more advanced sound tricks (**cough** yet to be released **cough**), such as using two AY channels to get a ~8bit linear DAC for samples, I have no idea if it will be enough or not (at least, it won't be as dramatic as it is now on pretty much all CPC emus I tested).

McKlain

Quote from: Executioner on 01:19, 28 July 11
ST-Sound 5.51 is completely different to 5.5 (5.5 had completely the wrong frequency output on the notes). In the test recordings I've just made, WinAPE is closer to your real CPC output when recording a mono WAV file than ST-Sound 5.51. I need to convert your m4a to WAV so I can compare at a lower level.

Mind you, I have played ym exports from my songs on st-sound 5.51 before and they all played at lower frequencies than they should be. Exports made directly on arkos tracker.

Powered by SMFPacks Menu Editor Mod