Pseudo random numbers / DOS / memory, etc....

[Thomas Jensen]

Hi

I am a newbie, and I have made a program that generates some pseudo
random numbers, and print how many times each number come out.

I have two problems;

1. I am not sure the dynamic memory allocation is correct. I sometimes
get errors, sometimes not. Specially the free-mem part could be wrong, I
think. Is it correct what I do - pushing the address returned in ax by
function 48h/int21h and popping it to es in function 49h/int21h?

2. I have made my own implementation of "X = (XA+C) mod M", a Linear
Congruential Generator, but it doesn't really work well. The could very
well be something very wrong, I am only a newbie... ;-) and it is first
time I ever use dwords, so ... well, ... ;-)

I use some code from Tom Swans book about TASM to write strings, get
commandline parameters, etc, so just ignore that. Fell free to comment on
any part of the code, but I hope also to get some tips on the two issues
- memory and the fact that get_random4 is with some numbers.

And, it is written for a 8086 class computer running ms-dos 3.3, so
that's why I don't use 32 bit registers, etc.

Okay, the code:

=========== code start ================================

%TITLE "rs7.asm"

IDEAL
MODEL small
STACK 256

NUMTESTS = 10000

DATASEG
exCode DB 0
str_syntax DB ??FILENAME, "min max", 0
str_error1 DB "Error freeing unused mem", 0
str_error2 DB "Error allocating mem", 0
str_error3 DB "Error freeing allocated mem", 0
str_result DB 10 DUP(0)

UDATASEG
rand_result DW ?
rand_min DW ?
rand_max DW ?

CODESEG

;----> From PARAMS.OBJ
EXTRN ParamCount:Proc, GetParams:Proc, GetOneParam:Proc

EXTRN AscToBin:Proc, NumToAscii:Proc
EXTRN NewLine:Proc, StrWrite:Proc

;----> From RAND4.OBJ
EXTRN seed_random4:proc, get_random4:proc


;=========================================================================
Start:

;-------------------------------------------------------------------------
;----> release unused memory
;-------------------------------------------------------------------------

mov bx, es
mov ax, ss
sub ax, bx

mov cx, sp ;convert SP to paragraphs
shr cx, 4
inc cx
add ax, cx ;<- and then add here

mov bx, ax ;Release unused memory
mov ah, 4Ah
int 21h
jnc @@L1

mov di, offset str_error1
call StrWrite
jmp Exit

;-------------------------------------------------------------------------
;---->
;-------------------------------------------------------------------------

@@L1:
mov ax, @data ; Set ax to data segment
mov es, ax ; Set es to data segment
call GetParams ; Get parameters with ds = PSP
; ds is set from getparams

;-------------------------------------------------------------------------
;----> get cmdline parameters
;-------------------------------------------------------------------------

call ParamCount ; Get number of parameters
cmp dx, 2
je @@L3

mov di, offset str_syntax
call StrWrite
jmp Exit
@@L3:
xor cx, cx
call GetOneParam
call AscToBin
mov [rand_min], ax
inc cx

call GetOneParam
call AscToBin
mov [rand_max], ax

inc [rand_max]


;-------------------------------------------------------------------------
;----> find diff between min and max
;-------------------------------------------------------------------------

mov bx, [rand_max]
sub bx, [rand_min] ; number of words to allocate
shr bx, 3 ; number of paragraphs to allocate
inc bx

;-------------------------------------------------------------------------
;----> allocate memory
;-------------------------------------------------------------------------

mov ah, 48h ; size in bx
int 21h
jnc @@L5

mov di, offset str_error2
call StrWrite
jmp Exit

@@L5:

mov si, ax ; address of allocated memory
mov di, ax
push ax ; save - pop when freeing mem

;-------------------------------------------------------------------------
;----> clear allocated mem
;-------------------------------------------------------------------------

mov ax, 0
shl bx, 4
mov cx, bx
rep stosw ; write to es:di


;-------------------------------------------------------------------------
;----> start generating random numbers
;-------------------------------------------------------------------------

mov cx, NUMTESTS
call seed_random4

@@L10:
push cx
mov bx, [rand_max]
mov cx, [rand_min]

call get_random4

mov bx, dx
sub bx, [rand_min]
shl bx, 1

inc [word bx + si]
pop cx

loop @@L10


;-------------------------------------------------------------------------
;----> Write result to screen
;-------------------------------------------------------------------------

mov cx, [rand_max]
sub cx, [rand_min]
xor bx, bx

@@L20:
mov ax, [word bx + si]
push bx
push cx
mov bx, 10 ; prepare for NumToAscii
mov cx, 1
mov di, offset str_result
call NumToAscii
call StrWrite ; write to screen
call NewLine
pop cx
pop bx
add bx, 2
loop @@L20


;-------------------------------------------------------------------------
;----> free allocated memory
;-------------------------------------------------------------------------

mov ah, 49h
pop dx
mov es, dx
int 21h
jnc Exit

mov di, offset str_error3
call StrWrite


;-------------------------------------------------------------------------
;
;-------------------------------------------------------------------------
Exit:
mov ah, 04Ch ; DOS function: Exit program
mov al, [exCode] ; Return exit code value
int 21h ; Call DOS. Terminate program


END Start ; End of program / entry point


=============== code end ===================================


================ code start ===================================

%TITLE "rand4.asm"
IDEAL
MODEL small

DATASEG
num_a DD 1103515245
num_c DW 12345

UDATASEG

dd_result DD ?
rand_seed4 DW ?


CODESEG

PUBLIC seed_random4, get_random4

;------------------------------------------------------------------------
;
; GET_RANDOM
;
; x = (xa + c) mod 32768
;
; expect: bx = max
; cx = min
;
; return: dx = result
;
;------------------------------------------------------------------------

PROC get_random4

@@L10:
push cx
push bx

mov ax, [word num_a + 2] ; high word
mul [rand_seed4]

mov [word dd_result + 2], dx ; high word of result
mov [word dd_result], ax ; low word

mov ax, [word num_a] ; low word
mul [rand_seed4]

add [word dd_result + 2], dx ; add high word of result
add [word dd_result], ax ; add low word of result
adc [word dd_result + 2], 0 ; add carry

mov ax, [num_c]
add [word dd_result], ax ; + c

and [word dd_result], 7FFFh ; mod 32768

mov ax, [word dd_result]

or ax, ax
jnz @@L20
call seed_random4
jmp @@L10

@@L20:
mov [rand_seed4], ax ; 0 <= x < 32768

pop bx ; max
pop cx ; min

xor dx, dx ;
div bx
cmp dx, cx

jb @@L10 ; dx must be larger than min

@@L99:

ret

ENDP get_random4

;------------------------------------------------------------------------
;
; SEED_RANDOM
;
; return: seed in ax
;------------------------------------------------------------------------

PROC seed_random4

push bx
push cx
push dx
@@L10:
mov ah, 2Ch ;
int 21h ;

or dx, dx
jz @@L10

mov [rand_seed4], dx

pop dx
pop cx
pop bx

@@L99:
ret

ENDP seed_random4

END

============ code end ==================================



--
Thomas Jensen, Denmark

[Bjarni Juliusson]

This isn't really going to answer any of your questions, but I see this
all the time and I have to ask:

Why do so many people still run MSDOS on their computers?

Also, 8086? That's a 35 year old processor you have there. I'd like to
encourage you to learn about assembly language programming, but I have
to say my best advice would be to forget about the 8086, and enter into
the 1980s and the wonderful world of the 80386 and the wide variety of
operating systems avalilable for it. Why make it hard on yourself?

As for MSDOS, I think you will find a proper modern operating system
gets in your way a lot less, and especially the various Un*x flavours
are really comfortable for us programmers! Try it!

Also, of course, it's a matter of learning what's useful - if you start
with 8086/MSDOS, you will then have to partially relearn the way you
program to be able to write programs that are really useful on modern
computers and operating systems.

I started with MSDOS, writing 16-bit assembly code in the mid 1990s,
when those things were on their way out, but once I tried 32-bit
assembly on Linux, I realised just how difficult MSDOS and 16-bit
programming had been and how counterproductive it was to continue doing
it. I haven't looked back.


Bjarni
--

INFORMATION WANTS TO BE FREE

[Tim Roberts]

Thomas Jensen <liane...@nospicedham.sejlgarnet.dk> wrote:
>
>2. I have made my own implementation of "X = (XA+C) mod M", a Linear
>Congruential Generator, but it doesn't really work well. The could very
>well be something very wrong, I am only a newbie... ;-) and it is first
>time I ever use dwords, so ... well, ... ;-)

For curiousity, where did the values for A, C and M here? It is very easy
to choose values that do NOT produce random numbers.

One of your problems is in the code that converts from the range [0,32767]
to the range [cx,bx]. You are actually trying to convert to the range
[0,bx] and then throwing out values below cx. That's not right.

As a general rule, to convert a value K from the range [a,b] to the range
[c,d], you need:

(K - a) x (d - c)
c + -----------------
(b - a)

In your case, a is 0, and b is 32767. So:

@@L20:
mov [rand_seed4], ax ; 0 <= x < 32768

pop bx ; max
pop cx ; min

push cx
sub bx, cx ; desired range
mul bx
mov ax, 32767
div ax
pop cx
add ax, cx
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Hugh Aguilar]

On Oct 30, 3:23 pm, Bjarni Juliusson <bja...@nospicedham.update.uu.se>
wrote:

> This isn't really going to answer any of your questions, but I see this
> all the time and I have to ask:
>
> Why do so many people still run MSDOS on their computers?
>
> Also, 8086? That's a 35 year old processor you have there. I'd like to
> encourage you to learn about assembly language programming, but I have
> to say my best advice would be to forget about the 8086, and enter into
> the 1980s and the wonderful world of the 80386 and the wide variety of
> operating systems avalilable for it. Why make it hard on yourself?

I agree, the 16-bit x86 is very much a CISC --- there are a lot of
special-purpose registers --- we have fancy instructions that work
with only certain registers. That is not the way programming is done
nowadays though --- the 32-bit x86 supports those CISC instructions so
legacy code will continue working, but they generally aren't used for
modern programming.

Most likely the guy is programming the 16-bit x86 under MS-DOS because
he has one of the many many books available for it. But what books are
available for 32-bit x86? I have read Michael Abrash's second book,
which covered this. I am also now reading "The Art of Assembly" by
Randall Hyde. What else is there?

Also, I read "Professional Assembly Programming" by Richard Blum. It
didn't discuss macros or EQU at all, and I went away believing that
GAS didn't have this stuff, although I now know that it does. Most
assembly language books are too novice-level! I looked at Jeff
Duntemann's book at the bookstore, but it seemed the same. I don't
need entire chapters explaining things like addition --- I would like
at least intermediate-level assembly language. Is there anything
available?

[Bob Masta]

On Sun, 30 Oct 2011 22:57:36 -0700 (PDT), Hugh Aguilar
<hughag...@nospicedham.yahoo.com> wrote:

>On Oct 30, 3:23=A0pm, Bjarni Juliusson <bja...@nospicedham.update.uu.se>

Probably not what you are looking for, but if you are
interested in Windows programming, MASM32 has some nice
Iczelion tutorials plus a lot of example code.

If you are interested in FPU code, Raymond Filiatreault has
"Simply FPU" , which I think also comes with MASM32.

Best regards,


Bob Masta

DAQARTA v6.02
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!

[Thomas Jensen]

On Sun, 30 Oct 2011 19:43:40 -0700, Tim Roberts wrote:


> For curiousity, where did the values for A, C and M here? It is very
> easy to choose values that do NOT produce random numbers.

I got them from K&R The Programming Language. But they are also listed
here - http://en.wikipedia.org/wiki/Linear_congruential_generator - and
thank you for asking, because I had forgot all about that web page. I
have not tried with some of the other numbers yet - will do that.

> One of your problems is in the code that converts from the range
> [0,32767] to the range [cx,bx]. You are actually trying to convert to
> the range [0,bx] and then throwing out values below cx. That's not
> right.
>

Oh, thanks. I didn't think of that, but you're right. I am not sure it
will help on the serious lack of randomness, but it will make it better.
Thanks.

The serious problem is this:

b:\>rs7 0 10
948
984
916
923
926
982
917
993
908
993
910
b:\>rs7 0 11
0
0
1609
1661
0
0
1715
1673
0
0
1676
1666
b:\>rs7 0 12
743
772
801
793
778
793
756
759
762
749
773
781
740
b:\>rs7 0 13
[ok]
b:\>rs7 0 14
[ok]
b:\>rs7 0 15
1250
1250
0
0
1250
1250
0
0
1250
1250
0
0
b:\>rs7 0 16
[ok]
b:\>rs7 0 17
[ok]
b:\>rs7 0 18
[ok]
b:\>rs7 0 19
989
1015
0
0
1001
977
0
0
1016
1040
0
0
1001
1016
0
0
993
962
0
0


Well, I will try some other numbers and see if that help, but it looks
like something is seriously wrong somewhere.



--
Thomas Jensen, Denmark

[Thomas Jensen]

On Sun, 30 Oct 2011 22:23:19 +0100, Bjarni Juliusson wrote:


> Why do so many people still run MSDOS on their computers?

Are there so many people doing that? Well, I can come up with several
possible answers, and none of them involve it is superiour.

> Also, 8086? That's a 35 year old processor you have there.

Yes. And my car is 42 and my boat is 53... ;-) I could easily get a
faster car and boat, but they have their own charme. And, I do have a
faster computer... and it has absolutlu no much charme... ;-)

>I'd like to
> encourage you to learn about assembly language programming,

Good. I would also be very disappointed if you didn't - specially here in
this group! Just kidding... ;-)

No, you have a point. There's no need to learn a lot of stuff no longer
needed in modern OS'es. 10 years ago I would have said it is good to know
the history, and it makes you understand the reason why things are as
they are today, but... No, I agree. No-one today will benefit from
learning 16bit assembly.

And I actually have a book about assembly programming in Linux - the AT&T
way with gas. It's just waiting for me taking it down from the shell and
start.

I started learning assembly in 2000, but did find it very difficult. I
bought a book by Peter Abel, and I find that book terrible. He really
makes things more difficult than it is. I also tried win32asm (or
whatever it is called) and yes, it was more simple, specially because I
had already made a few simple win32 api programs in C, so the jump was
not so big. But I never made anything other than a few demo apps. Some
years ago I bought Tom Swans book about TASM, and it is a way better book
than Peter Abel's. Now I was able to learn something, and I also bought
his book about Turbo Debugger. But there was still much to learn before I
was able to make anything useful, so I lost interest and have just picked
it up again here lately.

Right now I am playing with my Amstrad PPC640.

http://www.old-computers.com/museum/computer.asp?c=195

It boots up on a 720kb floppy with msdos 3.3, and I assemble the programs
with TASM 4.1, link with TLINK 2.0 and debug with TD 2.01. They all work
fine in the 640k environment, and are small enough to leave room for
other programs and documents on the floppies. My kind of programs... ;-)

--
Thomas Jensen, Denmark

[Markus Wichmann]

On 30.10.2011 22:23, Bjarni Juliusson wrote:
> This isn't really going to answer any of your questions, but I see this
> all the time and I have to ask:
>
> Why do so many people still run MSDOS on their computers?
>

My guess is that several people think you can't write assembly for
anything but MSDOS. The reason being they tried their old MSDOS code on
Windows or Linux and - surprise - it turned out to be unportable. Yeah,
well that's the idea behind assembly! But some people just don't get it.

Here at the Uni I'm attending we had a course for assembly language.
Well, suffice it to say that the instructor wanted me, as someone who
said he already had experience with assembly, to write up some code for
the FPU so that he has something. No FPU code in the course? Frig? OK,
then in 20 years they'll start learning about MMX or what?

All this however just served to make the other attendees think assembly
was a dying art. Well d'uh! When all you do is teaching people assembly
on grounds of software that is so old it has to be emulated nowadays,
something really isn't right!

> Also, 8086? That's a 35 year old processor you have there. I'd like to
> encourage you to learn about assembly language programming, but I have
> to say my best advice would be to forget about the 8086, and enter into
> the 1980s and the wonderful world of the 80386 and the wide variety of
> operating systems avalilable for it. Why make it hard on yourself?
>

Exactly. PLus, try to steer clear of 16-bit mode as it has several
pitfalls, like only allowing you to reference memory from certain
registers... in 16-bit mode, you can use pointers in bx, bp, si and di
and several additions of the four, but not from ax, cx, dx and sp.
Especially the latter is kind of dull when you try to allocate a
temporary variable on stack: You can push it, but you can't reference it
unless you created a stack frame beforehand. I just needed a place for
my friggin 80-bit long double to stay for a short time!

> As for MSDOS, I think you will find a proper modern operating system
> gets in your way a lot less, and especially the various Un*x flavours
> are really comfortable for us programmers! Try it!
>

Right so! Just sometimes I'd like dosbox's debugger natively for Linux,
but then again, maybe I just have to write it.

Really though, the kernel interface to MSDOS was kind of shit, but then
so is the entire 16-bit mode, with 32-bit pointers that are effectively
20 bits long (64-bit mode nearly manages to up this by introducing
64-bit pointers that are effectively 48-bits long. But at least 48 bits
of address space are impossible to fill completely nowadays at least.)

> Also, of course, it's a matter of learning what's useful - if you start
> with 8086/MSDOS, you will then have to partially relearn the way you
> program to be able to write programs that are really useful on modern
> computers and operating systems.
>
> I started with MSDOS, writing 16-bit assembly code in the mid 1990s,
> when those things were on their way out, but once I tried 32-bit
> assembly on Linux, I realised just how difficult MSDOS and 16-bit
> programming had been and how counterproductive it was to continue doing
> it. I haven't looked back.
>

I learned assembly on Win32 a while back, then switched to Linux, then
had to do some work for DOS, then embraced Linux really hard! Now I'm
writing code for Linux/AMD64 and wonder where all those MSDOS and 8086
enthusiasts lived the past 20 years or so... under a rock?

>
> Bjarni

Markus

[Nathan Baker]

"Markus Wichmann" <null...@nospicedham.gmx.net> wrote in message
news:j8b2o8-...@voyager.wichi.de.vu...

