functions of 32 bits

[Fumador]

can quickbasics include in a Qlb or in a Sub, a function of 32 bits and run it?

[RyanKelly]

You're question is vague.

Are you asking:

1) Can QuickBasic produce code that uses 32 bit opcodes.

2) Can QuickBasic work with libraries that contain 32 bit code.

3) Can QuickBasic operate on 32 bit data?

[Fumador]

You're question is vague.
Are you asking:
1) Can QuickBasic produce code that uses 32 bit opcodes.
2) Can QuickBasic work with libraries that contain 32 bit code.
3) Can QuickBasic operate on 32 bit data?

i am curious, please try to explain (2) and (3) in easy language.

[RyanKelly]

You're question is vague.
Are you asking:
1) Can QuickBasic produce code that uses 32 bit opcodes.
2) Can QuickBasic work with libraries that contain 32 bit code.
3) Can QuickBasic operate on 32 bit data?

i am curious, please try to explain (2) and (3) in easy language.

I will try to clarify as best I can.

32 bit data is simply any sort of data that requires 32 bits to represent. For example the LONG variable type in Quick Basic is a 32 bit data type. There are eight bits in a byte, which means that a LONG variable occupies four bytes in memory.

Now, concerning the distinction between 32 bit and 16 bit code:
The intel family of proccessors and the compatable chips from other manufacturers that most of use use began with a 16 bit CPU. This means that the math and memory transfer units could work with up to 16 bits at one time. To perform calculations or computation on larger data required a programmer to break it down into smaller steps. Starting with the 80386, the largest unit of memory the CPU could deal with at one time increased to 32 bits. However, this CPU and its successors could be run in two different modes, REAL and PROTECTED.

Real mode behaves much like the old 16 bit chip. It can work with 32 bit data, but by default it works with 16 bits.

Protect mode is much different. The default bit setting is selectable, but most often only the 32 bit default is used. The most important difference from real mode is the way memory is addressed. Because of this difference, programs that were designed to run in real mode, like DOS or QBasic (and the programs written in QB) can not run properly in protected mode, and code designed fro protected mode won't behave as expected in real mode. (There is a sub mode of protected mode that does behave like real mode, which is why a protected mode OS like Windows can let us run old DOS programs).

Now, with all that in mind, the term "32 bit code" can refer to 1) a program designed to run in real mode that contains instructions to work on 32 bit data, or 2) a program designed to run in 32 bit protected mode. When most people say "32 bit program" they are often refering to protected mode.

To answer your question, a Qb lib can contain all of the above, BUT not with equal ease. Any program can work with 32 bit data (the math function in QB work with LONG integers 16 bits at a time). A library can easily incorportate 32 bit intructions but these must be developed with a compiler that may do so (QB 4.5 won't, PDS and VBDOS will, but the libaries produced by these compiler don't function with QB 4.5. Most C compilers and assembler will.). As for using 32 bit protected mode code, the libary routines must switch the CPU into protected mode, execute the code and then switch back to real mode. This is not a trivial task and will most likely conflict with Windows and even some memory managers on a DOS machine.

[yetifoot]

@RyanKelly

I was wondering about this 32-bit code in 16-bit DOS. I was fooling around the other day and tried using stosd in 16bit mode. Strangely it seemed to work.

You seem quite knowledgable on this subject, is this allowed behaviour? Is it especially naughty?

Heres my code, excuse its low quality, i'm not an expert in asm, and certainly not on 16 bit dos stuff. Plus this is a test program.

Code:

org 100h

  push 0A000h
  pop es
  call vga_init_13h

  xor ax, ax
  mov dx, 3C8h
  out dx, al
  inc dx
  out dx, al
  out dx, al
  out dx, al
  inc al
genpal:
  out dx, al
  out dx, al
  out dx, al
  inc al
jnz genpal


main_loop:
  mov di, 0
  mov cx, 320 * 50
  mov al, [f]
  mov ah, [f]
  shl eax, 16
  mov al, [f]
  mov ah, [f]
  inc [f]
  call vsync
;plot_loop:
  rep stosd
;loop plot_loop
  call check_escape
  cmp ax, 0
jnz main_loop
  call vga_deinit
  ret

;;;;------------
vga_init_13h:
  pusha
  mov ax, 13h
  int 10h
  popa
  ret
;;;;------------
vga_deinit:
  pusha
  mov ax, 3h
  int 10h
  popa
  ret
;;;;------------
vsync:
  push ax dx
  mov ax, 0
  mov dx, 3DAh
vsync_loop:
  in al, dx
  and al, 8
  jz vsync_loop
  pop dx ax
  ret
;;;;------------
check_escape:
  mov ah, 0
  in al, 60h
  dec al
  ret
;;;;------------

f db 0

[na_th_an]

You have to diferentiate. You can use extended 32 bits registers from DOS16, but you can't use "32 bits code" which is the loose way of calling code which runs on pmode thus can use 32 bits to address memory, i.e. it can address 4Gb of memory.

[yetifoot]

I see, thanks na_th_an, that clears it up a bit for me. I was never a DOS programmer back when DOS was big (I was still using my Atari ST!), i've just been doing it lately for a bit of fun.

[na_th_an]

Oh! You lucky Atari ST owner!

(I'm feeling envy right now)

I want ONEEE :lol: (seriously, I'd love to find a nice 1024STFM)

[yetifoot]

Mine died quite a few years ago. I had a 512STe that i upgraded to 1024. The STe had the proper blitter chip, and you didn't have to solder the ram upgrades you just plugged them in. I still have some of my games/demos though, and all my ST format magazines(1989-1994).

Sometimes i wish i still had one, but I guess i wouldn't use it very much. At the time everybody else had Amigas, but i was into music/programming so the Atari was the more natural choice.

Same goes for the old Spectrum, wish i still had it, i regret throwing my old computers away, but it was the period before it was cool to be retro, and too late to get them fixed cheaply.

A few years ago a shop in my town was selling Spectrum +2's brand new in the box (old warehouse stock) for £20, i feel stupid for not buying them, as you can easy get £50 for one in the box.

[RyanKelly]

yetifoot, yes, 32 bit memory and register access is perfectly fine in real mode. Intel extended the instruction set by introducing an optional size prefix to the applicable opcodes. When running in real mode or 16 bit protected mode, the presense of the size prefix in the code stream indicates that any instruction that would normally work on a 16 bit operand should perform a 32 bit operation instead. In 32 bit protected mode, the size prefix does the exact opposite. So, in your strange little .com program (is this suppose to flash a bunch of colored bars on the screen?), your assembler would code emit the size prefix, then encode "stosd" with the exact same bit pattern that it would "stosw".