Vetus Pars Coding - Retrotroniks Forum

Writing CHIP for CA3083

mbrando — Thu, 24 Sep 2026 23:11:45 +0000

Hello,

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.

Hello World! CHIP for CD74HCT245E

mbrando — Thu, 24 Sep 2026 22:54:54 +0000

Hey everyone,

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.

KM4164B-12 DRAM Test Files: 1W1R and 2W2R for Vetus Pars 2.0

Midwest Mac — Wed, 23 Sep 2026 16:57:41 +0000

I’ve created two test files for the Samsung KM4164B-12 64K × 1-bit DRAM using Vetus Pars hardware revision 1.01 with firmware and VetusGUI running 2.0.

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.

vp-Tools and Website almost ready

rbourque — Fri, 10 Apr 2026 01:23:07 +0000

Status update

The website is mostly done in dark mode, and I'm still working on light mode. https://caffeinatedbytes.com

A very basic Forum is also now online for tech support. It also allow to the poster to pick the best solution.

vp-Tools seems to be working (vp-chip, vp-asm, vp-flash and vp-man) and successfully communicate the the backend to download, search, flash chips, etc.

Everything still needs testing. I still need to do some small things like make user friendly error messages instead of exception messages for things like flashing when not in USB mode, or when the wrong COM port is selected.

I'm away for the next 4 days but when I return I will be granting @nivbot access to download the tools for betatesting. If he approves I will open it up to a couple more serious testers to try out the command line tools.

My goal is to also add a screen to the website to examine chips online as well as an option for vp-chip to upload chips to share with others. I'll do that when the current vp-tools is out of betatesting.

I have a day job and a part time company in my spare time so progress on this project has been slow and was started impulsively. I think the Vetus Pars is an amazing tool and I want to help get it known out there so it has a chance to compete with the other overpriced tools. A word to Canadians, after the exchange rate and duty fees and tax it's over $200, and is still less than half the price of Retro chip tester. Someday I want to buy a second one to mess around putting it in a 3d printed case, but I'm going to wait until the Canadian dollar is stronger.

To Blink or not to Blnk

Midwest Mac — Sun, 29 Mar 2026 23:48:23 +0000

VETUS_PARS_CODING.txt documentation needs a correction / update.

BLNKON should be BLINKON: 0x68
BLNKOFF should be BLINKOFF: 0x69

Yes, minor, but if a correction will save someone else a few head-scratching minutes it's worth it in my opinion.

MOS 6526 (CIA) Testing

Midwest Mac — Sun, 29 Mar 2026 21:59:30 +0000

Getting my feet wet in creating .chip files, i've created a couple simple Proof-of-Concept for the MOS 6526 (aka CIA chip for the Commodore 64). Wasn't sure where to upload these, so I'll just share the text here:

Simple Reset:

type = single



---



name = 6526 (CIA) RESET POC
pins = 40
type = 5
imageIndex = 9



PASSFAIL 0x1 0x0 0x0
ASAFE 0x0 0x0 0x0
SHOSTR 0x0 0x0 0x18
UDSCRN 0x0 0x0 0x0
SETOUT 0x16 0x0 0x0
SETOUT 0x17 0x0 0x0
SETOUT 0x18 0x0 0x0
SETOUT 0x19 0x0 0x0
SETOUT 0x22 0x0 0x0
SETPIN 0x16 0x1 0x0
SETPIN 0x17 0x1 0x0
SETPIN 0x18 0x1 0x0
SETPIN 0x19 0x0 0x0
SETPIN 0x22 0x1 0x0
DELMS 0x64 0x0 0x0
SHOSTR 0x1 0x0 0x18
UDSCRN 0x0 0x0 0x0
SETPIN 0x22 0x0 0x0
DELMS 0x14 0x0 0x0
SETPIN 0x22 0x1 0x0
DELMS 0x64 0x0 0x0
SHOSTR 0x2 0x0 0x18
UDSCRN 0x0 0x0 0x0
DELMS 0x64 0x0 0x0
ENDTEST 0x0 0x0 0x0



