Vetus Pars Coding - Retrotroniks Forum

Missing documentation CLKST and CLKSTP

arnljot — Thu, 25 Jun 2026 00:48:35 +0000

It would be nice to know what frequency they send, if it's meaningful to use for ICs that use a clock.

I have a small collection of OKI clock chips, would be nice to put a little green sticker on them :)

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?

Register Variables?

aadhoc4370 — Mon, 09 Feb 2026 05:07:08 +0000

Firstly, this is great. I love anything that makes code more declarative & readable.

I wonder about using "register variables"

The example `DIM MYVAR 0xFF` look like you're doing replaces, such as `REGLOD 0x1 MYVAR 0x0` becomes `REGLOD 0x1 0xFF 0x0`
The example `DIM MYREG #R5` might be a "replace" as well, so `IF 0x1 MYREG 0x08` would be `IF 0x1 #R5 0x08` ?!?!?
But, what happens with a `GETADDR 0x1 MYREG 0x0`? Does it become `GETADDR 0x1 #R5 0x0` ? I think the docs say the syntax must be `GETADDR 0x1 0x5 0x0`

This doc text is my confusion:
In code, if you are getting a value from the register then you need to use #Rn where n is the register number. If you are doing anything to a register other then using its value then you should simply use the register number for the argument.

I've found I have to specifically use `#R10` or `0xa` depending on situation and had to create my own converter (via preprocessing).
Have you changed something, or is there special handling or more uniform handling now for registers, or "register variables"?

Or have I misunderstood something?
Thanks

Failing a test?

aadhoc4370 — Tue, 03 Feb 2026 17:08:19 +0000

How does a test failure work?

I know PASSFAIL can be used to set the final status of 0x0 (fail) or 0x1 (pass)... and I know the test should start with a PASSFAIL 0x0

The chip tests you coded use IF statements to set PASSFAIL and perform a SHOSTR that displays a custom fail message. Then a moment later the screen clears and becomes the common red failure screen.

But according to the code, after that IF, the test continues.... so I think you have some non-obvious "code short circuiting" check points going on that looks for PASSFAIL failure state and chooses not to continue the test if the test has already failed? Hmmmm... though it feels like a bad coding practice... could PASSFAIL be set to 0x1, then set back to 0x0 without the test ending?

Q1: When is the PASSFAIL checked and test stopped?

Q2: Can my test leave ever the custom progress/pass/fail details on the screen or will green/red screen always replace my script's output?