[Color-Forth:406] disassembly of arrayForth
jcomeau_ictx
in-progress of disassembling the arrayForth kernel, using a patched
version of Albert van der Horst's cidis (ciasdis) version 0.3.0. The
patch and instructions are included. Albert has been very helpful with
this, and has supplied me with starter .cul files on which I have
expanded.
I split the kernel part of the binary (the first 12K) into two pieces
at the end of the bootblock, since by that point (0x200, or 0x7e00
where loaded by the BIOS) the system has been relocated to 0020,0200.
And I didn't know how to set a new -ORG- using a .cul file, so it was
easier for me just to disassemble in two parts. The Makefile
reassembles, as a test, and compares the concatenated results to the
original 12K binary. So to complete the disassembly, all that is
necessary is to view cf2code.dsm, add the next address of data that
looks like i386 machine code with a CRAWL statement to cf2code.cul,
and 'make' to see if it disassembles/reassembles correctly.
After the disassembly is complete, I plan to work on commenting the
source so it's more obvious what's going on.
--
You received this message because you are subscribed to the Google Groups "ColorForth" group.
To post to this group, send email to Color...@googlegroups.com.
To unsubscribe from this group, send email to Color-Forth...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/Color-Forth?hl=en.
Dennis Ruffer
as I get a chance.
Your work prompted me to get my latest work published to the files section
at:
http://groups.google.com/group/Color-Forth/files?hl=en
I've had this colorForth to ascii translator around for a while and I
recently updated it to arrayForth and just got the Restore.f portion
working. It creates am almost readable ascii translation of a cf file. It
even handles the compressed ones now. It can do a complete round trip, back
into a cf file, but I haven't bothered to translate the compression
algorithm yet. It runs in gforth, and maybe SwiftForth, but I haven't
tested it in SwiftForth for a while. It should work in others easily, but
I'm just not setup to test in anything but gforth on Win7 with cygwin.
You might like my formatting if you are going to do some commenting of the
source.
Enjoy!
DaR
Dennis Ruffer
I can't get any of them to download properly, so I just posted the 2 files
in my cf2a2cf.zip separately. You need cf2a2cf.f and Restore.f together for
it to load properly.
I'm just wondering why zip doesn't work. ;(
DaR
Ray St. Marie
> Can anyone download the zip files in the Files section of this group?
>
> I can't get any of them to download properly, so I just posted the 2 files
> in my cf2a2cf.zip separately. You need cf2a2cf.f and Restore.f together for
> it to load properly.
>
> I'm just wondering why zip doesn't work. ;(
>
> DaR
>
Do not knwo why you had a problem from this end.
thanks ray
--
Raymond St. Marie ii,
public E-mail Ray.s...@gmail.com
a quickstart guide http://colorforthray.info
http://groups.google.com/group/Color-Forth
Community Blog http://colorForth.net
Community Wiki http://ForthWorks.com/c4th
The Movies http://YouTube.com/Raystm2
jcomeau_ictx
http://unixshell.unternet.net/src/cf2_analyze/cf2boot.dsm
Also, the Makefile is more complete, allowing you to build the patched
ciasdis with: make ../ciasdis
It still has numerous assumptions that may trip people up: the
cf2_analyze folder should be in your /usr/src; AvdH's Forth compiler
"lina" version 4.0.6 should be installed on your system; /usr/bin/cias
and /usr/bin/cidis should be symlinked to /usr/src/ciasdis/ciasdis.
On May 14, 12:46 am, jcomeau_ictx <john.com...@gmail.com> wrote:
> Seehttp://unixshell.unternet.net/src/cf2_analyze/for my current work-
jcomeau_ictx
> The arrayForth boot sector code is now quite fully commented:http://unixshell.unternet.net/src/cf2_analyze/cf2boot.dsm
> Also, the Makefile is more complete, allowing you to build the patched
> ciasdis with: make ../ciasdis
7C00-7E00 addresses aren't hardcoded anywhere in the first 0200 bytes;
so now the URL is http://unixshell.unternet.net/src/cf2_analyze/cf2.dsm
Still working on commenting the code, but also focusing on making
the .cul files use relative offsets, to make it easier to apply them
to other colorForth releases.
So far resisting the urge to mess with the code, though I'm seeing
lots of opportunities!
Can anyone tell me authoritatively, if this code is booted natively on
a machine without a serial port, will the serial-port code hang it?
Dennis Ruffer
> > The arrayForth boot sector code is now quite fully
> commented:http://unixshell.unternet.net/src/cf2_analyze/cf2boot.dsm
> > Also, the Makefile is more complete, allowing you to build the
> patched
> > ciasdis with: make ../ciasdis
>
> I've now merged cf2boot.* with cf2code.*, after realizing that the
> 7C00-7E00 addresses aren't hardcoded anywhere in the first 0200 bytes;
> so now the URL is http://unixshell.unternet.net/src/cf2_analyze/cf2.dsm
I'm going to have to figure out merging your updates this weekend.
> Still working on commenting the code, but also focusing on making
> the .cul files use relative offsets, to make it easier to apply them
> to other colorForth releases.
>
> So far resisting the urge to mess with the code, though I'm seeing
> lots of opportunities!
If you see any serious mistakes, Chuck would probably be interested.
> Can anyone tell me authoritatively, if this code is booted natively on
> a machine without a serial port, will the serial-port code hang it?
It's been a long time since I've done much work on Intel CPUs, but I suspect
that outs to the serial addresses will work. You would get stuck if an in
is waiting for something specific, but I doubt that the code would hang.
Otherwise, too much debug code wouldn't work on those machines.
Try it and see. ;)
DaR
jcomeau_ictx
locations in the code. But anyway, I finally did get a USB key to mess
around with, and here's what happened on my emachines E625 laptop: the
screen shows 0180 F902 FA02 F620 F620 across the top left; the USB
light flashes, indicating it's loading; the screen goes blank; and it
reboots. Over and over. Now to see what those numbers mean...
jcomeau_ictx
> On May 28, 7:37 am, "Dennis Ruffer" <daruf...@gmail.com> wrote:
>
> > > On May 26, 12:38 am, jcomeau_ictx <john.com...@gmail.com> wrote:
> > > Can anyone tell me authoritatively, if this code is booted natively on
> > > a machine without a serial port, will the serial-port code hang it?
>
>
> Well, it does wait for something specific, in several different
> locations in the code. But anyway, I finally did get a USB key to mess
> around with, and here's what happened on my emachines E625 laptop: the
> screen shows 0180 F902 FA02 F620 F620 across the top left; the USB
> light flashes, indicating it's loading; the screen goes blank; and it
> reboots. Over and over. Now to see what those numbers mean...
0180 F902 FA02 F620 F620
indicates the boot device is the first hard drive known to the BIOS
F902: F9 is the index of the last drive head.
FA02: FA is the number of heads (by adding 1 to the 0-based index)
F620: F6 is the low 8 bits of the index of the last cylinder. 20 is
the 1-based index of the last sector-per-track, and thus the number of
sectors per track. The high two bits are 0, but if present would be
bits 8 and 9 of the last cylinder index. The number appears again
because the 2nd time is after the high 2 bits of the low byte have
been cleared.
FA * 20 * (F6 + 1) should be the size of the disk (USB key). It is, as
closely as the virtual geometry can express it: 197600 512-byte
sectors for a total 1011712000 bytes accessible by the normal int13
BIOS calls. The actual size is a little larger: 1981408 sectors,
1014480896 bytes.
Hard drive? Hmm... I thought, and figured I had made a mistake in my
dd command. Sure enough, history | dd showed I had placed the
arrayForth image onto /dev/sdb1 not /dev/sdb. That was why it wouldn't
boot, I figured, since the bootloader assumed the image was at the
start of the disk, not of a partition. But read on...
So, I ran: dd if=OkadWork.cf of=/dev/sdb, and this time got the
numbers 0000 FE01 FF01 7A3F 7A3F, which indicates the first floppy
drive and FF * 3F * 7B accessible bytes: 1011709440. Lost 2.5k more
because the BIOS decided this was a floppy, based upon a VBR (Volume
Boot Record) existing where it expected a MBR, Master Boot Record. And
this time it booted up all the way; although the video was all wrong,
and the screen appeared blank, when I pressed keys it would flicker
and I could see the "qwer" appear. So the serial-port stuff does not
interfere with booting. Good.
Curious about the 01 in DH appearing at the first boot, and not
finding that documented anywhere, I restored the USB key's original
MBR (using xxd -r on the saved xxd dump in my xterm buffer; a very
useful tool for people who do things without fully thinking them
through) and made some more partitions using Linux's fdisk. Then I
dd'd OkadWork.cf onto partition 3, made that bootable, and tried
again. Instead of 0380 showing up in the screendump of DX (the first
number in the 5 numbers dumped), which I guessed would indicate the
first hard drive partition 3, there was 0080. And it booted up all the
way again! From a partition, using the same bootloader that supposedly
expects the colorForth image starting at sector 0 on the disk.
The only difference I can see between the two partitions is that the
"type byte" of partition 1 is 0b (W95 FAT32) and partition 3 is 07,
which I set because it's used by several widely different operating
systems, so a normal bootloader wouldn't dare mess with it. I
disassembled the code of the bootloader that came with the USB key,
but haven't yet grokked it in fullness.
Obviously I have more stuff to figure out, but first I want to add
back my VESA code and unreal-mode code from some of my last colorForth
experiments on SourceForge (back when I was using the GNU "as"
assembler; I got discouraged when I upgraded gcc and my code would no
longer compile, back in 2007 or 2008 as I remember). These changes
will allow it to boot on many more systems, hopefully including my
laptop, and allow writes back to the boot medium using BIOS calls, by
switching between protected and unreal mode each time the BIOS is to
be used. Dennis, if you could convince Chuck to accept those two
changes to the colorForth kernel, it ought to make life easier for
everyone who wants to use colorForth or arrayForth natively on an x86
system. Meanwhile, according to the new website, I can't call the
modified code colorForth. Maybe clusterFix.
Dennis Ruffer
I'm just barely following what you have discovered, but it sounds like you
are on your way to figuring out how to make Chuck's code more compatible
with more USB controllers. If you can manage to get them to work, or at
least, more of them to work, I suspect Chuck will be very interested. I
know that the USB driver has been a issue for them. I doubt he is listening
to this group, but as you move forward, if we don't hear from anyone in his
group, I can pass along your results. At the moment, I don't think I can
summarize it well enough to pass on much of anything, but I suspect it will
become clearer with time.
On my efforts, I'm chugging alone converting Albert's ciasdis to gforth, or
actually, to something closer to ANS standards. It's pretty well married to
his ciforth at the moment, but I was able to make quite a bit of progress
this last weekend. I only have a couple more files to go and I might have
enough to submit something back to him.
Sounds like good progress on both fronts. ;)
DaR
> -----Original Message-----
> From: color...@googlegroups.com [mailto:color-
> fo...@googlegroups.com] On Behalf Of jcomeau_ictx
> Sent: Sunday, June 06, 2010 6:45 PM
> To: ColorForth
> --
> You received this message because you are subscribed to the Google
> Groups "ColorForth" group.
> To post to this group, send email to Color...@googlegroups.com.
> To unsubscribe from this group, send email to Color-
> Forth+un...@googlegroups.com.
Dennis Ruffer
re-purpose my existing vf-plugins site at
http://code.google.com/p/vf-plugins/ to share what I am doing with everyone
and to maybe enlist some volunteers to help fill in some of the blanks.
You can download an archive of my latest work at:
http://code.google.com/p/vf-plugins/downloads/detail?name=cfdis.zip
You will need Albert van der Horst's ciadis from:
http://home.hccnet.nl/a.w.m.van.der.horst/forthassembler.html
Or you can just look at the consultation file at:
http://code.google.com/p/vf-plugins/source/browse/trunk/af/OkadWork.cul
Any place where there is a CRAWL, we need to have a name for that jump
target.
Any place where there is a LABELED, we need a name for that data location.
I have added a wiki page to organize your input at:
http://code.google.com/p/vf-plugins/wiki/Labels
I need to make the assembler portions to complete this round trip, and the
disassemblers may change some as I do that, but it's good enough to give you
all a view of where I am headed. Look around at the other pages and feel
free to share your thoughts.
Have fun! ;)
DaR