In 15KHz RGB mode, VERA is rendering border pixels during VSYNC and possibly HSYNC. If the border color happens to be black, this isn't a problem, but other colors can create unusual visual effects such as the entire display becoming unusually dark.

With a high V_Scale value we get what appears to be line 480 copied down the screen. This feels unintuitive. It should either be line 479 (where line 0 is the first line), draw nothing, or should continue to render without the 480 constraint.

So either change this to 479, or remove the check?
https://github.com/fvdhoef/vera-module/blob/rev4/fpga/source/graphics/composer.v#L157

Test app for above:
code: test.zip
prg: example.zip

As seen here, the signal should be generated on both even frames and odd frames, giving ~60Hz rate:

Here is a measurement confirming the bug:

Because the PSG/Pal/Sprite registers overlap with the top 1.5 KB of VRAM, this space is effectively unusable for graphics data. I am suggesting having a bit in CTRL turn on and off access to PSG/Pal/Sprite. This way, applications can use all 128 KB of VRAM by turning off this area temporarily.

When the y_counter_r register was widened to 10 bits to prevent this from happening in VGA mode, the irqline check for composite mode was not also widened resulting in a 7-bit check of bits [8:1].

I connected a 65C816 to my X16 hardware today and the ROM was stuck waiting for VERA ready. Looking at the logic analyzer trace, I suspect that there may be an issue of propagation delay or related timing during a write. The read always comes back with $00. My suspicion is that the write data is sampled too early, but this probably needs to be tested in simulation.

In the logic analyzer capture below, the A1 marker is at the start of the write instruction lda #42 / sta $9F20 and the A2 marker is at the start of the read instruction lda $9F20.

Thanks for sharing! But, I think you should clarify the terms under which you like to distribute the source code.

PR for this coming shortly. A similar problem to the 4bpp tiles seen earlier also impacted the 1bpp tiles.

Tiles as currently rendered:

Intended result:

Dag Frank,

Ik woon in België, niet ver van jou.

Ik heb een vraag ... Is het mogelijk om de SPI op het VERA board (Rev4) te programmeren/lezen met een Arduino Uno?
De Arduino werkt op +5V, terwijl de SPI op +3.3V werkt. Er bestaan Arduino Uno libraries om de SPI chip te kunnen aansturen gebruik makende van SS, SCK, MISO en MOSI interface.
Heeft de VERA header interface een implementatie dat toelaat de J2 +5V om te zetten in een interface naar de SPI op +3.3v, gebruik makende van shifters (mijn assumptie: ja), maar ik wil het graag van U horen ... (Ik zie die shifters op je design).

Op het VERA (Rev4) bord is een J2 header. Ik heb de originele schemas gevonden van VERA Rev0, waar er sprake is van een J3 header ... zie hieronder:

Is de configuratie van de J3 header van de VERA Rev 0 gelijk aan de J2 header van de VERA Rev4? En is deze ongewijzigd?

Is de volgende PIN configuratie juist?

• J2 header PIN 1 = +5V(?) => verbonden met PIN +5V van de Arduino Uno?
• J2 header PIN 2 = FPGA_CDONE, en is niet gebruikt om de SPI te programmeren (JUIST?)
• J2 header PIN 3 = FPAGE_CRESET, en is niet gebruikt om de SPI te programmeren (JUIST?)
• J2 header PIN 4 = SPI_MISO => verbinden met PIN 12 van de Arduino Uno?
• J2 header PIN 5 = SPI_MOSI => verbinden met PIN 11 van de Arduino Uno?
• J2 header PIN 6 = SPI_SCK => verbinden met PIN 13 van de Arduino Uno?
• J2 header PIN 7 = SPI_SSEL_N => met welke PIN te verbinden van de Arduino Uno?
• J2 header PIN 8 = GND => verbinden met PIN GND op de Arduino Uno?

Heb ik nog iets anders nodig om met de SPI van de VERA te kunnen communiceren?

