JetSetIlly

Indeed. But Festival is very flexible and I've not done anything beyond the bare basics yet. I'll work on that this week. However, even if it doesn't sound exactly like the AtariVox, it would serve as a convenient development tool for people without access to the hardware, which is my goal really.

Is it? I'd be surprised if it's not compilable for other OSs but I'll admit I've not researched that yet. Either way, it's just an idea at the moment. I'll code it such it that the speech engines are changeable. A good alternative to Festival might be Flite, but Festival was the first engine that came to mind. A SpeakJet emulator would be perfect of course, but I don't think it exists. In the absence of any speech engine though, subtitles might be a good fallback solution. Hah.

First attempt at adding AtariVox support to Gopher2600. This solution relies on a Festival running in a separate process. In the emulator, the AtariVox/SpeakJet bitstream is decoded, translated into Festival instructions and piped to the Festival process. I very quickly converted the SpeakJet codes to phonemes that Festival can work with so the voice in the video is a little rough. I can definitely do a better job of this and I also need to support the codes that control volume, pitch, speed etc. But as a proof of concept I think this is promising.

? That's good to know!

What should be possible is to link the emulator with VSCode by setting up Gopher2600 as a LSP server. That will save time by selecting the correct file/line in the editor via the illegal accesses window. @mksmith have you done any work with LSP for ADS?

Combat (!) has 263 lines, so there is that. The Activision Ventian Blinds demo meanwhile, has 267. The "curtains" loading screen for Supercharger cassettes doesn't sync at all! So yes, even back in the day, 262 wasn't a fixed rule. But if people report that those ROMs have issues on modern TVs then I suppose we should be more careful with modern ROMs. The most important thing IMO is consistency. If you're going to output 263 lines then it should be 263 every frame

50Hz for PAL, which is 312 scanlines. PAL60 is 60Hz, or 262 scanlines.

Wow

Agreed. That would be a fundamental error in the hardware. It would stick out like a sore thumb.

Isn't this just the same issue that affects Quickstep? In which case, it's not often noticeable from my understanding. From my notes, this issue can also be caused by certain RGB mods.

This was the logic I figured out when developed Gopher2600. It was one of the first things I did when exploring the 2600, but it turns out I didn't really need it - from an emulation point of view it doesn't provide anything that you can't get from a normal count. https://github.com/JetSetIlly/Gopher2600/blob/master/hardware/tia/polycounter/table.go It will produce the table as shown in Tower's document. Couple of years since I wrote this so I can't recall exactly how I derived it.

Looking again at the byte sequences currently defined in Stella, there is another solution that would be less disruptive for your code. Instead of BIT INPT1 BPL .... Try LDA INPT1|$30 BPL ... Similarly for INPT4 and INPT0. The disadvantage of this is that you're clobbering the A register. on edit: what we're doing here is using one of the INPT1 "mirrors". So instead of memory address $09 we're reading address $39. For the Atari VCS itself this makes absolutely no difference, but it does produce a different sequence of bytes in the machine code. An emulator can take advantage of these variations in byte sequences for convenient features like controller auto-detection. It should. The only reason why it wouldn't is if the binary has been rebuilt and the resulting MD5 hash of the binary is different. That might have happened during development and caused the confusion.

Your code isn't triggering the controller detector in Stella correctly. Stella looks for certain patterns in the binary and when it finds them will conclude that this is a ROM that uses a keypad or paddle or whatever. Looking at the latest ROM you read the keypad at the marked locations in the image. Addresses $fe6e and $fe74 It'll require you to juggle your code around a bit but instead of BPL try BMI. That will produce the byte sequence $24 $09 $30 and $24 $08 $30, which should work with Stella.

I look forward to your feedback.

