Posting a new thread for this topic as BigEd suggested, since my original topic in Newbies was getting incredibly long and cluttered.

I'm in the process of building a 65c816 based system with video/audio sub systems to support some classic games. I'd love to get DOOM running on this system, to continue the tradition of porting DOOM to every computer system ever to exist.

I'd like to discuss some possible roadblocks in this, and pose the outlines of what capabilities I'm planning for this system to give a general idea of the processing capability it will have.

Presently, I'm planning:
4-8MB + 32k RAM
a cartridge slot with 4 GPIO (off a VIA) and 6 slave selects for SPI comms (off of 65SPI)
a video daughterboard powered by the VLSI vs23s010 datasheet
a sound card powered by the VLSI VS1000 datasheet (and possibly a daughterboard for audio signal generation (mostly for midi, but could be used for this)
16Mhz clock, hopefully pushing up to 20Mhz if possible.

This is probably a monumental task that will take a while, hopefully we can get some good information going here for the next guy crazy enough to try this.

EDIT: original thread

The first thing I would check is the video bandwidth. Start with rough calculation, and if that seems okay, try a single texture mapped polygon at full screen size.

I think with the current video chip I'm looking at, the bandwidth should be manageable. NTSC/PAL standards are pretty low res, and I don't think they even carry 24 bit color (I think it's 16 bit). I'll see about getting some calculations in just a bit, after I confirm some info on the chip

Looks like it's been done:https://www.doomworld.com/forum/topic/66801-doom-out-on-commodore-vic-20/

Sweet! This may be easier than I thought, looks like there version isn't quite the original though, maybe I can get closer to the original running on it?

So going off of this the resolution we'd be looking at would probably be the first.

It comes out to 30.4Mb/s of bandwidth, but that's if we were feeding all frames directly. The VLSI chip has its own RAM and supports operations like block move and scrolling. If we load all the textures we can into the SRAM and move them from there, it gets significantly easier.

I'm going to bullshit some numbers here, just to get some thoughts going

I'm making an educated guess that most textures in DOOM are 32x32 pixels.

let's say we have 10 wall, floor, and ceiling textures per level, for a total of 30 textures for our "3D" objects (2.5d really).
Let's also say we have a large texture for the hud, maybe 128x128
And we need to throw in some character sets for displaying information, if we give each character 16x16, and only do numbers and letters (and we'll say a couple symbols, like %) we end up with about 40 characters

adding all this together, and assuming 16 bits for color (since the memory is organized x8 I believe) we end up with 67,584 bytes for all the textures in a particular level.

The VLSI has about 128k of RAM, so we can fit this into that comfortably, and I believe you can tell the chip to use a certain area of memory as the display section, and other areas are able to store textures or other garbage you may need in it.

This means we may not need to swap textures in and out of the chip at all during game play, which makes this task quite a bit easier, since we'll only need to calculate texture movements and send those as block move commands to the chip.

The VIC-20 version isn't really a port. The SuperCPU version however is a direct C source port to the 65816, running genuine WAD files. It might even render internally to a 256-color buffer and downsample the color into c64 bitmap modes as a postprocessing step.

It's a proof of concept for a cross-compiler chain, so it seems only functionality has been worked on, not speed.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Textures have to be 3D mapped, though.

Since the video chip is only a framebuffer with non-scaling block moves (from a quick skim), it can't assist in rendering the 3d environment, so none of those textures need to be on-chip. The UI elements however don't have any scaling applied, and could be block copied. The player's held weapon is a large sprite that usually isn't scaled, but if you shrink the render window, it needs to shrink along with it, so it still needs to be CPU-drawn unless you want to specialize the case of 100% render window size (edit: um, that's only if the block copy can have a transparent color, which it might not).

I don't think that DOOM does any reads from the framebuffer, so if you can find a video mode that can squeeze in double-buffering into the 128K, you can just do blind writes to the back buffer for the render window and flip, avoiding a separate system RAM->VPU copy. However, if writes going to the video chip are going to slow down the CPU, then handling all of the overdraw (which isn't all that much due to BSP: only the scaled sprites incur overdraw) might be considered if it's worth doing CPU overdraw and copying the final frame to the video chip.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I'm not sure how much writes are going to slow down the CPU, they'll be going through the 65SPI, and I've not read if it has any kind of buffer yet (although I believe it doesn't).

Since it can't be block moved (because of scaling) it may be worth looking at a separate solution for rendering, I'm worried that scaling all of that may eat up too many CPU cycles. (although maybe not, if properly culled)



This is interesting, being a direct port, I'll need to read on this and see if I can possibly work from it and just work on optimizing the port.