colorforth boots from and saves to USB partition, finally

[jc]

One of the last things hanging me up was some unknown flakiness
apparently caused by my use of video RAM (0xb8000) for the stack
during boot; at some point in the process it just stopped loading and
started marching characters across the screen in text mode. Quite
colorful sometimes but very useless. Anyway, I put the boot stack at
0x7a00 instead and rebooted several times with no such problem. Not
saying it won't happen again though.

Some improvements over GreenArrays's last PD release, on which this
was based, are:

* Automatically detects one of 3 graphics modes: 0x4118, 0x4123, or
0x4144 (the last being for Qemu or Bochs)
* If it fails to boot, there is at least a chance of determining where
it failed, as a nearly-full register dump appears at the top of the
screen as the boot code executes.
* Can theoretically be used from any device the BIOS recognizes,
including a hard drive partition. However, I recommend only using it
from a smallish USB drive, either loaded to the MBR or to the first
partition. Instructions are in the README. It drops back into real
mode for 'read' and 'write' to use the BIOS.

I'm hoping this helps spread the use of native colorforth among the
hacker community by removing the requirement for ancient computer
hardware. I am willing to install to USB keys for a few people who
will pay postage both ways, just email me. Or roll your own by
visiting http://unternet.net/src/clusterFix/. Most of the changes are
in newboot.nasm. I'm hoping GreenArrays will incorporate some or all
of the improvements into the official arrayforth, if testing proves no
major bugs that erase your hard drive, fry your pet hamster, or propel
you through a wormhole into another corner of the multiverse without
giving you the chance to grab a towel first.

Howerd: I put the nsec count back at byte offset 4 of block 0 again,
just to avoid the problem mentioned earlier. Even though I could edit
the high-level Forth to use my new 'nsec' kernel variable, apparently
the Windows loader depends on its block 0 location as well.

Someday I may upload this to the SourceForge colorforth page, but at
this point I've spent way too much time on this project and I'm going
to take a break.

[Rod Pemberton]

"jc" <john....@gmail.com> wrote in message
news:cbbf1a88-704d-49e1...@v24g2000prn.googlegroups.com...

> One of the last things hanging me up was some unknown flakiness
> apparently caused by my use of video RAM (0xb8000) for the stack
> during boot; at some point in the process it just stopped loading and
> started marching characters across the screen in text mode. Quite
> colorful sometimes but very useless. Anyway, I put the boot stack at
> 0x7a00 instead and rebooted several times with no such problem. Not
> saying it won't happen again though.
>

IIRC, not all x86 PCs had video ram at 0xb8000, e.g., hercules cards.
Second, even PCs without 640kB had 512kB. So, a lower memory region is a
better choice, at least for really old machines.

> * Automatically detects one of 3 graphics modes: 0x4118, 0x4123,
> or 0x4144 (the last being for Qemu or Bochs)

I don't recognize those numbers. Are they for BIOS Int 10h? Are those text
or video?

Apparently, they are VESA video modes. I'm not sure what resolution a
couple of them are. But, they seem to be higher resolution graphics modes.

I don't understand. I thought colorforth used colored TEXT.

You do know some machines, especially older ones, won't support VESA and/or
newer VESA modes. I.e., you may need VGA or TEXT modes, yes?

> * Can theoretically be used from any device the BIOS recognizes,
> including a hard drive partition.

That's good.

> I'm hoping this helps spread the use of native colorforth among the
> hacker community by removing the requirement for ancient computer
> hardware.

Delusional ... ?

> I am willing to install to USB keys for a few people who
> will pay postage both ways, just email me.

Ok, that's not happening ...

Do you really expect Forth people - none of whom have likely ever paid for a
commercial Forth - to cough up money for postage? Seriously ...

> Or roll your own by visiting [link]

I'm rollin' my own.


Rod Pemberton

[jc]

On Dec 23, 3:01 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> "jc" <john.com...@gmail.com> wrote in message

> IIRC, not all x86 PCs had video ram at 0xb8000, e.g., hercules cards.
> Second, even PCs without 640kB had 512kB.  So, a lower memory region is a
> better choice, at least for really old machines.

This whole effort was aimed at making colorforth available to those
with more modern hardware.

> > * Automatically detects one of 3 graphics modes: 0x4118, 0x4123,
> > or 0x4144 (the last being for Qemu or Bochs)

> Apparently, they are VESA video modes.  I'm not sure what resolution a
> couple of them are.  But, they seem to be higher resolution graphics modes.
>
> I don't understand.  I thought colorforth used colored TEXT.

It does, but the text is rendered by a custom bitmap font on a
1024x768 graphics video mode.

> You do know some machines, especially older ones, won't support VESA and/or
> newer VESA modes.  I.e., you may need VGA or TEXT modes, yes?

I'd like to experiement with a text-mode colorforth eventually; you'll
see it's in my to-do list. But again, my goal was using the existing
colorforth with modern hardware.

> > I'm hoping this helps spread the use of native colorforth among the
> > hacker community by removing the requirement for ancient computer
> > hardware.
>
> Delusional ... ?

Possibly, but why do you think so?

> > I am willing to install to USB keys for a few people who
> > will pay postage both ways, just email me.
>

> Do you really expect Forth people - none of whom have likely ever paid for a
> commercial Forth - to cough up money for postage?  Seriously ...

No, in fact I'm hoping to not get any requests for this. But the offer
stands, for now.

> > Or roll your own by visiting [link]
>
> I'm rollin' my own.

Good!

[Paul Rubin]

jc <john....@gmail.com> writes:
> * Can theoretically be used from any device the BIOS recognizes,
> including a hard drive partition. However, I recommend only using it
> from a smallish USB drive, either loaded to the MBR or to the first
> partition. Instructions are in the README. It drops back into real
> mode for 'read' and 'write' to use the BIOS.

Maybe running it in a KVM or similar container could be even
more convenient. No need to boot a real machine.

> I'm hoping this helps spread the use of native colorforth among the
> hacker community

Out of curiosity, what is the motivation for running native colorforth
on a PC in the first place, other than cross-development? I thought the
idea of colorforth was to be a machine language for MISC chips. These
days, that means the GA144, so you probably want to emulate the whole
parallel computing setup.

[jc]

On Dec 23, 5:10 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> Out of curiosity, what is the motivation for running native colorforth
> on a PC in the first place, other than cross-development?  I thought the
> idea of colorforth was to be a machine language for MISC chips.  These
> days, that means the GA144, so you probably want to emulate the whole
> parallel computing setup.

That's Chuck Moore's idea of colorforth. I like the idea of using it,
or something like it, on x86 hardware, and maybe port it to ARM as
well.

And Chuck's development team uses it on PCs don't they? I'm assuming
mostly under Windows or Linux, but I'm guessing the ability to use a
zipdrive rather than floppy would lower the bar for "going native".

[Albert van der Horst]

In article <jd3154$6fi$1...@speranza.aioe.org>,

Rod Pemberton <do_no...@noavailemail.cmm> wrote:
>"jc" <john....@gmail.com> wrote in message
>news:cbbf1a88-704d-49e1...@v24g2000prn.googlegroups.com...
>> One of the last things hanging me up was some unknown flakiness
>> apparently caused by my use of video RAM (0xb8000) for the stack
>> during boot; at some point in the process it just stopped loading and
>> started marching characters across the screen in text mode. Quite
>> colorful sometimes but very useless. Anyway, I put the boot stack at
>> 0x7a00 instead and rebooted several times with no such problem. Not
>> saying it won't happen again though.
>>
>
>IIRC, not all x86 PCs had video ram at 0xb8000, e.g., hercules cards.
>Second, even PCs without 640kB had 512kB. So, a lower memory region is a
>better choice, at least for really old machines.
>
>> * Automatically detects one of 3 graphics modes: 0x4118, 0x4123,
>> or 0x4144 (the last being for Qemu or Bochs)
>
>I don't recognize those numbers. Are they for BIOS Int 10h? Are those text
>or video?
>
>Apparently, they are VESA video modes. I'm not sure what resolution a
>couple of them are. But, they seem to be higher resolution graphics modes.
>
>I don't understand. I thought colorforth used colored TEXT.

No! If you look at my decompilation (ftp at my site below), you will
see that the character design is part of colour forth.
The decompilation is such that you can redesign the font,
if you wanted so.

Using colored text might make the life easier if you're interested
in just colorforth, but remember the purpose is to design chips,
and graphics is crucial for the green arrays chip simulator.

<SNIP>

>
>
>Rod Pemberton

Groetjes ALbert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Howerd]

Hi jc,

I've just been away without internet or computer for the festive
season - hence the late reply...

> Howerd: I put the nsec count back at byte offset 4 of block 0 again,
> just to avoid the problem mentioned earlier. Even though I could edit
> the high-level Forth to use my new 'nsec' kernel variable, apparently
> the Windows loader depends on its block 0 location as well.

I think that block 0 is "sector 0" which normally contains boot code.
The first three or four bytes are a jump that skips over some ID
bytes, and I assume that some of these ID bytes are being used by
ArrayForth to store the number of sectors to load.
Could you make the first instruction a jump to say, location 0x20 ?

I would like to "roll my own" using Windows, but USB access only seems
to be possible by reverse engineering.
If anyone can point me in the right direction it would be much
appreciated...

When I have recovered more from too much feasting I will take a look
at these BIOS calls, and try to get cf201x to work from a USB disk.

Thanks again for all of your efforts,

Happy New Year to one and all,

Howerd

