if you are interested by LZ4 decompressor, you can find the 6502 implementation here :
http://pferrie.host22.com/misc/appleii.htm
Search found 305 matches
- Sun Jan 03, 2016 9:25 am
- Forum: NESdev
- Topic: Compression benchmarks
- Replies: 23
- Views: 10849
- Mon Dec 28, 2015 3:58 am
- Forum: NESdev
- Topic: Compression benchmarks
- Replies: 23
- Views: 10849
Re: Compression benchmarks
You have the lz4 one :
http://www.brutaldeluxe.fr/products/crossdevtools/lz4/
It's for 65816 cpu but a 6502 version exist somewhere .
It's a fast decompressor (real time oriented), but it have not the best ratio of course .
http://www.brutaldeluxe.fr/products/crossdevtools/lz4/
It's for 65816 cpu but a 6502 version exist somewhere .
It's a fast decompressor (real time oriented), but it have not the best ratio of course .
- Wed Dec 09, 2015 12:19 pm
- Forum: SNESdev
- Topic: faster, but less accurate, sprite rotation algorithm
- Replies: 6
- Views: 3429
Re: faster, but less accurate, sprite rotation algorithm
It consumes many cycles ??Converting from packed pixel to planar takes a lot of work too
I said to stef, that the main reason for slow rendering on snes was his planar mode,it take many more cycles than packed pixels and makes software effects more slower than MD .
- Tue Sep 01, 2015 10:28 am
- Forum: SNESdev
- Topic: SNES register sizing schemes (65816 M and X)
- Replies: 28
- Views: 7236
Re: SNES register sizing schemes (65816 M and X)
Memory is *never* a problem for me on MD as on SNES, you have plenty of them so there is no interest in trying to optimize their use. It is definitely useful on NES and PCE systems though :p Working with 8 bit allow you to do some tricks that are not possible with 16 bit . Of course on 68k, working...
- Sat Aug 29, 2015 10:15 am
- Forum: General Stuff
- Topic: What is the slowest part of 6502/65816 running C?
- Replies: 78
- Views: 12040
Re: What is the slowest part of 6502/65816 running C?
thanks tepples 
- Fri Aug 28, 2015 7:47 am
- Forum: General Stuff
- Topic: What is the slowest part of 6502/65816 running C?
- Replies: 78
- Views: 12040
Re: What is the slowest part of 6502/65816 running C?
I think the banks system is also an issue .
I don't know if the 65816 can access directly of his full 24 bits addressing .
I don't know if the 65816 can access directly of his full 24 bits addressing .
- Mon Jun 29, 2015 9:14 am
- Forum: NESdev
- Topic: Unexpected "Good glitches"
- Replies: 23
- Views: 6826
Re: Unexpected "Good glitches"
No pure hazardousWait, damn. I thought it was just a high frequency sine (that has been done before precisely to get this kind of effect).
- Mon Jun 29, 2015 8:00 am
- Forum: NESdev
- Topic: Unexpected "Good glitches"
- Replies: 23
- Views: 6826
Re: Unexpected "Good glitches"
The bug was an uninitialized sine table .
Originaly, i wanted to do this :
https://youtu.be/vLUnXOm6o18?t=2m49s
Not really an hardware bug, but like Vectrex2809's one i think,a bug in his code,which did an unexpected effect.
Originaly, i wanted to do this :
https://youtu.be/vLUnXOm6o18?t=2m49s
Not really an hardware bug, but like Vectrex2809's one i think,a bug in his code,which did an unexpected effect.
- Mon Jun 29, 2015 3:28 am
- Forum: NESdev
- Topic: Unexpected "Good glitches"
- Replies: 23
- Views: 6826
Re: Unexpected "Good glitches"
Cool effect ..
i was in the same case, when i went to make a TF3 wavy fire effect .
The result is here :
https://www.youtube.com/watch?v=qsSsNe3RfSk
It runs at 60 fps .
i was in the same case, when i went to make a TF3 wavy fire effect .
The result is here :
https://www.youtube.com/watch?v=qsSsNe3RfSk
It runs at 60 fps .
- Wed Jun 24, 2015 12:59 am
- Forum: SNESdev
- Topic: Flaw in Ben Heck's 16 console wars video.
- Replies: 27
- Views: 7685
Re: Flaw in Ben Heck's 16 console wars video.
Excellent, and thanks for sharing the source code 
- Tue Jun 23, 2015 12:31 am
- Forum: SNESdev
- Topic: Flaw in Ben Heck's 16 console wars video.
- Replies: 27
- Views: 7685
Re: Flaw in Ben Heck's 16 console wars video.
How do you do that type of compression on planar tiles? Don't you need a whole lot of shifting? No lz4 is in fact more a simple bytes copy,you don't need to shift datas at all, this is why is so fast . you need to shift only the litteral length to retrieve the size of the litteral part to copy. Loo...
- Mon Jun 22, 2015 12:41 am
- Forum: SNESdev
- Topic: Flaw in Ben Heck's 16 console wars video.
- Replies: 27
- Views: 7685
Re: Flaw in Ben Heck's 16 console wars video.
If we talk about decompression, in Miniplanets I'm just streaming rafts and conveyor belts because I'm too lazy to make a software scrolling routine for them, but I also don't want them to eat up too much ROM space so I keep them compressed... meaning the game has to decompress the graphics on the ...
- Thu Jun 18, 2015 11:20 pm
- Forum: SNESdev
- Topic: Flaw in Ben Heck's 16 console wars video.
- Replies: 27
- Views: 7685
Re: Flaw in Ben Heck's 16 console wars video.
But would LZ4 on the Super NES handle planar tiles well? Yes i converted the lz4 for pcengine (with planar graphics too) and it compress very well for a real time decompressor, far better than RLE . Does Sonic decompress 128x128 rooms as it scrolls, or does it decompress all the 128x128 rooms at th...
- Thu Jun 18, 2015 11:46 am
- Forum: SNESdev
- Topic: Flaw in Ben Heck's 16 console wars video.
- Replies: 27
- Views: 7685
Re: Flaw in Ben Heck's 16 console wars video.
If your scrolling has become pattern update-bound, and the Genesis can decompress pattern updates faster, then the Genesis can scroll faster. Tiles decompression in sonic is about 3/6 tiles per frame, i don't think this is really incredible . With 128ko you can decompress most datas before starting...
- Thu Jun 18, 2015 12:43 am
- Forum: SNESdev
- Topic: Flaw in Ben Heck's 16 console wars video.
- Replies: 27
- Views: 7685
Re: Flaw in Ben Heck's 16 console wars video.
I agree with tokumaru, and the ability to scroll faster has nothing to do with the number of layers or colors on screen, because you rarely update 3 layers at 60 fps (or even 30), the 2nd and 3rd are rarely updated and wrap around in most case,but for sure you eat more VRAM .