V4 Kernel available -- WIP
V4 Kernel available -- WIP
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.
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.
Re: V4 Kernel available -- WIP
Wow, you rely have work hard.
You really keep UZBOX alive .
I tried make own optimist video core but only optimizer I came up wide was jitter remover
You really keep UZBOX alive .
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:
-
- Posts: 252
- Joined: Tue Dec 02, 2008 12:38 am
- Location: Carlsbad, California (USA)
Re: V4 Kernel available -- WIP
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?exile wrote:Wow, you rely have work hard.
You really keep UZBOX alive .
I tried make own optimist video core but only optimizer I came up wide was jitter remover
-Dave
Re: V4 Kernel available -- WIP
Uze, now that's an awesome update.
Also, I noticed the emulator got some SVN love over the last two weeks. Any word on the next binary release?
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?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.
Also, I noticed the emulator got some SVN love over the last two weeks. Any word on the next binary release?
Tango D Library http://www.dsource.org/projects/tango
D Dynamic Libraries - http://www.dsource.org/projects/ddl
Enki Parser Generator - http://www.dsource.org/projects/ddl/wiki/Enki
D Programming Language - http://www.digitalmars.com/d
D Dynamic Libraries - http://www.dsource.org/projects/ddl
Enki Parser Generator - http://www.dsource.org/projects/ddl/wiki/Enki
D Programming Language - http://www.digitalmars.com/d
-
- Posts: 252
- Joined: Tue Dec 02, 2008 12:38 am
- Location: Carlsbad, California (USA)
Re: V4 Kernel available -- WIP
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?pragma wrote:Uze, now that's an awesome update.
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?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.
Also, I noticed the emulator got some SVN love over the last two weeks. Any word on the next binary release?
(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
Re: V4 Kernel available -- WIP
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?
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.
Re: V4 Kernel available -- WIP
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.DavidEtherton wrote:You can get the latest win32 release of the emulator directly from that thread in the emulator forum
Tango D Library http://www.dsource.org/projects/tango
D Dynamic Libraries - http://www.dsource.org/projects/ddl
Enki Parser Generator - http://www.dsource.org/projects/ddl/wiki/Enki
D Programming Language - http://www.digitalmars.com/d
D Dynamic Libraries - http://www.dsource.org/projects/ddl
Enki Parser Generator - http://www.dsource.org/projects/ddl/wiki/Enki
D Programming Language - http://www.digitalmars.com/d
Re: V4 Kernel available -- WIP
Yeah, all that low level video stuff is not for the faint of heart!I tried make own optimist video core but only optimizer I came up wide was jitter remover
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).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?
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.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;
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.what's the RAM budget MODE3 like?
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?Also, I noticed the emulator got some SVN love over the last two weeks. Any word on the next binary release?
Uze
Re: V4 Kernel available -- WIP
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!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?
What kind of api where you thinking of? Willing to develop some using the raw blitting functions?
Uze
-
- Posts: 252
- Joined: Tue Dec 02, 2008 12:38 am
- Location: Carlsbad, California (USA)
Re: V4 Kernel available -- WIP
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:)
-Dave
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