On Dec 23, 2:29 am, jc <john.com...@gmail.com> wrote:
> One of the last things hanging me up was some unknown flakiness
> apparently caused by my use of video RAM (0xb8000) for the stack
> during boot; at some point in the process it just stopped loading and
> started marching characters across the screen in text mode. Quite
> colorful sometimes but very useless. Anyway, I put the boot stack at
> 0x7a00 instead and rebooted several times with no such problem. Not
> saying it won't happen again though.
>
> Some improvements over GreenArrays's last PD release, on which this
> was based, are:
>
> * Automatically detects one of 3 graphics modes: 0x4118, 0x4123, or
> 0x4144 (the last being for Qemu or Bochs)
> * If it fails to boot, there is at least a chance of determining where
> it failed, as a nearly-full register dump appears at the top of the
> screen as the boot code executes.
> * Can theoretically be used from any device the BIOS recognizes,
> including a hard drive partition. However, I recommend only using it
> from a smallish USB drive, either loaded to the MBR or to the first
> partition. Instructions are in the README. It drops back into real
> mode for 'read' and 'write' to use the BIOS.
>
> I'm hoping this helps spread the use of native colorforth among the
> hacker community by removing the requirement for ancient computer
> hardware. I am willing to install to USB keys for a few people who
> will pay postage both ways, just email me. Or roll your own by

> visitinghttp://unternet.net/src/clusterFix/. Most of the changes are

[Rod Pemberton]

"jc" <john....@gmail.com> wrote in message

news:b6c75ab3-26cc-4591...@h37g2000pri.googlegroups.com...

> On Dec 23, 3:01 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>
> > > I'm hoping this helps spread the use of native colorforth among
> > > the hacker community by removing the requirement for ancient
> > > computer hardware.
>
> > Delusional ... ?
>
> Possibly, but why do you think so?
>

In 3 decades of computing, I've seen colored text used in many places, e.g.,
applications, color code, as graphics, etc. Except for text as graphics,
use of colored text was always where monochrome or two-color would've
sufficed. I've only only seen one use of colored text that was novel enough
that I like it. It's for coloring directory listings in Linux. I like that
mostly due to an overload of information that Posix directory listing
provides. The entire computing industry has moved from text user interfaces
(TUI) such as the command line to graphical user interfaces (GUI) such as
windows. So, why would use of colored text become common or used now? ...
to color Forth code?

Also - slightly unrelated to the "delusional" issue - all modern x86
computer hardware still supports those "ancient" features, including video
text modes. Is it ancient if it's still in use? So, I don't understand why
you chose to support modern features, or use graphics to do text ...


Rod Pemberton

[John Passaniti]

On Dec 27, 12:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> So, why would use of colored text become common or used now? ...
> to color Forth code?

As has been discussed in the past, the use of color in ColorForth is
not just to make it look pretty. The tokens that inject color are
actually part of the syntax, replacing some of the textual syntax of
Forth. The most obvious examples are that definitions are in red,
yellow words are executed, green words are compiled, white words are
comments, etc. So this isn't syntax color highlighting, the color
*is* syntax. Specifically, each word in ColorForth is attributed with
a set of bits that define how the system interprets it, and these bits
are also mapped to colors.

[jc]

On Dec 27, 8:45 am, Howerd <howe...@yahoo.co.uk> wrote:
> I think that block 0 is "sector 0" which normally contains boot code.
> The first three or four bytes are a jump that skips over some ID
> bytes, and I assume that some of these ID bytes are being used by
> ArrayForth to store the number of sectors to load.
> Could you make the first instruction a jump to say, location 0x20 ?

I made it jump to location 0x8 in this latest revision. I *believe*
all the other bootblock variables are now mapped to kernel-defined
headers, and have no need to be accessed using "0 block n + @"

> I would like to "roll my own" using Windows, but USB access only seems
> to be possible by reverse engineering.
> If anyone can point me in the right direction it would be much
> appreciated...
> When I have recovered more from too much feasting I will take a look
> at these BIOS calls, and try to get cf201x to work from a USB disk.
>

For my part I will try going the other direction, i.e., getting all
the snazzy apps in cf2010 working under clusterFix.

[jc]

On Dec 27, 9:26 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> Also - slightly unrelated to the "delusional" issue - all modern x86
> computer hardware still supports those "ancient" features, including video
> text modes.  Is it ancient if it's still in use?  So, I don't understand why
> you chose to support modern features, or use graphics to do text ...

Those questions rightly belong to Chuck Moore, not to me. My main
contribution so far was to eliminate the requirement for a floppy
drive to run colorforth natively.

[Howerd]

Hi jc,

I've tried to build your colorForth system under Cygwin - but there
doesn't seem to be a make utility provided out of the box.
What flavour of *nix do you use, and what version of make and NASM ?

Or... would it be possible for you to zip up a complete system and
upload it somewhere (or email it to me)?
Sorry that I am not very Linux literate... yet...

Maybe we will meet in the middle with a merge of the two systems...

Best regards,
Howerd

[Brad]

On Dec 22, 7:29 pm, jc <john.com...@gmail.com> wrote:
> I'm hoping this helps spread the use of native colorforth among the
> hacker community by removing the requirement for ancient computer
> hardware.

It's a step in the right direction, but I wonder if colorforth was
built too close to the metal. It would be a nice fit for Android, with
its small screen and limited number of virtual keys. Speaking of
which, if you can't touch-type colorforth it's no big deal since the
shifted character display would be under your fingertips. Some kind of
gesture-based chording could be used to ease typing even more.

-Brad

[jc]

On Dec 27, 1:50 pm, Howerd <howe...@yahoo.co.uk> wrote:
> I've tried to build your colorForth system under Cygwin - but there
> doesn't seem to be a  make  utility provided out of the box.
> What flavour of *nix do you use, and what version of  make  and NASM ?

http://www.linuxfromscratch.org/blfs/view/5.1/general/NASM.html for
nasm; later revisions were giving me problems I don't remember at the
moment.

GNU Make 3.81 is my "make" version. I'm using Debian GNU/Linux,
currently at lenny/sid.

> Or... would it be possible for you to zip up a complete system and
> upload it somewhere (or email it to me)?

No, not really feasible. Especially since you're running under
Cygwin, for which the binaries would be totally incompatible. Even if
you switched to coLinux it wouldn't be something I'd want to attempt.

[jc]

Figured out something that had me stumped: how to remove the LZ77
compression from arrayforth in order to get a more hackable image to
play with. Here are the steps:

2880 0 block 1 + ! ( sets sector count to entire floppy)
2880 ns ! ( same here as well)
80 nc ! ( cylinder count to 80, entire floppy)
0 block 0 80 writes ( write out uncompressed image to disk)

Also redefining "save" to that last line, 0 block 0 80 writes, might
be a good idea if you don't want to inadvertently overrwrite your disk
or USB key with a compressed image.

This didn't work for me under Wine, I had to do it by booting the USB
key made with newboot.cf. And with that, one can use the kernel-
defined variable nsec instead of "0 block 1 +", as documented here:
http://unternet.net/src/clusterFix/#uncompress

[jc]

Howerd, I've made some progress, getting your Conway's Life program
working on clusterFix, except that the 'g' key doesn't actually get
the game automatically playing; repeatedly hitting 'g' or space is
necessary. The only thing I had to change was to make all the variable
references yellow. Apparently arrayforth (or colorforth 2?) is much
pickier about that than cf2005.

The only other change I know for sure you need to make to get cf2010
working with the clusterfix kernel is to redefine block to:

: block [ offset ] @ +
: blks $100 * ;

(the fallthrough is of course necessary).

Here is the Life that is almost working:

{block 960}
( app conway's game of life) empt 962 load
: cell 32 /mod adj adj over over at 16 u+ 16 + box ;
: nocell drop ;
: draw dup old @ 1 and jump nocell cell
: cells [ 1023 ] for i draw -next ;
: gen [ 1023 ] for i tick swap new ! -next [ 1023 ] for i new @ i
old ! -next ;
: loc [ row ] @ 32 * [ col ] @ + ;
: cur loc dup old @ $ff * $ff0000 + color cell ;
: back black screen $303010 color 40 40 at 583 dup box ;
: g show back green cells gen keyboard ;
: s gen show back blue cells cur keyboard ;
: clear 1500 8 erase 16 [ row ] ! 16 [ col ] ! s ;
: t loc old dup @ 1 or ( xor) swap ! ;
: l $7ffffff [ col ] +! [ col ] @ 31 and [ col ] ! ;
: u $7ffffff [ row ] +! [ row ] @ 31 and [ row ] ! ;
: d 1 [ row ] +! [ row ] @ 31 and [ row ] ! ;
: r 1 [ col ] +! [ col ] @ 31 and [ col ] ! ;
: h pad nul nul accept nul nul nul nul nul l u d r nul nul nul nul
glide glid2 glid3 glid4 clear s g t nul nul nul nul [ $2500 , 0 ,
$110160c , 0 , $1c1b1a19 , $20d0815 , 0 , clear glide g h ]

{block 961}

: s ( stop)
: g ( go)
: t ( toggle the square)
: ludr ( left up down right)
: . ( press s to stop then draw a shape using ludr and t to toggle)
: . ( then press g to go or s to single step)
: 1234 ( create gliders which move to the four corners counting
clockwise from the top left)

{block 962}
( conway's game of life) var row [0x10] var col [0x10]
: old [ 1500 block ] + ;
: new [ 1504 block ] + ;
: nul ;
: pos swap 32 /mod swap ;
: val 32 * + swap over old @ 1 and + ;
: up pos swap 31 + 31 and val ;
: dn pos swap 1 + 31 and val ;
: lt pos 31 + 31 and swap val ;
: rt pos 1 + 31 and swap val ;
: n [ 0 ] ;
: s dup old @ 1 and ;
: y [ 1 ] ;
: tick dup 0 up lt dn dn rt rt up up nip jump n n s y n n n n n
: adj swap 17 * 40 + ;
: st ( rc-) [ col ] @ + swap [ row ] @ + 32 * + old 1 swap ! ;
: glide 0 2 st 0 1 st 0 0 st 1 0 st 2 1 st ;
: glid2 0 0 st 0 1 st 0 2 st 1 2 st 2 1 st ;
: glid3 0 2 st 1 2 st 2 2 st 2 1 st 1 0 st ;
: glid4 0 0 st 1 0 st 2 0 st 2 1 st 1 2 st ;

[Howerd]

Hi jc,


Great!
Is this all available for download from your site now?

I should say that it not's _my_ Life program - I just collected it and
gave it a home ;-)

I hope to get some time to look at this over the weekend...

Best regards,
Howerd

[jc]

On Jan 5, 11:50 am, Howerd <howe...@yahoo.co.uk> wrote:
> Is this all available for download from your site now?

It is, but if you wait a few more hours there may be some
improvements.

> I should say that it not's _my_ Life program - I just collected it and
> gave it a home ;-)