>
>> As for MSDOS, I think you will find a proper modern operating system
>> gets in your way a lot less, and especially the various Un*x flavours
>> are really comfortable for us programmers! Try it!
>>
>
> Right so! Just sometimes I'd like dosbox's debugger natively for Linux,
> but then again, maybe I just have to write it.
>

In case you haven't seen them yet, you might look at these:

http://codef00.com/projects#debugger

http://freecode.com/projects/linux_debug

Nathan.

[Rugxulo]

Hi,

On Oct 31, 12:57 am, Hugh Aguilar

<hughaguila...@nospicedham.yahoo.com> wrote:
>
> Most likely the guy is programming the 16-bit x86 under MS-DOS because
> he has one of the many many books available for it. But what books are
> available for 32-bit x86? I have read Michael Abrash's second book,
> which covered this. I am also now reading "The Art of Assembly" by
> Randall Hyde. What else is there?
>
> Also, I read "Professional Assembly Programming" by Richard Blum. It
> didn't discuss macros or EQU at all, and I went away believing that
> GAS didn't have this stuff, although I now know that it does. Most
> assembly language books are too novice-level! I looked at Jeff
> Duntemann's book at the bookstore, but it seemed the same. I don't
> need entire chapters explaining things like addition --- I would like
> at least intermediate-level assembly language. Is there anything
> available?

Just for the record, Duntemann updated his book (third edition) in
2009. It dropped DOS and now focuses exclusively on 32-bit Linux.
IIRC, he didn't have the space to go into 64-bit (yet) due to
publisher constraints.

http://www.duntemann.com/assembly.html

I don't know of any intermediate books as I'm just a lame hobbyist
who's self-taught (and still enjoys FreeDOS). ;-)

[Rugxulo]

Hi,

On Oct 31, 1:45 am, Thomas Jensen

<lianergo...@nospicedham.sejlgarnet.dk> wrote:
> On Sun, 30 Oct 2011 19:43:40 -0700, Tim Roberts wrote:
> > For curiousity, where did the values for A, C and M here?  It is very
> > easy to choose values that do NOT produce random numbers.
>
> I got them from K&R The Programming Language. But they are also listed

> here -http://en.wikipedia.org/wiki/Linear_congruential_generator- and

> thank you for asking, because I had forgot all about that web page. I
> have not tried with some of the other numbers yet - will do that.
>
> > One of your problems is in the code that converts from the range
> > [0,32767] to the range [cx,bx].  You are actually trying to convert to
> > the range [0,bx] and then throwing out values below cx.  That's not
> > right.
>
> Oh, thanks. I didn't think of that, but you're right. I am not sure it
> will help on the serious lack of randomness, but it will make it better.
> Thanks.
>
> The serious problem is this:
>

> (snip)

>
> Well, I will try some other numbers and see if that help, but it looks
> like something is seriously wrong somewhere.

I'm far from an expert in random numbers, but here's some links you
may find interesting:

= http://www.schneier.com/essay-371.html
(mostly just for citation of Elkins, for which I don't know of any
good links offhand)
= http://www.standardpascal.com/pascalfaq.html#Q.%20How%20to%20get%20random%20numbers?
("multiplicative linear congruential algorithm" ... is that the same
or slightly different??)
= http://burtleburtle.net/bob/rand/isaacafa.html
(suggested by Ben Olmstead, he's pretty smart)

[Rugxulo]

Hi,

On Oct 30, 4:23 pm, Bjarni Juliusson <bja...@nospicedham.update.uu.se>
wrote:
>

> This isn't really going to answer any of your questions, but I see this
> all the time and I have to ask:
>
> Why do so many people still run MSDOS on their computers?

They don't, they run (or used to run) Windows or OS/2 or similar which
had emulation for it. The main reason to run an OS is to run specific
apps which won't run elsewhere. Unfortunately, XP was the last "fairly
good" DOS-supporting OS, and even that is (falsely) called "old,
deprecated, crap" nowadays because it's 10 years old. Later Windows,
esp. Win64, don't support DOS well or at all. So of course, you'll
have to dual- or triple-boot DOS if you want to run old apps that
can't (easily) be recompiled.

> Also, 8086? That's a 35 year old processor you have there. I'd like to
> encourage you to learn about assembly language programming, but I have
> to say my best advice would be to forget about the 8086, and enter into
> the 1980s and the wonderful world of the 80386 and the wide variety of
> operating systems avalilable for it. Why make it hard on yourself?

Truly, if you're really intending to move to 32-bit (or 64-bit),
there's no reason (and even some disadvantages) to messing with 16-
bit. Of course, there's nothing wrong with any of it, it's just
different and somewhat incompatible. For playing around, esp. with old
books and hardware, it's fine, even recommended.

But don't get too smug, I've already seen various people call 32-bit
"deprecated", even some higher ups. It won't be long before 32-bit
compatibility is dropped just like 16-bit. And they'll be saying the
same thing, "AMD64 has been around for 10 years, it's everywhere, get
with the times!" If you think that won't happen, you're very naive.

> As for MSDOS, I think you will find a proper modern operating system
> gets in your way a lot less, and especially the various Un*x flavours
> are really comfortable for us programmers! Try it!

Doubt it. They have their own problems and aren't targeted at the same
machines. It really just depends on what you want to do and how you
want to accomplish it (what you know, tools, etc).

> Also, of course, it's a matter of learning what's useful - if you start
> with 8086/MSDOS, you will then have to partially relearn the way you
> program to be able to write programs that are really useful on modern
> computers and operating systems.
>
> I started with MSDOS, writing 16-bit assembly code in the mid 1990s,
> when those things were on their way out, but once I tried 32-bit
> assembly on Linux, I realised just how difficult MSDOS and 16-bit
> programming had been and how counterproductive it was to continue doing
> it. I haven't looked back.

You know you can write 32-bit code in DOS, right? You don't have to do
anything special (barely), it's quite easy. There is no disadvantage.
So I disagree that it's less "modern" unless you believe the (hype)
superiority of 64-bit. If you know what you're doing, you can easily
do anything in DOS, with the proper knowledge and tools. Just because
another OS has more "batteries included" doesn't make it impossible.
(And keep in mind that many, many DOS-compatible OSes exist besides MS-
DOS.)

But honestly, the big problem with DOS (IMHO) is lack of compatibility
with other OSes. DOSEMU and DOSBox and VirtualBox work mostly, but
that's not always ideal. Then again, sometimes it's easier than having
to rebuild every app for every incompatible OS.

[Hugh Aguilar]

On Oct 31, 4:52 am, Markus Wichmann <nullp...@nospicedham.gmx.net>
wrote:

> Here at the Uni I'm attending we had a course for assembly language.
> Well, suffice it to say that the instructor wanted me, as someone who
> said he already had experience with assembly, to write up some code for
> the FPU so that he has something. No FPU code in the course? Frig? OK,
> then in 20 years they'll start learning about MMX or what?
>
> All this however just served to make the other attendees think assembly
> was a dying art. Well d'uh! When all you do is teaching people assembly
> on grounds of software that is so old it has to be emulated nowadays,
> something really isn't right!

This is common. The first assembly language class I took (in 1984) was
for PDP-11 assembly. The school actually had a VAX though, and they
were just emulating the PDP-11. The instructor told us on the first
day that nothing we learned would be useful anywhere. They were just
sticking with the PDP-11 because they had all the textbooks in the
bookstore, and the instructor had his course materials. About a decade
later I took another course, this time for the 68000, which was also
dead by that time (the Mac had switched to the Power-PC, and the Amiga
and Atari-ST were defunct). The school also had a class in 6811
assembly, which was also dead. The instructor told us that this was
because Motorola was in town (Phoenix) and had donated some equipment
several years ago.

Some people go for old processors on the theory that they are simpler
than the new ones, and hence easier to learn. This usually isn't true.
For example, on the 16-bit x86 you have to learn which registers can
be used for which instructions. This is a lot to learn, and it also
complicates the program as you have to be careful to get the right
kind of data into the correct registers. On the 32-bit x86, you can
pretty much just use whatever register happens to be available. Also,
a lot of those old processors had severe register starvation --- it is
a lot easier to program a PIC24 than a 6812, for example. Of course,
upgrading from 16-bit x86 to 32-bit x86 doesn't help in this matter,
because the 32-bit x86 still has the same register starvation problem
--- Argh!

I don't think anybody should expect to learn any useful technology in
school. The most important thing that you can learn, is how to read
data-sheets --- that way you can pick up new technology quickly. Also,
learn how to figure out how a system works through experimentation, as
you often lack an up-to-date data-sheet and there really is no
documentation for the hardware. They don't really teach this though
--- they give you the information about the processor in a textbook,
which is like a gigantic and incredibly wordy data-sheet --- you are
not going to get this much hand-holding at a job!

BTW, for Mr. Jensen --- my novice package has several linear-
congruential prngs, including one (LC53) that I invented. All of this
is in Forth though, but still, you get to see the basic idea.
http://www.forth.org/novice.html
Most 16-bit LC prngs that you find, were designed for use in C and
Pascal, etc. They use tiny little numbers because C etc. don't allow
for double-sized intermediate values. When you multiply a single by a
single, the result has to be a single. Similarly, when you divide,
everything has to be the same size. In Forth however, we have "mixed-
precision" arithmetic. We have a multiplication of two singles that
produces a double product. We also have a division of a double by a
single to get a single quotient and single remainder. We actually have
a variety of ways to multiply and divide, signed and unsigned numbers
of various sizes, and using different flooring algorithms in the
division. You can do all of this in assembly language too, but you
can't do this in C.

Here is some of my LC53 stuff:

4294967291 constant rnd-unity \ 2^32 - 5
3961633963 constant rnd-mult \ 2^32 - 333333333

123456789 constant default-seed

create seed default-seed , \ must be non-zero

macro: <prng> ( rnd -- new-rnd )
rnd-mult um* rnd-unity um/mod drop ;

macro: prng ( -- rnd ) \ updates seed
seed @ <prng> dup seed ! ;

macro: rnd ( ulimit -- uvalue ) \ in the range: [0,ulimit)
prng um* nip ;

macro: bias ( ulimit -- uvalue )
dup rnd over rnd um*
rot um/mod nip ;

This is somewhat crude, because I'm using a global variable for the
seed. Better would be to OOP it, and construct an object that contains
a seed, that way there could be more than one stream of pseudo-random
numbers in use at the same time. I did do that in my JRND
implementation, but the code is more complicated so I won't show it
here (I shouldn't really be posting Forth code in an assembly-language
forum anyway, but the LC53 stuff is very simple and should be a good
guide for novices).

Note that it is impossible to implement LC53 in C (at least, not
without recourse to inline assembly). By comparison, LC53 and
everything else in the novice package is ANS-Forth compliant.

[Rugxulo]

Hi,

On Oct 31, 5:52 am, Markus Wichmann <nullp...@nospicedham.gmx.net>
wrote:

> On 30.10.2011 22:23, Bjarni Juliusson wrote:
>
> > This isn't really going to answer any of your questions, but I see this
> > all the time and I have to ask:
>
> > Why do so many people still run MSDOS on their computers?
>
> My guess is that several people think you can't write assembly for
> anything but MSDOS. The reason being they tried their old MSDOS code on
> Windows or Linux and - surprise - it turned out to be unportable. Yeah,
> well that's the idea behind assembly! But some people just don't get it.

If you want portable code, assembly probably isn't the answer. You
can, in theory, write "dual mode" code for 16-/32-bit, but most people
don't. (The fact that x86 is "everywhere" obliterates the need for
super portability, though.)

> Here at the Uni I'm attending we had a course for assembly language.
> Well, suffice it to say that the instructor wanted me, as someone who
> said he already had experience with assembly, to write up some code for
> the FPU so that he has something. No FPU code in the course? Frig? OK,
> then in 20 years they'll start learning about MMX or what?

FPU/MMX/3dnow! are all deprecated and only remain for legacy. I don't
see how they could ever cleanly remove those, but who knows. The
future is all SSE2 on up, for good or bad (no 80-bit numbers??).
Everything nowadays really exercises CPUID, that's for sure!

> All this however just served to make the other attendees think assembly
> was a dying art. Well d'uh! When all you do is teaching people assembly
> on grounds of software that is so old it has to be emulated nowadays,
> something really isn't right!

The idea is that computers are fast enough and RAM is abundant enough
to not need assembly, which is obviously not true (or at least only
partially). Still, people flock to Java and C#/.NET in droves, for
whatever reason. Unfortunately, HLLs don't always deliver on their
promises of being ultra portable ("strictly conformant"??, LP64 vs.
LLP64, etc).

> > Also, 8086? That's a 35 year old processor you have there. I'd like to
> > encourage you to learn about assembly language programming, but I have
> > to say my best advice would be to forget about the 8086, and enter into
> > the 1980s and the wonderful world of the 80386 and the wide variety of
> > operating systems avalilable for it. Why make it hard on yourself?

386 (1986) isn't exactly modern anymore. And most people don't even
utilize 686 (1996?) properly. Only now are we starting to see decent
coverage for AMD64 (2003). The industry is slow to adopt, sometimes
for good reasons. Too many changes too quickly doesn't help anybody.

> Exactly. PLus, try to steer clear of 16-bit mode as it has several
> pitfalls, like only allowing you to reference memory from certain
> registers... in 16-bit mode, you can use pointers in bx, bp, si and di
> and several additions of the four, but not from ax, cx, dx and sp.
> Especially the latter is kind of dull when you try to allocate a
> temporary variable on stack: You can push it, but you can't reference it
> unless you created a stack frame beforehand. I just needed a place for
> my friggin 80-bit long double to stay for a short time!

None of that is a dealbreaker. It's easy to overcome such silly
limitations, no processor mode is perfect. There's always a few
gotchas, which is why there is no clear-cut answer.

> > As for MSDOS, I think you will find a proper modern operating system
> > gets in your way a lot less, and especially the various Un*x flavours
> > are really comfortable for us programmers! Try it!
>
> Right so! Just sometimes I'd like dosbox's debugger natively for Linux,
> but then again, maybe I just have to write it.

It's true, Linux has gotten many ports so that the uniqueness of DOS
is much, much less these days (e.g. Tran's Timeless). Still, don't
forget that DOS had a decade or two of good software (esp. games).

> Really though, the kernel interface to MSDOS was kind of shit, but then
> so is the entire 16-bit mode, with 32-bit pointers that are effectively
> 20 bits long (64-bit mode nearly manages to up this by introducing
> 64-bit pointers that are effectively 48-bits long. But at least 48 bits
> of address space are impossible to fill completely nowadays at least.)
>
> > Also, of course, it's a matter of learning what's useful - if you start
> > with 8086/MSDOS, you will then have to partially relearn the way you
> > program to be able to write programs that are really useful on modern
> > computers and operating systems.

You'll be constantly relearning anyways as things move too fast. There
are tons of competing technologies, and they all come and go (thus
will be abandoned eventually, even DEC's Alpha or Sony's Cell or
Intel's Itanium or MS' Win32 API).

> > I started with MSDOS, writing 16-bit assembly code in the mid 1990s,
> > when those things were on their way out, but once I tried 32-bit
> > assembly on Linux, I realised just how difficult MSDOS and 16-bit
> > programming had been and how counterproductive it was to continue doing
> > it. I haven't looked back.
>
> I learned assembly on Win32 a while back, then switched to Linux, then
> had to do some work for DOS, then embraced Linux really hard! Now I'm
> writing code for Linux/AMD64 and wonder where all those MSDOS and 8086
> enthusiasts lived the past 20 years or so... under a rock?

No, just old (but functional) hardware and lack of decent tools, texts/
tutorials, etc. No sense in bothering with learning 64-bit if you
don't have the hardware to test. (Yes, I know, QEMU had a 32-bit-
hosted emulator.) Also no sense in using 32-bit when 16-bit gets the
job done.

"A poor carpenter blames his tools." Viva la FreeDOS! ;-)

(yes, I'm actually triple-booting these days, for no obvious reason:
FreeDOS, Linux32, Win64)

[Bjarni Juliusson]

On 10/31/2011 09:26 AM, Thomas Jensen wrote:
> On Sun, 30 Oct 2011 22:23:19 +0100, Bjarni Juliusson wrote:
>
>
>> Why do so many people still run MSDOS on their computers?
>
> Are there so many people doing that? Well, I can come up with several
> possible answers, and none of them involve it is superiour.

Well at least in a couple of the newsgroups I frequent, there seems to
be a balls load of people who teleported there from the 80s and
apparently brought their computers with them. In alt.os.development they
all want to know how to write a bootloader for floppy disks.

Where do you even buy floppy disks?

I might add that I myself am an avid retrocomputing fan - my collection
includes both PDP-11s, DG Eclipses, VAXen, a DG Nova 3, and a PDP-10,
I'm currently repairing a rare PDP-12 together with friends at the
computer club, and I still have the C64 that I learned to program on,
and if you give me a moment to go through my tapes I probably have the
very first machine code program I wrote all by myself.

But as for the 16-bit x86 days, I say good riddance! The C64 at least is
a nice platform, into the design of which seems to have gone some not
insignificant amount of thought.

Programming the 6510 CPU involves all the register shuffling of
programming the 8086, but with the 6510 it's not because it's a
complicated architecture, but because it's a simple one! Some 3500
transistors compared to over 20000 in the 8086 - you had your 8-bit
accumulator, you could add and subtract and do the logical operations,
and then they threw in two index registers for speed.

And fast it was, impressively so, and given that it was introduced at a
small fraction of the price of all of its competitors, it was a hit.
Some people could hardly believe it. Imagine seeing an ad for a computer
ostensibly touting the same performance as a £1000 PC, but being sold
for less than £200. Would you bother reading an ad like that?

The C64 was introduced just a few months after the PC. They both came
with 64K RAM, they both stored their programs on cassette tapes, and
they both used your TV for their display. But while the C64, sometimes
derided for its poor graphics capabilities, had 320x200 16-colour tiled
or bitmapped graphics with hardware sprites and retrace interrupts, the
PC had the (optional) CGA card which gave you 320x200 in only 4 colours,
no sprites, no tiles, no retrace interrupts. Who remembers playing games
in cyan and magenta back in the day?

While the C64 included the fantastic 6581 sound chip, which gave you
three independent voices of sound, each with three waveforms plus noise,
16-bit pitch covering eight octaves, and an ADSR envelope generator,
plus a common programmable analog filter, the PC gave you no sound at
all. Well, it could go "beep" I guess.

