|
| Author |
Message |
jar
Member |
hi, i'm currently trying to do some a500 coding again and have some trouble getting a simple bitplane display setup to work. So far I successfully managed setup a vblank irq routine that just increments a tick counter and periodically changes the background color. This is working fine. Now I am trying to display some bitplane data (1bpl iff picture converted to raw bpl data), but without using a copperlist - just setting DIWSTRT/STOP and friends plus BPL1PT etc. in my vblank routine. But so far I was not able to display any pixel data. What am I doing wrong (code below)? Do I still need a dummy copperlist (just a WAIT e.g)?
start:
bsr getvbr
move.l d0,a0
move.l $6c(a0),oldvbi
bsr WaitRaster
move.w $dff01c,oldintena
move.w $dff002,olddma
bsr disable_dma_and_irqs
lea irq_level3(pc),a1
move.l a1,$6c(a0)
move.w #$c020,$dff09a ; c020 = SET|INTEN|VERTB
move.w #$8160,$dff096 ; DMACON=SET|BPLEN|BLTEN|SPREN
waitmouse:
btst #6,$bfe001
bne waitmouse
bsr WaitRaster
bsr disable_dma_and_irqs
move.l oldvbi(pc),$6c(a0)
; restore irq requests
move.w olddma(pc),d0
or.w #$8000,d0
move.w d0,$dff096
move.w oldintena(pc),d0
or.w #$c000,d0
move.w d0,$dff09a
rts
setscreen:
; Setup 320x256x1 screen
move.w #$2c81,$dff08e ; DIWSTRT
move.w #$2cc1,$dff090 ; DIWSTOP
move.w #$0038,$dff092 ; DDFSTRT
move.w #$00d0,$dff094 ; DDFSTOP
move.w #$1200,$dff100 ; BPLCON0 (1 planes)
move.w #0000,$dff102
move.w #0000,$dff108 ; BPL1MOD
move.w #0000,$dff10a ; BPL2MOD
rts
disable_dma_and_irqs:
lea $dff000,a6
move.w #$7fff,d2
;bsr WaitRaster
move.w d2,$9A(a6)
move.w d2,$96(a6)
move.w d2,$9C(a6)
move.w d2,$9C(a6) ; twice for A4k
rts
; VBR helper code
; ---------------
getvbr:
moveq #0,d0 ; on 68k default is 0
; Check for 68010+
move.l $4.w,a6
btst #0,296+1(a6)
beq.b is68k
; Switch to supervisor mode (movec is priviledged instruction)
lea svr_getvbr(pc),a5
jsr -30(a6) ; Supervisor() - returns vbr in d0
lea vbroffset(pc),a0
move.l d0,(a0) ; store vbr
is68k:
rts
svr_getvbr:
dc.l $4e7a0801 ; movec vbr,d0
rte
; Level3 interrupt handler
; ------------------------
irq_level3:
movem.l d0-a6,-(a7)
move.w $dff01e,d0 ; Check bits of INTREQR
btst #5,d0 ; VBLANK?
bne vertb
bra irq_level3_quit
vertb:
move.w #$0fff,$dff182
lea timer(pc),a0
addq.l #1,(a0)
bsr setscreen
move.l #pic,d1 ; bplsize=320/8*256=10240
;add.l timer,d1
move d1,$dff0e2 ; BPL1PTL
swap d1
move d1,$dff0e0 ; BPL1PTH
;move.w #$00f0,$dff180
move.w timer+2,$dff180
move.w #$4020,$dff09c
move.w #$4020,$dff09c
bra.w irq_level3_quit
irq_level3_quit:
movem.l (a7)+,d0-a6
nop
rte
; Vars
; ----
vbroffset:
dc.l 0
oldvbi: dc.l 0
oldintena: dc.l 0
olddma: dc.l 0
timer: dc.l 0
gfxlib: dc.b "graphics.library",0,0
WaitRaster:
move.l d0,-(a7)
loop:
move.l $dff004,d0
and.l #$1ff00,d0
cmp.l #303<<8,d0
bne.b loop
move.l (a7)+,d0
rts
SECTION ChipData,DATA_C
pic:
incbin "apic.bpl"
|
losso
Member |
Hi! I tested that, and I think you need to set DMAEN as well, so the move to DMACON needs to be: move.w #$8360,$dff096 ; DMACON=SET|DMAEN|BPLEN|BLTEN|SPREN |
jar
Member |
Thanks for your reply! However, wouldn‘t setting of DMAEN also enable copper DMA (and audio etc), i.e. any previously set copperlist would be active again, interfering with my vblank display settings?
|
jar
Member |
.. hm or maybe I am just misinterpreting the DMACON docs here. It says „DMAEN: Enables all DMA below“ which I read as „activates all the DMA channels mentioned below“. It dawns on me now that it might mean „need to set DMAEN in addition ton some of the other flags below in order to activate them“.. hence why sometimes this flag is referred to DMAF_MASTER i guess
|
jar
Member |
well, just was a able to try it out - lo and behold it immediately worked :) just needed to set the DMAEN flag. Thanks a lot losso!
|
Blueberry
Member |
You might be interested in my demo startup code. It handles all of the boilerplate startup code you have in your example, plus several other useful things, such as switching from other screenmodes and automatic exit on left mousebutton. It doesn't require you to have a copperlist, so you can still use it for copper-free displays. |
rloaderror
Member |
is there a benefit to a copperless display? Save dma? No need to waste bytes on a coper list? Less typing?
|
jar
Member |
Main reason for me was to gain a proper understanding about how the amiga display hardware works from first principles. The minimum basics are DMA, bitplanes and hardware registers, copperlists can be considered a convenience on top :)
My background is from PC democoding, and I didn't wan't to go the "use some preexisting api/framework" road, because then I can just continue coding on PC :)
I grew up with amiga (little coding), but it seems it took me until now to fully grasp some hardware details :)
|
rloaderror
Member |
Are you Jar in Alien Prophets?
It is fascinating how it all hangs together. For me I’m still curious whether there is some hidden crazy screenmode that could be made. Several registers I never touched yet from the descriptions it seems they should allow controlling the display. Used by monitor drivers perhaps? Who knows
|
rloaderror
Member |
I’m thinking of all these.. what happens if writing these? Are they emulated in uae?
HTOTAL 1C0 W A( E ) Highest number count (VARBEAMEN=1)
HSSTOP 1C2 W A( E ) Horizontal line position for HSYNC stop
HBSTRT 1C4 W A( E ) Horizontal line position for HBLANK start
HBSTOP 1C6 W A( E ) Horizontal line position for HBLANK stop
VTOTAL 1C8 W A( E ) Highest numbered vertical line (VARBEAMEN=1)
VSSTOP 1CA W A( E ) Vertical line position for VSYNC stop
VBSTRT 1CC W A( E ) Vertical line for VBLANK start
VBSTOP 1CE W A( E ) Vertical line for VBLANK stop
BEAMCON0 1DC W A( E ) Beam counter control register (SHRES,PAL)
HSSTRT 1DE W A( E ) Horizontal sync start (VARHSY)
VSSTRT 1E0 W A( E ) Vertical sync start (VARVSY)
|
Blueberry
Member |
They do seem to be fully emulated by WinUAE. The various monitor drivers work fine, and the internal flag I had in one of my old demos (Peanut) to manually write these registers for DBLPAL also works.
One problem with using these in demos would be that the output then is no longer PAL, so whatever monitor or recording equipment is attached to the Amiga might not be able to display it.
I think they could be useful to get the superhires resolution distributed to more square-ish pixels than 1280x256. The safest bet in that case would probably be to output completely standard VGA, i.e. 640x480 60Hz noninterlaced. And ask the compo organizers first. :)
|
jar
Member |
“Are you Jar in Alien Prophets?“
:) no. My current handle is actually „spike“ of Science. I changed it a while ago, to avoid confusion. Didn‘t bother to change it here in ADA so far :) However, i used this handle in releases starting back in 1997. the earliest alien prophets release seems to be from july 1998. but well :)
|
rloaderror
Member |
@jar: I now thought you were the coder behind "copperstorm" which was released recently only to find out that was Origo. The reason I thought of Spike was because I think Origo and Spite(not spike)!! did a few demos together in the past. Now I see from Pouet you have made a few nice PC demos.
Allrighty then :) Looking forward to your Amiga works.
@blueberry: If superhires pixels can be distributed to more square pixels.. Does that mean that lowres resolutions like 256x256 could be distributed to full width on a pal screen by messing with these registers?
|
Blueberry
Member |
You could stretch it, but the resulting mode would not be PAL. Since the pixel frequency is fixed (7MHz for lowres, 14MHz for hires, 28MHz for superhires), you would end up with a very non-standard mode with 20kHz scanlines, which probably very few monitors would be able to display.
|
krabob
Member |
I did some test about that and there is a silly reason that oblige to use the copper:
you set the bitmap planes in low/hi pointers in the copper, and these pointers value are actually updated by the curse of the beam, the modulo, etc... line after lines.
so if you have an empty copper the next frame, the bitmap memory will just be "the next line in memory after the previous frame bitmap".
so I guess you can have a very little copper with only the bitmap pointers, and settings all the rest elsewhere in the cpu code with movems.
This could give a little more bus available for the rest, I don't know. Let's say: passing a whole AGA palette is actually huge.
|
Blueberry
Member |
The bitplane pointers were actually the first thing I took out of the copperlist. Many of my demos have everything but the bitplane pointers in the copperlist. :) The motivation was to avoid the race condition that arises when the CPU writes new bitplane pointers to the copperlist while the copper is reading them. This results in the glitches which are so common in Amiga demos. If instead the frame swap is done by writing a single value (pointer or index) atomically, the vblank interrupt can compute and write the bitplane pointers from that and the glitch is gone. It's also often smaller to just write the pointers directly to the registers (a whole longword at a time) than to write them to the copperlist. This is important for 4k intros. :) There is indeed some space to be saved by writing the rest of the "copperlist" directly to the registers using the CPU, since this allows the register numbers to be delta coded, making them compress better. The code looks like this: ; A3 = $DFF000
lea CopperData(pc),a0
moveq.l #(CopperData_End-CopperData)/4-1,d7
.cloop: add.w (a0)+,a3
move.w (a0)+,(a3)+
dbf d7,.cloop
|
|
|
