I want to Write CHIP for CA3083 IC. It is a five-transistor NPN array, not a powered digital IC.

Before writing a safe .chip file, one essential hardware question needs to be resolved:

Does the Vetus fixture provide per-pin current limiting / external resistor paths for analog transistor testing? The CA3083 is rated for up to 100 mA collector current, but direct digital output pins must not be used to force transistor junctions without known current limiting. Its base-emitter reverse-voltage limit is only 5 V, so an uncontrolled digital pin test could damage the IC.

Any thoughts on this would be helpful. 

I made my first CHIP file for the CD74HCT245E with Perplexity help. We tried to make a counter and pause but it would not work. SO here is the basic. 

---

CD74HCT245E Test Overview

This .chip file is a basic functional test for a CD74HCT245E / 74HCT245 20-pin octal bus transceiver in a DIP-20 socket.

It tests the chip in both data directions:

• A-to-B direction: Sets DIR high and enables outputs with active-low OE.
• Drives the A bus with four patterns: 00, FF, 55, and AA.
• Reads the B bus after each pattern and checks that it matches.
• B-to-A direction: Sets DIR low, keeps outputs enabled, and repeats the same four patterns.
• Drives the B bus and verifies that the A bus matches.

The patterns check:

• All outputs low (00)
• All outputs high (FF)
• Alternating bits (55)
• The opposite alternating bits (AA)

At the end, the program disables the transceiver output by taking OE high, returns both buses to input mode, executes ASAFE, and reports PASS. If any expected bus value does not match, it executes ASAFE, reports FAIL, and stops.

What it does not test

• It does not prove that the outputs are truly high impedance when OE is high. A reliable Hi-Z test needs external pull-up/pull-down resistors or other fixture support.
• It does not measure output voltage levels, current drive capability, propagation delay, leakage, or timing specifications.
• It does not identify counterfeit or marginal parts that happen to pass these static logic patterns.
• It does not provide a batch/pass counter or automatic “remove/insert next” loop. The tested counter/restart approach was not reliable on the current firmware, so this version uses the normal result-screen workflow.

The file is intended as a practical go/no-go functional screen, not a complete production-characterization test. Before removing or inserting a device, wait for the normal test result and use the tester’s standard navigation; ASAFE releases tester-controlled socket I/O lines, but it should not be assumed to remove any automatic socket supply rail without confirming that behavior on the specific hardware.

I just received my VETUS PARS. It is assembled and my first launch of the VetusGUI2-0-0-OSX I get an error. 

"VetusGUI" Not Opened

Apple could not verify "VetusGUI" is free of malware that may harm your Mac or compromise your privacy.

I think you can fix this by either going to Settings -> Privacy and Security -> Open anyway. 

However, I cleaner fix would be for the Apple developer to have have the App notarized by Apple. 

I attached screenshot. 

Just saying, it would be a cleaner user experience. 

Also, the license is now free so you can download a license file and use RetroCPLD for all the supported chips. I only ask you provide an email so that you can stay informed of updates. Programmer support for ATF15xxASV (3.3 volts) is definitely coming so if you want that it would behoove you to stay informed. And that's it. Hopefully anyone who has downloaded RetroCPLD reads this and gets the update. It's a nice addition to be able just keep working without changing commands or programmers. 

TLDR: RetroCPLD can now program with ATDH1150USB or USB Blaster (except Windows), license is free. You can donate if you wish, that would be kinda cool. 

Both tests begin with a short address-line check and then exercise all 65,536 memory cells. The memory is treated as 256 rows × 256 columns.

Each row is tested in eight blocks of 32 columns. The display shows progress similar to:

Row 001 / 256
Col 032 / 256

1W1R test

This is the shorter routine screening test.

• Writes one checkerboard value to every cell
• Reads and verifies that value
• Covers all 65,536 cells
• Performs 65,536 writes and 65,536 verified reads
• Alternates the checkerboard polarity by row, so half the cells are tested with 0 and half with 1

Each individual cell is tested at only one logic value. A passing result therefore confirms full-address coverage, but it does not prove that every cell can store both 0 and 1.

2W2R test

This is the more thorough and longer-running test.

• Writes a checkerboard pattern to every cell and verifies it
• Writes the inverse checkerboard pattern and verifies it
• Tests every cell once as 0 and once as 1
• Performs 131,072 writes and 131,072 verified reads

The 2W2R test should take approximately twice as long as 1W1R, in addition to display-update overhead.

It's been a lot of long days and nights but the new firmware and GUI and other goodies are finally finished. All of the documentation has been updated and all downloads are ready to go. Any bugs founding the beta have been fixed and all should be good to go. Granted, if you find a bug be sure to let me know. 

From now on all information about Vetus Pars is in one place and that is the main Vetus Pars page which is right here. I hope you all enjoy it as much as I do. 

Sorry if anyone had issues.

-Kelvin 

Let's hope the old saying "The third times a charm" holds true. As this is my third time making this post. It started with a very bad web host to a crazy day and night of migrating. Anyway, I think the worst of all of that is over so if you had issues logging in or doing anything on the site that its why. The migration is complete and hopefully no one will have to wait 10 minutes for their page to load if it even does. Now, that being said, let's get to the real reason for this post. I have completed beta versions of each natively coded GUI for OSX, Win64 and Linux (mint). I would say they are roughly 95% complete. They just need a little bit of polish and a few things added that I am either mulling over or would like feedback on if possible. I can tell you though that they are working great and I'd like to share them with you and hopefully you'll give me feedback. Don't worry about hurting my feelings and let me know if you have issues or dislike something. Criticism of this type only helps and there is nothing offensive about it. OK, that said. Let me go over a little bit.

