Page 2 of 2
Posted: Sat Jan 06, 2007 10:52 am
by Fonzie
Do you want an oldskool-style demo where you merely go from one part to the other in a predetermined order
Yeah, i think it could be good... i mean, one impressive screen per demo only... need to be rythmed by the same sound track i think...
Like you, i wont use interupts (i was too shocked by segacd hardware interupts-timings problems, no need them anymore LOL).
"Maybe the games from the original could be remade for the Genesis/Sega CD. "
Umm, then we need to tell ppl to dont use hint... too complex to drive with accurency on segacd.
I think it would be interesting to do something like Cascade Cassette 50.
Ho, you think? Well... maybe it is too much effort to make a gameplay code... But it could had some interest from the viewer... Anyinput?
but I can try composing something with MML.
Ho, nice
Uushen driver is now z80 based?
Maybe we can use mvs tracker too
Posted: Sat Jan 06, 2007 7:22 pm
by Pascal
hey ! it's megadrive anniversary , why doing on segacd
;)
Posted: Mon Jan 08, 2007 9:35 am
by TmEE co.(TM)
Yesterday I was messing with my demo thingy, I noticed that 256KB is getting tight for me (PCM, FMV maybe), 512KB maybe (If we get no more than 8 people).
What about VBL and HBL ? My demo is VBL timed. My VBL routine is simple ADDQ.L #1, (VTIMER) timer.
Posted: Mon Jan 08, 2007 8:58 pm
by Fonzie
Yo TMEE.
If your demo is just VBL timed, you should rather use VDP's Vflag... For that just wait for Vdrawing and loop until Vnothing happen
I was using VBL to increment a counter before, but then i found more handy to go for Vflag watching, it is so more stable.
As for the 256KB extend... well... If there is space, why not... but to be fair, you would have to negociate the additional space by providing something impressive
Posted: Mon Jan 08, 2007 10:28 pm
by ob1
I'd like to submit something but don't know yet if I'd be brave enough. For now, don't count me in.
Do we have a deadline yet ?
Posted: Tue Jan 09, 2007 6:28 am
by TmEE co.(TM)
Fonzie wrote:Yo TMEE.
If your demo is just VBL timed, you should rather use VDP's Vflag... For that just wait for Vdrawing and loop until Vnothing happen
I was using VBL to increment a counter before, but then i found more handy to go for Vflag watching, it is so more stable.
As for the 256KB extend... well... If there is space, why not... but to be fair, you would have to negociate the additional space by providing something impressive
OK, I'll try that that !!!
Posted: Tue Jan 09, 2007 8:45 am
by ob1
Great !!!
I've just figured it. Here it is, my way :
Code: Select all
GFX_CTRL equ $C00004
main:
* main code goes here
waitVInt:
move.w GFX_CTRL,d0
andi.w #$0008,d0
bne waitVInt
* code during V blank
waitVIntFinish:
move.w GFX_CTRL,d0
andi.w #$0008,d0
beq waitVIntFinish
bra main
or, for the Cish people :
Code: Select all
int main() {
int * GFX_CTRL = (int *) 0xC00004;
/* main code goes here*/
while (!(*GFX_CTRL & 8)) ;
/* code during V blank */
while (*GFX_CTRL & 8) ;
}
Re: Megadrive multipart demo
Posted: Tue Jan 09, 2007 9:01 am
by ob1
Fonzie wrote:This rom header can reroot hint and vint using vectors in ram to each demo.
Just figured out this too.
The header would be
Code: Select all
dc.l $00FFFFFC,$200
dc.l INT,INT,INT,INT,INT,INT,INT
dc.l INT,INT,INT,INT,INT,INT,INT,INT
dc.l INT,INT,INT,INT,INT,INT,INT,INT
dc.l INT,INT,INT,HBL,INT,$FF0000,INT,INT
dc.l INT,INT,INT,INT,INT,INT,INT,INT
dc.l INT,INT,INT,INT,INT,INT,INT,INT
dc.l INT,INT,INT,INT,INT,INT,INT,INT
dc.l INT,INT,INT,INT,INT,INT,INT
and for each demos, we would have something like
Code: Select all
move.l #$FF0000,a2
move.w #$5280,(a2)+ ; addq.l #1,d0
move.w #$4E73,(a2)+ ; rte
move.w #$816C,GFX_CTRL ; enable V Int
where my V Int code is just
.
Posted: Tue Jan 09, 2007 9:39 am
by Pascal
that's the idea, but it's better to have an variable which hold a pointer to the user vblank function itself. Here's the code i'm using for my interrupts handling (HInt is the same)
Code: Select all
MD_VBlank_Cnt ds.l 1; vblank counter
MD_VBlank_Handler ds.l 1; *vblank function pointer
MD_HBlank_Handler ds.l 1; *hblank function pointer
VBL:
68K_DisableINT
movem.l d0-d7/a0-a6,-(a7)
addq.l #1,MD_VBlank_Cnt
move.l MD_VBlank_Handler,a0
jsr (a0)
PAD_Read
movem.l (a7)+,d0-d7/a0-a6
68K_EnableINT
rte
*******************************************************************************
* MACRO 68K_InstallVBlankHandler
* DESCRIPTION: \1: Adress of the function to install as VBlank
* PARAMETERS:
*******************************************************************************
MD_InstallVBlankHandler macro
68K_DisableINT
move.l \1,MD_VBlank_Handler
68K_EnableINT
endm
*******************************************************************************
* MACRO 68K_DisableINT
* DESCRIPTION: Disable INT on the 68000
* PARAMETERS:
*******************************************************************************
68K_DisableINT macro
move.w sr,-(sp) ; disable interrupt
or.w #$700,sr
endm
*******************************************************************************
* MACRO 68K_EnableINT
* DESCRIPTION: Enable INT on the 68000
* PARAMETERS:
*******************************************************************************
68K_EnableINT macro
move.w (sp)+,sr
endm
Posted: Tue Jan 09, 2007 1:02 pm
by Stef
My basic library provides almost all needed basics functions as WaitVSync(), Z80Halt(), VDP_UploadTile(), ShowFPS(), DrawString(), IntToStr(), some timers functions...
It also provides a callback for VBlank interrupt and HBlank interrupt, bitmap support, a complete 3D transformation library with camera and 1 (directionnal) light support (for flat shading), but this part is just for fun as performance are quite limited...
Of course, all that stuff brings some overhead compared to a basic and direct use of hardware, but i try to keep the overhead as small i can and development is really easier. You don't have to rewrite all these basics routines. It could be nice to work on this base, of course everyone is free of doing as he want, but that could help in the library growing then developing a real and efficient genesis devkit in future
Posted: Tue Jan 09, 2007 1:16 pm
by TmEE co.(TM)
I was thinking of relocatable VBL/HBL stuff, In RAM there are 2 routines, one for VBL other for HBL, when either of the ints happen, 68K then jumps to that routine in RAM. Routine itself is a JMP to location of your VBL/HBL routine. Use LEA to get the address of your routine and copy it to RAM. JMP should take 2 bytes and address 4 so 12 bytes are required.
Code: Select all
MOVE.W #2700, SR ;disable ints
LEA RAM_routines, A0
MOVE.L #$FF0000, A1
MOVE.W (A0)+, (A1)+
MOVE.W (A0)+, (A1)+
MOVE.W (A0)+, (A1)+
LEA VBlank, A0
MOVE.L A0, ($FF0002) ;I'm not sure if you can do this like so
LEA HBlank, A0
MOVE.L A0, ($FF0008)
MOVE.W #2000, SR ;enable ints
IdleLoop:
BRA IdleLoop:
VBlank:
ADDQ.L #1, (VTIMER)
RTS
HBlank:
ADDQ.L #1, (HTIMER)
RTS
RAM_routines:
JMP #000000
JMP #000000
Posted: Sat Jan 20, 2007 3:29 pm
by Mask of Destiny
Fonzie wrote: Umm, then we need to tell ppl to dont use hint... too complex to drive with accurency on segacd.
If the demo is less than 53K or so, it's not complicated at all. Even if it's bigger than that, all you need to do is move the HInt handler to Genesis RAM.
(i was too shocked by segacd hardware interupts-timings problems, no need them anymore LOL).
I wasn't aware of there being a timing problem apart from HInts or is that all you're referring to. Technically there is a delay in both if all your code is in Word RAM as the vector table in the BIOS points to a series of long jump instructions, but it's not a big issue for VInts.
If your demo is just VBL timed, you should rather use VDP's Vflag... For that just wait for Vdrawing and loop until Vnothing happen
I was using VBL to increment a counter before, but then i found more handy to go for Vflag watching, it is so more stable.
Personally I always found it easier to just do all my per-frame rendering in my VInt handler, but to each his own I suppose.
Posted: Wed Jan 24, 2007 11:24 am
by TmEE co.(TM)
OK, who is writing something ??? I am with some breaks