Forums

Does anyone have good figures on what VDP transfer rates a tight assembly loop can achieve during VBlank?

I have a crazy idea...

http://www.smspower.org/forums/viewtopic.php?t=14599

You can do a lot better if it's not coming via the Z80, and slightly better if you don't need to read data from memory.

It would be cool to see a DMA device that could read from the fast on-cart flash, and write it to the VDP quickly within the timing limitations.

Charles MacDonald wrote

It would be cool to see a DMA device that could read from the fast on-cart flash, and write it to the VDP quickly within the timing limitations.

N*nt&nD@ had support chips; we can do it too! We can do it better! Haha!

No that wasn't my idea but still that would be pretty cool!

I read about the Graphic Board, and discussion of graphics limitations and realized the NES had a drawing app that let it (very slowly) draw a fullscreen bitmap (using a standard controller), but then I recall the reason even that was possible: because the NES required the tile memory to be present on the cart (rather than built in the console, like probably every other console ever created :D ) it was possible to expand the memory (though still subject to all the other limitations like number of colors).

I'd guess no such luck on MS?

Correct. In theory you could try to write to tiles that had already been displayed and reuse them later, but that still doesn't get you anywhere near enough tiles. You could use the legacy video modes but the disadvantages are quite severe.

Bitmap is indeed possible, if you don't do it fullscreen...

Charles MacDonald wrote

It would be cool to see a DMA device that could read from the fast on-cart flash, and write it to the VDP quickly within the timing limitations.

TmEE is working on such a device.

I cannot post a link but have a look on Sega 16 in the thread about reverse engineering the 6502.

db-electronics wrote

N*nt&nD@ had support chips; we can do it too! We can do it better! Haha!

Haha - yeah!!! Theoretically, could we even have a cartridge-based VDP upgrade to overcome lets say sprite limitations (8 on a scanline)?

You mean replace the VDP functionality with a new chip in the cart? I don't think so... and expand internal VDP hardware sprite limit I guess it's really impossible.

Why not implement a video chip that does overlays, then loop the host system video through... may as well put a faster CPU and more RAM in there too... let's call it a "32X"?

Then let's not develop but few titles for it...

Haha, I foresaw some witty comments here :) lets not forget that this thread is about VDP and "a crazy idea...".

I get the point, though. On a micro level I had these thoughts when building the arcade table: Not only the internal hardware, but also the old peripherals, are part of the SMS experience, in all its limitations and glory.

hang-on wrote

I get the point, though. On a micro level I had these thoughts when building the arcade table: Not only the internal hardware, but also the old peripherals, are part of the SMS experience, in all its limitations and glory.

Yes I completely agree, limitations are definitely part of the experience! I'm studying different applications and upgrades for my Power Base Converter series.

Author	Message
db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Typical Data Bandwidth to VDP During VBlank Posted: Mon Oct 06, 2014 12:12 pm
	Does anyone have good figures on what VDP transfer rates a tight assembly loop can achieve during VBlank? I have a crazy idea...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Oct 06, 2014 5:22 pm
	http://www.smspower.org/forums/viewtopic.php?t=14599 You can do a lot better if it's not coming via the Z80, and slightly better if you don't need to read data from memory.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Mon Oct 06, 2014 9:57 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	It would be cool to see a DMA device that could read from the fast on-cart flash, and write it to the VDP quickly within the timing limitations.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Tue Oct 07, 2014 3:25 am
	Charles MacDonald wrote It would be cool to see a DMA device that could read from the fast on-cart flash, and write it to the VDP quickly within the timing limitations. N*nt&nD@ had support chips; we can do it too! We can do it better! Haha! No that wasn't my idea but still that would be pretty cool!

KingMike Joined: 14 Oct 2008 Posts: 513	Posted: Tue Oct 07, 2014 5:41 am
KingMike Joined: 14 Oct 2008 Posts: 513	I read about the Graphic Board, and discussion of graphics limitations and realized the NES had a drawing app that let it (very slowly) draw a fullscreen bitmap (using a standard controller), but then I recall the reason even that was possible: because the NES required the tile memory to be present on the cart (rather than built in the console, like probably every other console ever created :D ) it was possible to expand the memory (though still subject to all the other limitations like number of colors). I'd guess no such luck on MS?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Tue Oct 07, 2014 7:24 am
	Correct. In theory you could try to write to tiles that had already been displayed and reuse them later, but that still doesn't get you anywhere near enough tiles. You could use the legacy video modes but the disadvantages are quite severe.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Oct 07, 2014 7:58 am
	Bitmap is indeed possible, if you don't do it fullscreen...

CMcK Joined: 23 Jan 2013 Posts: 20 Location: Scotland	Posted: Tue Oct 07, 2014 8:52 am
CMcK Joined: 23 Jan 2013 Posts: 20 Location: Scotland	Charles MacDonald wrote It would be cool to see a DMA device that could read from the fast on-cart flash, and write it to the VDP quickly within the timing limitations. TmEE is working on such a device. I cannot post a link but have a look on Sega 16 in the thread about reverse engineering the 6502.

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Tue Oct 07, 2014 1:32 pm
	db-electronics wrote N*nt&nD@ had support chips; we can do it too! We can do it better! Haha! Haha - yeah!!! Theoretically, could we even have a cartridge-based VDP upgrade to overcome lets say sprite limitations (8 on a scanline)?

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Oct 07, 2014 1:39 pm
	You mean replace the VDP functionality with a new chip in the cart? I don't think so... and expand internal VDP hardware sprite limit I guess it's really impossible.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Tue Oct 07, 2014 2:19 pm
	Why not implement a video chip that does overlays, then loop the host system video through... may as well put a faster CPU and more RAM in there too... let's call it a "32X"?

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Oct 07, 2014 2:30 pm
	Then let's not develop but few titles for it...

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Tue Oct 07, 2014 3:35 pm
	Haha, I foresaw some witty comments here :) lets not forget that this thread is about VDP and "a crazy idea...". I get the point, though. On a micro level I had these thoughts when building the arcade table: Not only the internal hardware, but also the old peripherals, are part of the SMS experience, in all its limitations and glory.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Oct 10, 2014 4:27 pm
	hang-on wrote I get the point, though. On a micro level I had these thoughts when building the arcade table: Not only the internal hardware, but also the old peripherals, are part of the SMS experience, in all its limitations and glory. Yes I completely agree, limitations are definitely part of the experience! I'm studying different applications and upgrades for my Power Base Converter series.

Forums

View topic - Typical Data Bandwidth to VDP During VBlank