OK, wasn't sure.

[jc]

On Jan 5, 8:22 pm, jc <john.com...@gmail.com> wrote:
> On Jan 5, 11:50 am, Howerd <howe...@yahoo.co.uk> wrote:
>
> > Is this all available for download from your site now?
>
> It is, but if you wait a few more hours there may be some
> improvements.

I believe I'm done with it for the next week or so, as I'll be
offline. There's a zipfile, clusterFix.zip under http://unternet.net/src/clusterFix/.
More details in the other thread re: colorforth to forth translator.

[Howerd]

Hi jc,

I finally managed to get your uncompressedcf.blk file ontl a USB Flash
drive, and it boots.
But, alas, I cannot save edits to the USB drive using the cf command
"save".

Does "save" work on your system?
I have tried it on both my PC (Lenovo 64 bit) and netbook MSI (Wind) -
both boot but do not save...

Best regards,
Howerd

On Jan 6, 8:56 am, jc <john.com...@gmail.com> wrote:
> On Jan 5, 8:22 pm, jc <john.com...@gmail.com> wrote:
>
> > On Jan 5, 11:50 am, Howerd <howe...@yahoo.co.uk> wrote:
>
> > > Is this all available for download from your site now?
>
> > It is, but if you wait a few more hours there may be some
> > improvements.
>
> I believe I'm done with it for the next week or so, as I'll be

> offline. There's a zipfile, clusterFix.zip underhttp://unternet.net/src/clusterFix/.

[jc]

On Jan 14, 9:07 am, Howerd <howe...@yahoo.co.uk> wrote:
> I finally managed to get your uncompressedcf.blk file ontl a USB Flash
> drive, and it boots.
> But, alas, I cannot save edits to the USB drive using the cf command
> "save".

If you're using uncompressed.cf, you should save using '0 !work'
instead of 'save'. I've tried changing the definition of 'save' but
somehow it interferes with the ability of Windows to boot the binary,
so I haven't committed the change yet.

If, on the other hand, you use newboot.cf, which is a LZ77-compressed
image, you should be able to use 'save'.

Keep checking http://unternet.net/src/clusterFix/README.html for the
latest updates, OK? Thanks for testing! -- jc

[Howerd]

Hi jc,

I've just taken a look at the files in clusterFix.zip (downloaded
today 2012Jan15) - you certainly have done a lot of work on this :-)

I am still having problems reading and writing from/to the USB drive.
When I type :

1000 edit <space>
1000 block 1 read

I only see 'dr' appear on the screen, not block 18.
The same 'dr' also appears on the next 17 blocks.

This is on real hardware BTW.
I am expecting to see the contents of sector 1 (blocks 18 to 35)
copied to the RAM for blocks 1000 to 1017.

Similarly 0 !work does not work.

Am I doing something wrong here? You mentioned some confusion over the
parameters to read ...
Clearly the read primitive word works, or the system would not
boot.
Does something change after booting, so that read no longer works?

Best regards,
Howerd

> Keep checkinghttp://unternet.net/src/clusterFix/README.htmlfor the

[jc]

On Jan 15, 9:31 am, Howerd <howe...@yahoo.co.uk> wrote:
> I am still having problems reading and writing from/to the USB drive.
> When I type :
>
> 1000 edit <space>
> 1000 block 1 read

I repeated this experiment, and got the expected results: "1000 block
1 read" showed block 18 loaded onto block 1000. Then I positioned the
cursor at the white word "colorforth" and deleted it. Then saved using
"0 !work", and rebooted: "boot". On reboot, "1000 list" showed the
modified copy of block 18 just as I'd saved it, with the word
"colorforth" missing.

> I only see 'dr' appear on the screen, not block 18.
> The same 'dr' also appears on the next 17 blocks.

Very strange. So "read" must be doing *something* on your system, i.e.
loading 18 blocks into the address range you gave it. It's just
pulling the data out of its arsch instead of the USB key :^\

> This is on real hardware BTW.
> I am expecting to see the contents of sector 1 (blocks 18 to 35)
> copied to the RAM for blocks 1000 to 1017.
>
> Similarly  0 !work  does not work.

Both should work. I had first booted uncompressed.cf off partition 1
of my USB key, so I rebooted back into Debian and loaded
uncompressed.cf directly onto the root of the key, /dev/sdb, and tried
again. Exactly the same results.

> Am I doing something wrong here? You mentioned some confusion over the
> parameters to  read ...
> Clearly the  read  primitive word works, or the system would not
> boot.
> Does something change after booting, so that  read  no longer works?

I resolved the confusion by looking at the disassembly and also what
actually happens when the commands are used, and no, you're not doing
anything wrong. My system just isn't working for you. And it's a real
disappointment, because I really thought I was onto something. I
realized from a link gavino posted that Chuck Moore will probably not
want to use my solution because he doesn't like using the BIOS. So I
hoped it would be at least useful for the hobbyist community, but
apparently it isn't yet.

I'll see if I can figure out where that "dr" is coming from. Is there
an LED or other indication on your USB drive that shows disk activity?
If it's not showing activity when "read" is being performed, then the
obvious answer would be that the BIOS is loading data off the wrong
disk. Which could be disastrous if "0 !work" does the same thing, as
it will overwrite 1.44MB of whatever disk it is using.

[Howerd]

Hi jc,

My Flash drive does not have an LED, but the fact that on my netbook
Windows requests a repair when I try to reboot it , seems to indicate
that the blocks _are_ being written to the hard drive...
> ... Chuck Moore will probably not want to use my solution because he doesn't like using the BIOS.
This is speculation - I suspect that Chuck will happily use whatever
works...
But Chuck/GreenArrays should not use any code that could potentially
wipe the hard disk's boot sector ;-) Lets get this fixed ASAP :-)

> I'll see if I can figure out where that "dr" is coming from.

The "dr" is just the colorForth representation of the values in the
block. All 18 blocks are the same, at least in the first cell.
I can dump the actual hex data if it would help.

The only other difference between our systems is that I am using
Windows and a swiftForth program to load the colorForth system onto
the USB drive.
Could it be the formatting of the USB drive? Is there a level lower
than sector 0 and the MBR? Or higher, that the BIOS boot code uses?

Best regards,
Howerd

[jc]

On Jan 16, 12:51 am, Howerd <howe...@yahoo.co.uk> wrote:
> My Flash drive does not have an LED, but the fact that on my netbook
> Windows requests a repair when I try to reboot it , seems to indicate
> that the blocks _are_ being written to the hard drive...> ... Chuck Moore will probably not want to use my solution because he doesn't like using the BIOS.
>
> This is speculation - I suspect that Chuck will happily use whatever
> works...
> But Chuck/GreenArrays should not use any code that could potentially
> wipe the hard disk's boot sector ;-) Lets get this fixed ASAP :-)

Wow, it's amazing Windows was able to boot at all, if the MBR and
first 1.44MB of the disk was overwritten. I can't picture how it is
even possible.

> > I'll see if I can figure out where that "dr" is coming from.
>
> The "dr" is just the colorForth representation of the values in the
> block. All 18 blocks are the same, at least in the first cell.
> I can dump the actual hex data if it would help.

The hex data could help if you can compare it to the hex data on your
own (repaired) hard drive, and see if it's the same.

> The only other difference between our systems is that I am using
> Windows and a swiftForth program to load the colorForth system onto
> the USB drive.
> Could it be the formatting of the USB drive? Is there a level lower
> than sector 0 and the MBR? Or higher, that the BIOS boot code uses?

No, absolute sector 0 is the MBR, and there is nothing lower. The BIOS
provides the drive number in DL when it passes control to the
bootloader at 0x7c00, and I store that value at 0x7c38. It should be
either 0 or 0x80 (after using F1 to switch to hex display) in the low
byte, depending on whether your BIOS assigned the USB key as the first
floppy (0x00) or the first hard drive (0x80). I believe "vesa 2- + @
0ff and" should be the right magic incantation to see it. I can't
check just now.

If you aren't successful with "read" for sure don't use "write" or "!
work" or "save". I should have said that from the start. Glad you were
able to recover.

[jc]

On Jan 16, 4:16 pm, jc <john.com...@gmail.com> wrote:
> floppy (0x00) or the first hard drive (0x80). I believe "vesa 2- + @
> 0ff and" should be the right magic incantation to see it. I can't
> check just now.

I checked, "and" cannot be used interactively, so you'll have to do it
in your head. Mine, on entry of "vesa 2- + @" shows (in hex mode)
10180: head 1 (zero-based), sector 1 (1-based), 0x80=first hard drive.
That's because I have it (uncompressed.cf) back on the first
partition, otherwise it would be simply 180.

You can also view the contents of DL during the bootup process, which
on my computer takes several seconds when using uncompressed.cf rather
than newboot.cf. DX is constantly changing in DH, but DL shows the
boot disk until loading is complete.

