I recently learned that 16K x 1 DRAM with built-in substrate bias generator exist. Mostek MK4516 are pin-pin compatible with 4116 DRAM but require no negative supply rail (pin 9 is no-connect). If can find 8 of these devices, you can use them in the original configuration found in the VDP datasheet.

Is it possible to use 74LS573 instead of 74LS574?

I suspect not, they are level sensitive and edge-triggered latches respectively. But you can use a 374, since the 573 (574) are just 373 (374) with friendlier pinouts.

I once put a 374 instead of a 373 by mistake in a design and scratched my head for a while. Fortunately on breadboard.

Short answer: no, they ALL need to be positive edge triggered FF’s  (‘374, ‘574, a raft of ‘74s, etc...)

Reason; Substituting a level triggered latch (‘573, ‘373, etc) for the ROW would not work, because the RAS pulse remains low for the entire cycle. This would result in the ROW latch being ‘transparent’ the entire cycle, and the row potion of the address will be overwritten by the column address info, followed by the data info. The lower order address lines to the SRAM would be Incorrect by the time the read or write actually took place!

A similar situation prevents using a level triggered latch for the COL - the column portion of the address would be overwritten by the data info. So, in this case the higher order address lines would be unstable. 

The write data register needs to be edge triggered because the write data setup and hold times are relative to the falling edge of RW. It’s not clear if the write data is stable throughout the duration of the write pulse. The TI timing diagrams seem to imply that it’s not. In this case, a level sensitive write data latch would end up providing corrupted data for the SRAM to write. 

Caveat; okay, for the sake of completeness, you COULD use level sensitive latches IF you add additional circuitry to create brief positive ROW and COL and WR pulses from the falling edges of RAS, CAS, and R/W, respectively. But, that’s more effort (and parts) than simply using positive edge triggered FF in the first place!

Hope this explanation was helpful!

I worked out these VDP-SRAM timing nuances in 2010 while collaborating on the N8VEM Z80 retrocomputer project. I was never successful in getting good RGB or YPbCr out of the TMS9928, however. It’s a shame that composite video has become so inconvenient to use these days. I’m waiting for an open source VGA output VDP work-alike implemented in VHDL to include in future projects...

It took five months of work, but we finally got good RGB out of the TMS9928A (while keeping everything analog) over in the Colecovision sub-forum at AtariAge.  The solution is open-source and is called TMS-RGB.  It's a little board you solder right onto the bottom of the VDP.

Wow!  Great work there!  I tinkered with trying to coax component video and RGB out of the 9928 but eventually gave up because it was too "touchy" and required frequent readjustment (temperature sensitivity was very poor).  Can you tell me if modern VGA monitors (e.g. LCD) will work with the scantimes that the 9928 generates?  For me, this was always the next problem to face, after somehow getting RGB output...

I have a project which may be of interest in that regard, although it is using Yamaha V9938/9958 VDPs: https://hackaday.io/project/178481-msx2-video-to-vga-conversion-proof-of-concept

This is interesting indeed.  I have a V9938 chip that I never did anything with. I seem to recall that the V99xx series allowed access to the internal color bus?  If my recollection is correct, it seems to me that it would be easier to simply access the color bus directly, rather than digitize the analog RGB outputs?   Also, it would neatly sidestep the 8-color limitation you face now. Curious to hear your thoughts on this idea?

(This is a reply to your Apr-1-2021 comment, which doesn't seem to have its own "reply" option for whatever reason.  Did we reach the comment nesting limit?)

As far as I've heard, no one has tried it in a VGA-out style configuration.  The separate H- and V-sync are generated by one of the ICs on the board, but only C-sync was included in the easy-to-reach outputs.  All the uses I've seen from others have been with line-doubling or other upscaling hardware (OSSC, Framemeister, Rad2X cable, etc.).  I'd also be curious to know how it fared with a VGA monitor.  Sorry for not having a better answer!

No worries on not knowing the answer!. I suspect that line doubling is still required for most (if not all) VGA monitors, unless some monitor manufacturer went out of their way to allow the sync circuit to work with the old "TV style" line and frame rates. 

I'm working on-and-off on a project using a uPD7220 Video Display Processor, a MAX II CPLD, and an SRAM to produce a VGA mixed-text + graphic display output. That device is capable of working at VGA (640x480) resolution natively, and the built in hardware acceleration stuff is pretty neat. Sadly, it's nowhere near as cool as the TMS99xx or V99xx chips...

I played a bit with this VDP too, nostalgic for the old days with my TI-99/4A: http://obex.parallax.com/object/864

Just wondering if you've seen #rc9918, which is a very similar project?

Yes, it's based upon the circuit here - I developed this back in 2010, and the writeup lived in various places on the internet since then. I thought that there might be enough general interest in this technique that I would document it here on Hackaday to reach a wider audience.  I am happy that this technique I worked out more than a decade ago still generates so much interest :-)