_NetNomad

i think you’re mixing up a few different things here. beam-racing was really only a thing with the 2600 and stopped once consoles had VRAM, which is essentially a frame-buffer. but even then many games would build the frame in a buffer in regular RAM and then copy everything into VRAM at the vblank. in other cases you had two frames in VRAM and would just swap between them with a pointer every other frams. if it took longer than one frame to build the image, you could write your interrupt handler to just skip every other or every three vblank interrupts, which is how a game like super hang-on on the megadrive runs at 15 FPS even though the VDP is chucking out 60 frames a second. you could also disable interrupts when the buffer was still being filled, which is how you end up with slowdown on certain games when too many objects were on the screen. too many objects could also lead to going over the limits of how many sprites you can have on a scanline, which is why things would vanish- bit that is it’s own seperate issue. if you don’t touch VRAM between interrupts then the image shown last frame will show this frame as well

COBOL is still being updated because, believe it or not, people are still writing COBOL

Unlike other older languages, such as Cobol and Fortran – which are still used, but almost always in legacy projects – Java has constantly evolved to meet new demands while maintaining backward compatibility.

can’t speak on the FORTRAN claim but with COBOL this couldn’t be less true. last i checked the newest Enterprise COBOL LTS is newer than Java’s