Hardware Resources

[MooZ]

• Pinouts
  • Expansion Connector
  • HuCard
  • HU 6260
  • HU 6270
  • HU 6280
• Pad
  • Emanuele Bettidi's
    • Turbo Pad
    • Avenue Pad 3
    • Avenue Pad 6
    • Avenue Pad 6 (without rapidfire)
  • Gamesx
  • NFG controls
  • Cyber Stick
  • Micomsoft XE-1 AP
    • page 1-2
    • page 3-4
• Misc
  • Power supplies
  • RGB mod/cable/amp

Does anyone have some schematics for the tenokoe2 and the memory base 128?

[Gravis]

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]

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 .

[tomaitheous]

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]

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]

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

[TOUKO]

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 ..