They might be tile based systems, but you can setup the tiles in such an arrangement - that you make a pseudo bitmap. Depending on how many unique tiles/cells the systems can show, is how large your bitmap/pixelmap can be.
The usual method (because most older systems don't have full access to vram during active display), is have a buffer of the bitmap in local ram. Once you draw what you need to that buffer, you then upload it to vram. If the bitmap size/window is large, it might need to be updated across a few frames. If this is the case, then you usually want to have two spots in vram to 'double buffer' the image. I.e. So you don't get tearing or partial screen update artifacts.
That aside, you still need to deal with the logic of the bitmap itself. Most older systems are planar format (with the exception of the Genesis, which are linear pixels), which can make it a pain to do certain things (types of drawing/plotting/compositing). The 16bit era systems have 4bit pixel graphics, so the tendency is to leave the whole bitmap in 4bit pixel format (else you get attribute clashing). SNES has two 8bit pixel modes available, but really limits the size of the bitmap window due to using double the vram space (and the option to do double buffering). Then there's the issue of bitmap in local ram has to be in 'tile' format. That slows things down. Some Genesis games optimize the bitmap in local ram as 'columns' of 8 pixels wide. That works well rendering stuff on a vertical level (like a raycaster engine).
That's the basic idea of it.