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.

As you can see, there was an "expansion" board with a Z80 cpu for the CBM 8032.
Madison Computer build a board named "Z-RAM". But it wasn't only a RAM expansion. It was also a CPU addon board, running CP/M 2.2. The disk format still used GCR coding, means the 6502 was still used for I/O operations, similar to the C64 running CP/M with the Z80 cartridge.
This wonderful but rare expansion was seen at the Classic Computing in Schoenau, Germany, a few days ago. Data Becker sold this as "CP/Maker" in Germany in 1982/1983.
For more information about the expansion board, visit Mike Naberezny's Site, see below "related link"...

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.