0=6526 reset poc start
1=6526 reset poc low
2=6526 reset poc done
3=
4=
5=
6=
7=

Reset followed by DDRA:

type = single



---



name = 6526-DDRA-POC
pins = 40
type = 5
imageIndex = 9



PASSFAIL 0x1 0x0 0x0
ASAFE 0x0 0x0 0x0
SHOSTR 0x0 0x0 0x18
UDSCRN 0x0 0x0 0x0
DEF8 0x0 0x1A1B1C1D 0x1E1F2021
SETIN 0x1A 0x0 0x0
SETIN 0x1B 0x0 0x0
SETIN 0x1C 0x0 0x0
SETIN 0x1D 0x0 0x0
SETIN 0x1E 0x0 0x0
SETIN 0x1F 0x0 0x0
SETIN 0x20 0x0 0x0
SETIN 0x21 0x0 0x0
SETOUT 0x16 0x0 0x0
SETOUT 0x17 0x0 0x0
SETOUT 0x19 0x0 0x0
SETOUT 0x22 0x0 0x0
SETOUT 0x23 0x0 0x0
SETOUT 0x24 0x0 0x0
SETOUT 0x25 0x0 0x0
SETOUT 0x26 0x0 0x0
SETPIN 0x16 0x1 0x0
SETPIN 0x17 0x1 0x0
SETPIN 0x19 0x0 0x0
SETPIN 0x22 0x1 0x0
SETPIN 0x23 0x0 0x0
SETPIN 0x24 0x0 0x0
SETPIN 0x25 0x0 0x0
SETPIN 0x26 0x0 0x0
DELMS 0x64 0x0 0x0
SHOSTR 0x1 0x0 0x18
UDSCRN 0x0 0x0 0x0
SETPIN 0x22 0x0 0x0
DELMS 0x14 0x0 0x0
SETPIN 0x22 0x1 0x0
DELMS 0x14 0x0 0x0
SHOSTR 0x2 0x0 0x18
UDSCRN 0x0 0x0 0x0
SETPIN 0x23 0x0 0x0
SETPIN 0x24 0x1 0x0
SETPIN 0x25 0x0 0x0
SETPIN 0x26 0x0 0x0
SETPIN 0x16 0x1 0x0
SETPIN 0x17 0x0 0x0
DELUS 0x10 0x0 0x0
SETPIN 0x19 0x1 0x0
DELUS 0x10 0x0 0x0
GET8 0x0 0x0 0x0
SETPIN 0x19 0x0 0x0
SETPIN 0x17 0x1 0x0
IF 0x1 #R0 0x0
SHOSTR 0x3 0x0 0x18
UDSCRN 0x0 0x0 0x0
PASSFAIL 0x0 0x0 0x0
ENDTEST 0x0 0x0 0x0
ENDIF 0x0 0x0 0x0
SHOSTR 0x4 0x0 0x18
UDSCRN 0x0 0x0 0x0
DELMS 0x64 0x0 0x0
ENDTEST 0x0 0x0 0x0



0=6526 ddra poc start
1=6526 reset
2=6526 read ddra
3=6526 ddra fail
4=6526 ddra ok
5=
6=
7=

Command Line Assembler?

rbourque — Fri, 27 Feb 2026 12:58:32 +0000

Have you ever considered making a command line assembler instead of your current GUI in Unity? (It looks like Unity libraries, strange choice for development) Or documenting the communication with the device so other people can help you with supporting tools?

I believe that the people buying Vetus Pars are going to be very techie people anyway and I find the current GUI really more of a hindrance. People who just want to test chips would buy a BackBit Chip Tester or a Retro Chip Tester Pro and they would be very frustrated with the Vetus Pars.

A python assembler would satisfy Linux/Mac/Windows users, and simple scripts would make the process very easy to use.