If what you see after boot, using "vesa 2- + @", is different from the
DL during bootup, something is wrong with my code. If, however, the
value remains the same, your BIOS is doing something funky, changing
what it decided the drive numbers represented after handing control to
my bootcode. Or perhaps something is overwriting the BIOS data area of
RAM (between 0x400 to 0x600 IIRC)? I don't believe so but anything is
possible.

[jc]

On Jan 16, 5:55 pm, jc <john.com...@gmail.com> wrote:
> On Jan 16, 4:16 pm, jc <john.com...@gmail.com> wrote:
>
> I checked, "and" cannot be used interactively, so you'll have to do it
> in your head. Mine, on entry of "vesa 2- + @" shows (in hex mode)
> 10180: head 1 (zero-based), sector 1 (1-based), 0x80=first hard drive.
> That's because I have it (uncompressed.cf) back on the first
> partition, otherwise it would be simply 180.
>

Actually that "180" guess was wrong. Not only did I confuse the sector
number with the head number, but when I load the code directly onto
the MBR, the BIOS treats my USB key as a floppy and assigns it a
number of 0x00 accordingly. And due to the way my bootcode works I
don't one-base the sector number when it's a floppy, so "vesa 2- + @"
shows 0 in this case, and probably should on your system also. If it
sees a hard drive, it *ought* to be 10080. Maybe.

I don't actually know how the BIOS keeps its decision on what 0x00,
0x01, 0x80, and 0x81 map to in the hardware. I glanced over some BIOS
data area docs online yesterday and didn't see anything pertinent.
It's possible that the PCI bus scan, which I didn't cut out of the
existing GreenArrays code although I prevented it from overwriting the
VESA framebuffer, is messing with that decision, particularly if your
BIOS decides the USB key is a hard drive and not a floppy.

[Howerd]

Hi jc,

Both the PC and netbook show DL = 0x80 => hard drive.
Maybe DL is getting reset to 0, and I am reading data from a non-
existent floppy...

I checked the Hex data - the first 3 blocks are the same in the first
16 bytes, so its not random, and the actually data has changed
slightly since I last looked :
000700BB 00400040 0000A000 00005296
...in case this means anything to anyone...

I will take a look tonight at DL after booting...

Best regards,
Howerd

[Rod Pemberton]

"jc" <john....@gmail.com> wrote in message

news:d805763a-01d5-48bd...@c1g2000pbf.googlegroups.com...
...

> If it sees a hard drive, it *ought* to be 10080. Maybe.
>

Your description of what DL is supposed to do is correct. You might post to
alt.os.development, or search archives of it, to confirm how well BIOSes
support it.

> I don't actually know how the BIOS keeps its decision on what 0x00,
> 0x01, 0x80, and 0x81 map to in the hardware.

1) news://alt.os.development
2) http://wiki.osdev.org/
3) http://board.flatassembler.net/

The issue of what's in DL comes up occassionally on alt.os.development.

You might also check RBIL (Ralf Brown's Interrupt List). It's in there.
I've seen it.

Mike Gonta posts to the Fasm forums. He made some images that are
supposedly bootable from a variety of devices. He tells us about them every
now and then on alt.os.development. E.g., some of his "OS Construction"
topics on the Fasm forums:

USB booting secrets
http://board.flatassembler.net/topic.php?t=12389

More USB booting secrets
http://board.flatassembler.net/topic.php?t=12469

Universal Single Method USB Flash Drive Boot and Run
http://board.flatassembler.net/topic.php?t=12488

Real Mode FAT32 USB Boot Loader
http://board.flatassembler.net/topic.php?p=127245

> ... BIOS decides the USB key is a hard drive and not a floppy.
>

That should require a HD image, i.e., the image has a partition table.
Depending on the BIOS (I'm guessing ...), it may require a bootable
partition too. I'd be interested in knowing which specification covers
floppy and harddisk images on USB sticks and USB HDs being
mapped to normal devices by the BIOS. Do you know?


Rod Pemberton

[jc]

On Jan 18, 5:51 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> Your description of what DL is supposed to do is correct.  You might post to
> alt.os.development, or search archives of it, to confirm how well BIOSes
> support it.

Thanks. I'd been using osdev.org, but didn't know, or didn't remember,
about the newsgroup.

> > ... BIOS decides the USB key is a hard drive and not a floppy.
>
> That should require a HD image, i.e., the image has a partition table.
> Depending on the BIOS (I'm guessing ...), it may require a bootable
> partition too.  I'd be interested in knowing which specification covers
> floppy and harddisk images on USB sticks and USB HDs being
> mapped to normal devices by the BIOS.  Do you know?
>

It seems fairly certain that when there's a valid partition table the
BIOS decides it's a hard drive. I believe my BIOS is deciding the non-
partition-table image is a floppy simply because my chosen boot order
has USBFDD before USBHDD. Other BIOSes may be more or less
sophisticated. I don't know the spec, if there is one, and would be
highly skeptical that BIOS manufacturers follow specs to any given
level of accuracy anyway.

[Howerd]

Hi jc,

OK, so its looks like DL is cleared to 0 , and so read and write
access the non-existent floppy drive.
The Windows repair whinge was coincidence...

I took a look at the nasm files in your zip - I cannot see anything
that is restoring DL before a read or write - maybe this is a version
control issue?

Unfortunately I cannot build the system under Linux due to limited
time.

But we (i.e. you) are very close now :-)

Best regards,
Howerd

[jc]

On Jan 20, 10:40 am, Howerd <howe...@yahoo.co.uk> wrote:

> OK, so its looks like DL is cleared to 0 , and so  read  and  write
> access the non-existent floppy drive.
> The Windows repair whinge was coincidence...

So "vesa 2- + @" is showing you zero? Just out of curiosity, what does
"vesa @" show? If one memory location is being cleared, perhaps
several are.

> I took a look at the nasm files in your zip - I cannot see anything
> that is restoring DL before a read or write - maybe this is a version
> control issue?

It's in the last 4 lines of chs.nasm: CL is loaded with the drive
number which was saved at bootup, and it is stored on the stack such
that DL contains it after POPAD.

I don't believe there are any revision control issues. The Makefile
rebuilds the ZIPfile before every upload.

[Howerd]

Hi jc,

> It's in the last 4 lines of chs.nasm:

Yes - I can see it now - the code even has a comment ;-)

I am making too many assumptions here...

On my netbook :
vesa 2- + = 0x1f73 ( just so know we are talking about the same
location )
vesa 2- + @ = 0xd43f7f02
vesa @ = 0x4123
vesa @ @ = 0x0000

and vesa @ contains zeros all around that address ( 0x4123 )

In fact from 0x2f86 upwards appears to be all zeros...

Best regards,
Howerd

[jc]

On Jan 21, 1:54 am, Howerd <howe...@yahoo.co.uk> wrote:
> On my netbook :
> vesa 2- +    = 0x1f73  ( just so know we are talking about the same
> location )

We aren't:

jcomeau@intrepid:/usr/src/clusterFix$ printf "%x\n" $((0x1f73*4))
7dcc

A byte address of 7dcc indicates you're using an older kernel than I
am. On that one, "vesa 2- +" will not point to the right location. Use
the latest newboot.cf (compressed) or uncompressed.cf (uncompressed)
from http://unternet.net/src/clusterFix/

> vesa 2- + @  = 0xd43f7f02
> vesa @       = 0x4123
> vesa @ @     = 0x0000
> and vesa @ contains zeros all around that address ( 0x4123 )

vesa @ is not an address, it's your VESA mode (0x123 with linear
framebuffer in your case).

What you're seeing now at vesa 2- + @ might be the disk geometry. If
you use the newest kernel we'll be on the same page at least, and I'll
be able to help diagnose the problems more effectively.

[Howerd]

Hi jc,

This is progress! Now we know that we are not looking at the same
code ;-)

I downloaded your latest zip (21 Jan 2012) and tried newboot.cf in
the USB stick.
This is a 156k byte file, so must be compressed - it does not boot at
all.

I compared the uncompressed.cf files in the old and new zips - they
are identical, and both dated 12 Jan 2012.

I did wonder if I was using the latest because uncompressed.cf has
the "watermark" big block numbers, which are not present on the latest
version.

What is the date of the version of uncompressed.cf that you are
using?

Best regards,
Howerd

On Jan 21, 9:36 pm, jc <john.com...@gmail.com> wrote:
> On Jan 21, 1:54 am, Howerd <howe...@yahoo.co.uk> wrote:
>
> > On my netbook :
> > vesa 2- +    = 0x1f73  ( just so know we are talking about the same
> > location )
>
> We aren't:
>
> jcomeau@intrepid:/usr/src/clusterFix$ printf "%x\n" $((0x1f73*4))
> 7dcc
>
> A byte address of 7dcc indicates you're using an older kernel than I
> am. On that one, "vesa 2- +" will not point to the right location. Use
> the latest newboot.cf (compressed) or uncompressed.cf (uncompressed)

> fromhttp://unternet.net/src/clusterFix/

[Howerd]

Hi jc,

Correction - the compressed image newboot.cf dated 16 Jan 2012 does
boot correctly.

However it has exactly the same problem as the uncompressed version,
which is a relief, since they should end up with the same code after
decompression.

I have some problems with my Windows USB downloader. I got the USB
drive to boot after about three attempts, but for some time this
afternoon I could not write to the drive at all.
It may have something to do with the Avira anti-virus preventing
something from happening...

I will try the latest version as soon as you post it :-)

Best regards & TIA,
Howerd

[jc]

On Jan 22, 9:27 am, Howerd <howe...@yahoo.co.uk> wrote:
> However it has exactly the same problem as the uncompressed version,
> which is a relief, since they should end up with the same code after
> decompression.

