Windless Posted April 21, 2021 Share Posted April 21, 2021 (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 April 21, 2021 by Windless Quote Link to comment Share on other sites More sharing options...
stepho Posted April 22, 2021 Share Posted April 22, 2021 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 ). Quote Link to comment Share on other sites More sharing options...
alex_79 Posted April 22, 2021 Share Posted April 22, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Windless Posted April 22, 2021 Author Share Posted April 22, 2021 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. Quote Link to comment Share on other sites More sharing options...
alex_79 Posted April 22, 2021 Share Posted April 22, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Windless Posted April 22, 2021 Author Share Posted April 22, 2021 >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 ? Quote Link to comment Share on other sites More sharing options...
alex_79 Posted April 22, 2021 Share Posted April 22, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted April 22, 2021 Share Posted April 22, 2021 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. Quote Link to comment Share on other sites More sharing options...
Windless Posted April 22, 2021 Author Share Posted April 22, 2021 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.