English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. Asm / Hardware (http://eab.abime.net/forumdisplay.php?f=112)
-   -   Getting back into coding. But does this work on a REAL Amiga? (http://eab.abime.net/showthread.php?t=98997)

mydma 29 September 2019 22:03

Getting back into coding. But does this work on a REAL Amiga?
 
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
https://i.imgur.com/Wge8ZKO.jpg

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...
https://www.youtube.com/watch?v=OKTCLNpDR4A
Dont know what went on with the capture as its a lot smoother than that :guru

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

ross 29 September 2019 22:36

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.

:great

mydma 29 September 2019 22:50

Quote:

Originally Posted by ross (Post 1348493)
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.

:great

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 29 September 2019 23:05

Quote:

Originally Posted by mydma (Post 1348496)
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 29 September 2019 23:57

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 30 September 2019 00:01

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 30 September 2019 00:20

Quote:

Originally Posted by DanScott (Post 1348518)
$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 30 September 2019 09:05

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 30 September 2019 16:34

Quote:

Originally Posted by DanScott (Post 1348517)
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 30 September 2019 17:59

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

mydma 02 October 2019 01:11

Quote:

Originally Posted by ross (Post 1348493)
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.

Quote:

Originally Posted by DanScott (Post 1348518)
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.

Quote:

Originally Posted by Photon (Post 1348611)
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?

Quote:

Originally Posted by Toni Wilen (Post 1348558)
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?

Quote:

Originally Posted by clenched (Post 1348630)
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 :spin

ross 02 October 2019 01:57

1 Attachment(s)
Quote:

Originally Posted by mydma (Post 1348971)
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 :)

Quote:

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 02 October 2019 23:23

Quote:

Originally Posted by mydma (Post 1348971)
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 03 October 2019 00:29

Quote:

Originally Posted by ross (Post 1348975)
;) 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 03 October 2019 01:12

Quote:

Originally Posted by mydma (Post 1349155)
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?

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

Quote:

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 :D
First effect (~25"):
https://www.youtube.com/watch?v=GazqAFdhcvU

mydma 06 October 2019 00:38

Quote:

Originally Posted by ross (Post 1349166)
:EDIT: gosh, just noticed that Dan is in this thread, ask him for BPLCON1 trick :D
First effect (~25"):
https://www.youtube.com/watch?v=GazqAFdhcvU

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 :crazy

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


All times are GMT +2. The time now is 02:42.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.

Page generated in 0.04906 seconds with 11 queries