As I said these Beta builds are basically complete I just want some time to look over everything, do a little pre-release clean up etc. The core of the GUI system is the same as before. Load your files, you can batch save, or load the file and edit it then send to Vetus and either save or run it. Just like before. There are some changes though that I need to make you aware of so that you can test them with confidence. Without further ado.

- The new firmware is version 2.0.0. The old GUIs will not work with Vetus that has this firmware installed. The new GUIs will only work with firmware 2.0.0 and up. And vice versa. the new firmware will not work with the old GUIs. So if you update one, update them all. You can of course revert in the same way you upgrade. 

- Tests no longer require that all three arguments be added to your code if an opcode doesn't use them. In fact, you will now get an error if you ad an extra argument. That being the case, if you load an old test script that has all of the arguments for every opcode you will get a bunch of errors. These aren't critical, you just need to delete the extra arguments. I have also redone all of the current tests in the new style so those are there for you as well. 

- You no longer need to use HEX in your arguments. You may use decimal or binary or HEX at your leisure. Code imported from a test on Vetus will still import with HEX values and any DIM variable shown as it's value rather then the variable name. Just as before. This however, is not the case with addresses. Because of the way addresses are setup you must still use the HEX value for each address pin as before. 

- There are now tool bars beside the editor for each OpCode that give a short description and allows you to insert the arguments. For OpCode that require pins there is an optional mock chip that allows you to set the pins visually. You can also do this for addresses making the HEX value method trivial as it will write the values for you when you select the pins. 

- Connections are much better than before. You should have few if any issues reconnecting if you unplug, turn off or close the GUI. You should no longer have times where you need to turn off Vetus or restart the GUI to connect. It COULD happen I suppose, I haven't had it happen yet though so it is rather secure in that way.

- Also for connections, uploads are much faster and way more reliable. Batch uploads are especially faster.

- Serials - Serial numbers are no longer stamped on the PCB, serials are now created algorithmically from the STM32's serial number. It is not the same serial it is just derived from it. When you start Vetus you will see the serial and you will also see it when you connect to the GUI.

- Settings. settings have now been moved totally to the GUI Menu. There are not many as a lot of the previous settings can now be set in other ways in the GUI, from normal use. 

- Fonts manager has been added. you can create, open font files and upload them to one of 6 slots on the left hand side. By selecting a slot you can delete or save a font to that slot. Fonts cannot be imported from Vetus and edited you must use a file to create or upload the font. I'll include the original two here.

- Image manager, you can now edit images if you'd like. Images can be created from scratch sent to a file or sent to Vetus. As of right now, the images in Vetus are called from an index and as such you cannot select the slot you add the image to. It will always go to the last slot (256 total). Also, I haven't yet decided how to implement deleting images. So as of now you cannot. this will change soon but I'm weighing options. Images are compressed via RLE well my own RLE I don't know if it is what a typical RLE would be but anyway, you don't need to now that stuff but you will see the code for the image at the bottom. Just know that the more colors you have and the more changes in those colors the bigger the file will be with 4096 bytes as the limit, this limit is enforced by VertusGUI however, you can still save the image to a file if you wish. You just cannot upload it to vetus until it is under 4096 bytes. 

- There are new OpCodes for specialty test boards. You can see these tentative and likely to change opcodes in this version. These are for special test boards that have special functions. You will be able to send commands and retrieve data etc. But as of now these are not functioning as there are no boards that take advantage of that yet. There is one addon board that doesn't use those functions but it does have a board ID. the 30 Pin SIMM board (coming soon). You will see in the start menu there is now a brd scan option. This is so you can make sure the proper test board is on Vetus. For the default 40 pin ZIF the scan will only show Default or Unknown board. Others will show their board ID and or name. There is also a get board ID command now. Default and unknown return 0. Other boards return a 16bit ID. This is so tests that use them can ensure the board is correct before starting as some boards might and likely will have higher voltages. Users are allowed to make their own test boards and once the DOCS are ready and this is fully released info for making them will be available. 

That's all I can think of for now without my notes but I think you can all manage it well enough. It is a lot of the same with improvements and some additions. Because of how this forum, works I can only add one file at a time. I will add the firmware then the GUI files in their own replies. Then extra files. If you have comments about a specific version please reply to my original reply. I hope that makes sense. Anyway, without further ado, I give you new stuff... haha

I am wrapping up the OSX version of the new GUI very soon and the other OSs soon after. I have one question to ask that I believe I know thew answer to but I would like to have your opinions. Sometimes when you are working on something like this certain features might seem to fit or might make sense while developing that don't really do anything for the real end-user. So, I recently decided to make room for more technical features by removing the settings menu page and removing the code and strings section of the chip information screen. It will now show the info as soon as you select the chip and you simply need to click button 2 to test once on that screen.

You will still be able to control everything in the settings from the new GUI app. So, the features will still be there they just won't be hogging up Vetus' display menu. 

How does everyone feel about that? My assumption in that no one ever uses anything from the settings more than maybe once or twice and the benefits from doing it this way far exceed whatever downsides there are (if any). I'd love to hear your opinions. 

Thanks

-Kelvin