Het zou geweldig zijn mocht ik een JEDEC handshake kunnen bewerkstelligen!

Ik weet niet of U hiermee kan helpen?

En ook, indien de bovenstaande configuratie correct is, waar/hoe moet dan J2 PIN 7 aangesloten met welke PIN op de Arduino Uno?

Hartelijk dank bij voorbaat!
Mocht U tijd hebben, wil ik best met mijn CX16 bord naar U rijden om te kijken hoe een Arduino kan aangesloten worden.
Het zou niet te lang moeten duren denk ik.

Sven Van de Velde

Both 16x8 and 16x16 tiles appear stretched and some tiles do not show at all due to invalid address calculation in layer renderer.

E.g. with these five test tile targets:

Rendering tile 2 on top of tile 3 comes out as this:

It is not possible to render tile 3 as its address is always calculated to be in the middle of tile 2.

This request came from some of the users on the Discord server. I had always responded that VERA was out of register space. Recently someone suggested that there is almost never a software use case for reading the line IRQ value, but many software use cases for polling/waiting for a specific scan line; it would be better to have the line IRQ return the current scanline when read.

I have made this change and one of the community members wrote a test case to demo/exercise it. The results looked great. If there is no objection to adding this feature, I will prep a PR in the next day or two with the two-line change that enables it.

The HSYNC and VSYNC polarity for 640x480 60Hz is negative on HSYNC and VSYNC according to the VGA spec. VERA's sync polarity is positive for both. Most modern LCD monitors do not appear to care if this is correct, but there are mixed results on older monitors, particularly CRT monitors.

There is currently a fifo_empty wire in the PCM fifo module. Making this available (read-only) as bit6 of AUDIO_CTRL ($9F3B in CommanderX16 memory map) would be very useful for applications that wish to know when an audio clip is completely finished playing for various synchronization purposes, as well as being a way to check for buffer underflow in applications trying to minimize the FIFO latency so that they may increase the fill rate.

