Mark McDougall has ported Lode Runner from the MSX computer (another Z80-based micro) to the TRS-80 Model 4/4P with MicroLabs Grafyx Solution hires board.


Mark McDougall           ( )  
    11 , 13:16  

 : comp.sys.tandy
: Mark McDougall <msmcd...@no.spam.iinet>
: Thu, 11 Feb 2010 22:16:23 +1100
 : . 11  2010 13:16
: [ANNC] Lode Runner for TRS-80 Model 4
 |  |   |   |     |      
Greetings all, 

I was going to hold off until I could get this tested on a real TRS-80, but 
at this stage I'm not sure when that will be, and there's no real reason not 
to release a "beta" version that people can test anyway. 


For years now new games - even cartridges - have been developed for the 
Atari 2600, C64, Spectrum and even the ZX80/81. The good old TRS-80 has been 
forgotten completely - until now. 


I'm pleased to announce a "new" game for the TRS-80. I have managed to port 
Lode Runner from the MSX computer - another Z80-based micro - to the TRS-80 
Model 4/4P with MicroLabs Grafyx Solution hires board. It may even work with 
the RS hires board - I'm not sure. 


Anyway, you can read about it in excrutiating detail, and download a DSK 
image of the game, on my website. 
<http://members.iinet.net.au/~msmcdoug/lrmsxtrs/index.html> 


Enjoy, and feel free to post/email any comments/bug reports. 


Regards, 


-- 
|              Mark McDougall                | "Electrical Engineers do it 
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!" 


Hi Mark, 

wow! That's cool! The game runs 1a on my xtrs. Really impressive! 


Cheers, 
_ralf_ 


Hi all, 

It was reported a week or two ago that Lode Runner does not run properly on 
a real TRS-80. 


After some consideration, aided in no small part by my reverse-engineering 
of the Grafyx Solution Hires Board, the likely cause has become quite 
apparent to me. 


It is due to 2 related factors: 


(1) During the active display, the hires board will halt the CPU on any 
access to video memory, until the next horizontal or vertical blanking period. 


(2) Because the RTC interrupt is asychronous to the vertical retrace on the 
TRS-80, the code cannot take advantage of uninterrupted (fast) access to 
video memory during the vertical blanking period, as it can on the MSX. 


As a result the ISR, which updates the sprites at 60Hz, spends most of its 
time with the CPU halted when it needs to be emulating sprites. I've yet to 
profile video I/O during retrace but there's obviously a very limited video 
bandwidth, and it all really needs to be done well inside 16.7ms (60Hz) 
because the main-line code also needs time to run between interrupts. 


I've had an idea or two about how to optimise the sprite emulation to 
minimise the effects of halting the CPU. In a nutshell, the sprite code 
needs to effectively "pre-render" all 6 sprites in memory and then "blit" 
them to the screen in contigious chunks (as far as possible). 


I still don't really have much of an idea if this will be sufficient to run 
properly on a TRS-80. The worst-case scenario is that the RTC interrupt 
coincides with the start of active video, and the cpu is halted for much of 
the ISR. Without a true VBLANK interrupt, I fear there's not enough video 
bandwidth to run the game properly. 


I will endeavour none-the-less to get it running on a real machine if 
possible. I should also note that the original graphics are actually doubled 
horizontally; thus the video bandwidth is actually twice that required for a 
1-to-1 pixel implementation of the MSX version. Maybe reverting to 
single-width and running in 512x192 mode would be more suitable? 


BTW this is not a problem on software emulators because they do not need to 
halt the cpu during "active video display", principally because the hardware 
is not emulated at this conceptual level. Indeed, my FPGA implementation 
also avoids this problem because it uses dual-port RAM. But I digress... 


Lastly, FWIW I am designing the Grafyx Solution repro board with a VBLANK 
interrupt output which can *optionally* be connected to the EXTBUSIO# line 
on the Model 4 expansion connector. Obviously using it requires enhanced 
software that won't run on a legacy Grafyx Solution. 


Regards, 


