Re: [M100] Interesting keyboard thingy

2024-10-19 Thread Gary Weber
Interesting, indeed.
Paired with a tiny single board computer it could get even more interesting.

On Wed, Oct 16, 2024 at 8:23 PM John R. Hogerhuis  wrote:

> [US$169.99]AJAZZ AKP846 84 Keys Smart Display Wired Mechanical Gaming
> Keyboard with 10.1-inch Color Screen Gasket Structure Hot Swappable PBT
> Keycaps Open Source Type-C Programmable 75% Layout Gaming Keyboard Computer
> Peripherals from Computers & Office on banggood
> https://ban.ggood.vip/1567Y
>
> -- John.
>


Re: [M100] interesting

2023-05-21 Thread Fisher
New game? I don’t care if it’s written in longhand, bring it on!




> On May 20, 2023, at 3:11 PM, Gary Wilkinson  wrote:
> 
> Ah, when you said you were writing a game, I assumed Z80 assembly and 
> wondered how you managed memory on the T100 and also the toolchain you’d use 
> to develop it.
> 
> Sent from my iPhone
> 
>> On 20 May 2023, at 17:32, lloydel...@comcast.net wrote:
>> 
>> 
>> I’m writing everything in BASIC.   I use lots of comments, but mainly to 
>> identify sections of code.   These might come out later if memory becomes an 
>> issue.Since all variables have global scope, it is important to keep 
>> track of how and where variables are used.   Things might become a mess if 
>> you accidentally reuse a variable.   I keep a running Word document open to 
>> keep track of what the variables are being used for.
>>  
>> I recently developed some tools that run on Windows for working on the T100 
>> programs.   They are MTRenum, MTVarConcor and MTLineRef.   They can be found 
>> at my GitHub page, (www.github.com/LEJ-Projects 
>> <http://www.github.com/LEJ-Projects>).There are also two games I’ve 
>> written for the TRS-80 Model 100 (or NEC8201).  They are Star Merchant and 
>> Dungeon Warrior.  Star Merchant was a rewrite of a game that I originally 
>> wrote for Creative Computing (August 1981).  Dungeon Warrior was a new game 
>> generated from an earlier self-published version I wrote for an Ohio 
>> Scientific Challenger 2.   I like to think of Dungeon Warrior as the prequel 
>> to Wizard War that I developed with Fred Saberhagen.  
>>  
>> I’m currently doing the development with bitchin100.com/CloudT.   I’ll try 
>> it later with a real M100.  I might also have a separate NEC8201 version.
>>  
>> I’ll put lots of game development notes in the pdf of new game I’m working 
>> on.It will be like the documentation I provided for Star Merchant and 
>> Dungeon Warrior, but maybe more so.
>>  
>> Lloyd
>>  
>> From: M100  On Behalf Of Gary Wilkinson
>> Sent: Saturday, May 20, 2023 9:51 AM
>> To: m...@bitchin100.com
>> Subject: Re: [M100] interesting
>>  
>> It’d be amazing if you could document the process of creating a game for the 
>> T100. The T100 is a bit different from other computers as everything sits in 
>> memory and it’s hard to know where in memory to locate the game and how much 
>> memory is free for the game. I’d be really interested in how a T100 game is 
>> built.
>> 
>> Sent from my iPhone
>> 
>> 
>> On 20 May 2023, at 13:14, lloydel...@comcast.net 
>> <mailto:lloydel...@comcast.net> wrote:
>> 
>>  
>> Those are indeed the games.  We had several more that we were considering 
>> but our publisher (Jim Baen) decided to get out of the software gaming 
>> business and that more or less ended that.   Fred and Joan Saberhagen 
>> continued to market them and their other games for a few years after.   It 
>> was fun.   I still stay in touch with Joan from time to time.  Fred died of 
>> cancer in 2007.  
>>  
>> I am currently working on a new game for the TRS-80 Model 100 that will 
>> reference the Berserkers (with Joan’s permission).   It might be a few 
>> months, but when it is done, I will share it with this group.   (Assuming I 
>> complete it.)
>>  
>> Using REXCPM for external storage does provide some interesting ideas. 
>>  
>> When I wrote Wizard Wars, I was concerned about fitting into the available 
>> memory.   I had only 64K of RAM and DOS and BASIC ate much of it.Wizard 
>> War consisted of 4 programs, an Intro, Main, Battle, and End.   Most of the 
>> time the game would switch between the Main program and the Battle program 
>> and would use a data file for sharing data.  I don’t own REXCPM (yet), but 
>> some very complex programs could do something similar and not be limited to 
>> the 29K or so that is available.  
>>  
>> Lloyd
>>  
>> From: M100 > <mailto:m100-boun...@lists.bitchin100.com>> On Behalf Of Ben Wiley Sittler
>> Sent: Friday, May 19, 2023 11:31 AM
>> To: m...@bitchin100.com <mailto:m...@bitchin100.com>
>> Subject: Re: [M100] interesting
>>  
>> Nice! Are these perhaps Wizard War and Berserker Raids? Those seem like they 
>> could be fun on the m100 too if only storage space were available. Maybe 
>> with REXCPM it is?
>>  
>> On Fri, May 19, 2023, 09:16 > <mailto:lloydel...@comcast.net>> wrote:
>> I’m intrigued.   The two games I worked on in the early 80s with Fred 

Re: [M100] interesting

2023-05-20 Thread Gary Wilkinson
Ah, when you said you were writing a game, I assumed Z80 assembly and wondered 
how you managed memory on the T100 and also the toolchain you’d use to develop 
it.

Sent from my iPhone

On 20 May 2023, at 17:32, lloydel...@comcast.net wrote:


I’m writing everything in BASIC.   I use lots of comments, but mainly to 
identify sections of code.   These might come out later if memory becomes an 
issue.Since all variables have global scope, it is important to keep track 
of how and where variables are used.   Things might become a mess if you 
accidentally reuse a variable.   I keep a running Word document open to keep 
track of what the variables are being used for.

I recently developed some tools that run on Windows for working on the T100 
programs.   They are MTRenum, MTVarConcor and MTLineRef.   They can be found at 
my GitHub page, 
(www.github.com/LEJ-Projects<http://www.github.com/LEJ-Projects>).There are 
also two games I’ve written for the TRS-80 Model 100 (or NEC8201).  They are 
Star Merchant and Dungeon Warrior.  Star Merchant was a rewrite of a game that 
I originally wrote for Creative Computing (August 1981).  Dungeon Warrior was a 
new game generated from an earlier self-published version I wrote for an Ohio 
Scientific Challenger 2.   I like to think of Dungeon Warrior as the prequel to 
Wizard War that I developed with Fred Saberhagen.

I’m currently doing the development with bitchin100.com/CloudT.   I’ll try it 
later with a real M100.  I might also have a separate NEC8201 version.

I’ll put lots of game development notes in the pdf of new game I’m working on.  
  It will be like the documentation I provided for Star Merchant and Dungeon 
Warrior, but maybe more so.

Lloyd

From: M100  On Behalf Of Gary Wilkinson
Sent: Saturday, May 20, 2023 9:51 AM
To: m...@bitchin100.com
Subject: Re: [M100] interesting

It’d be amazing if you could document the process of creating a game for the 
T100. The T100 is a bit different from other computers as everything sits in 
memory and it’s hard to know where in memory to locate the game and how much 
memory is free for the game. I’d be really interested in how a T100 game is 
built.
Sent from my iPhone


On 20 May 2023, at 13:14, lloydel...@comcast.net<mailto:lloydel...@comcast.net> 
wrote:

Those are indeed the games.  We had several more that we were considering but 
our publisher (Jim Baen) decided to get out of the software gaming business and 
that more or less ended that.   Fred and Joan Saberhagen continued to market 
them and their other games for a few years after.   It was fun.   I still stay 
in touch with Joan from time to time.  Fred died of cancer in 2007.

I am currently working on a new game for the TRS-80 Model 100 that will 
reference the Berserkers (with Joan’s permission).   It might be a few months, 
but when it is done, I will share it with this group.   (Assuming I complete 
it.)

Using REXCPM for external storage does provide some interesting ideas.

When I wrote Wizard Wars, I was concerned about fitting into the available 
memory.   I had only 64K of RAM and DOS and BASIC ate much of it.Wizard War 
consisted of 4 programs, an Intro, Main, Battle, and End.   Most of the time 
the game would switch between the Main program and the Battle program and would 
use a data file for sharing data.  I don’t own REXCPM (yet), but some very 
complex programs could do something similar and not be limited to the 29K or so 
that is available.

Lloyd

From: M100 
mailto:m100-boun...@lists.bitchin100.com>> 
On Behalf Of Ben Wiley Sittler
Sent: Friday, May 19, 2023 11:31 AM
To: m...@bitchin100.com<mailto:m...@bitchin100.com>
Subject: Re: [M100] interesting

Nice! Are these perhaps Wizard War and Berserker Raids? Those seem like they 
could be fun on the m100 too if only storage space were available. Maybe with 
REXCPM it is?

On Fri, May 19, 2023, 09:16 
mailto:lloydel...@comcast.net>> wrote:
I’m intrigued.   The two games I worked on in the early 80s with Fred 
Saberhagen were developed on an original IBM PC that had a motherboard fully 
populated with 64K and later a memory board that added an additional 512K.  I 
had 4 floppy drives connected to it but no hard drive.

If I want to play these games anymore (and every few years I do), I fire up the 
DOS box emulator.   It might be fun to run it on a machine dedicated to 
mimicking the capabilities of the old IBM PC.  The novelty might wear off soon 
followed by some buyer’s remorse.   But then again, it does sound cool.

Lloyd

From: M100 
mailto:m100-boun...@lists.bitchin100.com>> 
On Behalf Of Russell Flowers
Sent: Friday, May 19, 2023 10:15 AM
To: m...@bitchin100.com<mailto:m...@bitchin100.com>
Subject: Re: [M100] interesting

That is an unusual product. I wonder how it came to be? Hobbyist pulled the 
lever and went into production? Could they be just-in-time and/or built to 
order?

On Fri, May 19, 2023 at 10:02 AM Paco 
mailto:z

Re: [M100] interesting

2023-05-20 Thread lloydelmer
I’m writing everything in BASIC.   I use lots of comments, but mainly to 
identify sections of code.   These might come out later if memory becomes an 
issue.Since all variables have global scope, it is important to keep track 
of how and where variables are used.   Things might become a mess if you 
accidentally reuse a variable.   I keep a running Word document open to keep 
track of what the variables are being used for.

 

I recently developed some tools that run on Windows for working on the T100 
programs.   They are MTRenum, MTVarConcor and MTLineRef.   They can be found at 
my GitHub page, (www.github.com/LEJ-Projects 
<http://www.github.com/LEJ-Projects> ).There are also two games I’ve 
written for the TRS-80 Model 100 (or NEC8201).  They are Star Merchant and 
Dungeon Warrior.  Star Merchant was a rewrite of a game that I originally wrote 
for Creative Computing (August 1981).  Dungeon Warrior was a new game generated 
from an earlier self-published version I wrote for an Ohio Scientific 
Challenger 2.   I like to think of Dungeon Warrior as the prequel to Wizard War 
that I developed with Fred Saberhagen.   

 

I’m currently doing the development with bitchin100.com/CloudT.   I’ll try it 
later with a real M100.  I might also have a separate NEC8201 version.

 

I’ll put lots of game development notes in the pdf of new game I’m working on.  
  It will be like the documentation I provided for Star Merchant and Dungeon 
Warrior, but maybe more so.

 

Lloyd

 

From: M100  On Behalf Of Gary Wilkinson
Sent: Saturday, May 20, 2023 9:51 AM
To: m...@bitchin100.com
Subject: Re: [M100] interesting

 

It’d be amazing if you could document the process of creating a game for the 
T100. The T100 is a bit different from other computers as everything sits in 
memory and it’s hard to know where in memory to locate the game and how much 
memory is free for the game. I’d be really interested in how a T100 game is 
built.

Sent from my iPhone





On 20 May 2023, at 13:14, lloydel...@comcast.net 
<mailto:lloydel...@comcast.net>  wrote:

 

Those are indeed the games.  We had several more that we were considering but 
our publisher (Jim Baen) decided to get out of the software gaming business and 
that more or less ended that.   Fred and Joan Saberhagen continued to market 
them and their other games for a few years after.   It was fun.   I still stay 
in touch with Joan from time to time.  Fred died of cancer in 2007.   

 

I am currently working on a new game for the TRS-80 Model 100 that will 
reference the Berserkers (with Joan’s permission).   It might be a few months, 
but when it is done, I will share it with this group.   (Assuming I complete 
it.)

 

Using REXCPM for external storage does provide some interesting ideas.  

 

When I wrote Wizard Wars, I was concerned about fitting into the available 
memory.   I had only 64K of RAM and DOS and BASIC ate much of it.Wizard War 
consisted of 4 programs, an Intro, Main, Battle, and End.   Most of the time 
the game would switch between the Main program and the Battle program and would 
use a data file for sharing data.  I don’t own REXCPM (yet), but some very 
complex programs could do something similar and not be limited to the 29K or so 
that is available.   

 

Lloyd

 

From: M100 mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Ben Wiley Sittler
Sent: Friday, May 19, 2023 11:31 AM
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] interesting

 

Nice! Are these perhaps Wizard War and Berserker Raids? Those seem like they 
could be fun on the m100 too if only storage space were available. Maybe with 
REXCPM it is?

 

On Fri, May 19, 2023, 09:16 mailto:lloydel...@comcast.net> > wrote:

I’m intrigued.   The two games I worked on in the early 80s with Fred 
Saberhagen were developed on an original IBM PC that had a motherboard fully 
populated with 64K and later a memory board that added an additional 512K.  I 
had 4 floppy drives connected to it but no hard drive.

 

If I want to play these games anymore (and every few years I do), I fire up the 
DOS box emulator.   It might be fun to run it on a machine dedicated to 
mimicking the capabilities of the old IBM PC.  The novelty might wear off soon 
followed by some buyer’s remorse.   But then again, it does sound cool.   

 

Lloyd

 

From: M100 mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Russell Flowers
Sent: Friday, May 19, 2023 10:15 AM
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] interesting

 

That is an unusual product. I wonder how it came to be? Hobbyist pulled the 
lever and went into production? Could they be just-in-time and/or built to 
order?

 

On Fri, May 19, 2023 at 10:02 AM Paco mailto:zx4e...@gmail.com> > wrote:

Very interesting computer, using real expansión board 8 bits.

 

El vie, 19 may 2023, 15:01, Stephen Adolph mailto:twospru...@gmail.c

Re: [M100] interesting

2023-05-20 Thread Ben Wiley Sittler
That's great! I'll look forward to that possibility, new games are always
welcome.

Fred Saberhagen is surely missed by me who has only read his words, and a
new computer game in the Berserker universe sounds like a fine addition. I
hope development and distribution are both somewhat easier now than they
were then. Even finding the original games - for any platform - has become
a challenge of its own.

Documentation of the process can be really interesting reading too,
regardless of whether the end result matches the initial vision. If you
decide that it's something you're interested in trying I'm sure there will
be readers here! In this vein, yesterday I was reading mass:werk/Norbert
Landsteiner's writings about a Model T Maze War conversion and it was both
entertaining and informative: https://www.masswerk.at/rc2016/01/

On Sat, May 20, 2023, 05:14  wrote:

> Those are indeed the games.  We had several more that we were considering
> but our publisher (Jim Baen) decided to get out of the software gaming
> business and that more or less ended that.   Fred and Joan Saberhagen
> continued to market them and their other games for a few years after.   It
> was fun.   I still stay in touch with Joan from time to time.  Fred died of
> cancer in 2007.
>
>
>
> I am currently working on a new game for the TRS-80 Model 100 that will
> reference the Berserkers (with Joan’s permission).   It might be a few
> months, but when it is done, I will share it with this group.   (Assuming I
> complete it.)
>
>
>
> Using REXCPM for external storage does provide some interesting ideas.
>
>
>
> When I wrote Wizard Wars, I was concerned about fitting into the available
> memory.   I had only 64K of RAM and DOS and BASIC ate much of it.Wizard
> War consisted of 4 programs, an Intro, Main, Battle, and End.   Most of the
> time the game would switch between the Main program and the Battle program
> and would use a data file for sharing data.  I don’t own REXCPM (yet), but
> some very complex programs could do something similar and not be limited to
> the 29K or so that is available.
>
>
>
> Lloyd
>
>
>
> *From:* M100  *On Behalf Of *Ben Wiley
> Sittler
> *Sent:* Friday, May 19, 2023 11:31 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] interesting
>
>
>
> Nice! Are these perhaps Wizard War and Berserker Raids? Those seem like
> they could be fun on the m100 too if only storage space were available.
> Maybe with REXCPM it is?
>
>
>
> On Fri, May 19, 2023, 09:16  wrote:
>
> I’m intrigued.   The two games I worked on in the early 80s with Fred
> Saberhagen were developed on an original IBM PC that had a motherboard
> fully populated with 64K and later a memory board that added an additional
> 512K.  I had 4 floppy drives connected to it but no hard drive.
>
>
>
> If I want to play these games anymore (and every few years I do), I fire
> up the DOS box emulator.   It might be fun to run it on a machine dedicated
> to mimicking the capabilities of the old IBM PC.  The novelty might wear
> off soon followed by some buyer’s remorse.   But then again, it does sound
> cool.
>
>
>
> Lloyd
>
>
>
> *From:* M100  *On Behalf Of *Russell
> Flowers
> *Sent:* Friday, May 19, 2023 10:15 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] interesting
>
>
>
> That is an unusual product. I wonder how it came to be? Hobbyist pulled
> the lever and went into production? Could they be just-in-time and/or built
> to order?
>
>
>
> On Fri, May 19, 2023 at 10:02 AM Paco  wrote:
>
> Very interesting computer, using real expansión board 8 bits.
>
>
>
> El vie, 19 may 2023, 15:01, Stephen Adolph 
> escribió:
>
> https://www.aliexpress.com/item/1005005534146618.html
>
>
>
> Concept is neat but I think the execution was bad.  Apparently the BIOS
> was modified and used without following the author's license.  (FYI BIOS
> author requesting that no one purchase this until the license issue is
> resolved)
>
>
>
> Made me think of a 2nd generation M100 work alike.
>
>


