Blatant Programming Question
-
I have to agree - the IAR Z80-C compiler is particularly bad at this. But then, I guess the Z80 when it was originally designed never had much of a memory space anyway (although 64K was a very good size for embedded work in those days) And come to think of it, I haven't seen an IAR compiler I did like the output of anyway! :laugh:
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Indeed, even by 1980 most computers still had 16k or less. I can remember huge (S-100) memory boards that used some Intel DRAM controller and had up to 32 4016 16k x 1 DRAMS, 64k RAM total. Those things cost between 800 and 1000 Dollars (far beyond my budget with being only 14 years old :)) and nororiously suffered from issues with the DRAM's refresh. 4k static RAM was all I could afford, but it still works. That was not really much, but already enough to get some things working. Hey, I could even load a debugger (2.25 k) and debug programs of up to 1.75k. No debugging anymore if they got bigger than that. :)
-
Indeed, even by 1980 most computers still had 16k or less. I can remember huge (S-100) memory boards that used some Intel DRAM controller and had up to 32 4016 16k x 1 DRAMS, 64k RAM total. Those things cost between 800 and 1000 Dollars (far beyond my budget with being only 14 years old :)) and nororiously suffered from issues with the DRAM's refresh. 4k static RAM was all I could afford, but it still works. That was not really much, but already enough to get some things working. Hey, I could even load a debugger (2.25 k) and debug programs of up to 1.75k. No debugging anymore if they got bigger than that. :)
Lucky bugger! We had 8K, but had to write our own debuggers - and we couldn't have spared 2.25K for it! I think it was probably a couple of hundred bytes, and could only display register and memory values, pause that kind of thing. Variable names? No chance - look up the address on the assembler output (no linker) and look at that!
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
Lucky bugger! We had 8K, but had to write our own debuggers - and we couldn't have spared 2.25K for it! I think it was probably a couple of hundred bytes, and could only display register and memory values, pause that kind of thing. Variable names? No chance - look up the address on the assembler output (no linker) and look at that!
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
It was a machine code debugger, so there were no variable names as well. You could, however, set breakpoints, single step through the instructions and examine the CPU registers or the screen output of the program. And it relocated the entire program to the memory behind it automatically, while displaying everything as if it were located at its normal starting address. The first software I ever bought (for something like 10 or 15 Dollars). It was a good investment. I have it running right now. It has been converted from tape to binary with the program I wrote about a few days ago. Now I use Visual Studio to edit the sources and start the assembler, then I can load the debugger and the program into an emulator (with 64k RAM :)) and see if it works. For now I'm emulating the old hardware, since I have not yet built my new version.
-
It was a machine code debugger, so there were no variable names as well. You could, however, set breakpoints, single step through the instructions and examine the CPU registers or the screen output of the program. And it relocated the entire program to the memory behind it automatically, while displaying everything as if it were located at its normal starting address. The first software I ever bought (for something like 10 or 15 Dollars). It was a good investment. I have it running right now. It has been converted from tape to binary with the program I wrote about a few days ago. Now I use Visual Studio to edit the sources and start the assembler, then I can load the debugger and the program into an emulator (with 64k RAM :)) and see if it works. For now I'm emulating the old hardware, since I have not yet built my new version.
Ooo! Breakpoints would have been lovely! (As would single stepping). But there was no hardware support, and our code ran in EPROM becasue we had so little memory we couldn't fit the code in and still do anything. I looked at doing both in software, but with a variable length instruction set and no MMU it wasn't an option I could spend enough time on.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
I have to agree - the IAR Z80-C compiler is particularly bad at this. But then, I guess the Z80 when it was originally designed never had much of a memory space anyway (although 64K was a very good size for embedded work in those days) And come to think of it, I haven't seen an IAR compiler I did like the output of anyway! :laugh:
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
IAR is still in business and still makes compilers and I believe IDE for embedded systems.
VS2010/Atmel Studio 6.0 ToDo Manager Extension
Version 3.0 now available. There is no place like 127.0.0.1 -
... for which there will certainly be no more adequate place to post it. And I don't really expect more than some moral support. :) So here we go: I'm planing to build a computer again, with up to 8 CPUs (CDP1802, what else?), up to 8 Mb RAM, Graphics based on the old MC6847 graphics chip (with one of the CPUs dedicated as graphics processor). An 8 bit machine with processors from 1976, which would have outperformed typical 16 bit Amigas or Atari STs from 1990. :) I also want PS/2 ports for the keyboard and a mouse, but don't want to use microcontrollers. I have read, that in IBM's first AT models the Intel 8255 parallel port was used in bit mode for that purpose. Does anybody have more information about that? The old computers based on the CDP1802 worked quite well without any OS, but this will obviously not be the case here. So I fired up both the assembler and the C compiler and started coding. The code generated by the C compiler was more than eight times longer than that produced by the assembler. So much for compilers generating much better code than you possibly could manually. But, to be fair, it is no secret that 8 bit processors are generally not well suited for C. Looking at the machine code confirmed that. The C compiler needed all that extra code to pass parameters to functions and keep local variables on the stack. The oldschool assembly techniques relied far more on global variables or holding values in the CDP1802's large register set. Before I really can get to work now, I will need to work out some kind of calling convention which does not bloat the code too much, does not bog down the CPU by doing actually more work to pass parameters and variables than anything else, while trying to at least reduce the need for globals. Still, it now seems very strange that even the processor's handbook saw no need to discuss any techniques beyond global data. For recursive calls they worried about keeping the return address on the stack, but that's all. Who cares about parameters or local variables? Edit: Just for fun: A small part of the assembler's listing:
(1) 118/ 34 : ; =========================================================================================
(1) 119/ 34 : ; Interrupt and DMA service routine for the CDP1861 to display an effective resolution
(1) 120/ 34 : ; of 64 x 64 pixels, using a display buffer of 512 bytes.
(1) 121/ 34 : ; ===============================If I understand you correctly, it's early and just now getting my first cup-o-joe you are looking to find a convention for passing variables to subroutine. Check out my article AVR Assembly 101[^] the section "Mixing Languages", about half way down explains a way.
VS2010/Atmel Studio 6.0 ToDo Manager Extension
Version 3.0 now available. There is no place like 127.0.0.1 -
If I understand you correctly, it's early and just now getting my first cup-o-joe you are looking to find a convention for passing variables to subroutine. Check out my article AVR Assembly 101[^] the section "Mixing Languages", about half way down explains a way.
VS2010/Atmel Studio 6.0 ToDo Manager Extension
Version 3.0 now available. There is no place like 127.0.0.1Thanks. If I understand it correctly, you are passing parameters directly in registers. That's ecactly what I'm doing right now. Even with a large register set the number of parameters is obviously limited. The way C functions are called is more interesting: The parameters are pushed onto the stack and stay there until the function exits. Local variables are allocated on the stack as well. Nested function calls are no problem, because those values stay on the stack until the nested function returns. That is nice and well, but accessing the variables on the stack can become very awkward with 8 bit processors and twice as awkward with my little CDP1802. It's a RISC processor and has no fancy addressing modes that could help. Whenever I would want to access a variable on the stack, I would have to load the base address into a register and perform some math on that address for it to finaly point at the right place. And that kind of stuff is exactly what bloated up the C compiler's code so much. The best compromise I have come up with yet would be to push the register's contents onto the stack before calling another function and restoring them when it returns. It's nice that C compilers hide away those things, but it also tends to hide that you are actually writing awkward and slow code.
-
Thanks. If I understand it correctly, you are passing parameters directly in registers. That's ecactly what I'm doing right now. Even with a large register set the number of parameters is obviously limited. The way C functions are called is more interesting: The parameters are pushed onto the stack and stay there until the function exits. Local variables are allocated on the stack as well. Nested function calls are no problem, because those values stay on the stack until the nested function returns. That is nice and well, but accessing the variables on the stack can become very awkward with 8 bit processors and twice as awkward with my little CDP1802. It's a RISC processor and has no fancy addressing modes that could help. Whenever I would want to access a variable on the stack, I would have to load the base address into a register and perform some math on that address for it to finaly point at the right place. And that kind of stuff is exactly what bloated up the C compiler's code so much. The best compromise I have come up with yet would be to push the register's contents onto the stack before calling another function and restoring them when it returns. It's nice that C compilers hide away those things, but it also tends to hide that you are actually writing awkward and slow code.
Well, why don't you throw out those old CDP1802 processors and get some Pentiums? They're still old but are much better with C! :laugh:
- Life in the fast lane is only fun if you live in a country with no speed limits. - Of all the things I have lost, it is my mind that I miss the most. - I vaguely remember having a good memory...
-
Thanks. If I understand it correctly, you are passing parameters directly in registers. That's ecactly what I'm doing right now. Even with a large register set the number of parameters is obviously limited. The way C functions are called is more interesting: The parameters are pushed onto the stack and stay there until the function exits. Local variables are allocated on the stack as well. Nested function calls are no problem, because those values stay on the stack until the nested function returns. That is nice and well, but accessing the variables on the stack can become very awkward with 8 bit processors and twice as awkward with my little CDP1802. It's a RISC processor and has no fancy addressing modes that could help. Whenever I would want to access a variable on the stack, I would have to load the base address into a register and perform some math on that address for it to finaly point at the right place. And that kind of stuff is exactly what bloated up the C compiler's code so much. The best compromise I have come up with yet would be to push the register's contents onto the stack before calling another function and restoring them when it returns. It's nice that C compilers hide away those things, but it also tends to hide that you are actually writing awkward and slow code.
CDP1802 wrote:
Even with a large register set the number of parameters is obviously limited.
It is very limited but is the less painful way if you only have a few parameters.
CDP1802 wrote:
That is nice and well, but accessing the variables on the stack can become very awkward with 8 bit processors and twice as awkward with my little CDP1802. It's a RISC processor and has no fancy addressing modes that could help. Whenever I would want to access a variable on the stack, I would have to load the base address into a register and perform some math on that address for it to finaly point at the right place. And that kind of stuff is exactly what bloated up the C compiler's code so much.
If you are passing a large number of variables there really isn't an elegant way to do it.
CDP1802 wrote:
It's nice that C compilers hide away those things, but it also tends to hide that you are actually writing awkward and slow code.
Yes it depends a lot on the compiler and how well they optimize the code. Like anything else there is good and bad.
VS2010/Atmel Studio 6.0 ToDo Manager Extension
Version 3.0 now available. There is no place like 127.0.0.1 -
Well, why don't you throw out those old CDP1802 processors and get some Pentiums? They're still old but are much better with C! :laugh:
- Life in the fast lane is only fun if you live in a country with no speed limits. - Of all the things I have lost, it is my mind that I miss the most. - I vaguely remember having a good memory...
-
... for which there will certainly be no more adequate place to post it. And I don't really expect more than some moral support. :) So here we go: I'm planing to build a computer again, with up to 8 CPUs (CDP1802, what else?), up to 8 Mb RAM, Graphics based on the old MC6847 graphics chip (with one of the CPUs dedicated as graphics processor). An 8 bit machine with processors from 1976, which would have outperformed typical 16 bit Amigas or Atari STs from 1990. :) I also want PS/2 ports for the keyboard and a mouse, but don't want to use microcontrollers. I have read, that in IBM's first AT models the Intel 8255 parallel port was used in bit mode for that purpose. Does anybody have more information about that? The old computers based on the CDP1802 worked quite well without any OS, but this will obviously not be the case here. So I fired up both the assembler and the C compiler and started coding. The code generated by the C compiler was more than eight times longer than that produced by the assembler. So much for compilers generating much better code than you possibly could manually. But, to be fair, it is no secret that 8 bit processors are generally not well suited for C. Looking at the machine code confirmed that. The C compiler needed all that extra code to pass parameters to functions and keep local variables on the stack. The oldschool assembly techniques relied far more on global variables or holding values in the CDP1802's large register set. Before I really can get to work now, I will need to work out some kind of calling convention which does not bloat the code too much, does not bog down the CPU by doing actually more work to pass parameters and variables than anything else, while trying to at least reduce the need for globals. Still, it now seems very strange that even the processor's handbook saw no need to discuss any techniques beyond global data. For recursive calls they worried about keeping the return address on the stack, but that's all. Who cares about parameters or local variables? Edit: Just for fun: A small part of the assembler's listing:
(1) 118/ 34 : ; =========================================================================================
(1) 119/ 34 : ; Interrupt and DMA service routine for the CDP1861 to display an effective resolution
(1) 120/ 34 : ; of 64 x 64 pixels, using a display buffer of 512 bytes.
(1) 121/ 34 : ; ===============================CDP1802 wrote:
it is no secret that 8 bit processors are generally not well suited for C.
True; C was written for 12-bit processors and performs poorly with any other word width. ;P
-
... for which there will certainly be no more adequate place to post it. And I don't really expect more than some moral support. :) So here we go: I'm planing to build a computer again, with up to 8 CPUs (CDP1802, what else?), up to 8 Mb RAM, Graphics based on the old MC6847 graphics chip (with one of the CPUs dedicated as graphics processor). An 8 bit machine with processors from 1976, which would have outperformed typical 16 bit Amigas or Atari STs from 1990. :) I also want PS/2 ports for the keyboard and a mouse, but don't want to use microcontrollers. I have read, that in IBM's first AT models the Intel 8255 parallel port was used in bit mode for that purpose. Does anybody have more information about that? The old computers based on the CDP1802 worked quite well without any OS, but this will obviously not be the case here. So I fired up both the assembler and the C compiler and started coding. The code generated by the C compiler was more than eight times longer than that produced by the assembler. So much for compilers generating much better code than you possibly could manually. But, to be fair, it is no secret that 8 bit processors are generally not well suited for C. Looking at the machine code confirmed that. The C compiler needed all that extra code to pass parameters to functions and keep local variables on the stack. The oldschool assembly techniques relied far more on global variables or holding values in the CDP1802's large register set. Before I really can get to work now, I will need to work out some kind of calling convention which does not bloat the code too much, does not bog down the CPU by doing actually more work to pass parameters and variables than anything else, while trying to at least reduce the need for globals. Still, it now seems very strange that even the processor's handbook saw no need to discuss any techniques beyond global data. For recursive calls they worried about keeping the return address on the stack, but that's all. Who cares about parameters or local variables? Edit: Just for fun: A small part of the assembler's listing:
(1) 118/ 34 : ; =========================================================================================
(1) 119/ 34 : ; Interrupt and DMA service routine for the CDP1861 to display an effective resolution
(1) 120/ 34 : ; of 64 x 64 pixels, using a display buffer of 512 bytes.
(1) 121/ 34 : ; ===============================Why in the world do you want to use a CDP1802? I gave away my Apple IIc because it used that heap of crap! No LONG CALL instruction (though a LONG JMP was implemented) made it messy to program anything useful. I moved to an Epson QX-16 instead, since it used a far more logical instruction set, with symmetric CALL and JMP instructions, and used a 2 bit register to enable 4 separate banks of RAM and extend my addressing capacity to 256k. The 8255 was a great I/O controller, by the way, as was the Signetics 2651 USART, which is what you want for a PS/2 serial port. IIRC, the PS/2 is a 4-pin interface that includes TxD, RxD, Signal Ground, and Frame Ground as a four-wire RS232 port, relying on software handshaking (Xon/Xoff) rather than the older hardware handshaking (RTS/CTS). Both will do the job, though the 8255 was designed to integrate nicely with the Z80 bus structure.
Will Rogers never met me.
-
Why in the world do you want to use a CDP1802? I gave away my Apple IIc because it used that heap of crap! No LONG CALL instruction (though a LONG JMP was implemented) made it messy to program anything useful. I moved to an Epson QX-16 instead, since it used a far more logical instruction set, with symmetric CALL and JMP instructions, and used a 2 bit register to enable 4 separate banks of RAM and extend my addressing capacity to 256k. The 8255 was a great I/O controller, by the way, as was the Signetics 2651 USART, which is what you want for a PS/2 serial port. IIRC, the PS/2 is a 4-pin interface that includes TxD, RxD, Signal Ground, and Frame Ground as a four-wire RS232 port, relying on software handshaking (Xon/Xoff) rather than the older hardware handshaking (RTS/CTS). Both will do the job, though the 8255 was designed to integrate nicely with the Z80 bus structure.
Will Rogers never met me.
Roger Wright wrote:
I gave away my Apple IIc because it used that heap of crap!
If you had not done that, you could now get a small bundle of cash for it from the fanboys. And the processor was a 6502, like in the 8 bit Ataris or C64s (their 6510 was a clone with minor modifications).
Roger Wright wrote:
Both will do the job, though the 8255 was designed to integrate nicely with the Z80 bus structure.
No wonder. The 8255 was designed for Intel processors, while the Z80 was intended to be an enhanced 8080 clone.
-
... for which there will certainly be no more adequate place to post it. And I don't really expect more than some moral support. :) So here we go: I'm planing to build a computer again, with up to 8 CPUs (CDP1802, what else?), up to 8 Mb RAM, Graphics based on the old MC6847 graphics chip (with one of the CPUs dedicated as graphics processor). An 8 bit machine with processors from 1976, which would have outperformed typical 16 bit Amigas or Atari STs from 1990. :) I also want PS/2 ports for the keyboard and a mouse, but don't want to use microcontrollers. I have read, that in IBM's first AT models the Intel 8255 parallel port was used in bit mode for that purpose. Does anybody have more information about that? The old computers based on the CDP1802 worked quite well without any OS, but this will obviously not be the case here. So I fired up both the assembler and the C compiler and started coding. The code generated by the C compiler was more than eight times longer than that produced by the assembler. So much for compilers generating much better code than you possibly could manually. But, to be fair, it is no secret that 8 bit processors are generally not well suited for C. Looking at the machine code confirmed that. The C compiler needed all that extra code to pass parameters to functions and keep local variables on the stack. The oldschool assembly techniques relied far more on global variables or holding values in the CDP1802's large register set. Before I really can get to work now, I will need to work out some kind of calling convention which does not bloat the code too much, does not bog down the CPU by doing actually more work to pass parameters and variables than anything else, while trying to at least reduce the need for globals. Still, it now seems very strange that even the processor's handbook saw no need to discuss any techniques beyond global data. For recursive calls they worried about keeping the return address on the stack, but that's all. Who cares about parameters or local variables? Edit: Just for fun: A small part of the assembler's listing:
(1) 118/ 34 : ; =========================================================================================
(1) 119/ 34 : ; Interrupt and DMA service routine for the CDP1861 to display an effective resolution
(1) 120/ 34 : ; of 64 x 64 pixels, using a display buffer of 512 bytes.
(1) 121/ 34 : ; =============================== -
Roger Wright wrote:
I gave away my Apple IIc because it used that heap of crap!
If you had not done that, you could now get a small bundle of cash for it from the fanboys. And the processor was a 6502, like in the 8 bit Ataris or C64s (their 6510 was a clone with minor modifications).
Roger Wright wrote:
Both will do the job, though the 8255 was designed to integrate nicely with the Z80 bus structure.
No wonder. The 8255 was designed for Intel processors, while the Z80 was intended to be an enhanced 8080 clone.
CDP1802 wrote:
6502
Yup, you're right - memories fade in time... :-D
Will Rogers never met me.
-
CDP1802 wrote:
6502
Yup, you're right - memories fade in time... :-D
Will Rogers never met me.
-
My own technique : push the registers, use the registers for anything you need them, pull the registers.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Do not feed the troll ! - Common proverb
Why not try compiling some C for a couple of subroutines that reflect your application for an alternative RISC machine ? I suggest you download a free toolchain such as CodeSourcery G++, find out how to select compilation for an earlier ARM CPU, switch on every optimisation possible and see what comes out in the mixed lising, maybe get some ideas ? If that is not to your taste maybe there is another RISC as resource-absent as the CPD1802 you could do something similar for ? Not sure how old the CPD1802 C compiler is...I could always hammer a compiler with a.n.other assembler for smaller chips but I wouldn't be so sanguine in the face of recent compiler advances... If that doesn't work maybe there is a fully static CPD1802 model in VHDL you could pop into a fast small FPGA and generate your own CPU running at warp speed and hence making your execution problems vanish - faster bus-interfacing problems aside, that is... What is your application anyway ? Is the CPD1802 the only non-Intel chip licensed for space flight ? What is wrong with an ARM Cortex-based microcontroller ? Was Rick Deckard really Nexus 6 ? Anyway, the best of luck with your project, I hope you have a lot of fun solving your puzzles and get a great result.
-
... for which there will certainly be no more adequate place to post it. And I don't really expect more than some moral support. :) So here we go: I'm planing to build a computer again, with up to 8 CPUs (CDP1802, what else?), up to 8 Mb RAM, Graphics based on the old MC6847 graphics chip (with one of the CPUs dedicated as graphics processor). An 8 bit machine with processors from 1976, which would have outperformed typical 16 bit Amigas or Atari STs from 1990. :) I also want PS/2 ports for the keyboard and a mouse, but don't want to use microcontrollers. I have read, that in IBM's first AT models the Intel 8255 parallel port was used in bit mode for that purpose. Does anybody have more information about that? The old computers based on the CDP1802 worked quite well without any OS, but this will obviously not be the case here. So I fired up both the assembler and the C compiler and started coding. The code generated by the C compiler was more than eight times longer than that produced by the assembler. So much for compilers generating much better code than you possibly could manually. But, to be fair, it is no secret that 8 bit processors are generally not well suited for C. Looking at the machine code confirmed that. The C compiler needed all that extra code to pass parameters to functions and keep local variables on the stack. The oldschool assembly techniques relied far more on global variables or holding values in the CDP1802's large register set. Before I really can get to work now, I will need to work out some kind of calling convention which does not bloat the code too much, does not bog down the CPU by doing actually more work to pass parameters and variables than anything else, while trying to at least reduce the need for globals. Still, it now seems very strange that even the processor's handbook saw no need to discuss any techniques beyond global data. For recursive calls they worried about keeping the return address on the stack, but that's all. Who cares about parameters or local variables? Edit: Just for fun: A small part of the assembler's listing:
(1) 118/ 34 : ; =========================================================================================
(1) 119/ 34 : ; Interrupt and DMA service routine for the CDP1861 to display an effective resolution
(1) 120/ 34 : ; of 64 x 64 pixels, using a display buffer of 512 bytes.
(1) 121/ 34 : ; =============================== -
... for which there will certainly be no more adequate place to post it. And I don't really expect more than some moral support. :) So here we go: I'm planing to build a computer again, with up to 8 CPUs (CDP1802, what else?), up to 8 Mb RAM, Graphics based on the old MC6847 graphics chip (with one of the CPUs dedicated as graphics processor). An 8 bit machine with processors from 1976, which would have outperformed typical 16 bit Amigas or Atari STs from 1990. :) I also want PS/2 ports for the keyboard and a mouse, but don't want to use microcontrollers. I have read, that in IBM's first AT models the Intel 8255 parallel port was used in bit mode for that purpose. Does anybody have more information about that? The old computers based on the CDP1802 worked quite well without any OS, but this will obviously not be the case here. So I fired up both the assembler and the C compiler and started coding. The code generated by the C compiler was more than eight times longer than that produced by the assembler. So much for compilers generating much better code than you possibly could manually. But, to be fair, it is no secret that 8 bit processors are generally not well suited for C. Looking at the machine code confirmed that. The C compiler needed all that extra code to pass parameters to functions and keep local variables on the stack. The oldschool assembly techniques relied far more on global variables or holding values in the CDP1802's large register set. Before I really can get to work now, I will need to work out some kind of calling convention which does not bloat the code too much, does not bog down the CPU by doing actually more work to pass parameters and variables than anything else, while trying to at least reduce the need for globals. Still, it now seems very strange that even the processor's handbook saw no need to discuss any techniques beyond global data. For recursive calls they worried about keeping the return address on the stack, but that's all. Who cares about parameters or local variables? Edit: Just for fun: A small part of the assembler's listing:
(1) 118/ 34 : ; =========================================================================================
(1) 119/ 34 : ; Interrupt and DMA service routine for the CDP1861 to display an effective resolution
(1) 120/ 34 : ; of 64 x 64 pixels, using a display buffer of 512 bytes.
(1) 121/ 34 : ; ===============================Have you tried liberal use of the "register" keyword? Its supposed to keep variables in registers, if possible. And I recall something about it passing parameters to functions in registers instead of on the stack if used in the function parameter delcaration. You can write some amazingly small code in C if you try.. like the main loop of a marching pattern memory test in 15 bytes (just small enough to completely fit in the 16 byte instruction cache of the 386 and scream). [has anybody noticed, if your VI fingers take over and you press esc twice in a row while typing in the message entry box, you loose your entire message with no warning and way to recover it? Guess we now know that codeproject coders have never used VI :)]
We can program with only 1's, but if all you've got are zeros, you've got nothing.