The C64 came with a floppy/printer interface, tape interface, two game
ports including analog inputs, a parallel "user port", a cartridge
expansion port, and RF and composite video outputs, all built into the
keyboard, selling for a third of the price of the PC.

And then of course there is the damn BIOS, and the keyboard controller
which seems be the chip that really does everything in a PC, the cruddy
floppy controller, and of course all the cumulative extensions to
everything without any apparent thought or planning.

And then there's MSDOS. Or was!

<inflammatory material>

Now I just wish the "Windows" part of "DOS/Windows" would go die too.

</inflammatory material>

>> Also, 8086? That's a 35 year old processor you have there.
>
> Yes. And my car is 42 and my boat is 53... ;-) I could easily get a
> faster car and boat, but they have their own charme. And, I do have a
> faster computer... and it has absolutlu no much charme... ;-)

I know all about this charm, but I wouldn't associate the 8086 with it!

>>I'd like to
>> encourage you to learn about assembly language programming,
>
> Good. I would also be very disappointed if you didn't - specially here in
> this group! Just kidding... ;-)

I suspect that assembly gives you a sound understanding of programming
that is a great help in understanding other languages.

> No, you have a point. There's no need to learn a lot of stuff no longer
> needed in modern OS'es. 10 years ago I would have said it is good to know
> the history, and it makes you understand the reason why things are as
> they are today, but... No, I agree. No-one today will benefit from
> learning 16bit assembly.

I couldn't agree more about the history, and I've given a couple of
lectures here at the university on the topic of computer history, but
I'm not so sure it applies in that way. You'd want to study computer
architecture and then read about the architectures of computers through
the decades to see how they have changed (and how the x86 is very much a
1970s architecture, at least in real mode), and study operating systems
and the progression of ideas that have led to the systems we have today.

I'd say it's the operating systems that have really made a difference;
they've completely changed the way computers work and what they can be
used for, much more than the details of which registers you can multiply
in real mode, or "Steampunk Mode" as a friend called it.

I don't see MSDOS in there among the ancestors of modern operating
systems. I see VMS, UNIX, Multics, and a bunch of other systems that
pioneered ideas that are used in modern operating systems today: time
sharing, high-level programming languages, user accounts, file systems,
file permissions, job control, memory protection, paging, block caches,
dynamic linking, networking, graphical user interfaces, and so on. Some
of those things depend on hardware support, but historically that
hardware was often originally custom-built for some operating system
research project.

Knowledge of MSDOS is of course a good thing because knowledge of
history is, but it is mostly a question of understanding the times; to
understand how computers were used by the general population in the
1980s, how much work something that is trivial today might have
entailed, and as a part of understanding the broad variety of operating
systems and computer architectures available to the home user in that
decade and what that meant to the users. I can't really say it pioneered
anything.

And even so, it's one thing to study something out of historical
interest, and another to actually use it seriously every day. :)

> And I actually have a book about assembly programming in Linux - the AT&T
> way with gas. It's just waiting for me taking it down from the shell and
> start.

Take it off the shelf!

> Right now I am playing with my Amstrad PPC640.
>
> http://www.old-computers.com/museum/computer.asp?c=195

Wow!

I personally have a Bondwell model 2. It's my only laptop. :)

[Bjarni Juliusson]

On 10/31/2011 09:37 PM, Hugh Aguilar wrote:
> On Oct 31, 4:52 am, Markus Wichmann<nullp...@nospicedham.gmx.net>
> wrote:
>
> Some people go for old processors on the theory that they are simpler
> than the new ones, and hence easier to learn. This usually isn't true.
> For example, on the 16-bit x86 you have to learn which registers can
> be used for which instructions.

The easiest architecture that I have programmed on was the 68000,
followed by SPARC. Both mostly for the same reasons: you have lots of
registers, and all instructions can use all registers (well, almost).
The 68000 also has a large instruction set and a nice set of address
modes that can also be (almost) freely combined with the instructions.

x86 is pretty close to the bottom, a bit above the PDP-8. Imagine having
only one register, no stack, and only being able to access two pages of
128 12-bit words of memory: the bottom page and the page that the
currectly executing instruction is in. Jumps and other accesses to other
pages have to be indirect, and even then they are limited to one
4096-word "field", beyond which memory can be extended with the aid of
bank switching.

Or maybe the LINC is worse, where some instructions use 12-bit
arithmetic and some use 11-bit arithmetic, and some use two's complement
and some one's complement *and* sign-magnitude, and the "fields" are
only 1024 words.

But the 68000 is just wonderful. When you program it, you feel free in a
way that is uncommon in assembly programming. It's friendly and helpful,
and you wonder why the other architectures aren't the same way.

The PPC and the PDP-10 also seem nice, and similar to the 68000 in some
ways, but I haven't programmed on them. I'm going to get access to a
Power server shortly, and I intend to learn everything about assembly
programming on it! :)

Another couple of architectures renowned for their orthogonal use of
registers and address modes are the PDP-11 and its successor, the VAX. I
can't say I've programmed much on them either, but the VAX is absolutely
bizarre. It's the only architecture I've seen that has a machine
instruction for evaluating polynomials.

> I don't think anybody should expect to learn any useful technology in
> school. The most important thing that you can learn, is how to read
> data-sheets --- that way you can pick up new technology quickly. Also,
> learn how to figure out how a system works through experimentation, as
> you often lack an up-to-date data-sheet and there really is no
> documentation for the hardware. They don't really teach this though
> --- they give you the information about the processor in a textbook,
> which is like a gigantic and incredibly wordy data-sheet --- you are
> not going to get this much hand-holding at a job!

I'm a computer scientist from Sweden, and one of the worst things about
studying computer science was the lack of good textbooks. Especially the
American textbooks are often pretty useless.

But it's right what you said: you learn how to learn, and a lot of the
details they teach you aren't useful. They taught us MIPS assembly, not
because lots of people use MIPS processors, but because assembly was
necessary to allow us to understand operating systems fully, the MIPS
architecture is easy to learn, and they had lab hardware for it. I'm
fine with that. I would have hated it if they had tried to teach us x86
assembly.

They also teach you how to *think*, how to conceptualise and model the
real world so you can do anything with it. That's as important as
knowing how to find information.

[Bjarni Juliusson]

On 10/31/2011 09:41 PM, Rugxulo wrote:
> Hi,
>
> On Oct 31, 5:52 am, Markus Wichmann<nullp...@nospicedham.gmx.net>
> wrote:
>> On 30.10.2011 22:23, Bjarni Juliusson wrote:
>>
>> > Also, 8086? That's a 35 year old processor you have there. I'd like to
>> > encourage you to learn about assembly language programming, but I have
>> > to say my best advice would be to forget about the 8086, and enter into
>> > the 1980s and the wonderful world of the 80386 and the wide variety of
>> > operating systems avalilable for it. Why make it hard on yourself?
>
> 386 (1986) isn't exactly modern anymore.

It was supposed to be a humorous demonstration of how extremely outmoded
the 8086 is.

Also, starting with the 32-bit protected mode of the 386, you get the
machine model that is still current today. If you learn to program on
it, you are able to program all x86 processors that have come after it
in an appropriate manner. It's only if you want to optimise your code
that you /really/ need to worry about the differences between the 32-bit
modes of the 386 and the Core 2.

Of course, x86-64 is starting to replace x86-32 now. I really ought to
build myself a 64-bit kernel and learn how to program these newfangled
machines some day. Who has a good introduction?

> Still, don't
> forget that DOS had a decade or two of good software (esp. games).

I seem to recall that the games were without exception better on the
other platforms on which they were released. :/

>> I learned assembly on Win32 a while back, then switched to Linux, then
>> had to do some work for DOS, then embraced Linux really hard! Now I'm
>> writing code for Linux/AMD64 and wonder where all those MSDOS and 8086
>> enthusiasts lived the past 20 years or so... under a rock?
>
> No, just old (but functional) hardware and lack of decent tools, texts/
> tutorials, etc. No sense in bothering with learning 64-bit if you
> don't have the hardware to test. (Yes, I know, QEMU had a 32-bit-
> hosted emulator.) Also no sense in using 32-bit when 16-bit gets the
> job done.

That is a reason for a person who learned 16-bit x86 assembly when it
was current to continue using it, but doesn't explain all the people who
seem to want to learn it today, especially as a first assembly language.
Learning 32-bit x86 assembly is a whole lot less bother. Besides,
running those old 16-bit programs is getting difficult too.

How much support does Windows still have for DOS programs, by the way?
My knowledge of Windows sort of drops out around Windows 2000; after
that I got wind of Linux. I remember that after you'd had Windows
running for a few hours, you'd start running out of memory for no
apparent reason, but you could free memory up by repeatedly starting and
exiting Paintbrush. I can't say I've ever needed to do that on Linux. :)

> (yes, I'm actually triple-booting these days, for no obvious reason:
> FreeDOS, Linux32, Win64)

Incredible. I don't get power failures often enough that I'd ever get to
boot the other systems.

[Bjarni Juliusson]

On 10/31/2011 09:26 PM, Rugxulo wrote:
> Hi,
>
> On Oct 30, 4:23 pm, Bjarni Juliusson<bja...@nospicedham.update.uu.se>
> wrote:
>>
>> This isn't really going to answer any of your questions, but I see this
>> all the time and I have to ask:
>>
>> Why do so many people still run MSDOS on their computers?
>
> They don't, they run (or used to run) Windows or OS/2 or similar which
> had emulation for it. The main reason to run an OS is to run specific
> apps which won't run elsewhere. Unfortunately, XP was the last "fairly
> good" DOS-supporting OS, and even that is (falsely) called "old,
> deprecated, crap" nowadays because it's 10 years old. Later Windows,
> esp. Win64, don't support DOS well or at all. So of course, you'll
> have to dual- or triple-boot DOS if you want to run old apps that
> can't (easily) be recompiled.

This answered a question I just posted in another part of this thread.
Thanks.

> Truly, if you're really intending to move to 32-bit (or 64-bit),
> there's no reason (and even some disadvantages) to messing with 16-
> bit. Of course, there's nothing wrong with any of it, it's just
> different and somewhat incompatible. For playing around, esp. with old
> books and hardware, it's fine, even recommended.

Sure, but since he didn't say he specifically wanted to play around with
retro hardware I just figured he might be one of these people who show
up and think that real mode is overall a good way to learn programming,
so I gave him advice that pertained to that.

> But don't get too smug, I've already seen various people call 32-bit
> "deprecated", even some higher ups. It won't be long before 32-bit
> compatibility is dropped just like 16-bit. And they'll be saying the
> same thing, "AMD64 has been around for 10 years, it's everywhere, get
> with the times!" If you think that won't happen, you're very naive.

Don't worry. :) I'd recommend anyone to go straight to x86-64, except
that adoption of it isn't as complete as for the 32-bit architecture and
good tutorials, books, etc are still a bit scarce from what I can tell.
Also, I don't know anything about it myself, so it's hard to make any
recommendations.

>> As for MSDOS, I think you will find a proper modern operating system
>> gets in your way a lot less, and especially the various Un*x flavours
>> are really comfortable for us programmers! Try it!
>
> Doubt it. They have their own problems and aren't targeted at the same
> machines. It really just depends on what you want to do and how you
> want to accomplish it (what you know, tools, etc).

I assumed the most common case, that he was an average guy with some
knowledge of programming, who had taken an interest in assembly and
decided to learn it, without having any special requirements other than
that.

>> I started with MSDOS, writing 16-bit assembly code in the mid 1990s,
>> when those things were on their way out, but once I tried 32-bit
>> assembly on Linux, I realised just how difficult MSDOS and 16-bit
>> programming had been and how counterproductive it was to continue doing
>> it. I haven't looked back.
>
> You know you can write 32-bit code in DOS, right?

Yes, and I've done it. Oh boy it sucked. DOS was still there.

> There is no disadvantage.

For most people, not having a proper shell, multitasking, a real file
system, and all those other things that operating systems usually have,
is indeed a disadvantage.

I've done a whole lot of programming in DOS, I've done a whole lot of
programming in Linux, and I've done a fair amount of programming on the
sort of computers where you have only a panel of lights and switches and
have to enter your programs byte by byte into the memory in binary, and
the difference in difficulty and discomfort is actually about the same
between the latter type and DOS and between DOS and Linux.

> So I disagree that it's less "modern" unless you believe the (hype)
> superiority of 64-bit. If you know what you're doing, you can easily
> do anything in DOS, with the proper knowledge and tools. Just because
> another OS has more "batteries included" doesn't make it impossible.

Sure it's possible, and it's even possible to do it blindfolded, but why
bother unless you're into blindfolding?

[Markus Wichmann]

On 01.11.2011 05:35, Bjarni Juliusson wrote:
> Of course, x86-64 is starting to replace x86-32 now. I really ought to
> build myself a 64-bit kernel and learn how to program these newfangled
> machines some day. Who has a good introduction?
>

> Bjarni

Well, there's http://www.x86-64.org. I think, you're looking for
http://www.x86-64.org/documentation/assembly.html

Other than that, the ABI is different, with parameter passing in
registers instead of the stack, but the order is different for Windows
and Linux. Linux uses for user-mode in this order rdi, rsi, rdx, rcx, r8
and r9. For kernel-mode, instead of rcx, r10 is used. (I think, rcx is
needed somewhere in that syscall/sysret stuff)

Floating Point parameters go into the SSE registers in order. If the
function has variable arguments, al is set to the number of used SSE
registers. Everything that doesn't fit goes on the stack, though.
There's some unique strangeness to passing whole structures that fit in
one register (They're passed in one register instead of in components),
but then, who passes whole structures instead of pointers, anyway?

No idea for Windows though.

HTH,
Markus

[Bjarni Juliusson]

Thanks!

[Bob Masta]

On Mon, 31 Oct 2011 13:37:27 -0700 (PDT), Hugh Aguilar
<hughag...@nospicedham.yahoo.com> wrote:
<snip>

>Most 16-bit LC prngs that you find, were designed for use in C and
>Pascal, etc. They use tiny little numbers because C etc. don't allow
>for double-sized intermediate values. When you multiply a single by a
>single, the result has to be a single. Similarly, when you divide,
>everything has to be the same size.

Instead of the linear congruential random generator, the
"polynomial" type can avoid word size limitations if you set
it up right. The idea behind one of these generators is
that you have a shift register with a tap at a certain
position, and you XOR the tap output with the final stage
output and feed it back to the input. People have worked
out the taps that give a maximum-length sequence, equal to 2
to the number of shift stages, minus 1. (See Knuth,
"Seminumerical Algorithms", table 1, page 28)

The output of the shift register is a series of
pseudo-random bits. You could run it N times to get an
N-bit value, but there are problems with that. Better to
use N shift registers in parallel, each starting with a
different initial pattern.

This explanation might make you think of using a CPU
register as a shift register, advancing via rotates, with
some tricky masking to pick off the bits to XOR. But that
limits you to 2^32-1 lengths, just like linear congruential.
Much better is to think about "turning this sideways", to
use an array of elements where each element is (say) a
DWORD, and the number of elements is the number of stages in
each shift register. Now you just XOR two elements together
and that's the same as XORing all 32 shift registers in
parallel. The length of the sequence is now determined only
by the number of memory elements you want to use (and more
likely by the maximum-length sequence tap tables you can
find).

I've used a 63-element scheme to get 2^63-1 sequences (which
nowadays are easy with linear congruential on a 64-bit
machine), but I've seen taps listed for up to 1023 stages.
(Maybe more, these days, since that was a while ago.) Note
that although this method is slower than linear conguential
when the LCG uses a native word size, it operates at a
constant speed regardless of sequence length.. no penalty at
all for scaling. (Basically, just an XOR and pointer
changes.) So if you want a really huge sequence, this is a
good way to go.

[Jim Leonard]

On Oct 31, 9:43 pm, Bjarni Juliusson <bja...@update.uu.se> wrote:
> Well at least in a couple of the newsgroups I frequent, there seems to
> be a balls load of people who teleported there from the 80s and
> apparently brought their computers with them.

As one of Those People(tm) I can tell you why: In the 1980s, we
marveled at what our machines could do, but lacked the skill and
knowledge to reproduce that work and build on it. Now that we're
older and wiser, we can.

I "retroprogram" (for lack of a better word) for a few reasons, the
most important being a sense of accomplishment that I was unable to
achieve as a youth. I find it especially fun to write programs that
would have blown the doors off of 1982 (such as full-screen texture-
mapping or digital video playback in CGA, a multi-voice digital sound
engine, etc.). I like surprising the 1982 Me.

> Where do you even buy floppy disks?

They come with our retrocomputers. Or, if you're sufficiently old,
you still have them. I still have some of my old Apple 2 floppies.

> But as for the 16-bit x86 days, I say good riddance! The C64 at least is
> a nice platform, into the design of which seems to have gone some not
> insignificant amount of thought.

The more I probe into the PC, the more I'm impressed with what they
were able to put into it with very little time and limited to off-the-
shelf components. For example, someone had the foresight at the last
minute to tie one of the timer lines to the speaker such that very
short timing periods were possible, enabling clear digitized sound
output.

> Programming the 6510 CPU involves all the register shuffling of
> programming the 8086, but with the 6510 it's not because it's a
> complicated architecture, but because it's a simple one! Some 3500
> transistors compared to over 20000 in the 8086 - you had your 8-bit
> accumulator, you could add and subtract and do the logical operations,
> and then they threw in two index registers for speed.

I commented on 6502 vs. 8088 here, if you're curious:
http://trixter.oldskool.org/2011/06/04/at-a-disadvantage/

> But while the C64, sometimes
> derided for its poor graphics capabilities, had 320x200 16-colour tiled
> or bitmapped graphics with hardware sprites and retrace interrupts, the
> PC had the (optional) CGA card which gave you 320x200 in only 4 colours,
> no sprites, no tiles, no retrace interrupts. Who remembers playing games
> in cyan and magenta back in the day?