Re: [M100] interesting

2023-05-20 Thread Gary Wilkinson
It’d be amazing if you could document the process of creating a game for the 
T100. The T100 is a bit different from other computers as everything sits in 
memory and it’s hard to know where in memory to locate the game and how much 
memory is free for the game. I’d be really interested in how a T100 game is 
built.

Sent from my iPhone

On 20 May 2023, at 13:14, lloydel...@comcast.net wrote:


Those are indeed the games.  We had several more that we were considering but 
our publisher (Jim Baen) decided to get out of the software gaming business and 
that more or less ended that.   Fred and Joan Saberhagen continued to market 
them and their other games for a few years after.   It was fun.   I still stay 
in touch with Joan from time to time.  Fred died of cancer in 2007.

I am currently working on a new game for the TRS-80 Model 100 that will 
reference the Berserkers (with Joan’s permission).   It might be a few months, 
but when it is done, I will share it with this group.   (Assuming I complete 
it.)

Using REXCPM for external storage does provide some interesting ideas.

When I wrote Wizard Wars, I was concerned about fitting into the available 
memory.   I had only 64K of RAM and DOS and BASIC ate much of it.Wizard War 
consisted of 4 programs, an Intro, Main, Battle, and End.   Most of the time 
the game would switch between the Main program and the Battle program and would 
use a data file for sharing data.  I don’t own REXCPM (yet), but some very 
complex programs could do something similar and not be limited to the 29K or so 
that is available.

