As a hobby exercise, I will be developing a somewhat large program for
a very ancient 808x computer with limited RAM (128KB).  So far, most
of my projects in this realm have been in Turbo Pascal 7.0 with a
mixture of inline asm code and linked assembler .objs, all authored by
me.  I would like to take the final plunge into 100% asm-developed
programming, which I feel will not only give me the best bang for the
buck in terms of size (important to this memory-limited machine) but
also because I feel that it will be a lot of fun.

My only question is:  What assembler should I start with?  My
requirements are:

- Able to compile 16-bit code while running on 16-bit processor (ie. a
32-bit build of NASM does not help me)
- Able to generate symbolic debugger output and/or otherwise work with
a debugger
- Able to create and maintain libraries of code.  Overlay management a
plus (see below)
- Decent documentation must exist for these in any form (remember, I'm
new to the process of 100% asm projects).  I have the ability to
obtain packages/manuals/books (I already own a complete package of
tasm 4.0, for example)

As far as I can tell, my choices are:

- masm (not sure which version) + debug.com
- a86 + d86
- tasm (3.2? 4.0? not sure which is best version) + turbo debugger
- nasm + ??

My development environment is the same speed and processor as my
target environment, but with 640KB RAM and a hard disk, so that makes
things easier.

An additional wrinkle is that I would eventually like to deploy this
program as a bootable disk -- meaning, I was thinking of writing my
own custom floppy disk boot loader that would load code segments into
memory and execute them.  I was planning on writing everything as .com
files to test/debug them from DOS, then after it's all working, change
how they're loaded and executed.

I would be interested to hear any and all suggestions, criticism,
comments, etc.  Subjective opinions welcome, even if to tell me I
should switch to C or something.  a86 appeals to be because of its
simplicity, but I have no experience with it and the debugger appears
cumbersome at first glance.  tasm appeals to be because I am familiar
with turbo debugger; not sure if I should use ideal mode or not.  nasm
appeals to be because I would be using a modern, supported assembler,
but I don't know what my debugging options are.  Any direction is
appreciated!

On Jan 18, 12:49=A0am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:
> As a hobby exercise, I will be developing a somewhat large program for
> a very ancient 808x computer with limited RAM (128KB). =A0So far, most
> of my projects in this realm have been in Turbo Pascal 7.0 with a
> mixture of inline asm code and linked assembler .objs, all authored by
> me. =A0I would like to take the final plunge into 100% asm-developed
> programming, which I feel will not only give me the best bang for the
> buck in terms of size (important to this memory-limited machine) but
> also because I feel that it will be a lot of fun.
>
> My only question is: =A0What assembler should I start with? =A0My
> requirements are:
>
> - Able to compile 16-bit code while running on 16-bit processor (ie. a
> 32-bit build of NASM does not help me)
> - Able to generate symbolic debugger output and/or otherwise work with
> a debugger
> - Able to create and maintain libraries of code. =A0Overlay management a
> plus (see below)
> - Decent documentation must exist for these in any form (remember, I'm
> new to the process of 100% asm projects). =A0I have the ability to
> obtain packages/manuals/books (I already own a complete package of
> tasm 4.0, for example)
>
> As far as I can tell, my choices are:
>
> - masm (not sure which version) + debug.com
> - a86 + d86
> - tasm (3.2? 4.0? not sure which is best version) + turbo debugger
> - nasm + ??
>
> My development environment is the same speed and processor as my
> target environment, but with 640KB RAM and a hard disk, so that makes
> things easier.
>
> An additional wrinkle is that I would eventually like to deploy this
> program as a bootable disk -- meaning, I was thinking of writing my
> own custom floppy disk boot loader that would load code segments into
> memory and execute them. =A0I was planning on writing everything as .com
> files to test/debug them from DOS, then after it's all working, change
> how they're loaded and executed.
>
> I would be interested to hear any and all suggestions, criticism,
> comments, etc. =A0Subjective opinions welcome, even if to tell me I
> should switch to C or something. =A0a86 appeals to be because of its
> simplicity, but I have no experience with it and the debugger appears
> cumbersome at first glance. =A0tasm appeals to be because I am familiar
> with turbo debugger; not sure if I should use ideal mode or not. =A0nasm
> appeals to be because I would be using a modern, supported assembler,
> but I don't know what my debugging options are. =A0Any direction is
> appreciated!

I would highly recommend to do the development with a decent machine,
with quick (online) reference access and fancy IDE/Editor,
and test the code on VM if the project do not rely on special I/O
stuff (with small changes)
and test on target machine (with bigger changes)
This make life much easier and you can have more choice of tools.

On Jan 17, 10:49=A0am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:
> My only question is: =A0What assembler should I start with?

BTW I forgot to mention that I'm posing these questions *after* having
read "Which Assembler Is Best" (http://web.archive.org/web/
20070222085435/http://webster.cs.ucr.edu/WhichAsm.html).  I'm hoping
people look at my development environment, experience level
(intermediate assembly programmer), and eventual target (self-booting
floppy that chains or overlays code segments) and can recommend the
best starting point.

On Jan 17, 10:49=A0am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:
> As a hobby exercise, I will be developing a somewhat large program for
> a very ancient 808x computer with limited RAM (128KB). =A0So far, most
> of my projects in this realm have been in Turbo Pascal 7.0 with a
> mixture of inline asm code and linked assembler .objs, all authored by
> me. =A0I would like to take the final plunge into 100% asm-developed
> programming, which I feel will not only give me the best bang for the
> buck in terms of size (important to this memory-limited machine) but
> also because I feel that it will be a lot of fun.
>
> My only question is: =A0What assembler should I start with? =A0My
> requirements are:
>
> - Able to compile 16-bit code while running on 16-bit processor (ie. a
> 32-bit build of NASM does not help me)
> - Able to generate symbolic debugger output and/or otherwise work with
> a debugger
> - Able to create and maintain libraries of code. =A0Overlay management a
> plus (see below)
> - Decent documentation must exist for these in any form (remember, I'm
> new to the process of 100% asm projects). =A0I have the ability to
> obtain packages/manuals/books (I already own a complete package of
> tasm 4.0, for example)
>
> As far as I can tell, my choices are:
>
> - masm (not sure which version) + debug.com
> - a86 + d86
> - tasm (3.2? 4.0? not sure which is best version) + turbo debugger
> - nasm + ??
>
> My development environment is the same speed and processor as my
> target environment, but with 640KB RAM and a hard disk, so that makes
> things easier.
>

I'm biased, fwiw.  I use NASM v 0.98.38 (Dos) compiled on Sept 12
2003.  I develop under XP using CMD.EXE, and target 16/32 bit code in
either .COM or .EXE or .BIN form, without linkers or libraries, just
%include modules as needed, in other words, a monolithic build.  I've
done the same on DR-DOS 6, using XTPRO as the file manager / editor.
I use [MAP ALL filename.MAP] directive to check some things n/a in the
filename.LST listing file.  I use SID.EXE (OpenDOS tool) for
debugging .COM or 16bit .BIN's and CV.EXE (ms codeview) for the .EXE
16&32 bit stuff.  Since there isn't any .obj in this method, there
isn't any embedded debug info.  The listing file suffices, along with
the .map file on occasion (you know, old school).

Commonly I use .BIN form with 16&32 bit code and load it from a custom
bootloader on a fat12 diskette, the target is Pentium class generally.

In all of these; com, exe, bin, I manage my own segments.  All of
these optionally allow independent sections, if you manage them within
your code, separate .code, .data, .stack, even nobits sections.  EXE
is the most restrictive in that the ordering is
dictated: .data, .stack, .code, but then nobits sections can be sized
and set to FS and GS.

> An additional wrinkle is that I would eventually like to deploy this
> program as a bootable disk -- meaning, I was thinking of writing my
> own custom floppy disk boot loader that would load code segments into
> memory and execute them. =A0I was planning on writing everything as .com

Not a problem.  It's alittle odd that they say a .com is restricted to
64k, yet the dos loader gives a .com all of available memory.  And
AFAICT, a .com > 64k could be loaded under dos.  XP's CMD.EXE does
report 'out of memory' on trying to load a .COM > 64k.  It will
accept the same if made as an .EXE file however.

> files to test/debug them from DOS, then after it's all working, change
> how they're loaded and executed.
>

I don't find this to be a problem either.  I write much the same code
for RomBios interrupts, int 21h (least used), or Call5 system
interfaces.  There's no filesystem for RomBios calls, of course, this
requires low level function calls to 'build-up' a filesystem, such as
fat12.  Most boot strap code demonstrates some of that.

> I would be interested to hear any and all suggestions, criticism,
> comments, etc. =A0Subjective opinions welcome, even if to tell me I
> should switch to C or something. =A0a86 appeals to be because of its
> simplicity, but I have no experience with it and the debugger appears
> cumbersome at first glance. =A0tasm appeals to be because I am familiar
> with turbo debugger; not sure if I should use ideal mode or not. =A0nasm
> appeals to be because I would be using a modern, supported assembler,
> but I don't know what my debugging options are. =A0Any direction is
> appreciated!

You've got my perspective, hth,

Steve

Jim Leonard wrote:

....
> 32-bit build of NASM does not help me)