Very strange. I'm using the same files, with the same dates, and they
both have the watermark numbers on edit blocks, as they have had since
I started this branch of the project using the af-35f-g144a12-PD
release from GreenArrays.

When I boot off the USB key, I invariably get 1f10 as a result of
'vesa', which is exactly right, as it is 0x10 words (0x40 bytes) into
the bootblock. This is what you should see if you hexdump the start of
uncompressed.cf:

jcomeau@intrepid:/usr/src/clusterFix$ xxd uncompressed.cf | head
0000000: fa56 eb65 400b 0000 2700 087c 0000 1823 .V.e@...'..|...#
0000010: ffff 0000 009a cf00 ffff 0000 0092 cf00 ................
0000020: ffff 0000 009a 0000 ffff 0000 0092 0000 ................
0000030: 0000 2000 0000 0000 0000 0000 0000 0000 .. .............
0000040: 4441 0000 3031 3233 3435 3637 3839 4142 DA..0123456789AB

Note the "4441" at offset 0x0000040. That is 0x4144, the default video
mode, which works for Bochs and QEMU. It gets overwritten during the
boot process, in your case to 0x4123. This is what ends up at the
address 0x7c40, which as a "word" address is 0x1f10. If you are really
booting from this binary, I can't see what could be giving you 0x1f75
for 'vesa'.

> I have some problems with my Windows USB downloader. I got the USB
> drive to boot after about three attempts, but for some time this
> afternoon I could not write to the drive at all.
> It may have something to do with the Avira anti-virus preventing
> something from happening...

Knowing you are running Windows, I can't help but speculate that it is
somehow using some hidden, cached copy of a previous version when you
write to your USB key. Microsoft is really cute like that.

We need to resolve this problem before we can do any meaningful
troubleshooting. So current goal: "vesa" yields 1f10. Agreed?

[Alex Wegel]

jc <john....@gmail.com> wrote:

> Very strange.

Could it be that instead of "vesa 2- + @" it should say "vesa -2 + @",
or even "vesa 2 - @"?

hth, alex

[jc]

On Jan 22, 12:08 pm, jc <john.com...@gmail.com> wrote:
> Note the "4441" at offset 0x0000040. That is 0x4144, the default video
> mode, which works for Bochs and QEMU. It gets overwritten during the
> boot process, in your case to 0x4123. This is what ends up at the
> address 0x7c40, which as a "word" address is 0x1f10. If you are really
> booting from this binary, I can't see what could be giving you 0x1f75
> for 'vesa'.

Found it by reverting back to my code from Dec. 21. That's very likely
the version you're using, from over a month ago. It has the boot drive
in the low byte at "vesa 3- + @", and the disk geometry (as I had
guessed) at "vesa 2- + @".

> We need to resolve this problem before we can do any meaningful
> troubleshooting. So current goal: "vesa" yields 1f10. Agreed?

But if you can't for some reason resolve this right away, and are
still seeing 1f75 as the result of "vesa", check "1f72 @" to see what
it's using for a drive number.

[jc]

On Jan 22, 3:59 pm, awe...@arcor.de (Alex Wegel) wrote:
> Could it be that instead of "vesa 2- + @" it should say "vesa -2 + @",
> or even "vesa 2 - @"?

Hi Alex, those might work in other Forths but not in arrayforth, at
least not this version. Entering "2-" at the prompt actually does give
you -2 on the stack, whereas entering "-2" causes the interpreter to
try and parse it as a word, which of course fails.

And "-" in cF is a bitnot operator, the equivalent of "~" in C.

[Alex Wegel]

oops.. 8-/

[Howerd]

Hi jc,

We are now in sync - I am using the 16 Jan 2012 compressed version,
and vesa returns 0x1f10.
vesa 2- + @ gives 0 , and this is presumably the problem.

I will test some more when time allows...

Best regards,
Howerd

[Howerd]

Hi jc,

Correction - the 0x80 drive number has now appeared. May have been a
typo on the Hamburg S-bahn...

Dump of the 4 cells below vesa and vesa itself ( in cell address
format from dump , ignoring the left column ) :
value address
00004123 00001f10 <-- vesa
d43f7f02 00001f0f
00000080 00001f0e <-- drive number
00000000 00001f0d
00227000 00001f0c

This all looks correct to me. I notice that the actual vesa mode is
not the same as yours, but is one of the three that you check for.
I am still not able to read from the USB drive.
How sure are you that the code is picking up the drive number from
1f0e == 0x7c38 in byte address units?
I get easily confused by cell versus byte addressing and 16 versus 32
bit assembler ;-)

Over to you :-)

Howerd

[jc]

On Jan 23, 3:32 am, Howerd <howe...@yahoo.co.uk> wrote:
> Hi jc,
>

> Correction - the 0x80 drive number has now appeared. May have been a
> typo on the Hamburg S-bahn...
>
> Dump of the 4 cells below vesa and vesa itself ( in cell address
> format from  dump , ignoring the left column ) :
> value    address
> 00004123 00001f10  <-- vesa
> d43f7f02 00001f0f
> 00000080 00001f0e  <-- drive number
> 00000000 00001f0d
> 00227000 00001f0c
>
> This all looks correct to me. I notice that the actual vesa mode is
> not the same as yours, but is one of the three that you check for.

Yes, that all looks good. I've change the boot code slightly (today's
upload) to correct the stored sector number, but that's only used
during boot anyway and won't have an effect on your problem.

> I am still not able to read from the USB drive.

Bummer.

> How sure are you that the code is picking up the drive number from
> 1f0e == 0x7c38 in byte address units?

Very sure. Somewhere around 99.9% sure, since I'm not using high-level
Forth to do it, I'm using it in assembly, with the label I gave it in
the source.

> Over to you :-)

Afraid I might not be able to troubleshoot this further, unless
somebody a lot closer to the San Francisco Bay area decides to help
test. The problem would almost have to be something to do with the
jump back into 16-bit mode for the BIOS call. Do you experience a
delay when you enter 0 !work, before the stack clears? If you don't,
then it's likely nothing at all is happening. Using the uncompressed
image on my system, it takes several seconds for "0 !work" to
complete, judging only by the stack display.

I could of course debug it using Bochs, but the problem doesn't appear
in Bochs. I'm open to suggestions.

[Howerd]

Hi jc,

> Bummer.
Exactly.

I think what we need is :
1. to try my USB drive in a PC that can boot in "USB floppy" mode
2. to load a USB drive under Linux.
that way we should at least know that it is not my (very flakey)
USBboot.exe (copy to boot sector) program.

If I could get USBboot.exe to work properly I could publish it and
maybe get some feedback form other users...

OK its late now. Thanks again for the excellent work - I remain
persistant :-)

Best regards,
Howerd

[jc]

On Jan 23, 2:41 pm, Howerd <howe...@yahoo.co.uk> wrote:
> I think what we need is :
> 1. to try my USB drive in a PC that can boot in "USB floppy" mode
> 2. to load a USB drive under Linux.
> that way we should at least know that it is not my (very flakey)
> USBboot.exe (copy to boot sector) program.
>
> If I could get USBboot.exe to work properly I could publish it and
> maybe get some feedback form other users...

If you're running Cygwin, 'dd' works on block devices. Googling brings
up a few examples: https://www.google.com/search?q=using+dd+in+cygwin

You can see my Makefile for the "dd" syntax. "make -n" just shows what
it does without actually writing anything, so you could "make -n
uncompressed.cf.usb" to see the command I use to write uncompressed.cf
to the bootsector of my USB key.

[Rod Pemberton]

"jc" <john....@gmail.com> wrote in message

news:a98776cf-b1bf-4d98...@rk3g2000pbb.googlegroups.com...

...

> If you're running Cygwin, 'dd' works on block devices.

FYI, for non-*nix environments, there are other utilities he can use to
write directly to USB and/or other devices, depending on his environment,
e.g., for DOS: John Fine's partcopy or rawrite/rawread, for Windows: USB
Image Tool or WinImage, etc.

It's possible but unlikely IMO that 'dd' works correctly in Cygwin, or maybe
it's limited to certain Windows versions ... In my experience, commands
like 'dd' and Linux 'fdisk' do work correctly in *nix environments, e.g.,
Linux, BSD, SysV, but don't work correctly in non-*nix environments, e.g.,
DJGPP, MinGW, etc. The usual problem is that those applications require
direct access to physical devices. In *nix environments, the C libraries
via fopen(), open(), etc support both file access and device access. In
non-*nix environments, the C libraries via fopen(), open(), etc usually
support file access but don't support device access. They don't support
direct device access because the non-Posix host doesn't support it.
Accessing a physical device in such environments requires a custom
device-driver to be written, i.e., to treat the device like a file to
conform with the "everything is a file" *nix concept. So, non-*nix
environments require a huge amount of work to support that and so usually
don't.


Rod Pemberton

[jc]

On Jan 24, 12:20 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "jc" <john.com...@gmail.com> wrote in message

> > If you're running Cygwin, 'dd' works on block devices.
>
> FYI, for non-*nix environments, there are other utilities he can use to
> write directly to USB and/or other devices, depending on his environment,
> e.g., for DOS: John Fine's partcopy or rawrite/rawread, for Windows: USB
> Image Tool or WinImage, etc.
>
> It's possible but unlikely IMO that 'dd' works correctly in Cygwin, or maybe
> it's limited to certain Windows versions ...

I used to use it in Cygwin under XP, and it worked just fine on block
devices. The guys who coded the Cygwin project did a really good job,
IMO. But once I switched to coLinux I never went back.

[Rod Pemberton]

"jc" <john....@gmail.com> wrote in message

news:56cb9f55-d536-4f74...@nu6g2000pbb.googlegroups.com...
...

<OT coLinux>

> But once I switched to coLinux I never went back.

How long now?