Lloyd

From: M100  On Behalf Of Ben Wiley Sittler
Sent: Friday, May 19, 2023 11:31 AM
To: m...@bitchin100.com
Subject: Re: [M100] interesting

Nice! Are these perhaps Wizard War and Berserker Raids? Those seem like they 
could be fun on the m100 too if only storage space were available. Maybe with 
REXCPM it is?

On Fri, May 19, 2023, 09:16 
mailto:lloydel...@comcast.net>> wrote:
I’m intrigued.   The two games I worked on in the early 80s with Fred 
Saberhagen were developed on an original IBM PC that had a motherboard fully 
populated with 64K and later a memory board that added an additional 512K.  I 
had 4 floppy drives connected to it but no hard drive.

If I want to play these games anymore (and every few years I do), I fire up the 
DOS box emulator.   It might be fun to run it on a machine dedicated to 
mimicking the capabilities of the old IBM PC.  The novelty might wear off soon 
followed by some buyer’s remorse.   But then again, it does sound cool.

Lloyd

From: M100 
mailto:m100-boun...@lists.bitchin100.com>> 
On Behalf Of Russell Flowers
Sent: Friday, May 19, 2023 10:15 AM
To: m...@bitchin100.com<mailto:m...@bitchin100.com>
Subject: Re: [M100] interesting

That is an unusual product. I wonder how it came to be? Hobbyist pulled the 
lever and went into production? Could they be just-in-time and/or built to 
order?

On Fri, May 19, 2023 at 10:02 AM Paco 
mailto:zx4e...@gmail.com>> wrote:
Very interesting computer, using real expansión board 8 bits.

El vie, 19 may 2023, 15:01, Stephen Adolph 
mailto:twospru...@gmail.com>> escribió:
https://www.aliexpress.com/item/1005005534146618.html

Concept is neat but I think the execution was bad.  Apparently the BIOS was 
modified and used without following the author's license.  (FYI BIOS author 
requesting that no one purchase this until the license issue is resolved)

Made me think of a 2nd generation M100 work alike.


Re: [M100] interesting

2023-05-20 Thread lloydelmer
Those are indeed the games.  We had several more that we were considering but 
our publisher (Jim Baen) decided to get out of the software gaming business and 
that more or less ended that.   Fred and Joan Saberhagen continued to market 
them and their other games for a few years after.   It was fun.   I still stay 
in touch with Joan from time to time.  Fred died of cancer in 2007.   

 

I am currently working on a new game for the TRS-80 Model 100 that will 
reference the Berserkers (with Joan’s permission).   It might be a few months, 
but when it is done, I will share it with this group.   (Assuming I complete 
it.)

 

Using REXCPM for external storage does provide some interesting ideas.  

 

When I wrote Wizard Wars, I was concerned about fitting into the available 
memory.   I had only 64K of RAM and DOS and BASIC ate much of it.Wizard War 
consisted of 4 programs, an Intro, Main, Battle, and End.   Most of the time 
the game would switch between the Main program and the Battle program and would 
use a data file for sharing data.  I don’t own REXCPM (yet), but some very 
complex programs could do something similar and not be limited to the 29K or so 
that is available.   

 

Lloyd

 

From: M100  On Behalf Of Ben Wiley Sittler
Sent: Friday, May 19, 2023 11:31 AM
To: m...@bitchin100.com
Subject: Re: [M100] interesting

 

Nice! Are these perhaps Wizard War and Berserker Raids? Those seem like they 
could be fun on the m100 too if only storage space were available. Maybe with 
REXCPM it is?

 

On Fri, May 19, 2023, 09:16  wrote:

I’m intrigued.   The two games I worked on in the early 80s with Fred 
Saberhagen were developed on an original IBM PC that had a motherboard fully 
populated with 64K and later a memory board that added an additional 512K.  I 
had 4 floppy drives connected to it but no hard drive.

 

If I want to play these games anymore (and every few years I do), I fire up the 
DOS box emulator.   It might be fun to run it on a machine dedicated to 
mimicking the capabilities of the old IBM PC.  The novelty might wear off soon 
followed by some buyer’s remorse.   But then again, it does sound cool.   

 

Lloyd

 

From: M100 mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Russell Flowers
Sent: Friday, May 19, 2023 10:15 AM
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] interesting

 

That is an unusual product. I wonder how it came to be? Hobbyist pulled the 
lever and went into production? Could they be just-in-time and/or built to 
order?

 

On Fri, May 19, 2023 at 10:02 AM Paco mailto:zx4e...@gmail.com> > wrote:

Very interesting computer, using real expansión board 8 bits.

 

El vie, 19 may 2023, 15:01, Stephen Adolph mailto:twospru...@gmail.com> > escribió:

https://www.aliexpress.com/item/1005005534146618.html

 

Concept is neat but I think the execution was bad.  Apparently the BIOS was 
modified and used without following the author's license.  (FYI BIOS author 
requesting that no one purchase this until the license issue is resolved)

 

Made me think of a 2nd generation M100 work alike.



Re: [M100] interesting

2023-05-19 Thread Ben Wiley Sittler
Nice! Are these perhaps Wizard War and Berserker Raids? Those seem like
they could be fun on the m100 too if only storage space were available.
Maybe with REXCPM it is?

On Fri, May 19, 2023, 09:16  wrote:

> I’m intrigued.   The two games I worked on in the early 80s with Fred
> Saberhagen were developed on an original IBM PC that had a motherboard
> fully populated with 64K and later a memory board that added an additional
> 512K.  I had 4 floppy drives connected to it but no hard drive.
>
>
>
> If I want to play these games anymore (and every few years I do), I fire
> up the DOS box emulator.   It might be fun to run it on a machine dedicated
> to mimicking the capabilities of the old IBM PC.  The novelty might wear
> off soon followed by some buyer’s remorse.   But then again, it does sound
> cool.
>
>
>
> Lloyd
>
>
>
> *From:* M100  *On Behalf Of *Russell
> Flowers
> *Sent:* Friday, May 19, 2023 10:15 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] interesting
>
>
>
> That is an unusual product. I wonder how it came to be? Hobbyist pulled
> the lever and went into production? Could they be just-in-time and/or built
> to order?
>
>
>
> On Fri, May 19, 2023 at 10:02 AM Paco  wrote:
>
> Very interesting computer, using real expansión board 8 bits.
>
>
>
> El vie, 19 may 2023, 15:01, Stephen Adolph 
> escribió:
>
> https://www.aliexpress.com/item/1005005534146618.html
>
>
>
> Concept is neat but I think the execution was bad.  Apparently the BIOS
> was modified and used without following the author's license.  (FYI BIOS
> author requesting that no one purchase this until the license issue is
> resolved)
>
>
>
> Made me think of a 2nd generation M100 work alike.
>
>


Re: [M100] interesting

2023-05-19 Thread lloydelmer
I’m intrigued.   The two games I worked on in the early 80s with Fred 
Saberhagen were developed on an original IBM PC that had a motherboard fully 
populated with 64K and later a memory board that added an additional 512K.  I 
had 4 floppy drives connected to it but no hard drive.

 

If I want to play these games anymore (and every few years I do), I fire up the 
DOS box emulator.   It might be fun to run it on a machine dedicated to 
mimicking the capabilities of the old IBM PC.  The novelty might wear off soon 
followed by some buyer’s remorse.   But then again, it does sound cool.   

 

Lloyd

 

From: M100  On Behalf Of Russell Flowers
Sent: Friday, May 19, 2023 10:15 AM
To: m...@bitchin100.com
Subject: Re: [M100] interesting

 

That is an unusual product. I wonder how it came to be? Hobbyist pulled the 
lever and went into production? Could they be just-in-time and/or built to 
order?

 

On Fri, May 19, 2023 at 10:02 AM Paco mailto:zx4e...@gmail.com> > wrote:

Very interesting computer, using real expansión board 8 bits.

 

El vie, 19 may 2023, 15:01, Stephen Adolph mailto:twospru...@gmail.com> > escribió:

https://www.aliexpress.com/item/1005005534146618.html

 

Concept is neat but I think the execution was bad.  Apparently the BIOS was 
modified and used without following the author's license.  (FYI BIOS author 
requesting that no one purchase this until the license issue is resolved)

 

Made me think of a 2nd generation M100 work alike.



Re: [M100] interesting

2023-05-19 Thread Russell Flowers
That is an unusual product. I wonder how it came to be? Hobbyist pulled the
lever and went into production? Could they be just-in-time and/or built to
order?

On Fri, May 19, 2023 at 10:02 AM Paco  wrote:

> Very interesting computer, using real expansión board 8 bits.
>
> El vie, 19 may 2023, 15:01, Stephen Adolph 
> escribió:
>
>> https://www.aliexpress.com/item/1005005534146618.html
>>
>> Concept is neat but I think the execution was bad.  Apparently the BIOS
>> was modified and used without following the author's license.  (FYI BIOS
>> author requesting that no one purchase this until the license issue is
>> resolved)
>>
>> Made me think of a 2nd generation M100 work alike.
>>
>


