Hello world. It works, but... (controller interrupts?)

colonthree · Post by **colonthree** » Mon Mar 07, 2011 3:48 pm

Oh so thanks again for the informations guys!

My next issue I'm having is DMA. I've been trying to learn how to do this before moving on to other parts of the system. I've spent a couple of days or so now trying to work this out myself referring to sega2 and genvdp.txt
Even compared against TMEE's DMA code from the TMEGALIB. Only real difference I noted is that you seem to set VDP destination addr high and addr low before addr middle. Is that some weird requirement or was it just more efficient to code it that way for the subroutine input data registers?
I checked over my code many times and I'm satisfying all the requirements specified in sega2 to perform a VRAM fill (or so I think). Here's the command chain I'm using to try fill plane a with 0x0023 (Actually want to fill with NUL but it makes more sense to try fill with an ASCII character first so I can see if it's working on display without having to debug, and I'm only trying to fill plane a for now until I know how to work it properly!):

Code: Select all

	movea.l	#$C00000, a4	; a4 points to vdpdata 
	movea.l	#$C00004, a5	; a5 points to vdpctrl
	move.w	#$8154, (a5)	; DISPLAY and DMA on. VINT off. 28-cell mode.
	move.w	#$8F01, (a5)	; VRAM destination auto-increment (should this be 1 or 2?) 
	move.w	#$9300, (a5)	; sets dma length (low) to 0x00 
	move.w	#$9420, (a5)	; sets dma length (high) to 0x20. Total length 0x2000 (ALL of plane a) 
	move.w	#$9780, (a5)	; sets dma 'source high' to 'fill using constant' mode 
	move.w	#$9600, (a5)	; clearing dma source mid just incase
	move.w	#$9500, (a5)	; clearing dma source low just incase
	move.l	#$40000003, (a5); VRAM addr: C000 
	; genvdp.txt says the above write triggers dma, 
	; but it doesn't have the constant until following vram write, see next line
	move.w   #$0023, (a4)   ; move "#" into VDP_DATA to trigger DMA FILL 
	; dma should begin just now after write complete, right?

Plane a is set to VRAM:C000 elsewhere and I know that's correct because I can of course do the standard method of pushing data into plane a name table (hence getting hello world on screen!)

Also in my code all the setting of VDP registers, and vdpdata,vdpcontrol to a4,a5 is done at the start of the ROM using a table, I've just tried coding them all inline here in case some code inbetween is somehow changing them, shouldn't be the case, and also so you don't have to look through the full code, unless you might have to anyway? Well it's hardly massive being hello world! XD

Checked in Exodus (which is brilliant!) and KMod (also very useful), and the 0x0023 is being written to VRAM:C000, just no DMA. (!?)

Thanks for any and all help guys

I'm at a complete loss! Let's see if I can figure this out before someone posts what I'm doing wrong. GAME ON

edit: Originally I was trying to fill with 0x23, then realised I actually need to format it 0x0023, so updated that, still not triggering DMA, of course it should trigger regardless of what the data represents. Just overwriting first letter with #
Also, would this work:
move.b 0x23, (a4)
Would it be interpreted 0x0023, 0x2323, or is it an invalid VDP write?

edit2:
Aha, I forgot you needed to set bit 7 in the data port write to trigger DMA. I thought it was ALWAYS 0 because of page 12 of sega2, where the table specifies CD4 and CD5 are 0 regardless of access mode, when perhaps it should say DMA in the CD5 column...
This brings the question: when is CD4 set, if ever?

Now plane a seems to be getting blanked in stead of # everywhere so I still have something to sort out...

Eke · Post by **Eke** » Tue Mar 08, 2011 7:30 am

Also, would this work:
move.b 0x23, (a4)
Would it be interpreted 0x0023, 0x2323, or is it an invalid VDP write?

In MD mode, VDP always read 16-bit data from the 68k bus, it doesn't make any difference between byte or word writes. Now, according to 68k user manual, when using 8-bit memory writes, byte is duplicated to D0-D7 and D8-D15 so this would be interpreted as 0x2323 by VDP, but I guess it depends on 68k implementation, different CPU revisions might act differently.

