[M100] batteries...

2018-03-06 Thread Gregory McGill
so I decided to take apart my m100 that has 8k of ram to see what's in
there and what I find is acid it looks like it may have not left the
battery just yet so snipped that thing out of there and cleaned up with
some vinegar etc..

need the battery source now :)  also is there a ram module source since we
can't get quads?


Re: [M100] BASIC 10Liners

2018-03-06 Thread Gregory McGill
yeah I threw it on cloudt to try it :)

Greg

On Tue, Mar 6, 2018 at 7:31 PM, Kevin Becker  wrote:

> Was that on actual hardware?  I tried to tune it so that I could wail on
> the keys as fast as I could and didn't get off the black bar on both my
> real M102 and VirtualT set explicitly to 2.4Mhz.  Maybe it needs more
> tweaking though, lol.
>
>
>
> On Tue, Mar 6, 2018 at 9:35 PM, Gregory McGill 
> wrote:
>
>> cool.. i jumped around to the other side! :)
>>
>> Greg
>>
>>
>> On Tue, Mar 6, 2018 at 5:18 PM, John R. Hogerhuis 
>> wrote:
>>
>>>
>>> On Tue, Mar 6, 2018 at 3:43 PM Ken Pettit  wrote:
>>>

 On 3/6/18 2:19 PM, John R. Hogerhuis wrote:
 >
 > Ah. Well, CloudT dynamically inserts delays to simulate the Model T
 > processor speed. If you look at the number at the bottom of the screen
 > it should over around 2.4Mhz. But being written in Javascript and
 > running off timer event callbacks, I can't get cycle accuracy.
 >

 Ahh, that's how you are emulating the 2.4MHz speed.  I was wondering.
 What do you use to determine the number of cycles to dynamically delay?

>>>
>>>
>>> Well it’s basically on cpu cycles per instruction. There are definitely
>>> some inaccuracies beyond just the JavaScript event driven model (I don’t
>>> get to be the only code on my thread or get a guaranteed time slice).  But
>>> it ought to be close enough.
>>>
>>> The JUMP game seems to work off how fast inkey$ runs. I am guessing the
>>> issue is that CloudT does some queueing beyond what the model t provides
>>> due to some very fancy keyboard stuff going on in mobile browsers
>>> (predictive text and such). So keys batch up and allow the man run faster
>>> than he should.
>>>
>>> — John.
>>>
>>
>>
>


Re: [M100] BASIC 10Liners

2018-03-06 Thread Gregory McGill
cool.. i jumped around to the other side! :)

Greg


On Tue, Mar 6, 2018 at 5:18 PM, John R. Hogerhuis  wrote:

>
> On Tue, Mar 6, 2018 at 3:43 PM Ken Pettit  wrote:
>
>>
>> On 3/6/18 2:19 PM, John R. Hogerhuis wrote:
>> >
>> > Ah. Well, CloudT dynamically inserts delays to simulate the Model T
>> > processor speed. If you look at the number at the bottom of the screen
>> > it should over around 2.4Mhz. But being written in Javascript and
>> > running off timer event callbacks, I can't get cycle accuracy.
>> >
>>
>> Ahh, that's how you are emulating the 2.4MHz speed.  I was wondering.
>> What do you use to determine the number of cycles to dynamically delay?
>>
>
>
> Well it’s basically on cpu cycles per instruction. There are definitely
> some inaccuracies beyond just the JavaScript event driven model (I don’t
> get to be the only code on my thread or get a guaranteed time slice).  But
> it ought to be close enough.
>
> The JUMP game seems to work off how fast inkey$ runs. I am guessing the
> issue is that CloudT does some queueing beyond what the model t provides
> due to some very fancy keyboard stuff going on in mobile browsers
> (predictive text and such). So keys batch up and allow the man run faster
> than he should.
>
> — John.
>


Re: [M100] Bar code reader with REX / M100 Digest, Vol 87, Issue 2