Re: [M100] interesting

2023-05-19 Thread Paco
Very interesting computer, using real expansión board 8 bits.

El vie, 19 may 2023, 15:01, Stephen Adolph  escribió:

> https://www.aliexpress.com/item/1005005534146618.html
>
> Concept is neat but I think the execution was bad.  Apparently the BIOS
> was modified and used without following the author's license.  (FYI BIOS
> author requesting that no one purchase this until the license issue is
> resolved)
>
> Made me think of a 2nd generation M100 work alike.
>


Re: [M100] Interesting m-100 clone

2021-12-05 Thread Ben Wiley Sittler
I stand corrected, the A06 DevTerm does allow some configuration when it
comes to power consumption!
https://github.com/clockworkpi/DevTerm/blob/main/Code/A06/devterm-a06-gearbox

On Sun, Dec 5, 2021 at 4:54 PM Ben Wiley Sittler 
wrote:

> As of today the A06 model appears to be in stock at their shop again, by
> the way: https://www.clockworkpi.com/shop
>
> I don't have it, but have read that this A06 version is a bit more
> powerful than the Raspberry Pi CM3+ lite version, though also
> correspondingly a bit more power-hungry/has a bit less battery life if
> you're running it without an external power source
>
> Also note that you will need to find and supply your own pair of 18650
> batteries if you want to run it portably. Protected cells are recommended,
> and not the "short burst" ones sold for vaping but rather the "endurance"
> cells sold for flashlights. I bought some with a flashlight on Amazon and
> they work fine in my CM3+ lite model.
>
> On Sun, Dec 5, 2021 at 3:39 PM Kevin Becker  wrote:
>
>> I'm still waiting for mine.  I ordered the A04 model, not knowing at the
>> time that it would ship dead last.
>>
>> On Sat, 2021-12-04 at 21:00 -0800, Ben Wiley Sittler wrote:
>>
>> I have that machine! Specifically mine is the version with a Raspberry Pi
>> Compute Module 3+ Lite. It can run VirtualT OK too, though I need to fix
>> some memory corruption or API incompatibity that currently renders FLTK
>> file dialogs unusable. The optional cash register thermal printer mode is a
>> nice Epon-ish touch, and of course the screen is lovely though it could
>> really stand to have a protective layer of hard plastic in front. The
>> gamepad arrows are very reminiscent of PC-8201 though positioned
>> differently. The keyboard is nowhere near as typeable as the Model T's,
>> unfortunately. The whole device is only half the area of a Model 100!
>>
>> Unfortunately being Pi-based it doesn't have any concept of low-power
>> sleep or suspend mode, but on the other hand it does have a microsd card
>> for persistent storage, and it boots in less than ten seconds. The WiFi,
>> Bluetooth, USB, and HDMI connectivity feel very fancy after using a device
>> with just serial connectivity
>>
>> On Sat, Dec 4, 2021, 13:17 Earl Baugh  wrote:
>>
>> Saw this and found it an interesting look-a-like :
>>
>>
>> https://www.hackster.io/news/clockwork-pi-devterm-review-hands-on-with-the-ultra-compact-trs-80-inspired-kit-computer-b5a73acbaefd?mc_cid=142fb5fc81&mc_eid=39010d1c63
>>
>> Earl
>>
>> Sent from my iPhone
>>
>>


Re: [M100] Interesting m-100 clone

2021-12-05 Thread Ben Wiley Sittler
As of today the A06 model appears to be in stock at their shop again, by
the way: https://www.clockworkpi.com/shop

I don't have it, but have read that this A06 version is a bit more powerful
than the Raspberry Pi CM3+ lite version, though also correspondingly a bit
more power-hungry/has a bit less battery life if you're running it without
an external power source

Also note that you will need to find and supply your own pair of 18650
batteries if you want to run it portably. Protected cells are recommended,
and not the "short burst" ones sold for vaping but rather the "endurance"
cells sold for flashlights. I bought some with a flashlight on Amazon and
they work fine in my CM3+ lite model.

On Sun, Dec 5, 2021 at 3:39 PM Kevin Becker  wrote:

> I'm still waiting for mine.  I ordered the A04 model, not knowing at the
> time that it would ship dead last.
>
> On Sat, 2021-12-04 at 21:00 -0800, Ben Wiley Sittler wrote:
>
> I have that machine! Specifically mine is the version with a Raspberry Pi
> Compute Module 3+ Lite. It can run VirtualT OK too, though I need to fix
> some memory corruption or API incompatibity that currently renders FLTK
> file dialogs unusable. The optional cash register thermal printer mode is a
> nice Epon-ish touch, and of course the screen is lovely though it could
> really stand to have a protective layer of hard plastic in front. The
> gamepad arrows are very reminiscent of PC-8201 though positioned
> differently. The keyboard is nowhere near as typeable as the Model T's,
> unfortunately. The whole device is only half the area of a Model 100!
>
> Unfortunately being Pi-based it doesn't have any concept of low-power
> sleep or suspend mode, but on the other hand it does have a microsd card
> for persistent storage, and it boots in less than ten seconds. The WiFi,
> Bluetooth, USB, and HDMI connectivity feel very fancy after using a device
> with just serial connectivity
>
> On Sat, Dec 4, 2021, 13:17 Earl Baugh  wrote:
>
> Saw this and found it an interesting look-a-like :
>
>
> https://www.hackster.io/news/clockwork-pi-devterm-review-hands-on-with-the-ultra-compact-trs-80-inspired-kit-computer-b5a73acbaefd?mc_cid=142fb5fc81&mc_eid=39010d1c63
>
> Earl
>
> Sent from my iPhone
>
>


Re: [M100] Interesting m-100 clone

2021-12-05 Thread Kevin Becker
I'm still waiting for mine.  I ordered the A04 model, not knowing at
the time that it would ship dead last.

On Sat, 2021-12-04 at 21:00 -0800, Ben Wiley Sittler wrote:
> I have that machine! Specifically mine is the version with a
> Raspberry Pi Compute Module 3+ Lite. It can run VirtualT OK too,
> though I need to fix some memory corruption or API incompatibity that
> currently renders FLTK file dialogs unusable. The optional cash
> register thermal printer mode is a nice Epon-ish touch, and of course
> the screen is lovely though it could really stand to have a
> protective layer of hard plastic in front. The gamepad arrows are
> very reminiscent of PC-8201 though positioned differently. The
> keyboard is nowhere near as typeable as the Model T's, unfortunately.
> The whole device is only half the area of a Model 100!
> 
> Unfortunately being Pi-based it doesn't have any concept of low-power
> sleep or suspend mode, but on the other hand it does have a microsd
> card for persistent storage, and it boots in less than ten seconds.
> The WiFi, Bluetooth, USB, and HDMI connectivity feel very fancy after
> using a device with just serial connectivity
> 
> On Sat, Dec 4, 2021, 13:17 Earl Baugh  wrote:
> > Saw this and found it an interesting look-a-like :
> > 
> >
> https://www.hackster.io/news/clockwork-pi-devterm-review-hands-on-with-the-ultra-compact-trs-80-inspired-kit-computer-b5a73acbaefd?mc_cid=142fb5fc81&mc_eid=39010d1c63
> > 
> > Earl 
> > 
> > Sent from my iPhone


Re: [M100] Interesting m-100 clone

2021-12-05 Thread Brad Grier
Nice, thanks for sharing that comparison -- I thought it looked a bit small
compared to the hand in one of the shots :)

--Brad

On Sat, Dec 4, 2021 at 10:01 PM Ben Wiley Sittler 
wrote:

> I have that machine! Specifically mine is the version with a Raspberry Pi
> Compute Module 3+ Lite. It can run VirtualT OK too, though I need to fix
> some memory corruption or API incompatibity that currently renders FLTK
> file dialogs unusable. The optional cash register thermal printer mode is a
> nice Epon-ish touch, and of course the screen is lovely though it could
> really stand to have a protective layer of hard plastic in front. The
> gamepad arrows are very reminiscent of PC-8201 though positioned
> differently. The keyboard is nowhere near as typeable as the Model T's,
> unfortunately. The whole device is only half the area of a Model 100!
>
> Unfortunately being Pi-based it doesn't have any concept of low-power
> sleep or suspend mode, but on the other hand it does have a microsd card
> for persistent storage, and it boots in less than ten seconds. The WiFi,
> Bluetooth, USB, and HDMI connectivity feel very fancy after using a device
> with just serial connectivity
>
> On Sat, Dec 4, 2021, 13:17 Earl Baugh  wrote:
>
>> Saw this and found it an interesting look-a-like :
>>
>>
>> https://www.hackster.io/news/clockwork-pi-devterm-review-hands-on-with-the-ultra-compact-trs-80-inspired-kit-computer-b5a73acbaefd?mc_cid=142fb5fc81&mc_eid=39010d1c63
>>
>> Earl
>>
>> Sent from my iPhone
>>
>

-- 
-- 
Brad Grier


Re: [M100] Interesting m-100 clone

2021-12-04 Thread Ben Wiley Sittler
I have that machine! Specifically mine is the version with a Raspberry Pi
Compute Module 3+ Lite. It can run VirtualT OK too, though I need to fix
some memory corruption or API incompatibity that currently renders FLTK
file dialogs unusable. The optional cash register thermal printer mode is a
nice Epon-ish touch, and of course the screen is lovely though it could
really stand to have a protective layer of hard plastic in front. The
gamepad arrows are very reminiscent of PC-8201 though positioned
differently. The keyboard is nowhere near as typeable as the Model T's,
unfortunately. The whole device is only half the area of a Model 100!

