What's the reason for the version number in the VERA chip?

[grml]

According to the latest docs, you can now read some version number from VERA's registers. What is the rationale for this change? What is the average programmer gonna do with the information?

[BruceRMcF]

Wouldn't the normal scenario there be that after initial release, a bug is found and fixed, and you have a program that requires that bug fix, so your loading Basic program can have a look at the version number, and if the number is from before the bug fix, you can warn the user that there may be a problem.

[grml]

Yeah that's possible but it's also a new thing that's not being done anywhere else in the project as far as I can tell. Seems kind of weird why it's added now. Would have hoped for some insight.

You would only do this if you expect major changes over time, right? Also 4 registers just for a version number -- that's future proof.

[BruceRMcF]

There has been identifying information in the ROM for years, but of course you don't have to make any provision for having identifying information in a ROM segment, you just have to include it somewhere that is not executing code. The serial flash ROM that contains the Vera implementation can't be read by the 65C02 in service, so if you want to extend that to identifying information to Vera, you're going to have to make it available from a register.

As far as why now, that's a good question to pose to the design team. It could easily be because they've finally reached the point where the hardware is getting a lot more eyes and hands checking things out, so the issue of having to keep track of whether bug A with a known fix may be involved in a new observed bug B is a much more live issue than when there was two or three versions of a particular prototype revision.

[TomXP411]

Yeah that's possible but it's also a new thing that's not being done anywhere else in the project as far as I can tell. Seems kind of weird why it's added now. Would have hoped for some insight.

You would only do this if you expect major changes over time, right? Also 4 registers just for a version number -- that's future proof.

There are several versions of the VERA firmware floating around right now, with different bug fixes and experimental features. Having a version number/hash makes it easier to provide support and guarantee compatibility with the latest programs.

It actually is a critically important feature for providing support to end users; it's a surprise to me that this was not a feature until now.

[grml]

I hope there's not gonna be a multitude of hardware and firmware revisions for this thing in the wild, and lots of difference configurations, and programmers don't need to be aware and work around those differences, because that would really suck. User-facing version numbers in chips does not bode well.

[BruceRMcF]

I hope there's not gonna be a multitude of hardware and firmware revisions for this thing in the wild, and lots of difference configurations, and programmers don't need to be aware and work around those differences, because that would really suck. User-facing version numbers in chips does not bode well.

If they are going on what Dave was saying early on, there won't be, at least not from the original design team.

That is, I expect that the aim is to release a stable development platform, but if there is a serious bug, they will fix it.

However, the Vera code is not proprietary to this design, so if other projects adopt Vera, don't be surprised if they do some tweaks to it to make it better suit their project.

So it could well be that there ends up being, say, four or five versions for the Commander X16 over its life, as lurking bugs come to light and are snuffed out, but other versions of Vera being used in some other projects.

[TomXP411]

I hope there's not gonna be a multitude of hardware and firmware revisions for this thing in the wild, and lots of difference configurations, and programmers don't need to be aware and work around those differences, because that would really suck. User-facing version numbers in chips does not bode well.

The product is still in development.

As I said, having the version number available to developers is essential to tracking down bugs and problems. And since there's now a way to flash VERA in-system, you can upgrade pretty easily.

Once the system goes to full production, I don't expect VERA to get major updates. Even then, however, having version numbers will always be a thing. Because, once again, having version numbers is essential for software products.

[Wavicle]

I added the version number in VERA and the principle near-term reason is that many small things are changing, an increasing number of people are getting hardware, and we need a way to identify which version of VERA someone reporting an issue is running on. I recently spent about two weeks working closely with Adrian "Digital Basement" Black on getting VERAs composite and 15KHz modes as accurate as possible so that X16 looks good on a retro CRT. If someone reports a bug in composite video, I need to know if they are using a VERA bitstream that comes before or after that two-week long deep dive.

Also, per Adrian's request I added support for a "240P" composite mode, and MooingLemur added support for 240P into a new built in display boot configuration menu - there needs to be a way to figure out if you have a bitstream that supports it.

After the official release, I would imagine that only bug fixes would be released.

[Wavicle]

For reference, this is what a "240P" mode looks like. If you look closely, you can see that only every other scanline is drawn. This gives the characteristic 80's scan line look and eliminates interlace flickering. The second picture is a joke I inserted for Adrian's benefit where I set the display boot mode to match the VIC-20s and hacked the VIC-20 font into the ROM. The first image comes from a Sony PVM showing 15KHz RGB with composite sync (I think we refer to that as "Amiga Mode"), and the second from a venerable Commodore 1702 using separate chroma and luma signals (aka "S-Video"). (Sorry about the Moire pattern, this came from my phone's camera.)

IMG_20230317_231319321.jpg (2.29 MiB) Viewed 2548 times

IMG_20230319_204941846.jpg (3.8 MiB) Viewed 2548 times