2018-03-06 Thread Gregory McGill
picked up two for 13ea off ebay, work great

Greg

On Fri, Mar 2, 2018 at 8:50 AM, Gregory McGill 
wrote:

> they are 29$ new on newegg
>
> On Fri, Mar 2, 2018 at 4:49 AM, Anthony Coghlan 
> wrote:
>
>> Thanks, Peter. I think I’m going to try the barcode reader you use if I
>> can get it on eBay cheaply, as it may be more reliable anyway.  Perhaps I
>> have to try loading the driver and program with REX temporarily disabled as
>> an experiment.  I suspect a conflict in memory and don’t otherwise know how
>> to resolve that.
>>
>> Best wishes,
>> Anthony
>>
>>
>>
>> On Friday, March 2, 2018, Peter Noeth  wrote:
>>
>>> I don't have a REX in my M102, but I have been using the BCR to do
>>> "pantry" and "wine cellar" inventory. Both are in the basement, so are not
>>> readily accessible when one wants to know what is down there. I am not
>>> using the Radio Shack wand, but instead am using a UniTech
>>> MS120-NTCB00-SG "industrial strength" wand. It is "plug-in" compatible with
>>> the RS wand, and has a sapphire tip that doesn't abrade the barcode labels
>>> and keeps dust out of the wand. It also has better "dynamic range" so has
>>> no problems reading low contrast barcodes or ines in color. I am using the
>>> sample "Simple Inventory" program (with some modifications) that came with
>>> the RS Barcode Reader package. I read the "database" file into Excel
>>> and keep a printout in the kitchen. The program works well, and barcode
>>> reads are quite reliable once you get used to the swiping speed needed.
>>>
>>> As to your program conflicts, problem with many of the early computers
>>> with "operating systems" supplied by Microsoft, is the RAM driver concept
>>> is limited in practical use. Microsoft intended the RAM driver facility to
>>> patch a ROM driver that may have bugs or add additional planned system
>>> expansion (like the DVI, Bar Code Reader, TDD, Option ROM, etc.). Later
>>> third party developers who had a product that used their own RAM driver all
>>> seemed to locate them in the same address in memory (top of available RAM,
>>> the logical place to put it). This creates memory conflicts. Especially in
>>> computers using the Intel 8080/8085 processors that do not support
>>> "relative" addressing. Without relative addressing, the user cannot move a
>>> driver to a different starting address in memory without recompiling it
>>> first, and since the user does not get a copy of the source code, he is
>>> usually out of luck.
>>>
>>> There were a few attempts using programs that would read the code of the
>>> driver and attempt to find all of the JMP and CALL instructions and patch
>>> them directly to a new base starting address, but it was not always
>>> successful, as often times the driver would contain inline data bytes that
>>> would confuse the conversion program. These programs usually worked on
>>> computers using the Z80 processors, since it did support relative
>>> addressing.
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> 
>>>
>>> 
>>>
>>> Message: 14
>>> Date: Fri, 2 Mar 2018 00:57:07 -0500
>>> From: Anthony Coghlan 
>>> To: "m...@bitchin100.com" 
>>> Subject: Re: [M100] Bar code reader with REX
>>> Message-ID:
>>> >> ail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Yes, that was the drive belt I used also if I recall, made by Russell
>>> Industries.  I can?t find my old purchase info from eBay, but it was
>>> about
>>> $9 at the time.  (I think Brian mentioned that price as well.)  It was so
>>> nice to see the drive come to life!
>>>
>>> Best wishes,
>>> Anthony
>>>
>>>
>>> All on the list:  any tips on reliably using the bar code reader?
>>> Thanks.
>>> I?m threatening to inventory our pantry if I can get it working, though
>>> my
>>> wife doesn?t think that?s such a practical application...  :)
>>>
>>> 
>>>
>>>
>>>
>


Re: [M100] Bar code reader with REX

