Re: [M100] Special "c0de" helper in CloudT

[John R. Hogerhuis]

On Sat, Jan 14, 2023 at 5:35 AM Stephen Adolph  wrote:

> You know what might also be a fun thing to add, is a way to select a
> different main ROM.
>

At the moment the main T102 is hard coded in. Wouldn't be much work to get
that functional. Horses for courses though... I think of CloudT to be the
fun emulator you pull up to scratch the M100 itch wherever you're at, no
installation. Experiments. BASIC programming. BASIC games. When I want
tricky setups and cycle accuracy VirtualT or a real M100 is 100% the way to
go.

But I don't actually know how people are using CloudT.

We saw recently that Sarah Libman published a very cool Teeny integrated
> main ROM, trading off under-used functions of the standard M100.
>

Did she leave the cassette stuff? CloudT relies on that staying in-tact
because it's file I/O solution is completely based on that.


> I have a "hardware scrolling" main rom to toy with.
>

I definitely need to work on hardware scrolling. I'm pretty sure the
hardware scrolling has issues in CloudT. I want the emulation to be as
accurate as I can. I was thinking about making a scrolling banner, but with
a short ML routine to scroll it left. Getting that working would probably
address whatever little bug is in there.

Anyway I'm pretty sure that ROM would not work at present.

-- John.

Re: [M100] Special "c0de" helper in CloudT

[John R. Hogerhuis]

On Sat, Jan 14, 2023 at 5:31 AM Stephen Adolph  wrote:

> thats pretty cool John.
> The other part of this is, how to make use of the code.
> Have you thought about a button to support the poker code to go with the
> data?
>

Thought about it some.

For Raw code you just need to know how to compute the code address of a
string using VARPTR. At this point I can do that from memory but it isn't
completely obvious how to do it in BASIC.

Comma decimal is trivial to rewrite.

For all the others, I end up cut and pasting from other sources, or
rewriting..

To support this better I think you'd need a way to manage parameterizable
snippets of code. You'd want to be able to specify the loader type,
starting line number, override the variable names to use (to avoid
collision with other variables in your program), etc.

The ultimate solution to this kind of stuff is just to cook with gas, on
your desktop, with an assembler and something good at text processing
(Perl).

-- John.

>

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

Yah I know about that ask.  It is on my list.

On Sat, Jan 14, 2023 at 4:38 PM  wrote:

> An addendum: I was just chatting with the Backpack developer about this.
> Another point he brought up is that the Backpack won’t overwrite an
> existing file. Let’s say you are using TS-DOS and you try to save a file
> with the same name as one on the disk. The Backpack (like the real TPDD?)
> will return a file exists error. TS-DOS will ask if you want to overwrite.
> When you select YES TS-DOS first deletes the existing file on the disk then
> it saves the new file.
>
> The REX seems to ignore a file exists error and then gives up/times out.
> It would be nice to have the same sort of prompt that TS-DOS provides. The
> user may not wish to overwrite a previous backup, and this will give them a
> warning that they are about to do so.
>
>
>
> Jeff Birt
>
>
>
> *From:* bir...@soigeneris.com 
> *Sent:* Saturday, January 14, 2023 1:30 PM
> *To:* 'm...@bitchin100.com' 
> *Subject:* RE: [M100] Rex#..TPDD compatibility
>
>
>
> For the Backpack, when you save a file the Backpack needs to check to see
> if the file already exists. If you have a lot of files in the directory it
> will take a while to check all of them. The timeout on the REX is rather
> short so it gives up before the Backpack (or real drive I would guess) can
> respond. The work around is to save to a directory with few files. If you
> can increase the timeout on the REX it would probably solve the issue for
> it and the real drive.
>
>
>
> Jeff Birt
>
>
>

Re: [M100] Rex#..TPDD compatibility

[birt_j]

An addendum: I was just chatting with the Backpack developer about this. 
Another point he brought up is that the Backpack won’t overwrite an existing 
file. Let’s say you are using TS-DOS and you try to save a file with the same 
name as one on the disk. The Backpack (like the real TPDD?) will return a file 
exists error. TS-DOS will ask if you want to overwrite. When you select YES 
TS-DOS first deletes the existing file on the disk then it saves the new file. 

The REX seems to ignore a file exists error and then gives up/times out. It 
would be nice to have the same sort of prompt that TS-DOS provides. The user 
may not wish to overwrite a previous backup, and this will give them a warning 
that they are about to do so.

 