I think this is the last 16-bit build of Nasm. I'm not certain if it's 
targeted at 8086/8088 or possibly 80286? If you decide to try it, let me 
know if it runs on 8086/8.

<http://sourceforge.net/projects/nasm/files/DOS%2016-bit%20binaries%20%28OBSOLETE%29/0.98.39/nsm09839.zip/download>

> - Able to generate symbolic debugger output and/or otherwise work with
> a debugger

Well... Nasm's "-f obj" mode produces symbolic debug info (the "-g" 
switch) allegedly compatible with TD. Alexei did some work on it, and it 
no longer causes TD to "act like a barral of sexed-up monkeys" (to quote 
a bug report). I don't think it's 100%.

> - Able to create and maintain libraries of code.

More a function of your linker, I think.

....
> An additional wrinkle is that I would eventually like to deploy this
> program as a bootable disk -- meaning, I was thinking of writing my
> own custom floppy disk boot loader that would load code segments into
> memory and execute them.  I was planning on writing everything as .com
> files to test/debug them from DOS, then after it's all working, change
> how they're loaded and executed.

Sounds like a good plan!

> I would be interested to hear any and all suggestions, criticism,
> comments, etc.  Subjective opinions welcome, even if to tell me I
> should switch to C or something.

Heavens to Murgatroid! :)

>  a86 appeals to be because of its
> simplicity, but I have no experience with it and the debugger appears
> cumbersome at first glance.

Just a "learning curve", I think.

> tasm appeals to be because I am familiar
> with turbo debugger;

Familiarity is a *big* plus!

> not sure if I should use ideal mode or not.

I suppose they called it "ideal" 'cause they thought it was good. Nasm 
liked the idea and carried it further (in a way). Down side would be not 
compatible with Masm...

> nasm
> appeals to be because I would be using a modern, supported assembler,

The 16-bit build isn't, really. You won't be needing the new 
instructions anyway. :)

> but I don't know what my debugging options are.

I have to think that Tasm would be "even more compatible" with TD. Since 
you're already familiar with that toolset, I'd stick with Tasm (much as 
I love Nasm).

Best,
Frank

"Jim Leonard" <mobygamer@nospicedham.gmail.com> wrote in message
news:0d181c2e-68e4-4af2-bbc6-fca9647060ba@y31g2000vbt.googlegroups.com...
>
> - Able to compile 16-bit code while running on 16-bit processor (ie. a
> 32-bit build of NASM does not help me)

IIRC, there are 16-bit versions of NASM.

> As far as I can tell, my choices are:
>
> - masm (not sure which version) + debug.com
> - a86 + d86
> - tasm (3.2? 4.0? not sure which is best version) + turbo debugger
> - nasm + ??
>

NASM supposedly has 16-bit builds on sourceforge upto the 0.98.39 version
which should cover 16-bit/32-bit code.  You'll have to check if they are
8086 or 80286 executables.
http://sourceforge.net/projects/nasm/files/DOS%2016-bit%20binaries%20(OBSOLETE)/

DJGPP port of GNU GAS is 32-bit only, but the DJGPP project has an 16-bit
assembler.  I suspect has to be run from 32-bit though...
http://www.delorie.com/djgpp/16bit/

There are other assemblers: fasm, yasm.  I think they're both NASM
compatible, i.e., probably support compiling 16-bit.  fasm has a DOS
version.  fasm.exe has "required 80386 or better" in it...  That doesn't
look promising, but maybe it's just a warning during assembling.  yasm has a
DOS version.  It's 32-bit DJGPP based.  So, that one is out for sure.
http://flatassembler.net/
http://www.tortall.net/projects/yasm/

The FreeDOS project also lists Dunfield's ArrowAsm, JWASM, and Wasm
(Wolfware Asm, not OpenWatcom).  JWasm is Japheth's improved replacement for
OpenWatcom's Wasm.  It's a MASM clone.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/arrow/
http://www.japheth.de/JWasm.html
http://www.shoelesscomputers.com/software/wasm/

Sorry, you'll have to download and try them...

> nasm
> appeals to be because I would be using a modern, supported assembler,
> but I don't know what my debugging options are.
>

None come with it, AFAIK.    DJGPP has GDB as a debugger.  Of course, it's
32-bit.  Japheth has a DEBUG clone which, IIRC, is for the FreeDOS project.
It's 16-bit.  It comes with assembly source and binaries.  It compiles with
MASM or JWasm:
http://www.japheth.de/debxxf.html

That could be a candidate for a NASM port.


Rod Pemberton

Jim Leonard wrote:
> - Decent documentation must exist for these in any form (remember, I'm
> new to the process of 100% asm projects).  I have the ability to
> obtain packages/manuals/books (I already own a complete package of
> tasm 4.0, for example)
>
> As far as I can tell, my choices are:
>
> - masm (not sure which version) + debug.com
> - a86 + d86
> - tasm (3.2? 4.0? not sure which is best version) + turbo debugger
> - nasm + ??

Even before reading your message body I would have suggested TASM + TD, 
I have used this combo for more than 20 MBs (.asm source) of pure asm 
programming. (The last was probably around 1995 though!)

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

"Rod Pemberton" <do_not_have@nospicedham.notreplytome.cmm> wrote

(as severely excerpted...)

> 
> There are other assemblers: fasm, yasm.  I think they're both NASM
> compatible, i.e., probably support compiling 16-bit.  fasm has a
> DOS version.  fasm.exe has "required 80386 or better" in it... 
> That doesn't look promising, but maybe it's just a warning during
> assembling.  

Nope it is genuine : all FASM versions share the same main code, with 
some added OS-specific "glue". They us  32-bit flat segments, 
*including* the code segment (CS) ! The real mode version is not an 
exception, it runs in "huge real" mode and yes a 32 bits CS too (CS 
desciptor D bit set). Kind of a prowess, isn't it (although Tomasz 
wasn't the first to create such an exotic real mode, it is very rarely 
used and in fact breaks on some early Cyrix processors).

In every case, a "386 or better" /is/ a requisite.

Cheers


-- 
Czerno

On Jan 18, 1:35=A0am, Terje Mathisen <"terje.mathisen at
tmsw.no"@giganews.com> wrote:
> Even before reading your message body I would have suggested TASM + TD,
> I have used this combo for more than 20 MBs (.asm source) of pure asm
> programming. (The last was probably around 1995 though!)

I was kind-of leaning that way as well (familiarity, I own the
manuals, etc.), but wanted to make sure I wasn't making some horrible
mistake before starting.

So, ideal mode or not?  And which version?  (3.2? 4.0?)

Even though I dislike microsoft OS they do compiler right!

16-bit linker MASM 6.14 DOS
ftp://ftp.microsoft.com/Softlib/MSLFILES/ml614.exe

16-bit linker
ftp://ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE


In <0d181c2e-68e4-4af2-bbc6-fca9647060ba@y31g2000vbt.googlegroups.com>, Jim Leonard <mobygamer@nospicedham.gmail.com> writes:
>As a hobby exercise, I will be developing a somewhat large program for
>a very ancient 808x computer with limited RAM (128KB).  So far, most
>of my projects in this realm have been in Turbo Pascal 7.0 with a
>mixture of inline asm code and linked assembler .objs, all authored by
>me.  I would like to take the final plunge into 100% asm-developed
>programming, which I feel will not only give me the best bang for the
>buck in terms of size (important to this memory-limited machine) but
>also because I feel that it will be a lot of fun.
>
>My only question is:  What assembler should I start with?  My
>requirements are:
>
>- Able to compile 16-bit code while running on 16-bit processor (ie. a
>32-bit build of NASM does not help me)
>- Able to generate symbolic debugger output and/or otherwise work with
>a debugger
>- Able to create and maintain libraries of code.  Overlay management a
>plus (see below)
>- Decent documentation must exist for these in any form (remember, I'm
>new to the process of 100% asm projects).  I have the ability to
>obtain packages/manuals/books (I already own a complete package of
>tasm 4.0, for example)
>
>As far as I can tell, my choices are:
>
>- masm (not sure which version) + debug.com
>- a86 + d86
>- tasm (3.2? 4.0? not sure which is best version) + turbo debugger
>- nasm + ??
>
>My development environment is the same speed and processor as my
>target environment, but with 640KB RAM and a hard disk, so that makes
>things easier.
>
>An additional wrinkle is that I would eventually like to deploy this
>program as a bootable disk -- meaning, I was thinking of writing my
>own custom floppy disk boot loader that would load code segments into
>memory and execute them.  I was planning on writing everything as .com
>files to test/debug them from DOS, then after it's all working, change
>how they're loaded and executed.
>
>I would be interested to hear any and all suggestions, criticism,
>comments, etc.  Subjective opinions welcome, even if to tell me I
>should switch to C or something.  a86 appeals to be because of its
>simplicity, but I have no experience with it and the debugger appears
>cumbersome at first glance.  tasm appeals to be because I am familiar
>with turbo debugger; not sure if I should use ideal mode or not.  nasm
>appeals to be because I would be using a modern, supported assembler,
>but I don't know what my debugging options are.  Any direction is
>appreciated!

Jim Leonard <mobygamer@nospicedham.gmail.com> writes:
>On Jan 18, 1:35=A0am, Terje Mathisen <"terje.mathisen at
>tmsw.no"@giganews.com> wrote:
>> Even before reading your message body I would have suggested TASM + TD,
>> I have used this combo for more than 20 MBs (.asm source) of pure asm
>> programming. (The last was probably around 1995 though!)
>
>I was kind-of leaning that way as well (familiarity, I own the
>manuals, etc.), but wanted to make sure I wasn't making some horrible
>mistake before starting.
>
>So, ideal mode or not?  And which version?  (3.2? 4.0?)

Hi,

   If you want to share your code, or have others help you
with it, then MASM mode would seem to be a convenience.
Obviously, if no one else is going to see it, then it is your
preference alone.

   The newest version should have the most bugs fixed.
The oldest may use less resources.  Try them out and
see which one has the fewest constraints on your system.

   $0.02.

Regards,

Steve N.

On Wed, 19 Jan 2011 10:39:52 +0000 (UTC),
anon@nospicedham.att.net wrote:

>Even though I dislike microsoft OS they do compiler right!
>
>16-bit linker MASM 6.14 DOS
>ftp://ftp.microsoft.com/Softlib/MSLFILES/ml614.exe
>
>16-bit linker
>ftp://ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE
>

I'll also add my vote for MASM.  My old 16-bit Daqarta for
DOS was well over 64K code size, involving inter-segment
calls.  It also self-decrypted, rewrote speed-critical
sections using a home-built token assembler (when the user
changed certain controls like trigger slope), and did lots
of other "non-standard" assembler operations.  MASM v5.00
worked fine.  

I now use MASM32 for Daqarta for Windows.

Best regards,


Best regards,


Bob Masta
 
              DAQARTA  v6.00
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
          Science with your sound card!

On Wed, 2011-01-19 at 13:45 +0000, Bob Masta wrote:
> On Wed, 19 Jan 2011 10:39:52 +0000 (UTC),
> anon@nospicedham.att.net wrote:
>=20
> >Even though I dislike microsoft OS they do compiler right!
> >
> >16-bit linker MASM 6.14 DOS
> >ftp://ftp.microsoft.com/Softlib/MSLFILES/ml614.exe
> >
> >16-bit linker
> >ftp://ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE
> >
>=20
> I'll also add my vote for MASM.  My old 16-bit Daqarta for
> DOS was well over 64K code size, involving inter-segment
> calls.  It also self-decrypted, rewrote speed-critical
> sections using a home-built token assembler (when the user
> changed certain controls like trigger slope), and did lots
> of other "non-standard" assembler operations.  MASM v5.00
> worked fine. =20
>=20
> I now use MASM32 for Daqarta for Windows.

Ever thought about porting that to the Linux platform?=20
--=20
Tactical Nuclear Kittens

Jim Leonard polled for opinions:

> As a hobby exercise, I will be developing a somewhat large program for
> a very ancient 808x computer with limited RAM (128KB).  So far, most
> of my projects in this realm have been in Turbo Pascal 7.0 with a
> mixture of inline asm code and linked assembler .objs, all authored by
> me.  I would like to take the final plunge into 100% asm-developed
> programming, which I feel will not only give me the best bang for the
> buck in terms of size (important to this memory-limited machine) but
> also because I feel that it will be a lot of fun.
>
> My only question is:  What assembler should I start with?  My
> requirements are:

> - Able to compile 16-bit code while running on 16-bit processor (ie. a
> 32-bit build of NASM does not help me)
> - Able to generate symbolic debugger output and/or otherwise work with
> a debugger
> - Able to create and maintain libraries of code.  Overlay management a
> plus (see below)
> - Decent documentation must exist for these in any form (remember, I'm
> new to the process of 100% asm projects).  I have the ability to
> obtain packages/manuals/books (I already own a complete package of
> tasm 4.0, for example)

The problem might be a decent debugger support, but I'd use either
FASM (allowes mix of 16/32-bit code and data)
or NASM (AFAIK the older 16-bit variant also had a mix opportunity).

> As far as I can tell, my choices are:

JMHO:

> - masm (not sure which version) + debug.com

No.

> - a86 + d86

No, never.

> - tasm (3.2? 4.0? not sure which is best version) + turbo debugger

Ok if you can find a working asm/debug-pair ... I don't know any.

> - nasm + ??

unfortunately you'll need to write the debugger yourself ... :)
not a big deal for 16-bit DOS, but some overhead and detours needed
for 16-bit emulation within Loonix or windoze environments as usual.

> My development environment is the same speed and processor as my
> target environment, but with 640KB RAM and a hard disk, so that makes
> things easier.

Me think a 8086 disassembler/debugger could be written within a few
(~30) hours for any platform, there are not too many instructions to
consider and XT-hardware architecture contains only a few things.

> An additional wrinkle is that I would eventually like to deploy this
> program as a bootable disk -- meaning, I was thinking of writing my
> own custom floppy disk boot loader that would load code segments into
> memory and execute them.  I was planning on writing everything as .com
> files to test/debug them from DOS, then after it's all working, change
> how they're loaded and executed.

DOS + debug.com helped me once to develope my own tools, but this
is now that long ago that I really would have to search my old
handwritten comments to tell how I did it then :)

FASM can do boot-image formats (ie: .bin). Not sure about, but NASM
should do it as well: [org 0 | org 7c00h | :use16 ?] or similar.

> I would be interested to hear any and all suggestions, criticism,
> comments, etc.  Subjective opinions welcome, even if to tell me I
> should switch to C or something.  a86 appeals to be because of its
> simplicity, but I have no experience with it and the debugger appears
> cumbersome at first glance.  tasm appeals to be because I am familiar
> with turbo debugger; not sure if I should use ideal mode or not.  nasm
> appeals to be because I would be using a modern, supported assembler,
> but I don't know what my debugging options are.  Any direction is
> appreciated!

My question just is: why work on and for machines which only reside
in the museum since decades ?

Either way,
As a performance hunter I'd forget very fast about C and all other
high-level approaches to make a programm which shall have any sense.

TASM/TD/... PowerBasic with the integrated source-level debugger
might be what you search for. I once used it too, but soon found
the frequent need for ASM db lines and the unwanted stack-behave
too annoying, so I replaced this functions with my own tools.

