- refactor code for transfer buffer reads/writes, real mode
int 0x21 calls, and assembler segment declarations
- define transfer buffer size in one place
- beef up error checking for transfer buffer operations
(prevent buffer overflows)
- also optimize such operations to transfer dword by dword
where feasible
- ensure es = ds = ss upon exit of each C runtime function
- clear upper 16 bits of ebx before setting them to 0x0021,
when invoking interrupt_ptr to simulate a RM int 0x21
- make _sys_exists use the transfer buffer (which it needs)
- make _sys_rawread properly handle an end-of-file read
(zero bytes read)
- make argument to _sys_seterrno short --- after a failed
int 0x21 call, only the lower 16 bits of eax hold the MS-DOs
error code
- _sys_rawlseek accepts only 3 longword arguments, not 4
(the offset is only 1 longword)
- other minor fixes
- correctly calculate size of BSS area to clear
- make realloc routine set both ds & es to point to new
data segment
- correctly initialize real mode flags when simulating real
mode interrupt via DPMI
- other minor fixes
- do not try to store data through code segment selectors
- set each segment limit to segment size - 1, not segment size
- get PSP segment while still in real/V86 mode (DPMI host
might choose to return PM selector for int 0x21, ah = 0x62)
- other minor fixes
The new .seek assembler pseudo-op advances the location
counter to a fixed offset within a section --- or to a fixed
address, if the section is a .base'd section. It works
somewhat like the GNU assembler's .org pseudo-op, though
with a hopefully less confusing name.
This pseudo-op lets us avoid having to manually compute the
needed boot sector padding in the pc86 start-up code
plat/pc86/boot.s .
bug caused by this instruction:
fmove.l fp0,d0
problem was caused by a conflict between the fpu emulator (softfloat) and the compiler.
the emulator implemented this as a purely arithmetic move & conversion,
but the compiler assumed that the result could be interpreted as a logical (ie unsigned) conversion.
rightly or wrongly.
for example, if fp0 contained the value 2576980377.0 which is unsigned integer -1717987328
the emulator would treat this as an integer overflow and move 0x7fffffff (INT_MAX) into d0.
The complier on the other hand would assume that d0 contained 2576980377 (the unsigned value).
I don't know which is correct, but this is my fix for the time being.
problem was implementation of fint & fintrz floating point ops in m68kfpu.c
Both these ops truncated the integer to 32 bits instead of leaving it as an extended precision floating point number
Changed the implementation to use 64 bit ints instead of 32 bit ints.
latest version of musashi engine
includes floating point emulation
(plus a few patches to add in missing opcodes needed by ack - see tags JFF & TBB)
added a few missing linux syscalls in sim.c
pascal now runs pretty well
quick test with modula2 passes
c gets the floating point numbers wrong, so more work needed here
other languages untested
plat/linux68k/emu/build.lua is probably not quite right - the softfloat directory is compiled in the wrong place