Jeff Birt

 

From: bir...@soigeneris.com  
Sent: Saturday, January 14, 2023 1:30 PM
To: 'm...@bitchin100.com' 
Subject: RE: [M100] Rex#..TPDD compatibility

 

For the Backpack, when you save a file the Backpack needs to check to see if 
the file already exists. If you have a lot of files in the directory it will 
take a while to check all of them. The timeout on the REX is rather short so it 
gives up before the Backpack (or real drive I would guess) can respond. The 
work around is to save to a directory with few files. If you can increase the 
timeout on the REX it would probably solve the issue for it and the real drive.

 

Jeff Birt

 

Re: [M100] Fixing a CCR 82 the proper way

[Cedric Amand]

Thanks Birt, I'm actually one of your subscribers :) , but in this case I watch 
youtube mostly on my smart tv, and it cuts the titles of the videos after 6 or 
7 words, actually I think the iphone app does that too ; and so because of the 
title I did not realize this particular video was about ccr 82 - I must have 
missed it. I'll have a look. I think my belts were initially too tight when I 
put them in, but now - like only 1 year later - they are way too loose. Which 
means those cheap "assorted belts" out of Amazon are a heap of cr$$ - which 
probably isn't a surprise to anyone. It's not an easy device to disassemble 
iirc, so I'd rather do it once and for all now, with the super proper belts. Le 
2023-01-14 21:45, bir...@soigeneris.com a écrit : > > > > I just made a video 
about the CCR-82. Link below. The belt dimensions are in the video description. 
In the Links section of the description are links to the company who makes the 
belts and the distributor I bought them from. A very unscientific specification 
is ‘just tight enough to do the job’. Since very little power is being 
transmitted little tension is needed. Belts should not be tight. This puts too 
much tension on the pulleys and wears things out prematurely. > > The quality 
of the belt is important too. I have shied away from big sets of random belts 
to buying belts of known length and quality. That way they should last for the 
rest of my lifetime at least. > > > > > > > > While I got this deck 
mechanically working the amplifier IC was bad. I did get a new chip but have 
not installed it yet. > > > > > > > > https://youtu.be/aqW6cF-4btI > > Jeff 
Birt > > > > > > > > > From: M100  On Behalf 
Of Cedric Amand > Sent: Saturday, January 14, 2023 2:30 PM > To: 
m...@bitchin100.com > Subject: [M100] Fixing a CCR 82 the proper way > > > > > 
> > > > > Hello everyone, > > > > > > > > > > > > Hi have a CCR-82 that kinda 
"works" but I know it's absolutely not working well. > > > > > > I initially 
changed the belts with a set of assorted belts out of amazon, again this "kinda 
works", but they quickly lost their tension, > > > > > > The tape goes way too 
slow. > > > > > > I ordered a 3Khz test cassette, but before using it I guess I 
have to be confident in my new belts. > > > > > > What would be real, actual, 
best belts for the ccr82 ? Exact dimensions seem to be a mystery. > > > > > > 
What should be the belt "tension" (tight, super tight, loose ?) > > > > > > > > 
> > > > The technical manual has a tuning procedure, which i'll try to follow 
for the parts that don't require exotic equipments like small dynamometers, but 
if anyone has experiences to share about rejuvenating a CCR82 (or I guess 81) 
that would be much appreciated > > > > > > > > > > > > thanks ! > > > >

Re: [M100] Fixing a CCR 82 the proper way

[birt_j]

I just made a video about the CCR-82. Link below. The belt dimensions are in 
the video description. In the Links section of the description are links to the 
company who makes the belts and the distributor I bought them from. A very 
unscientific specification is ‘just tight enough to do the job’. Since very 
little power is being transmitted little tension is needed. Belts should not be 
tight. This puts too much tension on the pulleys and wears things out 
prematurely. 

The quality of the belt is important too. I have shied away from big sets of 
random belts to buying belts of known length and quality. That way they should 
last for the rest of my lifetime at least.

 

While I got this deck mechanically working the amplifier IC was bad. I did get 
a new chip but have not installed it yet.

 

https://youtu.be/aqW6cF-4btI

Jeff Birt

 

From: M100  On Behalf Of Cedric Amand
Sent: Saturday, January 14, 2023 2:30 PM
To: m...@bitchin100.com
Subject: [M100] Fixing a CCR 82 the proper way

 

 Hello everyone,

 

Hi have a CCR-82 that kinda "works" but I know it's absolutely not working 
well. 