Which OSes and versions or distributions do you use?

Is Windows always the host to Linux?

What's the advantage?

I.e., if Windows can do everything I need or Linux can do everything I need,
why do I need two OSes?

The idea of a Linux on DOS appeals to me, since I still use DOS. The hope
would be to eliminate some of the issues DJGPP (GCC) has with DOS, i.e, not
using GLIBC, no physical device drivers. I was interested in whether UML
could be ported to DOS. From the coLinux website, it implies coLinux might
be a better choice. E.g., "... coLinux only requires a very small set of
commonly exported primitives from the host OS kernel in order to work ..."
Unfortunately, it doesn't define "small". AIR, UML was rewritten to just
use the C library, however the C library seemed to need almost the entire
Linux syscall interface to be implemented on the host OS. The number of
Linux syscalls keeps increasing. The last I counted it was up to 290
(kernel v2.6.17). Early Linux had about 40 implemented syscalls. So, the
question of how exactly many syscalls UML actually needed was an issue.
It's probably the same with coLinux.

BTW, any relation to Greg Comeau of Comeau C? It seems he still posts to a
variety of Usenet NGs (C, plan9, etc).


Rod Pemberton

[jc]

On Jan 24, 3:55 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>

wrote:
> "jc" <john.com...@gmail.com> wrote in message

> <OT coLinux>
>
> > But once I switched to coLinux I never went back.
>
> How long now?

I guess 3 or 4 years.

> Which OSes and versions or distributions do you use?

Currently, Windows Vista and Debian GNU/Linux.

> Is Windows always the host to Linux?

No, in fact rarely.

> What's the advantage?
>
> I.e., if Windows can do everything I need or Linux can do everything I need,
> why do I need two OSes?

I run in Linux only unless I'm doing a job that requires Windows; in
that case I do what I can under Linux within coLinux, and whatever
else (IE testing for example) I do with Windows. I use the actual
Linux partition on my drive rather than a virtual drive, which makes
it fairly seamless to switch back and forth. Also, /etc/hosts is a
symlink to /mnt/vista/system32/drivers/etc/hosts, so whatever is in my
hosts file is available to both Windows and Linux.

> The idea of a Linux on DOS appeals to me, since I still use DOS.  The hope
> would be to eliminate some of the issues DJGPP (GCC) has with DOS, i.e, not
> using GLIBC, no physical device drivers.  I was interested in whether UML
> could be ported to DOS.  From the coLinux website, it implies coLinux might
> be a better choice.  E.g., "... coLinux only requires a very small set of
> commonly exported primitives from the host OS kernel in order to work ..."
> Unfortunately, it doesn't define "small".  AIR, UML was rewritten to just
> use the C library, however the C library seemed to need almost the entire
> Linux syscall interface to be implemented on the host OS.  The number of
> Linux syscalls keeps increasing.  The last I counted it was up to 290
> (kernel v2.6.17).  Early Linux had about 40 implemented syscalls.  So, the
> question of how exactly many syscalls UML actually needed was an issue.
> It's probably the same with coLinux.

I haven't looked under the hood. It "just works", and I have so many
other projects already; hundreds in fact.

> BTW, any relation to Greg Comeau of Comeau C?  It seems he still posts to a
> variety of Usenet NGs (C, plan9, etc).

Probably a distant cousin. Comeau = Comeaux = Commeaux ?= Como ?=
Cuomo, possibly all of us from the Lake Como area of Italy. "Comeau"
has no meaning in French, hence my guess. I could be all wet on this
though :^)

[Howerd]

Hi jc,

I have tidied up my USBboot.exe program enough to be useable, and
zipped it up with two of your colorForth binaries here :

http://www.inventio.co.uk/USBboot1v0.zip

Maybe you could run USBboot.exe as administrator, insert your USB
drive and press the space bar to compare.
Or make your own USB drives using USBboot.exe - either way we should
be able to pin down the save problem abit more...

USBboot.exe copies the file USBimage.cf to, or compares with, a USB
drive.
It also shows the MD5 hash of the file and USB disk image.

There are still some unexplained issues (for me at least) around Disks
and Volumes, and what a BIOS makes of them.

I would love to know if a USB drive loaded with my program 'saves' on
your machine :-)

If anyone else would like to have a go too that would be fine...

Best regards,
Howerd

[Dennis Ruffer]

At 1st, I don't see any change when pressing Q or Y in your program,
but then I unplugged it and plugged it back in and got:

**** Copy boot image USBimage.cf to a USB drive ****

www.inventio.co.uk USBboot V1.0 2012 Jan 27

Please insert the USB drive to be programmed...

Note that Pressing Q and Y will destroy all data on the USB drive!!!

You may need to remove and re-insert the USB drive until it works


Ignore and 'cancel' later any Windows that pop up offering to format
the drive

Press the Esc key to exit the program

Interface Name VID Vendor ID
name PID Product ID name
- DEVICEINTERFACE Disk
- DEVICEINTERFACE USB 55AA OnSpec Electronic,
Inc. 2B30
- DEVICEINTERFACE Volume
- VOLUME Local physical drive F
+ DEVICEINTERFACE USB 55AA OnSpec Electronic,
Inc. 2B30
+ DEVICEINTERFACE Disk
PhysicalDriveName \\.\PHYSICALDRIVE2
OpenPhysicalDriveFile success
+ DEVICEINTERFACE Volume
+ VOLUME Local physical drive F
- DEVICEINTERFACE Disk
- DEVICEINTERFACE USB 55AA OnSpec Electronic,
Inc. 2B30
- DEVICEINTERFACE Volume
- VOLUME Local physical drive F
+ DEVICEINTERFACE USB 55AA OnSpec Electronic,
Inc. 2B30
+ DEVICEINTERFACE Disk
PhysicalDriveName \\.\PHYSICALDRIVE2
OpenPhysicalDriveFile success
Press 'Q' to copy file USBimage.cf to the USB drive that you just
inserted, or 'space' to compare :
!!!!!!!!!!!!!!! WARNING!!!! THIS OVERWRITES THE USB DRIVE !!!! Press
Y to continue :
OpenPhysicalDriveFile success
Writing USBimage.cf to USB drive, length = 159744 = 156 K bytes
WriteUSBdrive failed! LastError = 0 Not an error at all ;)
Check that the USB drive is not write protected (e.g. Lock switch)
For Win7/Vista you may need to 'Run as administrator'
(right click on USBboot.exe).
OpenPhysicalDriveFile success
*************************************************************
* Compare failed!!! *
*************************************************************
File being written MD5 : 1DCF044DAC5070828C33E7D2BD72B8F1
Data on USB drive MD5 : 6DE8D7BA4716AD0BF4DDCAB203D2DB9A
Size = 159744 = 156 K bytes

Press the Esc key to quit the program ...
Or insert another USB drive

+ DEVICEINTERFACE Volume
+ VOLUME Local physical drive F

I will try to boot it now...

DaR

[Dennis Ruffer]

Nope, it would not boot on my HP Pavilion dm3 U4100 Mobile Intel(R) 4

DaR

[Howerd]

Hi DaR,

The "Compare failed!" message in red and different MD5 hashes from the
file and USB drive indicate that the USB drive has not been updated...
It is therefore not going to boot ;-)

USBboot.exe detects Windows events when a USB device is inserted or
removed. I felt this is the best way of only writing to the device
that you insert, rather than some other drive.
Sometimes Windows trys to be helpful and pops up a window offering you
the opportunity to format the newly inserted drive. This sometimes
prevents my program from registering the event, so you have to remove
and reinsert the USB drive.

Did you run USBboot.exe as administrator? Right click on it and choose
that option. Some flavours of Windows require this (Win7, Vista).
I have never had a working USB drive that didn't get programmed by
this, but I have only tried three different drives.

It also works on some SD cards, which may then boot on some machines.

I'm getting a sense of deja vue here - this is like trying to get
native colorForth to boot on a variety of different floppy disk
drives.
This is a sure sign that we a messing about at a level below
Microsoft's comfort zone (again).

Thanks for trying this :-)

Best regards,
Howerd

[Ray St. Marie]

