Getting back into coding. But does this work on a REAL Amiga?

[mydma]

Hi

I had the urge to try my hand at a bit of 68k on the Amiga. Its been a very long time but its surprising what you still remember!

I dont have a real Amiga anymore so im using vasm/winuae.

Thing is I noticed that if the emulator is running in windowed mode I can see the copper "wait" positions to the left of the screen. If I resize the window they are off screen. They are not visible if winuae is in full screen mode either.

Heres a screen capture incase my explanation is a bit poor
https://imgur.com/Wge8ZKO


So what causes this? Is it an issue with the emulator or is it an issue with my code?

Basically does my little demo effect work on a real amiga? If it does then it may motivate me to continue with it

Here's a link to the amiga executable (rustycopper1)
http://s000.tinyupload.com/index.php...89809371019253
Made for A500 1.3 OCS PAL

If it freezes with a red or yellow screen then it couldnt allocate enough chip mem. Thats as far as i go with error handling - at least until i figure out how you write text to the cli on kickstart 1.3

Just in case I failed completely and it doesnt work at all. Then I uploaded a (very poor) rip to youtube here...
[ Show youtube player ]
Dont know what went on with the capture as its a lot smoother than that

Happy to upload the source too if anyone feels like a good laugh.

[ross]

Nice COLOR00 effect

Yes, you've a zone with solid color because of a Copper wait too much to the right (for how the routine is set is inevitable).
You can cover the glitches with sprites.

[mydma]

Originally Posted by ross

Nice COLOR00 effect

Yes, you've a zone with solid color because of a Copper wait too much to the right (for how the routine is set is inevitable).
You can cover the glitches with sprites.

Thanks, wanted to play with the copper again for a while now. Great fun

So it is visible on a real amiga? Any idea why its off screen if the window is resized in winuae?

Id use a sprite to mask it but im not sure how much i need to mask - bearing in mind i want to still be as overscan as possible.

[ross]

Originally Posted by mydma

So it is visible on a real amiga? Any idea why its off screen if the window is resized in winuae?

It depends on monitor, could be that on some is not visible.

Is off screen because of the resize
Go to Option/Host/Filters and select 'No scaling' (third row button to the right).
Now enlarge the windows for a full overscan.

Ah, welcome

[DanScott]

In windowed mode in WinUAE, you will see stuff off the left that would never normally be seen on a TV / Monitor (properly setup) on a real Amiga

[DanScott]

Wow your DDFSTART is quite low ($24)... should be $38 for regular centred 320 wide... and $30 for 352 overscan

$24 will probably eat all your sprites

[ross]

Originally Posted by DanScott

$24 will probably eat all your sprites

4 sprites available.
Well, actually 3+1(one plane) on OCS but to use as a cover you can.

[Toni Wilen]

WinUAE shows complete visible area (everything except horizontal and vertical blanking). Filter panel can be used to make it narrower.

It is not that rare to be able to see identical output using real hardware, for example scandoubler + non-4:3 LCD TV can show full horizontal overscan. (I can duplicate it with OSSC + 16:9 LCD TV). Back in the day it was invisible except if you had 1081/1084/8833 or similar monitor with adjustable size/position.

[Photon]

Originally Posted by DanScott

In windowed mode in WinUAE, you will see stuff off the left that would never normally be seen on a TV / Monitor (properly setup) on a real Amiga

This.

(And it shows extra stuff on the right, too. It shows everything your code does, which can be good sometimes. )

You should expect $30..$d8 to be visible on any display.

If you start setting colors at a horizontal wait, you won't need to cover it up. But you can make sprites a thing and design nice borders ofc

It's up to you and the effect how much you want to cater to 16:9 screens - it could triple the copper list size.

The Amiga was made for 5:4, and I think other computers and consoles will show glitches at the edges on 16:9. It's just that some like their displays thin, and then it's hard to find a good display or even any display that isn't 16:9 now.

[clenched]

A500 ECS: Without touching 1080 monitor controls I see just a smidgen over 2 "steps" inside bezel.

[mydma]

Originally Posted by ross

You can cover the glitches with sprites.

Bitplane dma is disabled for the whole frame except where the scroll text is. So blanking with a sprite isnt going to work. I originally had big plans to try and make it a sine scroller but with bitplane dma on it doesnt run at 50fps (even with just the standard scroll). Not enough dma time for the the blitter i suppose.

Originally Posted by DanScott

Wow your DDFSTART is quite low ($24)... should be $38 for regular centred 320 wide... and $30 for 352 overscan

Yes Ive shifted it left as i was unsure where the edge of the screen actually was and I obviously wanted the scroll to be full screen. I looked at Magnetic Fields - Copper Mosaic 2 and Pacmania as a reference as they were two things I remember that were a nice full screen.

Originally Posted by Photon

You should expect $30..$d8 to be visible on any display.

