What was the single byte change to port WordStar from CP/M to DOS? - history

I was re-reading Joel's Strategy Letter II: Chicken and Egg problems and came across this fun quote:
In fact, WordStar was ported to DOS
by changing one single byte in the
code. (Real Programmers can tell you
what that byte was, I've long since
forgotten).
I couldn't find any other references to this with a quick Google search. Is this true or just a figure of speech? In the interest of my quest to become a "Real Programmer", what was the single byte change?

Sounds a bit exaggerated, found some WordStar history here
WordStar 3.0 for MS-DOS
Apr 1982
In one single all-night session Jim Fox patched the CP/M-86 version of WordStar to make it run under MS-DOS on the IBM PC so that it could be demonstrated to Rubenstein. The actual port was done by a group of Irish programmers using Intel development systems, which ran the ISIS II operating system. The software build was done on 8" floppies and the binary (executable) files were then transferred to the IBM PC by serial cable.
But...Joel maybe meant MS-DOS 1.0 / QDOS
MS-DOS 1.0 was actually a renamed version of QDOS (Quick and Dirty Operating System), which Microsoft bought from a Seattle company, appropriately named Seattle Computer Products, in July 1981. QDOS had been developed as a clone of the CP/M eight-bit operating system in order to provide compatibility with the popular business applications of the day such as WordStar and dBase. CP/M (Control Program for Microcomputers) was written by Gary Kildall of Digital Research several years earlier and had become the first operating system for microcomputers in general use.

You'd have to change more than one byte. CP/M-86 executables (.CMD) all have a 128-byte header, which isn't anything like the .EXE header.
If you restrict all your API calls to the common subset of CP/M and DOS, then you can use conditional assembly to build CP/M and DOS versions from the same source:
bdos:
if CPM86
int 0E0h
else
mov ah, cl
int 21h
endif

This Wikipedia entry claims that CP/M and MS-DOS share binary formats. It goes on to say:
Although the file format is the same
in MS-DOS and CP/M, this does not mean
that CP/M programs can be directly
executed under MS-DOS or vice versa;
MS-DOS COM files contain x86
instructions, while CP/M COM files
contain 8080, 8085 or Z80
instructions.
Under CP/M 3, if the first byte of a
COM file is 0xC9 then this indicates
the presence of a 256-byte header;
since 0xC9 corresponds to the 8080
instruction RET, this means that the
COM file will immediately terminate if
run on an earlier version of CP/M that
does not support this extension.
This implies that perhaps the fix/port was changing this first instruction into something else, that alowed the rest to execute. Not sure though, that seems to imply that the binary must have been "fat", which seems unreasonable for a legacy binary.

WordStar was written in 8080 assembler, and there were tools back then to convert 8080 to 8086 assembler (the 8086 instruction set was designed to allow this) if all the code could fit into a single segment, so this is quite possible.
I first used WordStar in 1979, on a Z80 CP/M box. People today might not realise how lucky they are - how many MS Word users would be prepared as the first task on installing their word processor to have to write a couple of small assembler routines (in hex!) to interface the word processor efficiently (you could use the CP/M routines but they were dog slow and didn't work properly) with the screen and keyboard? Happy days...

"In fact, WordStar was ported to DOS by changing one single byte in the code. (Real Programmers can tell you what that byte was, I've long since forgotten)."
Mon 6/08/2009 6:27 pm. My assumption was Spolsky was talking about 8080 CP/M to 8086 MSDOS, and that the story is probably bogus. 8086 CP/M was never a big item -- I mean, it was crushed utterly by MSDOS -- and someone may have converted WordStar from 8080-CPM to 8086-CPM -- by reassembling it, as others have noted, using a special 8080-to-8086 translator thingey -- and then perhaps only a single byte had to be changed.

I'm not sure whether Joel's statement is accurate or not. Perhaps he meant the demonstration version that Jim Fox made?
See http://www.wordstar.org/wordstar/history/history.htm
I'll quote the pertinent section:
WordStar 3.0 for MS-DOS
Apr 1982
In one single all-night session Jim
Fox patched the CP/M-86 version of
WordStar to make it run under MS-DOS
on the IBM PC so that it could be
demonstrated to Rubenstein. The actual
port was done by a group of Irish
programmers using Intel development
systems, which ran the ISIS II
operating system. The software build
was done on 8" floppies and the binary
(executable) files were then
transferred to the IBM PC by serial
cable.
(Edit: Oops, too late. Someone else already found the exact same thing :-/ Feel free to ignore me.)

An important thing to understand is that at the time 16-bit 8086 machines was just coming out to replace the current 8-bit machines, where the CP/M operating system was the Windows of the day. Everything with a disk drive intended for work ran CP/M. That version was later called CP/M-80 to differentiate it from CP/M-86 for the 8086 processor.
Unfortunately that took so long to get to market that QDOS was written to have SOMETHING to run programs on, and that was essentially a quick reimplementation of the CP/M functions (but with a different syntax). QDOS was later bought by Microsoft and made into MS-DOS. Hence MS-DOS actually has a CP/M core deep deep inside, and therefore the amount of work needed to get a CP/M-86 program to run under MS-DOS was limited (not to a single byte, but manageable).
I had the pleasure to work a few years with CCP/M-86 which allowed multitasking very similar to what Linux in text mode (with virtual consoles) allow today. Unfortunately it never caught on. Oh, well, we have Linux :)