Unfortunately being Pi-based it doesn't have any concept of low-power sleep
or suspend mode, but on the other hand it does have a microsd card for
persistent storage, and it boots in less than ten seconds. The WiFi,
Bluetooth, USB, and HDMI connectivity feel very fancy after using a device
with just serial connectivity

On Sat, Dec 4, 2021, 13:17 Earl Baugh  wrote:

> Saw this and found it an interesting look-a-like :
>
>
> https://www.hackster.io/news/clockwork-pi-devterm-review-hands-on-with-the-ultra-compact-trs-80-inspired-kit-computer-b5a73acbaefd?mc_cid=142fb5fc81&mc_eid=39010d1c63
>
> Earl
>
> Sent from my iPhone
>


Re: [M100] interesting VARPTR bug

2018-05-29 Thread Stephen Adolph
ah, so making the assignment to the scalar variable is the difference, vs
an array variable.  they are in different memory areas.

thanks I think that is a clear answer.

On Tue, May 29, 2018 at 7:08 PM, Ken Pettit  wrote:

> Hi Steve,
>
> The line:
>
> 20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)
>
> Doesn't work because you take the value of VARPTR(A$(0)) and assign it to
> F.  But then you assign the value of K.  This creates a new scalar
> variable, causing A$(0) to be moved.  So then the "256*PEEK(F+2)+PEEK(F+1)"
> fails because K is pointing to the old location for A$(0).
>
> If you change your line as follows, then it should work because K is
> created first, causing A$() to be moved, and *then* you take the address of
> A$():
>
> 20 K=0:F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)
>
> Ken
>
>
> On 5/29/18 3:43 PM, Stephen Adolph wrote:
>
> Ken, when I first read your code I said "That wont work and k(0) will be
> wrong."
>
> however it seems to work.
>
> I cannot explain why your code works and my original code did not.  I
> never modify the string content.
>
> -
> your line:
> 20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
>
> compared with
> 20 F=VARPTR(A$(0)):*K(0)*=256*PEEK(F+2)+PEEK(F+1)
>
> yield the same answers for K(0)
>
> ---
> your line:
> 20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
>
> compared with
> 20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)
>
> yield different answers for K, K(0)
> the only difference is using K vs K(0).
>
>
> I still don't know a good rule for how to safely use VARPTR!!
>
>
>
>
>
>
>
> On Tue, May 29, 2018 at 4:52 PM, Ken Pettit  wrote:
>
>> Steve,
>>
>> Are you are trying to pre-calculate the addresses of the strings to save
>> time or something?
>>
>> One thing to note is that the address of the A$() or D$() array variable
>> will move around in RAM.  However, as long as you don't modify the strings
>> *in* the array after they are first assigned, then the
>> "256*PEEK(K+2)+PEEK(K+1)" address values pointing to the actual text will
>> NOT change.  Those addresses will be pointing back to the actual string
>> text in the BASIC program (which doesn't move around during program
>> execution).
>>
>> This is an optimization BASIC makes.  When strings are first assigned,
>> the variable is created with an address pointing to the actual string
>> text.  The initial value simply points to the BASIC program.  If the
>> contents of that string variable are changed after that point, then BASIC
>> moves the text into high RAM to make the modification.  Otherwise the text
>> simply lives in the BASIC program.
>>
>> So you could create an array of pre-calculated addresses as follows:
>>
>> 10 DIM A$(3):DIMK(3):A$(0)="blah0":A$(1)="blah1":A$(2)="blah2":A$(3
>> )="blah3"
>> 20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
>> 30 REM
>> 40 REM Now any variable can be created and the values in K() will still
>> be correct.
>>
>> Ken
>>
>>
>> On 5/29/18 9:25 AM, Stephen Adolph wrote:
>>
>> John, I wasn't able to declare variables in any meaningful way to solve
>> this problem. Only assignment seemed to work.  Do you know a trick for that?
>> steve
>>
>> On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis 
>> wrote:
>>
>>>
>>> On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt 
>>> wrote:
>>>
 >>> Anytime a new scalar (i.e. non-array) variable is created, the
 addresses of the array variables must all change to make room for the new
 scalar variable.



 So BASIC copies all the arrays to a new memory address? That does not
 seem very efficient.



 Jeff



>>>
>>> I think it’s a trade off. Extra levels of indirection are also
>>> inefficient.
>>>
>>> It’s either take the hit on a “move” when a variable is created  or take
>>> a guaranteed hit every variable access.
>>>
>>> And you can avoid the cost by declaring your variables up front.
>>>
>>> — John.
>>>
>>>
>>>
>>
>>
>
>


Re: [M100] interesting VARPTR bug

2018-05-29 Thread Ken Pettit

Hi Steve,

Or rather  "... fails becuase *F* is pointing to the old location for 
A$(0)".


Ken

On 5/29/18 4:08 PM, Ken Pettit wrote:

Hi Steve,

The line:

20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)

Doesn't work because you take the value of VARPTR(A$(0)) and assign it 
to F.  But then you assign the value of K.  This creates a new scalar 
variable, causing A$(0) to be moved.  So then the 
"256*PEEK(F+2)+PEEK(F+1)" fails because K is pointing to the old 
location for A$(0).


If you change your line as follows, then it should work because K is 
created first, causing A$() to be moved, and *then* you take the 
address of A$():


20 K=0:F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)

Ken

On 5/29/18 3:43 PM, Stephen Adolph wrote:
Ken, when I first read your code I said "That wont work and k(0) will 
be wrong."


however it seems to work.

I cannot explain why your code works and my original code did not.  I 
never modify the string content.


-
your line:
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT

compared with
20 F=VARPTR(A$(0)):*K(0)*=256*PEEK(F+2)+PEEK(F+1)

yield the same answers for K(0)

---
your line:
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT

compared with
20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)

yield different answers for K, K(0)
the only difference is using K vs K(0).


I still don't know a good rule for how to safely use VARPTR!!







On Tue, May 29, 2018 at 4:52 PM, Ken Pettit > wrote:


Steve,

Are you are trying to pre-calculate the addresses of the strings
to save time or something?

One thing to note is that the address of the A$() or D$() array
variable will move around in RAM.  However, as long as you don't
modify the strings *in* the array after they are first assigned,
then the "256*PEEK(K+2)+PEEK(K+1)" address values pointing to the
actual text will NOT change.  Those addresses will be pointing
back to the actual string text in the BASIC program (which
doesn't move around during program execution).

This is an optimization BASIC makes.  When strings are first
assigned, the variable is created with an address pointing to the
actual string text.  The initial value simply points to the BASIC
program.  If the contents of that string variable are changed
after that point, then BASIC moves the text into high RAM to make
the modification.  Otherwise the text simply lives in the BASIC
program.

So you could create an array of pre-calculated addresses as follows:

10 DIM
A$(3):DIMK(3):A$(0)="blah0":A$(1)="blah1":A$(2)="blah2":A$(3)="blah3"
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
30 REM
40 REM Now any variable can be created and the values in K() will
still be correct.

Ken


On 5/29/18 9:25 AM, Stephen Adolph wrote:

John, I wasn't able to declare variables in any meaningful way
to solve this problem. Only assignment seemed to work.  Do you
know a trick for that?
steve

On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis
mailto:jho...@pobox.com>> wrote:


On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt
mailto:bir...@soigeneris.com>> wrote:

>>> Anytime a new scalar (i.e. non-array) variable is
created, the addresses of the array variables must all
change to make room for the new scalar variable.

So BASIC copies all the arrays to a new memory address?
That does not seem very efficient.

Jeff


I think it’s a trade off. Extra levels of indirection are
also inefficient.

It’s either take the hit on a “move” when a variable is
created  or take a guaranteed hit every variable access.

And you can avoid the cost by declaring your variables up front.

— John.












Re: [M100] interesting VARPTR bug

2018-05-29 Thread Ken Pettit

Hi Steve,

The line:

20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)

Doesn't work because you take the value of VARPTR(A$(0)) and assign it 
to F.  But then you assign the value of K.  This creates a new scalar 
variable, causing A$(0) to be moved.  So then the 
"256*PEEK(F+2)+PEEK(F+1)" fails because K is pointing to the old 
location for A$(0).


If you change your line as follows, then it should work because K is 
created first, causing A$() to be moved, and *then* you take the address 
of A$():


20 K=0:F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)

Ken

On 5/29/18 3:43 PM, Stephen Adolph wrote:
Ken, when I first read your code I said "That wont work and k(0) will 
be wrong."


however it seems to work.

I cannot explain why your code works and my original code did not.  I 
never modify the string content.


-
your line:
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT

compared with
20 F=VARPTR(A$(0)):*K(0)*=256*PEEK(F+2)+PEEK(F+1)

yield the same answers for K(0)

---
your line:
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT

compared with
20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)

yield different answers for K, K(0)
the only difference is using K vs K(0).


I still don't know a good rule for how to safely use VARPTR!!







On Tue, May 29, 2018 at 4:52 PM, Ken Pettit > wrote:


Steve,

Are you are trying to pre-calculate the addresses of the strings
to save time or something?

One thing to note is that the address of the A$() or D$() array
variable will move around in RAM.  However, as long as you don't
modify the strings *in* the array after they are first assigned,
then the "256*PEEK(K+2)+PEEK(K+1)" address values pointing to the
actual text will NOT change.  Those addresses will be pointing
back to the actual string text in the BASIC program (which doesn't
move around during program execution).

