JetSetIlly

I like that idea. It makes the most sense to me. My understanding of the gamepad is that for the left player, the regular fire button uses the high bit of INPT4 and while the second button uses the high bit of INPT1. For the right player it's INPT5 and INPT3. INPT0 is definitely low in Gopher2600 when either Gamepad is attached (The Ports window shows and allows you to interact with the RIOT I/O Ports). That makes me believe that the problem is something else in this case. It would be interesting to track down the problem. I'm aware of QuadTari but I'm not entirely sure how it works. It allows more than one controller to be attached to each player port, but that's all I know. Is there developer documentation for the QuadTari I can reference?

There are no parameters to set the controllers on startup but there is another solution. Hopefully, this will work on Windows when launching from the command prompt or via Textpad. (I don't have Window available here and am cross-compiling from Linux. @Al_Nafuur has been helping me test on Windows, but I don't think we've tested this) To launch in debug mode: gopher2600 debug <romfile> To force the TV mode then you can add the -tv option gopher2600 debug -tv PAL <romfile> To force the bank switching mapper: gopher2600 debug -mapping <format> <romfile> In the case of setting controllers, what you can do is to run an initialisation script on startup. gopher2600 debug -initscript <scriptfile> <romfile> In the scriptfile, you could add something like peripheral left gamepad Each line of the scriptfile is a terminal command. For reference, the terminal can be opened up in the GUI via the "Debugger" menu at the top. In the terminal you can type "HELP" to see every command. and "HELP <command>" to see help on a specific command. The disadvantage of the initscript mechanism at the moment is that, in the case of the peripheral command, the peripheral will be reset automatically when the ROM is reloaded or another ROM is selected. I can fix that for a future version. Note: In the Linux and Mac versions, it is possible to run the emulator from the command line with the "--help" option and to see what modes and switches are available. Unfortunately, I don't know how to allow that on Windows without having a DOS window open automatically when launching the emulator from an icon. From my understanding, it should launch fine from the command prompt but you won't see any output to the command prompt window.

At the moment, it's really only for reference for the profiling/performance of the program. Taking the ARM7TDMI menu in order. 1) Disassembly - This is a running disassembly that shows every ARM instruction executed in the previous CALLFN. It shows, details of the cycles (what type of cycle), whether the cycles were merged, the MAM mode, etc. It's slow so it is disabled by default. 2) Illegal Accesses - Shows the line of code that was responsible for accessing memory that is out of range. There is an option in the preferences "Abort on Illegal Memory Accesses" which should be off (and should probably be removed altogether) when using this feature. 3) The performance window - Shows the most expensive functions (or CPU load) over the course of the last frame. You can also sort by Average load and Max load. Clicking on a function will open a Tab showing all executing lines in that function only. 4) The source window - Allows you to browse the code. Lines that have generated ASM code to be generated have a microchip symbol in the left margin. Tooltips in these windows show detail appropriate for the context. So in the source window for example, the tooltip shows the ASM underneath cursor. I like your thinking. Breakpoints and stepping of C code will be coming in a future version. The debugging loop of the emulator already handles very fine grained stepping by colour clock; an even finer stepping by the ARM clock should also be possible.

Reading your post again, I should add that the final binary file will need to be in the game folder (ie. not in the output folder). on edit: alternatively, copy the ELF file to the same folder as the final binary, but name it armcode.elf

Cheers. I have a couple of other ideas to improve the CRT emulation but I'm glad you like it. I like it too ? MAM will be set to 1 on entry to the custom ARM program, unless the format is CDFJ+, in which case it is set to 2. If you'll be releasing plain CDFJ ROMs that need to be in MAM 2 on entry, then I'll need to think about how to address that. Right. I think it might be because the ELF file is called testarm.elf. Try naming it armcode.elf and see if that works. The path of the C source itself is present in the ELF file so shouldn't be an issue. There isn't. I should probably add that option. I've chosen not to yet because I wanted to force these issues to the surface and to see if it can be handled more elegantly. It shouldn't be. I do something similar here and it works fine. It's a pleasure. I'm happy to hear about any features you may require that build on this.

v0.17.0 binaries on the github release page https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.17.0 The main improvement this version is the use of DWARF data for ARM profiling. The previous version required the generation of an .obj and .map file from the ELF binary. v0.17.0 now only requires the ELF binary to be produced with debugging data, something which the example ARM projects prepared by @SpiceWare are set up to do. (The ELF binary is the binary which is combined with the 6507 program to create the final 2600 ROM. The ELF binary is stripped of DWARF data before being combined) Gopher2600 should automatically find the ELF binary upon loading of the 2600 ROM, unless your build method is especially exotic. If it does not then let me know and I can make the necessary improvements. The video above is a short demonstration of @Spiceware's Collect3 demo project. What we're seeing here is 1) New profiling window shows most expensive functions in order 2) A function can be focused by clicking on it 3) Function tab shows most expensive source line in order. 4) Source window shows source line in context 5) ARM assembly shown in tooltip 6) Works with rewind system Most of the improvements in this release of the emulator have been made at the request of @Andrew Davie who is using these features during the development of his current project. Also added is AtariVox support. This requires the installation of a third party program called Festival. Currently, not all AtariVox commands are supported but as it stands, it should work well for initial development work. It is also (in my opinion at least) good for playing existing games that feature voice output. Other changes are listed on the github release page