Granted, for fast created, dirty hacks like demo-disks, PowerBasic is
still a workable choice for me because it saves me and my clients from 
formatting a partition for my Filesystem just to view how it looks.
So this PB 16-bit compiler remained as an active part in my tool-set.

And yes, a working but not too restricting OS like DOS 6.00 (even
limited to certain maemory range, it is the last one without VM86
detours) helps alot in creating your very own functions.

With every step into detailed functions from yourself you can get
rid of one of this weird designed M$-functions or even replace most
of the (now almost completely C-bloated-shit) BIOS functions.

It worked quite well for me that way, even the learning curve
may be a bit steep and may need 'some' love for deep details :)
__
wolfgang

On Jan 17, 12:55=A0pm, Bluemoon <nospam.cal...@nospicedham.gmail.com>
wrote:
> I would highly recommend to do the development with a decent machine,
> with quick (online) reference access and fancy IDE/Editor,
> and test the code on VM if the project do not rely on special I/O
> stuff (with small changes)
> and test on target machine (with bigger changes)
> This make life much easier and you can have more choice of tools.

Unfortunately, my target platform is nearly impossible to emulate,
especially with the very specific timing operations I'll be writing
code for, as well as the hardware I'm interfacing with.

On 01/18/2011 06:17 AM, Czerno wrote:
>>
>> There are other assemblers: fasm, yasm.  I think they're both NASM
>> compatible, i.e., probably support compiling 16-bit.  fasm has a
>> DOS version.  fasm.exe has "required 80386 or better" in it... 
>> That doesn't look promising, but maybe it's just a warning during
>> assembling.  
> 
> Nope it is genuine : all FASM versions share the same main code, with 
> some added OS-specific "glue". They us  32-bit flat segments, 
> *including* the code segment (CS) ! The real mode version is not an 
> exception, it runs in "huge real" mode and yes a 32 bits CS too (CS 
> desciptor D bit set). Kind of a prowess, isn't it (although Tomasz 
> wasn't the first to create such an exotic real mode, it is very rarely 
> used and in fact breaks on some early Cyrix processors).
> 
> In every case, a "386 or better" /is/ a requisite.
> 

It's also rather a pointless mode, since it's not compatible with other
real-mode code, which means you might as well run in 32-bit protected mode.

	-hpa

On Jan 20, 6:37=A0am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:
> On Jan 17, 12:55=A0pm, Bluemoon <nospam.cal...@nospicedham.gmail.com>
> wrote:
>
> > I would highly recommend to do the development with a decent machine,
> > with quick (online) reference access and fancy IDE/Editor,
> > and test the code on VM if the project do not rely on special I/O
> > stuff (with small changes)
> > and test on target machine (with bigger changes)
> > This make life much easier and you can have more choice of tools.
>
> Unfortunately, my target platform is nearly impossible to emulate,
> especially with the very specific timing operations I'll be writing
> code for, as well as the hardware I'm interfacing with.


If you are going to develop on the ancient machine, you'll need a good
plan on backup as it can explode anytime :D
Especially you mentioned your work include booting directly - if you
mess it up you may lost your work!

IMO a better approach is do the coding with newer machine, and
transfer to the target machine for testing.

Either way, you'll need to setup a good workflow to transfer files.

For debugger, do you have any special requirement? you mentioned some
timing sensitive code, and not much memory of target platform, it
seems not many choice and endup with crappy debugger(in a modern
sense). So I would not totally rely much on debugger and would
consider also producing signals(print on screen)/traps(halt/reboots)/
log(serial/file) to do debugging work.

On Wed, 19 Jan 2011 15:30:30 +0000, Freedom on the Oceans
<alex.buell@nospicedham.munted.org.uk> wrote:

>On Wed, 2011-01-19 at 13:45 +0000, Bob Masta wrote:
>> On Wed, 19 Jan 2011 10:39:52 +0000 (UTC),
>> anon@nospicedham.att.net wrote:
>>=20
>> >Even though I dislike microsoft OS they do compiler right!
>> >
>> >16-bit linker MASM 6.14 DOS
>> >ftp://ftp.microsoft.com/Softlib/MSLFILES/ml614.exe
>> >
>> >16-bit linker
>> >ftp://ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE
>> >
>>=20
>> I'll also add my vote for MASM.  My old 16-bit Daqarta for
>> DOS was well over 64K code size, involving inter-segment
>> calls.  It also self-decrypted, rewrote speed-critical
>> sections using a home-built token assembler (when the user
>> changed certain controls like trigger slope), and did lots
>> of other "non-standard" assembler operations.  MASM v5.00
>> worked fine. =20
>>=20
>> I now use MASM32 for Daqarta for Windows.
>
>Ever thought about porting that to the Linux platform?=20

Thanks for asking... I'll take that as a compliment.  <g>
But the problem is that I'd have a huge learning curve since
I am not even a Linux user, let alone a Linux coder. 
Daqarta makes heavy use of API calls (there are well over
1000 user-adjustable controls).  I don't for a moment
imagine that a port would be anything remotely as simple as
a 1:1 replacement of Windows API calls with Linux
equivalents (which I guess might also vary depending on
which specific Linux GUI was used?).  I'm sure there will be
many places where my entire approach would need to be
re-thought.  I'm guessing at least a year of my time here.

And on top of all the work, there is the fact that the vast
majority of Linux users won't pay for anything.  Not such a
good deal for me!

However, about a year ago I looked at WINE.  Daqarta *sorta*
ran on WINE under Ubuntu, but I never got around to tracking
down the problems.  Thay might have been due to my test
system, which was an early XP machine with 256 Meg RAM
(*including* integrated video).  XP ran fine with this
amount of RAM, but Ubuntu was slow as molasses and crashed
frequently.  Apparently, the days are long gone when Linux
would run fine on ancient systems.  <sigh>

Anyway, "one of these days" I do hope to get back to testing
Daqarta under WINE on a system with more RAM.

Best regards,



Best regards,


Bob Masta
 
              DAQARTA  v6.00
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
          Science with your sound card!

N0Spam@daqarta.com (Bob Masta) �crivait :

 
> However, about a year ago I looked at WINE.  Daqarta *sorta*
> ran on WINE under Ubuntu, but I never got around to tracking
> down the problems.  Thay might have been due to my test
> system, which was an early XP machine with 256 Meg RAM
> (*including* integrated video).  XP ran fine with this
> amount of RAM, but Ubuntu was slow as molasses and crashed
> frequently.  Apparently, the days are long gone when Linux
> would run fine on ancient systems.  <sigh>
> 

Ubuntu not == Linux ! Ububtu = Windows7 in diguise. Just kidding, but 
really the Buntus  are very bloated distros oriented towards Windows 
lusers and hardly work acceptably but on high end hardware. 

You better try a lighter distribution - there are a handful that will 
happily run on a 486 and 32 megabytes or even less RAM, but you don't 
need/want to be so minimalist. OpenSUSE, Fedora, PCLOS ... are what 
you want, and you might choose a lighter desktop than Gnome (burp!) 
or KDE.

> Anyway, "one of these days" I do hope to get back to testing
> Daqarta under WINE on a system with more RAM.
> 

Doesn't your app use its own Windows *drivers* ? I'm unsure WINE is 
able to run those (yes this is a question to the n.g.)

Regards

-- 
NimbUs

"H. Peter Anvin" <hpa@nospicedham.zytor.com> wrote

>> Nope it is genuine : all FASM versions share the same main code,
>> with some added OS-specific "glue". They us  32-bit flat
>> segments, *including* the code segment (CS) ! The real mode
>> version is not an exception, it runs in "huge real" mode and yes
>> a 32 bits CS too (CS desciptor D bit set). Kind of a prowess,
>> isn't it (although Tomasz wasn't the first to create such an
>> exotic real mode, it is very rarely used and in fact breaks on
>> some early Cyrix processors). 
 
> It's also rather a pointless mode, since it's not compatible with
> other real-mode code, which means you might as well run in 32-bit
> protected mode. 

FASM natively does run 32-bit protected mode in all versions, except 
the DOS version FASM.EXE that runs in 32-bit "huge" real. 
I don't quite understand your comment, care to explain what you mean 
by "not compatible" with other (ordinary) RMcode ? It's fully 
interoperable. The point, I think, was to make the 16-bit DOS version 
reuse the same pre-existing 32-bit FASM source without change - which 
it does, you can look at the source.  A further point probably that 
Tomasz found fun in designing and testing the "glue" (switching back 
and forth between ordinary and huge RM for interrupt processing...)