I initially changed the belts with a set of assorted belts out of amazon, again 
this "kinda works", but they quickly lost their tension,

The tape goes way too slow. 

I ordered a 3Khz test cassette, but before using it I guess I have to be 
confident in my new belts.

What would be real, actual, best belts for the ccr82 ? Exact dimensions seem to 
be a mystery.

What should be the belt "tension" (tight, super tight, loose ?) 

 

The technical manual has a tuning procedure, which i'll try to follow for the 
parts that don't require exotic equipments like small dynamometers, but if 
anyone has experiences to share about rejuvenating a CCR82 (or I guess 81) that 
would be much appreciated 

 

thanks !

[M100] Fixing a CCR 82 the proper way

[Cedric Amand]

Hello everyone, Hi have a CCR-82 that kinda "works" but I know it's absolutely 
not working well. I initially changed the belts with a set of assorted belts 
out of amazon, again this "kinda works", but they quickly lost their tension, 
The tape goes way too slow. I ordered a 3Khz test cassette, but before using it 
I guess I have to be confident in my new belts. What would be real, actual, 
best belts for the ccr82 ? Exact dimensions seem to be a mystery. What should 
be the belt "tension" (tight, super tight, loose ?) The technical manual has a 
tuning procedure, which i'll try to follow for the parts that don't require 
exotic equipments like small dynamometers, but if anyone has experiences to 
share about rejuvenating a CCR82 (or I guess 81) that would be much appreciated 
thanks !

Re: [M100] Rex#..TPDD compatibility

[birt_j]

For the Backpack, when you save a file the Backpack needs to check to see if 
the file already exists. If you have a lot of files in the directory it will 
take a while to check all of them. The timeout on the REX is rather short so it 
gives up before the Backpack (or real drive I would guess) can respond. The 
work around is to save to a directory with few files. If you can increase the 
timeout on the REX it would probably solve the issue for it and the real drive.

 

Jeff Birt

 

From: M100  On Behalf Of Stephen Adolph
Sent: Saturday, January 14, 2023 9:30 AM
To: m...@bitchin100.com
Subject: Re: [M100] Rex#..TPDD compatibility

 

Here is the current status of REX# (and REXCPM) interworking.

Better than I thought!

 



 

Dosbox is set up to run pretty slow, but my set up runs Desklink well on 
Windows 10, and also runs PDD.EXE, which is great.

 

Backpack works for general use with REX#.  Just the REX# utilities for 
rebuilding etc do not work.

I'm not sure what makes Backpack unique in that sense.  But it will probably 
work once I fix the TPDD1/TPDD2 interworking.

Pretty sure I know what that is.

 

I still rely on LaddieAlpha for building and testing REX#.

 

 

On Sat, Jan 14, 2023 at 8:54 AM Stephen Adolph mailto:twospru...@gmail.com> > wrote:

thanks Josh, I think I should be able to test mComm windows.  

I imagine I need something special to use mComm android.

 

 

On Thu, Jan 12, 2023 at 10:14 PM Josh O’Keefe mailto:maj...@nachomountain.com> > wrote:

Those I have used “for real” recently not on your list:
mComm Python 
dlplus

Those I’m aware of off the top of my head not on your list, but can’t comment 
on further due to platform constraints:
mComm Windows
mComm Android


Sent from my iPhone

> On Jan 13, 2023, at 8:38 AM, Stephen Adolph   > wrote:
> 
> 
> Thinking about a maintenance release on REX# to pick up a bunch of fixes and 
> improvements.
> 
> One of the items is to make the interface to a TPDD client more reliable.
> 
> Did I get that right Brian? ;)
> 
> What are the clients that are needed?
> 
> Real TPDD1, TPDD2
> Nadsbox
> LaddieAlpha
> Backpack
> DLPilot
> Desklink on an old PC or DOSbox
> 
> What else?
> 
> Thanks
> Steve
> 

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

added DLPilot to the list:

[image: image.png]


On Sat, Jan 14, 2023 at 11:09 AM Stephen Adolph 
wrote:

> not yet but that is the plan
>
> On Sat, Jan 14, 2023 at 10:35 AM Cedric Amand  wrote:
>
>> I wish to add that the patched version you sent me (with enlarged delays)
>> worked on my TPDD1
>> Was this never merged with the "main" software ?
>>
>>
>> Le 2023-01-14 16:30, Stephen Adolph  a écrit :
>>
>> Here is the current status of REX# (and REXCPM) interworking.
>> Better than I thought!
>>
>>
>>

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