2018-03-06 Thread Gregory McGill
just tested mine with the new wands i got off ebay with rex and quad works
fine

Greg

On Sat, Mar 3, 2018 at 3:11 AM, Anthony Coghlan  wrote:

> Thanks, Willard - I'll give those suggestions a try.  Won't be this
> weekend, unfortunately - bunch of other things going on - but this
> information will be very helpful.  I like the idea of a BCR RAM image.  I
> can use it to keep the drivers, programs, and all my "valuable" inventory
> data!
>
> I was able to get the alternative barcode reader suggested elsewhere in
> the thread on eBay for about $20 used.  Sapphire tip, able to read reliably
> in a wider range of circumstances, and still quite sleek-looking - should
> be a good thing.
>
> Best wishes,
> Anthony
>
>
>
> On Sat, Mar 3, 2018 at 2:10 AM, Willard Goosey  wrote:
>
>> On Fri, 2 Mar 2018 15:46:55 -0500
>> Anthony Coghlan  wrote:
>>
>> (OK on a real keyboard now! :)
>>
>> > Willard, thanks for the confirmation that it’s not something inherent
>> > to trying to use REX and BCR at the same time.  That would be sad,
>> > because I like my REX...
>>
>> I agree, REX is awesome! The BCR is... kind of a neat toy? But yes they
>> work fine together for me. I've got a RAM image named BCR with all the
>> goodies!
>>
>> > I think I got the driver off Club 100 and
>> > transferred It with MComm.  I have the original cassette, too, but
>> > haven’t tried it.
>>
>> I know the versions in the UPS directory work, are those the ones
>> you're using?
>>
>> > Poke and reboot - could you tell me more, so I’ll get it right..?  :)
>> >  Thanks.  Otherwise, I’d just end up doing CALL 63012 a couple of
>> > times, perhaps not the desired / required steps.  Thanks again.
>>
>> Ahh... After a crash and reboot, go into BASIC:
>> POKE 62975,201
>>
>> then power cycle. This clears the timer hook REX uses.
>> Go into BASIC again and:
>> CALL 63012
>>
>> this will bring up REXMGR.
>>
>> (this is all in the REX wiki on bitchin100).
>>
>> (wow I had to look this up, it's been a couple of months since I
>> crashed the M100! Takin' a little break from SmallC-85 to explore RISC
>> OS :)
>>
>>
>> Hope this helps,
>> Willard
>> --
>> Willard Goosey  goo...@sdc.org
>> Socorro, New Mexico, USA
>> I search my heart and find Cimmeria, land of Darkness and the Night.
>>   -- R.E. Howard
>>
>
>


Re: [M100] BASIC 10Liners

2018-03-06 Thread John R. Hogerhuis
On Tue, Mar 6, 2018 at 3:43 PM Ken Pettit  wrote:

>
> On 3/6/18 2:19 PM, John R. Hogerhuis wrote:
> >
> > Ah. Well, CloudT dynamically inserts delays to simulate the Model T
> > processor speed. If you look at the number at the bottom of the screen
> > it should over around 2.4Mhz. But being written in Javascript and
> > running off timer event callbacks, I can't get cycle accuracy.
> >
>
> Ahh, that's how you are emulating the 2.4MHz speed.  I was wondering.
> What do you use to determine the number of cycles to dynamically delay?
>


Well it’s basically on cpu cycles per instruction. There are definitely
some inaccuracies beyond just the JavaScript event driven model (I don’t
get to be the only code on my thread or get a guaranteed time slice).  But
it ought to be close enough.

The JUMP game seems to work off how fast inkey$ runs. I am guessing the
issue is that CloudT does some queueing beyond what the model t provides
due to some very fancy keyboard stuff going on in mobile browsers
(predictive text and such). So keys batch up and allow the man run faster
than he should.

— John.


Re: [M100] BASIC 10Liners

2018-03-06 Thread Ken Pettit