This is an optimization BASIC makes.  When strings are first
assigned, the variable is created with an address pointing to the
actual string text.  The initial value simply points to the BASIC
program.  If the contents of that string variable are changed
after that point, then BASIC moves the text into high RAM to make
the modification.  Otherwise the text simply lives in the BASIC
program.

So you could create an array of pre-calculated addresses as follows:

10 DIM
A$(3):DIMK(3):A$(0)="blah0":A$(1)="blah1":A$(2)="blah2":A$(3)="blah3"
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
30 REM
40 REM Now any variable can be created and the values in K() will
still be correct.

Ken


On 5/29/18 9:25 AM, Stephen Adolph wrote:

John, I wasn't able to declare variables in any meaningful way to
solve this problem. Only assignment seemed to work.  Do you know
a trick for that?
steve

On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis
mailto:jho...@pobox.com>> wrote:


On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt
mailto:bir...@soigeneris.com>> wrote:

>>> Anytime a new scalar (i.e. non-array) variable is
created, the addresses of the array variables must all
change to make room for the new scalar variable.

So BASIC copies all the arrays to a new memory address?
That does not seem very efficient.

Jeff


I think it’s a trade off. Extra levels of indirection are
also inefficient.

It’s either take the hit on a “move” when a variable is
created  or take a guaranteed hit every variable access.

And you can avoid the cost by declaring your variables up front.

— John.










Re: [M100] interesting VARPTR bug

2018-05-29 Thread Stephen Adolph
Ken, when I first read your code I said "That wont work and k(0) will be
wrong."

however it seems to work.

I cannot explain why your code works and my original code did not.  I never
modify the string content.

-
your line:
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT

compared with
20 F=VARPTR(A$(0)):*K(0)*=256*PEEK(F+2)+PEEK(F+1)

yield the same answers for K(0)

---
your line:
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT

compared with
20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1)

yield different answers for K, K(0)
the only difference is using K vs K(0).


I still don't know a good rule for how to safely use VARPTR!!







On Tue, May 29, 2018 at 4:52 PM, Ken Pettit  wrote:

> Steve,
>
> Are you are trying to pre-calculate the addresses of the strings to save
> time or something?
>
> One thing to note is that the address of the A$() or D$() array variable
> will move around in RAM.  However, as long as you don't modify the strings
> *in* the array after they are first assigned, then the
> "256*PEEK(K+2)+PEEK(K+1)" address values pointing to the actual text will
> NOT change.  Those addresses will be pointing back to the actual string
> text in the BASIC program (which doesn't move around during program
> execution).
>
> This is an optimization BASIC makes.  When strings are first assigned, the
> variable is created with an address pointing to the actual string text.
> The initial value simply points to the BASIC program.  If the contents of
> that string variable are changed after that point, then BASIC moves the
> text into high RAM to make the modification.  Otherwise the text simply
> lives in the BASIC program.
>
> So you could create an array of pre-calculated addresses as follows:
>
> 10 DIM A$(3):DIMK(3):A$(0)="blah0":A$(1)="blah1":A$(2)="blah2":A$(
> 3)="blah3"
> 20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
> 30 REM
> 40 REM Now any variable can be created and the values in K() will still be
> correct.
>
> Ken
>
>
> On 5/29/18 9:25 AM, Stephen Adolph wrote:
>
> John, I wasn't able to declare variables in any meaningful way to solve
> this problem. Only assignment seemed to work.  Do you know a trick for that?
> steve
>
> On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis 
> wrote:
>
>>
>> On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt 
>> wrote:
>>
>>> >>> Anytime a new scalar (i.e. non-array) variable is created, the
>>> addresses of the array variables must all change to make room for the new
>>> scalar variable.
>>>
>>>
>>>
>>> So BASIC copies all the arrays to a new memory address? That does not
>>> seem very efficient.
>>>
>>>
>>>
>>> Jeff
>>>
>>>
>>>
>>
>> I think it’s a trade off. Extra levels of indirection are also
>> inefficient.
>>
>> It’s either take the hit on a “move” when a variable is created  or take
>> a guaranteed hit every variable access.
>>
>> And you can avoid the cost by declaring your variables up front.
>>
>> — John.
>>
>>
>>
>
>


Re: [M100] interesting VARPTR bug

2018-05-29 Thread Ken Pettit

Steve,

Are you are trying to pre-calculate the addresses of the strings to save 
time or something?


One thing to note is that the address of the A$() or D$() array variable 
will move around in RAM.  However, as long as you don't modify the 
strings *in* the array after they are first assigned, then the 
"256*PEEK(K+2)+PEEK(K+1)" address values pointing to the actual text 
will NOT change.  Those addresses will be pointing back to the actual 
string text in the BASIC program (which doesn't move around during 
program execution).


This is an optimization BASIC makes.  When strings are first assigned, 
the variable is created with an address pointing to the actual string 
text.  The initial value simply points to the BASIC program.  If the 
contents of that string variable are changed after that point, then 
BASIC moves the text into high RAM to make the modification.  Otherwise 
the text simply lives in the BASIC program.


So you could create an array of pre-calculated addresses as follows:

10 DIM A$(3):DIMK(3):A$(0)="blah0":A$(1)="blah1":A$(2)="blah2":A$(3)="blah3"
20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=256*PEEK(F+2)+PEEK(F+1):NEXT
30 REM
40 REM Now any variable can be created and the values in K() will still 
be correct.


Ken

On 5/29/18 9:25 AM, Stephen Adolph wrote:
John, I wasn't able to declare variables in any meaningful way to 
solve this problem. Only assignment seemed to work.  Do you know a 
trick for that?

steve

On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis > wrote:



On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt
mailto:bir...@soigeneris.com>> wrote:

>>> Anytime a new scalar (i.e. non-array) variable is created,
the addresses of the array variables must all change to make
room for the new scalar variable.

So BASIC copies all the arrays to a new memory address? That
does not seem very efficient.

Jeff


I think it’s a trade off. Extra levels of indirection are also
inefficient.

It’s either take the hit on a “move” when a variable is created
 or take a guaranteed hit every variable access.

And you can avoid the cost by declaring your variables up front.

— John.







Re: [M100] interesting VARPTR bug

2018-05-29 Thread Diggy Dude
I read something last night that gave me the impression the moving array
thing applies to BASIC generally, not just the M100.

On Tue, May 29, 2018 at 11:56 AM, John R. Hogerhuis 
wrote:

>
> On Tue, May 29, 2018 at 9:25 AM Stephen Adolph 
> wrote:
>
>> John, I wasn't able to declare variables in any meaningful way to solve
>> this problem. Only assignment seemed to work.  Do you know a trick for that?
>> steve
>>
>
> No I think you’re probably right, storage attaches and variables move when
> you assign a value for the first time. So in your case you only need to
> assign the F variable early on in the program. It’s a special case since
> otherwise it gets created after VARPTR is called and moves the array.
>
> No other variables (than the array itself) matter in your case unless you
> want to store the result of VARPTR.
>
> — John.
>


Re: [M100] interesting VARPTR bug

2018-05-29 Thread John R. Hogerhuis
On Tue, May 29, 2018 at 9:25 AM Stephen Adolph  wrote:

> John, I wasn't able to declare variables in any meaningful way to solve
> this problem. Only assignment seemed to work.  Do you know a trick for that?
> steve
>

No I think you’re probably right, storage attaches and variables move when
you assign a value for the first time. So in your case you only need to
assign the F variable early on in the program. It’s a special case since
otherwise it gets created after VARPTR is called and moves the array.

No other variables (than the array itself) matter in your case unless you
want to store the result of VARPTR.

— John.


Re: [M100] interesting VARPTR bug

2018-05-29 Thread Stephen Adolph
John, I wasn't able to declare variables in any meaningful way to solve
this problem. Only assignment seemed to work.  Do you know a trick for that?
steve

On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis 
wrote:

>
> On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt 
> wrote:
>
>> >>> Anytime a new scalar (i.e. non-array) variable is created, the
>> addresses of the array variables must all change to make room for the new
>> scalar variable.
>>
>>
>>
>> So BASIC copies all the arrays to a new memory address? That does not
>> seem very efficient.
>>
>>
>>
>> Jeff
>>
>>
>>
>
> I think it’s a trade off. Extra levels of indirection are also
> inefficient.
>
> It’s either take the hit on a “move” when a variable is created  or take a
> guaranteed hit every variable access.
>
> And you can avoid the cost by declaring your variables up front.
>
> — John.
>
>
>


Re: [M100] interesting VARPTR bug

2018-05-29 Thread John R. Hogerhuis
On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt  wrote:

> >>> Anytime a new scalar (i.e. non-array) variable is created, the
> addresses of the array variables must all change to make room for the new
> scalar variable.
>
>
>
> So BASIC copies all the arrays to a new memory address? That does not seem
> very efficient.
>
>
>
> Jeff
>
>
>

I think it’s a trade off. Extra levels of indirection are also inefficient.

It’s either take the hit on a “move” when a variable is created  or take a
guaranteed hit every variable access.

And you can avoid the cost by declaring your variables up front.

— John.


Re: [M100] interesting VARPTR bug

2018-05-29 Thread Ken Pettit

On 5/29/18 5:13 AM, Jeffrey Birt wrote:


>>> Anytime a new scalar (i.e. non-array) variable is created, the 
addresses of the array variables must all change to make room for the 
new scalar variable.


So BASIC copies all the arrays to a new memory address? That does not 
seem very efficient.




Hey Jeff,

Yeah, the M100 does a lot of stuff that is inefficient like this to 
maintain it's RAM filesystem.  Adding / removing any bytes from a BASIC 
program will cause the ROM to copy all TEXT and .CO files to a new 
memory address, plus any BASIC programs that exist past the edit.  
Likewise, editing any TEXT document will cause the ROM to copy all .CO 
files to a new memory address, plus any TEXT files past the edit point.


