Jump to content
Windless

Reading VBLANK on real hardware ?

Recommended Posts

Posted (edited)

Hi,

 

  TIA($01) is both the read address for CXM1P (only D6 and D7 used) and the write address for VBLANK.

  But what happens to other bits when we read CXM1P ? In Stella, even if we check "developer -> Drive unused TIA pins randomly on read/peek", it seems we always read %xx000001 whatever has been written to TIA($01) before. Is that true on a real hardware, or would we read random value ? The values from the bits of VBLANK  at least for bit 1 ? something else ?

 

Thanks,

Windless.

 

Edited by Windless

Share this post


Link to post
Share on other sites

Any bits that are not explicitly defined should always be masked out.
Otherwise you will find that some implementations will give %xx000001 but you may also find some other implications give other numbers.
Or even the same hardware under different conditions (temperature, timing, previous operations).

Never trust what isn't fully documented (and only partly trust what is documented :) ).

Share this post


Link to post
Share on other sites
8 hours ago, Windless said:

In Stella, even if we check "developer -> Drive unused TIA pins randomly on read/peek", it seems we always read %xx000001 whatever has been written to TIA($01) before.

That's not how the "Drive unused TIA pins..." should behave, and it's not how it works for me. Do you have an up to date Stella version (6.5.3 has just been released)? And did you reload the rom after changing the setting?

 

The TIA only drives bit 7 and 6. If the register don't use one of those two bits, it will read as 0 (e.g. CXBLPF only uses bit 7, bit 6 will always result as 0).

Bits 5 to 0 are undriven and their value must not relied upon. On most consoles those bits usually keep the last value they were driven with, and that's what Stella emulates if the "Drive unused TIA pins.." option is disabled.

e.g. with

	lda CXM1P

the last value that appeared on the data bus before reading the register is the address $01

 

If you access the same register with the instruction

	lda CXM0P,x

with x=1, the last value on the bus is $00, while using e.g.

	lda $FF,x

with x=2, the last value on the bus is $FF (so bits 5 to 0 will usually be all "1" in this case.

 

If you're coding for the 2600, keep the developers' settings enabled in Stella.

  • Like 1

Share this post


Link to post
Share on other sites

Ok, the way I was testing in stella was wrong (I re-ran the same code by manually mloving the PC to my manually assembled code). I made a test rom hoping someone could run it on real hardware, but the behaviour is different : In stella, bits 5 to 1 seems to be random, and bit 0 is always 1. (7 and 6 should be from CXM1P).

 

And yes, I know I should not be trusting this, otoh I should not be doing 6502 assembly and be looking for a serious paid job as a Rust developer, but you know... Maybe I should try understanding the schematic of the TIA to be (more) sure.

Share this post


Link to post
Share on other sites
3 minutes ago, Windless said:

In stella, bits 5 to 1 seems to be random, and bit 0 is always 1.

That was a bug that was fixed a while ago. Download an updated version of Stella.

  • Like 1

Share this post


Link to post
Share on other sites

>On most consoles those bits usually keep the last value they were driven with, and that's what Stella emulates if the "Drive unused TIA pins.." option is disabled.

 

How, thank you, this is exactly what I was looking for. Is it a completely unreliable behaviour, or will it be true most of the time on most 2600 ? (e.g. if I use this value in a game on every line, will I get a random glitch every 10 minutes or will it probably behave randomly several times on each frame ?

Share this post


Link to post
Share on other sites

Most consoles will work very consistently, so you'll basically never notice the bug. Many original games have this sort of bug (because of a missing "#" in front of a constant in the source code, which cause an access to a TIA register instead of an immediate load) and they'll glitch if you enable that developer option in Stella (that's why it's disabled by default in "player" mode).


But some consoles, or some combination of consoles and cartridges (e.g. when using some specific brand of eproms), will cause some pins to be consistently driven high or low.


You'll not find any real hardware behaving exactly like the "drive unused TIA pins" option does in Stella, with all the bits perfectly random on every read. The purpose of that option is to make bugs more evident so that you can correct them early during development, rather than simulating a real world behavior.

 

  • Like 3

Share this post


Link to post
Share on other sites

BTW, here is an example of an original cart misbehaving on a stock console (a 7800 in this case) because of this kind of bug.

Share this post


Link to post
Share on other sites

Thank you. I didn't manage to install stella from the provided packages on my debian 10 earlier, so I installed the older version from Snap store.

You convinced me to give it another try and I finally managed to compile it from sources, and I feel better and will update my code thanks to your posts :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...