Re: [M100] interesting

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

Re: [M100] interesting

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

Re: [M100] interesting

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

Re: [M100] interesting

ome 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

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

Re: [M100] interesting

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

Re: [M100] interesting

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

Re: [M100] interesting

. 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

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

Re: [M100] interesting

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 aut

[M100] interesting

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

Re: [M100] Interesting m-100 clone

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 s

Re: [M100] Interesting m-100 clone

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

Re: [M100] Interesting m-100 clone

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,

Re: [M100] Interesting m-100 clone

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 ru

Re: [M100] Interesting m-100 clone

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

[M100] Interesting m-100 clone

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

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

Re: [M100] interesting VARPTR bug

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

Re: [M100] interesting VARPTR bug

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 be

Re: [M100] interesting VARPTR bug

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)=25

Re: [M100] interesting VARPTR bug

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,

Re: [M100] interesting VARPTR bug

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 a

Re: [M100] interesting VARPTR bug

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

Re: [M100] interesting VARPTR bug

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

Re: [M100] interesting VARPTR bug

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 see

Re: [M100] interesting VARPTR bug

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.

Re: [M100] interesting VARPTR bug

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

Re: [M100] interesting VARPTR bug

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

Re: [M100] interesting VARPTR bug

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

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

Re: [M100] interesting VARPTR bug

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

Re: [M100] interesting VARPTR bug

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)="ó:@ð:@ð

Re: [M100] interesting VARPTR bug

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

Re: [M100] interesting VARPTR bug

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 cr

Re: [M100] interesting VARPTR bug

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

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

[M100] interesting VARPTR bug

I found something odd about VARPTR. I have a matrix of strings A$(x) where x is 0 to 2 for example. If I use the statement: K=VARPTR(A$(S)):F=256*PEEK(K+2)+PEEK(K+1) to derive the location for the data in memory, I get incorrect results. If however I do this: F=0:K=VARPTR(A$(S)):F=256*PEEK(K+2)

Re: [M100] Interesting 102

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-

Re: [M100] Interesting 102

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,

Re: [M100] Interesting 102

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 2

Re: [M100] Interesting 102

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

Re: [M100] Interesting 102

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

[M100] Interesting 102

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