Actually when you enter TEXT, the ROM expands the .DO file being edited 
such that it occupies the remaining free RAM.  It does this by copying 
all files past the edit point to the highest RAM location possible.  
That way individual keystroke edits don't have to perform copy, copy, 
copy operations.  Then when you exit, it shrinks the file back to the 
minimum size and copies .CO and higher RAM TEXT files back down to their 
new location in RAM.


In general, files / Data in RAM are ALWAYS stored in the order and RAM 
is copied as needed to ensure this order is maintained:


.BA
Unsaved BASIC program
.DO
.CO
BASIC scalar variables
BASIC string variables
BASIC array variables

The ROM maintains a RAM pointer containing the start address of each of 
these location, and it has a routine to recalculate each of those 
pointers that it can call as needed (i.e. when you want to edit a 
specific TEXT file, etc.).


Ken



Re: [M100] interesting VARPTR bug

2018-05-29 Thread Jeffrey Birt
>>> Anytime a new scalar (i.e. non-array) variable is created, the addresses of 
>>> the array variables must all change to make room for the new scalar 
>>> variable. 

 

So BASIC copies all the arrays to a new memory address? That does not seem very 
efficient.

 

Jeff

 

From: M100  On Behalf Of Ken Pettit
Sent: Monday, May 28, 2018 10:24 PM
To: m...@bitchin100.com
Subject: Re: [M100] interesting VARPTR bug

 

Steve,

John is correct.  Array variables are stored at a higher memory address than 
scalar variables.  Anytime a new scalar (i.e. non-array) variable is created, 
the addresses of the array variables must all change to make room for the new 
scalar variable.  So the return value from VARPTR for array variables is only 
valid for as long a there are no new scalar variables delcared.

Ken

On 5/28/18 4:37 PM, Stephen Adolph wrote:

sounds plausible.

 

for reference here is the code. I have 4 embedded ML programs that I want to 
select to run.

 

2 REM good command sequence
3 A$(0)="using good sequence":D$(0)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77~2ÀüûÉ"
4 REM bad command sequence  add 7 after 4@
5 A$(1)="using bad sequence1":D$(1)="ó:@ð:@ð:¸ð:òð:4ð7:°ð:1ð:¿ð77~2ÀüûÉ"
6 REM bad command sequence 2 add 7 after 77
7 A$(2)="using bad sequence2":D$(2)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77&~2ÀüûÉ"
8 REM bad command sequence 3 remove 7 from 77
9 A$(3)="using bad sequence3":D$(3)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð7~2ÀüûÉ"
10 CLS:PRINT"Send command + data to REXCPM"
11 INPUT"select command sequence (1-4)";S:IF S<1 OR S>4 THEN 10
12 S=S-1
20 PRINT A$(S):F=0:K=VARPTR(D$(S)):F=256*PEEK(K+2)+PEEK(K+1)
21 PRINTF
22 FORI=1TOLEN(D$(S)):IF ASC(MID$(D$(S),I,1)) <> PEEK(F+I-1) THEN 
BEEP:PRINT"bad!":END
23 NEXTI:PRINT"good!!"
30 INPUT"Enter command byte";L
40 INPUT"enter data byte";H
50 CALLF,0,256*H+L
60 PRINT"result = ";PEEK(64704)
70 PRINT"hit any key to repeat"
80 IFINKEY$=""THEN 80
90 GOTO10

 

On Mon, May 28, 2018 at 7:36 PM, John R. Hogerhuis mailto:jho...@pobox.com> > wrote:

 

On Mon, May 28, 2018 at 4:29 PM Stephen Adolph mailto:twospru...@gmail.com> > wrote:

yes, I do have a dim but ..not sure it matters though. I think I tried with and 
without.

 

Hmm. Not sure how the basic variable allocator works. But if putting F=0 makes 
it work or not work I suspect that assigning F for the first time creates a new 
variable and caused the array to move.

 

DIM’ing either or both, or assigning a value like you did might resolve. 

 

Whether that’s a bug I don’t know. Maybe you just need to be careful not to 
allocate variables between when you take VARPTR and when you use it the 
address. 

 

— John 

 

 



Re: [M100] interesting VARPTR bug

2018-05-29 Thread Stephen Adolph
The manual mentions something to this effect.  What is tricky is
understanding when it works and when it breaks.
As a rule, if every variable used in a program is assigned once before
using VARPTR then you are for sure safe.

I guess using VARPTR with array variables complicates things.


On Tue, May 29, 2018 at 12:04 AM, Ken Pettit  wrote:

> One other interesting thing about BASIC variables.  A, A%, A%, A(1), A$(1)
> and A%(1) are all different variables and can exist at the same time with
> different values.
>
> Ken
>
>
> On 5/28/18 4:55 PM, John R. Hogerhuis wrote:
>
>
>
> On Mon, May 28, 2018 at 4:43 PM, Stephen Adolph 
> wrote:
>
>> I think you must be right John,
>> because this line works
>>
>> 20 PRINT A$(S):F=256*PEEK( VARPTR(D$(S)) +2)+PEEK( VARPTR(D$(S)) +1)
>>
>>
> Yeah, the theory being that F as a left-hand-side of a (implied) LET
> allocates F before the (two) VARPTR operations. I suspect if you DIM your
> variables up front it would work either way. And you could DIM your numeric
> variables as INT (%)  and save a tiny bit of space / execution time.
>
> -- John.
>
>
>


Re: [M100] interesting VARPTR bug

2018-05-28 Thread Ken Pettit
One other interesting thing about BASIC variables.  A, A%, A%, A(1), 
A$(1) and A%(1) are all different variables and can exist at the same 
time with different values.


Ken

On 5/28/18 4:55 PM, John R. Hogerhuis wrote:



On Mon, May 28, 2018 at 4:43 PM, Stephen Adolph > wrote:


I think you must be right John,
because this line works

20 PRINT A$(S):F=256*PEEK( VARPTR(D$(S)) +2)+PEEK( VARPTR(D$(S)) +1)


Yeah, the theory being that F as a left-hand-side of a (implied) LET 
allocates F before the (two) VARPTR operations. I suspect if you DIM 
your variables up front it would work either way. And you could DIM 
your numeric variables as INT (%)  and save a tiny bit of space / 
execution time.


-- John.




Re: [M100] interesting VARPTR bug

2018-05-28 Thread Ken Pettit

Steve,

John is correct.  Array variables are stored at a higher memory address 
than scalar variables.  Anytime a new scalar (i.e. non-array) variable 
is created, the addresses of the array variables must all change to make 
room for the new scalar variable.  So the return value from VARPTR for 
array variables is only valid for as long a there are no new scalar 
variables delcared.


Ken

On 5/28/18 4:37 PM, Stephen Adolph wrote:

sounds plausible.

for reference here is the code. I have 4 embedded ML programs that I 
want to select to run.


2 REM good command sequence
3 A$(0)="using good sequence":D$(0)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77~2ÀüûÉ"
4 REM bad command sequence  add 7 after 4@
5 A$(1)="using bad sequence1":D$(1)="ó:@ð:@ð:¸ð:òð:4ð7:°ð:1ð:¿ð77~2ÀüûÉ"
6 REM bad command sequence 2 add 7 after 77
7 A$(2)="using bad sequence2":D$(2)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77&~2ÀüûÉ"
8 REM bad command sequence 3 remove 7 from 77
9 A$(3)="using bad sequence3":D$(3)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð7~2ÀüûÉ"
10 CLS:PRINT"Send command + data to REXCPM"
11 INPUT"select command sequence (1-4)";S:IF S<1 OR S>4 THEN 10
12 S=S-1
20 PRINT A$(S):F=0:K=VARPTR(D$(S)):F=256*PEEK(K+2)+PEEK(K+1)
21 PRINTF
22 FORI=1TOLEN(D$(S)):IF ASC(MID$(D$(S),I,1)) <> PEEK(F+I-1) THEN 
BEEP:PRINT"bad!":END

23 NEXTI:PRINT"good!!"
30 INPUT"Enter command byte";L
40 INPUT"enter data byte";H
50 CALLF,0,256*H+L
60 PRINT"result = ";PEEK(64704)
70 PRINT"hit any key to repeat"
80 IFINKEY$=""THEN 80
90 GOTO10


On Mon, May 28, 2018 at 7:36 PM, John R. Hogerhuis > wrote:



On Mon, May 28, 2018 at 4:29 PM Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

yes, I do have a dim but ..not sure it matters though. I think
I tried with and without.


Hmm. Not sure how the basic variable allocator works. But if
putting F=0 makes it work or not work I suspect that assigning F
for the first time creates a new variable and caused the array to
move.

DIM’ing either or both, or assigning a value like you did might
resolve.

Whether that’s a bug I don’t know. Maybe you just need to be
careful not to allocate variables between when you take VARPTR and
when you use it the address.

— John






Re: [M100] interesting VARPTR bug

2018-05-28 Thread John R. Hogerhuis
On Mon, May 28, 2018 at 4:43 PM, Stephen Adolph 
wrote:

> I think you must be right John,
> because this line works
>
> 20 PRINT A$(S):F=256*PEEK( VARPTR(D$(S)) +2)+PEEK( VARPTR(D$(S)) +1)
>
>
Yeah, the theory being that F as a left-hand-side of a (implied) LET
allocates F before the (two) VARPTR operations. I suspect if you DIM your
variables up front it would work either way. And you could DIM your numeric
variables as INT (%)  and save a tiny bit of space / execution time.

-- John.


