The resolution of PMODE2 which is the maximum resolution the TRS-80 MCX can handle, is bit courser than the 256 horizontal resolution of the MSX standard (which Nanochess converted the Apple source to). However, it might be closer to what things look like on the original Apple version, which I think was something like 180X192, with the bottom 4 rows reserved for text.
PMODE2 halves the 256 horizontal resolution, so you have 128X192. However, every graphic command still uses the 256X192 resolution for plotting purposes, so I didn't have to convert the resolution of any of the commands from Nanochess's version. I just had to add a few color numbers, which are not just assumed to be a certain default if not specified.
As Darren Atkinson points out about the limits of graphics on the MC-10:
Three of the 6847’s graphics modes are now available from Basic. Unfortunately, Tandy’s decision to limit the internal RAM to 4K means that modes RG6 and CG6 (aka PMODEs 3 and 4) can’t be displayed without wrap-around. For this reason, MCX Basic supports only RG2, CG3 and RG3 (aka PMODEs 0, 1 and 2). Although the maximum horizontal resolution in these modes is 128 pixels, MCX Basic has adopted the Extended Color Basic convention that all modes are addressed using horizontal coordinate values from 0 to 255 and vertical coordinate values from 0 to 191. These values are then scaled to fit the actual 128 x 96 or 128 x 192 screen size for the current mode.One additional compromise made in the MCX version is that snow can appear on screen in the RG3 (PMODE2) resolution. As Darren mentions:
A timing problem in the MC-10 can cause modes 0 and 2 to produce a very noisy display. This depends on whether the VDG syncs with the rising or falling edge of the clock.So any of you folks who run this program on real hardware, you might have to switch your machine on and off a number of times before you get the right timing. Darren had a similar problem with his M/L Asteroids and provides these helpful instructions to work around the problem
ASTEROIDS for MC-10 When playing on a real MC-10 the monochrome graphics mode used for this game may display random sparkles on the screen. This is due to a defect in the design of the MC-10 hardware.
There is a 50% chance that the problem will occur and it depends on which edge of the clock the video chip synchronizes with when the computer is powered on.
You may want to check if the problem will occur before loading the game. You can preview the graphics mode by entering the command:
If you see a lot of random white pixels moving across the entire screen then you should turn the computer off for several seconds and try again.
When the screen is mostly stable (just 2 or 3 rows where the pixels appear to be changing), press the RESET button to get back to the normal text screen. Then enter CLOADM to load the game and EXEC to run it.
Follow a similar procedure for AKALABET, or just consider the sparklies to be "dust" falling from the dungeon's ceiling or snow from the sky (i.e. treat it as an atmospheric feature, rather than a bug:). It's just one of those limitations that one has to deal with in a beloved machine. At least it won't be a problem when I port to the Coco as all its graphics modes work properly. I haven't been able to locate my cable for plugging in my MC-10 to the RS232 port of my PC so I haven't been able to see the game on real hardware yet. So many cable all stored in vast knots in my basement and attic...