Prevent software from running on new computers or virtual machines.

There is going to be one massive obstacle: Emulators.

Don't confuse emulators with hypervisors.

An emulator can fake everything the application "sees".

I was recently involved in getting an old DOS application to run. The application communicates over a serial port, but has some shoddy programming causing it to crash if the UART has a FIFO buffer larger than one byte. The application starts just fine under DOSBox, but as soon as the serial comms start, it crashes. DOSBox emulates a 16550A UART, which has 16 bytes FOFO buffer. If DOSBox would be modified to emulate an older 8250, I assume it would work.

They were compatible.

the computers that were sold to the US military. Zenith bought Heatthkit t o get into the computer business. The bidding process required bidders to a lready be in the computer business. Typical of Heathkit, ports were all at the wrong addresses, sou you had to run ZDOS. A third party board was sold that remapped the addresses so you could run software not written by Heathk it/Zenith.

If interested in the "original" bios source code, find a copy of the IBM Te chnical Reference manual, circa 1983 (4?) Don't recall the publication dat e and am too lazy to get a step stool to get it from the top shelf of my li brary. It is probably floating around the web somewhere.

It was a very handy reference back in the day when we cannibalized the PCs for the MBs and wrote our own rtos for industrial control applications.

ters and not on new computers and not on virtual machines ?!

are from being run on newer computers or virtual machines ? :)

The UARTs for the 80xx family at the time of the original PC were the intel 8250. It was not double/multiple buffered, and the person(s) who wrote th e driver were clueless about how to write an circular queue/dequeue handler . Coupled with the fact that the UART generated an interrupt with every cha racter resulting in a high overhead at high speeds, e.g. 9600 bps +. (and the 'genius' Bill Gates was also clueless about how to design print dr ivers as well..but that is another story) The standard upgrade was to get a serial port card with the NS16550 (more precisely the NS16550A which fixe d the programmable interrupt logic on the 16450 to interrupt on 1,4,8, or 1

He wanted "old", but then I realsed that PCIe parallel ports are available.

If you compile it for the 8008, how would you know if it works?

If you need to do a test run on actual hardware, I can help.

Port I/O can be trapped and emulated, yes.

No, it makes zero sense. It is just another of your knee jerk reactions to a lack of understanding of PCs and the world in general.

Nothing you can do will ever make even a tiny dent in what the rest of the world does.

If anyone needs them, I have some available. Probably free if you pay the shipping.

Before the 8086 was officially released. Intel claimed that 8086 was compatible with 8080.

However, when the 8086 opcode mapping was released, it became clear that those processors were not binary compatible, only some assembler mnemonics looked familiar. Intel then quickly removed the compatibility claim from their marketing material.

Thus, there is no point of trying to execute 8080/Z80 code on 8086.

I may not recall this correctly, but I believe they had a switch that would allow 8080 code to be compiled for the 8086. Even if the source code was not interchangeable, the functionality was. Am I remembering this incorrectly?

If this is not the case, it would have been a huge failure for Intel marketing. A company heavily invested in Intel processors would have had little reason to stick with Intel 16 bit products.

My only 8-bit software I wrote or modified was for the 6502/6510. I didn 't use a compiler. I used a sector editor, and wrote the code in machine la nguage. I even rewrote the sector editor from a second copy on the disk to remove the oldest floppy drives, to add a 3.5" drive. I also cleaned up the GUI to use the space freed up from the deleted drives. It displayed as eig ht rows of 32 bytes, instead of six lines of 40, and one line of 16 bytes. That was over 30 yeas ago.

I did write a decompiler for the Commodore floppy disk drives. It read the PROMS in a drive, and wrote the output to a disk in the drive. That was don e in Basic, since I was in a hurry.

ld allow 8080 code to be compiled for the 8086. Even if the source code wa s not interchangeable, the functionality was. Am I remembering this incorr ectly?

eting. A company heavily invested in Intel processors would have had littl e reason to stick with Intel 16 bit products.

Was it a cross compiler? That would allow existing code to be ported over to the newer CPU, while newer code was being written.

I used to write Science Fiction for relaxation. In one story, they had a co mputer with a 1024 Byte data bus. It was a supercomputer, with the ability to take the code for any known processor, decompile it, and recompile it to run on the 32 core, 4 GHz processors in it's native code. I wrote that whe n a 12 MHz AT with two MB of RAM and a 10MB HD was leading edge. :)

ould allow 8080 code to be compiled for the 8086. Even if the source code was not interchangeable, the functionality was. Am I remembering this inco rrectly?

rketing. A company heavily invested in Intel processors would have had lit tle reason to stick with Intel 16 bit products.

er to the newer CPU, while newer code was being written.

computer with a 1024 Byte data bus. It was a supercomputer, with the abilit y to take the code for any known processor, decompile it, and recompile it to run on the 32 core, 4 GHz processors in it's native code. I wrote that w hen a 12 MHz AT with two MB of RAM and a 10MB HD was leading edge. :)

I think you misunderstand what a cross compiler is. It's actually not a ve ry useful term by it's proper definition. "A cross compiler is a compiler capable of creating executable code for a platform other than the one on wh ich the compiler is running". Who really cares what CPU is running the com piler?

From what I understand, the 16550 is configured for single byte FIFO by default in order to maintain backwards compatibility. The application would have to explicitly activate the FIFO if it wanted to use it.

Have I misunderstood?

Well if you learn to use google and type 'trinary computer' you'll find out, won't you.

Un the old days all utility programs including assemblers, compilers and linkers were written in assembler to minimize size of the program in order to maximize the size of the symbol table and hence allowing larger programs to be assembled/compiled/linked.

I have written several crossassemblers running a 16 bit mini in assembler, one was for a 20 bit processor and the other for a decimal computer with 10 decimal digit words and 3 decimal digit addresses (0...999) The problem was how to allocate just one 16 bit word for each symbol table value to conserve symbol table space and allow large symbol tables. These symbol tables needed to be kept in memory between passes (the passes used overlay loading).

HAHA :) This is easy to fix with a fixpatch that's out there ;)

It modifies the exe and voila fixed, or it modifies some crt unit or something and needs recompile, but I think it was actually an exe fix too.

Bye, Skybuck.

The claim was based on an assembly code converter program provided by Intel. The produced code was not too good, so I ended up rewriting the code for 8086 (actually 8088, no PC yet).

The initial PC processor was an 8088, not 8008, internally a 16 bit machine with an external 8 bit bus.

The thing that run both 8086 and 8080 code was NEC V20, with mode switching logic and entry/exit mechanism built in.