Both platforms had graphics limitations; I think it's disingenuous to
paint (pun intended0 the C64 as vastly surperior. Each CGA pixel was
individually addressable; in C64 16-color mode, they were not and you
were limited to 3 colors per tile + background. CGA could also do
high-res line art 640 pixels across, whereas C64 could not. So they
both had pros and cons.

> While the C64 included the fantastic 6581 sound chip, which gave you
> three independent voices of sound, each with three waveforms plus noise,
> 16-bit pitch covering eight octaves, and an ADSR envelope generator,
> plus a common programmable analog filter, the PC gave you no sound at
> all. Well, it could go "beep" I guess.

Agreed.

> And then of course there is the damn BIOS, and the keyboard controller
> which seems be the chip that really does everything in a PC, the cruddy
> floppy controller, and of course all the cumulative extensions to
> everything without any apparent thought or planning.

The BIOS allowed for extremely small programs to be written, if you
could take the speed penalty. (Why so much hate for the BIOS? The
BIOS was one of the things that made the original Mac possible,
although they called it a ROM. Maybe if they called it a BIOS there
would be the same stigma?)

I'd argue that the 8253 timer was the chip that did everything in a
PC :-)

I'm surprised you're arguing against the PC's floppy controller when
your comparison is the C64.

> I know all about this charm, but I wouldn't associate the 8086 with it!

I find the 1-byte CISC instructions charming. xlat, movs, lods, stos,
are single-byte opcodes and get a lot done. And who doesn't love a
built-in MUL/IMUL/DIV/IDIV? Sure, they're slow on 8086, but at least
they're present.

[Nathan]

On Oct 30, 5:23 pm, Bjarni Juliusson

>
> As for MSDOS, I think you will find a proper modern operating system
> gets in your way a lot less, and especially the various Un*x flavours
> are really comfortable for us programmers! Try it!
>

In the given context, your premise has validity. However, for years
(esp. in alt.lang.asm), I've often seen this argument stated the other
way around. In a DOS environment, one has direct access to hardware
(can twiddle the IVT values, can use IN/OUT instructions, can use Mode
13h for direct access to screen pixels, etc.) -- therefore, DOS "gets
in your way a lot less" than modern operating systems. It stands to
reason that if "What's under the hood?" or "Machine Understanding" is
the goal of an ASM student, then DOS obviously provides the best
target environment.

Nathan.

[Jim Leonard]

On Oct 31, 10:46 pm, Bjarni Juliusson <bja...@update.uu.se> wrote:
> But the 68000 is just wonderful. When you program it, you feel free in a
> way that is uncommon in assembly programming. It's friendly and helpful,
> and you wonder why the other architectures aren't the same way.

Surprising statement to make, considering that attempting to read
unaligned words on a 68000 throws an exception. (I can understand the
stack needing to be word-aligned, but generic data access?)

[Jim Leonard]

On Oct 31, 11:35 pm, Bjarni Juliusson <bja...@update.uu.se> wrote:
>
> > Still, don't
> > forget that DOS had a decade or two of good software (esp. games).
>
> I seem to recall that the games were without exception better on the
> other platforms on which they were released. :/

In the 1980s, this was true with only a handful of exceptions (Flight
Simulator, for example). In the 1990s, this was false, as the PC's
raw horsepower overwhelmed the other platforms.

> How much support does Windows still have for DOS programs, by the way?

If you run a 32-bit version of Windows, they still run, barring a few
exceptions.

[Lasse Reichstein Nielsen]

And if not, most of them can be run perfectly in DosBox.

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Rugxulo]

Hi,

On Nov 1, 10:04 am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:

> On Oct 31, 9:43 pm, Bjarni Juliusson <bja...@update.uu.se> wrote:
>
> > But while the C64, sometimes
> > derided for its poor graphics capabilities, had 320x200 16-colour tiled
> > or bitmapped graphics with hardware sprites and retrace interrupts, the
> > PC had the (optional) CGA card which gave you 320x200 in only 4 colours,
> > no sprites, no tiles, no retrace interrupts. Who remembers playing games
> > in cyan and magenta back in the day?
>
> Both platforms had graphics limitations; I think it's disingenuous to
> paint (pun intended0 the C64 as vastly surperior.  Each CGA pixel was
> individually addressable; in C64 16-color mode, they were not and you
> were limited to 3 colors per tile + background.  CGA could also do
> high-res line art 640 pixels across, whereas C64 could not.  So they
> both had pros and cons.

Bjarni, check out Paku Paku, a modern retro game written (earlier this
year) to run on the original IBM PC (8088). It uses a tweaked CGA mode
to get more than 4 colors.

http://my.opera.com/deathshadow/blog/

> > While the C64 included the fantastic 6581 sound chip, which gave you
> > three independent voices of sound, each with three waveforms plus noise,
> > 16-bit pitch covering eight octaves, and an ADSR envelope generator,
> > plus a common programmable analog filter, the PC gave you no sound at
> > all. Well, it could go "beep" I guess.
>
> Agreed.

Again, I'm probably telling you something you already know, but you
can reprogram the PIT to achieve digital sound from the PC speaker.
Paku Paku does it, as do many others. (Even Wolfenstein 3D has an
undocumented option / byte to turn it on.)

> > And then of course there is the damn BIOS
>

> The BIOS allowed for extremely small programs to be written, if you
> could take the speed penalty.

The BIOS' main problem is that it's not re-entrant. Also there are
some rare bugs, and it obviously got quite complex as time went on.
But yeah, at least it (mostly) hid the various differences in clone
hardware.

> > I know all about this charm, but I wouldn't associate the 8086 with it!
>
> I find the 1-byte CISC instructions charming.  xlat, movs, lods, stos,
> are single-byte opcodes and get a lot done.  And who doesn't love a
> built-in MUL/IMUL/DIV/IDIV?  Sure, they're slow on 8086, but at least
> they're present.

Right, it's just a matter of taste. I don't say it's 100% my ideal
cpu, but if you dislike it, don't program for it: run a 68000 emulator
and/or some scripting language or HLL compiler or whatever. The 8086
indeed does well at compact code, usually better than most others.

http://www.deater.net/weave/vmwprod/asm/ll/ll.html

Embrace the kludge that is 8086, resistance is futile! :-))

[Rugxulo]

Hi,

On Nov 1, 12:44 am, Bjarni Juliusson <bja...@update.uu.se> wrote:
> On 10/31/2011 09:26 PM, Rugxulo wrote:
>
> > You know you can write 32-bit code in DOS, right?
>
> Yes, and I've done it. Oh boy it sucked. DOS was still there.

Then you were using the wrong tools and/or wrong "DOS". There are
many. Which did you use last? (A lot has changed over the years.)

> > There is no disadvantage.
>
> For most people, not having a proper shell, multitasking, a real file
> system, and all those other things that operating systems usually have,
> is indeed a disadvantage.

Again, wrong tools. You can find a myriad of shells, multitasking,
file systems, etc. if you look hard enough. It's not "DOS"' fault that
you don't know enough about it. Anything sucks when you don't
understand it.

> I've done a whole lot of programming in DOS, I've done a whole lot of
> programming in Linux, and I've done a fair amount of programming on the
> sort of computers where you have only a panel of lights and switches and
> have to enter your programs byte by byte into the memory in binary, and
> the difference in difficulty and discomfort is actually about the same
> between the latter type and DOS and between DOS and Linux.

Depends on what you're trying to do.

> > So I disagree that it's less "modern" unless you believe the (hype)
> > superiority of 64-bit. If you know what you're doing, you can easily
> > do anything in DOS, with the proper knowledge and tools. Just because
> > another OS has more "batteries included" doesn't make it impossible.
>
> Sure it's possible, and it's even possible to do it blindfolded, but why
> bother unless you're into blindfolding?

It's easy to look back 30 years and think everyone was a fool, but in
reality, they were probably smarter than we are (understatement)! You
don't have to like, understand, or agree with them, but they had their
reasons. Sure, backwards compatibility is difficult, but it's either
that or reinvent the wheel a billion times (which indeed still
happens), which is a PAIN to deal with. Sometimes, "old" but stable is
"good enough".

http://xkcd.com/927/

[Rod Pemberton]

"Bjarni Juliusson" <bja...@nospicedham.update.uu.se> wrote in message
news:j8kf88$5g4$1...@Iltempo.Update.UU.SE...

> This isn't really going to answer any of your questions, but I see this
> all the time and I have to ask:
>
> Why do so many people still run MSDOS on their computers?
>

It's part of Win98/SE/ME which I'm still using. There are good compilers
for it, e.g., DJGPP and OpenWatcom among others. It's a CLI, which
eliminates coding for a GUI. DOS is an OS that doesn't interfere with code
development for a personal OS. I grew up on CLI based OSes and like them.
GUIs are convenient, but not critical to me.

> Also, 8086? That's a 35 year old processor you have there. I'd like to
> encourage you to learn about assembly language programming, but I have
> to say my best advice would be to forget about the 8086, and enter into
> the 1980s and the wonderful world of the 80386 and the wide variety of
> operating systems avalilable for it. Why make it hard on yourself?

I don't have an x86 microprocessor older than a 486 DX2-66. It's packed
away somewhere. The older ones were given to a former friend who, I
suspect, sold them as collectibles ... The oldest x86 microprocessor I have
that is in a bootable machine is a 233Mhz Pentium. So, he is definately "PC
retro-computing", like Jim, for using something that old.

> As for MSDOS, I think you will find a proper modern operating system
> gets in your way a lot less, and especially the various Un*x flavours
> are really comfortable for us programmers! Try it!

Are you joking?

DOS is 16-bit real-mode code. There is no memory protection, no paging.
You can program ports, keyboards, mice, and A20 directly. Nothing gets in
the way on DOS. You can run 32-bit or 64-bit code. If need be, DOS can
have it's state stopped and saved, be removed from memory, and be reloaded
and restored when needed again.

> Also, of course, it's a matter of learning what's useful - if you start
> with 8086/MSDOS, you will then have to partially relearn the way you
> program to be able to write programs that are really useful on modern
> computers and operating systems.

...

> I started with MSDOS, writing 16-bit assembly code in the mid 1990s,
> when those things were on their way out, but once I tried 32-bit
> assembly on Linux, I realised just how difficult MSDOS and 16-bit
> programming had been and how counterproductive it was to continue
> doing it. I haven't looked back.

Well, that's definately not my experience with DOS, most of which is post 98
due to Win98SE, although I did use it slightly earlier in the 90's w/6.22
and 5.0 ...


Rod Pemberton

[Rod Pemberton]

"Bjarni Juliusson" <bja...@update.uu.se> wrote in message
news:j8nmcn$m6i$1...@Iltempo.Update.UU.SE...

> On 10/31/2011 09:26 AM, Thomas Jensen wrote:
> > On Sun, 30 Oct 2011 22:23:19 +0100, Bjarni Juliusson wrote:
>
>>> Why do so many people still run MSDOS on their computers?
>
>> Are there so many people doing that? Well, I can come up with several
>> possible answers, and none of them involve it is superiour.
>
> Well at least in a couple of the newsgroups I frequent, there
> seems to be a balls load of people who teleported there from
> the 80s and apparently brought their computers with them.

...

> In alt.os.development they all want to know how to write
> a bootloader for floppy disks.

Using a floppy to execute bootstrap code is _easy_.

> Where do you even buy floppy disks?
>

We still have them from the 80s ... ;-)

That's funny, but I'm not joking.

I haven't used 5 1/4" in a long time. I still have a bunch. They were
notorious for losing data. 3 1/2" are much more reliable. I've stil got a
bunch of them, decades old, that haven't lost data. Although, there
were a bunch I had to throw out after about a decade.

> I might add that I myself am an avid retrocomputing fan - my collection
> includes both PDP-11s, DG Eclipses, VAXen, a DG Nova 3, and a
> PDP-10, I'm currently repairing a rare PDP-12 together with friends

> at the computer club, [...]

Could you or your friends fill in some missing PDP info on this
Wikipedia page?
http://en.wikipedia.org/wiki/Word_(computer_architecture)

I'm really interested in the sizes for the PDP-7. Wikipedia also has
specific pages on PDP-1, PDP-6, PDP-8, PDP-10 and PDP-11.

> [posted, impressive, recollection of 80's computing history]

I lived through that and experienced it ...

> And fast it was, impressively so, and given that it was introduced at a
> small fraction of the price of all of its competitors, it was a hit.

AIR, it was the first microprocessor with pipelining.

I quoted the MOS Technology manual here:
http://groups.google.com/group/alt.lang.asm/msg/e38c78eb59dba037

> I don't see MSDOS in there among the ancestors of modern

> operating systems. I see VMS, UNIX, Multics, [...]

I too learned how to program on the C64. I've also programmed DEC
VAX, Stratus Continuum's, etc. I still use DOS to this day. You're not
giving DOS anywhere near enough credit, IMO.

> I see VMS, UNIX, Multics, and a bunch of other systems that
> pioneered ideas that are used in modern operating systems today:

Most individuals don't need any of those advanced features. Yes, they are
important to businesses or universities, etc. E.g., for a single individual
using a PC:

> time sharing,
Not needed. Most systems an individual would use are only used by a single
person, so time sharing between multiple useres is not needed. Time-based
multi-tasking is nice for individuals, although it's not needed either.

> high-level programming languages,
Not needed. Most individual computer users are not programmers. C is
great. The rest are mostly horrid to program.

> user accounts,
Not needed. Why do you need user accounts on a computer used by a single
individual? I don't know why Linux and Unix insist on this horrid feature.
It's one of the first things I rip out of a new Linux install. Boot. Put
me at a prompt immediately. Don't ask me for account info on a PC I own.
If you're seriously concerned that someone else is going to access your PC
without your permission, like you're actually somebody important in life or
a notorious criminal, then you don't own enough guns, ammo, or hunting or
attack dogs. If you're a law abiding citizen, you should have no concern.

> file systems,
Needed. How else are you going to save files?

> file permissions,
Not needed. These are mostly a nuisance on computers used by a single
individual.

>job control,
Not needed. Most invidual computers have directly connected devices.

>memory protection,
Not needed. See C64, DOS, etc.

>paging,
Not needed, but nice.

>block caches,
?

>dynamic linking,
Not needed, but nice, if you're a programmer ... but most who use computers
*aren't* programmers.

>networking,
Needed.

>graphical user interfaces,
Not needed, but nice.

> And even so, it's one thing to study something out of
> historical interest, and another to actually use it
> seriously every day. :)

Yes, and most of the people you questioned in regards to using DOS, use it
every day. I use Win98SE. The personal programs I write are DOS C
programs: to calculate mortgage payments, to determine the best location to
buy gasoline, to convert links to html for my mother, ad infinitum. Could I
compile them or port them to Linux? I assume that is fairly easily, since
they compile using GCC via DJGPP project. Linux, however, has had between
one and three hardware devices for every machine that I've owned, that it
doesn't support. I've tried numerous Linux distro's for decades now. With
a few exceptions, fewer than Linux, DOS or Win98 supports it.


Rod Pemberton

[Thomas Jensen]

On Mon, 31 Oct 2011 13:37:27 -0700, Hugh Aguilar wrote:


> BTW, for Mr. Jensen --- my novice package has several linear-
> congruential prngs, including one (LC53) that I invented. All of this is
> in Forth though, but still, you get to see the basic idea.

Thank you. And sorry for the late reply. There have been too many posts
to answer them all, so I will just say thank you to everyone here
answering my post, and say I finally got it working. Bjarni Juliusson
said something that made me take another look at my random routine, and I
think it works properly now. Code is at the bottom of message.

Today I will make a program that can give me some stats on the randomness
of the different values in and c, but only for the fun. I am not going
to use it for anything serious stuff, so it doesn't matter. Actually, the
reason why I started on this random-stuff is, I want to write a program
where I draw a line on the screen and use some random numbers to make it
move around on the screen. The good old screen saver. I wrote a program
like that 15 years ago in C, with some inline assembly, for video mode
13h. Not much, but that's more or less the limits for my talent... :-/
Well, it could be fun - and I would learn something in the process - to
make it again, this time in assembly and for video mode 2, and may also
in mode 6. So that's why I need a random function. I don't want anything
complicated and cryptographically strong, just something that can trow
some numbers that can make my line move in something that looks like an
unpredictical way.

A few weeks ago I wrote another "screensaver" - only to give myself an
easy exercise I could learn something from. It draw some squares made of
'X' direct to video memory - and well, that's it. Not much, but now I
have some code I can use in other projects, and it was an easy project to
get me started and picking up assembly again.


I'll propably come back soon and ask for help. It sounds like there are
still people here, after all, that are familiar with dos, so... ;-)



====================== code start ======================
%TITLE "rand5.asm"
IDEAL
MODEL small

DATASEG
num_a DD 1103515245
num_c DW 12345

UDATASEG

dd_result DD ?
rand_seed5 DW ?


CODESEG

PUBLIC seed_random5, get_random5
PUBLIC rand_seed5


;--------------------------------------------------------------------
;
; SEED_RANDOM
;
; return: seed in dx
;
;--------------------------------------------------------------------

PROC seed_random5

push bx
push cx
push dx
@@L10:
mov ah, 2Ch ;
int 21h ;

or dx, dx
jz @@L10

mov [rand_seed5], dx


pop dx
pop cx
pop bx

@@L99:
ret

ENDP seed_random5

;====================================================================



;--------------------------------------------------------------------
;
; GET_RANDOM
;
; x = (xa + c) mod 32767
;
; expect: bx = max
; cx = min
;
; return: dx = result
;
;------------------------------------------------------------------------

PROC get_random5

@@L10:
push cx
push bx

mov ax, [word num_a + 2] ; high word
mov bx, [rand_seed5]
mul bx ; result in dx:ax

mov [word dd_result + 2], dx ; high word of result
mov [word dd_result], ax ; low word

mov ax, [word num_a] ; low word
mov bx, [rand_seed5]
mul bx ; result in dx:ax
; we don't use dx
add ax, [num_c] ; + c
and ax, 7FFFh ; mod 32767

or ax, ax
jnz @@L20
call seed_random5
jmp @@L10

@@L20:
mov [rand_seed5], ax ; 0 <= x <= 32767

pop bx ; max
pop cx ; min

xor dx, dx ;
sub bx, cx
div bx ; reminder in dx

add dx, cx


@@L99:

ret

ENDP get_random5

END


============= code end =================================


=================code start ===========================

%TITLE "square4.asm"
IDEAL
MODEL small
STACK 256

MACRO PAUSE num
LOCAL @@L1
push bx

mov ah, 00h
int 1ah
mov bx, dx
@@L1:
mov ah, 00h
int 1ah
sub dx, bx
cmp dx, num
jb @@L1

pop bx
ENDM

DATASEG