In this code in top.v:

        if (spi_autotx_r && access_addr == 5'h1E && do_read) begin
            spi_txdata = 8'hFF;
            spi_txstart = 1;
        end

It looks like the SPI auto tx will only start if access_addr is 5'h1E while the do_read strobe is active. The access_addr signal is updated with the contents of rdaddr_r which in turn is updated on the falling edge of bus_read. Since do_read is only active for 40ns and bus_read is active for 62ns, it appears that there may be a 22ns window of opportunity for the start condition to be missed.

Thank you for your amazing chip!
It's really a powerful chip, my jaw dropped only tinkering the PSG+PCM sections, far from grasping any sense of the whole chip and what it can do.

But during the mocking about, there has been questions back of head that I always hesitate to ask.

Why the PWM respond linearly to values.
Why there's no a different seed/algorithm for noise generation.
Why signed value for PCM.
Why 48.88Khz?

I just assuming there's already an answer floating on the internet and move on, by chance this topic got brought up in a discord bantering https://discord.com/channels/547559626024157184/629903991794434048/1161984652538544138

And evidently, there is no answer as to why the PSG section is it and what it is based on.

There have been discussions about the possibility of FULL AY-8910 compatibly or MOS 6581 compatibly is main driving force.
But I check all datasheets about the AY-8910 MOS 6581 and even Atari POKEY
TI SN76489 and Phillps SAA1099, I can not determine any of them related to VERA PSG.
Internet deep dive resulting nothing.

Could you share some lights on how you went about designing the PSG section, what're the decisions you have to do?

However, also in the discussion, we discovered there are some possible improvements that might be very helpful to further improve the PSG section while costs little to noting.

VERA PSG Fork mode
a. use the highest PWM bit to flip the pulse wave to cover higher than 50 duty cycle.
b. add a different seed/algorithm for noise generation.
c. making duty-cycle logarithmically responses to the PWM value.( optional )
d. a possibly new register or a magic number to write to switch this new mode ON or OFF to remaining compatibly.
e. cap off the pulse width from 6.25 to 50%(or possibly 93.75%) (to free one PWM bit)

If lose one bit on the PWM value and use the bit to flip the phase of the wave to cover 50-99 duty-cycle the resulted precision of PWM is acceptable.
The 75% PWM value is pretty widely used on Ricon 2A03 compositions to make sure the two waves will not "ADD UP" among other fun things!

The ??PWM(value 00) to 6.25PWM(value 04) is most likely not to be very useful in most compositions.....
I know some will jump to use these values right after reading this, but still very little.
As such, it might be sensible to cap it off in the F mode leaving rage to the values that are useful.

The default seed for LFSR noise gen is some what meh, and it can not recreate some of the 2A03 SFX.

The logarithmically response is a way employed by Furnace tracker to making the audio changes with little value change.
This mainly fights the physical and phycological characteristics of our human ears and how we preserves the PWM.
For example, a ??PWM(value 00) to 12.5PWM(value 08) sounds almost the same and almost too unpleasant to use, and 33PWM to 48.5PWM a nontrained person could not tell much difference.
However, the 12.5PWM to 33PWM is a much more drastically change at a higher rate also than mentioned range.
As such, making the making duty-cycle logarithmically responses to the PWM value can make the PWM quickly glide though the ??PWM to 12.5PWM rage, slowdown the changing rate of 33PWM to 50PWM.
This is so rare of a thing that most of the VST expects you to mod it however you like by custom pattern and leave it linear response.
Like I said, very optional.

Personally tho, I think these PSG functions has already been considered and then discarded during the designing.
Could you tell me if I'm right about this?

But just in case it's not, would you consider adding these fetures?
I know how hard it is to design FPGA and how the system is done and how there's little room left on the FLASH or LUTs.
But hey, the VERA FX also is out under the same terms.

Thank you for your time and considerations.
Willhem.

This request originates from Adrian Black. This causes old "Arcade" monitors (and the venerable Commodore 1084) to skip painting odd scanlines producing a visible raster line effect very reminiscent of early displays.

The attached sample was rendered on a VERA that I had modified to render 240p.

Sprites at the same Z depth are rendered from lowest VRAM location to highest location which places sprites at the lowest location behind all others at the same Z depth. This is opposite to what is stated in the VERA documentation:

Rendering Priority The sprite memory location dictates the order in which it is rendered. The sprite whose attributes are at the lowest location will be rendered in front of all other sprites; the sprite at the highest location will be rendered behind all other sprites, and so forth.

The Commander X16 emulator implements rendering priority as described in the documentation which does not match hardware. Comparing the appearance of the end screen of the FlappyX16 game between hardware and emulator resulted in several sprites being invisible when played on hardware because those sprites were rendered behind a larger sprite at a higher VRAM location. Those same sprites were visible on the emulator. Changing the sprite order such that background sprites were placed into lower locations fixed the rendering on hardware.

Some possible fixes for this:

1. Update the documentation and X16 emulator to reflect the functionality of the hardware. This may require existing software to be rewritten.
2. Update VERA to render sprites at higher locations first. This will make VERA match the documentation and emulator, but may cause undesirable effects when higher priority / low VRAM location sprites do not get rendered due to running out of available rendering cycles / "work units".
3. Update VERA such that it does not render sprite pixels to non-transparent pixels in the line buffer. This is probably the best solution and might work by inverting the is_pixel_transparent check in this line:

    // Determine if current pixel should be rendered
    wire render_pixel =  !pixel_is_transparent && sprite_z_r >= linebuf_rddata[9:8] && tmp_pixel_color != 0;

This was seen in a test setup driving communication from a Raspberry Pi connected via I2C to a 16 bit GPIO expander and then to a VERA implemented using an UPduino 3.1 on a solderless breadboard. The official X16 emulator was modified such that all register IO within the emulator system and the emulated VERA was duplicated out to the VERA on the breadboard. The results of all register reads from the emulator are compared and mismatches are reported. The only mismatches observed so far happens during a cursor blink (at a "READY." prompt) at which time the second read always, or almost always, comes back with the same data from the first read as though the address had not been incremented.

Attached is a logic analyzer trace from the UPduino-based VERA. D7 of the analyzer appears to have an internal connection and is always reading ground but probing it separately does show the D7 signal behaving as expected. The analyzer probes are connected between the GPIO expander and the UPduino module. The Pi and GPIO expander are both operating with 3.3v IO. The only change to the VERA source code was the addition of a PLL to derive a 25MHz clock from the 12MHz clock on the module. A log of video activity from the emulator and VERA HW activity was collected on some runs, the relevant portion of a failure similar to the one in the LA trace looks like this:

VERA  READ $(00) == $0C
VERA  READ $(01) == $B8
VERA  READ $(02) == $11
VERA WRITE $(00) <= $00
VIDEO WRITE $(00) <= $00
VERA WRITE $(01) <= $B9
VIDEO WRITE $(01) <= $B9
VERA WRITE $(02) <= $11
VIDEO WRITE $(02) <= $11
VERA  READ $(03) == $20
READ  video_space[$1B900] = $20
VERA  READ $(03) == $20
READ  video_space[$1B901] = $61
!! MISMATCH !! ($03): 20 != 61

The emulator VERA correctly returned $61 while the hardware VERA returned $20. Immediately preceding the mis-matched read is a successfully matched read of $20 and a write to ADDR_L/_M/_H of $1B900 and setting the increment to 1.

In the attached trace, Cursor A (solid vertical line) on the left is marking the approximate location of the write to ADDR_H with the value $11. Cursor B (dotted vertical line) is marking the approximate location of the first read of DATA0 and getting the value $20. The next CS# assertion to the right of Cursor B is the second read of DATA0 which gets the erroneous value of $20.

A python script to perform a similar sequence was also written but always sees the correct, address-incremented value. A trace when that script is running has not yet been collected, but when it is the result will be posted as a reply to this issue.

Given this isn't being used, we should remove it.

Its also on the wrong bit compared to the rom!

@fvdhoef Heb je ooit de toevoeging van een "alpha channel" in de 2 byte rgb mixer beschouwd? Je hebt 4 bits vrij per rgb palette register.
Het zou mooi zijn om ook transparantie labels te hebben in de vera.

Ik ben Sven Van de Velde op de CX16 portal. Ik woon in Antwerpen. Jij blijkbaar in Revele tegen Turnhout?

As an example, have 3 lines -- Red, Green and Blue, drawn in 8x8 tiles.

Using a line interrupt turn the layer off in the red section.

Turn the layer back on on the line before the blue section, so the last line of the green part. (The line before, as rendering is done to the line buffer on the previous line.)

We should either see green, or nothing. However we currently see a red line.

This was introduced with this PR: #35

Current hardware:

Link: https://discordapp.com/channels/547559626024157184/547560914744901644/1077336180997230752

How it used to work (and arguably should)

Example prg: https://discordapp.com/channels/547559626024157184/547560914744901644/1077329433263882270
Example code: https://discordapp.com/channels/547559626024157184/547560914744901644/1077329961905570012

It appears that around the rollover point from line 511 to line 512, there is an opportunity for the IRQ signal to glitch and generate an interrupt in the middle of the back porch, ahead of line 0.

As seen in the above sequence of images, the unexpected line IRQ happens at roughly line 480 + 10 + 2 + 20 = 512. This erroneous IRQ appears to happen during every frame while a line IRQ is set for line 0.

It isn't obvious to me why this is happening. y_counter and line_irq are both registers in composer.v; they should be safe. Needs further investigation.

I'm trying to understand how sprite collision works, and the negation of the mask on this line looks wrong.

I cant think of a reason why it would be there, but I don't really know the intent of how the collision is to be used either.