Peter's site blog
8086tiny - a very small CPU and PC emulator... but difficult to use 
Wednesday, January 28, 2015, 12:00 PM
Posted by Administrator
When I saw the first time "8086tiny" at , I was really surprised about the extremly small size of the source and executable.
I tried it on my Windows 7 x64 PC, and I was able to start it with the floppy disk image (don't forget to have sdl.dll also in your 8086tiny directory).
Later, I found also a hard disk image (about 38MB size, downloaded from dropbox), which is very useful too.
The fun stops after I recognized all text console/screen output was translated into ESC sequences. This is very annoying if you don't have a "terminal" which interprets these ESC sequences. I thought I found a solution at , which let you use ESC sequences even in a Windows 7 console prompt (just load ansicon as a command, no need for ANSI.SYS or similar things).
ANSICON worked with console output using Windows 7 (text output) programs, but not with 8086tiny. Still a lot of ESC sequences will fill your console window.

Ok, I tried Alleycat, which is also included in the floppy disk image.

It showed up the Alleycat start screen, but then screen remains black, nothing happened further.
If you are using Ctrl-C, even a Windows App Crash message appears.

It seems to be totally unusable with Windows 7 x64, I didn't tested it with Windows 7 32bit version. You can download the >SDL compatible binaries from my site<.

NO RECOMMENDATION for the original version, compiled with SDL support.

There is another version named "8086 Tiny Plus" which works well, MUCH BETTER than the original one. Take a look at
It uses NO ANSI sequences, instead, it includes a BIOS with CGA support.
But this version is bigger than the original one. Still small compared to DOSBOX or whatever else can be compared.

The modified version "8086 Tiny Plus" IS RECOMMENDED. Because it works.
add comment ( 128 views )   |  permalink   |  related link   |   ( 3.3 / 291 )
Some tests with PGP 6.5.8 from NAI and ckt builds of PGP and Windows 7 [offtopic] 
Saturday, January 24, 2015, 04:00 PM
Posted by Administrator
While looking for Symantec PGP 10.x alternatives, I started to think about using old versions of PGP, too. At least the ADK problem should be fixed (see ... ments.html ), so I had to start with 6.5.8ckt or newer.
Unfortunately PGP 7, PGP 8 (which I think personally was the best of all) are not really working in Windows 7, and PGP 9 and newer can be used, but should not be used due to considerations about trusting Symantec (they will cooperate with the NSA for sure and they offered the source only 'til version 10.0.1 from 2011, but they offer and deliver newer versions meanwhile only without source code review possibility).

Also, I read some dumb comments additional keys in the NAI versions.
So I started with the original 6.5.8 PGP version from NAI.

The PGP Memory Page Locking Driver does NOT work with Windows 7, but the programs are still running, if you're giving them administrative rights (that problem is unfortunately not solved yes, but it depends from the installation directory and because this version wants to write his keyring by default into the program directory).

You can fix this by setting a registry value to 1 (the name of it: ClearPageFileAtShutdown), so you can be sure after shutting down the PC, the pagefile is at least cleared.

I created a PGP keypair and encrypted a file (with "PGP tools").
After that, I uninstalled the original PGP 6.5.8 and installed Imad R. Faiad's "ckt build" version 8 (and later 9b3, which shows 9b2, a bit weird), using the already created key. It gaves exactly the same result.

Then, I created a new key (with similar parameters) and encrypted again the above used file. Again the resulting file had at least exactly the same size.
Just for testing purposes, I added an additional key - again with the same file.
I got a different file size for the encrypted file - as expected.
So I can't see any difference between using the NAI version and the "ckt builds".
But you have to use the "ckt builds" for two reasons at least:
There is no ADK weakness in the "ckt builds" (see above) and you can use much longer keys, although most of the cryptographers say, more than 3072 bit key length is wasted effort.

Meanwhile it's a bit difficult to get these ckt builds as a binary.
Try it with the "related link" below, at least you can search the web for "" and/or "", and for the source try to search for "".
add comment ( 129 views )   |  permalink   |  related link   |   ( 3.1 / 3143 )
The perfect virus ? NSA's "barnfire" program and implications [offtopic] 
Monday, January 19, 2015, 07:00 PM
Posted by Administrator
The german magazine Spiegel published new infos about some (meanwhile old but still valid) NSA programs in their latest >article<. They also mentioned "barnfire", which is a codename for a BIOS modification to bypass all virus scanners and other (local) detection mechanisms.
Bruce Schneider offers also infos about at, although it does not contain much more infos, see >here<.
His blog points to , inside the 7z archive is also a file named media-35661.pdf which mentions "BARNFIRE"
A year ago news were published about a >BadBIOS super trojaner<, but not found yet in a real example.
Also, in January 2014, infos were published about >a similar NSA project named DEITYBOUNCE<, which describes that DELL server were hacked and manipulated by NSA also.

A modified BIOS (it must be a modified one, not a new one, because otherwise it can be easily discovered) does not help if hard disks are encrypted. May be you can "chain/hook" into Windows API after Windows is already booted (and encryption is active), but this seems to be a much more sophisticated approach. It has to be possible to extend functions while they are loaded in memory, because even Windows API will use in its driver BIOS calls (at least in drivers, but may be in some basic parts of the OS too).
You can't modify directly files on disk unless you "know" the encryption keys/encryption algorithm, but you don't need to have the knowledge about it, if your "base" is the BIOS itself.
It's like placing a virus on your harddisk, but the virus is located in the BIOS itself and can't be detected by scanning files or even memory.
But your PC's BIOS flash memory does not have to be write protected. Fortunately new computers only protects the firmware flashing "entry" of the BIOS, but this is SOFTWARE, so unless your PC is not protected by "jumper", it can be bypassed. The function "Flash BIOS" is also just a piece of software.

So the possible attack sequence might be:
1 - try to use a zero day exploit
2 - if successful, identify the used firmware
3 - load the appropriate but modified BIOS
4 - flash the BIOS
5 - delete all traces
6 - reboot (or just wait)

Remember, you will be still protected by external IT security components like http-Proxy servers, unless you analyze also the network traffic with your backdoor code. But this will make the BIOS modifications almost impossible, because you need much more code.

I guess the simpler variation of the BIOS mod is already existing, made by smart programmers @NSA ...
add comment ( 103 views )   |  permalink   |  related link   |   ( 3.1 / 2968 )
640K Ought to be Enough for Anyone 
Monday, January 12, 2015, 10:00 PM
Posted by Administrator
For most DOS software, this might be true.
I am referring to that "quote", because a few days ago, I upgraded my Schneider (Amstrad) PC 1512 to 640KB RAM. And yes, for this machine, it is enough to run most of the programs of an exciting decade.

But where does this "out to be enough" sentence come from ?

Most of the "googled" internet hits says Bill Gates said this.
At least there is one source of a similar sentence he said:
In Infoworld magazine from April 29th, 1985 (Vol.7 Issue 17), you can read at page 5:

When we set the upper limit of PC-DOS at 640K, we thought nobody would ever need that much memory.

William Gates, Chairman of Microsoft

You can read the whole article here (click on picture):

But some already further investigated some more possible sources, so it's difficult to say "Bill Gates" said this. Go on reading at

At least, this all is (interesting) history.

P.S.: I have seen a negative feedback (below 3) for this entry. Please give me a note why with "add comment", thank you in advance.
add comment ( 118 views )   |  permalink   |  related link   |   ( 3.1 / 3076 )
Pioneer hardware with a (meanwhile) rare CPU: Cosmac Elf (1976) ... and his successors 
Sunday, January 4, 2015, 10:00 PM
Posted by Administrator
This is really cool:
The "ancient" CMOS CPU from RCA, the 1802, can be still found in SBC projects like the "1802 Cosmicos" and the "COSMAC Elf 2000" !

Why is a SBC so interesting with the RCA 1802 ?
Because the CPU is also used in many satellites and (former) rockets (it was also manufactured as a radiation resistant variation), and it was one of the first 8 Bit CPUs available, too.
Some of the first video consoles used the RCA 1802, too.
In 1976, it was the fastest (3.58Mhz) running CPU, unfortunately no bigger computer manufacturing company used it for their models.
The CPU was also used in a rare homecomputer named "COMX35", but that's the only one of his kind I know.
The first SBC, the Cosmac Elf, was published in August 1976 in "Popular Electronics".

You can take a look at the articles also >here< and >here<.
You should also visit


Hans Otten has his own page about his 1802 Cosmicos SBC:
Infos about the "COSMAC Elf 2000" can be found here:

But you don't need real hardware to try to program a RCA 1802.
There is a really good emulator:
Another emulator can be found here:

Take a look at for a first impression about the CPU.
Then look at the instruction list at

Picture was taken from wikipedia.
add comment ( 114 views )   |  permalink   |  related link   |   ( 3.1 / 854 )

<<First <Back | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | Next> Last>>