If I'm grasping a bit of what you wanted to convey, Tomasz could have 
rewritten his source targetting DOS instead and possibly used some 
kind of (bloated) DOS extender ? Note that his approach in a way was 
opposite to that. I'm not saying which way is better, but is this 
"pointless" ? Nope.

Cheers

-- 
Czerno

On Jan 19, 10:36=A0pm, Bluemoon <nospam.cal...@nospicedham.gmail.com>
wrote:
> If you are going to develop on the ancient machine, you'll need a good
> plan on backup as it can explode anytime :D

I have several of them :-)

> For debugger, do you have any special requirement? you mentioned some
> timing sensitive code, and not much memory of target platform, it
> seems not many choice and endup with crappy debugger(in a modern
> sense). So I would not totally rely much on debugger and would
> consider also producing signals(print on screen)/traps(halt/reboots)/
> log(serial/file) to do debugging work.

Good point -- I hadn't thought of how to get debugging output.

On Jan 19, 2:50=A0pm, "wolfgang kern" <nowh...@never.at> wrote:
> My question just is: why work on and for machines which only reside
> in the museum since decades ?

For the challenge of making such an old machine do things it was never
meant to do.  I've met similar challenges and had great fun doing so.
Some of what I'll be attempting has never been done on this class of
hardware, so being "first" also has its own rewards.  Think
"demoscene".

NimbUs <nimbus@nospicedham.XXX.invalid> wrote:
>
>Ubuntu not == Linux ! Ububtu = Windows7 in diguise. Just kidding, but 
>really the Buntus  are very bloated distros oriented towards Windows 
>lusers and hardly work acceptably but on high end hardware. 

I'm not sure that's quite fair.  Regular Ubuntu uses Gnome, and I agree
completely that both Gnome and KDE are heavyweights.  However, in my view,
Xubuntu (which uses xfce) is much lighter.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts �crivait ...

> NimbUs <nimbus@nospicedham.XXX.invalid> wrote:
>>
>>Ubuntu not == Linux ! Ububtu = Windows7 in diguise. Just kidding,
>>but really the Buntus  are very bloated distros oriented towards
>>Windows lusers and hardly work acceptably but on high end
>>hardware. 
> 
> I'm not sure that's quite fair.  Regular Ubuntu uses Gnome, and I
> agree completely that both Gnome and KDE are heavyweights. 
> However, in my view, Xubuntu (which uses xfce) is much lighter.

Fair enough, I wasn't aware of Xubuntu - or rather I didn't know it 
was an official offspring of Canonical. They don't make much advocacy 
for the "other" buntus do they ? Yet I did mention choosing a lighter 
desktop/window manager that (K)ubuntu's defaults.

My personal preferred distros are SuSE 9.1 which for sentimental 
reasons I can't ditch (and serves me well), and PCLOS which is not 
bad, and does have a minimalist variant. On old computers (486) I use 
BasLinux - rather than Windows 95!- that one is *really* minimalist 
and not to be recommended to Linux newbies though.

Cheers

-- 
NimbUs

On 20 Jan 2011 17:05:24 GMT, NimbUs
<nimbus@nospicedham.XXX.invalid> wrote:

>N0Spam@daqarta.com (Bob Masta) �crivait :
>
> 
>> However, about a year ago I looked at WINE.  Daqarta *sorta*
>> ran on WINE under Ubuntu, but I never got around to tracking
>> down the problems.  Thay might have been due to my test
>> system, which was an early XP machine with 256 Meg RAM
>> (*including* integrated video).  XP ran fine with this
>> amount of RAM, but Ubuntu was slow as molasses and crashed
>> frequently.  Apparently, the days are long gone when Linux
>> would run fine on ancient systems.  <sigh>
>> 
>
>Ubuntu not == Linux ! Ububtu = Windows7 in diguise. Just kidding, but 
>really the Buntus  are very bloated distros oriented towards Windows 
>lusers and hardly work acceptably but on high end hardware. 
>
>You better try a lighter distribution - there are a handful that will 
>happily run on a 486 and 32 megabytes or even less RAM, but you don't 
>need/want to be so minimalist. OpenSUSE, Fedora, PCLOS ... are what 
>you want, and you might choose a lighter desktop than Gnome (burp!) 
>or KDE.

Thanks, I'll look into one of those lighter distros.  Do you
have recommendations for a particular lightweight desktop?
(In my Linux innocence, I think I've only heard of KDE and
Gnome.)

>> Anyway, "one of these days" I do hope to get back to testing
>> Daqarta under WINE on a system with more RAM.
>> 
>
>Doesn't your app use its own Windows *drivers* ? I'm unsure WINE is 
>able to run those (yes this is a question to the n.g.)

I'm not sure what you are asking about here.  If you mean
the Windows sound card drivers, then yes that is an issue.
As far as I can tell, each Linux user must find and load the
Linux driver for his particular sound card.  I'm not sure
how WINE maps those to Windows.  As I recall, in my tests
the sound outputs worked, but not the inputs.  I would not
be at all surprised if WINE doesn't handle the Windows Mixer
properly, if at all.  (The mixer is probably the worst of
all the Windows abominations I have encountered... and it
has gotten worse with every new release. Now it appears with
Vista/7 that Microsoft is no longer supporting it...
apparently the goal is to avoid confusing Joe Sixpack with
anything more complicated than "more volume"!)

Best regards,


Bob Masta
 
              DAQARTA  v6.00
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
          Science with your sound card!

Bob Masta �crivait ...
>>> However, about a year ago I looked at WINE.  Daqarta *sorta*
>>> ran on WINE under Ubuntu, but I never got around to tracking
>>> down the problems. 
.... ...
>>
>>You better try a lighter distribution - there are a handful that
>>will happily run on a 486 and 32 megabytes or even less RAM, but
>>you don't need/want to be so minimalist. OpenSUSE, Fedora, PCLOS
>>... are what you want, and you might choose a lighter desktop than
>>Gnome (burp!) or KDE.
> 
> Thanks, I'll look into one of those lighter distros.  Do you
> have recommendations for a particular lightweight desktop?
> (In my Linux innocence, I think I've only heard of KDE and
> Gnome.)

There is a choice of several light, but adequate, desktops and 
windows managers but I haste to admit I'm not the Linux expert but a 
simple user lacking the breadth of experience necessary to answer the 
pecific question. I saw Tim Roberts mentioning Xfce in this same 
thread. Baslinux is using twm (IIRC) which is extremely minimal but 
gets the job done. It's one of the charms of Linux, interested users 
do get a lot of choice, versus MS Windows giving you none (it's User 
+ GDI, take or leave). 

......

>>Doesn't your app use its own Windows *drivers* ? I'm unsure WINE
>>is able to run those (yes this is a question to the n.g.)
> 
> I'm not sure what you are asking about here.  If you mean
> the Windows sound card drivers, then yes that is an issue.

Hmm, sorry I didn't express myself aptly, I was trying to ask whether 
your Apps come with their own kernel mode drivers. If it was the 
case, then I don't think they could run in WINE, out of the box, 
you'd have to provide equivalent Linux drivers.

> As far as I can tell, each Linux user must find and load the
> Linux driver for his particular sound card.  I'm not sure
> how WINE maps those to Windows.  As I recall, in my tests
> the sound outputs worked, but not the inputs. 

In my limited experience, things have got much easier going in recent  
Linuces. Again I'm not the expert, leaving your questions to be 
addressed by the more competent instead...

> I would not
> be at all surprised if WINE doesn't handle the Windows Mixer
> properly, if at all.  (The mixer is probably the worst of
> all the Windows abominations I have encountered... and it
> has gotten worse with every new release. Now it appears with
> Vista/7 that Microsoft is no longer supporting it...
> apparently the goal is to avoid confusing Joe Sixpack with
> anything more complicated than "more volume"!)

LOL !

-- 
NimbUs

"Bob Masta" <N0Spam@daqarta.com> wrote in message 
news:4d398ccd.299689@news.eternal-september.org...
>
> Thanks, I'll look into one of those lighter distros.  Do you
> have recommendations for a particular lightweight desktop?
> (In my Linux innocence, I think I've only heard of KDE and
> Gnome.)
>

