I don't know how taxing wire frame 3D is compared to polygons...
Wireframes are easier, if you don't mind background wires showing through. It gets a bit harder if you want them erased - at that point, it's not much different from a black-filled polygon.
I'm assuming that they should be able to do some decent wire frame stuff.
Possibly, assuming you don't need a high frame rate.
In one test Arkhan and I did (for the vines in junglehunt), we managed to get 5 lines moving before hitting the frame time limit. The problem is that the pce has a 4-plane BG layer, so drawing 1 dot involves 4 read/update/write cycles. Add in the need for floating point math (faked or not), and you can see it's a problem.
Not saying impossible, but it looks like it would take a hell of a lot of optimization to get anything above about 15 fps for more than a dozen or so lines....
If it's wireframe and you don't care about different colors, you can setup the VDC for 1bit bitmap. You write/use the 1bit frame buffer in main ram, then you blit it to vram. But vram tiles need to be setup in a
specific order. And the vram increment pointer needs to be set to 32. It's true that you need to write a whole WORD to the vram port at a time, but the latch is only on the
MSB port. Just write a zero on the
LSB port
once at the very first write (or whatever value you want to
repeat), and only write to the
MSB when copying the rest of the 1bit frame buffer data. Instant scanline blitting. You can either update the vram pointer at the end of every bitmap 'scanline' transfer
or let it wrap on to do 1 scanline writing per 8 high block area, doing 8 passes total (each pass writes scanline Y of an 8 high pixel group in the pseudo tile arrangement bitmap in vram). And since you're only using the first two bits of the tile (and one plane you don't even write to, so it's a free cycle to update), you can uses the other 2 bitplanes to hold a crude/low color BG image that the poly lines overlay onto. It's very complex to setup, and probably difficult understand (you have to keep your head constantly wrapped around it), but once you do both - you'll see that you have do a ton of stuff you can do (you also have the option of making the wire frame overlay translucent over the other 2bit planes or not). You could take the slower route, 1bit frame buffer and 3bit tile graphics, but it requires you write the 1bit frame buffer data to the LSB and read the MSB and write it back to the MSB. So, quite a bit slower - but more colors and still the ability for translucency (don't forget you can still apply subpalettes to the tiles to make the underneath buffer more than just 8 colors. I've done many of private demos/tests messing around with this kind of stuff).
You could use sprites in the same fashion and it's a little easier too (setup wise), but that's a waste since you'd probably want some movable sprite ability. Of course stock ram isn't much for holding a working frame buffer. 240x200x1bit is 6000bytes, leaving only 2192bytes left over on a stock hucard (without cheating and using the Populous hucard setup with its extra 32k of ram on chart). That's pretty tight, but doable.