not yet but that is the plan

On Sat, Jan 14, 2023 at 10:35 AM Cedric Amand  wrote:

> I wish to add that the patched version you sent me (with enlarged delays)
> worked on my TPDD1
> Was this never merged with the "main" software ?
>
>
> Le 2023-01-14 16:30, Stephen Adolph  a écrit :
>
> Here is the current status of REX# (and REXCPM) interworking.
> Better than I thought!
>
>
>

Re: [M100] Rex#..TPDD compatibility

[Cedric Amand]

I wish to add that the patched version you sent me (with enlarged delays) 
worked on my TPDD1 Was this never merged with the "main" software ? Le 
2023-01-14 16:30, Stephen Adolph  a écrit : > > > Here is 
the current status of REX# (and REXCPM) interworking. > > Better than I 
thought! > > > >

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

Here is the current status of REX# (and REXCPM) interworking.
Better than I thought!

[image: image.png]

Dosbox is set up to run pretty slow, but my set up runs Desklink well on
Windows 10, and also runs PDD.EXE, which is great.

Backpack works for general use with REX#.  Just the REX# utilities for
rebuilding etc do not work.
I'm not sure what makes Backpack unique in that sense.  But it will
probably work once I fix the TPDD1/TPDD2 interworking.
Pretty sure I know what that is.

I still rely on LaddieAlpha for building and testing REX#.


On Sat, Jan 14, 2023 at 8:54 AM Stephen Adolph  wrote:

> thanks Josh, I think I should be able to test mComm windows.
> I imagine I need something special to use mComm android.
>
>
> On Thu, Jan 12, 2023 at 10:14 PM Josh O’Keefe 
> wrote:
>
>> Those I have used “for real” recently not on your list:
>> mComm Python
>> dlplus
>>
>> Those I’m aware of off the top of my head not on your list, but can’t
>> comment on further due to platform constraints:
>> mComm Windows
>> mComm Android
>>
>>
>> Sent from my iPhone
>>
>> > On Jan 13, 2023, at 8:38 AM, Stephen Adolph 
>> wrote:
>> >
>> > 
>> > Thinking about a maintenance release on REX# to pick up a bunch of
>> fixes and improvements.
>> >
>> > One of the items is to make the interface to a TPDD client more
>> reliable.
>> >
>> > Did I get that right Brian? ;)
>> >
>> > What are the clients that are needed?
>> >
>> > Real TPDD1, TPDD2
>> > Nadsbox
>> > LaddieAlpha
>> > Backpack
>> > DLPilot
>> > Desklink on an old PC or DOSbox
>> >
>> > What else?
>> >
>> > Thanks
>> > Steve
>> >
>>
>

Re: [M100] Rex#..TPDD compatibility

[Stephen Adolph]

thanks Josh, I think I should be able to test mComm windows.
I imagine I need something special to use mComm android.


On Thu, Jan 12, 2023 at 10:14 PM Josh O’Keefe 
wrote:

> Those I have used “for real” recently not on your list:
> mComm Python
> dlplus
>
> Those I’m aware of off the top of my head not on your list, but can’t
> comment on further due to platform constraints:
> mComm Windows
> mComm Android
>
>
> Sent from my iPhone
>
> > On Jan 13, 2023, at 8:38 AM, Stephen Adolph 
> wrote:
> >
> > 
> > Thinking about a maintenance release on REX# to pick up a bunch of fixes
> and improvements.
> >
> > One of the items is to make the interface to a TPDD client more reliable.
> >
> > Did I get that right Brian? ;)
> >
> > What are the clients that are needed?
> >
> > Real TPDD1, TPDD2
> > Nadsbox
> > LaddieAlpha
> > Backpack
> > DLPilot
> > Desklink on an old PC or DOSbox
> >
> > What else?
> >
> > Thanks
> > Steve
> >
>

Re: [M100] Special "c0de" helper in CloudT

[Stephen Adolph]

You know what might also be a fun thing to add, is a way to select a
different main ROM.
We saw recently that Sarah Libman published a very cool Teeny integrated
main ROM, trading off under-used functions of the standard M100.
I have a "hardware scrolling" main rom to toy with.

Is there a way to enable a main ROM swap?

..Steve

On Sat, Jan 14, 2023 at 8:29 AM Stephen Adolph  wrote:

> thats pretty cool John.
> The other part of this is, how to make use of the code.
> Have you thought about a button to support the poker code to go with the
> data?
>
> On Sat, Jan 14, 2023 at 2:15 AM John R. Hogerhuis 
> wrote:
>
>> [image: image.png]
>>
>> There is a new button on CloudT called "C0DE". It is not the same thing
>> as the CODE key on a real Model 100 keyboard. Note that you will probably
>> have to force-reload the app to get the new feature (Ctrl-Shift-R).
>>
>> This button brings up a dialog from which you can assemble any 8085
>> instruction covered at
>> https://bitchin100.com/wiki/index.php?title=8085_Reference. This
>> includes several known synonyms for the Undocumented Instructions
>>
>> Somehow it ended up looking like the Windows XP theme. A 20+ year old OS
>> is now retro right?
>>
>> You can move this dialog around the browser window using its title bar.
>> CloudT remembers (browser local storage) whether it was open and where you
>> last put it even if you close the dialog.  You can close it with the close
>> icon. You can toggle close it by clicking C0DE again.
>>
>> Number operands are considered decimal unless they only make sense as hex
>> (A-F characters) or are explicitly prefixed with $ or 0x.
>>
>> Examples...
>>
>> mvi a,10
>> 10 is decimal
>>
>> mvi a,1d
>> 1D is hex
>>
>> mvi a,11
>> 11 is decimal
>>
>> mvi a,$11
>> $11 is hex
>>
>> mvi a,0x11
>> 0x11 is hex
>>
>> When you type your instruction, if it makes sense, CloudT will
>> immediately show you the assembled bytes as hex. There is no support for a
>> symbol table or multiple instructions (yet).
>>
>> Now what makes it useful (to me) is there are four buttons that will
>> "type in" this data into BASIC.
>>
>> Raw
>> This injects your character as a 8-bit Model 100 character. The purpose
>> of this is for directly building quoted strings that contain XIP (execute
>> in place) code. This code of code must be specially constructed, but the
>> advantage is it requires no copying or processing to run.
>> So the instruction
>>
>> mov b,c assembles as $41
>> If you click Raw, it will show up in CloudT as if you typed the letter
>> 'A' since A is $41 = 65d.
>>
>> Raw-35-escape
>> This is an encoding I saw in Ken's programs. Characters less then ASCII
>> '#' are encoded as ASCII '#' followed by
>>
>> It's like Raw otherwise.
>>
>> So mov b,c will still type-in 'A'
>>
>> If you assemble NOP, that's instruction zero.
>>
>> So, as Raw-35-escape it will show up as
>>
>> ##
>>
>> Raw-35-escape code has to be minimally processed and copied somewhere
>> else. Like ALTLCD. It is very compact. The code to poke it in somewhere
>> else is not particularly complicated. But it probably deserves an XIP
>> injector for speed :-)
>>
>> Hex
>>
>> Traditional numbers and A-F hex encoding. It's not particularly compact,
>> it's not particularly tractable. Its main advantage is everyone will know
>> what it is if they list your BASIC program.
>>
>> Funny Hex
>> This is like hex but it uses 0-9 and puncuation : through ? instead of
>> A-F. Slightly more tractable than regular hex, since you don't need to look
>> up the nibble values, you can just subtract 48 from the ASCII
>> representation to get the 0..15 value.
>>
>> Comma Decimal
>> This is for encoding your program as comma-separated decimal, as in
>>
>> 10 DATA 110,120,1
>>
>> Advantages: the loader logic is simple and intuitive to write from
>> scratch. It has no limitations as to what you can represent. BASIC is tuned
>> to process it. The main disadvantage is it is bulky.
>>
>> Anyway, it's probably easier to understand by trying it than wading
>> through my ponderous exposition.
>>
>> If you're still scratching your head as what this is for, fair enough.
>>
>> I read somewhere that Acorn BASIC has a built in assembler. Forths tend
>> to as well though you can always "c," in a few bytes. Our BASIC doesn't. So
>> if you want to do some immediate assembly programming and experimentation
>> without cracking open a full assembler, this will assist you. A small step
>> up from hand assembling using the 8085 reference.
>>
>> For bigger programs, use a regular file assembler. CloudT will probably
>> never have that.. though it will probably get a disassembler/debugger
>> support. Again, targeted at experimenting with small subroutines. So maybe
>> it could disassemble the code embedded in a string on the screen. Or a
>> series of data statements.
>>
>> Let me know if you have any problems. Also if you have another favorite
>> encoding you've seen and would like included, let me know.
>>
>> -- John.
>>
>