On 3/6/18 2:19 PM, John R. Hogerhuis wrote:


Ah. Well, CloudT dynamically inserts delays to simulate the Model T 
processor speed. If you look at the number at the bottom of the screen 
it should over around 2.4Mhz. But being written in Javascript and 
running off timer event callbacks, I can't get cycle accuracy.




Ahh, that's how you are emulating the 2.4MHz speed.  I was wondering.  
What do you use to determine the number of cycles to dynamically delay?


VirtualT works a bit differently.  It has two threads running:

1  Thread T (throttle) wakes up every 20ms (10ms for Windows) and 
calculates the number of emulated CPU cycles the emulation thread is 
allowed to execute.  This number will vary dynamically depending on the 
number of FLTK window updates during the previous 20/10ms period.  It 
then wakes up thread E and goes to sleep.


2.  Thread E (emulate) wakes up and executes the number of allowed CPU 
cycles for this timer period as calculated by Thread T then goes back to 
sleep.  So the throttled emulation (2.4MHz, 8Mhz, 20Mhz) modes actually 
execute 8085 code in short bursts every 10/20ms.


Ken




Re: [M100] BASIC 10Liners

2018-03-06 Thread John R. Hogerhuis
On Tue, Mar 6, 2018 at 3:12 PM, Kevin Becker  wrote:

> I only tried it in Safari but I can give it a go in Firefox and Chrome
> too.
>
>
Well I think I see the same behavior you're describing. I'm guessing it's
queuing keystrokes, not a Mhz issue.

-- John.


Re: [M100] BASIC 10Liners

2018-03-06 Thread Kevin Becker
I only tried it in Safari but I can give it a go in Firefox and Chrome too.

On Mar 6, 2018, at 5:19 PM, John R. Hogerhuis  wrote:



On Tue, Mar 6, 2018 at 1:06 PM, Kevin Becker  wrote:

> I just tried it again and I can easily run so fast that the player loops
> around the screen.  I suppose I could try to compensate for that in the
> code but I only have 10 lines. =)
>
>>
>>>

Ah. Well, CloudT dynamically inserts delays to simulate the Model T
processor speed. If you look at the number at the bottom of the screen it
should over around 2.4Mhz. But being written in Javascript and running off
timer event callbacks, I can't get cycle accuracy.

It may actually have nothing to do with cpu cycles but instead keyboard
emulation.

What browser are you using?

-- John.


Re: [M100] BASIC 10Liners

2018-03-06 Thread John R. Hogerhuis
On Tue, Mar 6, 2018 at 1:06 PM, Kevin Becker  wrote:

> I just tried it again and I can easily run so fast that the player loops
> around the screen.  I suppose I could try to compensate for that in the
> code but I only have 10 lines. =)
>
>>
>>>

Ah. Well, CloudT dynamically inserts delays to simulate the Model T
processor speed. If you look at the number at the bottom of the screen it
should over around 2.4Mhz. But being written in Javascript and running off
timer event callbacks, I can't get cycle accuracy.

It may actually have nothing to do with cpu cycles but instead keyboard
emulation.

What browser are you using?

-- John.


Re: [M100] BASIC 10Liners

2018-03-06 Thread Jim Anderson
> -Original Message-
> 
> I must have missed the email.  New member creation must be approved,
> otherwise we would have 321 users with names like joe.joe@joe.com
> posting all manner of things into the library.
> 
> I need to login to the Lizardhill maintenance page and switch back to
> PHP 5 for now.  My Safari browser isn't even pulling up the Personal
> Libraries page at all right now.

No rush - I don't have any masterpieces to upload :)

I think I submitted a request through a form on the website, but I could be 
mis-remembering.







jim


Re: [M100] BASIC 10Liners

2018-03-06 Thread Ken Pettit

Hi Jim,

I must have missed the email.  New member creation must be approved, 
otherwise we would have 321 users with names like joe.joe@joe.com 
posting all manner of things into the library.


