headers
rlevy | 7 Jan 2005 20:47
Favicon

blocks and corrupted floppies

I know that thinking critically about ColorForth and what improvements can be
made is probably on noone's mind, with the recent lawsuit Chuck is involved
in. i also noticed that not many ideas are being bounced back and forth
publically. but I was just concerned about the system because in my primary
getting-aquainted-with doings, and i've really just only started 2 days ago
(but i am absolutely hooked now), i've found myself continually "patching"
corrupted colorforth floppies, due to a byte getting written here or there
into the wrong spot. i know it may be my fault, for want of experience and
understanding all the ins and outs, but i was wondering if people continue to
have this problem even after lots of time and if it is why Chuck has
suggested the use of a "round-robin" system of floppies, a kind of analog
GoBack. it sounds like a sure bet to protect oneself against losing all their
work but i imagine that it could lead to confusion, say if you make the
mistake of writing to them out-of-order or simply forget to save a working
copy before continuing.

I thought that maybe the problem could be softened by changing (or
extending?) the system to only save changed blocks to disk. then if the core
software is disturbed while working, it won't be a problem next time you boot
up, saving the trouble of finding the newest working save or patching the
floppy from Windows. i think that first i need a word to save a random block
to disk (even past the original 162-block boundary) and then one in the root
block to save whatever i'm currently working on and only that. should save
some headaches. and time waiting for the disk. but it's not perfect. maybe
patching corrupted disks isn't the bother that could be made possible by
forgetting to update my custom save word. wow, these are real issues. one of
the things i love most about working in this new platform is i l so
RESPONSIBLE for myself. what a remarkable change from working in a sea of
rules and complexity that i was in before ...
(Continue reading)

Permalink | Reply | 2 comments |
headers
rlevy | 7 Jan 2005 21:24
Favicon

hello

My name's Roger, and I'm a 21 year old hobbyist programmer going to school in
Baltimore, MD. My current project is learning colorForth with the goal of
creating arcade games. 

( Hopefully most people read this one first ... :) Sorry, i noticed in my
last message that i didn't even introduce myself, and i thought well it was
my first message here so that was kind of gauche... )

-Roger
Permalink | Reply | 0 comments |
headers
Ray St. Marie | 8 Jan 2005 01:26
Picon

Re: blocks and corrupted floppies

Hello Roger, and the "LIST" :-)

On Fri, 7 Jan 2005 14:47:55 -0500, rlevy <rlevy <at> mica.edu> wrote:
> My name's Roger, and I'm a 21 year old hobbyist programmer going to school in
> Baltimore, MD. My current project is learning colorForth with the goal of
> creating arcade games.

Hi Roger, I'm Ray St. Marie, a 41 year old hobbiest programmer from
Forth Wort, Texas :-)
oops that's Fort Worth. That's a very worthy goal you have.

> ( Hopefully most people read this one first ... :) Sorry, i noticed in my
> last message that i didn't even introduce myself, and i thought well it was
> my first message here so that was kind of gauche... )

Not a problem. :-)  I'm very glad to make your aquaintence and glad to
learn of your interest.

> I know that thinking critically about ColorForth and what improvements can be
> made is probably on noone's mind, with the recent lawsuit Chuck is involved
> in. 

Well, i don't think this list is a true reflection of the interest
about the improvements
that can be made. 

> i also noticed that not many ideas are being bounced back and forth
> publically. 

They are, but in Internet Relay Chat. I'll say more about that below.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Walton | 8 Jan 2005 01:28
Picon

Re: blocks and corrupted floppies

On Fri, 7 Jan 2005 14:47:55 -0500, rlevy <rlevy <at> mica.edu> wrote:
> I know that thinking critically about ColorForth and what improvements can be
> made is probably on noone's mind, with the recent lawsuit Chuck is involved
> in. i also noticed that not many ideas are being bounced back and forth
> publically. but I was just concerned about the system because in my primary
> getting-aquainted-with doings, and i've really just only started 2 days ago
> (but i am absolutely hooked now), i've found myself continually "patching"
> corrupted colorforth floppies, due to a byte getting written here or there
> into the wrong spot. i know it may be my fault, for want of experience and
> understanding all the ins and outs, but i was wondering if people continue to
> have this problem even after lots of time and if it is why Chuck has
> suggested the use of a "round-robin" system of floppies, a kind of analog
> GoBack. it sounds like a sure bet to protect oneself against losing all their
> work but i imagine that it could lead to confusion, say if you make the
> mistake of writing to them out-of-order or simply forget to save a working
> copy before continuing.

I have a floppy labeled "Vanilla" which is the vanilla colorforth,
without any changes. When a floppy doesn't work, or just when I feel
like it, I boot from "Vanilla" and do "0 0 3 writes" to the broken
floppy.

> I thought that maybe the problem could be softened by changing (or
> extending?) the system to only save changed blocks to disk. then if the core
> software is disturbed while working, it won't be a problem next time you boot
> up, saving the trouble of finding the newest working save or patching the
> floppy from Windows. i think that first i need a word to save a random block
> to disk (even past the original 162-block boundary) and then one in the root
> block to save whatever i'm currently working on and only that. should save
> some headaches. and time waiting for the disk. but it's not perfect. maybe
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Kifiak | 8 Jan 2005 01:58

Re: To Jeff or Chuck : 2004 fireside chat?

> But for those of us who like to keep
> up with the latest in "frontier Forth" is 
> there anything that can be shared on this
> list from the 2004 fireside chat?

There is some text posted from the chat at:
http://www.ultratechnology.com/fsc04.htm

Not many colorforth details, but still an interesting
read.  Thanks Mr. Fox!
Permalink | Reply | 0 comments |
headers
howerd.oakford | 8 Jan 2005 19:29