excode DB 0h
char DB 'X'
attr DB 07h
v DW 4
vbase DW 0B800h

rect DB 0,0,79,24
DB 6,2,73,22
DB 13,4,65,20
DB 19,6,59,18
DB 26,8,52,16
DB 32,10,46,14
DB 38,11,40,13

UDATASEG
vmode DB ?
rbase DW ?
vbuffer DW 2000 DUP(?)


CODESEG
Start:
mov ax, @data ; Initialize DS to address
mov ds, ax ; of segment
mov es, ax ; Make es=ds

;;----> ; get and set videomode

mov ah, 0Fh ; DOS function: get videomode
int 10h
mov [vmode], al ;
; mov ah, 00h ; DOS function: set videomode
; mov al, 03h ;
; int 10h ;

;----> ;

@@L10:
cld
xor bx, bx
@@L20:
mov dx, offset rect
add dx, bx
mov [rbase], dx

push bx

call write_vbuffer

mov si, offset vbuffer
mov es, [vbase]
xor di, di
mov cx, 2000
rep movsw

PAUSE 10 ; 20 = ~1 sec.

mov ah, 0Bh
int 21h ;result in al
or al, al
jnz @@L80

pop bx

add bx, [v]

cmp bx, 0
jz @@L30

cmp bx, 24
jne @@L20

@@L30:
neg [v]
jmp @@L20
@@L80:

;----> ; wait for keypresss before exit
mov ah, 08h ; DOS function: keyb input w/o
echo
int 21h

;----> ; set videmode back to original
mov ah, 00h ; DOS function: set videomode
mov al, [vmode] ;
int 10h ;

Exit:
mov ah, 04Ch ; DOS function: Exit program
mov al, [excode] ; Return exit code value
int 21h ; Call DOS. Terminate program


;---------------------------------------------------------------------

PROC write_vbuffer


; clear mem area
mov ax, ds
mov es, ax
mov di, offset vbuffer
mov ax, 0
mov cx, 2000
rep stosw

mov di, offset vbuffer
xor cx, cx
mov bx, [rbase]
mov cl, [byte bx+1] ;starty
cmp cl, 0
je @@ll10

@@ll5:
;add 80 words = one line
add di, 160
loop @@ll5
@@ll10:
; from start to first pos

mov cl, [byte bx] ;startx
shl cx, 1
add di, cx

; di is now in pos for first char

xor ch, ch
mov cl, [byte bx+2] ;endx
sub cl, [byte bx] ;startx

; num of chars on line in cl

mov al, [char]
mov ah, [attr]
rep stosw

;from last char to end of line

xor dh, dh
mov dl, 80
sub dl, [byte bx+2] ;endx
shl dl, 1
add di, dx

; num of lines to write

mov cl, [byte bx+3] ;endy
sub cl, [byte bx+1] ;starty
cmp cl, 1
je @@ll99
cmp cl, 2
je @@ll80
sub cl, 2

@@ll20:
; from start to first pos
mov dl, [byte bx] ;startx
shl dl, 1
add di, dx
stosw

;left char done now

xor dx, dx
mov dl, [byte bx+2] ;endx
sub dl, [byte bx] ;startx
sub dl, 2
shl dx, 1
add di, dx
stosw

;right char done now

mov dl, 80
sub dl, [byte bx+2] ;endx
shl dl, 1
add di, dx
loop @@ll20

;ready for last line

@@ll80:
mov cl, [byte bx] ;startx
shl cx, 1
add di, cx
xor ch, ch
mov cl, [byte bx+2] ;endx
sub cl, [byte bx] ;startx
rep stosw
@@ll99:
ret
ENDP

END Start ; End of program / entry point


================== code end ===================================



--
Thomas Jensen, Denmark

[Dirk Wolfgang Glomp]

Am 30 Oct 2011 15:47:31 GMT schrieb Thomas Jensen:

> Hi
>
> I am a newbie, and I have made a program that generates some pseudo
> random numbers, and print how many times each number come out.
>
> I have two problems;
>
> 1. I am not sure the dynamic memory allocation is correct. I sometimes
> get errors, sometimes not. Specially the free-mem part could be wrong, I
> think. Is it correct what I do - pushing the address returned in ax by
> function 48h/int21h and popping it to es in function 49h/int21h?

I correct it below.

> =========== code start ================================
>
> %TITLE "rs7.asm"

>
> IDEAL
> MODEL small
> STACK 256
>

> NUMTESTS = 10000
>
> DATASEG
> exCode DB 0
> str_syntax DB ??FILENAME, "min max", 0
> str_error1 DB "Error freeing unused mem", 0
> str_error2 DB "Error allocating mem", 0
> str_error3 DB "Error freeing allocated mem", 0
> str_result DB 10 DUP(0)
>
> UDATASEG
> rand_result DW ?
> rand_min DW ?
> rand_max DW ?
>
> CODESEG
>
> ;----> From PARAMS.OBJ
> EXTRN ParamCount:Proc, GetParams:Proc, GetOneParam:Proc
>
> EXTRN AscToBin:Proc, NumToAscii:Proc
> EXTRN NewLine:Proc, StrWrite:Proc
>
> ;----> From RAND4.OBJ
> EXTRN seed_random4:proc, get_random4:proc
>
>
> ;=========================================================================
> Start:
>
> ;-------------------------------------------------------------------------
> ;----> release unused memory
> ;-------------------------------------------------------------------------
>
mov bx, ss
mov ax, es
sub bx, ax

mov ax, sp
add ax, 0Fh
shr ax, 4
add bx, ax

mov ah, 49h
int 21h
jnc @@L1

RBIL->inter61b.zip->Interrup.g
--------D-2149-------------------------------
INT 21 - DOS 2+ - FREE MEMORY
AH = 49h
ES = segment of block to free
Return: CF clear if successful
CF set on error
AX = error code (07h,09h) (see #01680 at AH=59h/BX=0000h)
Notes: apparently never returns an error 07h, despite official docs; DOS
2.1+
code contains only an error 09h exit
DOS 2.1-6.0 does not coalesce adjacent free blocks when a block is
freed, only when a block is allocated or resized
the code for this function is identical in DOS 2.1-6.0 except for
calls to start/end a critical section in DOS 3.0+
SeeAlso: AH=48h,AH=4Ah
--------------------------------------------

> mov di, offset str_error1
> call StrWrite
> jmp Exit
>
> ;-------------------------------------------------------------------------
> ;---->
> ;-------------------------------------------------------------------------
>
> @@L1:
> mov ax, @data ; Set ax to data segment
> mov es, ax ; Set es to data segment
> call GetParams ; Get parameters with ds = PSP
> ; ds is set from getparams

Maybe DS has the address of current the PSP, or maybe not.
If we start this code as a child-application (using function 4B00h int
21h) inside of a parent-aplication, then we have to make sure that we get
the real address of the current PSP, before we can get any commandline
parameter.

RBIL->inter61b.zip->Interrup.h
--------D-2162-------------------------------
INT 21 - DOS 3.0+ - GET CURRENT PSP ADDRESS
AH = 62h
Return: BX = segment of PSP for current process
Notes: this function does not use any of the DOS-internal stacks and may
thus be called at any time, even during another INT 21h call
the current PSP is not necessarily the caller's PSP
identical to the undocumented AH=51h
---------------------------------------------

RBIL->inter61b.zip->Interrup.g
--------D-214B-------------------------------
INT 21 - DOS 2+ - "EXEC" - LOAD AND/OR EXECUTE PROGRAM
AH = 4Bh
AL = type of load
00h load and execute
....

> ;-------------------------------------------------------------------------
> ;----> free allocated memory
> ;-------------------------------------------------------------------------
>
> mov ah, 49h
> pop dx
> mov es, dx
> int 21h
> jnc Exit

If the aplication terminate, then all allocated memory will be free.
So we don´t need to free the memory for to terminate our aplication.

Dirk

[Dirk Wolfgang Glomp]

Am Sun, 30 Oct 2011 22:23:19 +0100 schrieb Bjarni Juliusson:

> This isn't really going to answer any of your questions, but I see this
> all the time and I have to ask:
>

> Why do so many people still run MSDOS on their computers?

Because MSDOS will never die as lomg as it possible to use it.

> Also, 8086? That's a 35 year old processor you have there. I'd like to
> encourage you to learn about assembly language programming, but I have
> to say my best advice would be to forget about the 8086, and enter into
> the 1980s and the wonderful world of the 80386 and the wide variety of
> operating systems avalilable for it. Why make it hard on yourself?
>

> As for MSDOS, I think you will find a proper modern operating system
> gets in your way a lot less, and especially the various Un*x flavours
> are really comfortable for us programmers! Try it!

But we use assembler not for to programm comfortable. It is more an
enthusiast way, isn´t it?

I like DOS for to access all of our hardware and not only for to handle
such things with an unknow driver and many restrictions.

> Also, of course, it's a matter of learning what's useful - if you start
> with 8086/MSDOS, you will then have to partially relearn the way you
> program to be able to write programs that are really useful on modern
> computers and operating systems.

> I started with MSDOS, writing 16-bit assembly code in the mid 1990s,
> when those things were on their way out, but once I tried 32-bit
> assembly on Linux, I realised just how difficult MSDOS and 16-bit
> programming had been and how counterproductive it was to continue doing
> it. I haven't looked back.
>
>

> Bjarni

I start learning x86-assembler using MSDOS debug.exe with an 80286 and
a few later with an 80386. These days i use MSDOS with my intel core2quad.
DOS let us also use all parts of our hardware accept the PM with 32 bit
programming or 64 bit programming. There is no limit with DOS, if we can
boot it on modern hardware.

Dirk

[Bob Masta]

On Tue, 1 Nov 2011 08:04:25 -0700 (PDT), Jim Leonard
<moby...@nospicedham.gmail.com> wrote:

>On Oct 31, 9:43=A0pm, Bjarni Juliusson <bja...@update.uu.se> wrote:
>> Well at least in a couple of the newsgroups I frequent, there seems to
>> be a balls load of people who teleported there from the 80s and
>> apparently brought their computers with them.
>
>As one of Those People(tm) I can tell you why: In the 1980s, we
>marveled at what our machines could do, but lacked the skill and
>knowledge to reproduce that work and build on it. Now that we're
>older and wiser, we can.
>
>I "retroprogram" (for lack of a better word) for a few reasons, the
>most important being a sense of accomplishment that I was unable to
>achieve as a youth. I find it especially fun to write programs that
>would have blown the doors off of 1982 (such as full-screen texture-
>mapping or digital video playback in CGA, a multi-voice digital sound
>engine, etc.). I like surprising the 1982 Me.

Back when the PC first came out, I bought a real-time audio
spectrum analyzer for the lab I was working in. These were
stand-alone hardware units, like a scope. Internally, they
used special hardware to compute FFTs to obtain the
spectrum.

I really wanted a spectrum analyzer for home use, though I
couldn't justify a hardware unit. At the time, it was
"common knowledge" that you couldn't do FFTs on a PC because
PCs were just too darn slow. But all the examples I could
find were written in BASIC or Fortran... nothing in
assembler.

Well, it took a long time for me to get up to speed on both
assembler and FFTs, but the answer is yes, you *can* turn an
old 8088 PC/XT into a real-time spectrum analyzer. Spectrum
update rate is several per second, typical for hardware
units of the day. That became the basis for my Daqarta for
DOS software.

Now that the world has moved on to Windows, the DOS version
is available for free at:

<www.daqarta.com/download.htm>

But note that it WILL NOT RUN under Windows XP or later, and
only supports ISA-bus Sound Blasters and a few other sound
cards. (Though you can make a really simple "sound card"
that I call the LPTX , using only a handful of resistors
that you solder into a DB25 connector and plug into the
parallel port.)

[Thomas Jensen]

On Wed, 02 Nov 2011 07:07:08 +0100, Dirk Wolfgang Glomp wrote:


Thank you for taken time to help me.

=== snip ===

>> ;-------------------------------------------------------------------------
>> ;----> release unused memory
>> ;-------------------------------------------------------------------------
>>
> mov bx, ss
> mov ax, es
> sub bx, ax
>
> mov ax, sp
> add ax, 0Fh
> shr ax, 4
> add bx, ax
>
> mov ah, 49h
> int 21h
> jnc @@L1

I'm sorry, but this doesn't make sense. You add some values to bx, but
never use them. Function 49h don't use bx, but expect the address of a
segment in es, which you doesn't set. Right now es points to psp, so it
will free all memory allocated to the program. The aim is to release only
the un-used memory.

> INT 21 - DOS 2+ - FREE MEMORY
> AH = 49h
> ES = segment of block to free
> Return: CF clear if successful
> CF set on error
> AX = error code (07h,09h) (see #01680 at AH=59h/BX=0000h)

I think you have misunderstood something because I talk about "releasing"
memory, while, what I in fact do, is "re-allocating" memory with function
4Ah/int21h.

I am not 100% sure what I do is correct, but this is what I think I do:

;-------------------------------------------------------------------------
;----> release unused memory
;-------------------------------------------------------------------------

mov bx, es ; start of program (psp)
mov ax, ss ; start of last segment (ss)
sub ax, bx ; size of prog without stack

mov cx, sp ; size of stack
shr cx, 4 ; convert to paragraphs
inc cx
add ax, cx ; prog size + stack size

mov bx, ax ; new size of allocated memory
mov ah, 4Ah ; es still points to
int 21h ; start of program (psp)

jnc @@L1 ; error?

mov di, offset str_error1
call StrWrite
jmp Exit

=== snip ===

>> @@L1:
>> mov ax, @data ; Set ax to data segment
>> mov es, ax ; Set es to data segment
>> call GetParams ; Get parameters with ds = PSP
>> ; ds is set from getparams
>
> Maybe DS has the address of current the PSP, or maybe not. If we start
> this code as a child-application (using function 4B00h int 21h) inside
> of a parent-aplication, then we have to make sure that we get the real
> address of the current PSP, before we can get any commandline parameter.

Well, you're right. It is propably safer to get psp from funtion 62h/
int21h... but as long as you know ds are not set by other parts of the
program, I think it is safe to assume it points to psp.


=== snip ====


> If the application terminate, then all allocated memory will be free. So
> we don´t need to free the memory for to terminate our application.
>

Cool. Then that's not the problem. I think the random function works now
(I have not have time to test it properly yet), but I do sometime get
errors when re-allocating memory. Executing the program again imitatively
after an error can result in success or in error. Sometimes I get error 3
or 4 times, and then success. Strange... Hmm... maybe some of the ram
modules have faults? I better look into that possibility.


--
Thomas Jensen, Denmark

[Jim Leonard]

On Nov 2, 8:37 am, N0S...@daqarta.com (Bob Masta) wrote:
> Well, it took a long time for me to get up to speed on both
> assembler and FFTs, but the answer is yes, you *can* turn an
> old 8088 PC/XT into a real-time spectrum analyzer.  Spectrum
> update rate is several per second, typical for hardware
> units of the day.

Thank you for the free license -- I can't wait to see what realtime
FFTs look like on an 8088. Just as impressive is the fact that you
don't require an 8087 (although I'm surprised you don't support one,
either).

[Bjarni Juliusson]

On 11/01/2011 04:04 PM, Jim Leonard wrote:
> On Oct 31, 9:43 pm, Bjarni Juliusson<bja...@update.uu.se> wrote:
>> Well at least in a couple of the newsgroups I frequent, there seems to
>> be a balls load of people who teleported there from the 80s and
>> apparently brought their computers with them.
>
> As one of Those People(tm) I can tell you why: In the 1980s, we
> marveled at what our machines could do, but lacked the skill and
> knowledge to reproduce that work and build on it. Now that we're
> older and wiser, we can.

And ain't it grand? The graphics of modern computer games sting my eyes.
Those are just lots of pixels, not _graphics_!

> I "retroprogram" (for lack of a better word) for a few reasons, the
> most important being a sense of accomplishment that I was unable to
> achieve as a youth. I find it especially fun to write programs that
> would have blown the doors off of 1982 (such as full-screen texture-
> mapping or digital video playback in CGA, a multi-voice digital sound
> engine, etc.). I like surprising the 1982 Me.

There's something special about getting those simple machines to do
things their designers never expected could be done. You have exclusive
access to the whole machine and you know every detail of how it works.

>> Where do you even buy floppy disks?
>
> They come with our retrocomputers. Or, if you're sufficiently old,
> you still have them. I still have some of my old Apple 2 floppies.

Yes yes, I know. I have a bunch of 8" floppies even.

>> But as for the 16-bit x86 days, I say good riddance! The C64 at least is
>> a nice platform, into the design of which seems to have gone some not
>> insignificant amount of thought.
>
> The more I probe into the PC, the more I'm impressed with what they
> were able to put into it with very little time and limited to off-the-
> shelf components. For example, someone had the foresight at the last
> minute to tie one of the timer lines to the speaker such that very
> short timing periods were possible, enabling clear digitized sound
> output.

I wouldn't go so far as to call it "clear", and I doubt it's the reason
they tied the speaker to the timer...

>> Programming the 6510 CPU involves all the register shuffling of
>> programming the 8086, but with the 6510 it's not because it's a
>> complicated architecture, but because it's a simple one! Some 3500
>> transistors compared to over 20000 in the 8086 - you had your 8-bit
>> accumulator, you could add and subtract and do the logical operations,
>> and then they threw in two index registers for speed.
>
> I commented on 6502 vs. 8088 here, if you're curious:
> http://trixter.oldskool.org/2011/06/04/at-a-disadvantage/

Nice comparison. :) Do you have any idea why they chose the 8088 of all
CPUs? Can't imagine it was cheaper than a 6502 or a Z80?