I need to login to the Lizardhill maintenance page and switch back to 
PHP 5 for now.  My Safari browser isn't even pulling up the Personal 
Libraries page at all right now.


Ken

On 3/6/18 1:51 PM, Jim Anderson wrote:

-Original Message-
I created a member library at Club100 but

How did you do that?  I put in a request to have a member library months ago, 
and nothing ever happened (I only just remembered now when I read this).







 jim




Re: [M100] BASIC 10Liners

2018-03-06 Thread Jim Anderson
> -Original Message-
> I created a member library at Club100 but

How did you do that?  I put in a request to have a member library months ago, 
and nothing ever happened (I only just remembered now when I read this).







jim


Re: [M100] BASIC 10Liners

2018-03-06 Thread Kevin Becker
I just tried it again and I can easily run so fast that the player loops
around the screen.  I suppose I could try to compensate for that in the
code but I only have 10 lines. =)


On Tue, Mar 6, 2018 at 4:02 PM, Kevin Becker  wrote:

> That was my original plan but when I was testing in in CloudT the timing
> was way off.  The code increments a counter while looping for key presses
> to determine how fast you are running so it's pretty sensitive to differing
> clock speeds. I tuned it on my real Model 102 and VirtualT locked to 2.4MHz
> gives similar results but CloudT was running either too fast or too slow, I
> can't remember which now.
>
> On Tue, Mar 6, 2018 at 3:56 PM, John R. Hogerhuis 
> wrote:
>
>> You could try it like this
>>
>> Browse Chrome or Safari to
>>
>> http://bitchin100.com/CloudT
>>
>>
>> Open another tab to
>>
>> https://github.com/ksbex/basic-longjump/raw/master/JUMP.BA
>>
>> This should download the JUMP.BA file
>>
>> In the CloudT tab, select Choose File
>>
>> Navigate to your Downloads directory and pick JUMP.BA
>>
>> Notice at the bottom of your CloudT window that "JUMP.BA" is now on your
>> Cassette file queue
>>
>> Enter BASIC
>>
>> Type CLOAD
>>
>> Type SAVE"JUMP"
>>
>> Type RUN
>>
>>
>


Re: [M100] BASIC 10Liners

2018-03-06 Thread Kevin Becker
That was my original plan but when I was testing in in CloudT the timing
was way off.  The code increments a counter while looping for key presses
to determine how fast you are running so it's pretty sensitive to differing
clock speeds. I tuned it on my real Model 102 and VirtualT locked to 2.4MHz
gives similar results but CloudT was running either too fast or too slow, I
can't remember which now.

On Tue, Mar 6, 2018 at 3:56 PM, John R. Hogerhuis  wrote:

> You could try it like this
>
> Browse Chrome or Safari to
>
> http://bitchin100.com/CloudT
>
>
> Open another tab to
>
> https://github.com/ksbex/basic-longjump/raw/master/JUMP.BA
>
> This should download the JUMP.BA file
>
> In the CloudT tab, select Choose File
>
> Navigate to your Downloads directory and pick JUMP.BA
>
> Notice at the bottom of your CloudT window that "JUMP.BA" is now on your
> Cassette file queue
>
> Enter BASIC
>
> Type CLOAD
>
> Type SAVE"JUMP"
>
> Type RUN
>
>


Re: [M100] BASIC 10Liners

2018-03-06 Thread John R. Hogerhuis
You could try it like this

Browse Chrome or Safari to

http://bitchin100.com/CloudT


Open another tab to

https://github.com/ksbex/basic-longjump/raw/master/JUMP.BA

This should download the JUMP.BA file

In the CloudT tab, select Choose File

Navigate to your Downloads directory and pick JUMP.BA

Notice at the bottom of your CloudT window that "JUMP.BA" is now on your
Cassette file queue

Enter BASIC

Type CLOAD

Type SAVE"JUMP"

Type RUN