On Jan 3, 2:34 am, jc <john.com...@gmail.com> wrote:
> Howerd, I've made some progress, getting your Conway's Life program
> working on clusterFix, except that the 'g' key doesn't actually get
> the game automatically playing; repeatedly hitting 'g' or space is
> necessary. The only thing I had to change was to make all the variable
> references yellow. Apparently arrayforth (or colorforth 2?) is much
> pickier about that than cf2005.
>
> The only other change I know for sure you need to make to get cf2010
> working with the clusterfix kernel is to redefine block to:
>
> : block [ offset ] @ +
> : blks $100 * ;
>
> (the fallthrough is of course necessary).
>
> Here is the Life that is almost working:
>
> {block 960}
> ( app conway's game of life) empt 962 load
> : cell 32 /mod adj adj over over at 16 u+ 16 + box ;
> : nocell drop ;
> : draw dup old @ 1 and jump nocell cell
> : cells [ 1023 ] for i draw -next ;
> : gen [ 1023 ] for i tick swap new ! -next [ 1023 ] for i new @ i
> old ! -next ;
> : loc [ row ] @ 32 * [ col ] @ + ;
> : cur loc dup old @ $ff * $ff0000 + color cell ;
> : back black screen $303010 color 40 40 at 583 dup box ;
> : g show back green cells gen keyboard ;
> : s gen show back blue cells cur keyboard ;
> : clear 1500 8 erase 16 [ row ] ! 16 [ col ] ! s ;
> : t loc old dup @ 1 or ( xor) swap ! ;
> : l $7ffffff [ col ] +! [ col ] @ 31 and [ col ] ! ;
> : u $7ffffff [ row ] +! [ row ] @ 31 and [ row ] ! ;
> : d 1 [ row ] +! [ row ] @ 31 and [ row ] ! ;
> : r 1 [ col ] +! [ col ] @ 31 and [ col ] ! ;
> : h pad nul nul accept nul nul nul nul nul l u d r nul nul nul nul
> glide glid2 glid3 glid4 clear s g t nul nul nul nul [ $2500 , 0 ,
> $110160c , 0 , $1c1b1a19 , $20d0815 , 0 , clear glide g h ]
>
> {block 961}
>
> : s ( stop)
> : g ( go)
> : t ( toggle the square)
> : ludr ( left up down right)
> : . ( press s to stop then draw a shape using ludr and t to toggle)
> : . ( then press g to go or s to single step)
> : 1234 ( create gliders which move to the four corners counting
> clockwise from the top left)
>
> {block 962}
> ( conway's game of life) var row [0x10] var col [0x10]
> : old [ 1500 block ] + ;
> : new [ 1504 block ] + ;
> : nul ;
> : pos swap 32 /mod swap ;
> : val 32 * + swap over old @ 1 and + ;
> : up pos swap 31 + 31 and val ;
> : dn pos swap 1 + 31 and val ;
> : lt pos 31 + 31 and swap val ;
> : rt pos 1 + 31 and swap val ;
> : n [ 0 ] ;
> : s dup old @ 1 and ;
> : y [ 1 ] ;
> : tick dup 0 up lt dn dn rt rt up up nip jump n n s y n n n n n
> : adj swap 17 * 40 + ;
> : st ( rc-) [ col ] @ + swap [ row ] @ + 32 * + old 1 swap ! ;
> : glide 0 2 st 0 1 st 0 0 st 1 0 st 2 1 st ;
> : glid2 0 0 st 0 1 st 0 2 st 1 2 st 2 1 st ;
> : glid3 0 2 st 1 2 st 2 2 st 2 1 st 1 0 st ;
> : glid4 0 0 st 1 0 st 2 0 st 2 1 st 1 2 st ;

Hi JC,
Hope this finds you well!

I've had some luck with this. Things to note about my changes:
At the bottom of the main block "h" before "g", that is, call the
keyboard before displaying.
Changing "g" into a loop that can be interrupted by "key?" and the
need for "pause" before using "key?".
The "s" display word becomes the "ok" word, if you will permit, and
therefore suppressing the "cur" cursor and changing the color of the
moving blocks happens there with a new variable "colr" and the jump
word "colour".
I've also moved "cell" and "nocell" to the next block to make room for
my new words, this meant moving "adj" above "cell". I've removed
"null" already in the system.

{block 960}
( app conway's game of life) empt 962 load var colr 0 / NEW VARIABLE
: draw dup old @ 1 and jump nocell cell
: cells [ 1023 ] for i draw -next ;
: gen [ 1023 ] for i tick swap new ! -next [ 1023 ] for i new @ i
old ! -next ;
: loc [ row ] @ 32 * [ col ] @ + ;
: cur loc dup old @ $ff * $ff0000 + color cell ;
: back black screen $303010 color 40 40 at 583 dup box ;
: colour [ colr ] @ jump green blue / NEW WORD and g and s CHANGED!
: g 0 [ colr ] ! gen pause key? g ;
: s 1 [ colr ] ! gen show back colour cells [ colr ] @ 0 or drop if
cur then keyboard ;
: clear 1500 8 erase 16 [ row ] ! 16 [ col ] ! s ;
: t loc old dup @ 1 or ( xor) swap ! ;
: l $7ffffff [ col ] +! [ col ] @ 31 and [ col ] ! ;
: u $7ffffff [ row ] +! [ row ] @ 31 and [ row ] ! ;
: d 1 [ row ] +! [ row ] @ 31 and [ row ] ! ;
: r 1 [ col ] +! [ col ] @ 31 and [ col ] ! ;
: h pad nul nul accept nul nul nul nul nul l u d r nul nul nul nul
glide glid2 glid3 glid4 clear s g t nul nul nul nul [ $2500 , 0 ,
$110160c , 0 , $1c1b1a19 , $20d0815 , 0 , clear glide h g ]
\ h AND g SWAPPED

{block 961}

: s ( stop)
: g ( go)
: t ( toggle the square)
: ludr ( left up down right)
: . ( press s to stop then draw a shape using ludr and t to toggle)
: . ( then press g to go or s to single step)
: 1234 ( create gliders which move to the four corners counting
clockwise from the top left)

{block 962}
( conway's game of life) var row [0x10] var col [0x10]
: adj swap 17 * 40 + ; / adj MOVED ABOVE cell
: cell 32 /mod adj adj over over at 16 u+ 16 + box ;
: nocell drop ; / cell and nocell MOVED HERE FOR ROOM ON PREV BLOCK
: old [ 1500 block ] + ;
: new [ 1504 block ] + ;
: pos swap 32 /mod swap ;
: val 32 * + swap over old @ 1 and + ;
: up pos swap 31 + 31 and val ;
: dn pos swap 1 + 31 and val ;
: lt pos 31 + 31 and swap val ;
: rt pos 1 + 31 and swap val ;
: n [ 0 ] ;
: s dup old @ 1 and ;
: y [ 1 ] ;
: tick dup 0 up lt dn dn rt rt up up nip jump n n s y n n n n n
: st ( rc-) [ col ] @ + swap [ row ] @ + 32 * + old 1 swap ! ;
: glide 0 2 st 0 1 st 0 0 st 1 0 st 2 1 st ;
: glid2 0 0 st 0 1 st 0 2 st 1 2 st 2 1 st ;
: glid3 0 2 st 1 2 st 2 2 st 2 1 st 1 0 st ;
: glid4 0 0 st 1 0 st 2 0 st 2 1 st 1 2 st ;

/ NO OTHER CHANGES


I hope this works for you.

I recall that in the past some versions of colorforth had a show word
that somehow did the display update loop for you. What I mean is that
'show' would allow one to create a word that would update the changes
in the display with out need of a specific display loop. I assume that
is how the versions that Howerd is using work. I recall trying LIFE
and it word just as you have it coded in Howerd's collection.

At any rate, this is no longer the case. "show" is a 'one-shot' word,
and while it will show the frame buffer to the screen, words like
"gen" above need to be looped to update the buffer.

In order to keep the custom keyboard on the screen the display loop
pauses and uses "key?" to pop out of the loop. I had to do something
similar to TETRIS earlier this week to get the custom keyboard to not
switch back to the editor/interpret keyboard. ( let me know if you
would like a copy of TETRIS)

"clear" calls "s" ( there are 2 "s" words in this program and in this
case I mean the second-display word) ... calls "s" and this is enough
to start the display and the keyboard, so no need for "g" to do so.

Again I hope this works for you as well as it does for me.

Thank you for inspiring me to include "LIFE" in my personal collection
and giving me an opportunity to hack it into action. :-)


Ray

[Ray St. Marie]

AHH! i'm a bone head! :-)

I meant to say that "clear" calls the display thru "s" so swapping "g"
and "h" just means calling the "gen" loop after setting the keyboard,
instead of the keyboard waiting till after the "g / gen" loops finish,
which they won't with out a keyboard interrupt thru "key?".

And also the new "g" word loop constantly sets the "[ colr ]" variable
to 0 so this is slightly better:

: g 0 [ colr ] ! / FALLS THROUGH
: gg gen pause key? gg ;

and back to sleep :-)

Ray

[jc]

On Jan 30, 3:53 am, "Ray St. Marie" <ray.stma...@gmail.com> wrote:
> I meant to say that "clear" calls the display thru "s" so swapping "g"
> and "h" just means calling the "gen" loop after setting the keyboard,
> instead of the keyboard waiting till after the "g / gen" loops finish,
> which they won't with out a keyboard interrupt thru "key?".

Thanks Ray, but I'm much more of a bonehead and can't comprehend this
at the moment, though I was quite sure I used that "key?" trick in my
mandelbrot colorforth program (before finding out about Mark Slicker's
superior program he had written years earlier).

In any case, this works for me, at least under Windows, and I have no
reason to believe it won't work natively as well. It's now added to my
clusterFix distribution http://unternet.net/src/clusterFix/conray.f
(no typo there... remember "Chvorak"? :^)

If you feel like getting one of the Mandelbrot generators to work on
this kernel I'd be much happier with that than with Tetris, but it's
all about what brings *you* joy. Very glad to see you posting again --
jc

[Ray St. Marie]

On Feb 3, 2:26 am, jc <john.com...@gmail.com> wrote:
> On Jan 30, 3:53 am, "Ray St. Marie" <ray.stma...@gmail.com> wrote:
>
> > I meant to say that "clear" calls the display thru "s" so swapping "g"
> > and "h" just means calling the "gen" loop after setting the keyboard,
> > instead of the keyboard waiting till after the "g / gen" loops finish,
> > which they won't with out a keyboard interrupt thru "key?".
>
> Thanks Ray, but I'm much more of a bonehead and can't comprehend this
> at the moment, though I was quite sure I used that "key?" trick in my
> mandelbrot colorforth program (before finding out about Mark Slicker's
> superior program he had written years earlier).

The colorforth2 version I have of your "manju" Mandlebrot/Julia sets
does not include "key?" but then it is not needed in that program.
Each key-press of the custom keyboard you wrote is intended to only do
one change to the display. There is no need for an animation loop that
would have to be interrupted each key press.

>
> In any case, this works for me, at least under Windows, and I have no
> reason to believe it won't work natively as well. It's now added to my

> clusterFix distributionhttp://unternet.net/src/clusterFix/conray.f

> (no typo there... remember "Chvorak"? :^)
>

:^) I am honored to be included. Thank you very much!

> If you feel like getting one of the Mandelbrot generators to work on
> this kernel I'd be much happier with that than with Tetris, but it's
> all about what brings *you* joy. Very glad to see you posting again --
> jc

I have only just learned of your project this last two weeks and I am
currently reading it all.

With-out having the benefit of reading the project as yet, the only
thing I can for-see being a "problem" between your colorForth2 manju,
and having it hosted in an arrayForth is that arrayForth no longer
supports capital letters... those will have to be changed, and running
the manju thru the compressor/decompressor will automagically do this
to your code at any rate.

okay an hour later and I have done the above, that is I have imported
colorforth2 "manju" into arrayForth-01g and with the exception of the
capital font reducing to the arrayForth tiny font, "manju" works.

I will fix the fonts to no-caps and then post a link here for you to
try 'manju' in arrayforth-01g.

Best regards,
Ray

[jc]

On Feb 3, 4:47 pm, "Ray St. Marie" <ray.stma...@gmail.com> wrote:
> On Feb 3, 2:26 am, jc <john.com...@gmail.com> wrote:
> > On Jan 30, 3:53 am, "Ray St. Marie" <ray.stma...@gmail.com> wrote:
> The colorforth2 version I have of your "manju" Mandlebrot/Julia sets
> does not include "key?" but then it is not needed in that program.
> Each key-press of the custom keyboard you wrote is intended to only do
> one change to the display. There is no need for an animation loop that
> would have to be interrupted each key press.
>

> I will fix the fonts to no-caps and then post a link here for you to
> try 'manju' in arrayforth-01g.

I don't believe "manju" to be my creation, in fact I've never heard of
it before! But it sounds great anyway :^)