With enough linked machines and the screens at a suitable viewing distance, you could make an effective "high-resolution" display.

Another use for this is to have a second or maybe even a third 2600 simply displaying secondary game information (a map or an inventory screen in an RPG, for instance). Or similarly, to provide peripheral vision, like in the TX-1 arcade game. Worth experimenting with I think.

In addition, how are you receiving keyboard input? Is it from an Atari2600 peripheral, like the keypad, or is it directly to the ESP32? edit: Reading back I can see you have a regular keyboard attached to the ESP32? I like it but it would be interesting to see if you can transmit keypad input from the 2600 to the ESP32.

It looks like the display is about 27 characters wide. Is that correct? This is really interesting to me. I've experimented with compiling advland for ARM cartridges, with the aim of eventually moving to the ZMachine. You've taken a very different approach but it's a viable solution to an existing "problem". I look forward to seeing how it develops. When can we see a running video of it in action?

Smart work. So in the text adventure example, the ZMachine is running on the ESP32? What is actually being sent from the ESP32? Is it text information (ie. ASCII or similar) or is it graphical information? Can you transmit a page of text from the ESP32 in one frame?

Trailing space after "/usr/bin/festival" maybe? I've just tested that here with a trailing space and I get the same error as you. Removing it fixed the problem. (I'll fix this problem in the preference file parser tomorrow).

I've not completed the configuration step yet. So you need to edit the gopher2600 preferences file: Look for the peripherals.atarivox.festival.binary entry, or if it doesn't exist just add it. peripherals.atarivox.festival.binary :: /usr/bin/festival Making sure the path to the binary is correct of course.

I've implemented the SpeakJet pitch command. Maps very easily to Festival equivalent. I've also added the Speed SpeakJet command but I'm not sure how it's measured. The SpeakJet documentation simply says that it's a value between 0 and 127 (with a default of 114). But what do those values means? Is it duration in milliseconds for each phoneme, or something else..

It'll be a lot of work to do it correctly and satisfactorily I think. The SpeakJet codes came from page 16 of the Speakjet usermanual https://people.ece.cornell.edu/land/courses/ece4760/Speech/speakjetusermanual.pdf I converted those to the phonemes used by Festival's US phoneset http://festvox.org/festvox-1.2/festvox_18.html For example: I decided that code 164 is the 'ow' phoneme in that phoneset. This was a very quick sub-project done more or less in an afternoon so I've no doubt made mistakes and bad choices during the conversion. It can definitely be better. Ideally there would be a SpeakJet phoneset for Festival but I don't think it exists. I'm not familiar with that library. Does the ESP32 work in a similar fashion to the SpeakJet? (ie. you stream bits at a given baud to indicate what phoneme to play next)

Not necessarily. The diff image just shows those pixels that are different between the two emulations. A pixel is considered different if it is a different color. In the case of Millipede I think what you're seeing is the millipede being slightly ahead in one emulation than the other. Meaning that you see the outline of the millipede in the diff window. At the moment, I'm not sure the tool can tell you much other than that they are different. It's difficult to see how they are different.

Good video on the topic

Because your working directory probably isn't in your PATH you need to specify it: ./gopher2600 run ....

You do. For normal operation, it'll run from the desktop and open a file requester but for the comparison feature you'll need the command line.

You'll need to set the execute bit. chmod u+x <file> in the command line. I should really zip the files up and distribute them like that.

Maybe. It's compiled for amd64 architecture on Debian so there's a good chance. The only thing which might not be installed by default for you is SDL2 If it doesn't work, let me know and I'll see what I can do.

Yes. I included it in v0.16.0 https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.16.0 You need to run it from the command line though in order to specify the ROM which you want to compare against. For example. gopher2600 run -comparisonROM roms/prerelease/Solaris.bin roms/SOLARIS.BIN Will run "SOLARIS.BIN" in the main emulation and "prerelease/Solaris.bin" will be run in the comparison window. To keep things easy, the comparison will end the instant you switch to the debugger or rewind the emulation. I'm not sure how useful it is but it works pretty well I think. If you have any ideas for how to improve it then let me know.

Just to be clear, I'm proposing to use samples for the sound effects only. The speech generation would require an awful lot of samples to cover all the possibilities. I think Festival is flexible enough to not require samples of the speech phonemes. But we'll see. I'll try to improve it this week. If it's still unsatisfactory then it was a worthwhile experiment.

Yes. I think so.

Good point. I'll bear that in mind. The other thing missing from the Festival solution is the SpeakJet sound effects (codes 200 to 254). Not sure how to get around that. Probably a sample pack.