Neat! I think that's what I (and I think John as well) do on a 'real' M100, with a parallel>serial converter sending print output to a terminal log.
Useful for other things as well. m ----- Original Message ----- From: "Ken Pettit" <[email protected]> To: <[email protected]> Sent: Saturday, May 06, 2017 8:24 PM Subject: Re: [M100] Game idea > Hi all, > > One other note to anyone who uses VirtualT to help write / debug BASIC > programs. I discovered that using the BASIC LPRINT command is really > useful for debugging. You can use it one of two ways. > > The first is to configure the LPT port to connect to a virtual FX-80 > using Virtual Paper and then "print" you debug output at any time. This > will only show your debug output when you select "Print Now" from the > pop-up printer menu by clicking on the printer icon in the bottom window > border. > > The second (more useful) way is to use either socat on Linux/Mac or > com2com on Windows to create a virtual null-modem serial-to-serial > connection. Then use minicom (Hyperterm for Windows) to connect to one > of the ports and then configure LPT to connect to a Host device, > specifying the other serial port. In this case, you get a real-time > logging window of your debug info as printed by your LPRINT statements > in the BASIC code. > > Ken > > On 5/4/17 6:31 AM, Bob Pigford wrote: >> Mahjong. Right? >> >> -----Original Message----- >> From: M100 [mailto:[email protected]] On Behalf Of Ken Pettit >> Sent: Wednesday, May 03, 2017 7:00 PM >> To: Model 100 Discussion >> Subject: [M100] Game idea >> >> Hey gang, >> >> After integrating AsciiPixels into TextSweeper, it got me thinking about >> another game idea using AsciiPixels. I spent a few hours coding up a BASIC >> program on the T200 (using VirtualT) to get an idea if it would work / how >> it would look. It could be coded for M100 also by scrolling and showing >> only half of the screen (upper or lower) at a time. >> >> Written in BASIC, it is a bit slow, but was okay for "proof of concept". >> Plus BASIC doesn't require 2x the RAM like .CO files to (one copy for the >> .CO and another for the HIMEM location where it gets loaded). Maybe a full >> .CO implementation is the way to go? Currently the implementation has only >> the ability to build and display the board and no logic for choosing or >> removing pieces. Also, the board build logic is purely random with no >> attempt to add game theory for determining if there is a winning solution. >> This would all need to be added. The BASIC program is currenly 42 lines >> long (with multiple statements per line) and is about 2K in size, plus >> another 1300 bytes for AsciiPixels resources in a separate .DO file. >> >> Anyway, I though I would share a screen capture of what I have and see if >> there is any feedback on interest level. And yes, I intentionally didn't >> say what type of game so that you can discover it by watching the >> video: >> >> http://www.kenpettit.com/tj.mov >> >> Let me know >> Ken >>