I once found Puppy Linux to be decent for ASM work.  However, recently doing 
a "small linux distro" search, I've discovered other gems that also look 
promising.

I think your biggest hurdle will be deciding how to approach the GUI part of 
the application.  The X API certainly holds no candle to the Win32 API 
goodies.  You will have to build all components from scratch.  Either that, 
or learn how to call the C++ flavored GTK2 or QT libraries from ASM.  :(

Also, speaking of Ubuntu and of X, one should mention that Ubuntu is moving 
away from X in favor of some new-fangled display technology.  Linux is 
certainly not an easy target from the ASM perspective. :(

Nathan.

On Fri, 21 Jan 2011 22:16:40 -0500
"Nathan Baker" <nathancbaker@nospicedham.gmail.com> wrote:
[snip]
> I think your biggest hurdle will be deciding how to approach the GUI
> part of the application.  The X API certainly holds no candle to the
> Win32 API goodies.  You will have to build all components from
> scratch.  Either that, or learn how to call the C++ flavored GTK2 or
> QT libraries from ASM.  :(

GTK+ is actually written entirely in C and exposes only C functions.
Its design is a bit object-oriented, but not its language choice.

Chris

On 21 Jan 2011 17:23:02 GMT, NimbUs
<nimbus@nospicedham.XXX.invalid> wrote:

<snip>
>
>>>Doesn't your app use its own Windows *drivers* ? I'm unsure WINE
>>>is able to run those (yes this is a question to the n.g.)
>> 
>> I'm not sure what you are asking about here.  If you mean
>> the Windows sound card drivers, then yes that is an issue.
>
>Hmm, sorry I didn't express myself aptly, I was trying to ask whether 
>your Apps come with their own kernel mode drivers. If it was the 
>case, then I don't think they could run in WINE, out of the box, 
>you'd have to provide equivalent Linux drivers.

No, I haven't found a need for custom kernel mode drivers
with Windows.  I think those would only be needed if I
wanted to support a different sort of device than a standard
Windows sound card.  There are in fact some "high end" sound
cards that supply their own non-standard drivers, which I
don't support at present (since they have their own APIs and
don't directly replace the standard drivers).  There are
also lots of lab-type data acquisition boards that I
likewise don't support... wildly different APIs.  

The standard sound card interface is/was actually one of the
big virtues of Windows for me.  In the DOS days, every sound
card was different, with no standard driver interface.  I
had to contact each manufacturer and try to pry loose enough
info about ports and DMA usage, etc, to write a driver.  (I
was only successful with Sound Blaster and a couple others.)
Lab-type boards always supplied this info, but getting a
board to test on involved big $$$.  I was spending most of
my time and money on writing and testing my custom drivers,
instead of improving the core app.  

So, even though Windows involved a steep learning curve, and
meant that I had to give up all kinds of timing control (due
to multi-tasking), it was *sooo* nice not to have to deal
with custom drivers!

Best regards,


Bob Masta
 
              DAQARTA  v6.00
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
          Science with your sound card!

Nathan Baker in discussion with Bob Masta:

....
while you're at "WHINE", assume I once may decide to emulate
windoze in a way to run just games and a few other applications ...

Which API-functions (let's say just five hundred for now)
apart from vendor specific hardware drivers would I need to
support/convert for making it run at all ??

Is there any listing of most used windoze-API available ?
I for sure wont study all ~20000 known/50000 hidden M$-functions,
because most of them are just there by coincidence or remained
from previous bugs anyway.
__
wolfgang

btw Bob, what hardware do you use for data-aquisition ?
before 1997 I made a lot of things like buffered parallel opto-coupled
I/O up to 2048 pins myself, after this I used National-Instruments
ISA-cards and finally their quite expensive PCI-variants.
I might think over again to create my own Video-aquisition boards
because the price/performance ratio from third party seems sunken.

On Jan 22, 10:59=A0am, "wolfgang kern" <nowh...@never.at> wrote:
>
> Which API-functions (let's say just five hundred for now)
> apart from vendor specific hardware drivers would I need to
> support/convert for making it run at all ??
>
> Is there any listing of most used windoze-API available ?
> I for sure wont study all ~20000 known/50000 hidden M$-functions,
> because most of them are just there by coincidence or remained
> from previous bugs anyway.

The core functions are the ones in the Kernel, GDI, and User DLLs.
The following was snagged from the NasmX project:

http://www.inspiretomorrow.net/win32/kernel32.inc
http://www.inspiretomorrow.net/win32/gdi32.inc
http://www.inspiretomorrow.net/win32/user32.inc

Nathan.

Nathan replied:

> Which API-functions (let's say just five hundred for now)
> apart from vendor specific hardware drivers would I need to
> support/convert for making it run at all ??

> Is there any listing of most used windoze-API available ?
> I for sure wont study all ~20000 known/50000 hidden M$-functions,
> because most of them are just there by coincidence or remained
> from previous bugs anyway.

|The core functions are the ones in the Kernel, GDI, and User DLLs.
|The following was snagged from the NasmX project:

| http://www.inspiretomorrow.net/win32/kernel32.inc
| http://www.inspiretomorrow.net/win32/gdi32.inc
| http://www.inspiretomorrow.net/win32/user32.inc

Thanks Nate,
gdi-APIs may mainly use directX-drivers from graphic vendors
anyway, so only kernel and user would need special adaption.
Still a lot ..., but perhaps worth to give it a try.
If I just had a second lifespan to spend for all my ideas :)
__
wolfgang

On Jan 22, 10:59=A0am, "wolfgang kern" <nowh...@never.at> wrote:
> Nathan Baker in discussion with Bob Masta:
>
> ...
> while you're at "WHINE",
>

I wasn't complaining.  I was giving a warning.  When I see someone
being led into a "hell pit", I do not stand in their way.  But I will
attempt to remove their "blindfold" just a bit... so that they'll have
a better chance at escape.  :)

Nathan.

On Sat, 22 Jan 2011 16:59:07 +0100, "wolfgang kern"
<nowhere@never.at> wrote:

>
>Nathan Baker in discussion with Bob Masta:
>
>...
>while you're at "WHINE", assume I once may decide to emulate
>windoze in a way to run just games and a few other applications ...
>
>Which API-functions (let's say just five hundred for now)
>apart from vendor specific hardware drivers would I need to
>support/convert for making it run at all ??
>
>Is there any listing of most used windoze-API available ?
>I for sure wont study all ~20000 known/50000 hidden M$-functions,
>because most of them are just there by coincidence or remained
>from previous bugs anyway.
>__

I'm not sure what you are looking for here.  WINE allows a
Windows app to run under Linux, but it sounds like you are
asking for the opposite.

If you are looking for basic Windows functions that WINE
supports, I'd suggest you stick to Win9x only.  Almost all
of these are still supported in later Windows versions, and
my understanding is that WINE support for the later stuff is
spotty anyway.

The beauty of sticking with Win9x-level APIs is that you can
get the entire API Help file (old-style WinHelp, for XP or
earlier) to keep on your development system, without having
to go on-line for MSDN. Search for Win32Hlp to get this
package.

Also, whether you are a MASM fan or not, there are some nice
Windows assembly tutorials that come with the MASM32
package. (They are probably available on-line as well.)
These are great because they have the actual code, which you
can tweak and re-assemble to see what happens.

>btw Bob, what hardware do you use for data-aquisition ?

Only Windows sound cards, nowadays.

>before 1997 I made a lot of things like buffered parallel opto-coupled
>I/O up to 2048 pins myself, after this I used National-Instruments
>ISA-cards and finally their quite expensive PCI-variants.
>I might think over again to create my own Video-aquisition boards
>because the price/performance ratio from third party seems sunken.

Personally, I'd shy away from any of these "fast" projects.
The layouts are too critical and they are too hard to
troubleshoot.  Plus, I don't think it will be too easy to
beat the commercial products, even if you don't count your
time for anything...  there are "exotic" parts (fast A/Ds,
etc) that you have to buy at the one-piece prices, not to
mention the cost (or labor) of getting boards made.  Not for
me.

But I still do "slow" projects.  For my Daqarta for Windows
I've got projects to allow DC variables (like temperature or
pressure, or just plain DC voltage measurements) to be
handled via the sound card, which only accepts AC.  One
approach is to convert DC to frequency and measure that,
which is a fairly simple board.  Then I've got a direct mod
to the sound card, which can handle DC up to the original
card frequency limit.  I've also got a "trick" modulator
that can be used ahead of a normal sound card, which (when
used with Daqarta) allows you to record *signed* DC up to
several hundred Hz.  (See "DC Measurements" under "Features"
on the Daqarta home page, or direct to 
<http://www.daqarta.com/dw_ggmm.htm> for full schematics,
theory, and board layouts.)

Best regards,


Bob Masta
 
              DAQARTA  v6.00
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
          Science with your sound card!

"Christopher Head" <chead@nospicedham.is.invalid> wrote in message 
news:20110121220543.6b14153a@is.invalid...
> On Fri, 21 Jan 2011 22:16:40 -0500
> "Nathan Baker" <nathancbaker@nospicedham.gmail.com> wrote:
> [snip]
>> I think your biggest hurdle will be deciding how to approach the GUI
>> part of the application.  The X API certainly holds no candle to the
>> Win32 API goodies.  You will have to build all components from
>> scratch.  Either that, or learn how to call the C++ flavored GTK2 or
>> QT libraries from ASM.  :(
>
> GTK+ is actually written entirely in C and exposes only C functions.
> Its design is a bit object-oriented, but not its language choice.
>

Thanks for this correction.  I've taken a second look at GTK and decided it 
is an acceptable framework for ASM-based GUI apps.

Nathan.

Bob Masta replied>>

>>Nathan Baker in discussion with Bob Masta:
>>...
>>while you're at "WHINE", assume I once may decide to emulate
>>windoze in a way to run just games and a few other applications ...

>>Which API-functions (let's say just five hundred for now)
>>apart from vendor specific hardware drivers would I need to
>>support/convert for making it run at all ??

>>Is there any listing of most used windoze-API available ?
>>I for sure wont study all ~20000 known/50000 hidden M$-functions,
>>because most of them are just there by coincidence or remained
>>from previous bugs anyway.

> I'm not sure what you are looking for here.  WINE allows a
> Windows app to run under Linux, but it sounds like you are
> asking for the opposite.

No, I just think about to add an executer onto my Os which
should interprete and convert API-calls into KESYS-functions.
At the moment I only emulate a few 16-bit DOS functions like
himem.sys and FAT-12/16/32 file-functions to allow a few
DOS-programs to run under control of KESYS.

> If you are looking for basic Windows functions that WINE
> supports, I'd suggest you stick to Win9x only.  Almost all
> of these are still supported in later Windows versions, and
> my understanding is that WINE support for the later stuff is
> spotty anyway.

> The beauty of sticking with Win9x-level APIs is that you can
> get the entire API Help file (old-style WinHelp, for XP or
> earlier) to keep on your development system, without having
> to go on-line for MSDN. Search for Win32Hlp to get this
> package.

Yeah, I have this old help-file. Programs which are written
later than win98se may show many DirectX-calls beside other
newer stuff.

> Also, whether you are a MASM fan or not, there are some nice
> Windows assembly tutorials that come with the MASM32
> package. (They are probably available on-line as well.)
> These are great because they have the actual code, which you
> can tweak and re-assemble to see what happens.

Oh yes, I already got a huge collection of examples from
Iczelion, 'Skull'(Test Department), RosAsm, MASM32 and more ...

>>btw Bob, what hardware do you use for data-aquisition ?

> Only Windows sound cards, nowadays.

>>before 1997 I made a lot of things like buffered parallel opto-coupled
>>I/O up to 2048 pins myself, after this I used National-Instruments
>>ISA-cards and finally their quite expensive PCI-variants.
>>I might think over again to create my own Video-aquisition boards
>>because the price/performance ratio from third party seems sunken.

> Personally, I'd shy away from any of these "fast" projects.
> The layouts are too critical and they are too hard to
> troubleshoot.  Plus, I don't think it will be too easy to
> beat the commercial products, even if you don't count your
> time for anything...  there are "exotic" parts (fast A/Ds,
> etc) that you have to buy at the one-piece prices, not to
> mention the cost (or labor) of getting boards made.  Not for
> me.

Whenever I decide for a brand or another pcb-producer it usually
affects the next 20..50 units. So I really double cross-check
hardware-solutions more than twice ...
A couple of hours spent on thinking about future productions
saved me in the past from be owned by bankers :)
I hope to can keep it that way.

> But I still do "slow" projects.  For my Daqarta for Windows
> I've got projects to allow DC variables (like temperature or
> pressure, or just plain DC voltage measurements) to be
> handled via the sound card, which only accepts AC.  One
> approach is to convert DC to frequency and measure that,
> which is a fairly simple board.  Then I've got a direct mod
> to the sound card, which can handle DC up to the original
> card frequency limit.  I've also got a "trick" modulator
> that can be used ahead of a normal sound card, which (when
> used with Daqarta) allows you to record *signed* DC up to
> several hundred Hz.  (See "DC Measurements" under "Features"
> on the Daqarta home page, or direct to
> <http://www.daqarta.com/dw_ggmm.htm> for full schematics,
> theory, and board layouts.)

Interesting that your harware approach is quite similar to mine :)
the difference is that I (ab)used digital TV inputs on graphic-cards
and my speed-limit were given by the RAM-bus max. 50 MHz bandwith
on a 'true' Local Bus then.

Thanks for the insight into your business, sound good work anyway.
__
wolfgang

On Jan 17, 11:49=A0am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:
> As a hobby exercise, I will be developing a somewhat large program for
> a very ancient 808x computer with limited RAM (128KB). =A0So far, most
> of my projects in this realm have been in Turbo Pascal 7.0 with a
> mixture of inline asm code and linked assembler .objs, all authored by
> me. =A0I would like to take the final plunge into 100% asm-developed
> programming, which I feel will not only give me the best bang for the
> buck in terms of size (important to this memory-limited machine) but
> also because I feel that it will be a lot of fun.
>
> My only question is: =A0What assembler should I start with? =A0My
> requirements are:
>
> - Able to compile 16-bit code while running on 16-bit processor (ie. a
> 32-bit build of NASM does not help me)
> - Able to generate symbolic debugger output and/or otherwise work with
> a debugger
> - Able to create and maintain libraries of code. =A0Overlay management a
> plus (see below)
> - Decent documentation must exist for these in any form (remember, I'm
> new to the process of 100% asm projects). =A0I have the ability to
> obtain packages/manuals/books (I already own a complete package of
> tasm 4.0, for example)
>
> As far as I can tell, my choices are:
>
> - masm (not sure which version) + debug.com
> - a86 + d86
> - tasm (3.2? 4.0? not sure which is best version) + turbo debugger
> - nasm + ??
>
> My development environment is the same speed and processor as my
> target environment, but with 640KB RAM and a hard disk, so that makes
> things easier.
>
> An additional wrinkle is that I would eventually like to deploy this
> program as a bootable disk -- meaning, I was thinking of writing my
> own custom floppy disk boot loader that would load code segments into
> memory and execute them. =A0I was planning on writing everything as .com
> files to test/debug them from DOS, then after it's all working, change
> how they're loaded and executed.
>
> I would be interested to hear any and all suggestions, criticism,
> comments, etc. =A0Subjective opinions welcome, even if to tell me I
> should switch to C or something. =A0a86 appeals to be because of its
> simplicity, but I have no experience with it and the debugger appears
> cumbersome at first glance. =A0tasm appeals to be because I am familiar
> with turbo debugger; not sure if I should use ideal mode or not. =A0nasm
> appeals to be because I would be using a modern, supported assembler,
> but I don't know what my debugging options are. =A0Any direction is
> appreciated!

Once upon a time, I bread-boarded a Z80 computer, with a SCC.
The SCC had two ports. The first was used for a terminal.
The second, later, was used as a 'disk drive' - with a linux
machine acting as the 'disk drive'.

I used an EEPROM to boot, which simplified things a bit, but the
general process would be about the same, I think....

I also had 3 blinken lights.

So the process was:
0)
 Make one light blink.
 Make two lights alternate.
 Run recognizable patterns on all three.
Now, I chose
 STEADY GREEN =3D GOOD
 YELLOW =3D BUSY
 BLINKING RED =3D ERROR
 BLINKING GREEN =3D FINISHED
[ at this point, I used blinkenlights to test loading
programs into RAM and swapping out boot EEPROM for RAM]
1)
 Send a character to the terminal.
 Recieve a character from the terminal
 Echo characters from the terminal.
 Now, I could have a menu-driven 'BIOS'.
3)
 Implement X-MODEM
 Tweak menu to load X-MODEM to payload to
 specified address.
 Tweak menu to load & go specified address.
 Tweak menu to implement an ASCII dump.
