Re: [M100] Game idea - Tapper / Walnut Bowling

2017-06-20 Thread Lee Olivares
Sounds cool, start with some graph paper mockups of the game play action
and screens, then start coding up some basic!

On Fri, Jun 16, 2017 at 10:36 AM, Jim Williams  wrote:

> I was thinking that a tapper-like game might be doable on the M100,
> suiting its wide screen.
>
> Then the other day I was playing Plants Vs Zombies, doing one of the
> miniquests; "Walnut Bowling".
>
> You start on the left side of the screen releasing walnuts. Zombies
> attack from the right side of the screen.
>
> There are... I dunno... 8 lanes, maybe? You bowl the Walnuts down to
> take out the zombies. The nut ricochets around taking out multiple
> zombies, sometimes.
>
> I have a feeling that could be adapted to a game for the M100...
>
>
>


-- 

 - Lee
 - 909.437.0250
 - Destroying technology problems.


[M100] Game idea - Tapper / Walnut Bowling

2017-06-16 Thread Jim Williams
I was thinking that a tapper-like game might be doable on the M100, 
suiting its wide screen.

Then the other day I was playing Plants Vs Zombies, doing one of the 
miniquests; "Walnut Bowling".

You start on the left side of the screen releasing walnuts. Zombies 
attack from the right side of the screen.

There are... I dunno... 8 lanes, maybe? You bowl the Walnuts down to 
take out the zombies. The nut ricochets around taking out multiple 
zombies, sometimes.

I have a feeling that could be adapted to a game for the M100...




Re: [M100] Game idea

2017-05-11 Thread Kenneth Pettit
Hi John, 

I just now saw this email (it had been filtered into a different folder).

Thanks.  My idea for M100 was to show top half / bottom half like you 
suggested. 

I suspect the code is spending a fair amount if time in AsciiPixels asm, but 
probably equal or slightly more in BASIC trying to figure out where to draw 
shadows an in the BASIC LINE routine actually drawing them.

Ken

Sent from my iPhone

> On May 3, 2017, at 4:22 PM, John R. Hogerhuis  wrote:
> 
> Wow, nice graphics!
> 
> As to M100, I think scrolling would be a pain, but maybe just a toggle top 
> half, middle (showing bottom of top half and top half of bottom), bottom half.
> 
> CO or BASIC... well CO files usually take double space anyway. But it would 
> be faster I guess. But your demo probably spends most of its time in 
> AsciiPixels machine code, no?
> 
> -- John.


Re: [M100] Game idea

2017-05-06 Thread John R. Hogerhuis
Good ideas!

When I was doing HTERM testing with a real laptop I had a parallel to
serial converter and then the serial converter was wired to an hp serial
analyzer which had a bigger composite monochrome monitor attached to it so
I could see the debug trace live.  How's that for Rube Goldberg-ian

I was toying the other day with what a BASIC debugger would look like. That
would be nice too.

-- John.


Re: [M100] Game idea

2017-05-06 Thread Mike Stein
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" <petti...@gmail.com>
To: <m100@lists.bitchin100.com>
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:m100-boun...@lists.bitchin100.com] 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
>>


Re: [M100] Game idea

2017-05-06 Thread Ken Pettit

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:m100-boun...@lists.bitchin100.com] 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





Re: [M100] Game idea

2017-05-04 Thread Ken Pettit

Hi Bob,

Correct.  Or perhaps TJONG :)

Ken

On 5/4/17 6:31 AM, Bob Pigford wrote:

Mahjong.  Right?

-Original Message-
From: M100 [mailto:m100-boun...@lists.bitchin100.com] 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





Re: [M100] Game idea

2017-05-04 Thread Bob Pigford
Mahjong.  Right?

-Original Message-
From: M100 [mailto:m100-boun...@lists.bitchin100.com] 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



Re: [M100] Game idea

2017-05-04 Thread Kim Holviala
There's already a joystick interface that I made one day and documented here:
http://bitchin100.com/wiki/index.php?title=Joystick_adapter

I don't think there are any programs that would use it but it's a dead-simple 
adapter and works nicely. As for mouse, if the serial ports gives enough 
milliamps out then any old serial mouse would work out of the box, it's just a 
matter of turning a few pins high for power (RS-232 doesn't have power pins so 
serial mice "cheat" by stealing power from unused control pins) and then 
reading the incoming mouse data.

Offtopic to this discussion... but I'm finally moving to a big enough apartment 
so I can get my toys out of the boxes and into use \o/


- Kim



> On 04 May 2017, at 09:02, Ken Pettit <petti...@gmail.com> wrote:
> 
> That would be nice!  Perhaps an add-on in the BCR port?  Or maybe a wireless 
> mouse there?
> 
> Ken
> 
> On 5/3/17 5:37 PM, Mike Stein wrote:
>> Aww...
>>  
>> Joystick?
>>  
>> ;-)
>> - Original Message -
>> From: John R. Hogerhuis <mailto:jho...@pobox.com>
>> To: Model 100 Discussion <mailto:m100@lists.bitchin100.com>
>> Sent: Wednesday, May 03, 2017 8:31 PM
>> Subject: Re: [M100] Game idea
>> 
>> Or maybe a grid to allow keystroke
>> 
>> No mice! :-)
>> 
>> -- John. 
> 



Re: [M100] Game idea

2017-05-03 Thread Mike Stein
Aww...

Joystick?

;-)
  - Original Message - 
  From: John R. Hogerhuis 
  To: Model 100 Discussion 
  Sent: Wednesday, May 03, 2017 8:31 PM
  Subject: Re: [M100] Game idea


  Or maybe a grid to allow keystroke


  No mice! :-)


  -- John. 

Re: [M100] Game idea

2017-05-03 Thread John R. Hogerhuis
Or maybe a grid to allow keystroke

No mice! :-)

-- John.


Re: [M100] Game idea

2017-05-03 Thread Mike Stein
WOW!

Love the turkey or chicken, whatever it is.

Looks like we'll defnitely have to revive the mouse project.

m

- Original Message - 
From: "Ken Pettit" <petti...@gmail.com>
To: "Model 100 Discussion" <m100@lists.bitchin100.com>
Sent: Wednesday, May 03, 2017 6:59 PM
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
>


Re: [M100] Game idea

2017-05-03 Thread John R. Hogerhuis
Wow, nice graphics!

As to M100, I think scrolling would be a pain, but maybe just a toggle top
half, middle (showing bottom of top half and top half of bottom), bottom
half.

CO or BASIC... well CO files usually take double space anyway. But it would
be faster I guess. But your demo probably spends most of its time in
AsciiPixels machine code, no?

-- John.


Re: [M100] Game idea

2017-05-03 Thread Lee Olivares
That is extremely impressive Ken, fantastic work.

I wonder if there are so more M100's remaining "in the wild" since it
doesn't *look* like a normal "laptop"; I imagine many M200's were
unceremoniously tossed just for looking like "an old laptop".

 - Lee
 - 909.437.0250
 - Destroying technology problems.



On Wed, May 3, 2017 at 3:59 PM, Ken Pettit  wrote:

> 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
>
>


[M100] Game idea

2017-05-03 Thread Ken Pettit

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