>> But while the C64, sometimes
>> derided for its poor graphics capabilities, had 320x200 16-colour tiled
>> or bitmapped graphics with hardware sprites and retrace interrupts, the
>> PC had the (optional) CGA card which gave you 320x200 in only 4 colours,
>> no sprites, no tiles, no retrace interrupts. Who remembers playing games
>> in cyan and magenta back in the day?
>
> Both platforms had graphics limitations; I think it's disingenuous to
> paint (pun intended0 the C64 as vastly surperior.

And I don't think I did, but I mentioned the graphics anyway as one part
of the comparison.

> Each CGA pixel was
> individually addressable; in C64 16-color mode, they were not and you
> were limited to 3 colors per tile + background. CGA could also do
> high-res line art 640 pixels across, whereas C64 could not. So they
> both had pros and cons.

Yes alright, and you know I actually started describing the details but
decided to skip them because they were boring. Both have limitations to
which colours you can use together, and in fact the C64's limitations
are worse than you said: each tile is limited to only two colours, plus
two colours that are the same for all tiles on the screen. Tiled
graphics are nice though; they are fast and save a lot of memory.
Sprites are nice too, even though the C64 only had eight of them.

>> While the C64 included the fantastic 6581 sound chip, which gave you
>> three independent voices of sound, each with three waveforms plus noise,
>> 16-bit pitch covering eight octaves, and an ADSR envelope generator,
>> plus a common programmable analog filter, the PC gave you no sound at
>> all. Well, it could go "beep" I guess.
>
> Agreed.

Well I would have trained my spam filter on you if you hadn't agreed on
that one. :)

> The BIOS allowed for extremely small programs to be written, if you
> could take the speed penalty. (Why so much hate for the BIOS? The
> BIOS was one of the things that made the original Mac possible,
> although they called it a ROM. Maybe if they called it a BIOS there
> would be the same stigma?)

My hate is for the PC BIOS, not for firmware in general. That wouldn't
make any sense. And I admit, some of the badness of the BIOS comes from
incremental addition of features over the years. Try asking it how much
memory there is in the computer, Jim. :(

> I'd argue that the 8253 timer was the chip that did everything in a
> PC :-)

Maybe. :D But I think putting the control of the (bizarre) "A20 gate"
and the (286 era) CPU reset function in the keyboard controller put a
lot of responsibility on the little bugger.

> I'm surprised you're arguing against the PC's floppy controller when
> your comparison is the C64.

Don't even know what controller it uses, since you don't see it.
Couldn't agree with you more about the floppy interface though, I don't
understand what they were thinking. Never bothered me though, since I
never had a floppy drive. :)

I haven't done any floppy I/O programming on a PC in a while, but as I
recall the controller tries to be really clever but ends up providing
very limited configurability. The result is that you simply can't read
lots of floppy formats used with the same physical drives on other
platforms, even though PC floppies can often be used on those other
platforms.

A little project I've been thinking of for a few years is a "floppy
reading machine", a little computer with floppy drives of the different
varieties and controller hardware that allows the machine to be
configured to read any possible low-level format. I think I started
thinking about it one day when a club here at the university came to us
at Update (the computer club) with an old 8" floppy and asked us if we
could read it for them. We said we probably could, and then we tried
with several different machines without success.

The floppy was written with a Norsk Data ND500, and uses some format we
haven't been able to figure out. If you didn't guess it, there aren't a
whole lot of ND500s around, so we still haven't been able to read the
floppy after several years. We have some contact with one individual in
Norway who is supposed to have a machine of that particular type
(toresbe, if you know him), but we don't visit Norway all that often and
last time we did he wasn't in town.

So it would be nice to have a machine that could sense the read signal
from the drive, give you some statistics, and let you configure exactly
how you want to try to read the disk, all with a nice purpose-built user
interface!

>> I know all about this charm, but I wouldn't associate the 8086 with it!
>
> I find the 1-byte CISC instructions charming. xlat, movs, lods, stos,
> are single-byte opcodes and get a lot done. And who doesn't love a
> built-in MUL/IMUL/DIV/IDIV? Sure, they're slow on 8086, but at least
> they're present.

Can I just ask if you've done any programming on the 68000? :)

[Bjarni Juliusson]

On 11/01/2011 08:08 PM, Rod Pemberton wrote:
> "Bjarni Juliusson"<bja...@update.uu.se> wrote in message
> news:j8nmcn$m6i$1...@Iltempo.Update.UU.SE...
>> On 10/31/2011 09:26 AM, Thomas Jensen wrote:
>
>> In alt.os.development they all want to know how to write
>> a bootloader for floppy disks.
>
> Using a floppy to execute bootstrap code is _easy_.

It's such a solved problem. :(

>> I might add that I myself am an avid retrocomputing fan - my collection
>> includes both PDP-11s, DG Eclipses, VAXen, a DG Nova 3, and a
>> PDP-10, I'm currently repairing a rare PDP-12 together with friends
>> at the computer club, [...]
>
> Could you or your friends fill in some missing PDP info on this
> Wikipedia page?
> http://en.wikipedia.org/wiki/Word_(computer_architecture)

I'll have a look at it!

> I'm really interested in the sizes for the PDP-7. Wikipedia also has
> specific pages on PDP-1, PDP-6, PDP-8, PDP-10 and PDP-11.

It also has a page on the LINC-8, originally written by me, with a photo
of a LINC-8 on display here at Uppsala University! We were *very* happy
when we found it. :)

Also, the WP article for "Programmed Data Processor" has a picture of
the aforementioned PDP-12 at Update which I took and which I am rather
proud of.

>> And fast it was, impressively so, and given that it was introduced at a
>> small fraction of the price of all of its competitors, it was a hit.
>
> AIR, it was the first microprocessor with pipelining.

Just one level, but it's impressive. I can go on and on about how
awesome the 6502 is!

>> I don't see MSDOS in there among the ancestors of modern
>> operating systems. I see VMS, UNIX, Multics, [...]
>
> I too learned how to program on the C64. I've also programmed DEC
> VAX, Stratus Continuum's, etc. I still use DOS to this day. You're not
> giving DOS anywhere near enough credit, IMO.

Bah.

>> I see VMS, UNIX, Multics, and a bunch of other systems that
>> pioneered ideas that are used in modern operating systems today:
>
> Most individuals don't need any of those advanced features. Yes, they are
> important to businesses or universities, etc. E.g., for a single individual
> using a PC:

You are entitled to that opinion, but it doesn't change the fact that
MSDOS didn't introduce anything new and was highly unspectacular. I was
answering Thomas on his comment about the importance of knowing the
reason why things are as they are today.

>> time sharing,
> Not needed. Most systems an individual would use are only used by a single
> person, so time sharing between multiple useres is not needed. Time-based
> multi-tasking is nice for individuals, although it's not needed either.

Er, OK. Sure, not needed, but nothing really is...

>> high-level programming languages,
> Not needed. Most individual computer users are not programmers. C is
> great. The rest are mostly horrid to program.

I laughed and then I agreed! :D

>> user accounts,
> Not needed. Why do you need user accounts on a computer used by a single
> individual? I don't know why Linux and Unix insist on this horrid feature.
> It's one of the first things I rip out of a new Linux install. Boot. Put
> me at a prompt immediately. Don't ask me for account info on a PC I own.

Wow. Well, OK, if you limit yourself only to single-user systems (it's
been a while since I used one of those) then you don't really need
accounts, but I still really recommend that you don't run as root all
the time, you know. The reason Linux and the other Unices have user
accounts is because they aim to be general-purpose operating systems,
not to be run only on video games and single-user PCs.

It's also nice to be able to run the same operating system on your PC
even when you suddenly find yourself with two users of it and don't want
to constantly get on each others nerves by messing up all the
preferences, so even such a single-user oriented operating system as
Windows has multiple user accounts (and an administrator account to
protect the operating system from the average user).

>> file systems,
> Needed. How else are you going to save files?

Not needed much more than the other things. If you're the only user,
just put the files where there's free space and remember where you put
them, right?

>> file permissions,
> Not needed. These are mostly a nuisance on computers used by a single
> individual.

Still though, wasn't speaking of single-user systems but generally about
computers, and even then I really like both the x bit and being able to
write-protect things I don't want to mess up, like the operating systems
and backups, when you keep them on the same machine. For the general
case where you have more than one user, you just have to have file
permissions.

>>job control,
> Not needed. Most invidual computers have directly connected devices.

Don't know exactly what you mean by that?

Job control, you know, process groups, sessions, foreground, background.

>>memory protection,
> Not needed. See C64, DOS, etc.

Well no, not needed, but even if you are the only user of the computer,
you still don't like it when any one of all the programs running on the
computer can at any moment accidentally either crash the operating
system or alter the behaviour of other processes. When I think of the
number of times I've seen a segfault in my life (or seen Windows 9x go
over a cliff (sometimes destroying parts of the file system and/or
refusing to boot again) because I typed something wrong), I'm very happy
I have memory protection (in other operating systems). The C64 and MSDOS
couldn't run more than one program at one time anyway, so it it's less
relevant there, especially on the C64 where you can't clobber the
operating system. :)

>>paging,
> Not needed, but nice.

Very, very, nice. Gone are the days of swapping entire processes to the
drum to schedule the next process. It also gives you shared memory,
shared libaries, etc. Paging is a very significant improvement to the
abilities of computers.

>>block caches,
> ?

Keeping file system data in memory in case someone wants to read it
again. Makes things a whole lot faster, and the gain becomes greater
with increased difference in speed between the CPU and a disk.

>>dynamic linking,
> Not needed, but nice, if you're a programmer ... but most who use computers
> *aren't* programmers.

You don't have to know how it works to enjoy its benefits you know. It
gives you shared libraries, which saves memory, and it allows you to
install new versions of libraries without having to recompile all your
programs (which is even more of a hassle if you don't know what
"compile" means), it gives you plugin loading and whatnot. And even if
you aren't a programmer, every single program you run was written by
one, and the easier their job is the better the programs you get to run.

>>networking,
> Needed.

Not needed. See C64, DOS, etc.

>>graphical user interfaces,
> Not needed, but nice.

We agree on this one!

[Bjarni Juliusson]

On 11/01/2011 07:49 PM, Rugxulo wrote:
> Hi,
>
> On Nov 1, 10:04 am, Jim Leonard<mobyga...@nospicedham.gmail.com>
> wrote:
>> On Oct 31, 9:43 pm, Bjarni Juliusson<bja...@update.uu.se> wrote:
>
> Bjarni, check out Paku Paku, a modern retro game written (earlier this
> year) to run on the original IBM PC (8088). It uses a tweaked CGA mode
> to get more than 4 colors.
>
> http://my.opera.com/deathshadow/blog/

Thanks, I'll have a look!

> Again, I'm probably telling you something you already know, but you
> can reprogram the PIT to achieve digital sound from the PC speaker.

And the same goes for the C64. And you could write program loops of
carefully selected lengths on a PDP-8, place a radio next to it, and
play music through magnetical interference, but the PDP-8 still didn't
have sound hardware.

> Embrace the kludge that is 8086, resistance is futile! :-))

I know. :(

[Bjarni Juliusson]

On 11/02/2011 02:37 PM, Bob Masta wrote:
>
> Well, it took a long time for me to get up to speed on both
> assembler and FFTs, but the answer is yes, you *can* turn an
> old 8088 PC/XT into a real-time spectrum analyzer. Spectrum
> update rate is several per second, typical for hardware
> units of the day. That became the basis for my Daqarta for
> DOS software.
>
> Now that the world has moved on to Windows, the DOS version
> is available for free at:
>
> <www.daqarta.com/download.htm>

Well done!

> But note that it WILL NOT RUN under Windows XP or later, and
> only supports ISA-bus Sound Blasters and a few other sound
> cards. (Though you can make a really simple "sound card"
> that I call the LPTX , using only a handful of resistors
> that you solder into a DB25 connector and plug into the
> parallel port.)

Ah, I remember as a teenager, building a sound card for the parallel
port out of a handful of resistors, some diodes and a transistor and a
piece of plywood. Designed it with a friend, took just a few minuntes!
Played Prince of Persia on it too!

[Bjarni Juliusson]

That seems to me like a rather minor annoyance. I dunno.

But the instruction set, man! And the register file!

[Bjarni Juliusson]

On 11/01/2011 08:14 PM, Rugxulo wrote:
> Hi,
>
> On Nov 1, 12:44 am, Bjarni Juliusson<bja...@update.uu.se> wrote:
>> On 10/31/2011 09:26 PM, Rugxulo wrote:
>>
>> > You know you can write 32-bit code in DOS, right?
>>
>> Yes, and I've done it. Oh boy it sucked. DOS was still there.
>
> Then you were using the wrong tools and/or wrong "DOS". There are
> many. Which did you use last? (A lot has changed over the years.)

Hum, I don't remember. Well, it was probably MSDOS 6.22 or something,
but I don't know about the tools. Borland C++? DJGPP? Assembly?

>> For most people, not having a proper shell, multitasking, a real file
>> system, and all those other things that operating systems usually have,
>> is indeed a disadvantage.
>
> Again, wrong tools. You can find a myriad of shells, multitasking,
> file systems, etc. if you look hard enough. It's not "DOS"' fault that
> you don't know enough about it. Anything sucks when you don't
> understand it.

Well all right, if we only count the kernel then DOS isn't quite as
awful, but the kernel of that operating system also is not very
extensive. DOS gets better if you add lots of stuff to it, but the more
you add the less relevant the argument becomes too. Until you've added a
PC emulator and installed BSD on it.

>> I've done a whole lot of programming in DOS, I've done a whole lot of
>> programming in Linux, and I've done a fair amount of programming on the
>> sort of computers where you have only a panel of lights and switches and
>> have to enter your programs byte by byte into the memory in binary, and
>> the difference in difficulty and discomfort is actually about the same
>> between the latter type and DOS and between DOS and Linux.
>
> Depends on what you're trying to do.

True I guess.

[Bjarni Juliusson]

That's a good point of course. I was refering mostly to DOS as a
development environment. But even for "getting to know the machine", it
depends on whether it's controlling the I/O devices you are interested
in (in which case you don't have to do it in assembly) or whether it's
understanding how programming works on a computer at the assembly level.
Also, if you're getting at the hardware I/O level, you don't really need
DOS anyway.

But fine, I'll stop the DOS bashing for a week.

[Bjarni Juliusson]

On 11/01/2011 07:57 PM, Rod Pemberton wrote:
> "Bjarni Juliusson"<bja...@nospicedham.update.uu.se> wrote in message
> news:j8kf88$5g4$1...@Iltempo.Update.UU.SE...
>

> I don't have an x86 microprocessor older than a 486 DX2-66. It's packed
> away somewhere. The older ones were given to a former friend who, I
> suspect, sold them as collectibles ... The oldest x86 microprocessor I have
> that is in a bootable machine is a 233Mhz Pentium. So, he is definately "PC
> retro-computing", like Jim, for using something that old.

I think I have a 186 or two if I look. :) Oldest bootable is a 286, have
a couple of 386s, a 486...

>> As for MSDOS, I think you will find a proper modern operating system
>> gets in your way a lot less, and especially the various Un*x flavours
>> are really comfortable for us programmers! Try it!
>
> Are you joking?
>
> DOS is 16-bit real-mode code. There is no memory protection, no paging.
> You can program ports, keyboards, mice, and A20 directly. Nothing gets in
> the way on DOS. You can run 32-bit or 64-bit code. If need be, DOS can
> have it's state stopped and saved, be removed from memory, and be reloaded
> and restored when needed again.

Ah yes, slight misunderstanding Rob. I was refering to it in terms of
usability as an operating system - that is, how you would normally use
your computer: shell, file system, tools, package system, drivers, ...

Of course DOS gets in the way less in terms of memory protection and
that sort of thing, that goes without saying.

Since Thomas was just writing a random number generator, and even
allocating memory nicely, I made the natural assumption that he was not
trying to do bare-metal programming and I/O control.

[Bjarni Juliusson]

On 11/01/2011 06:41 PM, Jim Leonard wrote:
> On Oct 31, 11:35 pm, Bjarni Juliusson<bja...@update.uu.se> wrote:
>>
>> > Still, don't
>> > forget that DOS had a decade or two of good software (esp. games).
>>
>> I seem to recall that the games were without exception better on the
>> other platforms on which they were released. :/
>
> In the 1980s, this was true with only a handful of exceptions (Flight
> Simulator, for example). In the 1990s, this was false, as the PC's
> raw horsepower overwhelmed the other platforms.

You're right about that. In the 1990s there was a point when, in my
view, video game machines stopped being any fun hardware-wise, since it
had become a matter of computational speed essentially.

Then also my experience of video games is mostly limited to the 1980s
and early 1990s, because for one thing I guess I grew up, but also the
overall quality of games dropped sometime in he late 90s and the games
seemed to become mostly just clones of one another. I remember I played
Unreal when it was new and really hyped, and I just thought well, I
played this game when it was called Wolfenstein 3D...

I suspect I am possibly a bitter old fart.

>> How much support does Windows still have for DOS programs, by the way?
>
> If you run a 32-bit version of Windows, they still run, barring a few
> exceptions.

Impressive. What are the exceptions? :)

[Bjarni Juliusson]

On 11/02/2011 08:52 AM, Dirk Wolfgang Glomp wrote:
> Am Sun, 30 Oct 2011 22:23:19 +0100 schrieb Bjarni Juliusson:
>
>> This isn't really going to answer any of your questions, but I see this
>> all the time and I have to ask:
>>
>> Why do so many people still run MSDOS on their computers?
>
> Because MSDOS will never die as lomg as it possible to use it.

:)

>> As for MSDOS, I think you will find a proper modern operating system
>> gets in your way a lot less, and especially the various Un*x flavours
>> are really comfortable for us programmers! Try it!
>
> But we use assembler not for to programm comfortable. It is more an
> enthusiast way, isn´t it?

Well, I'm an assembly enthusiast and I write my code mostly in Linux to
run on Linux. It's the assembly I like, not sitting in 80x25 text mode,
printing all the documentation on paper, and rebooting when my code
didn't work.

And before Rod or anyone else starts telling me how some of that
technically can be considered improper, I just promised Nathan I'd stop
bashing DOS so let's just leave it!

> I like DOS for to access all of our hardware and not only for to handle
> such things with an unknow driver and many restrictions.

You sound like you might like programming microcontrollers. It's one of
my hobbies, and I worked with it for a short time. Gimme a PIC and a
breadboard, any day! :)

> I start learning x86-assembler using MSDOS debug.exe with an 80286 and
> a few later with an 80386. These days i use MSDOS with my intel core2quad.
> DOS let us also use all parts of our hardware accept the PM with 32 bit
> programming or 64 bit programming. There is no limit with DOS, if we can
> boot it on modern hardware.

I started out with DEBUG too, on a 386SX. As for fiddling with PC
hardware, I'm personally partial for operating system development rather
than playing with DOS. I have an enormous lot of notes in notebooks
about the perfect operating system I am certainly going to write one
day. Might collect them together and do something about it...

