I'll lend a hand with ASM stuff. There is already super optimized ASM code for reading bytes in SDBase.S which was part of the pre SDHC T2K source.
In T2K the very fast reading for the background - I always read full sectors
256 pixels wide * 208 Scanlines = 6656 bytes /512 = 13 sectors
The title screen and other resources read from the SD card are only 3424 bytes long so they are partial sectors. I don't care about the speed of those though so I have never benchmarked how long it takes to recover.
WIP - Castlevania Demo!
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: WIP - Castlevania Demo!
Awesome, thank you!CunningFellow wrote: ↑Thu Feb 09, 2023 8:50 pm I'll lend a hand with ASM stuff. There is already super optimized ASM code for reading bytes in SDBase.S which was part of the pre SDHC T2K source.
In T2K the very fast reading for the background - I always read full sectors
256 pixels wide * 208 Scanlines = 6656 bytes /512 = 13 sectors
The title screen and other resources read from the SD card are only 3424 bytes long so they are partial sectors. I don't care about the speed of those though so I have never benchmarked how long it takes to recover.
I have the nice fast streaming code in asm that ignores the CRC (from bootlib) that I split into two functions, one for cuing a sector for read, and another reading some data bytes into a spot in memory that I care about. I just need help figuring out where and how to shoehorn some reads in the HSYNC code. I'm thinking maybe unrolled instructions that just toggle the clock pin might be the fastest, I don't actually care about the data received, though at the end I would have to make sure to drain the RX buffer. The ideal would be if the clock pin of the SD card was attached to a pin on the AVR that we could toggle automatically using a PWM timer, then we could truly just eat and toss the remaining bytes asynchronously.
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: WIP - Castlevania Demo!
psudocode wise the simplest would just be
If Bytecount < 512 then out SPDR
And if you had less that 224 bytes to clock out to get to end of sector that would happen in the video render time.
You would still have to clock out the last two stuff bytes.
More complex things could maybe get you being able to clock out 511 bytes and the stuff bytes and a stop/cue command to get ready for next time.
If Bytecount < 512 then out SPDR
And if you had less that 224 bytes to clock out to get to end of sector that would happen in the video render time.
You would still have to clock out the last two stuff bytes.
More complex things could maybe get you being able to clock out 511 bytes and the stuff bytes and a stop/cue command to get ready for next time.
Re: WIP - Castlevania Demo!
Random bump.
Was thinking about Mode 74(or sub variants) then this popped into my mind. Because of the whip being a glutton for sprites in addition to many on screen enemies, I think this one is hard to realize in Mode 3 without significant re-imagining and downsizing(maybe I'm wrong, let me know).
Maybe a less significant downsizing could be a horizontal resolution trade, where some area that used to be purely vertical scrolling could be the same size but scroll horizontally also. The sprites on these modes is wild, easily enough to do CV? Random thought and these modes werent available during the heyday of CV development.
Was thinking about Mode 74(or sub variants) then this popped into my mind. Because of the whip being a glutton for sprites in addition to many on screen enemies, I think this one is hard to realize in Mode 3 without significant re-imagining and downsizing(maybe I'm wrong, let me know).
Maybe a less significant downsizing could be a horizontal resolution trade, where some area that used to be purely vertical scrolling could be the same size but scroll horizontally also. The sprites on these modes is wild, easily enough to do CV? Random thought and these modes werent available during the heyday of CV development.
Re: WIP - Castlevania Demo!
CV stayed a demo because indeed there was no more ramtiles for enemies in mode 3. Would be interesting to see how it looks in m74. Another thing on my todo list.
Re: WIP - Castlevania Demo!
Definitely a classic Uzebox demo
I hear that...TODO grows much faster than TODONE for me
I hear that...TODO grows much faster than TODONE for me
Re: WIP - Castlevania Demo!
Like DA said, the Castlevania demo is one of the most impressive Uzebox demos. It'd be fantastic to see a more complete remake, one with some enemies, or even just a candle or two to whip into some hearts.