A simple cheat sheet online for each of your GUI buttons Like "READ PIN: " would be a nice reference so we won't have to scroll up and down so much, combined with a command line compiler and the user's favourite text editor would be perfect.

This is just constructive criticism, I'm not knocking down your project at all, so please don't take what I'm saying the wrong way.
I think you've done some amazing work and I have a lot of respect for what you have accomplished.

Documentation samples

aadhoc4370 — Tue, 10 Feb 2026 02:30:32 +0000

I was thinking that every opcode needs a simple (yet functional) example to accompany your documentation.
I'm probably going to start walking down the opcodes and write an example for each.
Plus, I'm going to see if a "unit test" idea will be a natural fit. That will show how the opcode works AND will test the opcodes themselves.

This will also be a way to start demonstrating effective standards for coding tests.
I'll start posting some here so we can discuss and agree before I get too deep in it.
(I might even PM you with some so we don't overly clutter up this thread)

Once you've got an inventory you like of "unit tests" for opcodes/concepts/standards, you could add it to your docs.

BTNPR, BTNWT, WHILE, BRKLOOP, DOUNTIL, JMP ?

aadhoc4370 — Mon, 09 Feb 2026 06:05:05 +0000

Can you describe these undocumented opcodes and show how they could be used?

The control statements look good.
The button opcodes look interesting. They let the test interact with the user?

Allow missing 0x0?

aadhoc4370 — Mon, 09 Feb 2026 05:52:24 +0000

Can we stop writing all the extra 0x0's?

I might suggest having the parser notice when 3 aren't provided, and fill in 0x0 for all missing arguments.
(Or the parser could be smarter)

```
LOOP 0xF 0x0 0x0
SET8 0x1 #R1 0x1
GET8 0x2 0x2 0x0
IF 0x1 #R2 0xF
PASSFAIL 0x0 0x0 0x0
ENDTEST 0x0 0x0 0x0
ENDIF 0x0 0x0 0x0
DELMS 0x1 0x0 0x0
REGINC 0x1 0x0 0x0
ENDLOOP 0x0 0x0 0x0
```

Becomes
```
LOOP 0xF
SET8 0x1 #R1 0x1
GET8 0x2 0x2
IF 0x1 #R2 0xF
PASSFAIL 0x0
ENDTEST
ENDIF
DELMS 0x1
REGINC 0x1
ENDLOOP
```

Notes:
- I expect the tokenizer would fill these in, so no firmware updates are necessary.
- I don't like exceptions, so a rule like "any trailing arguments of `0x0` may be left out and are assumed to be `0x0`" should apply to all opcodes to prevent confusion.
- In cases where 0x0 is a real value, such as `REGLOD 0x1 0x0`, I personally don't think it's a problem to let people use `REGLOD 0x1` shorthand. In C and C#, we know that if you write `int a`, the variable defaults to 0.
- This might be a confusing one: `PASSFAIL`. That would set the test status to fail. The test would start with `PASSFAIL 0x1` and on a failed chip validation (sub test), we'd write `PASSFAIL; ENDTEST` or if we have "constant variables", define "PASS 0x1; FAIL 0x0" so we can write `PASSFAIL FAIL; ENDTEST`. Come to think of it, it would also be strange to see `REGLOD` which would load value 0x0 into register 0x0 (#R0).
- The other option around this is have your tokenizer know how many arguments each opcode needs, and just have the reserved/unused parameters be ones we can omit... and it fills in. So just having `PASSFAIL` or just `REGLOD` wouldn't "compile" and must include the required parameters.

I really don't want to type or see this anymore (Only 3 of those 18 args are real):
```
PASSFAIL 0x0 0x0 0x0
ENDTEST 0x0 0x0 0x0
ENDIF 0x0 0x0 0x0
DELMS 0x1 0x0 0x0
REGINC 0x1 0x0 0x0
ENDLOOP 0x0 0x0 0x0
```

Thoughts?