[Robert Wessel]

On Thu, 03 Nov 2011 02:18:56 +0100, Bjarni Juliusson
<bja...@nospicedham.update.uu.se> wrote:

>On 11/01/2011 07:57 PM, Rod Pemberton wrote:
>> "Bjarni Juliusson"<bja...@nospicedham.update.uu.se> wrote in message
>> news:j8kf88$5g4$1...@Iltempo.Update.UU.SE...
>>
>> I don't have an x86 microprocessor older than a 486 DX2-66. It's packed
>> away somewhere. The older ones were given to a former friend who, I
>> suspect, sold them as collectibles ... The oldest x86 microprocessor I have
>> that is in a bootable machine is a 233Mhz Pentium. So, he is definately "PC
>> retro-computing", like Jim, for using something that old.
>
>I think I have a 186 or two if I look. :) Oldest bootable is a 286, have
>a couple of 386s, a 486...

I'm assuming you mean 8086 or 8088 based systems.

While a handful of vendors did actually ship 186 (or 188) based PCs
(or PC like machines), they were quite rare. The 186 had a whole
bunch of integrated hardware, but essentially none of it was PC
compatible (one or two vendors did do PC compatibles, but basically
had to disable all the 186's onboard peripherals). For the modest
performance improvement* the 186 had over the 8086, it really wasn't
worth the trouble, particularly since the 286 arrived at basically the
same time. And if you wanted a slightly faster 8086, the NEC V30/V20
were available, and were pretty close to the 80186/8 on a
clock-for-clock basis, while being pin-compatible (unlike the 186,
which was completely different from the 8086/8).

The 186 found its main niche as a controller, and in that role, it
long outlived the 286.


*Many instructions ran a clock or three faster (basically address
generation was beefed up), and there were a few new instructions, but
the chip itself was not available in faster speeds than the 8086
(until later). Worse, the 8088's problem (as well as the 80188's),
was that they were memory limited almost all the time, so running
instructions a bit faster didn't accomplish much most of the time.

[Dirk Wolfgang Glomp]

Am Thu, 03 Nov 2011 02:39:52 +0100 schrieb Bjarni Juliusson:

> On 11/02/2011 08:52 AM, Dirk Wolfgang Glomp wrote:
>> Am Sun, 30 Oct 2011 22:23:19 +0100 schrieb Bjarni Juliusson:
>>
>>> This isn't really going to answer any of your questions, but I see this
>>> all the time and I have to ask:
>>>
>>> Why do so many people still run MSDOS on their computers?
>>
>> Because MSDOS will never die as lomg as it possible to use it.
>
> :)
>
>>> As for MSDOS, I think you will find a proper modern operating system
>>> gets in your way a lot less, and especially the various Un*x flavours
>>> are really comfortable for us programmers! Try it!
>>
>> But we use assembler not for to programm comfortable. It is more an
>> enthusiast way, isn´t it?
>
> Well, I'm an assembly enthusiast and I write my code mostly in Linux to
> run on Linux. It's the assembly I like, not sitting in 80x25 text mode,
> printing all the documentation on paper, and rebooting when my code
> didn't work.

Under pure DOS we can use the VESA-Bios and not only the text mode.
(For more information about the Vesa-Bios look into the public document
"vbe3.pdf" from vesa.org (need register and/or login).)

With my Colorfull GTX 295 i can switch to the native widescreen resolution
1920x1200 of my 28"(16:10)-LCD using the VESA-Bios. For a simple text
output in this mode we can use (and maybe enlarge) the charakter font
of any ASCII stored inside of the VGA-Bios, or we can use better scalable
vector-fonts if we want.

> And before Rod or anyone else starts telling me how some of that
> technically can be considered improper, I just promised Nathan I'd stop
> bashing DOS so let's just leave it!
>
>> I like DOS for to access all of our hardware and not only for to handle
>> such things with an unknow driver and many restrictions.
>
> You sound like you might like programming microcontrollers. It's one of
> my hobbies, and I worked with it for a short time. Gimme a PIC and a
> breadboard, any day! :)

Yes i like it, but i learn slowly.

Dirk

[Bob Masta]

On Wed, 2 Nov 2011 08:38:14 -0700 (PDT), Jim Leonard
<moby...@nospicedham.gmail.com> wrote:

>On Nov 2, 8:37=A0am, N0S...@daqarta.com (Bob Masta) wrote:
>> Well, it took a long time for me to get up to speed on both
>> assembler and FFTs, but the answer is yes, you *can* turn an

>> old 8088 PC/XT into a real-time spectrum analyzer. =A0Spectrum

>> update rate is several per second, typical for hardware
>> units of the day.
>
>Thank you for the free license -- I can't wait to see what realtime
>FFTs look like on an 8088. Just as impressive is the fact that you
>don't require an 8087 (although I'm surprised you don't support one,
>either).

I didn't use the 8087 because everything is done with
integer math. (Sound card data is just a list of integers,
after all.) In fact, I still use integer math for the FFTs
in the current Windows version.

[Dirk Wolfgang Glomp]

Ups, your are right. We have to use function AH=4Ah for to resize.

--------D-214A-------------------------------
INT 21 - DOS 2+ - RESIZE MEMORY BLOCK
AH = 4Ah
BX = new size in paragraphs
ES = segment of block to resize

Return: CF clear if successful
CF set on error

AX = error code (07h,08h,09h) (see #01680 at AH=59h/BX=0000h)
BX = maximum paragraphs available for specified memory block
Notes: under DOS 2.1-6.0, if there is insufficient memory to expand the
block
as much as requested, the block will be made as large as possible
DOS 2.1-6.0 coalesces any free blocks immediately following the block
to be resized
SeeAlso: AH=48h,AH=49h,AH=83h
--------------------------------

> I am not 100% sure what I do is correct, but this is what I think I do:

But i am sure your code below is correct. Sorry for my mistake in my code.

Additianal take a look in Ray Duncan "Advanced MS-DOS Programming"
Chapter 11 Memory Management beginning on page 128.
http://www.ece.ul.ie/homepage/tom_newe/Modules/CE4204/advdos-Duncan.pdf

Ok.

>> If the application terminate, then all allocated memory will be free. So
>> we don´t need to free the memory for to terminate our application.
>>
>
> Cool. Then that's not the problem. I think the random function works now
> (I have not have time to test it properly yet), but I do sometime get
> errors when re-allocating memory. Executing the program again imitatively
> after an error can result in success or in error. Sometimes I get error 3
> or 4 times, and then success. Strange...
> Hmm... maybe some of the ram
> modules have faults? I better look into that possibility.

Thats curious for me.

Dirk

[Bjarni Juliusson]

On 11/03/2011 06:05 AM, Robert Wessel wrote:
> On Thu, 03 Nov 2011 02:18:56 +0100, Bjarni Juliusson
> <bja...@nospicedham.update.uu.se> wrote:
>>
>>I think I have a 186 or two if I look. :) Oldest bootable is a 286, have
>>a couple of 386s, a 486...
>
> I'm assuming you mean 8086 or 8088 based systems.

Nope, don't have any of those that I can remember. I have a couple of
controller boards for something, don't even remember what, that have
186s on them. That's why I don't consider them "bootable systems".

> The 186 found its main niche as a controller, and in that role, it
> long outlived the 286.

Exactly. :)

[Terje Mathisen]

Bob Masta wrote:
> I didn't use the 8087 because everything is done with
> integer math. (Sound card data is just a list of integers,

Obviously the right thing to do on an 8088.

> after all.) In fact, I still use integer math for the FFTs
> in the current Windows version.

Ouch!

Integers-in-SSE I hope?

With SSE2 and above, implementing FFTs in FP is significantly easier you
know. :-)

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

[Bob Masta]

On Fri, 04 Nov 2011 11:06:48 +0100, Terje Mathisen
<"terje.mathisen at tmsw.no"@giganews.com> wrote:

>Bob Masta wrote:
>> I didn't use the 8087 because everything is done with
>> integer math. (Sound card data is just a list of integers,
>
>Obviously the right thing to do on an 8088.
>
>> after all.) In fact, I still use integer math for the FFTs
>> in the current Windows version.
>
>Ouch!
>
>Integers-in-SSE I hope?
>
>With SSE2 and above, implementing FFTs in FP is significantly easier you
>know. :-)

Actually, I didn't know. <g> (I haven't ventured into SIMD
waters.) A quick Google search just now hasn't clarified
this. Are you talking about using SIMD to do 4 decimated
"quarters" of a single FFT? Seems like the indexing would
get rather hairy, but as I say I haven't really looked into
it.

One thing I've noticed in the past is that FFT code
libraries recompute sine and cosine values every time the
FFT is run. I got a huge speedup by computing all the trig
values ahead of time, putting them in the order the FFT
would need them, and then just pulling each from memory as
needed. But maybe now the penalty for memory accesses is
worse than the cost of recomputing?

[James Van Buskirk]

"Bob Masta" <N0S...@daqarta.com> wrote in message
news:4eb3e25...@news.eternal-september.org...

> On Fri, 04 Nov 2011 11:06:48 +0100, Terje Mathisen
> <"terje.mathisen at tmsw.no"@giganews.com> wrote:

>>With SSE2 and above, implementing FFTs in FP is significantly easier you
>>know. :-)

> Actually, I didn't know. <g> (I haven't ventured into SIMD
> waters.) A quick Google search just now hasn't clarified
> this. Are you talking about using SIMD to do 4 decimated
> "quarters" of a single FFT? Seems like the indexing would
> get rather hairy, but as I say I haven't really looked into
> it.

It's actually tricky to get FFTs to work on SSE2. If you don't
choose your algorithm according to the hardware, you have to be
careful that you don't use all your resources doing data swizzling.
SSE2 works best when you can write a big chunk of your algorithm
as a tensor product, see the book by Tolimieri, An, and Lu or my
paper on FFTs for approaches like this. Also it matters whether
you really need the FFT as you would to get the spectrum of if
you really just want to do convolution when, as I showed in my
paper, it's (a little) easier do just do partial FFTs and also
this makes it easier to set up the computation as a tensor product.

> One thing I've noticed in the past is that FFT code
> libraries recompute sine and cosine values every time the
> FFT is run. I got a huge speedup by computing all the trig
> values ahead of time, putting them in the order the FFT
> would need them, and then just pulling each from memory as
> needed. But maybe now the penalty for memory accesses is
> worse than the cost of recomputing?

For a sufficiently large FFT there will be one course of trig
functions that only gets used once. For big FFTs like this, you
factor the algorithm into two or three steps that fit into cache
and splice the results together via Cooley-Tukey and it's the
splice steps that need the full run of trig functions. You
definitely want to precompute the trig functions for the in-cache
parts, but likely not for the splice steps.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[Terje Mathisen]

Bob Masta wrote:
> On Fri, 04 Nov 2011 11:06:48 +0100, Terje Mathisen
> <"terje.mathisen at tmsw.no"@giganews.com> wrote:
>
>> Bob Masta wrote:
>>> I didn't use the 8087 because everything is done with
>>> integer math. (Sound card data is just a list of integers,
>>
>> Obviously the right thing to do on an 8088.
>>
>>> after all.) In fact, I still use integer math for the FFTs
>>> in the current Windows version.
>>
>> Ouch!
>>
>> Integers-in-SSE I hope?
>>
>> With SSE2 and above, implementing FFTs in FP is significantly easier you
>> know. :-)
>
> Actually, I didn't know.<g> (I haven't ventured into SIMD
> waters.) A quick Google search just now hasn't clarified
> this. Are you talking about using SIMD to do 4 decimated
> "quarters" of a single FFT? Seems like the indexing would
> get rather hairy, but as I say I haven't really looked into
> it.

You use SSE to run 4 iterations simultaneously, if you have to you
rearrange processing order so that you can work on 4 consecutive
elements at once.

The most important consideration is that you'll probably have to
introduce somewhat more funky twiddle factor lookups, but then you use
the same factors for a full inner iteration.

(For small FFTs (up to 256 maybe?) you can consider doing the twiddle
factor reordering up front, during code generation time, setting up a
custom table for each of the major iterations just so you can use linear
accesses.)

>
> One thing I've noticed in the past is that FFT code
> libraries recompute sine and cosine values every time the
> FFT is run. I got a huge speedup by computing all the trig
> values ahead of time, putting them in the order the FFT
> would need them, and then just pulling each from memory as
> needed. But maybe now the penalty for memory accesses is
> worse than the cost of recomputing?

Oh no, that's horrible!

The twiddle factors should probably be generated at compile time, or
(worst case) during program startup when you know the sizes needed.

I have even seen code which uses NR style iterations to generate the
next sin/cos twiddle pair based on the previous values and the rule for
adding two angles:

If you work with double precision this leaves more than sufficient
accuracy for a float (single prec) lookup table to be generated, and you
only need a single sin/cos value, corresponding to the step size, to
start the process.

I have a feeling you could even do this without any sin/cos hw or
library code at all, just starting from the Taylor series:

sin(x) = x - x^3/3! + x^5/5! - x^7/7! + ...

sin(pi/1024) = sin(0.0031...)

Even disregarding the divisor part, this gives 5 more digits of
precision for each additional term, so 3-4 terms is enough for double.

If even this is too slow, then I'd compile in sin/cos for the smallest
step size supported, corresponding to the largest FFT.

[s_dub...@nospicedham.yahoo.com]

On Nov 2, 6:46 pm, Bjarni Juliusson <bja...@nospicedham.update.uu.se>
wrote:

> On 11/01/2011 04:04 PM, Jim Leonard wrote:
>
> > On Oct 31, 9:43 pm, Bjarni Juliusson<bja...@update.uu.se>  wrote:
> >>  Well at least in a couple of the newsgroups I frequent, there seems to
> >>  be a balls load of people who teleported there from the 80s and
> >>  apparently brought their computers with them.
>
> > As one of Those People(tm) I can tell you why:  In the 1980s, we
> > marveled at what our machines could do, but lacked the skill and
> > knowledge to reproduce that work and build on it.  Now that we're
> > older and wiser, we can.
>
> And ain't it grand? The graphics of modern computer games sting my eyes.
> Those are just lots of pixels, not _graphics_!
>

[snip]

Dave's got some tools you might be interested in...

http://www.classiccmp.org/dunfield/img/index.htm

As I recall, he has software to check controller capabilities and
diskette types.

Steve

[Bob Masta]

On Fri, 04 Nov 2011 19:13:25 +0100, Terje Mathisen

Err, I think perhaps you misunderstood me: I *do* generate
the twiddle factors at start-up. (Not "compile" time... this
is a pure assembly app!) In fact, I do that with the
angle-summation formula you mention. However, the values
are all 32-bit integers, not floats.

My FFT size is always 1024 (compromise between time- and
frequency resolution), so the number of twiddle factors is
small (262, as I recall), but as it turns out I also compute
a much larger full-cycle sine table for signal generation
purposes.

I'm still not sure that floating point FFTs would be any
faster than 32-bit integers, but in my situation that would
be academic anyway. The FFT (with windowing beforehand and
window correction afterward, if selected) takes less than
100 microsec on a 1.6 GHz system. That's an order of
magnitude faster than I can get it into a color-coded
vertical bar for one time-point on a color spectrogram, and
almost 2 orders of magnitude faster than I can plot it as a
spectrum, using ordinary Windows graphics operations
(PolyLine). And even at that, the spectra are computed and
drawn 100 times per second. So any speedup from a faster
FFT would be swamped by everything else, and would not
contribute anything to the overall functionality of the
program... while there are many new feature additions that
are taking up my time at the moment.

However, if I move to larger FFT sizes in the future, I will
definitely look at SIMD. So thanks for the pointers!

[Terje Mathisen]

Bob Masta wrote:
> Err, I think perhaps you misunderstood me: I *do* generate
> the twiddle factors at start-up. (Not "compile" time... this
> is a pure assembly app!) In fact, I do that with the

You can still calculate the initial term by hand and include that as a
constant to start the table calculation, is this what you do?

> angle-summation formula you mention. However, the values
> are all 32-bit integers, not floats.

That's OK. :-)

Garmin uses fractional circles for all angle measurement, mapping [-pi
to pi> into a 32-bit signed integer range.

> My FFT size is always 1024 (compromise between time- and
> frequency resolution), so the number of twiddle factors is
> small (262, as I recall), but as it turns out I also compute
> a much larger full-cycle sine table for signal generation
> purposes.

OK.

>
> I'm still not sure that floating point FFTs would be any
> faster than 32-bit integers, but in my situation that would

Plain SSE2 FFT code will turn out to be close to 3x faster than
integer-only code.

> be academic anyway. The FFT (with windowing beforehand and
> window correction afterward, if selected) takes less than
> 100 microsec on a 1.6 GHz system. That's an order of

Hmmm... about 150K cycles: A 1K FFT requires 512*10 complex muls and
1024*10 complex adds. Each CFMUL consists of 4 FMULs and some adds, so
we should end up with about 40K operations, half mul/half add.

In integer the adds are very fast but MULs take at least 4-5 cycles plus
the scaling, so this corresponds well with your claimed 150 K total cycles.

In SSE the FADDs take just as much time as the FMULs, but we can do
either 4 or 8 of them simultaneously, with no need for scaling, and you
can start one or two new SSE operations on every cycle.

In my own code (IMDCT) going to SSE did provide almost exactly 3X
speedup over scalar FP, using integer only would have been even slower.

> magnitude faster than I can get it into a color-coded
> vertical bar for one time-point on a color spectrogram, and
> almost 2 orders of magnitude faster than I can plot it as a
> spectrum, using ordinary Windows graphics operations
> (PolyLine). And even at that, the spectra are computed and
> drawn 100 times per second. So any speedup from a faster
> FFT would be swamped by everything else, and would not
> contribute anything to the overall functionality of the
> program... while there are many new feature additions that
> are taking up my time at the moment.

That otoh is a perfectly valid consideration. :-)

>
> However, if I move to larger FFT sizes in the future, I will
> definitely look at SIMD. So thanks for the pointers!

Good luck.

[James Van Buskirk]

"Terje Mathisen" <"terje.mathisen at tmsw.no"@giganews.com> wrote in message
news:k3vfo8-...@ntp6.tmsw.no...

> Bob Masta wrote:

