https://robhagemans.github.io/pcbasic/ is a GPL3-licensed implementation of the BASIC language this game is written in. PC-BASIC is written in Python. Supposedly it can run this game, although I haven't tried it.
A couple of interesting features of the game (quotidian to those of us around at the time, but...)
1. The "PLAY" statement is barely used; the sounds are mostly done with the SOUND statement, maybe in part because they are being generated randomly. In fact it seems to be used only to verify that the program is being run on a BASIC interpreter that supports "advanced" features like DRAW.
2. The "DRAW" statement, which has its own mini-language similar to that of the "PLAY" statement. Later these were dubbed "Graphics Macro Language" and "Music Macro Language", even though neither one allows you to define macros. This is used to include vector graphics of the donkey and the racecar in the program, in the subroutines on lines 1940 and 1780, respectively. But the interpretive rendering of these vector graphics (and especially the flood fills, lines 1900 and 2010) was too slow to want to do it every frame; instead it's done at program startup (into an on-screen buffer, since that's the only way to do it in GW-BASIC or BASICA; you can see the painting happen briefly before the game starts) and stored in the arrays CAR% and DNK% with GET statements, later to be PUT onto the screen in the right place each frame. There's a bit of sloppiness there: CAR% is DIMmed right there in the subroutine on line 1910, while DNK% is DIMmed up at the top on line 1470. (And the sprites for the halves of the donkey and car are dimmed there too, along with a planned sprite called Q% which is never used.)
3. There's actually an additional sprite, B%, which isn't set up with a GET statement; it's filled in "by hand" to a simple fill pattern on lines 1510–1530. My memory was saying that the data format of this array was undocumented, but it does seem to be documented in http://www.antonis.de/qbebooks/gwbasman/, which I'm pretty sure is the actual GW-BASIC manual from Microsoft. Anyway, B% is a vertical line that's getting XORed into the framebuffer (the default PUT raster op was to XOR into the framebuffer, violating patent 4,197,590 if you use it for a cursor) to make the stripes down the middle of the road "move".
4. See how AND is being used as a bitwise operator? That's why true was -1 in MBASIC.
I think there are some important lessons in GW-BASIC/BASICA about how to design user interfaces for end-user programming, and the DRAW and PLAY statements in particular. Also, I can't have been the only person who never figured out how to use the vi-like line editor in BASIC-80 but who edited existing code all the time in Z-BASIC/GW-BASIC/BASICA because I could just use the arrow keys.