Re: [M100] interesting VARPTR bug

2018-05-28 Thread Stephen Adolph
sounds plausible.

for reference here is the code. I have 4 embedded ML programs that I want
to select to run.

2 REM good command sequence
3 A$(0)="using good sequence":D$(0)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77~2ÀüûÉ"
4 REM bad command sequence  add 7 after 4@
5 A$(1)="using bad sequence1":D$(1)="ó:@ð:@ð:¸ð:òð:4ð7:°ð:1ð:¿ð77~2ÀüûÉ"
6 REM bad command sequence 2 add 7 after 77
7 A$(2)="using bad sequence2":D$(2)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77&~2ÀüûÉ"
8 REM bad command sequence 3 remove 7 from 77
9 A$(3)="using bad sequence3":D$(3)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð7~2ÀüûÉ"
10 CLS:PRINT"Send command + data to REXCPM"
11 INPUT"select command sequence (1-4)";S:IF S<1 OR S>4 THEN 10
12 S=S-1
20 PRINT A$(S):F=0:K=VARPTR(D$(S)):F=256*PEEK(K+2)+PEEK(K+1)
21 PRINTF
22 FORI=1TOLEN(D$(S)):IF ASC(MID$(D$(S),I,1)) <> PEEK(F+I-1) THEN
BEEP:PRINT"bad!":END
23 NEXTI:PRINT"good!!"
30 INPUT"Enter command byte";L
40 INPUT"enter data byte";H
50 CALLF,0,256*H+L
60 PRINT"result = ";PEEK(64704)
70 PRINT"hit any key to repeat"
80 IFINKEY$=""THEN 80
90 GOTO10


On Mon, May 28, 2018 at 7:36 PM, John R. Hogerhuis  wrote:

>
> On Mon, May 28, 2018 at 4:29 PM Stephen Adolph 
> wrote:
>
>> yes, I do have a dim but ..not sure it matters though. I think I tried
>> with and without.
>>
>
> Hmm. Not sure how the basic variable allocator works. But if putting F=0
> makes it work or not work I suspect that assigning F for the first time
> creates a new variable and caused the array to move.
>
> DIM’ing either or both, or assigning a value like you did might resolve.
>
> Whether that’s a bug I don’t know. Maybe you just need to be careful not
> to allocate variables between when you take VARPTR and when you use it the
> address.
>
> — John
>


Re: [M100] interesting VARPTR bug

2018-05-28 Thread Stephen Adolph
I think you must be right John,
because this line works

20 PRINT A$(S):F=256*PEEK( VARPTR(D$(S)) +2)+PEEK( VARPTR(D$(S)) +1)



On Mon, May 28, 2018 at 7:37 PM, Stephen Adolph 
wrote:

> sounds plausible.
>
> for reference here is the code. I have 4 embedded ML programs that I want
> to select to run.
>
> 2 REM good command sequence
> 3 A$(0)="using good sequence":D$(0)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77~2ÀüûÉ"
> 4 REM bad command sequence  add 7 after 4@
> 5 A$(1)="using bad sequence1":D$(1)="ó:@ð:@ð:¸ð:òð:4ð7:°ð:1ð:¿ð77~2ÀüûÉ"
> 6 REM bad command sequence 2 add 7 after 77
> 7 A$(2)="using bad sequence2":D$(2)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77&~2ÀüûÉ"
> 8 REM bad command sequence 3 remove 7 from 77
> 9 A$(3)="using bad sequence3":D$(3)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð7~2ÀüûÉ"
> 10 CLS:PRINT"Send command + data to REXCPM"
> 11 INPUT"select command sequence (1-4)";S:IF S<1 OR S>4 THEN 10
> 12 S=S-1
> 20 PRINT A$(S):F=0:K=VARPTR(D$(S)):F=256*PEEK(K+2)+PEEK(K+1)
> 21 PRINTF
> 22 FORI=1TOLEN(D$(S)):IF ASC(MID$(D$(S),I,1)) <> PEEK(F+I-1) THEN
> BEEP:PRINT"bad!":END
> 23 NEXTI:PRINT"good!!"
> 30 INPUT"Enter command byte";L
> 40 INPUT"enter data byte";H
> 50 CALLF,0,256*H+L
> 60 PRINT"result = ";PEEK(64704)
> 70 PRINT"hit any key to repeat"
> 80 IFINKEY$=""THEN 80
> 90 GOTO10
>
>
> On Mon, May 28, 2018 at 7:36 PM, John R. Hogerhuis 
> wrote:
>
>>
>> On Mon, May 28, 2018 at 4:29 PM Stephen Adolph 
>> wrote:
>>
>>> yes, I do have a dim but ..not sure it matters though. I think I tried
>>> with and without.
>>>
>>
>> Hmm. Not sure how the basic variable allocator works. But if putting F=0
>> makes it work or not work I suspect that assigning F for the first time
>> creates a new variable and caused the array to move.
>>
>> DIM’ing either or both, or assigning a value like you did might resolve.
>>
>> Whether that’s a bug I don’t know. Maybe you just need to be careful not
>> to allocate variables between when you take VARPTR and when you use it the
>> address.
>>
>> — John
>>
>
>


Re: [M100] interesting VARPTR bug

2018-05-28 Thread John R. Hogerhuis
On Mon, May 28, 2018 at 4:29 PM Stephen Adolph  wrote:

> yes, I do have a dim but ..not sure it matters though. I think I tried
> with and without.
>

Hmm. Not sure how the basic variable allocator works. But if putting F=0
makes it work or not work I suspect that assigning F for the first time
creates a new variable and caused the array to move.

DIM’ing either or both, or assigning a value like you did might resolve.

Whether that’s a bug I don’t know. Maybe you just need to be careful not to
allocate variables between when you take VARPTR and when you use it the
address.

— John


Re: [M100] interesting VARPTR bug

2018-05-28 Thread Stephen Adolph
yes, I do have a dim but ..not sure it matters though. I think I tried with
and without.

On Mon, May 28, 2018 at 6:54 PM, John R. Hogerhuis  wrote:

> I assume you DIM A$ somewhere else?
>
> — John.
>


Re: [M100] interesting VARPTR bug

2018-05-28 Thread John R. Hogerhuis
I assume you DIM A$ somewhere else?

— John.


Re: [M100] Interesting 102

2015-03-26 Thread Kurt McCullum
Here is what I found out about it. Sounds like a custom option rom to me. Other 
than that, I'd say it's a standard 102 with a new name badge.
-
Statimate-II SPC software is available for running on IBM-compatible or Tandy 
Model 102 computers ($395), and networked for information sharing ($495). When 
networked, an operator can transfer collected data to a supervisor's computer 
for review or printing, eliminating the need for "data trucks" as used by other 
SPC systems.

A complete starter network with three remote stations, supervisor station, 
printer, software, and network cabling is also offered, along with enclosures 
and hardened computers for harsh environments.

Statimate Systems Inc, 3216 W St Joseph, Lansing, MI 48917. 
-

Kurt

On Thu, 3/26/15, Kurt McCullum  wrote:

 Subject: Interesting 102
 To: "Model Discussion" 
 Date: Thursday, March 26, 2015, 8:05 AM
 
 I saw this on eBay this morning. Does
 anybody know what Statimate Systems was?
 
 
http://www.ebay.com/itm/Vintage-Statimate-Systems-Tandy-102-Personal-Portable-Computer-w-Manual-/151630324841?pt=LH_DefaultDomain_0&hash=item234ddf2469
 
 Kurt
 


Re: [M100] Interesting 102

2015-03-26 Thread bogus maximus
Besides, it's more difficult to get a non-standard ROM in the T102, since
the ROM is not socketed.  Maybe there's a custom option ROM?

On Thu, Mar 26, 2015 at 9:31 AM, Gmail  wrote:

> Except the picture of the LCD shows the standard OS stuff.
>
> Ken
>
> Sent from my iPhone
>
> > On Mar 26, 2015, at 9:25 AM, Frederick Whitaker 
> wrote:
> >
> > If it is what I think it is, it ha a non standard ROM and may not do
> anything do anything else.
> >
> > Fred W
> >
> > Sent from my iPhone
> >
> >> On Mar 26, 2015, at 12:22 PM, Ken Pettit  wrote:
> >>
> >> Based on the name, graphics and headings on the manual, I would say
> it's a statistics program.  But I had never heard of it before.
> >>
> >> Ken
>


Re: [M100] Interesting 102

2015-03-26 Thread Gmail
Except the picture of the LCD shows the standard OS stuff.

Ken

Sent from my iPhone

> On Mar 26, 2015, at 9:25 AM, Frederick Whitaker  wrote:
> 
> If it is what I think it is, it ha a non standard ROM and may not do anything 
> do anything else.
> 
> Fred W
> 
> Sent from my iPhone
> 
>> On Mar 26, 2015, at 12:22 PM, Ken Pettit  wrote:
>> 
>> Based on the name, graphics and headings on the manual, I would say it's a 
>> statistics program.  But I had never heard of it before.
>> 
>> Ken


Re: [M100] Interesting 102

2015-03-26 Thread Frederick Whitaker
If it is what I think it is, it ha a non standard ROM and may not do anything 
do anything else.

Fred W

Sent from my iPhone

On Mar 26, 2015, at 12:22 PM, Ken Pettit  wrote:

> Based on the name, graphics and headings on the manual, I would say it's a 
> statistics program.  But I had never heard of it before.
> 
> Ken


Re: [M100] Interesting 102

2015-03-26 Thread Ken Pettit
Based on the name, graphics and headings on the manual, I would say it's a
statistics program.  But I had never heard of it before.

Ken