RE: blocks and corrupted floppies.

Hi Roger,

> i've found myself continually "patching"
> corrupted colorforth floppies, due to a byte getting written here or there
> into the wrong spot.
You are not the only one!
If you have a "then" without an "if" the value on the top of the stack is
used as the place to write the forward jump. This is probably 0, so it
corrupts the binary image. I'm sure there are other causes too...

I have defined "ss" and "uu" ( as they are easy to type ) to Save and Undo
the sector containing the currently edited block.
From cfdos3.blk block 24 ( http://www.inventio.co.uk/cfdos.htm ) :
: blk ( -a ) 0xA86 ;
: ll blk  <at>  load ;
: sect blk  <at>  18 / dup 18 * block swap ;
: ss sect 1 writes /flop ;
: uu sect 1 reads /flop ;

"ll" loads the currently edited block.
Just type "ss" when you want to save your work. Bear in mind that the entire
18 block sector containing the changed block is written by "ss" ! "uu" is
useful to restore the last saved version.

I have renamed several of the colorForth primitives - you may need to modify
the names in the code above.
Also, you will need to check that the address of blk is correct for your
system.  :

Name changes to several system words to avoid clashes with ANS standard
(Continue reading)

Permalink | Reply | 4 comments |
headers
Albert van der Horst | 10 Jan 2005 00:58
Picon
Picon

Back and forth to machine code in blocks.

Hoy all,
In behalf of retroforth I have made a tool (parse/unparse)
that converts machine code in blocks (actually linux files)
into assembler code and back.

A similar tool could be had for colorforth, if there is interest.
An other option is to port the miniassembler to colorforth.
(it is 6 screens for a 386 assembler without the sib stuff,
7 screens with sib.) Then the machine code could be replaced
in  the colorforth screens by assembler code.

I think it will not be necessary to have the assembler permanently 
loaded. It could be used at startup to copy screens with 
assembler code to screens with machine code. So actual usage 
would be the same as in the current situation. This is assuming
sufficient screens are present. With the switch from floppies to
USB sticks that should not be a problem.

Example: screen 0 of retroforth
---------------------------------------------

forth : swap [ $0687 2, ] ;
: drop [ $ad 1, ] ;
: dup [ $fc4689 3, $fc768d 3, ] ;
: nip swap drop ;
: and [ $0623 2, ] nip ;
: or [ $060b 2, ] nip ;
: xor [ $0633 2, ] nip ;
: >> [ $c189 2, $ad 1, $e8d3 2, ] ;
: not -1 xor ;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ray St. Marie | 11 Jan 2005 04:19
Picon

Re: Back and forth to machine code in blocks.

Wow!! Albert.

On Mon, 10 Jan 2005 00:58:36 +0100, Albert van der Horst
<albert <at> spenarnc.xs4all.nl> wrote:
> Hoy all,
> In behalf of retroforth I have made a tool (parse/unparse)
> that converts machine code in blocks (actually linux files)
> into assembler code and back.
> 
> A similar tool could be had for colorforth, if there is interest.

You bet there's interest :-) 

> An other option is to port the miniassembler to colorforth.
> (it is 6 screens for a 386 assembler without the sib stuff,
> 7 screens with sib.) Then the machine code could be replaced
> in  the colorforth screens by assembler code.

This miniassembler, there is an example at your site?

> 
> I think it will not be necessary to have the assembler permanently
> loaded. It could be used at startup to copy screens with
> assembler code to screens with machine code. 

I'm slow, so save me if I have this wrong. As I'm reading this i'm thinking ...
The front 18 assembler blocks of the colorforth could be converted from
colorforth to assembler with this? 

> So actual usage
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ray St. Marie | 11 Jan 2005 04:21
Picon

Re: Back and forth to machine code in blocks.

> 
> I'm slow, so save me if I have this wrong. As I'm reading this i'm thinking ...
> The front 18 assembler blocks of the colorforth could be converted from
> colorforth to assembler with this?
Sorry, got that backwards -- ment to say....
The front 18 assembler blocks of the colorforth could be converted from 
assembler to colorforth with this?

My applologies .
Ray St. Marie
--
Rastm2 At users dot sourceforge dot net
Ray.StMarie AT gmail DOT com
Ray.StMarie AT sbcglobal DOT com
Raystm2 in  irc.freenode.net /join #c4th #c4th-ot #forth #retro
Permalink | Reply | 1 comment |
headers
Albert van der Horst | 11 Jan 2005 21:08
Picon
Picon

Re: Back and forth to machine code in blocks.

On Mon, Jan 10, 2005 at 09:21:48PM -0600, Ray St. Marie wrote:
> > 
> > I'm slow, so save me if I have this wrong. As I'm reading this i'm thinking ...
> > The front 18 assembler blocks of the colorforth could be converted from
> > colorforth to assembler with this?
> Sorry, got that backwards -- ment to say....
> The front 18 assembler blocks of the colorforth could be converted from 
> assembler to colorforth with this?

You can go back and forth, such as I said.

So a practical way in colorforth would be to have
1. the assembler far away  (block 200)
2. a copy of the first 18 blocks in block 18...35 but with assembler
code instead of machine code.
There may be a problem there, my assembler assumes ASCII, but a color
forth assembler would maybe not.

The procedure for a change would be :
1. edit in block 18 ..35 
2. load the assembler and convert the block edited,
put the result in the corresponding block 18 lower.
3. Use block 0 ..18 as before.

So the difference would be that one never edits the machine
code.

The assembler is started by the word { and stops by }.

The disassembler is combined with a clever miniparser that
(Continue reading)

Permalink | Reply | 0 comments |

Gmane