>> My FFT size is always 1024 (compromise between time- and
>> frequency resolution), so the number of twiddle factors is
>> small (262, as I recall), but as it turns out I also compute
>> a much larger full-cycle sine table for signal generation
>> purposes.

> Hmmm... about 150K cycles: A 1K FFT requires 512*10 complex muls and
> 1024*10 complex adds. Each CFMUL consists of 4 FMULs and some adds, so we
> should end up with about 40K operations, half mul/half add.

Except that I suspect the input data are real, not complex, so the
operation counts would be 11722 adds and 4240 multiplies for the
scaled odd tail algorithm. More of course for algorithms that could
be reasonably coded, but only about half of that 20K additions.

Since integer multiply is significantly slower than integer add, I
also speculate that the code in question uses the 3 multiply-3 add
form of complex multiplication which would have to be changed for
SSE2:

(a+j*b)*(x+j*y) = a*x-b*y+j*(a*y+b*x)
= a*(x+y)-(a+b)*y+j*((a*(x+y)+(a-b)*y)

Where a+b and a-b are precomputed at algorithm startup.

You can get all bogged down in trying to code up the best possible
FFT for the available hardware, so the choice not to mess with what
is already fast enough is reasonable.

[Terje Mathisen]

James Van Buskirk wrote:
> "Terje Mathisen"<"terje.mathisen at tmsw.no"@giganews.com> wrote in message

>> Hmmm... about 150K cycles: A 1K FFT requires 512*10 complex muls and
>> 1024*10 complex adds. Each CFMUL consists of 4 FMULs and some adds, so we
>> should end up with about 40K operations, half mul/half add.
>
> Except that I suspect the input data are real, not complex, so the
> operation counts would be 11722 adds and 4240 multiplies for the
> scaled odd tail algorithm. More of course for algorithms that could
> be reasonably coded, but only about half of that 20K additions.
>

You're obviously right, the canonical way would be to use a half-size
complex FFT, so about half the operation count (including the extra
setup overhead).

> Since integer multiply is significantly slower than integer add, I
> also speculate that the code in question uses the 3 multiply-3 add
> form of complex multiplication which would have to be changed for
> SSE2:
>
> (a+j*b)*(x+j*y) = a*x-b*y+j*(a*y+b*x)
> = a*(x+y)-(a+b)*y+j*((a*(x+y)+(a-b)*y)
>
> Where a+b and a-b are precomputed at algorithm startup.
>
> You can get all bogged down in trying to code up the best possible
> FFT for the available hardware, so the choice not to mess with what
> is already fast enough is reasonable.

That's the important point here!

For my ogg vorbis code the IMDCT started out being 60-70% of the total
processing time, and this is fairly typical for all modern audio codecs
(they all use IMDCT as a critical step afaik).

[Bjarni Juliusson]

On 11/04/2011 08:58 PM, s_dub...@nospicedham.yahoo.com wrote:
>
> Dave's got some tools you might be interested in...
>
> http://www.classiccmp.org/dunfield/img/index.htm
>
> As I recall, he has software to check controller capabilities and
> diskette types.

Thanks Steve.

[Jim Leonard]

On Nov 3, 7:12 am, N0S...@daqarta.com (Bob Masta) wrote:
> I didn't use the 8087 because everything is done with
> integer math.

Yes, but being such a slow machine, I would have thought that getting
the 8087 to do some calculation while the main CPU was off doing other
things would have been appealing. A nice speedup for those who owned
an 8087, for example.

[Jim Leonard]

On Nov 2, 5:46 pm, Bjarni Juliusson <bja...@nospicedham.update.uu.se>
wrote:
> Nice comparison. :) Do you have any idea why they chose the 8088 of all
> CPUs? Can't imagine it was cheaper than a 6502 or a Z80?

IIRC it was because the 6502 and Z80 weren't full-featured enough.
IBM was making a business computer, not a home computer. The original
CPU IBM considered was the 68000, but they switched to the 8088 for
cost reasons.

Think how different the world would be if they had stuck with the
68000! Right from 1981 we would have had tons of 32-bit registers to
play with and 16MB of memory to access. You could waste hours just
thinking about how different the world would be today.

> A little project I've been thinking of for a few years is a "floppy
> reading machine", a little computer with floppy drives of the different

Look up "kryoflux". It's a hardware/software project that is already
doing this.

[Jim Leonard]

On Nov 2, 7:26 pm, Bjarni Juliusson <bja...@nospicedham.update.uu.se>
wrote:

> I remember I played
> Unreal when it was new and really hyped, and I just thought well, I
> played this game when it was called Wolfenstein 3D...

Agreed. But there are a few diamonds in the rough, such as Portal and
its sequel.

> > If you run a 32-bit version of Windows, they still run, barring a few
> > exceptions.
>
> Impressive. What are the exceptions? :)

Anything that wants direct access to the hardware. I finished up some
benchmark code (again, as a hobby) this weekend where I was tested
every opcode and was surprised to learn that the LOCK prefix pretty
much crashes the DOS subsystem when you run it on a Windows machine
with more than one CPU. Also, anything that assumes a DOS soundcard
is present, or anything trying to set an SVGA video mode, will give
you problems. Fortunately, there's DOSBOX for those instances (or
vmware/virtualbox if you need more speed and no soundcard support).

[Rugxulo]

Hi,

On Nov 7, 10:05 am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:

> On Nov 2, 5:46 pm, Bjarni Juliusson <bja...@nospicedham.update.uu.se>
> wrote:
>
> > Nice comparison. :) Do you have any idea why they chose the 8088 of all
> > CPUs? Can't imagine it was cheaper than a 6502 or a Z80?
>
> IIRC it was because the 6502 and Z80 weren't full-featured enough.
> IBM was making a business computer, not a home computer.  The original
> CPU IBM considered was the 68000, but they switched to the 8088 for
> cost reasons.

CP/M was all the rage. 8086 meant more RAM and fully 16-bit, no longer
stuck to 8-bit with 64k limits. They wanted CP/M-86, but it took too
long to get ported (and was too expensive, comparatively, when it
finally arrived). Remember that PC-DOS started as a CP/M clone (API
compatible). The 8088 was 8-bit external bus for compatibility with
existing peripherals (I think). Yes, it was slightly slower and
cheaper too than the full 8086.

I also think fabs weren't as robust back then. Presumably IBM didn't
want to risk it, as they required Intel to have second sources (e.g.
AMD) to make their cpus.

Also, 8088 was at least source compatible to 8080, right? So that was
another advantage.

> Think how different the world would be if they had stuck with the
> 68000!  Right from 1981 we would have had tons of 32-bit registers to
> play with and 16MB of memory to access.  You could waste hours just
> thinking about how different the world would be today.

32-bit registers to eat up more precious memory that nobody had.
Machines came with very low amounts back then (128 kb was generous).
What good is potential of 16 MB when nobody would have that much for
10+ years?? It wasn't that uncommon to barely have 4 MB when Win 3.1
came out (1992).

Besides, look at us now, gobs and gobs of memory, and still the OSes
can barely run. You shouldn't ever need 1 GB for a functional OS (nor
even with web browser, word processor, multimedia). It's kinda sad,
really, don't fix the problem, just throw more horsepower at it (ad
infinitum). :-(

[Bjarni Juliusson]

On 11/07/2011 10:02 PM, Rugxulo wrote:
> Hi,
>
> On Nov 7, 10:05 am, Jim Leonard<mobyga...@nospicedham.gmail.com>
> wrote:
>
>> Think how different the world would be if they had stuck with the
>> 68000! Right from 1981 we would have had tons of 32-bit registers to
>> play with and 16MB of memory to access. You could waste hours just
>> thinking about how different the world would be today.
>
> 32-bit registers to eat up more precious memory that nobody had.

No no, the 68000 is a byte-oriented architecture. If you read code from
the Atari ST for instance, with 512Kb of memory, you'll probably find it
uses mostly bytes and halfwords, with very little 32-bit stuff. The
first two generations of CPUs also were only 16 bits wide internally, so
programmers avoided 32-bit operations not only to save memory but to
improve speed too.

> Besides, look at us now, gobs and gobs of memory, and still the OSes
> can barely run. You shouldn't ever need 1 GB for a functional OS (nor
> even with web browser, word processor, multimedia).

And we don't! :) The big offender is the web browsers, they seem to
require infinite memory and CPU time somehow, but as far as I know Linux
still runs fine in 4Mb or so, and the BSDs in even less I think.

Word processors use varying amounts of memory depending on what you mean
by word processor - my emacs here shows a virtual size of over 100Mb,
but only 22Mb resident with 12Mb shared. If you want a more
full-featured typesetting program, LyX with a report I wrote for work
loaded actually takes less than emacs: 88Mb virtual, 21Mb resident, 16Mb
shared.

If you're a fan of small footprints you might be using vi, which starts
up with a resident size of 2Mb on the system I'm on right now. For a
memory-starved system, nano takes 1.5Mb, with 1Mb shared.

I started mplayer showing a movie too, and it took 16Mb resident but
with a virtual size of 359Mb. It links with about a million libraries
though, which won't all be used at the same time so they won't be in memory:

>ldd `which mplayer` | wc -l
145

But you're absolutely right, programs just use more and more memory for
each year. There are two reasons for that: one is that programmers
simply get lazy - if you can spend less time developing a program and
put more work on the computer, that's what they will do - and the other
is that memory is used for new things, including things that speed up
execution but couldn't be done a decade ago because there was too little
memory.

And programs tend to have more features now than a decade ago, and we
expect them to. Find a copy of Netscape Navigator 2 and go browse the
web. You will almost certainly be dissatisfied. :)

[Bjarni Juliusson]

On 11/07/2011 05:05 PM, Jim Leonard wrote:
> On Nov 2, 5:46 pm, Bjarni Juliusson<bja...@nospicedham.update.uu.se>
> wrote:
>> Nice comparison. :) Do you have any idea why they chose the 8088 of all
>> CPUs? Can't imagine it was cheaper than a 6502 or a Z80?
>
> IIRC it was because the 6502 and Z80 weren't full-featured enough.
> IBM was making a business computer, not a home computer.

What exactly does "full-featured" mean in this context?

> The original CPU IBM considered was the 68000, but they switched to
> the 8088 for cost reasons.

Hoh boy.

> Think how different the world would be if they had stuck with the
> 68000! Right from 1981 we would have had tons of 32-bit registers to
> play with and 16MB of memory to access. You could waste hours just
> thinking about how different the world would be today.

It would have been sweet. Oh my oh my. Aargh.

>> A little project I've been thinking of for a few years is a "floppy
>> reading machine", a little computer with floppy drives of the different
>
> Look up "kryoflux". It's a hardware/software project that is already
> doing this.

Wow, thanks! :)

[Jim Leonard]

On Nov 7, 3:02 pm, Rugxulo <rugx...@nospicedham.gmail.com> wrote:
> > Think how different the world would be if they had stuck with the
> > 68000!  Right from 1981 we would have had tons of 32-bit registers to
> > play with and 16MB of memory to access.  You could waste hours just
> > thinking about how different the world would be today.
>
> 32-bit registers to eat up more precious memory that nobody had.

Registers don't take up any *memory* at all.

While I love optimizing for the 8088 in my hobby, there are times when
I curse that I don't have more than 16 bits per register to play
with. It makes atomic 32-bit ops tedious.

[Rugxulo]

Hi,

On Nov 8, 9:17 am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:

> On Nov 7, 3:02 pm, Rugxulo <rugx...@nospicedham.gmail.com> wrote:
>
> > 32-bit registers to eat up more precious memory that nobody had.
>
> Registers don't take up any *memory* at all.

C'mon, Jim, gimme a break. ;-) You know what I mean. The bigger
the pointers, the more space is used by HLL compilers, even if the
full size isn't needed (and thus worse on AMD64). The days of people
worrying about RAM are gone.

http://www.inf.ethz.ch/personal/wirth/Articles/LeanSoftware.pdf

(And that was 1995, way before all this new-age ultra-bloat, heheh.)

> While I love optimizing for the 8088 in my hobby, there are times when
> I curse that I don't have more than 16 bits per register to play
> with.  It makes atomic 32-bit ops tedious.

All programming is tedious and error-prone. If you don't want to hand-
code something, you'll have to use a HLL (as you often do, TP7).
"longint" FTW! Too bad it's not very optimized. ;-) (Actually, you
could try tputuner or similar. I don't have TP7, so I can't test it.)

http://phost.de/~stefan/turbo.html

[Rod Pemberton]

"Jim Leonard" <moby...@nospicedham.gmail.com> wrote in message
news:5ffdd3d5-83b6-4b2e...@c18g2000yqj.googlegroups.com...

On Nov 7, 3:02 pm, Rugxulo <rugx...@nospicedham.gmail.com> wrote:
>
> > 32-bit registers to eat up more precious memory that nobody had.
>
> Registers don't take up any *memory* at all.

Actually, they do. :-)

They do not "take up" *system* memory. They do "take up" *register* memory.

Without memory, you cannot store and retain values. We all know that that
is what registers do. So, please do not say registers aren't memory.


Rod Pemberton

[Jim Leonard]

On Nov 9, 1:43 am, "Rod Pemberton"
<do_not_h...@nospicedham.noavailemail.cmm> wrote:
> "Jim Leonard" <mobyga...@nospicedham.gmail.com> wrote in message

In the context of his comment, he was suggesting that registers took
up system memory, since 32-bit pointers are bigger than 16-bit
pointers. I don't buy that argument. Once you have more than 64K
bytes to access, you should have registers larger than 16 bits wide.
The overhead of 32-bit pointers in limited RAM is nothing compared to
the speed and flexibility you have with larger registers. IMO.

If 808x architecture had a real segment:offset model that made sense
(ie. seg:ofs was a normal 16:16 instead of the 20-bit stuff we got)
then that would have been great too.

[Jim Leonard]

On Nov 8, 1:04 pm, Rugxulo <rugx...@nospicedham.gmail.com> wrote:
> C'mon, Jim, gimme a break.   ;-)    You know what I mean. The bigger
> the pointers, the more space is used by HLL compilers, even if the
> full size isn't needed (and thus worse on AMD64).

I don't buy that argument. I believe more time was wasted managing
inefficient pointers that could have been saved with single-
instruction 32-bit pointer math. In the 20-bit model, normalizing a
pointer is not only sometimes necessary but takes 8 instructions last
I checked; with a linear addressing model, you don't even need to
normalize.

> http://phost.de/~stefan/turbo.html

Very cool, I hadn't heard about this before. I will check this out,
and also compare it to SPO. (But only as a curiosity, since the
really important size/speed stuff I write as in-line asm.)

And hey, with that mention of asm, we're actually back on-topic for
this group ;-)

[Single Stage to Orbit]

On Mon, 2011-11-07 at 08:38 -0800, Jim Leonard wrote:
>
> Anything that wants direct access to the hardware. I finished up some
> benchmark code (again, as a hobby) this weekend where I was tested
> every opcode and was surprised to learn that the LOCK prefix pretty
> much crashes the DOS subsystem when you run it on a Windows machine
> with more than one CPU.

IIRC, that used to crash Minix 1.1 if it was booted on a Pentium class
machine. Simply patching these LOCK instructions with NOP solved the
issue. :)
--
Tactical Nuclear Kittens

[Hugh Aguilar]

On Nov 9, 10:26 am, Jim Leonard <mobyga...@nospicedham.gmail.com>
wrote:

> On Nov 8, 1:04 pm, Rugxulo <rugx...@nospicedham.gmail.com> wrote:
>
> > C'mon, Jim, gimme a break.   ;-)    You know what I mean. The bigger
> > the pointers, the more space is used by HLL compilers, even if the
> > full size isn't needed (and thus worse on AMD64).
>
> I don't buy that argument.  I believe more time was wasted managing
> inefficient pointers that could have been saved with single-
> instruction 32-bit pointer math.  In the 20-bit model, normalizing a
> pointer is not only sometimes necessary but takes 8 instructions last
> I checked; with a linear addressing model, you don't even need to
> normalize.

You don't need to normalize pointers if you just make sure that every
data structure fits within 64K! Point ES to your data structure, and
do everything with 16-bit pointers without any housekeeping at all.

I predicted some time ago that 64-bit computers would never be built,
because nobody needs more that 2^32 bytes of memory, and because
people rarely need integers larger than 2^32 either (and they can just
use two 32-bit registers as a pair when they do need big integer
arithmetic). I believed that a 64-bit computer would be wasteful of
memory because it would be storing a lot of 64-bit pointers in memory,
all of which have the top word set to zero, and this waste of memory
would cause 64-bit programs to be slower than 32-bit programs due to
cache overflow.

Obviously, my prediction didn't work out very well, considering that I
am typing this on a laptop containing an AMD-64! Still though, it
seems like a strange direction for the technology to go.

[Rod Pemberton]

"Hugh Aguilar" <hughag...@nospicedham.yahoo.com> wrote in message
news:b2d91d7e-3671-4b5d...@x36g2000prb.googlegroups.com...

>
> I predicted some time ago that 64-bit computers would never be built,
> because nobody needs more that 2^32 bytes of memory, and because
> people rarely need integers larger than 2^32 either (and they can just
> use two 32-bit registers as a pair when they do need big integer
> arithmetic). I believed that a 64-bit computer would be wasteful of
> memory because it would be storing a lot of 64-bit pointers in memory,
> all of which have the top word set to zero, and this waste of memory
> would cause 64-bit programs to be slower than 32-bit programs due to
> cache overflow.
>

Yes, 64-bit computing is not really needed by the average PC user. They
probably won't even notice the difference, unless they have to buy more
memory due to larger addresses. I think that's why 64-bit mode uses 32-bit
offsets ...

There is always a demand for more computing capability. The question is for
what market. I.e., users of supercomputers can afford to pay for
"unecessary" features, but general consumers can't. So, additional
functionality for mass production becomes a question of cost: cost to the
manufacturer vs.consumer demand. E.g., shaving 10 cents off of 100 million
cpu's saves the manufacturer 10 million. If they didn't shave 1 cent,
they'd have to borrow that "extra" capital upfront in order to manufacture
the product. If the market demand isn't there for that feature, they'll
shave the 10 cents instead of providing it. If they provide it, they'll
expect to charge some absurd markup, like 1000% or 10000%. The upfront
capital problem affects all sorts of industries. It's why you can't get
some 10 cent feature on a much more expensive product.


Rod Pemberton