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.

When I REFRESH to pull the current list, there is a blank file at the bottom of the list in VetusGUI. If I load that from the hardware into VetusGUI, I will get either the correct Code, Chip Name, Num Pins, Chip Type, and Image fields but the String# fields will all be empty or have invalid characters in them - OR - I will get nothing.

A full reboot of the hardware, close/open of VetusGUI and doing a direct SAVE TO results in the same type of behavior. 

I'm on Windows 11, I have updated the hardware to 1.0.3. I have other much smaller test chip files that saved and run without issue.

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.

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=

Next I deleted some of the pre-installed tests that came on my Vetus and attempted to load them from the website (ex 6502-cj.chip, 4164.chip).  From the GUI I can save the file and do get confirmation that the file saved, although repeating the above steps still shows a blank entry. 

I've tried to backdate the firmware to 1.0.2, but got the same results.

I've tried to reinstall the firmware to 1.0.3, but also got the same results.

Is it possible the internal memory has become corrupted?  and is it possible to factory reset this?

System - Windows 11.

Firmware - 1.0.3

The order is:  Port (select a com port), Add (add a chip file), Highlight the file, Click Load, Select USB Mode from the Vetus Pars.  Any deviation of this and the GUI does not see the Vetus Pars.

Is there a driver that I may need to install.  I have tried this on USB 2, USB 3 ports, and multiple USB cables.  All produce the same result. 

Thanks

Just received my unit and put together. Super please with build quality.

Did my first test on a 4464 DRAM chip. Takes a while but the chip passed.

A little bit later ran the test on a second 4464 chip. Does a column count to 255 and then goes to the next section of the test and the DRAM fails. I tried this with a number of chip and get the same issue. I tried the first chip that did pass and now it's failing.

Using the VU GUI on my Mac, I can't actually see the unit connected although it did show up previously.

Any suggestions on how to resolve this issue?

Thanks

macsonny

New firmware update 03/13/2026: vetus-1-0-3.zip. This update is for version 1.0.3.

Vetus Pars 1.0.3

Fixed:

• Search by type has been revamped. It will now list all of the saved chips of whichever type is selected in alphabetical order
• Addressing has been optimized for significantly faster operation. Longer tests should be noticeably faster.
• WHILE will now properly nest within other loops. Syntax remains unchanged.
• MAX nested loops has been increased to an overkilling 32
• BREAK LOOP is now more stable and should work inside or outside any kind of loop. This OpCode will end only the loop that immediately contains it.
• Jump has been improved to work better with loops. Jumping from inside of a loop now properly ends any loop the jump command is called from and nested within. eg. LOOP LOOP JUMP 0x5 ENDLOOP ENDLOOP would end both loops and go to line 5.
• Now, by JUMPing into a loop or series of loops you will continue inside of that loop starting at the line you jumped to until the loop finishes. For obvious reasons it’s best to NOT jump into loops but it will not structurally break your code if you do so (be mindful of variables)
• The 16 bit address OpCodes have been increased to 32 bit. Where as before when defining an address you would use 0x0 as the first argument to show you were defining the first 8 bits of the address, and for the next 8 bits the first argument would be 0x8; we now can use 0x10 (16) as the first argument to define the pins for a 24 bit address and 0x18 (24) as the first argument to define the last 8 pins of a 32 bit address. For ex: DEFADDR 0x0 0x04030201 0x08070605 – would define pins 1 – 8 as addresses 0-7, DEFADDR 0x8 0x0C0B0A09 0x100F0E0D – would define pins 9 – 16 as address bits 8 – 15, DEFADDR 0x10 0x14131211 0x18171615 would define pins 17 – 24 as address bits 16 – 23, DEFADDR 0x18 0x1C1B1A19 0x201F1E1D would define pins 25 – 32 as address bits 24 – 31. Then of course, you would use the number of address bits you need as the first argument of SetAddress and GetAddress just as before only now you can have up to 32.

In Downloads

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.   

This will be fixed with the next update. Just remember that if you need to set the register value in any way then you need to use either a regular HEX value or set a regular hex value variable for the register just for when setting value. For now.