Lots of changes have accumulated in the last couple of months. Full change log and binaries here: https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.16.0 The main new feature is performance profiling of ARM binaries. This requires an ARM using ROM to be compiled in a certain way but it's been useful to me so far. I've included a video to give everyone an idea of how it works. arm_developer.mp4 The ROM in the video is @SpiceWare's Collect3 demo project compiled for the PlusCart. The first thing I do in the video is open the Performance window. This window shows the most computationally expensive lines of C code during the previous frame. Clicking on an entry opens the Source window at the correct line, providing context. I run the program some more and we can see how the performance profile changes when the program reaches the menu screen. The Timeline window can be used to move back to an earlier frame and the performance window will be updated accordingly. The Illegal Accesses window will be useful when porting ROMs intended for the Harmony to another cartridge type, for example the PlusCart. In the video the Illegal Accesses window shows are four entries. Like the Performance window, clicking on an entry opens the Source window at the correct place. In this instance, the illegal accesses is related to the address related to the timer in the ARM processor - the header files used for compilation have not been updated for the PlusCart. Do note that there are limitations to the information I can currently provide and indeed, some information might be misleading - I don't currently handle inlined functions very well for example. But this is an area I will be looking to improve for the next release. In addition, Gopher2600 now supports Genesis controllers and the EF bankswitching format. Bots and Comparison I've mentioned in other posts. Both are still a work in progress. By default, the CRT television emulation will now visibly sync on startup (depending on the ROM). If you don't like this you can turn it off by unchecking the "Synchronise on Power" option. Finally, there is now a 6507 Pinout window. This shows the state of the 6507's pins on any given video cycle. It also shows the values on the address and data bus at any given time. This might be useful to help tracking down and understanding bugs related to the reading of undriven pins and phantom writes. 6507 Pinout.mp4

Fantastic information.

Yes. If we say that the switching only ever occurs on access of $003f then that works. But I'm not sure it is limited to that single address. According to this old document by Kevin Horton (v6.0 of Cartridge Information) then scheme 3F will switch on an access of an address between 00 and 3f. http://kevtris.org/files/sizes.txt Maybe the document is wrong and it strictly works with address 3f It will. There's always a ghost read with indexed addressing. The base address is put on the bus while the index addition is taking place.

Semi-related question: why don't Tigervision cartridges (method 3F) bank switch on phantom reads? Take Miner2049er for example. In bank 2 at address $3611, the instruction STA VSYNC,X will cause a phantom read of address 0. Absent some other condition, this phantom read will cause a switch to bank 0. What's the condition in the cartridge that prevents this from happening? If we say that 3F only bank switches on access of address $003F then it solves the problem. However, it is my understanding that any primary TIA address will work, thereby causing the issue of phantom access.

And GPL projects can be dual licenced if all copyright holders agree.

GPLv2 compatible. So a ROM released under the Modified BSD licence for example, would be fine because that is compatible with the GPLv2.

You could do this very easily by compiling the emulator with the ROM binary embedded in the emulator source. The emulator would then use the embedded data instead of asking for a file to load. To be clear, I don't think the Stella source is set up to do this just yet but in principle it's very easy. Gopher2600 is already set up to do this but I've not pursued it because the emulator hasn't even reached v1.0 yet. The alternative method, which I think you're asking for, is for the Stella to output a Windows binary without having to recompile the source. It would be possible, with some work, for Stella (or Gopher2600 or any other binary emulator) to be set up like that but frankly, producing a Windows binary in this way would be full of pitfalls that I wouldn't want to tackle. Regardless, for easily distributing to friends and family, the Web is probably the easiest. So as @Gemintronic says, Javatari would be even better.

I'd not seen this format before so I had a look in the Stella source. I can see that a Superchip version of this format has also been coded. Are there any game/demo examples that use the additional RAM? Also, I see from the comments that it was added for Paul Slocum's Homestar Runner but the version of Homestar Runner that I'm aware of uses the 32k Atari style format. Is there another version of Homestar Runner? Tagging @Thomas Jentzsch and @stephena because they're credited in the source files.

Indeed. An important detail I missed out. Out of curiosity, do we know the specifics of which consoles are affected and specifically why?

From the Stella Programmer's Guide. Only the bits where there is a 1 in the column will be set by the reading of that register. The other bits will be set to whatever the most recent value on the bus was. This will vary depending on which TIA register mirror you are reading. For example, reading CXM1P LDA $01 Assuming there is no collision, the A register will contain 00000001 If we use a mirror of the CXM1P however, LDA $11 The A register will contain 00010001 This is because in the first cases the most recent value on the bus was $01 and in the second case the most recent value was $11. The most significant bits are set to the value in the TIA register, but the other bits are untouched.

Heh. Indeed. That's work for tomorrow ?