Related

How to find the number of bit of OS/390 or a z/OS?

What is the command for finding the number of bit of an OS/390 or a z/OS?
Since there didn't seem to be a "real" answer on this thread, I thought I'd provide one just in case anyone needs the information...
The definitive source of whether you're running in 64-bit mode is the STORE FACILITY LIST (STFL, or STFLE) hardware instruction. It sets two different bits - one to indicate that the 64-bit zArchitecture facility is installed, and one to indicate that the 64-bit zArchitecture facility is active (it was once possible to run in 31-bit mode on 64-bit hardware, so this would give you the "installed, but not active" case).
The operating system generously issues STFL/STFLE during IPL, saving the response in the PSA (that's low memory, starting at location 0). This is handy, since STFL/STFLE are privileged instructions, but testing low storage doesn't require anything special. You can check the value at absolute address 0xc8 (decimal 200) for the 0x20 bit to tell that the system is active in 64-bit mode, otherwise it's 31-bit mode.
Although I doubt there are any pre-MVS/XA systems alive anymore (that is, 24-bit), for completeness you can also test CVTDCB.CVTMVSE bit - if this bit is not set, then you have a pre-MVS/XA 24-bit mode system. Finding this bit is simple - but left as an exercise for the reader... :)
If you're not able to write a program to test the above, then there are a variety of ways to display storage, such as TSO TEST or any mainframe debugger, as well as by looking at a dump, etc.
While I was not able to find commands to give this information, I think below is what you're looking for:
According to this: https://en.wikipedia.org/wiki/OS/390
z/OS is OS/390 with various extensions including support for 64-bit architecture.
So if you're on a zSeries processor with z/OS, you're on 64-bit.
According to this: https://en.wikipedia.org/wiki/IBM_ESA/390
OS/390 was installed on ESA/390 computers, which were 32-bit computers, but were 31-bit addressable.
For either z/OS or OS/390 I believe you can do a D IPLINFO and look for ARCHLEVEL. ARCHLEVEL 1 = 31 bit, ARCHLEVEL 2 = 64 bit. But it's been a very long time since I've been on an OS/390 system.

Is it possible a unix or linux for 80286 machine (or any machine without memory page mechanism)

