Jump to content
IGNORED

Reading VBLANK on real hardware ?


Windless

Recommended Posts

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
Link to comment
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 :) ).

Link to comment
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
Link to comment
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.

Link to comment
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 ?

Link to comment
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
Link to comment
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 :)

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...