Re: [M100] BASIC 10Liners

2018-03-06 Thread Gregory McGill
looks great Kevin!

I'll have to set up the 100 and try it out :)

On Tue, Mar 6, 2018 at 11:47 AM, Kevin Becker  wrote:

> I finished my game a while ago but finally got around to writing up the
> readme for my submission.  I created a member library at Club100 but I'll
> wait until the hosting issues are resolved before uploading it there.  In
> the meantime I put it on Github if anyone is interested.
>
> https://github.com/ksbex/basic-longjump
>
> My original plan was for a very minimal text adventure but I couldn't make
> it fit. So instead I recreated a game I had written for my TRS-80 PC-3 that
> we would pass around in math class.  The teacher must've been suspicious
> about us pounding away on this weird looking calculator but never said
> anything.
>
>
>
>
>


[M100] BASIC 10Liners

2018-03-06 Thread Kevin Becker
I finished my game a while ago but finally got around to writing up the
readme for my submission.  I created a member library at Club100 but I'll
wait until the hosting issues are resolved before uploading it there.  In
the meantime I put it on Github if anyone is interested.

https://github.com/ksbex/basic-longjump

My original plan was for a very minimal text adventure but I couldn't make
it fit. So instead I recreated a game I had written for my TRS-80 PC-3 that
we would pass around in math class.  The teacher must've been suspicious
about us pounding away on this weird looking calculator but never said
anything.


Re: [M100] Portable Disk Drive 2 serial cable

2018-03-06 Thread Brian White
certainly. parts just came in yesterday too.

On Tue, Mar 6, 2018, 4:51 AM James Zeun  wrote:

> Brian if you make a new cable, could you photograph your progress? I think
> I'd like to make one myself and document it on my site, so that the process
> can be made clear enough for anyone with even a limited degree of soldering
> ability.
>
>
>
> On 1 Mar 2018 10:41 p.m., "Scotty Brown"  wrote:
>
>> Be keen to see how it goes Brian!
>>
>> Cheers,
>>
>> Scotty
>>
>> On 1/03/2018 19:38, Brian White wrote:
>>
>> I might have a good DigiKey cart to build one Marty Goodman cable now. I
>> just ordered one, so I'll know if this is actually a good kit when I get it.
>> IE, do the pins actually work in the 8-pin housing, is the polarity bump
>> on the 8-pin housing big enough or small enough, is that 6mm id insulation
>> tubing big enough to cover the diode & resistor next to one of those wires
>> , etc. Until then, this is just proposed. For starters, I figured it's
>> best to just follow Marty's specs excatly and only deviate from there after
>> testing, by which I mean measuring not just using.
>>
>> http://tandy.wiki/TPDD#Cable
>>
>>
>> --
>> bkw
>>
>>
>>


Re: [M100] Portable Disk Drive 2 serial cable

2018-03-06 Thread James Zeun
Brian if you make a new cable, could you photograph your progress? I think
I'd like to make one myself and document it on my site, so that the process
can be made clear enough for anyone with even a limited degree of soldering
ability.



On 1 Mar 2018 10:41 p.m., "Scotty Brown"  wrote:

> Be keen to see how it goes Brian!
>
> Cheers,
>
> Scotty
>
> On 1/03/2018 19:38, Brian White wrote:
>
> I might have a good DigiKey cart to build one Marty Goodman cable now. I
> just ordered one, so I'll know if this is actually a good kit when I get it.
> IE, do the pins actually work in the 8-pin housing, is the polarity bump
> on the 8-pin housing big enough or small enough, is that 6mm id insulation
> tubing big enough to cover the diode & resistor next to one of those wires
> , etc. Until then, this is just proposed. For starters, I figured it's
> best to just follow Marty's specs excatly and only deviate from there after
> testing, by which I mean measuring not just using.
>
> http://tandy.wiki/TPDD#Cable
>
>
> --
> bkw
>
>
>