V4 Kernel available -- WIP

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

V4 Kernel available -- WIP

Post by uze6666 »

For those who are interested, I've committed in SVN what's done so far regarding the latest revision of the kernel. Keep in mind this is a development branch and *will* change, though it is stable and builds fine. You can readily do "high-resolution" games with sprites like my Arknoid or Whak-a-mole with this code.

Here's a summary of the new features:

-New video mode 3: 30x28 Tiles+Sprites using 8x8 tiles & sprites. Scrolling yet to be implemented. Currently, heavy CPU usage requires disabling one or more sound channels.
-New EEPROM libraries to save game related data (ie: scores, progress, etc).
-New switchable color correction for the composite output. It's been reported to screw some LCD TV, but for those, use the S-VIDEO output!
-Support for the SNES mouse
-Fixed mode1 to remove unrolled loop
-Lots of cleanup and memory optimizations (lots more to do)
-Maybe Dave's hi-res mode?

Note that the demos are *not* updated to work with the WIP kernel. However, I will add the whack-a-mole demo very soon, so you can get an idea how it works.

Get source code here at Google Code. I'll keep you posted in this topic about progress.

Cheers,

Uze
------------------------------------------------------------------------------
Edit: January 06, '09
Added Whack-a-Mole game under /demos which support new video mode3 and SNES mouse. Not much comments so far, but that should help anyone get started.




ps: I'll remove the "beta" moniker on version as it does not fit lots with new features! Let's call it the V4 kernel.
exile
Posts: 11
Joined: Wed Dec 17, 2008 7:40 pm

Re: V4 Kernel available -- WIP

Post by exile »

Wow, you rely have work hard.
You really keep UZBOX alive :D .
I tried make own optimist video core but only optimizer I came up wide was jitter remover

Code: Select all

	lds ZL,TCNT1L
	subi ZL,0x10 ;MIN_INT_LATENCY

	sbrs ZL,0
	rjmp .		//diff 1 (1 if skip else 2)

	sbrs ZL,1
	LPM ZH, Z	//diff 2 (1 if skip else 3)

	sbrc ZL,2
	rjmp s_end	//diff 4 (2 if not skip else 6)
	LPM ZH, Z
	rjmp .
s_end:
:|
DavidEtherton
Posts: 252
Joined: Tue Dec 02, 2008 12:38 am
Location: Carlsbad, California (USA)

Re: V4 Kernel available -- WIP

Post by DavidEtherton »

exile wrote:Wow, you rely have work hard.
You really keep UZBOX alive :D .
I tried make own optimist video core but only optimizer I came up wide was jitter remover
That reminds me -- do we need to make sure that user-level code never keeps interrupts disabled for longer than that entry code there is prepared to deal with?

-Dave
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: V4 Kernel available -- WIP

Post by pragma »

Uze, now that's an awesome update.
uze6666 wrote: -New video mode 3: 30x28 Tiles+Sprites using 8x8 tiles & sprites. Scrolling yet to be implemented. Currently, heavy CPU usage requires disabling one or more sound channels.
I'm excited about this change, but that's a shame about the music. You must be doing a helluva lot of video pre-computation per v-blank; what's the RAM budget MODE3 like?

Also, I noticed the emulator got some SVN love over the last two weeks. Any word on the next binary release?
DavidEtherton
Posts: 252
Joined: Tue Dec 02, 2008 12:38 am
Location: Carlsbad, California (USA)

Re: V4 Kernel available -- WIP

Post by DavidEtherton »

pragma wrote:Uze, now that's an awesome update.
uze6666 wrote: -New video mode 3: 30x28 Tiles+Sprites using 8x8 tiles & sprites. Scrolling yet to be implemented. Currently, heavy CPU usage requires disabling one or more sound channels.
I'm excited about this change, but that's a shame about the music. You must be doing a helluva lot of video pre-computation per v-blank; what's the RAM budget MODE3 like?

Also, I noticed the emulator got some SVN love over the last two weeks. Any word on the next binary release?
Personally I'm most interested in a mode that lets me manage the ramtiles myself in user-level code for maximum flexibility; wouldn't that free up a bunch of time every frame?