Just a couple of notes about my f2cf.py program: 'var' needs to be
':var', and comments can only be in parens, not preceded by backslash
(and definitely not by forward-slash!). I don't mind making the
changes though.

[Ray St. Marie]

OH! MY! John, I am so embarrassed, and on several counts.

1. I have confused you with jc== Jef Calpe, author of Manju.
2. I have no knowledge of what I assume to be FORTHtoColorForth a
Python code translator.
3. that I had used forward slashes to indicate something I should have
used backslashes for.

Please excuse my ignorance. I am trying to catch up as quickly as
possible.

I have finished a couple of web pages and a have created a version of
arrayForth-01g that includes LIFE, Tetris, manju, and Mark Slickers
mand Mandlebrot. I need to proof read everything before posting.

I am struggling with the idea of rewriting some of Jef Calpe's code
because some of his words may conflict with words already in
arrayForth. OR do I just post it as is?


embarrassed
Ray

[jc]

On Feb 4, 4:54 am, "Ray St. Marie" <ray.stma...@gmail.com> wrote:
> On Feb 3, 6:47 pm, jc <john.com...@gmail.com> wrote:
> > Just a couple of notes about my f2cf.py program: 'var' needs to be
> > ':var', and comments can only be in parens, not preceded by backslash
> > (and definitely not by forward-slash!). I don't mind making the
> > changes though.
>
> OH! MY! John, I am so embarrassed, and on several counts.
> 1. I have confused you with jc== Jef Calpe, author of Manju.

No need to be. We haven't met, and we've interacted only sporadically
on various newsgroups. It was an easy error to make under the
circumstances.

> 2. I have no knowledge of what I assume to be FORTHtoColorForth a
> Python code translator.

That was in a separate thread, and if you're just catching up you
couldn't have known about it. It's on the webpage to which I referred
above, http://unternet.net/src/clusterFix/

> 3. that I had used forward slashes to indicate something I should have
> used backslashes for.
>
> Please excuse my ignorance. I am trying to catch up as quickly as
> possible.

Excused. Ignorance is curable. At least I keep telling myself that :^}

> I have finished a couple of web pages and a have created a version of
> arrayForth-01g that includes LIFE, Tetris, manju, and Mark Slickers
> mand Mandlebrot. I need to proof read everything before posting.
>
> I am struggling with the idea of rewriting some of Jef Calpe's code
> because some of his words may conflict with words already in
> arrayForth. OR do I just post it as is?

Just swallow that embarrassment (it tastes good with chocolate) and
post; we'll sort out any problems :^)

And *thank you*!

[Ray St. Marie]

On Feb 4, 8:36 am, jc <john.com...@gmail.com> wrote:
> On Feb 4, 4:54 am, "Ray St. Marie" <ray.stma...@gmail.com> wrote:
> No need to be. We haven't met, and we've interacted only sporadically
> on various newsgroups. It was an easy error to make under the
> circumstances.

Thank you for saying so, much appreciated. :-)

>
> > 2. I have no knowledge of what I assume to be FORTHtoColorForth a
> > Python code translator.
>
> That was in a separate thread, and if you're just catching up you
> couldn't have known about it. It's on the webpage to which I referred
> above,http://unternet.net/src/clusterFix/
>

Got a chance to look over the clusterfix. Must say how impressed I am
of the work you have done!
Hoping I can be of service to you there.

>
> > Please excuse my ignorance. I am trying to catch up as quickly as
> > possible.
>
> Excused. Ignorance is curable. At least I keep telling myself that :^}
>

Right! meee tooo :-)

> Just swallow that embarrassment (it tastes good with chocolate) and
> post; we'll sort out any problems :^)
>
> And *thank you*!

I'm a chockoholic so... YUMM!


I posted a page about the diffs between Charlie's original Mandlebrot
in your collection and changes I made that will make that particular
version work in arrayForth-01g.
It is here:

http://colorforthray.info/rayaf/cfjccsrsmand.html

"On behalf of the group and myself, I hope we've passed the
audition" :-)

Still working out the page about the other two colorForth Mandlebrots
and should have that up later tonight/tomorrow.

Best regards,
Ray

[jc]

On Feb 4, 3:41 pm, "Ray St. Marie" <ray.stma...@gmail.com> wrote:
> I posted a page about the diffs between Charlie's original Mandlebrot
> in your collection and changes I made that will make that particular
> version work in arrayForth-01g.
> It is here:
>
> http://colorforthray.info/rayaf/cfjccsrsmand.html

Thanks, but (1) I see no good reason for my name to be on it, having
contributed nothing to it, (2) Charley spells (or spelled at the time
of his post) his first name with an 'e' and last name with a 'u', e.g.
"Charley Shattuck", and (3) if you could post in the right format for
c2cf.py I could simply test without having to retype everything.
Alternatively, if you could send me the binary that would work too: jc
at unternet dot net.

> Still working out the page about the other two colorForth Mandlebrots
> and should have that up later tonight/tomorrow.

Much appreciated, thank you Ray.

[Ray St. Marie]

I have completed my work, thank you very much for your kind critique.
The page above has been resubmitted with your kind changes.

http://colorforthray.info/rayaf/cfjccsrsmand.html

two other pages now exist that feature:
Jef Calpe's and Mark Slicker's Mandlebrots
http://colorforthray.info/rayaf/cfmanjumand.html

The reason that they are featured together is that Jef has updated
Mark's work to include Jef's words that access and draw to the frame
buffer for both native and windows versions.

The second page is:
http://colorforthray.info/rayaf/cflifetetris.html
and features my changes to LIFE and includes the Tetris as a bonus.

ALL of those things above are included in a zipped downloadable that
includes those pages, the current OKAD executable that runs them, and
an OkadWork.cf that includes all of the code and a few extras that I
use ( not yet all of them) in developing code for Pentium running
colorforths.

http://colorforthray.info/rayaf/afcfmandlifetetris.zip



I shall either learn how to use your f2cf--cf2f's or I will ( most
likely because I have loads of free time and enjoy--) code it by hand
very very soon.

Thanks again John!
Ray

[jc]

Just ran the Mandelbrot app. Beautiful work, thanks immensely. I
should be able to incorporate your apps into clusterFix without much
effort.

[Ray St. Marie]

Thank you for saying that, John.

I had noticed that the TETRIS did not automatically start a piece in
world so I made a minor change to the executable by adding the reset
word "rc" to the initialization word "ini". Then I recreated the html
page, recreated the zip and executable and updated everything, now
with a date at the top of the page.

http://colorforthray.info/rayaf/afcfmandlifetetris.zip

If there is anything else I can do...

I am learning the f2cf--cf2f and cfword code this evening. Being that
I have not touched python in 10 years, it is a might slow going. But I
will get there.


Thank you for allowing me to hi-jack your USB thread. I understand
that this hi-jacking is supposed to be highly irregular, and my only
excuse is that I am not that savvy in how these things are supposed to
work.

Being that I've never been money motivated, live for appreciation, I
thank you again for your kind words of encouragement.

Here's to more progress
Ray

[Ray St. Marie]

On Jan 22, 5:47 pm, awe...@arcor.de (Alex Wegel) wrote:
> jc <john.com...@gmail.com> wrote:

> > On Jan 22, 3:59 pm, awe...@arcor.de (Alex Wegel) wrote:
> > > Could it be that instead of "vesa 2- + @" it should say "vesa -2 + @",
> > > or even "vesa 2 - @"?
>
> > Hi Alex, those might work in other Forths but not in arrayforth, at
> > least not this version. Entering "2-" at the prompt actually does give
> > you -2 on the stack, whereas entering "-2" causes the interpreter to
> > try and parse it as a word, which of course fails.
>
> > And "-" in cF is a bitnot operator, the equivalent of "~" in C.
>
> oops.. 8-/

just to add a smight more precision to John's answer...
This is just in the QWERTY mode of the colorforth keyboard in the
newest arrayForths where you must put a number up on the stack first
before you can use the minus sign to negate it for just the reason
John says above. In ChuckVorack mode this is not necessary and you can
select ( must actually) the minus sign on the number-keyboard display
before completing the rest of the number. Qwerty does not use a
dedicated number keyboard displayed and like John says...


Regards,
Ray