Re: [M100] Special "c0de" helper in CloudT

[Stephen Adolph]

thats pretty cool John.
The other part of this is, how to make use of the code.
Have you thought about a button to support the poker code to go with the
data?

On Sat, Jan 14, 2023 at 2:15 AM John R. Hogerhuis  wrote:

> [image: image.png]
>
> There is a new button on CloudT called "C0DE". It is not the same thing as
> the CODE key on a real Model 100 keyboard. Note that you will probably have
> to force-reload the app to get the new feature (Ctrl-Shift-R).
>
> This button brings up a dialog from which you can assemble any 8085
> instruction covered at
> https://bitchin100.com/wiki/index.php?title=8085_Reference. This includes
> several known synonyms for the Undocumented Instructions
>
> Somehow it ended up looking like the Windows XP theme. A 20+ year old OS
> is now retro right?
>
> You can move this dialog around the browser window using its title bar.
> CloudT remembers (browser local storage) whether it was open and where you
> last put it even if you close the dialog.  You can close it with the close
> icon. You can toggle close it by clicking C0DE again.
>
> Number operands are considered decimal unless they only make sense as hex
> (A-F characters) or are explicitly prefixed with $ or 0x.
>
> Examples...
>
> mvi a,10
> 10 is decimal
>
> mvi a,1d
> 1D is hex
>
> mvi a,11
> 11 is decimal
>
> mvi a,$11
> $11 is hex
>
> mvi a,0x11
> 0x11 is hex
>
> When you type your instruction, if it makes sense, CloudT will immediately
> show you the assembled bytes as hex. There is no support for a symbol table
> or multiple instructions (yet).
>
> Now what makes it useful (to me) is there are four buttons that will "type
> in" this data into BASIC.
>
> Raw
> This injects your character as a 8-bit Model 100 character. The purpose of
> this is for directly building quoted strings that contain XIP (execute in
> place) code. This code of code must be specially constructed, but the
> advantage is it requires no copying or processing to run.
> So the instruction
>
> mov b,c assembles as $41
> If you click Raw, it will show up in CloudT as if you typed the letter 'A'
> since A is $41 = 65d.
>
> Raw-35-escape
> This is an encoding I saw in Ken's programs. Characters less then ASCII
> '#' are encoded as ASCII '#' followed by
>
> It's like Raw otherwise.
>
> So mov b,c will still type-in 'A'
>
> If you assemble NOP, that's instruction zero.
>
> So, as Raw-35-escape it will show up as
>
> ##
>
> Raw-35-escape code has to be minimally processed and copied somewhere
> else. Like ALTLCD. It is very compact. The code to poke it in somewhere
> else is not particularly complicated. But it probably deserves an XIP
> injector for speed :-)
>
> Hex
>
> Traditional numbers and A-F hex encoding. It's not particularly compact,
> it's not particularly tractable. Its main advantage is everyone will know
> what it is if they list your BASIC program.
>
> Funny Hex
> This is like hex but it uses 0-9 and puncuation : through ? instead of
> A-F. Slightly more tractable than regular hex, since you don't need to look
> up the nibble values, you can just subtract 48 from the ASCII
> representation to get the 0..15 value.
>
> Comma Decimal
> This is for encoding your program as comma-separated decimal, as in
>
> 10 DATA 110,120,1
>
> Advantages: the loader logic is simple and intuitive to write from
> scratch. It has no limitations as to what you can represent. BASIC is tuned
> to process it. The main disadvantage is it is bulky.
>
> Anyway, it's probably easier to understand by trying it than wading
> through my ponderous exposition.
>
> If you're still scratching your head as what this is for, fair enough.
>
> I read somewhere that Acorn BASIC has a built in assembler. Forths tend to
> as well though you can always "c," in a few bytes. Our BASIC doesn't. So if
> you want to do some immediate assembly programming and experimentation
> without cracking open a full assembler, this will assist you. A small step
> up from hand assembling using the 8085 reference.
>
> For bigger programs, use a regular file assembler. CloudT will probably
> never have that.. though it will probably get a disassembler/debugger
> support. Again, targeted at experimenting with small subroutines. So maybe
> it could disassemble the code embedded in a string on the screen. Or a
> series of data statements.
>
> Let me know if you have any problems. Also if you have another favorite
> encoding you've seen and would like included, let me know.
>
> -- John.
>