[ in hindsight, I should have developed the
ASCII dump BEFORE load & go....]

After all of that, testing various CP/M BIOSes
and builds (diffrent feature sets from open-source
clones) became a breeze, as was developing the
Linux-based serial disk drive....

In short: make use of blinkenlights and serial port(s)
if you have them. Mercy upon you if you don't....

HTH,
  Tarkin

On 01/20/2011 09:37 AM, Czerno wrote:
> 
> FASM natively does run 32-bit protected mode in all versions, except 
> the DOS version FASM.EXE that runs in 32-bit "huge" real. 
> I don't quite understand your comment, care to explain what you mean 
> by "not compatible" with other (ordinary) RMcode ? It's fully 
> interoperable. The point, I think, was to make the 16-bit DOS version 
> reuse the same pre-existing 32-bit FASM source without change - which 
> it does, you can look at the source.  A further point probably that 
> Tomasz found fun in designing and testing the "glue" (switching back 
> and forth between ordinary and huge RM for interrupt processing...)
> 
> If I'm grasping a bit of what you wanted to convey, Tomasz could have 
> rewritten his source targetting DOS instead and possibly used some 
> kind of (bloated) DOS extender ? Note that his approach in a way was 
> opposite to that. I'm not saying which way is better, but is this 
> "pointless" ? Nope.
> 