Is it possible to have a Unix OS for 80286 machine (or any machine without paged memory mechanism but with segmented memory)?
80286 is a CPU without TLB, Page tables; only with segmented virtual memory and segmented protection of memory.
Is it possible to have a Linux on such machine?
UPD: the processor is very old, so I only ask about historic versions, not the ultra modern linux 2.6.42.11 or Solaris 13 or FreeBSD 10 or ...
The Linux/Microcontroller project (µClinux) is a port of Linux to systems without a Memory Management Unit (MMU).
There's the older ELKS project too.
However, due to the lack of MMU, many standard UNIX features (like fork and mmap) are not supported.
Today's Linux will only compile for a 486 or higher. So it's unlikely. I do remember 386s being somewhat supported in the 2.4.x era, but I don't remember anything about 286s.
User Zack says that Xenix (based on original UNIX) was capable of running on 80286:
There certainly were Unixes that ran on the 80286 -- Xenix comes to mind -- but I don't know if there's anything that implements what you would call a modern programming environment.
I'd checked, the Xenix FAQ http://www.uni-giessen.de/faq/archiv/sco-xenix/msg00000.html says
QA1 ... The PC/AT offered hardware memory protection, and SCO Xenix/286 took advantage of it.
So it was a PC/AT (80286) unix, which did used a memory protection using segmented memory (unlike modern unixes which use page based memory protection).
According to http://www.deinmeister.de/x86modes.htm 80286 have memory protection only in terms of segments, not a pages (pages was added in 80386).
Not sure how interested you are in the programming of it (if at all), but I was playing around with OpenCourseWare class from MIT awhile ago and they had a version of Minix they ported to x86 (not sure if it was just for 386+ or not and can't seem to find the link anymore). Anyway, if you're interested you can check it out here: MIT OpenCourseWare Operating System Engineering
I doubt so. From the very beginning, Linux was designed for the 386, using 386-specific features. MINIX, on the other hand, predates the 386 (and 286), so there should be a 286-compatible version out there.

What are the available interactive languages that run in tiny memory? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am looking for general purpose programming languages that
have an interactive (live coding) prompt
work in 32 KB of RAM by itself or 8 KB when the compiler is hosted on a separate machine
run on a microcontroller with as little as 8-32 KB RAM total (without an MMU).
Below is my list so far, what am I missing?
Python: The PyMite VM needs 64K flash, 8K RAM. Targets LPC, SAM7 and ATmegas with 8K or more. Hosted.
Lua: The eLua FAQ recommends 256K flash, 64K RAM.
FORTH: amforth needs 8K flash, 150 bytes RAM, 30 bytes EEPROM on an ATmega.
Scheme: armpit Scheme The smallest target is the LPC2103 with 32K Flash, 4K SRAM.
C: Interactive C runs on 68HC11 with no flash and 32K SRAM. Hosted.
C: picoc an open source, cross-compiling, interactive C system. When compiled for AVR, it takes 63K flash, 8K RAM. The RAM could be reduced with effort to keep tables in flash.
C++: AngelScript an open source, byte-code based, C/C++ like scripting language with easy native calls.
Tcl: TinyTCL runs on DOS, 60K binary. Looks easy to port.
BASIC: TinyBasic: Initializes with a 64K heap, might be adjustable.
Lisp
PostScript: (I haven't found a FOSS implementation for low memory yet)
Shell: bitlash: An interactive command shell for Arduino (ATmega). See also AVRSH.
A homebrew Forth runtime can be implemented in very little memory indeed. I know someone who made one on a Cosmac in the 1970s. The core runtime was just 30 bytes.
I hear that CHIP-8, XPL0, PicoC, and Objective Caml have been ported to graphing calculators.
The Wikipedia "Lego Mindstorms" article lists a bunch of programming languages that allegedly run on the Lego RCX or Lego NXT platform.
Do any of them meet your "live coding" criteria?
You might want to check out the other microcontroller Forths at the Forth wiki . It lists at least 4 Forths for the Atmel AVR: amforth (which you already mention), PFAVR, avrforth, and ByteForth.
(Links to those interpreters, as well as this StackOverflow question, are included in the "Embedded Systems" wikibook).
I would recommend LUA (or eLUA http://www.eluaproject.net/ ). I've "ported" LUA to a Cortex-M3 a while back. From the top of my head it had a flash size of 60~100KB and needed about 20KB RAM to run. I did strip down to the bare essentials, but depending on your application, that might be enough. There's still room for optimization, especially about RAM requirements, but I doubt you can run it comfortable in 8KB.
Some AVR interpreters/VMs:
http://www.cqham.ru/tbcgroup/index_eng.htm
http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php
http://www.jcwolfram.de/projekte/avr/chipbasic8/main.php
http://www.jcwolfram.de/projekte/avr/main.php
http://code.google.com/p/python-on-a-chip/
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=688&item_type=project
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=626&item_type=project
http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=460&item_type=project
http://www.harbaum.org/till/nanovm/index.shtml
Wren fits your criteria -- by default it's configured to use just 4k of RAM. AFAIK it hasn't seen any actual use, since the guy I wrote it for decided he didn't need an interpreter running wholly on the target system after all.
The language is influenced most obviously by ML and Forth.
Have you considered a port in C of Tiny Basic? Or, perhaps rewriting the UCSD Pascal p-machine to your architecture from Z-80?
Seriously, though, JavaScript would make a good embedded scripting language, but I've no clue what the minimum memory requirements are for the VM + GC, nor how difficult to remove OS dependencies. I played with NJS a while back, which could possibly fit your needs. This one is interesting in that the compiler is written in JavaScript (self hosting).
You can take a look at very powerful AvrCo Multitasking Pascal for AVR. You can try it at http://www.e-lab.de. MEGA8/88 version is free. There are tons of drivers and simulator with JTAG debugger and nice live or simulated visualizations of all standard devices (LCDCHAR, LCDGRAPH, 7SEG, 14SEG, LEDDOT, KEYBOARD, RC5, SERVO, STEPPER...).
You're missing EmbedVM, homepage here, svn repo here. Remember to check out both [1,2] videos on the front page ;)
From the homepage:
EmbedVM is a small embeddable virtual machine for microcontrollers
with a C-like language frontend. It has been tested with GCC and AVR
microcontrollers. But as the Virtual machine is rather simple it
should be easy to port it to other architectures.
The VM simulates a 16bit CPU that can access up to 64kB of memory. It
can only operate on 16bit values and arrays of 16bit and 8bit values.
There is no support for complex data structures (struct, objects,
etc.). A function can have a maximum of 32 local variables and 32
arguments.
Besides the memory for the VM, a small structure holding the VM state
and the reasonable amount of memory the EmbedVM functions need on the
stack there are no additional memory requirements for the VM.
Especially the VM does not depend on any dymaic memory management.
EmbedVM is optimized for size and simplicity, not execution speed. The
VM itself takes up about 3kB of program memory on an AVR
microcontroller. On an AVR ATmega168 running at 16MHz the VM can
execute about 75 VM instructions per millisecond.
All memory accesses done by the VM are parformed using user callback
functions. So it is possible to have some or all of the VM memory on
external memory devices, flash memory, etc. or "memory-map" hardware
functions to the VM.
The compiler is a UNIX/Linux commandline tool that reads in a *.evm
file and generates bytecode in vaious formats (binary file, intel hex,
C array initializers and a special debug output format). It also
generates a symbol file that can be used to access data in the VM
memory from the host application.
The C-like language looks like this: http://svn.clifford.at/embedvm/trunk/examples/numberquizz/vmcode.evm
I would recommend MY-BASIC, runs with in minimum 8 KB RAM, and easy to port.
There's also JavaScript, via Espruino.
This is built specifically for Microcontrollers and there are builds for various different chips (mainly STM32s) that fit a full system into as little as 8kB RAM.
Have you considered simply using the /bin/sh supplied by busybox? Or on of the smaller scripting languages they recommend?
Prolog - http://www.gprolog.org/
According to a google search "prolog small" the size of the executable can be made quite small by avoiding linking the built-in predicates.
None of the languages in the list in the question or in the answers proved satisfactory for the requirement of super easy compilation and integration into an existing micro controller project (disclosure: I didn't actually try every single one of the suggestions).
I found instead tinyscript which is a single .c+.h file that compiled with the rest of the source files on my project with the only additional configuration required being to provide a void outchar(int c) which can be empty if you don't require output from the scripts.
For me speed of execution is far less important than ease of build and integration and interop with C, as my use case is mainly just calling some C functions in order.
I have been using in my previous work busybox on a BlackFin.
we compiled perl + php for it, after changing s/fork/vfork/g it worked pretty good... more or less. Not having an MMU is not a good idea. The memory fragmentation will kill the server pretty easily. All I did was:
for i in `seq 1 100`; do wget http://black-fin-ip/test.php; done
It died while I was walking to my boss and telling him that the server is going to die in production :)
I would suggest use python. But now the only problem is the memory overhead right? So I have great idea for people who may be stuck in this problem later on.
First thing's first, write a bf interpreter(or just get source code from somewhere). The interpreter will be really small. Also bf is a Turing complete language. Now you need to write your code in python and then transpiler it to bf using bfpy( https://github.com/felko/bfpy/blob/master/README.md ). I've given you the solution with the least overhead and I am pretty sure a bf interpreter will easily stay under 10KB of ram usage.
Erlang - http://erlang.org/
it can fit in 2MB
http://www.experts123.com/q/is-erlang-small-enough-for-embedded-systems.html

how to access sound card in linux using nasm

hello i want to know how i can access sound card from nasm assembly program using int 0x80.
and also what values should i put in the registers when to access the sound card.
is there any manual or something that has details about the arguments that we have to pass to the kernel to access the sound card or other hardware devices, please if anyone know please tell me.
i had done alot of searching and well there alot of c libraries and ALSA and OSS and stuff like that, but what i would like is that if any one know of some resources about learning from the basics up about assembly program interfacing with the hardware.
and if any one could give me a small code listing as to how the access is done i would be very thankful.
As you've observed, the interface between user-space and kernel space in Linux is INT 0x80.
In Unix, as a matter of philosophy, (almost) everything is a file, thus sound cards are treated as "Character Files." The kernel syscalls are as per the POSIX specification - so "open","close","ioctl","read","write".
Access to the soundcard is done through the driver interface, as a file under "/dev/". Some sample documentation is at OSS documentation, but I'm not sure if its current.
To observe this communication, you can use 'strace' to see what system calls are being used by any existing application.
You will likely see a sequence like:
open("/dev/dsp", ... )
ioctl()
write()
...
write()
close()
Usually you'd get to "open" through the C library, but since you want to skip that, you can find the syscalls a few ways - one way would be
objdump -d /usr/lib/libc.a
For example, you can find that open is syscall 0x5 by looking for <__libc_open>:
You'll notice that eax is 5, and the rest of the parameters are in ebx, ecx and edx.
(The usage and parameters are also listed on Linux Syscalls )
This is what sound card drivers do. They have to be custom written for each sound card, in order to implement a common API which can be used by the O/S or applications. The same goes for other hardware devices. Hardware manufacturers tend to be less than open about how to access their stuff at this level (for one thing).
Not that I'm a Linux expert, but this is a fairly fundamental issue with all O/S's.
From user mode, this won't work - you won't have direct access to the sound hardware.
If you create a kernel-mode driver, you'd be able to directly poke the sound card hardware, but at this point I think most vendors have different implementations and don't follow a consistent standard. Newer sound cards might still be Adlib & SoundBlaster 16 compatible - this was the hardware standard WAY back when games were targetting DOS and directly used the hardware, but I wouldn't be surprised if this is no longer valid. A quick search should yield ways to directly access the interface for these legacy cards. Alternatively, you could run DOS inside of a virtual machine and access the hardware - most virtual machines emulate this level of sound card.
Depending what you're trying to do, you're probably better off using an existing library to handle the interface to the sound card, unless you aim to write a sound card driver, which I doubt, and that would be best done in C on linux.
Portaudio is one (free) one that's relatively easy to use. one example lib using portaudio with a C interface (I'm the author of wwviaudio).
FMOD seems to be big with the game programming guys, though it's not free.
sdl mixer is another one that's big with the linux game developers.
JACK is big in the linux pro-audio world. (think ardour -- the linux answer to Protools.)
There's no sense in trying to talk to the audio hardware directly from user space.

Protected Mode Keyboard Access on x86 Assembly

I'm working on keyboard input for a very basic kernel that I'm developing and I'm completely stuck. I can't seem to find any information online that can show me the information I need to know.
My kernel is running in protected mode right now, so I can't use the real mode keyboard routines without jumping into real mode and back, which I'm trying to avoid. I want to be able to access my keyboard from protected mode. Does anyone know how to do this? The only thing I have found so far is that it involves talking to the controller directly using in/out ports, but beyond that I'm stumped. This is, of course, is not something that comes up very often. Normally, Assembly tutorials assume you're running an operating system underneath.
I'm very new to the x86 assembly, so I'm just looking for some good resources for working with the standard hardware from protected mode. I'm compiling the Assembly source code with NASM and linking it to the C source code compiled with DJGPP. Any suggestions?
The MIT operating systems class has lots of good references. In particular, check out Adam Chapweske's resources on keyboard and mouse programming.
In short, yes, you will be using the raw in/out ports, which requires either running in kernel mode, or having the I/O permission bits (IOPL) set in the EFLAGS register. See this page for more details on I/O permissions.
You work with standard legacy hardware the same way on real and protected modes. In this case, you want to talk with the 8042 at I/O ports 0x60 to 0x6f, which in turn will talk to the controller within the keyboard at the other end of the wire.
A quick Google search found me an interesting resource at http://heim.ifi.uio.no/~stanisls/helppc/8042.html (for the 8042) and http://heim.ifi.uio.no/~stanisls/helppc/keyboard_commands.html (for the keyboard).
In case you are not used to it, you talk with components at I/O ports via the IN (read) and OUT (write) opcodes, which receive the I/O port number (a 16-bit value) and the value to be read or written (either 8, 16, or 32 bits). Note that the size read or written is important! Writing 16 bits to something which is expecting 8 bits (or vice versa) is a recipe for disaster. Get used to these opcodes, since you will be using them a lot (it is the only way to talk to some peripherals, including several essential ones; other peripherals use memory-mapped I/O (MMIO) or bus-mastering DMA).
The 8042 PS/2 Controller looks like the simplest possibility.
The oszur11 OS tutorial contains a working example under https://sourceforge.net/p/oszur11/code/ci/master/tree/Chapter_06_Shell/04_Makepp/arch/i386/arch/devices/i8042.c
Just:
sudo apt-get install build-essential qemu
sudo ln -s /usr/bin/qemu-system-i386 /usr/bin/qemu
git clone git://git.code.sf.net/p/oszur11/code oszur11
cd oszur11/Chapter_06_Shell/04_Makepp
make qemu
Tested on Ubuntu 14.04 AMD64.
My GitHub mirror (upstream inactive): https://github.com/cirosantilli/oszur11-operating-system-examples
Not reproducing it here because the code it too long, will update if I manage to isolate the keyboard part in a minimal example.

Resources