Hardware Resources

hu, cd, scd, acd, supergrafx discussions.
Post Reply
User avatar
MooZ
Site Admin
Posts: 389
Joined: Sun Jun 22, 2008 3:19 pm
Location: Lvl 3
Contact:

Hardware Resources

Post by MooZ » Sat Jan 16, 2010 8:45 pm


User avatar
Gravis
Kitten Blaster
Posts: 79
Joined: Sun Jun 22, 2008 3:52 pm
Location: Deadman Wonderland

Re: Hardware Resources

Post by Gravis » Mon Jan 30, 2012 6:58 am

There is now a lot of information about the PCE hardware here.

it has information about everything from HuC6280 to the 74163 IC which is used for the "turbo" buttons.

Archaicpixels.com is the PC Engine / TurboGrafx-16 compendium!

TOUKO
Posts: 41
Joined: Mon May 25, 2009 5:37 pm

Re: Hardware Resources

Post by TOUKO » Tue Jul 15, 2014 2:31 pm

Some good informations on archaic, but some errors too ..

I don't understand how works the burst mode .
As i understood in archaic's tech docs, burst mode is enabled by VDC when the TV beam is in the overscan area .
In burst mode the CPU has unrestricted access to VRAM, huuum, i always thought that the CPU have a "quasi" unrestricted access all the time .

Burst mode seems to be like over systems for me, transfering datas in VRAM must be in vblank, and not in active display .

An error too on DMA CONTROL REGISTER, is the bit 4 for enable/disable the VDC DMA auto transfert to VRAM -> SATB and not the bit 5 .
Last edited by TOUKO on Wed Jul 16, 2014 7:31 am, edited 1 time in total.

tomaitheous
Posts: 88
Joined: Mon Jun 23, 2008 1:58 pm

Re: Hardware Resources

Post by tomaitheous » Tue Jul 15, 2014 10:40 pm

The VDC has more CPU vram access slots during active display, then what the cpu can saturate. But if there's a slight out of alignment, the cpu will be stalled for a 'master clock' time slice. Of course, that's on the latch (MSB) and there's ~supposed~ to be a 1 word buffer as well. So to the programmer, this appears as unlimited access. The only real thing that can stall the CPU, is during hblank. The VDC can use all access slots to fetch sprite pixel data (IIRC it lasts about 16+ vdc pixels; it's relative to amount of sprites it's fetching for that scanline). If you touch 'vram' during this phase, the cpu will be stalled/halted. This does not apply to VDC registers; you have unlimited access to those without stalling.

Burst mode is where the VDC is not fetching sprite data or bg/map data. You cannot forcibly put the VDC in this mode by disabling sprites/bg layers; that disables the output but not the internal fetching process. And, IIRC, burst mode is the only area in the display(frame) where you can request vram-vram DMA (and satb-dma).

TOUKO
Posts: 41
Joined: Mon May 25, 2009 5:37 pm

Re: Hardware Resources

Post by TOUKO » Wed Jul 16, 2014 7:30 am

Thanks tom, i understand now .

But i think puting datas in vram in burst mode is not really faster than in active display, because the CPU cannot benefit of all BW, right ??

tomaitheous
Posts: 88
Joined: Mon Jun 23, 2008 1:58 pm

Re: Hardware Resources

Post by tomaitheous » Sat Jul 19, 2014 4:18 am

That's what my tests showed. I did writes to vram (ST1/2 opcodes), incremented a counter, and used the Timer interrupt to measure this for active display VS vblank area. I saw no difference in speed. Even with ST2 opcodes (writes to MSB only), the cpu can't saturate all the access slots of the VDC per 8pixel block (even in slow 5.37mhz dot clock mode). The VDC is too fast for the CPU :lol:

TOUKO
Posts: 41
Joined: Mon May 25, 2009 5:37 pm

Re: Hardware Resources

Post by TOUKO » Tue Jul 29, 2014 4:24 pm

Yes if docs on archaic are right, the VDC read/write on vram seems to be close to 1 MS / byte , it's really fast ..

A ram/rom -> VRAM DMA could be great ..

Post Reply