jmchacon

Oh. I see those in the stella list but don't see a cross reference to anything. Got a pointer?

Couldn't find an obvious old post so thought I'd ask. I'm working on my emulator again after a bit and things are running pretty well as I implement various cart mappers, etc. This is mostly an exercise for me in exploring bus cycle completeness issues as I implement. I was wondering why the community never seemed to chose to adopt a header format for the ROM images (i.e. how the ines format is used for NES emulation)? Reading z26 src it appears to match mappers by keeping a list of game checksums and basing it on that. Stella uses a variety of heuristics in auto-detect mode to determine things and in a lot of cases falls back to "it's 16k and nothing matches so we'll just assume F6". I know it also supports using extensions on the filename to force mappings as well (along with checksums to match ROMs for initial state, etc). I agree both systems work but they seem slightly brittle in some ways. i.e. all the ROMs available for download are raw .bin files so emulators loading them have to play auto-detect games (which can have gaps) or the ROM owner has to know already which mapper to rename the file to force a mapping, etc. What about a defined header and general extension name which allows one to declare up front "this is an F6+SC ROM" ? I'm not trying to argue here but mostly just curious about the history here more than anything as I look at other 8 bit systems and how they handled this sort of thing.

Heh...Yep..I completely misread part of the PIA docs and only had the timer registering 0 for a single clock no matter the multiplier. That doesn't work when a read of it takes 3 cycles and code is doing a BNE to test against it. Fix that and I also see very stable frame counts/sizes in my own code. Good way to learn

Hmm...Ok, I might have something wrong with my timing then in my emulator. I'm not 100% convinced my PIA implementation is perfect. Could be on some frames it's not dealing with the timer quite right.

I noticed combat seems to generate an odd looking frame compared to specs as laid out in the Stella guide. This is running in attract mode when I first turn it on and cycling through game select for a minute. I see (for game 1) a frame of VSYNC - 3 VBLANK - 45 Picture - 221 VBLANK - 3 Every 16th frame or so it changes to: VSYNC - 3 VBLANK - 38 Picture - 221 VBLANK - 3 So the visible picture remains constant but # HBLANK lines jumps around. I see this as well on other game selections but on some it's even worse (like every 4th frame). Dropping in space invaders shows something similar. Reading through the Stella code it appears to handle this by working in some slop on VBLANK turning off to within some limits (with the additional jitter emulation should one want a rolling screen). Did the TV just have enough slop in it's vertical hold that it didn't jump when the occasional frame did this as long as total visible picture remained constant? Also there's barely any overscan here (3 lines worth) which seems at odds with the suggested 30 the Stella guide suggests? I know the TV can display 262/263 (ok, generally 242/243 with the minimum 20 lines of VBLANK).

Technically the I/O "pins" are on the chip. The I/O port mechanism is clearly in the chip or else you've just got some dead pins that won't work

I did some more thinking about RSYNC and observed behavior after I wrote a test. Since it completely shifts the clocks (WRT the sprite clocks) this appears to allow sprite movement without an HMOVE/comb but you are restricted based on timing and the 3x difference in pixel vs CPU clocks. Example: I'm drawing a ball in the middle of the screen and then issue an RSYNC. Depending where I hit it I jump about 76 pixel clocks right all of sudden due to the synch change between the 2 clocks. Think of it how the HMOVE comb adds 8 pixels to every sprite and then those have to be recovered during HMOVE due to how the comparators work internally (i.e. a move 0 is really 8 extra clocks of the given sprite to move it left 8 to get a 0 net movement). I'm thinking in addition to allowing a fadeout effect (on a real CRT...not sure how an LCD will handle it emulating the signal) this could be used to do large movements of sprites between lines and some careful timing. It's really coarse but it does allow > 15 pixels which is the best one can do with an HMOVE triggered on pixel 224 (or so).

Sorry if I was coming across too opinionated there. Diving in randomly I ended up in Ball.cxx for instance and there's very few comments and a lot of magic constants. Same with a few other files I looked at while trying to pick some specifics. It's not impenetrable but without a lot of context it's not the simplest to follow initially either. Not saying the code isn't good (it's very well done C++) but as someone diving in to a specific portion there is a dearth of comments in the tia code I was reading. Code back in the main emucore may be better but I was concentrating in the tia directory at the time. I'll make an update on my other public posts to get more specific as well. Again, sorry if that came off a bit harsh.

I've read the Tower notes extensively since they are effectively a jump start on staring at schematics. The NMOS logic of the era is "interesting" to interpret He's got some oddities in clock references in places so one has to be careful to use CPU vs pixel vs the x4 counter when interpreting sometimes. Definitely will take a look at the typescript version. The C++ parts were a bit obtuse in places I'll admit. I'm also trying to avoid referencing other emulations if possible to greenfield this but sometimes there's only so much I can infer on my own it seems. I've really learned which write-ups are bad. I think the one you mentioned I mostly use a cross reference for some specs. I agree it's not great and obviously wrong in places. Thankfully the schematics tend to win out when I'm confused. 225 makes sense since RSYNC has to go through an H1/H2 cycle before it works since it just feeds into the same circuit as normal end of line does (i.e. when the H counter reaches it's end). I ended up processing the H1/H2 cycles and then forcing my counter to end of line. Since I'm pretty sure my current implementation is close to the hardware I wrote a quick test to check persistence and got a surprise. I forgot this only resets the Hclock and nothing else. That means it immediately skews the sprite clocks by whatever amount of visible area was in play. I was painting the ball down the middle of the screen and RSYNC in the middle of that which threw it all over the place on the next line since it picks up painting at the left edge. I need to debug a bit more but for once I feel like these are expected side effects

On 2nd thought HSYNC always vertically advances the beam.....So hitting RSYNC mid line should persist the previous pixels not yet painted this time (due to CRT effects) and then start the next line. So assuming one did this only every few frames shouldn't see flicker/fade. If it was done every frame for a specific set of lines then on a CRT those would slowly fade back out I think. Anyone know of a game that did this?

I've been working on a 2600 emulator (yes, I know about Stella but this was so I could do easier integration with other potential projects). I have HMOVE and all it's oddities working as best as I can tell but I'm a bit unsure on RSYNC. Looking at the schematics it appears to just force the main counter into the reset state (after 3-6 clocks depending where H1/H2 timing is at). So happening mid-scan line would potentially give another full set of pixel clocks to work with? i.e. triggering right at the end of HBLANK in theory would restart and give another 21-22 cpu clocks or so before painting occurs? The schematic looks like it's a normal reset of everything so it asserts resetting the HSYNC and disabling the beam, etc. I read through some commented space invaders code and it's used twice there. Once right after WSYNC and another it looks like as I described above (trigger WSYNC, compute a few things and then RSYNC to recover clocks). This isn't super well documented that I've found so until my Harmony cart arrives and I can write some test code I'm mostly stuck at interpreting 40 year old schematics James