Since you have to switch anyway, you could just have used flat protected
mode.

	-hpa

On Fri, 21 Jan 2011 07:33:11 -0000, Tim Roberts =20
<timr@nospicedham.probo.com> wrote:

> NimbUs <nimbus@nospicedham.XXX.invalid> wrote:
>>
>> Ubuntu not =3D=3D Linux ! Ububtu =3D Windows7 in diguise. Just kidding=
, but
>> really the Buntus  are very bloated distros oriented towards Windows
>> lusers and hardly work acceptably but on high end hardware.
>
> I'm not sure that's quite fair.  Regular Ubuntu uses Gnome, and I agree
> completely that both Gnome and KDE are heavyweights.  However, in my =20
> view,
> Xubuntu (which uses xfce) is much lighter.


I've recently (hello asm types!) found xPud, and would rteally like to se=
e =20
it develop again after a flurry in the Spring last year, and a bit of new=
 =20
stuff at the end.

for m, it seems like a light kiosk browser os

--=20
"Nuns! NUNS! Reverse! Reverse!"

"H. Peter Anvin" <hpa@nospicedham.zytor.com> �crivait

>> FASM natively does run 32-bit protected mode in all versions,
>> except the DOS version FASM.EXE that runs in 32-bit "huge" real. 
>> I don't quite understand your comment, care to explain what you
>> mean by "not compatible" with other (ordinary) RMcode ? It's
>> fully interoperable. The point, I think, was to make the 16-bit
>> DOS version reuse the same pre-existing 32-bit FASM source

> Since you have to switch anyway, you could just have used flat
> protected mode.

You need something to process system calls don't you ? File system and 
the like, that doesn't come from thin air by magics. Either he'd use PM 
plus a DOS extender, or what he did, huge real and... DOS itself.

I didn't want to start any deep analysis and still don't. You'd have to 
ask Tomasz himself for his reasons. In fact he has answered similar 
questions sometimes, and one reason is that Huge Real (it's not how 
Tomasz calls the mode BTW, I borrowed the name from Ralf Brown who took 
it from Helix) - Huge Real mode was measurably faster at least until 
and including Pentium. Maybe it still is...

-- 
Czerno

On 02/02/2011 09:39 AM, Czerno wrote:
> "H. Peter Anvin" <hpa@nospicedham.zytor.com> =C3=A9crivait
>=20
>>> FASM natively does run 32-bit protected mode in all versions,
>>> except the DOS version FASM.EXE that runs in 32-bit "huge" real.=20
>>> I don't quite understand your comment, care to explain what you
>>> mean by "not compatible" with other (ordinary) RMcode ? It's
>>> fully interoperable. The point, I think, was to make the 16-bit
>>> DOS version reuse the same pre-existing 32-bit FASM source
>=20
>> Since you have to switch anyway, you could just have used flat
>> protected mode.
>=20
> You need something to process system calls don't you ? File system and=20
> the like, that doesn't come from thin air by magics. Either he'd use PM=
=20
> plus a DOS extender, or what he did, huge real and... DOS itself.
>=20
> I didn't want to start any deep analysis and still don't. You'd have to=
=20
> ask Tomasz himself for his reasons. In fact he has answered similar=20
> questions sometimes, and one reason is that Huge Real (it's not how=20
> Tomasz calls the mode BTW, I borrowed the name from Ralf Brown who took=
=20
> it from Helix) - Huge Real mode was measurably faster at least until=20
> and including Pentium. Maybe it still is...
>=20

32-bit "Huge Real" mode is not compatible with DOS, BIOS or anything
like that.  You need to be in 16-bit Real or Big Real Mode for that.  To
switch between the two you have to go into and out of protected mode,
instead of just switching once.

	-hpa

"H. Peter Anvin" <hpa@nospicedham.zytor.com> wrote : 
> Czerno wrote
  
>> it from Helix) - Huge Real mode was measurably faster at least
>> until and including Pentium. Maybe it still is...
 
> 32-bit "Huge Real" mode is not compatible with DOS, BIOS or
> anything like that.  You need to be in 16-bit Real or Big Real
> Mode for that.  To switch between the two you have to go into and
> out of protected mode, instead of just switching once.

Yes and no. A trifle. Setting "CR0.PE":=1 for the sole the purpose of 
setting segment attributes and immediately going back to real mode 
(alterning between regular or huge)it when this is done is not what I 
call "going into protected mode" personally. It's a mere 
technicality, no different than the (real mode) BIOS setting up 
segments for "Big Real". 

Contrary to your view of it, I'd say Huge Real /is/  compatible with 
plain Real Mode, in much the same way than Virtual 86 Mode is 
compatible w/ Protected Mode, for example.

Whatever the definitions, we both know how things work in gory 
details, I suppose; then names and classifications overall are a 
matter of personal taste in my opinion.


-- 
Czerno

On 02/03/2011 09:36 AM, Czerno wrote:
> 
> Contrary to your view of it, I'd say Huge Real /is/  compatible with 
> plain Real Mode, in much the same way than Virtual 86 Mode is 
> compatible w/ Protected Mode, for example.
> 

It is not compatible in the sense that the opcodes have different
meaning.  You cannot execute the DOS kernel in huge real mode.

	-hpa

"H. Peter Anvin" <hpa@nospicedham.zytor.com> wrote:
>
>On 02/03/2011 09:36 AM, Czerno wrote:
>> 
>> Contrary to your view of it, I'd say Huge Real /is/  compatible with 
>> plain Real Mode, in much the same way than Virtual 86 Mode is 
>> compatible w/ Protected Mode, for example.
>
>It is not compatible in the sense that the opcodes have different
>meaning.

That's not true.  The opcodes have exactly the same meaning.  The only real
difference is that segment addresses don't wrap in the same way.

>You cannot execute the DOS kernel in huge real mode.

That's true, because of address wrapping.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts said: 

> "H. Peter Anvin" <hpa@nospicedham.zytor.com> wrote:

>>It is not compatible in the sense that the opcodes have different
>>meaning.
 
> That's not true.  The opcodes have exactly the same meaning.  The
> only real difference is that segment addresses don't wrap in the
> same way. 

>>You cannot execute the DOS kernel in huge real mode.
 
> That's true, because of address wrapping.

Uh, no, I mean, not just address wrapping, also instructions default 
operand and address sizes being inverted. I stand with Hpa here ;=)


-- 
Ninho