So $30..$d8 is what would have been classed as a full overscan demo back in the day?

Originally Posted by Toni Wilen

WinUAE shows complete visible area (everything except horizontal and vertical blanking). Filter panel can be used to make it narrower.

Now Ive come to look at the filter page thanks to this thread. Is "Full Screen (TV)" a fair representation of what would have been visible on a 5:4 display back in the day?

Originally Posted by clenched

A500 ECS: Without touching 1080 monitor controls I see just a smidgen over 2 "steps" inside bezel.

Thats good to know. I could just reduce the amplitude of the sine slightly I guess. I noticed that with copper mozaic 2 the waits are visible with the Full Screen (Max) setting, so maybe I worry too much.

Really really great to know it runs on a real amiga though!!! Gives me a warm fuzzy feeling inside and a desire to do something else

Thank you everyone for your replies. Hopefully I will get a bit of time over the weekend and fiddle around with this a little more. Id like to try my hand at some filled vectors though so may give that a go instead

[ross]

Originally Posted by mydma

Bitplane dma is disabled for the whole frame except where the scroll text is. So blanking with a sprite isnt going to work. I originally had big plans to try and make it a sine scroller but with bitplane dma on it doesnt run at 50fps (even with just the standard scroll).

DMA is not the only solution.

Launch this stupid code (some furious copy-paste from different snippets, so code contain random oddities..)
Not a single SPRITE DMA or BITPLANE DMA fetch, pure CMOVEs to DAT registers.
An unique sprite (SPR0 x-multiplexed) for the 'please insert' and 2 planes generated data on 'password' part.
For the case in question sprites have the advantage that they can be positioned regardless of the beam position in which the xDAT register was filled.
Of course it is not a trivial job because of the great use of copper on the lines and the positions for the coverage..
Surely you'll have to compromise

Not enough dma time for the the blitter i suppose.

Yep, you used all frame DMA time, only solution is to shrink COLOR00 effect to a smaller screen portion.
Anyway to do a sine scroller in this situation you need bigger changes.

[Photon]

Originally Posted by mydma

So $30..$d8 is what would have been classed as a full overscan demo back in the day?

Don't know about that, but it would certainly be classified as Overscan at any point in history!

I just meant that you should expect this range to be visible because it will be visible on most displays.

I.e. even though as you show, "emulators reveal all", it's not that bad. But the picture is output to have a little margin around the edges. This range is a good choice because it will fit almost all normal scenarios where you don't want the margin, without going mong.

[mydma]

Originally Posted by ross

DMA is not the only solution.

Launch this stupid code (some furious copy-paste from different snippets, so code contain random oddities..)
Not a single SPRITE DMA or BITPLANE DMA fetch, pure CMOVEs to DAT registers.
An unique sprite (SPR0 x-multiplexed) for the 'please insert' and 2 planes generated data on 'password' part.
For the case in question sprites have the advantage that they can be positioned regardless of the beam position in which the xDAT register was filled.

I looked at the copper list using action replay for your example.

Ive not had a chance to try anything in code yet. But am I right in understanding here that because BPL0DAT is written at the start of a raster line, then writing to SPR0DATA will show the sprite even though bitplane dma is disabled?

I had already tried writing $ffff to SPR0DATA at the top of the frame with sprite dma disabled to cause a vertical bar but it obviously only showed where bitplane dma was actually enabled.

[ross]

Originally Posted by mydma

But am I right in understanding here that because BPL0DAT is written at the start of a raster line, then writing to SPR0DATA will show the sprite even though bitplane dma is disabled?

The first write activate sprites for the full line (actually it's called BPL1DAT).
Warning, cannot be done too soon.

I had already tried writing $ffff to SPR0DATA at the top of the frame with sprite dma disabled to cause a vertical bar but it obviously only showed where bitplane dma was actually enabled.

Is the write to BPL1DAT (DMA, Copper, even CPU) that activate the buffered output for all the bplanes. At the fine position specified in BPLCON1.
Also a non-aligned DDFSTRT join the equation, especially in fetch modes higher than OCS/ECS (your $24 is one of these special cases.. try to change BPLCON1 ).
This can open you to very interesting effects (the famous BPLCON1 zoom trick to do an hw line shrink).

EDIT: gosh, just noticed that Dan is in this thread, ask him for BPLCON1 trick
First effect (~25"):
[ Show youtube player ]

[mydma]

Originally Posted by ross

:EDIT: gosh, just noticed that Dan is in this thread, ask him for BPLCON1 trick
First effect (~25"):
[ Show youtube player ]

That is one incredible demo! Ive got a vague understanding of of how a zoom is done using hardware scrolling. Never tried to code it though. Strikes me the hardest part is the actual blitter zoom every 16 pixels.

But the rest of the demo oh my god lol no idea how some of that is done at all

As for me I reduced the ampitude of the sin wave and discovered/introduced another bug