Re: [M100] what's the Right Way to code and assemble on model-t hardware
If I'm reading it right, he's using self-modifying code. On Thu, Sep 8, 2022 at 12:03 PM Stephen Adolph wrote: > don't you need to reserve the memory location 56301 > right now it would be an opcode LXI? > > Steve > > On Thu, Sep 8, 2022 at 12:59 PM Charlie Hoey > wrote: > >> Thanks for that Ken! Nice to have confirmation on taht. >> >> And yeah I found BYTEIT over here on the programming section of the >> club100 archives: http://www.club100.org/library/libprg.html >> >> Just in case it's useful to anybody, so far I've ported over an LFSR >> pseudo-random number generator over from here: >> https://64nops.wordpress.com/2021/02/07/pseudo-random-number-generators/ >> , I went with the short 16bit one. His code is for Z80, but in this case no >> instructions the 8085 doesn't also have. My version adapted for M100 >> BYTEIT is as follows: >> >> ; 64nops galois 16bit lfsr routine >> ORG 56300 >> LFVAR EQU 56301 >> START LXI HL,6128H >> DAD HL >> SBB A >> ANI 83H >> XRA L >> MOV L,A >> SHLD LFVAR >> MOV HL,BC >> MOV M,BC >> RET >> END >> >> After assembling the above, from BASIC I can then run `CALL 56300` to >> generate a new number, and `PEEK(56301)` to retrieve it. >> >> Anyhow, so far so good, but I may check out CMZASM, since it seems like >> if I want to easily share/reuse things, it's handy to have it installable >> through basic. >> >
Re: [M100] TPDD Server in MS BASIC?
> Not that I've seen yet, but I have seen some client code in gwbasic in the M100SIG: Nice! Thanks for posting those. I'll try porting them to Altair Basic. Shouldn't be too difficult. /hdan On Tue, Aug 30, 2022 at 3:58 AM Brian K. White wrote: > On 8/29/22 19:03, Dan Higdon wrote: > > Does anyone have source to a LaddieAlpha type TPDD "server" program, but > > written in Microsoft Basic? > > Not that I've seen yet, but I have seen some client code in gwbasic in > the M100SIG: > > > > https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-09-PERIFERALS/TDIR.BAS > > > https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-09-PERIFERALS/TREAD.BAS > > > https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-09-PERIFERALS/TWRITE.BAS > > > https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-09-PERIFERALS/TERASE.BAS > > > -- > bkw > > > I have this idea to have a CP/M machine (in this case, a recently built > > Altair clone) act as a file server for my ModelT. This is obviously just > > a "for the fun of it" project with little practical value, but I thought > > it would be worth asking here if anyone had already done something like > > this. > > > > I suppose a relevant followup question would be, "what com settings are > > necessary to support TPDD?" (baud rate, bits, etc.) I think that my > > target machine can't do serial comms faster than 9600, so maybe this > > project is impossible. > > > > (My *real* "for the fun of it" project would be doing an 8080 CP/M ASM > > program that hosts a TPDD dialog, but I'm afraid that my level of > > commitment to this project is not equal to the difficulty.) > > > > Thanks for indulging my questions, > > /hdan > > > -- > bkw >
Re: [M100] TPDD Server in MS BASIC?
> No, but I have it in Microchip PIC18F assembly!! Not sure that help you though. :) I don't know much about PIC assembly unfortunately. :) > Also, there is a C++ version in the VirtualT source code. C++ is my primary language these days, so I'll check that out. I knew VirtualT had a lot of stuff in it, but I didn't know about that. Thanks! /hdan On Mon, Aug 29, 2022 at 6:24 PM Ken Pettit wrote: > No, but I have it in Microchip PIC18F assembly!! Not sure that help > you though. :) > > Also, there is a C++ version in the VirtualT source code. > > Ken > > On 8/29/22 4:03 PM, Dan Higdon wrote: > > Does anyone have source to a LaddieAlpha type TPDD "server" program, > > but written in Microsoft Basic? > > > > I have this idea to have a CP/M machine (in this case, a > > recently built Altair clone) act as a file server for my ModelT. This > > is obviously just a "for the fun of it" project with little practical > > value, but I thought it would be worth asking here if anyone had > > already done something like this. > > > > I suppose a relevant followup question would be, "what com settings > > are necessary to support TPDD?" (baud rate, bits, etc.) I think that > > my target machine can't do serial comms faster than 9600, so maybe > > this project is impossible. > > > > (My *real* "for the fun of it" project would be doing an 8080 CP/M ASM > > program that hosts a TPDD dialog, but I'm afraid that my level of > > commitment to this project is not equal to the difficulty.) > > > > Thanks for indulging my questions, > > /hdan > >
[M100] TPDD Server in MS BASIC?
Does anyone have source to a LaddieAlpha type TPDD "server" program, but written in Microsoft Basic? I have this idea to have a CP/M machine (in this case, a recently built Altair clone) act as a file server for my ModelT. This is obviously just a "for the fun of it" project with little practical value, but I thought it would be worth asking here if anyone had already done something like this. I suppose a relevant followup question would be, "what com settings are necessary to support TPDD?" (baud rate, bits, etc.) I think that my target machine can't do serial comms faster than 9600, so maybe this project is impossible. (My *real* "for the fun of it" project would be doing an 8080 CP/M ASM program that hosts a TPDD dialog, but I'm afraid that my level of commitment to this project is not equal to the difficulty.) Thanks for indulging my questions, /hdan
Re: [M100] reuse Palm pilot as a serial LCD display for M100
Wow, that's pretty cool. I have an old Palm III that I keep wanting to find stuff to do with. I have the cradle (an RS232 cradle, thankfully) but no software. I put batteries into it and it does work. >From the sounds of things, it looks like it won't be a straight-up "throw ASCII at it" terminal, but it will be fun to explore the options I think. On Wed, Jun 23, 2021 at 7:24 AM Stephen Adolph wrote: > http://palmorb.sourceforge.net/download.html > > stumbled across this interesting piece of Palm Pilot software it turns > the PP into an RS232 driven LCD display. This seems like it could be quite > useful for the M100 - debug interface, auxiliary input/output etc. > >
Re: [M100] overflow
If you're in DEFINT mode or using % variables, it just means you had a result outside of [-32768, 32767]. On Fri, Feb 19, 2021 at 3:57 PM John R. Hogerhuis wrote: > Any idea what operation is happening in BASIC when you get the error? > > I'm not sure what generally causes OV in BASIC but we should be able to > determine what is making it happen in this case with more info. > > -- John. >
Re: [M100] compile and execute Turbo Pascal (Stephen Adolph)
Back in HS, I used the UCSD "P-System" Pascal compiler on our Apple][e hardware. We had the UCSD FORTRAN compiler too, and being into computer languages back then, I wound up getting enough FORTRAN in me to land an internship. In college, we used Modula2 for anything beyond the basic classes. I never used Pascal professionally, and for personal projects, I was way more interested in FORTH and C. (And once Zortech C++ came out, C++). On Fri, Oct 2, 2020 at 3:36 AM Bradley Kuss wrote: > -- Forwarded message -- > From: Stephen Adolph > To: m...@bitchin100.com > Date: Wed, 30 Sep 2020 18:17:43 -0400 > Subject: Re: [M100] compile and execute Turbo Pascal > oh and also in Setup: > MVT100 adapter with external LCD 80x24 > > On Wed, Sep 30, 2020 at 6:17 PM Stephen Adolph > wrote: > Well, that feels good! > > I finally got Turbo Pascal 3.01 configured (well enough) and running on > Model 100! And I compiled and ran a demo provided by Borland. Sweet! > > Setup: > REXCPM 2MB > M100 CP/M (modified to remove 8085 undoc opcodes) > Dual CPU board with 80C85 and NSC800 (socket at CPU on M100) > Dual Main ROM adapter (need a specific mainROM for each processor) > > -- > > Just out of curiosity, how many members of the M100 forum used Pascal? > Pascal came out in 1970 and I was still using/exploring Assembly Language > on the Z-80 and the then current Intel processors.(actually the programs > that ran on those processors using disassembly + assembly programs to tweak > them or find out how the "worked"). Many of the reviews over time of Pascal > were not very good so I never bought the program. But then C and it's > derivatives (C+, C++) came along and changed the whole world of programming. > > Bradley R Kuss > >
Re: [M100] TPDD client tools in... Forth?
LOVE it! I can't wait to dig in. I've been playing around in Forth since I was in high school. Such a fun language. On Fri, Jul 3, 2020 at 8:55 PM John R. Hogerhuis wrote: > Poking around my server I found a TPDD "client" that I wrote in Forth long > ago. Funny thing is I have no recollection of creating it. But it has my > copyright notice and a GPL license, so apparently I did. > > It runs on gForth on Linux. > > http://bitchin100.com/files/hardware/testtpdd.zip > > I'm guessing it's more of a "test" wordset so you can do different TPDD > experiments from the Forth OK prompt. > > Shouldn't be too hard to convert to MForth. > > -- John. >
Re: [M100] Video out adapter?
I see from the docs that the vt100 driver isn't REX compatible. Should I remove REX's hooks first, and can I restore REX with the usual call afterwards? On Fri, Jun 19, 2020 at 4:37 PM Stephen Adolph wrote: > Give it a try! Note that a normal vt100 does ot work perfectly. As I > say in the wiki page, a vt100 does not have certain commands that the model > T needs. > > On Friday, June 19, 2020, Dan Higdon wrote: > >> Ah, perfect, I missed the vt100 driver for the ModelT last time I read >> that page. Thank you. >> Option 3 for right now, with my PC and PuTTY playing the role of a vt100 >> terminal. >> Hopefully Option 2 at some point. >> >> On Fri, Jun 19, 2020 at 3:09 PM Stephen Adolph >> wrote: >> >>> >>> http://bitchin100.com/wiki/index.php?title=VT100 >>> >>> Link to the page.. >>> Hope that helps. >>> >>> Steve >>> >>> On Friday, June 19, 2020, Stephen Adolph wrote: >>> >>>> Well what do you want screen 1 to be? >>>> >>>> Option 1. A real DVI, with original DVI software >>>> >>>> Option 2. Using my hack of the DVI software, and the MVT100 video >>>> adapter >>>> >>>> Option 3. Using my hack of the DVI software plus an rs232 connected >>>> terminal as the display >>>> >>>> I believe i have posted the software at bitchin100. MTV100 adapter is >>>> still waiting for parts . Hopefully I will have kits soon. >>>> >>>> Steve >>>> >>>> >>>> On Friday, June 19, 2020, Dan Higdon wrote: >>>> >>>>> Where do I get whatever I need to add "screen 1" as a valid command? >>>>> It occurs to me that I can actually use PuTTY to be my 80x25 display >>>>> while I'm working my way up to building a vt100 connector. >>>>> Thanks, >>>>> Dan >>>>> >>>>> On Wed, Jun 17, 2020 at 10:11 PM Mike Stein >>>>> wrote: >>>>> >>>>>> Welcome to the list and the 'Model T' community! >>>>>> >>>>>> As a matter of fact several slightly different external 80x25 video >>>>>> adapters do exist, although unlike the DVI which connects to the system >>>>>> bus >>>>>> these connect either to the RS-232 com port or, with a minor board mod, >>>>>> to >>>>>> the BCR port. >>>>>> >>>>>> See >>>>>> http://bitchin100.com/wiki/index.php?title=File:VT100_1.jpg >>>>>> >>>>>> and >>>>>> http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK >>>>>> >>>>>> for a version adapted to the M100 by Steve Adolph, a list member, >>>>>> currently awaiting production quantity parts. >>>>>> >>>>>> Note that the BCR port mod may be superseded by a different internal >>>>>> connection. >>>>>> >>>>>> m >>>>>> >>>>>> Original Message - >>>>>> >>>>>> *From:* David B >>>>>> *To:* m100@lists.bitchin100.com >>>>>> *Sent:* Wednesday, June 17, 2020 7:48 PM >>>>>> *Subject:* [M100] Video out adapter? >>>>>> >>>>>> Hi just got a (working!) model 100 off eBay and replaced the nicd >>>>>> battery. So far, so good. >>>>>> >>>>>> Learning about this computer and just read there was a combined >>>>>> external disk and video adapter. I'm interested in the external video >>>>>> part. >>>>>> Has anyone designed an external video adapter for this, that can be built >>>>>> by a hobbyist? >>>>>> >>>>>> thanks, >>>>>> David >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *From:* M100 on behalf of >>>>>> m100-requ...@lists.bitchin100.com >>>>>> *Sent:* Wednesday, June 17, 2020 1:39 PM >>>>>> *To:* m100@lists.bitchin100.com >>>>>> *Subject:* M100 Digest, Vol 114, Issue 12 >>>>>> >>>>>> Send M100 mailing list submissions to >>>>>> m100@lists.bitchin100.com &
Re: [M100] Video out adapter?
Ah, perfect, I missed the vt100 driver for the ModelT last time I read that page. Thank you. Option 3 for right now, with my PC and PuTTY playing the role of a vt100 terminal. Hopefully Option 2 at some point. On Fri, Jun 19, 2020 at 3:09 PM Stephen Adolph wrote: > > http://bitchin100.com/wiki/index.php?title=VT100 > > Link to the page.. > Hope that helps. > > Steve > > On Friday, June 19, 2020, Stephen Adolph wrote: > >> Well what do you want screen 1 to be? >> >> Option 1. A real DVI, with original DVI software >> >> Option 2. Using my hack of the DVI software, and the MVT100 video >> adapter >> >> Option 3. Using my hack of the DVI software plus an rs232 connected >> terminal as the display >> >> I believe i have posted the software at bitchin100. MTV100 adapter is >> still waiting for parts . Hopefully I will have kits soon. >> >> Steve >> >> >> On Friday, June 19, 2020, Dan Higdon wrote: >> >>> Where do I get whatever I need to add "screen 1" as a valid command? >>> It occurs to me that I can actually use PuTTY to be my 80x25 display >>> while I'm working my way up to building a vt100 connector. >>> Thanks, >>> Dan >>> >>> On Wed, Jun 17, 2020 at 10:11 PM Mike Stein wrote: >>> >>>> Welcome to the list and the 'Model T' community! >>>> >>>> As a matter of fact several slightly different external 80x25 video >>>> adapters do exist, although unlike the DVI which connects to the system bus >>>> these connect either to the RS-232 com port or, with a minor board mod, to >>>> the BCR port. >>>> >>>> See >>>> http://bitchin100.com/wiki/index.php?title=File:VT100_1.jpg >>>> >>>> and >>>> http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK >>>> >>>> for a version adapted to the M100 by Steve Adolph, a list member, >>>> currently awaiting production quantity parts. >>>> >>>> Note that the BCR port mod may be superseded by a different internal >>>> connection. >>>> >>>> m >>>> >>>> Original Message - >>>> >>>> *From:* David B >>>> *To:* m100@lists.bitchin100.com >>>> *Sent:* Wednesday, June 17, 2020 7:48 PM >>>> *Subject:* [M100] Video out adapter? >>>> >>>> Hi just got a (working!) model 100 off eBay and replaced the nicd >>>> battery. So far, so good. >>>> >>>> Learning about this computer and just read there was a combined >>>> external disk and video adapter. I'm interested in the external video part. >>>> Has anyone designed an external video adapter for this, that can be built >>>> by a hobbyist? >>>> >>>> thanks, >>>> David >>>> >>>> >>>> >>>> -- >>>> *From:* M100 on behalf of >>>> m100-requ...@lists.bitchin100.com >>>> *Sent:* Wednesday, June 17, 2020 1:39 PM >>>> *To:* m100@lists.bitchin100.com >>>> *Subject:* M100 Digest, Vol 114, Issue 12 >>>> >>>> Send M100 mailing list submissions to >>>> m100@lists.bitchin100.com >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com >>>> or, via email, send a message with subject or body 'help' to >>>> m100-requ...@lists.bitchin100.com >>>> >>>> You can reach the person managing the list at >>>> m100-ow...@lists.bitchin100.com >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of M100 digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>>1. Rexcpm update (Stephen Adolph) >>>>2. Re: Rexcpm update (David Rogers) >>>>3. Re: Noisy T102 (B 9) >>>>4. Re: Noisy T102 (Erik van der Tier) >>>>5. Re: Noisy T102 (Erik van der Tier) >>>>6. Re: Noisy T102 (Stephen Adolph) >>>>7. Re: Noisy T102 (Jim Toth) >>>>8. Re: Noisy T102 (Mike Stein) >>>>9. Re: Rexcpm update (Bert Put) >>>> 10. Re: Noisy T102 (Alex ...) >>>> 11. Annotated disassemble of T102 rom (Erik van der Tier) >>>> 12. Re:
Re: [M100] Video out adapter?
Where do I get whatever I need to add "screen 1" as a valid command? It occurs to me that I can actually use PuTTY to be my 80x25 display while I'm working my way up to building a vt100 connector. Thanks, Dan On Wed, Jun 17, 2020 at 10:11 PM Mike Stein wrote: > Welcome to the list and the 'Model T' community! > > As a matter of fact several slightly different external 80x25 video > adapters do exist, although unlike the DVI which connects to the system bus > these connect either to the RS-232 com port or, with a minor board mod, to > the BCR port. > > See > http://bitchin100.com/wiki/index.php?title=File:VT100_1.jpg > > and > http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK > > for a version adapted to the M100 by Steve Adolph, a list member, > currently awaiting production quantity parts. > > Note that the BCR port mod may be superseded by a different internal > connection. > > m > > Original Message - > > *From:* David B > *To:* m100@lists.bitchin100.com > *Sent:* Wednesday, June 17, 2020 7:48 PM > *Subject:* [M100] Video out adapter? > > Hi just got a (working!) model 100 off eBay and replaced the nicd battery. > So far, so good. > > Learning about this computer and just read there was a combined external > disk and video adapter. I'm interested in the external video part. Has > anyone designed an external video adapter for this, that can be built by a > hobbyist? > > thanks, > David > > > > -- > *From:* M100 on behalf of > m100-requ...@lists.bitchin100.com > *Sent:* Wednesday, June 17, 2020 1:39 PM > *To:* m100@lists.bitchin100.com > *Subject:* M100 Digest, Vol 114, Issue 12 > > Send M100 mailing list submissions to > m100@lists.bitchin100.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com > or, via email, send a message with subject or body 'help' to > m100-requ...@lists.bitchin100.com > > You can reach the person managing the list at > m100-ow...@lists.bitchin100.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of M100 digest..." > > > Today's Topics: > >1. Rexcpm update (Stephen Adolph) >2. Re: Rexcpm update (David Rogers) >3. Re: Noisy T102 (B 9) >4. Re: Noisy T102 (Erik van der Tier) >5. Re: Noisy T102 (Erik van der Tier) >6. Re: Noisy T102 (Stephen Adolph) >7. Re: Noisy T102 (Jim Toth) >8. Re: Noisy T102 (Mike Stein) >9. Re: Rexcpm update (Bert Put) > 10. Re: Noisy T102 (Alex ...) > 11. Annotated disassemble of T102 rom (Erik van der Tier) > 12. Re: Annotated disassemble of T102 rom (Stephen Adolph) > 13. Re: Annotated disassemble of T102 rom (Ken Pettit) > 14. Re: Annotated disassemble of T102 rom (Erik van der Tier) > 15. Re: Annotated disassemble of T102 rom (Erik van der Tier) > 16. Re: Annotated disassemble of T102 rom (Ken Pettit) > 17. Tandy 200 Black Screen (ethan saul) > 18. Re: Tandy 200 Black Screen (Stephen Adolph) > > > -- > > Message: 1 > Date: Tue, 16 Jun 2020 22:11:30 -0400 > From: Stephen Adolph > To: m...@bitchin100.com > Subject: [M100] Rexcpm update > Message-ID: > < > camcmnv7xfugfhuq2w+inw9qm77wvuhxzhew+qodgaz2adgz...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I am well into the 2nd build of REXCPM. All of the REXCPM modules are > built, untested, but I still need to build the adapters. > So good progress. I'm aiming to ship the next tranch in 2 weeks or sooner. > Steve > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20200616/892a2d16/attachment-0001.html > > > > -- > > Message: 2 > Date: Tue, 16 Jun 2020 19:43:57 -0700 > From: David Rogers > To: m...@bitchin100.com > Subject: Re: [M100] Rexcpm update > Message-ID: <69772e77-75b5-44c3-a818-1d8660a9c...@gmail.com> > Content-Type: text/plain; charset="utf-8" > > > > David, WA7ZYQ > > C?est la vie, c?est la guerre, viva la salade de pommes de terre. > > > On Jun 16, 2020, at 7:11 PM, Stephen Adolph > wrote: > > > > I am well into the 2nd build of REXCPM. All of the REXCPM modules are > built, untested, but I still need to build the adapters. > > So good progress. I'm aiming to ship the next tranch in 2 weeks or > sooner. > > Steve > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20200616/84e5c9e2/attachment-0001.html > > > > -- > > Message: 3 > Date: Tue, 16 Jun 2020 19:52:31 -0700 > From: B 9 > To: m...@bitchin100.com > Subject: Re: [M100] Noisy T102 > Message-ID: > < > cag1tpetpsaurqtuc1dsayoqbdhlsrtnkcbrehfvk7pzuxzr...@mail.gmail.com> > Content-Type: text/plain;
Re: [M100] Barrel Jack Specification
According to Oppendahl's book, any ripple free DC adaptor between 3.3v and 7v, that can provide at least 1.1 watts, and has a center-negative 5.5mm barrel connector will work. 6V is what is ideal, and apparently you can use a 6V lantern battery or set of photocells in parallel will also work. He mentions the power connector as being a Radio Shack 274-1551, but I don't know how useful RS catalog numbers are these days. On Sat, May 30, 2020 at 10:04 PM Tom Wilson wrote: > I believe it’s a standard 2.1mm barrel plug. You need to provide 6VDC > center —…_negative_. > > On Sat, May 30, 2020 at 6:56 PM dano none wrote: > >> >> I want to purchase a barrel jack that would plug in to power port of the >> Model 100. >> Can someone please tell me the spec's I need? >> Thanks, >> Dan >> > -- > Tom Wilson > wilso...@gmail.com > (619)940-6311 > K6ABZ >
Re: [M100] Cleuseau ROM and REX?
Interesting - I hadn't thought to try call 911 without the ROM being
initialized, but as you say, it works fine!
I'll swap my BX out for the non-development one though.
I've noticed that if you go into REXMGR and re-select the Cleuseau ROM, it
installs. Until power up, but that is a less error-prone method of
installing, for me at least.
Thanks guys!
On Mon, May 11, 2020 at 6:19 PM Peter Noeth wrote:
> According to my information, version R2C1D.BX was some kind of development
> version, undocumented as far as I can tell.
>
> I use RC2100.BX myself, but only the ROM II portion ("CALLl 911" from
> BASIC each time you want to use one of it's functions), and have defined
> F6, in BASIC to access it { type: KEY 6,"CALL 911"+CHR$(13) }. BASIC will
> remember this F6 definition until you change it or cold boot.
>
> I just checked the Cleuseau portion ("CALL 63012") and I also see that
> Cleuseau seems to disable upon power cycle. Since I don't use it, I never
> noticed this behaviour. The REX documentation does not say if when
> activating an Option ROM, it stays active thru power cycles. Only that REX
> remembers which Option ROM you have selected to be the default one. REX
> also uses the CALL 63012 command to initialize itself, so I would expect
> there to be some power on conflict there.
>
> Regards,
>
> Peter
>
>>
>> --
>>
>> Message: 2
>> Date: Sun, 10 May 2020 11:26:01 -0500
>> From: Dan Higdon
>> To: m...@bitchin100.com
>> Subject: [M100] Cleuseau ROM and REX?
>> Message-ID:
>> > pxyrzrzgbdx...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I've noticed when trying out Cleusea ROM2 from my REX that the ROM doesn't
>> stay "installed" when I cycle power.
>>
>> Is this normal behavior?
>>
>> I just started playing around with this ROM, and since programming is
>> mostly what I use my ModelT.102 for, this thing is great.
>>
>> I'm using the file named R2C1D.BX as my image. How is that different from
>> R2C100.BX, and could that be my problem?
>>
>> Thanks,
>> /hdan
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20200510/68b0637c/attachment-0001.html
>> >
>>
>> --
>>
>> Message: 3
>> Date: Sun, 10 May 2020 12:34:41 -0400
>> From: Stephen Adolph
>> To: "m...@bitchin100.com"
>> Subject: Re: [M100] Cleuseau ROM and REX?
>> Message-ID:
>> <
>> camcmnv7t5f_qtkmkkjnti2oo87+tnr5k71q8am2etvorh-k...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Not sure of the answer anymore, but has been a long time.
>>
>> Rex and rom2 use the same software hooks so there is some interaction.
>>
>> When the laptop is power cycled, rex has to to auto configure. I may have
>> not been able to maintain the hooks for the selected rom.
>>
>>
>
[M100] Cleuseau ROM and REX?
I've noticed when trying out Cleusea ROM2 from my REX that the ROM doesn't stay "installed" when I cycle power. Is this normal behavior? I just started playing around with this ROM, and since programming is mostly what I use my ModelT.102 for, this thing is great. I'm using the file named R2C1D.BX as my image. How is that different from R2C100.BX, and could that be my problem? Thanks, /hdan
Re: [M100] T-102 is here!
Thanks for the PDF - that looks rad! I need to check to see if my REX still has that image. (And if not, it's an easy matter to add it). It sounds like that's exactly what I was looking for - makes BASIC easier to deal with, and has an assembler. /hdan On Tue, Mar 17, 2020 at 12:36 PM Tom Wilson wrote: > Ah, Bitchin 100 has a ZIP file with all of the useful ROMs ready to go. > > http://bitchin100.com/wiki/index.php?title=REX#Option_ROM_Images_for_Download > > > I'm going to work up a BASIC/Cleuseau cheat sheet later. I want to have > all the commands in a quick, searchable, text format. The manuals are all > PDF scans, and the Cleuseau one is pretty rough (and verbose). > > My favorite commands > .RENUM (range) [TO num] [STEP num] > .MOVE (range) [TO num] [STEP num] > .COPY (range) [TO num] [STEP num] > .KILL (range) > > There's also stuff for tracing code, setting breakpoints, and packing > lines. (.MIN crunches everything to its smallest possible size. .EXPAND > makes things human readable again... etc.) > > And that's just the BASIC side. There's also an assembler side... which is > TMI for a short email. =) > . > > > > > Tom Wilson > wilso...@gmail.com > (619)940-6311 > K6ABZ > > > On Tue, Mar 17, 2020 at 10:15 AM Tom Wilson wrote: > >> >> On Tue, Mar 17, 2020 at 9:57 AM Dan Higdon wrote: >> >>> Is there any documentation for Clueseau? I haven't been able to figure >>> out how to use it. >>> >> >> I found a scanned PDF here: >> https://ftp.whtech.com/club100/doc/cleurom2.pdf >> >> I also found the T200 Cleuseau ROM in Hex format, but I'm not sure how to >> make that loadable on Rex. I guess I need to RTFM. >> >> >
Re: [M100] T-102 is here!
Is there any documentation for Clueseau? I haven't been able to figure out how to use it. On Tue, Mar 17, 2020 at 11:28 AM Tom Wilson wrote: > Yay! The Rex arrived, and it's everything I'd hoped. It looks like it also > came with a copy of Cluseau, which is a pretty nice BASIC debugger and > assembler/debugger. > > Being able to switch option ROMs on the fly is super handy. (Use Clouseau > for editing and debugging BASIC, then switch to TS-DOS to upload the code > to storage.) > > So now that I have Rex working... I definitely need one for the 200 when > it arrives. > > Tom Wilson > wilso...@gmail.com > (619)940-6311 > K6ABZ > > > On Sat, Mar 14, 2020 at 4:00 PM Tom Wilson wrote: > >> True. I will probably tokenize the program after testing on VirtualT and >> keep one as .ba.txt and one as .ba. >> >> On Sat, Mar 14, 2020 at 3:58 PM Joshua O'Keefe >> wrote: >> >>> >>> > On Mar 14, 2020, at 3:53 PM, Tom Wilson wrote: >>> > >>> > Thanks. I was not aware of the TS-DOS resident feature. That is enough >>> to do what I want it to do. I prefer to keep my BASIC programs in ASCII >>> format while on the PC, so as long as I can tokenize on load, that great. >>> >>> That works just fine, but make sure not to name them .BA if you do. >>> LaddieAlpha protects you from exploding your memory if you do that, but not >>> everyone uses that tool, and a bad .BA can give someone a bad day if you >>> share your program. Note also that the tokenizer is a bit slow. Storing >>> your BASIC programs in .BA format instead of .DO format will make them much >>> faster to load. >>> >>> >>> -- >> Tom Wilson >> wilso...@gmail.com >> (619)940-6311 >> K6ABZ >> >
Re: [M100] REXCPM/REX status and questions
For REXCPM, how much hardware modification is required? Does it need any wires soldered to the motherboard? I have a Model102, if there is a difference between 100 and 102 in this regard. On Wed, Feb 19, 2020 at 9:35 AM Stephen Adolph wrote: > I can comment on the hardware side of things. Standard REX does not > support CP/M as it is FLASH only. > > REXCPM is different hardware. It uses Static RAM (either 2MB or 4MB) as > opposed to FLASH. In order to run CPM you need 64k of addressable RAM. > REXCPM does a few things to make that happen > 1) it takes over the OPTROM memory space (-7FFF) > 2) it takes over the internal RAM memory space (8000-) > 3) it provides bank switching for up to 4MB of SRAM into those spaces. > > It relies on the internal nicad battery to keep the Static RAM alive. > > REXCPM reserves a large portion of the 2MB or 4MB SRAM as a ram disk for > use by CPM. Some additional 32k blocks are usable as OPTROM images for > traditional REX applications. > > WRT the display, the LCD is always 40x8. However it is relatively easy to > use an external monitor with this solution, enabling the full CP/M screen > dimensions. > > Philip Avery owns the CP/M operating system port for M100, and can comment > on the rest. > > cheers > Steve > > > On Wed, Feb 19, 2020 at 10:27 AM Abraham Moller > wrote: > >> Hi all, >> >> Just curious about the state of this new REXCPM! It sounds incredible! >> Does it offer CP/M plus 4MB Flash RAM for storage? Does it change the >> number of lines/columns on the display by using a smaller font (like NC100 >> ZCN)? Could the regular REX also be configured to run CP/M? >> >> Also, I assume standard CP/M software (qterm, DX-Forth, vde, zork, rogue, >> and so on) works with it? >> >> Thanks!! >> Jon >> >
Re: [M100] another program
rms even though by rights they should each be > >>> different, or it causes some internal effect in the interpreter or > >>> hardware like loading or clearing registers as a side-effect, or it > >>> pushes the internal tokenized keywords in the program around into some > >>> funky byte alignment or other structure that ends up executing faster, > >>> or allows some other bit of the code to do some dirty math trick with > >>> pointers to addresses that by rights it should have to do some much > more > >>> expensive but safer way. > >>> > >>> Or it could actually just be dumb. Or it could be corrupted like it was > >>> originally typed in wrong manually from a book or OCR'd, or it worked > >>> fine on some other machine and it's only a bug now because of an > >>> incomplete port. > >>> > >>> There is at least one program where the bugs are actually the entire > >>> point of the program. The program name is, shall we say, promising. You > >>> run it. It fails but the error is obvious because you are smart! So you > >>> fix that clod's mistake and wonder how this crap ever made it into the > >>> archives without someone else fixing it before now. It runs a tiny bit > >>> further and fails again. Again the new error is obvious so you fix it. > >>> Man this programmer was a freaking buffoon. You fix a couple more > >>> errors, and in the end all it says is something like "wasn't that a fun > >>> game?" The promise of the filename never existed. ;) > >>> > >>> -- > >>> bkw > >>> > >>> On 1/24/20 2:26 PM, Peter Vollan wrote: > >>>> Well, it doesn't say that. And if it did, that would still be a dumb > >>>> way to do it. Then the next line sets three variables to 0 which is > >>>> totally unneccessary, so that's a line that does nothing. And that is > >>>> only the tip of the iceberg of the problems with this program > >>>> > >>>> On Thu, 23 Jan 2020 at 09:55, Dan Higdon > wrote: > >>>>> The final number on that line should be an 11, then it works. (That > is, "ELSE 11", not "ELSE 13") > >>>>> > >>>>> On Sun, Jan 19, 2020 at 4:57 PM Peter Vollan > wrote: > >>>>>>Check this out! Not only is it a dumb way to do things, but it > does > >>>>>> not even work the program just hangs! > >>>>>> 13 IF AL$ = "S" OR AL$ = "R" OR AL$ = "T" THEN 15 ELSE 13 > >>> > >>> -- > >>> bkw > > >
Re: [M100] another program
The final number on that line should be an 11, then it works. (That is, "ELSE 11", not "ELSE 13") On Sun, Jan 19, 2020 at 4:57 PM Peter Vollan wrote: > Check this out! Not only is it a dumb way to do things, but it does > not even work the program just hangs! > 13 IF AL$ = "S" OR AL$ = "R" OR AL$ = "T" THEN 15 ELSE 13 >
Re: [M100] Dungeon Master's Personnel Service
But it's 5 more bytes! :) On Fri, Jan 10, 2020 at 5:33 PM Peter Vollan wrote: > I like "PRINT CHR$(12)" because it is more universal than CLS. > > On Thu, 9 Jan 2020 at 15:16, Peter Vollan wrote: > > > > BTW, what the hell is this: > > > > 1300 INPUT C > > 1310 ON C GOTO 1320 > > 1320 PRINT CHR$(12) > > > > On Thu, 9 Jan 2020 at 14:09, Jason Benson > wrote: > > > > > > Good to know. Here's the same file renamed to DMPS.DO > > > As for the error you ran into, I'm not at all surprised, there are > probably a few of bugs in there I missed and didn't trigger when I did some > brief testing on it. > > > > > > On Thu, Jan 9, 2020 at 5:03 PM John R. Hogerhuis > wrote: > > >> > > >> > > >> > > >> On Thu, Jan 9, 2020 at 1:58 PM Jason Benson < > jason.benson...@gmail.com> wrote: > > >>> > > >>> I was loading the file through Virtual T. and running it just fine. > Is it VT automatically converting it to a tokenized basic file? > > > > > > >> > > >> Yes. >
Re: [M100] Dungeon Master's Personnel Service
Jason, I'm glad you left it alone. I think there's historical value in the original text. Having said that, if someone (maybe me?) rewrites it to be more ModelT friendly, that would be fine, too. On Fri, Jan 10, 2020 at 8:39 AM Jason Benson wrote: > > That's the worst way possible to do "press any key to continue". > > In my own "walk through", I'm replacing those with > > When I was briefly debugging it I came across a number of things I would > change if I had written it, and I considered just rewriting chunks of it, > but I decided to leave it more or less intact as a historical example. If I > actually needed to use this for a D 1st Ed campaign I would > definitely rewrite it though. > > On Thu, Jan 9, 2020 at 6:35 PM Dan Higdon wrote: > >> That's the worst way possible to do "press any key to continue". >> In my own "walk through", I'm replacing those with >> >> 1300 if inkey$="" then 1300 >> 1320 cls >> >> On Thu, Jan 9, 2020 at 5:16 PM Peter Vollan wrote: >> >>> BTW, what the hell is this: >>> >>> 1300 INPUT C >>> 1310 ON C GOTO 1320 >>> 1320 PRINT CHR$(12) >>> >>> On Thu, 9 Jan 2020 at 14:09, Jason Benson >>> wrote: >>> > >>> > Good to know. Here's the same file renamed to DMPS.DO >>> > As for the error you ran into, I'm not at all surprised, there are >>> probably a few of bugs in there I missed and didn't trigger when I did some >>> brief testing on it. >>> > >>> > On Thu, Jan 9, 2020 at 5:03 PM John R. Hogerhuis >>> wrote: >>> >> >>> >> >>> >> >>> >> On Thu, Jan 9, 2020 at 1:58 PM Jason Benson < >>> jason.benson...@gmail.com> wrote: >>> >>> >>> >>> I was loading the file through Virtual T. and running it just fine. >>> Is it VT automatically converting it to a tokenized basic file? >>> >>>> >>> >>>> >>> >> >>> >> Yes. >>> >>
Re: [M100] Dungeon Master's Personnel Service
That's the worst way possible to do "press any key to continue". In my own "walk through", I'm replacing those with 1300 if inkey$="" then 1300 1320 cls On Thu, Jan 9, 2020 at 5:16 PM Peter Vollan wrote: > BTW, what the hell is this: > > 1300 INPUT C > 1310 ON C GOTO 1320 > 1320 PRINT CHR$(12) > > On Thu, 9 Jan 2020 at 14:09, Jason Benson > wrote: > > > > Good to know. Here's the same file renamed to DMPS.DO > > As for the error you ran into, I'm not at all surprised, there are > probably a few of bugs in there I missed and didn't trigger when I did some > brief testing on it. > > > > On Thu, Jan 9, 2020 at 5:03 PM John R. Hogerhuis > wrote: > >> > >> > >> > >> On Thu, Jan 9, 2020 at 1:58 PM Jason Benson > wrote: > >>> > >>> I was loading the file through Virtual T. and running it just fine. Is > it VT automatically converting it to a tokenized basic file? > > > >> > >> Yes. >
Re: [M100] Books on programming
Given the vintage, that article is probably AD (1st edition). Maybe 2e, but 2e is not very different from 1e. (I can wax very nerdy on that subject, but this doesn't seem the right forum.) On Wed, Jan 8, 2020 at 6:52 PM Gregory McGill wrote: > Here's the issue in pdf: https://annarchive.com/files/Drmg074.pdf > > > On Wed, Jan 8, 2020 at 4:42 PM Peter Vollan wrote: > >> I mean, what edition of D? >> >> On Tue, 7 Jan 2020 at 23:42, James Zeun wrote: >> > >> > Dragon #74 >> > >> > On Wed, 8 Jan 2020, 1:56 am Peter Vollan, wrote: >> >> >> >> What edition do you use? >> >> >> >> On Tue, 7 Jan 2020 at 17:06, James Zeun wrote: >> >> > >> >> > Great, I'll have to check that out! >> >> > >> >> > I'm currently checking out all the books that have been suggested to >> me. >> >> > >> >> > Really difficult to find physically books. >> >> > >> >> > >> >> > On Wed, 8 Jan 2020, 1:03 am C. Magaret, wrote: >> >> >> >> >> >> "Dragon" was about role-playing games, primarily D >> >> >> >> >> >> /CAM >> >> >> >> >> >> >> >> >> >> >> >> > On Jan 7, 2020, at 16:48, James Zeun >> wrote: >> >> >> > >> >> >> > Was the Dragon Magazine a computer mag or a magazine about >> roleplaying? >> >> >> > >> >> >> > On Wed, 8 Jan 2020, 12:30 am Peter Vollan, >> wrote: >> >> >> > Dragon. >> >> >> > >> >> >> > On Tue, 7 Jan 2020 at 15:52, James Zeun >> wrote: >> >> >> > > >> >> >> > > Is that the one from the dungeon magazine? >> >> >> > > >> >> >> > > On Tue, 7 Jan 2020, 11:34 pm Peter Vollan, < >> dprogra...@gmail.com> wrote: >> >> >> > >> >> >> >> > >> I have just about got the Dungeon Master's Personnel Service >> debugged >> >> >> > >> and working on Virtual T. >> >> >> > >> >> >> >> > >> On Tue, 7 Jan 2020 at 14:14, Britt Dodd >> wrote: >> >> >> > >> > >> >> >> > >> > I’ve read the M100 manual and it did have some examples on >> there, but the majority of it was more a glossary of statements. >> >> >> > >> > >> >> >> > >> > Sent from my iPhone >> >> >> > >> > >> >> >> > >> > On Jan 7, 2020, at 5:10 PM, Dan Higdon < >> therealh...@gmail.com> wrote: >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > The treasure horde program isn't posted anywhere. It's not >> long, but I don't have a copy on this machine. When I get home, I can send >> it to the list. >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > On Tue, Jan 7, 2020 at 4:00 PM Peter Vollan < >> dprogra...@gmail.com> wrote: >> >> >> > >> >> >> >> >> > >> >> You may be interested in knowing that I have already cut >> that text out >> >> >> > >> >> of the pdf of Dragon #74 and then pasted it back together >> in a text >> >> >> > >> >> file. Better than typing it all in like the old days, yes? >> I just ran >> >> >> > >> >> it in Virtual T (Model 100) and it barfs at the command >> "randomize". >> >> >> > >> >> >> >> >> > >> >> I did the same thing with a program to generated character >> for TSR's >> >> >> > >> >> Top Secret RPG, and then adapted it for the Model 100. It >> looks at the >> >> >> > >> >> tail end of TIME$ to randomise from 1 to 10 and then goes >> through that >> >> >> > >> >> many random numbers. It is on my Club 100 member page, but >> the member >> >> >> > >> >> pages are unfortunately down just now. >> >> >> > >&
Re: [M100] Dungeon Master's Personnel Service
Here's my simple treasure generator.
Once it's loaded, just type the letter of the treasure code.
You can type letters multiple times, and you can press a digit first, like
5g will generate 5 'g' type treasures and add them to the hoard.
ESC exits, SPACE clears the hoard. I have plans for more sophistication,
but this is what I have now.
I also tried putting the data into a separate file and reading it, but the
DATA statements were about the same speed (and format), and cluttering up
the file view wasn't worth it.
The first version used RESTORE/READ for each treasure type, but that was
too slow. Now it loads arrays at boot time, which puts all the slowness up
front.
You'll see my "busy spinner" if you use the digit+letter feature. :)
1 REM Treasure Table
2 CLS:GOSUB 2000:CLS:GOTO 1000
10 PRINT@7,"AD 2e Treasure Generator":RETURN
100 REM ROLL
110 J=ASC(TT$)-64:REM Key to treasure type index
120 FOR I=1 TO NT
130 R=0:N=TC%(J,I):IFN=0ORINT(1+RND(1)*20)>NTHEN 190
140 IFI0 THEN PRINT STR$(K);"x";MI$(J);
460 NEXT
470 RETURN
1000 REM MAIN
1010 GOSUB 10:PRINT:GOSUB400
1020 PRINT@40,"Type: ";
1025 NN=1
1030 R=RND(1):TT$=INKEY$:IFTT$=""THEN1030
1031 IFTT$=CHR$(27)THEN 300
1032 IFTT$=" "THEN 200
1033 REM ADD OPTIONS
1034 IFTT$>="0"ANDTT$<="9"THEN NN=ASC(TT$)-ASC("0"):GOTO 1030
1039 IFTT$>="a"ANDTT$<="z"THEN TT$=CHR$(ASC(TT$)-32):REM UCASE
1040 IFTT$<"A"ORTT$>"Z"THEN BEEP:GOTO1030
1045 IFNN>1THENTC$=TC$+STR$(NN)+"x"
1050 TC$=TC$+TT$:PRINT TC$;
1060 PRINT"-";:FOR M=1 TO NN
1070 GOSUB 100:PRINTBS$;MID$("/-\|",1+(MMOD4),1);
1080 NEXT:PRINTBS$
1090 GOSUB 400
1100 GOTO 1000
2000 GOSUB 10:PRINT"Loading: ";
2010 DEFINT I-N:I=0:J=0:K=0:TT$="":BS$=CHR$(127):NT=7:NR=26
2020 DIM TY$(NT),TV(NT),TM%(NR),MI$(NR)
2030 DIM TC%(NR,NT),TN%(NR,NT),TD%(NR,NT),TS%(NR,NT-1)
2040 RESTORE 3000
2050 FOR I=1 TO NT:READ TY$(I):NEXT
2060 FOR J=1 TO NR
2070 READ T$:PRINTT$;:REM PROGRESS
2080 FOR I=1 TO NT
2090 READ TC%(J,I),TD$,TS$
2100 K=INSTR(TD$,"d")
2110 IFK=0THEN TN%(J,I)=VAL(TD$):TD%(J,I)=0:GOTO 2130
2120 TN%(J,I)=VAL(LEFT$(TD$,K-1)):TD%(J,I)=VAL(MID$(TD$,K+1))
2130 IF I=NT THEN MI$(J)=TS$ ELSE TS%(J,I)=VAL(TS$)
2140 NEXT:NEXT:RETURN
3000 REM Data
3005 DATA CP,SP,GP,PP,Gems,Art,Magic
3010 DATA
A,5,1d3,1000,6,1d10,200,8,1d6,1000,7,3d6,100,12,1d4,10,10,2d6,1,6,3,Any
3020 DATA
B,10,1d6,1000,5,1d3,1000,5,1d10,200,5,1d10,100,6,1d8,1,4,1d4,1,2,1,Armor+Weapon
3030 DATA C,4,1d10,1000,6,1d6,10002,1d6,100,5,1d6,1,4,1d3,1,2,2,Any
3040 DATA
D,2,1d6,1000,3,1d10,1000,10,1d3,1000,3,1d6,100,6,1d10,1,5,1d6,1,3,2,Any
3050 DATA
E,1,1d6,1000,5,1d10,1000,5,1d4,1000,5,3d6,100,3,1d12,1,2,1d6,1,5,3,Any
3060 DATA
F2,3d6,1000,8,1d6,1000,3,1d4,1000,4,2d10,1,2,1d8,1,6,5,Any-Weapon
3070 DATA G,,,10,1d10,2000,10,1d10,1000,6,3d6,1,5,1d6,1,7,5,Any
3080 DATA
H,5,3d6,1000,8,1d10,2000,11,1d10,2000,8,1d8,1000,10,1d10,3,10,1d10,2,3,6,Any
3090 DATA I,,6,1d6,100,11,2d6,1,10,2d4,1,3,1,Any
3100 DATA J,20,3d8,1,,
3110 DATA K20,3d6,1,,,
3120 DATA L,,20,2d6,1,
3130 DATA M,,,20,2d4,1
3140 DATA N,,20,1d6,1,
3150 DATA O,20,1d4,10,20,1d3,10,,,
3160 DATA P20,1d6,1020,1d20,1,
3170 DATA Q,20,1d4,1,,
3180 DATA R,,,20,2d10,1,20,1d6,10,20,2d4,1,20,1d3,1,,,
3190 DATA S,,,20,1d8,Potion
3200 DATA T,,,20,1d4,Scroll
3210 DATA U,18,2d8,1,16,1d6,1,14,1,Any
3220 DATA V,,,20,2,Any
3230 DATA W,,,20,1d6,5,20,1d8,1,12,2d8,1,10,1d8,1,12,2,Any
3240 DATA X,,,20,2,Potion
3250 DATA Y,,,20,2d6,100
3260 DATA
Z,20,1d3,100,20,1d4,100,20,1d6,100,20,1d4,100,11,1d6,1,10,2d6,1,10,3,Any
On Tue, Jan 7, 2020 at 9:13 PM Bruce James wrote:
> I corrected the errors using a online cloud basic compiler
>
> http://www.tutorialspoint.com/execute_basic_online.php?fbclid=IwAR0qpAiqI2Sxo2FkYdFh7QMf8BjENl8JTQA6Frk8DbEkg385XtbvdpTcxpA
> plan on loading to my m100 tomorrow to edit more there.
> Bruce
>
> On Tue, Jan 7, 2020 at 10:00 PM Russell Flowers
> wrote:
>
>> Is this from the issue with the big breasted lady reading a crystal globe
>> on the front? I think I may even have that issue around here Kudos for
>> sharing this!
>>
>> On Tue, Jan 7, 2020 at 8:13 PM Jason Paul wrote:
>>
>>> There is an Errata a couple issues later I believe.
>>>
>>> On Tue, Jan 7, 2020, 9:11 PM Peter Vollan wrote:
>>>
Here is the code just as I copied it from The Dragon. If you run it
you will find that there are few mistakes and typos, so this program
could not have worked as is. I wonder how this is possible Did
some poor slob have to type this from looking at a printout? Anyway
before you run it you will need to remove this first part you are
reading. Later I may post the fixed version I made with VT.
1000 REM*
1010 REM**
1020 REM*DUNGEON MASTER'S PERSONNEL SERVICE*
1030 REM*( 40
Re: [M100] Books on programming
That's really great! Let me know when you post it somewhere, and thanks for saving me the trouble of doing the conversion myself. :) On Tue, Jan 7, 2020 at 5:34 PM Peter Vollan wrote: > I have just about got the Dungeon Master's Personnel Service debugged > and working on Virtual T. > > On Tue, 7 Jan 2020 at 14:14, Britt Dodd wrote: > > > > I’ve read the M100 manual and it did have some examples on there, but > the majority of it was more a glossary of statements. > > > > Sent from my iPhone > > > > On Jan 7, 2020, at 5:10 PM, Dan Higdon wrote: > > > > > > The treasure horde program isn't posted anywhere. It's not long, but I > don't have a copy on this machine. When I get home, I can send it to the > list. > > > > > > > > > > On Tue, Jan 7, 2020 at 4:00 PM Peter Vollan > wrote: > >> > >> You may be interested in knowing that I have already cut that text out > >> of the pdf of Dragon #74 and then pasted it back together in a text > >> file. Better than typing it all in like the old days, yes? I just ran > >> it in Virtual T (Model 100) and it barfs at the command "randomize". > >> > >> I did the same thing with a program to generated character for TSR's > >> Top Secret RPG, and then adapted it for the Model 100. It looks at the > >> tail end of TIME$ to randomise from 1 to 10 and then goes through that > >> many random numbers. It is on my Club 100 member page, but the member > >> pages are unfortunately down just now. > >> > >> I know that there is a program that does exactly what you describe > >> called D20.BA. I don't know how it randomises. > >> > >> I am interested in that program to generate treasure. BTW it is called > >> a treasure "hoard". > >> > >> On Tue, 7 Jan 2020 at 13:15, Jason Paul wrote: > >> > > >> > In most cases the syntax could change but the command should mostly > be the same. Depending on what machine you're using that particular book > was published with versions for specific Basics Commodore Atari Apple > TRS-80 etc. > >> > > >> > Do a Google search for Dragon magazine 74 PDF and there should be a > program listing that is a dungeon Master's kind of utility program. It's > not the only one. Don't be confused by the battle computer that is really > just a slotted wheel for determining combat to hit percentages. > >> > > >> > On Tue, Jan 7, 2020, 4:10 PM James Zeun wrote: > >> >> > >> >> It says for the TRS80 Model 3... I'm assuming that would still be > alright? > >> >> > >> >> > >> >> > >> >> On Tue, 7 Jan 2020, 8:55 pm Ken Pettit, wrote: > >> >>> > >> >>> Hi James, > >> >>> > >> >>> I just remembered the title. It is "Golden Flutes and Great > Escapes": > >> >>> > >> >>> > http://www.apple-iigs.info/doc/fichiers/goldenflutesandgreatescapes.pdf > >> >>> > >> >>> Ken > >> >>> > >> >>> On 1/7/20 12:48 PM, James Zeun wrote: > >> >>> > >> >>> Yes please! That would be great! > >> >>> > >> >>> On Tue, 7 Jan 2020, 8:36 pm Ken Pettit, wrote: > >> >>>> > >> >>>> > >> >>>> On 1/7/20 11:12 AM, Jerry Stratton wrote: > >> >>>> >> I don't know if anyone has any books they'd be willing to part > with or just recommend one. > >> >>>> > > >> >>>> > If your D includes wanting to write text adventures in > BASIC, Tim Hartnell’s Creating Adventure Games On Your Computer was very > nice. > >> >>>> > >> >>>> Come to think of it, I still own a book on writing text adventures > in > >> >>>> BASIC ... probably sitting on the top shelf of my bookshelf at > home. I > >> >>>> could look up the title later tonight when I get home if it is of > any > >> >>>> interest. > >> >>>> > >> >>>> Ken > >> >>>> > >> >>> >
Re: [M100] Books on programming
Argh, yes, it's probably Hoard not Horde. Sorry. English is my native language, so I have no excuse. On Tue, Jan 7, 2020 at 4:10 PM Dan Higdon wrote: > The treasure horde program isn't posted anywhere. It's not long, but I > don't have a copy on this machine. When I get home, I can send it to the > list. > > > > > On Tue, Jan 7, 2020 at 4:00 PM Peter Vollan wrote: > >> You may be interested in knowing that I have already cut that text out >> of the pdf of Dragon #74 and then pasted it back together in a text >> file. Better than typing it all in like the old days, yes? I just ran >> it in Virtual T (Model 100) and it barfs at the command "randomize". >> >> I did the same thing with a program to generated character for TSR's >> Top Secret RPG, and then adapted it for the Model 100. It looks at the >> tail end of TIME$ to randomise from 1 to 10 and then goes through that >> many random numbers. It is on my Club 100 member page, but the member >> pages are unfortunately down just now. >> >> I know that there is a program that does exactly what you describe >> called D20.BA. I don't know how it randomises. >> >> I am interested in that program to generate treasure. BTW it is called >> a treasure "hoard". >> >> On Tue, 7 Jan 2020 at 13:15, Jason Paul wrote: >> > >> > In most cases the syntax could change but the command should mostly be >> the same. Depending on what machine you're using that particular book was >> published with versions for specific Basics Commodore Atari Apple TRS-80 >> etc. >> > >> > Do a Google search for Dragon magazine 74 PDF and there should be a >> program listing that is a dungeon Master's kind of utility program. It's >> not the only one. Don't be confused by the battle computer that is really >> just a slotted wheel for determining combat to hit percentages. >> > >> > On Tue, Jan 7, 2020, 4:10 PM James Zeun wrote: >> >> >> >> It says for the TRS80 Model 3... I'm assuming that would still be >> alright? >> >> >> >> >> >> >> >> On Tue, 7 Jan 2020, 8:55 pm Ken Pettit, wrote: >> >>> >> >>> Hi James, >> >>> >> >>> I just remembered the title. It is "Golden Flutes and Great Escapes": >> >>> >> >>> >> http://www.apple-iigs.info/doc/fichiers/goldenflutesandgreatescapes.pdf >> >>> >> >>> Ken >> >>> >> >>> On 1/7/20 12:48 PM, James Zeun wrote: >> >>> >> >>> Yes please! That would be great! >> >>> >> >>> On Tue, 7 Jan 2020, 8:36 pm Ken Pettit, wrote: >> >>>> >> >>>> >> >>>> On 1/7/20 11:12 AM, Jerry Stratton wrote: >> >>>> >> I don't know if anyone has any books they'd be willing to part >> with or just recommend one. >> >>>> > >> >>>> > If your D includes wanting to write text adventures in >> BASIC, Tim Hartnell’s Creating Adventure Games On Your Computer was very >> nice. >> >>>> >> >>>> Come to think of it, I still own a book on writing text adventures in >> >>>> BASIC ... probably sitting on the top shelf of my bookshelf at >> home. I >> >>>> could look up the title later tonight when I get home if it is of any >> >>>> interest. >> >>>> >> >>>> Ken >> >>>> >> >>> >> >
Re: [M100] Books on programming
The treasure horde program isn't posted anywhere. It's not long, but I don't have a copy on this machine. When I get home, I can send it to the list. On Tue, Jan 7, 2020 at 4:00 PM Peter Vollan wrote: > You may be interested in knowing that I have already cut that text out > of the pdf of Dragon #74 and then pasted it back together in a text > file. Better than typing it all in like the old days, yes? I just ran > it in Virtual T (Model 100) and it barfs at the command "randomize". > > I did the same thing with a program to generated character for TSR's > Top Secret RPG, and then adapted it for the Model 100. It looks at the > tail end of TIME$ to randomise from 1 to 10 and then goes through that > many random numbers. It is on my Club 100 member page, but the member > pages are unfortunately down just now. > > I know that there is a program that does exactly what you describe > called D20.BA. I don't know how it randomises. > > I am interested in that program to generate treasure. BTW it is called > a treasure "hoard". > > On Tue, 7 Jan 2020 at 13:15, Jason Paul wrote: > > > > In most cases the syntax could change but the command should mostly be > the same. Depending on what machine you're using that particular book was > published with versions for specific Basics Commodore Atari Apple TRS-80 > etc. > > > > Do a Google search for Dragon magazine 74 PDF and there should be a > program listing that is a dungeon Master's kind of utility program. It's > not the only one. Don't be confused by the battle computer that is really > just a slotted wheel for determining combat to hit percentages. > > > > On Tue, Jan 7, 2020, 4:10 PM James Zeun wrote: > >> > >> It says for the TRS80 Model 3... I'm assuming that would still be > alright? > >> > >> > >> > >> On Tue, 7 Jan 2020, 8:55 pm Ken Pettit, wrote: > >>> > >>> Hi James, > >>> > >>> I just remembered the title. It is "Golden Flutes and Great Escapes": > >>> > >>> > http://www.apple-iigs.info/doc/fichiers/goldenflutesandgreatescapes.pdf > >>> > >>> Ken > >>> > >>> On 1/7/20 12:48 PM, James Zeun wrote: > >>> > >>> Yes please! That would be great! > >>> > >>> On Tue, 7 Jan 2020, 8:36 pm Ken Pettit, wrote: > > > On 1/7/20 11:12 AM, Jerry Stratton wrote: > >> I don't know if anyone has any books they'd be willing to part > with or just recommend one. > > > > If your D includes wanting to write text adventures in BASIC, > Tim Hartnell’s Creating Adventure Games On Your Computer was very nice. > > Come to think of it, I still own a book on writing text adventures in > BASIC ... probably sitting on the top shelf of my bookshelf at home. > I > could look up the title later tonight when I get home if it is of any > interest. > > Ken > > >>> >
Re: [M100] Books on programming
That's actually a cooler idea than what I was talking about.
My code "shakes the cup" until you tap a key.
But "hold down the key, and when you release it, then take the random
number" is an even better idea. I need to try that out. Much more
interactive. You can even use the old trick where you print "\", "|", "/",
"-" in sequence (with back spaces before each print!) while looping waiting
for the key to be released. That makes a spinning "busy" indicator. Look up
the ASCII code for backspace. Try this test program to get the idea
5 BS$=CHR$(8):CLS:PRINT"Waiting";
10 FOR I=1TO4:PRINT BS$;MID$("/õ\-",I,1);:X=RND(1):NEXT I
20 IF INKEY$="" THEN 10
40 REM Now your randomizer is in a more random state
Unexpectedly, if you use i% or say DEFINT I first, the animation runs more
slowly, which might be useful to you.
I actually ran this program in VirtualT, so it should work.
Of course hack this up to work however makes the most sense to you. You
could put the INKEY$ test inside the FOR/NEXT loop, for instance.
On Tue, Jan 7, 2020 at 9:49 AM James Zeun wrote:
> Ok holding down a key to 'roll dice' is a genius idea.
>
> I understood a bit of that line, but I've delved in to keypresses etc. So
> this will be all new territory for me. But sounds exciting :-)
>
> On Tue, 7 Jan 2020, 3:27 pm Dan Higdon, wrote:
>
>> In my own random number based programs (for Traveller, not D, lol -
>> Traveller subsector generation is fun) I usually have a "busy loop" that
>> does something like D=RND(1) over and over until the user presses a key,
>> and then takes the next RND(1) value as my roll. This is the computer
>> equivalent of "shaking the dice cup", and lets the human's own reaction
>> times help with randomization.
>> Sort of like this:
>> 100 d=rnd(1): c=inkey$: if c=="" then 100
>> If you only want to wait for a keypress, you can of course do:
>> 100 d=rnd(1): if inkey$=="" then 100
>> I did a D (1e/2e) treasure table generator that used this trick. You'd
>> type the treasure code letter, and it would update the on-screen horde.
>> Space cleared the horde, ESC quite the program, and it "rattled the dice"
>> in a busy loop waiting for input. maybe not the most power efficient
>> program (not sure if ModelT "throttles down" while waiting for keyboard
>> interrupts or not), but it's easy to use. Takes a bit to load though,
>> because of the treasure tables. I didn't get to the point where it
>> enumerated the gems and magic items, nor do I have "Print a horde report"
>> working, since I don't have a ModelT compatible printer.
>>
>> On Tue, Jan 7, 2020 at 6:44 AM James Zeun wrote:
>>
>>> I already have a reasonable idea how the program should work.
>>>
>>> When run, it will ask the user the number of dice required. (Value A)
>>>
>>> Having established that value, the next INPUT shall be to determine the
>>> type of dice in play. (Value B)
>>>
>>> With those two values, I will either use the randomiser to roll the dice
>>> or if I can be a little fancy (as someone mentioned the randomiser isn't
>>> very random). I might have the computer wait for the user to tap the
>>> SPACEBAR or RETURN key twice. And use the time gap between the two as a
>>> value to use in the equation. (Value C)
>>>
>>> I'm utter rubbish at math, so I might have to trouble someone for a
>>> little help.
>>>
>>> An additional option would be to roll multiple dice of different types.
>>> So after inputting the value for one dice. The program asks the user if
>>> they'd like to add another.
>>>
>>>
>>>
>>> On Tue, 7 Jan 2020, 12:20 pm Charles Hudson, wrote:
>>>
>>>> On January 6th James Zeun wrote:
>>>> "It would be even cooler on a TRS80 M100." I apologize for my
>>>> ignorance in that I know nothing about the D game, never having played
>>>> it, but I applaud your willingness to undertake the task. Programming
>>>> breaks down into two (usually sequential, but don't ever let yourself get
>>>> dragged into the argument) tasks: strategy and implementation. The
>>>> strategy, known as the "algorithm", is just the logical path ("steps") to
>>>> accomplish the desired end. Implementation is using a language's syntax
>>>> ("commands") to describe each step in sufficient detail such that the
>>>> computer can carry them out. If you're going to do this on
Re: [M100] Books on programming
In my own random number based programs (for Traveller, not D, lol -
Traveller subsector generation is fun) I usually have a "busy loop" that
does something like D=RND(1) over and over until the user presses a key,
and then takes the next RND(1) value as my roll. This is the computer
equivalent of "shaking the dice cup", and lets the human's own reaction
times help with randomization.
Sort of like this:
100 d=rnd(1): c=inkey$: if c=="" then 100
If you only want to wait for a keypress, you can of course do:
100 d=rnd(1): if inkey$=="" then 100
I did a D (1e/2e) treasure table generator that used this trick. You'd
type the treasure code letter, and it would update the on-screen horde.
Space cleared the horde, ESC quite the program, and it "rattled the dice"
in a busy loop waiting for input. maybe not the most power efficient
program (not sure if ModelT "throttles down" while waiting for keyboard
interrupts or not), but it's easy to use. Takes a bit to load though,
because of the treasure tables. I didn't get to the point where it
enumerated the gems and magic items, nor do I have "Print a horde report"
working, since I don't have a ModelT compatible printer.
On Tue, Jan 7, 2020 at 6:44 AM James Zeun wrote:
> I already have a reasonable idea how the program should work.
>
> When run, it will ask the user the number of dice required. (Value A)
>
> Having established that value, the next INPUT shall be to determine the
> type of dice in play. (Value B)
>
> With those two values, I will either use the randomiser to roll the dice
> or if I can be a little fancy (as someone mentioned the randomiser isn't
> very random). I might have the computer wait for the user to tap the
> SPACEBAR or RETURN key twice. And use the time gap between the two as a
> value to use in the equation. (Value C)
>
> I'm utter rubbish at math, so I might have to trouble someone for a little
> help.
>
> An additional option would be to roll multiple dice of different types. So
> after inputting the value for one dice. The program asks the user if they'd
> like to add another.
>
>
>
> On Tue, 7 Jan 2020, 12:20 pm Charles Hudson, wrote:
>
>> On January 6th James Zeun wrote:
>> "It would be even cooler on a TRS80 M100." I apologize for my ignorance
>> in that I know nothing about the D game, never having played it, but I
>> applaud your willingness to undertake the task. Programming breaks down
>> into two (usually sequential, but don't ever let yourself get dragged into
>> the argument) tasks: strategy and implementation. The strategy, known as
>> the "algorithm", is just the logical path ("steps") to accomplish the
>> desired end. Implementation is using a language's syntax ("commands") to
>> describe each step in sufficient detail such that the computer can carry
>> them out. If you're going to do this on the Model 100 the you probably will
>> want to use the built-in BASIC programming language. Hopefully you have the
>> Model 100 manual, which has all of the syntax detailed, including the RND
>> function, which will be essential to your implementation. Your strategy
>> will be to determine /declare the number of dice in play and the number of
>> sides (range of values, if D dice differ from the familiar 6-sided,
>> dotted cube) on any given die, and then to create a random value for each
>> die in play that is within the domain of legal possibilities for the game.
>> Later you can expand the program to display these values, but generating
>> them is the first task. I know I've seen this algorithm in one of my
>> books - I like books, too - but when I find it I'll post it.
>>
>> -CH-
>>
>
Re: [M100] Issue with sd2tpdd
Sure, there are a lot of things I'd do differently if it were my program.
:)
On Tue, Oct 15, 2019 at 10:37 AM Fugu ME100 wrote:
> I would probably just use memset rather than the for loop. :)
>
> From: M100 on behalf of Dan Higdon <
> therealh...@gmail.com>
> Reply-To:
> Date: Tuesday, October 15, 2019 at 8:10 AM
> To:
> Subject: Re: [M100] Issue with sd2tpdd
>
> I'd also consider re-writing clear buffer to take a (char *c) parameter,
> like this:
>
> void clearBuffer(*char** buffer, int bufferSize){ //Fills the buffer with
> 0x00
> for(int i=0; i *buffer[i] = '\0';*
> }
> }
>
>
Re: [M100] Issue with sd2tpdd
I'd also consider re-writing clear buffer to take a (char *c) parameter,
like this:
void clearBuffer(*char** buffer, int bufferSize){ //Fills the buffer with
0x00
for(int i=0; i wrote:
> A couple of notes:
> After line 191 (term = i;), insert a break statement. This may actually
> fix the extra null problem.
>
> Change the declaration of the parameter in 147 to (char const * c). Do the
> same on line 98. This will silence a lot of the warnings.
>
> On Tue, Oct 15, 2019 at 5:45 AM Brian K. White wrote:
>
>> I'll do some more methodical testing to try to duplicate.
>> --
>> bkw
>>
>> On 10/15/19 4:55 AM, Gary Hammond wrote:
>> >
>> > With the code for sd2tpdd from GitHub, the compiler was issuing the
>> > warnings below. I have gone through and corrected them and the
>> > compiler is now happy and the randomness in the first 2 characters is
>> > less random. They are still garbage characters but now they are nearly
>> > consistently the same garbage for a given file.
>> >
>> > For example, for 3 runs of the load/save of the same file, I got the
>> > following first 2 bytes (hex)
>> >
>> > 5C 89
>> >
>> > 97 8A
>> >
>> > 5C 89
>> >
>> > On a different file I got 1B 8A
>> >
>> > The compiler warnings were:
>> >
>> > 184:33: warning: invalid conversion from 'char*' to 'byte* {aka
>> > unsigned char*}' [-fpermissive]
>> >
>> > 92:6: note: initializing argument 1 of 'void clearBuffer(byte*, int)'
>> >
>> > 253:30: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > 379:28: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > 473:24: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > 498:24: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > 522:34: warning: ISO C++ forbids converting a string constant to
>> > 'char*' [-Wwrite-strings]
>> >
>> > The NULL character is still being appended to the end of the file…no
>> > luck so far chasing that one down.
>> >
>> > To help with those who can confirm that they have their board working
>> > fine, I am using Arduino 1.8.10 for build and upload.
>> >
>> > The GitHub page for the source I am using is
>> > https://github.com/TangentDelta/SD2TPDD in case I am using the wrong
>> one.
>> >
>> > I have now tried my 2 slightly suspect AliExpress Arduino Mega clones
>> > and various combinations of el cheapo SD card readers and shop bought
>> > ones. The genuine Arduino Mega I ordered from arduino.cc arrived today
>> > so have swapped out the clones for the genuine article and still no
>> luck.
>> >
>>
>>
Re: [M100] Issue with sd2tpdd
A couple of notes:
After line 191 (term = i;), insert a break statement. This may actually fix
the extra null problem.
Change the declaration of the parameter in 147 to (char const * c). Do the
same on line 98. This will silence a lot of the warnings.
On Tue, Oct 15, 2019 at 5:45 AM Brian K. White wrote:
> I'll do some more methodical testing to try to duplicate.
> --
> bkw
>
> On 10/15/19 4:55 AM, Gary Hammond wrote:
> >
> > With the code for sd2tpdd from GitHub, the compiler was issuing the
> > warnings below. I have gone through and corrected them and the
> > compiler is now happy and the randomness in the first 2 characters is
> > less random. They are still garbage characters but now they are nearly
> > consistently the same garbage for a given file.
> >
> > For example, for 3 runs of the load/save of the same file, I got the
> > following first 2 bytes (hex)
> >
> > 5C 89
> >
> > 97 8A
> >
> > 5C 89
> >
> > On a different file I got 1B 8A
> >
> > The compiler warnings were:
> >
> > 184:33: warning: invalid conversion from 'char*' to 'byte* {aka
> > unsigned char*}' [-fpermissive]
> >
> > 92:6: note: initializing argument 1 of 'void clearBuffer(byte*, int)'
> >
> > 253:30: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > 379:28: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > 473:24: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > 498:24: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > 522:34: warning: ISO C++ forbids converting a string constant to
> > 'char*' [-Wwrite-strings]
> >
> > The NULL character is still being appended to the end of the file…no
> > luck so far chasing that one down.
> >
> > To help with those who can confirm that they have their board working
> > fine, I am using Arduino 1.8.10 for build and upload.
> >
> > The GitHub page for the source I am using is
> > https://github.com/TangentDelta/SD2TPDD in case I am using the wrong
> one.
> >
> > I have now tried my 2 slightly suspect AliExpress Arduino Mega clones
> > and various combinations of el cheapo SD card readers and shop bought
> > ones. The genuine Arduino Mega I ordered from arduino.cc arrived today
> > so have swapped out the clones for the genuine article and still no luck.
> >
>
>
[M100] I2C and ModelT
I was wondering if the ModelT is fast enough to process I2C data, considering that the data is clocked by the sender. I know I can always use an Arduino to talk to I2C devices, and then use RS232 to talk to the arduino from my ModelT, but cutting out the middle device seems useful. Also - I'm presuming that any such device would need to connect to the system connector through some bit of interface circuitry. I had originally thought that the barcode port would be ideal, except that it's input only. (I guess a small device that took parallel input/output from the system bus and strobed it over the I2C bus, and which delivered return bytes with an interrupt signal would be fairly simple to create, and be less of a load on the ModelT, but that's just rampant speculation. The added complication of not messing with REX could invalidate this idea though.) I don't have a pressing application for doing I2C with my ModelT, since as I've mentioned, there's always the Arduino, but I thought if anyone had experimented or even just daydreamed about such things, it would be the members of this list. :) Thanks, /hdan
Re: [M100] compact embedded ML coding
Cool, thanks. I thought I had a handle on how BASIC was storing strings, but I was starting to have doubts. :) It's nice that constant strings seem to be referenced out of the actual source code though, and not copied into the string table. Maybe Bill knew what he was doing after all. :) On Thu, Sep 19, 2019 at 12:49 PM Stephen Adolph wrote: > ok the root of the issue is my posted file. I'll fix that tonight. > > On Thu, Sep 19, 2019 at 1:40 PM Stephen Adolph > wrote: > >> yep like that. >> >> On Thu, Sep 19, 2019 at 1:38 PM Dan Higdon wrote: >> >>> It was earlier in this thread. >>> I would have thought that the proper code would look more like: >>> >>> 10 a$="your machine code here" >>> 20 a%=varptr(a$): call (peek(a%+1)+256*peek(a%+2)) >>> >>> On Thu, Sep 19, 2019 at 12:33 PM Stephen Adolph >>> wrote: >>> >>>> yah thats not up to date. where did you get that? >>>> I can post a correction. >>>> >>>> On Thu, Sep 19, 2019 at 1:31 PM Dan Higdon >>>> wrote: >>>> >>>>> I'm still struggling to understand how this works: >>>>> >>>>> 10 a$="Code in ASCII" >>>>> 20 call varptr(a$) >>>>> >>>>> Doesn't varptr(a$) return the address of the string descriptor, which >>>>> is [len,lo,hi]? Wouldn't you have to synthesize the call address from >>>>> lo+hi*256? >>>>> >>>>> Or is there something magical about how constant strings are stored? >>>>> And how do you relocate the code? Or is the first entry in the string >>>>> table >>>>> a known address, and you just assemble for that position? >>>>> >>>>> Thanks! >>>>> >>>>> On Fri, Sep 13, 2019 at 10:30 AM Kurt McCullum >>>>> wrote: >>>>> >>>>>> >>>>>> It would appear that Steve already came up with a simple solution to >>>>>> my problem. I just had to find the file "embedding short ML routines in >>>>>> BASIC.txt" >>>>>> >>>>>> 10 a$="Code in ASCII" Zeros not valid but I can work with that. >>>>>> 20 call varptr(a$) >>>>>> >>>>>> Simple solution Steve. My thanks to you for putting that file >>>>>> together. >>>>>> >>>>>> Kurt >>>>>> >>>>>
Re: [M100] compact embedded ML coding
It was earlier in this thread. I would have thought that the proper code would look more like: 10 a$="your machine code here" 20 a%=varptr(a$): call (peek(a%+1)+256*peek(a%+2)) On Thu, Sep 19, 2019 at 12:33 PM Stephen Adolph wrote: > yah thats not up to date. where did you get that? > I can post a correction. > > On Thu, Sep 19, 2019 at 1:31 PM Dan Higdon wrote: > >> I'm still struggling to understand how this works: >> >> 10 a$="Code in ASCII" >> 20 call varptr(a$) >> >> Doesn't varptr(a$) return the address of the string descriptor, which is >> [len,lo,hi]? Wouldn't you have to synthesize the call address from >> lo+hi*256? >> >> Or is there something magical about how constant strings are stored? And >> how do you relocate the code? Or is the first entry in the string table a >> known address, and you just assemble for that position? >> >> Thanks! >> >> On Fri, Sep 13, 2019 at 10:30 AM Kurt McCullum >> wrote: >> >>> >>> It would appear that Steve already came up with a simple solution to my >>> problem. I just had to find the file "embedding short ML routines in >>> BASIC.txt" >>> >>> 10 a$="Code in ASCII" Zeros not valid but I can work with that. >>> 20 call varptr(a$) >>> >>> Simple solution Steve. My thanks to you for putting that file together. >>> >>> Kurt >>> >>
Re: [M100] compact embedded ML coding
I'm still struggling to understand how this works: 10 a$="Code in ASCII" 20 call varptr(a$) Doesn't varptr(a$) return the address of the string descriptor, which is [len,lo,hi]? Wouldn't you have to synthesize the call address from lo+hi*256? Or is there something magical about how constant strings are stored? And how do you relocate the code? Or is the first entry in the string table a known address, and you just assemble for that position? Thanks! On Fri, Sep 13, 2019 at 10:30 AM Kurt McCullum wrote: > > It would appear that Steve already came up with a simple solution to my > problem. I just had to find the file "embedding short ML routines in > BASIC.txt" > > 10 a$="Code in ASCII" Zeros not valid but I can work with that. > 20 call varptr(a$) > > Simple solution Steve. My thanks to you for putting that file together. > > Kurt >
Re: [M100] Copy and Paste from BASIC
Ooh, I like the idea of patching up the paste buffer's file table entry I need to try that out over the weekend. Thanks, that's a great idea. The only reason I don't just use my own file is that for the tool I'm imagining, it would be handy to generate values directly into the paste buffer so I don't have to generate the file, load the file, copy the data, load the destination file, then paste the data. It also opens up the possibility of a small routine that just clears the paste buffer (freeing up the memory) if I have copied a large chunk of data, and one that shows the buffer's contents without creating another file to paste it into. Though those last two programs are mostly useful in dealing with data I put in the paste buffer myself, so they may not be as generally useful as they would seem. One wrinkle - I'm using a 102, so HAYASH isn't a consistent name. I may need to patch it right before opening it every time. I haven't investigated that part. On Fri, Jul 19, 2019 at 1:57 PM John R. Hogerhuis wrote: > > > On Fri, Jul 19, 2019 at 11:22 AM Dan Higdon wrote: > >> Peeking the paste buffer and scanning for EOF would definitely work for >> reading the buffer. The writing of data into the paste buffer seems like a >> harder problem. >> >> Might using the "make room" function (or whatever its real name is, I'm >> no near my docs right now) be capable of resizing the fake file to hold new >> data? >> I'm imagining a machine language routine that can replace/append a string >> onto that file. >> > > If you mess with the file system from BASIC you will probably want to do > some embedded ML code. There are multiple steps besides just MAKHOL. > > Why not just use a regular file? BASIC knows how to deal with RAM text > files. > > You can mark it hidden so it doesn't show up in the menu. Hopefully BASIC > would still let you access it hidden, don't know. You could unhide it > temporarily if necessary. > > But it will take up one menu slot. > > Hey there's an idea... maybe patch the paste buffer entry in the > Directory... HAYASH to make it visible to BASIC (give it a name, unhide > it, open, append, close) > > -- John. >
Re: [M100] Copy and Paste from BASIC
Peeking the paste buffer and scanning for EOF would definitely work for reading the buffer. The writing of data into the paste buffer seems like a harder problem. Might using the "make room" function (or whatever its real name is, I'm no near my docs right now) be capable of resizing the fake file to hold new data? I'm imagining a machine language routine that can replace/append a string onto that file. On Fri, Jul 19, 2019 at 1:11 PM John R. Hogerhuis wrote: > > > On Fri, Jul 19, 2019 at 10:15 AM Dan Higdon wrote: > >> So maybe it's impossible to access the paste buffer from inside a basic >> program after all, except trivially when the user presses during an >> input statement. >> Well, if I figure something out one day, I'll share it here. >> >>> >>> > Maybe that's your solution. Poke PASTE into the keyboard buffer and run an > INPUT command. > > Though you have a phasing issue, since INPUT wants to block. If you do the > INPUT command first, you'll never get to the POKEs. If you POKE first, the > paste will happen while INPUT isn't started. Maybe the characters just sit > in the keyboard buffer until an input command runs in which case it would > work. > > I don't know much about the PASTE buffer. According to Inside the Model > 100, it is the hidden "Hayashi" file. That's more than 6 characters so I > guess, HAYASH > > But Tandy removed the names in some version of the Rom. > > paste buffer pointer is at F88C > > So you cannot open the file by name. > > You might be able to pass the address to a low level part of the file open > command and call it. Not sure. > > -- John. >
Re: [M100] Copy and Paste from BASIC
So maybe it's impossible to access the paste buffer from inside a basic program after all, except trivially when the user presses during an input statement. Well, if I figure something out one day, I'll share it here. On Thu, Jul 18, 2019 at 1:49 PM Gene Corrigan wrote: > Ask the Russians: they've got all the codes in the world. > > epc > > > On Jul 18, 2019, at 11:00 AM, Dan Higdon wrote: > > > > Hey ModelT enthusiats! > > > > Has anyone cracked the code on how to access the paste buffer from > inside a BASIC program? I have some utilities I'm working on that would > benefit from using the pastebuffer as an IPC mechanism, since sometimes > they're just generating something I want to insert into a document. > > > > It feels like you should be able to open the paste buffer's file as an > input/output channel, since it looks like it's stored as an invisible file, > but I can't figure out how to do it. I have a Model102, so the hidden > filename of this buffer is semi-randomized. > > > > I imagine it would be possible with a small machine language routine to > open that file and bind it to an IO channel in BASIC. (Maybe passing the > channel number in A, and some option flags in HL), but I don't understand > the Model100's ROM routines well enough to pull that off, and I would be > shocked if I were the first person to think of doing this. > > > > Anyhow, thanks for any idea! > > Dan Higdon >
[M100] Copy and Paste from BASIC
Hey ModelT enthusiats! Has anyone cracked the code on how to access the paste buffer from inside a BASIC program? I have some utilities I'm working on that would benefit from using the pastebuffer as an IPC mechanism, since sometimes they're just generating something I want to insert into a document. It feels like you should be able to open the paste buffer's file as an input/output channel, since it looks like it's stored as an invisible file, but I can't figure out how to do it. I have a Model102, so the hidden filename of this buffer is semi-randomized. I imagine it would be possible with a small machine language routine to open that file and bind it to an IO channel in BASIC. (Maybe passing the channel number in A, and some option flags in HL), but I don't understand the Model100's ROM routines well enough to pull that off, and I would be shocked if I were the first person to think of doing this. Anyhow, thanks for any idea! Dan Higdon
Re: [M100] dsub 25 hood that fits
I bought one of these from Amazon, and it fits my 102. But it's going to my PC's COM port, not a USB port, so maybe this isn't what people are looking for. StarTech.com 10 ft Cross Wired DB9 to DB25 Serial Null Modem Cable - F/M On Sat, Jun 1, 2019 at 2:19 PM Mike Stein wrote: > Looks like a worthy 3d printing project... > > - Original Message - > *From:* Mike Stein > *To:* m...@bitchin100.com > *Sent:* Saturday, June 01, 2019 2:36 PM > *Subject:* Re: [M100] dsub 25 hood that fits > > This is what I use(d) but it appears that Souriau hasn't made them for > quite a while: > > > Why not just stick one of these on a 'normal' shell: > > m > > - Original Message - > *From:* Brian White > *To:* Model 100 Discussion > *Sent:* Saturday, June 01, 2019 1:19 PM > *Subject:* [M100] dsub 25 hood that fits > > Anyone ever find a dsub 25 hood that fits in the serial port openeing on > M100? > > -- > bkw > >
Re: [M100] Hello, and REX question
If I get anything working, I will definitely be bragging about it here. :) A sequencer feels like it's going to need some assembly language for the timer callback. I'm passably comfortable with 8080 assembly language, but I'm still working out the development toolchain. BYTEIT.BA is a great little assembler, but it's SO slow. To date, I've only put together a BASIC callable routine that will uppercase or lowercase a string in-place. I suspect I'll need to resort to cross-platform tools and VirtualT for any more serious coding. On Fri, 10 May 2019 22:49:22 -0400 Michael Brant wrote: > Very curious about your synth project. When you get it going, an update > would be great >
[M100] Hello, and REX question
Hello all, I'm a new M102 owner (the last two months). I've been having a lot of fun messing around with my new little friend. I just recently purchased a REX chip for it, and I have a question about how the REX interacts with the system bus. Specifically, does it use any of the expansion i/o port addresses. and if so, which ones? I ask because I'm considering breadboarding the simple parallel input/output circuits in that "inside the model 100" book (probably not the actual title, but I'm not near my pdf of that book right now.). I have it in mind to generate 8 trigger/gate signals to control some analog synthesizer modules, and I don't want to accidentally corrupt data in the REX by outing values to a port that's being used for something else. (I realize the ModelT's performance may not be up to precision drum machine standards :), but these sorts of projects are fun for me.) Thanks in advance for any details, Dan Higdon
