If NO IMAGES will be shown, use www.z80.eu/blog instead of blog.z80.eu

Please note also - THIS BLOG ENDS HERE WITH THE LAST ENTRY FROM NOVEMBER 9th 2021.

I have prepared a new blog with wordpress at https://vintagecomputing.info !!!

Thank you.

The TI Programmer was a real unusual calculator, because it can calculate also with hexadecimal and octal numbers, means not only add and substract, but also bit operations like AND, OR, XOR or SHIFT. This was one of the earliest devices of it's kind, although it was not the first (the SR-22 was the first). But it's still worth to be presented, also because not many was sold since it's debut in 1977. Technically it's very similar to the TI-30.

It's funny to look what the calculator does after a bit idle time. Something is running through the display ...

(it was too much work to animate all 8 possible dots, but all 8 positions are used)
See also the related link for more information.

Andrew Kay died yesterday in Vista, California. He got 95 years old.
See also for a homage at >NY Times<.
For an overview of the most known computers he designed, see also >my KAYPRO pages<.
For a >recent photo of him<, visit the above mentioned NY Times page also.

If you follow >Bruce Schneier's blog<, you will notice an >unusual entry<. He agreed with another blog entry about PGP from Matthew Green which was titled >"What's the matter with PGP?"<.
Matthew Green complained about usability and key management of PGP (... but mainly related with email), but he didn't gave any proof about a lack of (IT) security. Instead, he just spoke ill about using PGP and email in general.
If he is a cryptographer, why is he doing that ? I mean he can point his finger at real faults or errors, or at least weak spots in algorithms and methods. But he didn't.
He 's talking about cumpersome processes related with PGP. But it's related with the design of the "Web of trust". It's not really a fault.
Do you trust central key storages in cloud solutions ? That's awesome for secret services, because they will find standardized environments with large amounts of data at once, sure.
What is the alternative solution ? S/MIME for email ? Still not manageable for a "normal" user. Also, you have to trust a central provider you don't know (and may be a secret service has already access to that central provider).
If I just want to have data integrity, and I want to make sure no one else except me and my communication partner can read my messages, PGP is still a good choice. That's my opinion.
And I am disappointed about Bruce Schneiers posting such an unqualified blog entry without any further reflection. Not sure about his intention ... except there is a hidden agenda behind it.
This can be similar to the "truecrypt case". Someone (guess who) don't want that users encrypt their data in a secure manner, so they discrediting the unwanted solution. Instead, you should use "Bitlocker". Lol, be honest, that's NOT a solution I will trust. It's closed source. They could implement whatever they want. Think about >"key escrowing"<.

I am still trusting - >like Phil Zimmermann< - at least Open Source implementations of PGP, because I still see no legitimate reason why not.

And I am not alone with my opinion about Mr. Green's blog entry. See >Aaron Toponce's Blog Entry< also.

A few weeks ago, I obtained a Trantor T130 SCSI ISA 8-Bit controller, and I realized I had to burn an EPROM and also a PAL/GAL chip (both were missing), see >this< blog entry also.
I burned successfully the ROM content, this was easy.
Now I tried to burn also GAL chip, but I run into problems - I guess the chinese programmer can't interpret some JEDEC files or there is a problem with the JEDEC file itself.
Everytime I load the JEDEC file (download from >a vintage-computer blog entry<, included in the attached T130B.ZIP), I see no changes in the Data View window.

I tried to convert the JEDEC file into a binary one, using the JEDUTIL.EXE which is included in the MAME distribution. I got a file with 279 bytes - seems to be wrong also.

Also, I was unsure about the sum of fuses for a 16V8 GAL, but (meanwhile) this seems to be not the problem. I tried also another JEDEC file from http://www.princeton.edu/~mae412/HANDOU ... /EMP21.jed ... this worked, loading it shows also changed data in the data window!

This chinese programmer software (I got version 5.2 which seems to be the newest one) has an ugly user interface and the english translation was not really successful done. Also, some functions can't be used intuitively, e.g. to read a device, you have to choose "CONNECT" first (why not connect the device automatically when "read" is selected ?).
Also, the "programming sequence" let me think about it again.


I have to ask other users of these G540/G840 programmers for their expirience I guess...

See related link for the JEDEC file I can't use.

Added later:
>I have modified the non-working JEDEC file<, and as a result of it, I can load it into the programmer now. 2194 fuses seems to be correct, because these additional fuses (compared to 2048 fuses user data) are not used for normal data, instead, for managing content and special parameters.

I also figured out (again later) that the G840 programmer should not ENCRYPT it as a last step, otherwise a comparison with the loaded content (into buffer) will not work too.

After swapping the WD8013 card with a 3Com 3C503, I continued to install TCP/IP package.

You have to install STREAMS first - before TCP/IP, as usual with "custom" and "Add package" (Option '4'). It's a different serial/key combination compared to the TCP/IP package itself.

After you've added STREAMS, you can go on with TCP/IP Disk 1, start again "custom" and choose also "Add package" (Option '4'). After inserting all 3 Disks plus the TCP/IP maintance disk and entering again the serial/key combination (but now the one for TCP/IP), you've not finished it.

I read in a PDF document that also a SCO LLI Driver Disk (the hardware related part) was needed. You can find a version 3.0 of that LLI disk at ftp://ftp.sco.com/pub/EFS/efs120.Z (uncompress it with WINRAR for example, you will get a 1200KB (disk) tar file - copy it with doscp later from a 1.44MB DOS formatted floppy disk and rewrite it back with dd, like described in part 3 of my Xenix blog entry).

Unfortunately this LLI driver disk version 3.0 resulted in a version warning ("LLI should not be installed in any releases prior to 3.2.1." - not sure where to get a proper SCO LLI driver disk which fits for Xenix 2.3.4 ..... I WAS STUCK !


Looking for a "LLI driver disk" I found a bit later a hint, that XENIX 2.3.4 does not need and use a LLI driver disk ! I felt being framed from that above mentioned document.

So I looked for some help about using ifconfig with XENIX, and finally I found a really helpful page (here and later this one).
They mentioned to use mkdev wdn, but I looked at /usr/lib/mkdev and found the proper file was named "3comB". "mkdev 3comB" started the setup for the card and later on the kernel was rebuild also.
But 'ping' still generates 'ping: socket: Protocol not supported' .... bummer
Also, ifconfig still does not work - "ifconfig /dev/3comB0" says "invalid argument" ...

At the end I tried also "mkdev tcp" and that was the key for success !
With "mkdev tcp" you can setup your machines IP address as well as other important parameters. And after another reboot, even PING worked, and so also ifconfig 3comB0:


YES. FINALLY TCP/IP IS UP AND RUNNING WITH XENIX !!!!

If you google for "mkdev tcp", you will find several .doc files, which are located in a SCO driver directory and also existing are drivers there (e.g. ftp://ftparch.emu.edu.tr/Programs/Drivers/lan/EZ2000/SCOUNIX/ or http://download.modem-help.co.uk/mfcs-L ... e=#archive). So I guess it would be possible to run a NE2000 card also with XENIX.

Note: The related link below (a PDF at tenox.net) was NOT helpful. It describes a very different installation procedure for a later SCO UNIX version.