(You can get the latest win32 release of the emulator directly from that thread in the emulator forum -- it's always in sync with the latest SVN code. I don't know offhand how to update the binary release up on google code, and I'm also not sure if distributing SDL.dll is encouraged by their developers)

-Dave
User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Re: V4 Kernel available -- WIP

Post by Jhysaun »

So anychanges in the old video mode.

Can you flip sprites in Mode1(Classic Mode)?


Does Beta4 Classic Mode use more RAM/ cycles than Beta3 Sprite MOde?
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: V4 Kernel available -- WIP

Post by pragma »

DavidEtherton wrote:You can get the latest win32 release of the emulator directly from that thread in the emulator forum
Thanks, I didn't know that. I downloaded it and it works great. As my hardware is still on order, this thing is a life-saver.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: V4 Kernel available -- WIP

Post by uze6666 »

I tried make own optimist video core but only optimizer I came up wide was jitter remover
Yeah, all that low level video stuff is not for the faint of heart! ;)
That reminds me -- do we need to make sure that user-level code never keeps interrupts disabled for longer than that entry code there is prepared to deal with?
Thats true. Apart for atomic 16-bits writes and the like, interrupts should not be masked in the user code. The current jitter fixing code is set in length, but we *may* be able to have a configurable maximum latency (If there's a need for that).
I'm excited about this change, but that's a shame about the music. You must be doing a helluva lot of video pre-computation per v-blank;
There's indeed a lot of computations going on in the VSYNC. The music mixing normally takes ~20 scanlines alone. "Ramtiles" blitting takes also a lot of cycles, though it's linear to how many of those you are willing to allocate (using RAM_TILES_COUNT). The code was initially written in C but, even with -O3, it was too slow. The kernel would crash in my MarioWorld Demo because it would need all cycles until the next VSYNC! I've painfully ported that code in assembler and gained several scanlines. However, more optimizations can be done. For one, the sync code is totally inefficient, wasting the cycles in between pulses transitions. We could recover maybe 6-7 scanlines by addressing that (would need 4 to recover the lost sound channel)...but reworking sync code is a real pain! I though of mixing sound during the HBLANK, but I don't think there's enough cycles to handle the way it's done now. So we'll see.
what's the RAM budget MODE3 like?
That depends. If you don't need sprites (RAM_TILES_COUNT=0), then the kernel uses only 1576 bytes (38.5% of 4096) including a 30x28 VRAM. Each ramtile is 64 bytes and each "free moving" 8x8 sprites, will require 4 ramtiles.
Also, I noticed the emulator got some SVN love over the last two weeks. Any word on the next binary release?
I think we need to come up with something regarding binaries. Would be nice to have some sort of automated builds for all platforms. In the mean time, we could just continue posting binaries in the emulator topic?

Uze
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: V4 Kernel available -- WIP

Post by uze6666 »

Personally I'm most interested in a mode that lets me manage the ramtiles myself in user-level code for maximum flexibility; wouldn't that free up a bunch of time every frame?
Hmmm, the WIP code can handle that albeit with a #define to remove some vsync code. The only thing I wonder about is tearing/shearing of sprites, since you will never know when some ramtile are blitted and be part of the next field or frame. As an added benefit, with clever use of the ramtiles, you could have things like PutPixel() and why not DrawLine(). Here comes the 3D vectors! :mrgreen:

What kind of api where you thinking of? Willing to develop some using the raw blitting functions?

Uze
DavidEtherton
Posts: 252
Joined: Tue Dec 02, 2008 12:38 am
Location: Carlsbad, California (USA)

Re: V4 Kernel available -- WIP

Post by DavidEtherton »

One version of my 288x240 mode inlined the hsync code with my render function so that I could use the delay cycles in there for more setup, and it wasn't particularly difficult to implement. Then I realized that I was already starting TOO SOON and undid those changes (my real problem was too many extra cycles at the end of the scanline).

Personally I'd like to see more .macro's being used in the kernel code, they can simplify a lot of repetitive tasks. For example, the existing hsync function could be written something like this:

hsync_start
rcall mix_audio
delay 60
hsync_end

(Conditional compilation would hopefully let the delay macro do something like this:)

Code: Select all

.macro delay val
   ldi r19,\val/3
   dec r19
   brne .-2
.if \val % 3 == 2
   rjmp .
.elif \val %3 = 1
   nop
.endif
.endm
-Dave
Post Reply