Aha, I forgot you needed to set bit 7 in the data port write to trigger DMA. I thought it was ALWAYS 0 because of page 12 of sega2, where the table specifies CD4 and CD5 are 0 regardless of access mode, when perhaps it should say DMA in the CD5 column...

The official doc clearly states CD5 must be set to trigger DMA operations. The page you read is for normal read/Write operations, read a few pages after for DMA. In a sense, it's a little bit logical, how would VDP make the difference from normal write/read operations otherwise ?

This brings the question: when is CD4 set, if ever?

CD4 is only set in case of DMA Copy operation. I think it indicates the VDP a special bus access (a read followed by a write). Would be interested to test what this bit does outside DMA, with a normal write or read (probably nothing).

Now plane a seems to be getting blanked in stead of # everywhere so I still have something to sort out...

Try with 0x2300 instead of 0x0023

colonthree · Post by **colonthree** » Tue Mar 08, 2011 1:10 pm

Eke wrote:The official doc clearly states CD5 must be set to trigger DMA operations. The page you read is for normal read/Write operations, read a few pages after for DMA. In a sense, it's a little bit logical, how would VDP make the difference from normal write/read operations otherwise ?

Hmm fair point I guess, although I assumed it might have relied solely on the DMA Enable bit in Register #1. CD5 setting slipped my mind when I first posted.

Eke wrote:
Now plane a seems to be getting blanked in stead of # everywhere so I still have something to sort out...
Try with 0x2300 instead of 0x0023

I tried all combinations of 00 and 23, and found 0x2300 worked, however, I also had my VDP autoinc set to 1 (as in the above code)
It was originally set to 2 like I thought it should be but since I didn't know which part of the code was the problem I kept changing values in trial and error, and made more problems for myself. I think I have it sorted now thanks!

colonthree · Post by **colonthree** » Sat Apr 02, 2011 1:32 am

Having on and off progress with this project which explains why I'm only asking this question now:
Do the controllers not perform external/peripheral interrupts?

From all the code/document reading I've done I don't think I've read about it being possible, it seems like you have to manually poll regular controller data.

Is this so? and if so, WHY?

In case the reason is in fact obvious, keep in mind I am still relatively new to this!

Thanks again people

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Apr 02, 2011 7:31 am

the TH line that controllers use for selecting which set of buttons to send are outputs to the controller. To get an interrupt happen from controller port you need to enable it and have something pull the TH line low from controller side. You cannot generate interrupts from software by toggling the line.

colonthree · Post by **colonthree** » Sat Apr 02, 2011 8:20 pm

I'm not sure if that answers my question - does a standard controller cause interrupts to happen?

TmEE co.(TM) wrote:To get an interrupt happen from controller port you need to enable it and have something pull the TH line low from controller side.

What I mean is does this^ actually happen or not? Only with special peripherals maybe?..

Or do you just check for controller input every frame or so? And if I DO have to poll it, is per-frame a safe period, or should I poll faster? Can controller input be missed at that speed?

I have my hello world just running controller check in a main loop, but it feels like there should be a better, more efficient way, what if I want to (almost) dedicate 68k to some other task but still allow user control? Do I just prioritise my code to timeshare?

Thanks

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Apr 02, 2011 8:31 pm

Controller cannot generate interrupts as the interrupt generating capable pin goes to controller not comes from controller.

And once per frame is best as it will keep compatibility with 6 button controller. If you do more than once per frame reads you may get autofire effect on 6buttoners, but 3buttoners will always work.

colonthree · Post by **colonthree** » Sat Apr 02, 2011 8:48 pm

TmEE co.(TM) wrote:Controller cannot generate interrupts as the interrupt generating capable pin goes to controller not comes from controller.

I see, so my next question is why is this!?
Would it not have been relatively easy and sensible for Sega to implement this? Is there any use for it the way it's configured?

Thanks for the info Tiido!

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Apr 02, 2011 9:12 pm

The interrupt is meant for light guns and comms cables. The controllers need to be much more complex if they'd generate interrups when button is pressed or released etc. (like keyboards on PC) and it would not be very cost effective.

colonthree · Post by **colonthree** » Sat Apr 02, 2011 9:16 pm

Ah right, I know next to nothing about the hardware behind the code.
Thanks again

Stay tuned for my next stupid question!