Gopher2600 (continuing development on Github)

[JetSetIlly]

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

 

[+Andrew Davie]

On 3/10/2022 at 7:31 AM, JetSetIlly said:

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

 

Easy enough to test with a long speech sample and compare playing times on actual hardware. I think!

 

[alex_79]

I installed festival from the Arch linux repository, and from what I can tell it is working: it talks when using the "SayText" command as described in the manual.

 

Anyway, I tested a few AtariVox roms but can only hear the TIA sound in Gopher2600 (which is up to date with the git "master" branch).

Something is obviously wrong, as the log reports "festival: fork/exec : no such file or directory", but I have no clue on what to do next.

 

 

[JetSetIlly]

32 minutes ago, alex_79 said:

I installed festival from the Arch linux repository, and from what I can tell it is working: it talks when using the "SayText" command as described in the manual.

 

Anyway, I tested a few AtariVox roms but can only hear the TIA sound in Gopher2600 (which is up to date with the git "master" branch).

Something is obviously wrong, as the log reports "festival: fork/exec : no such file or directory", but I have no clue on what to do next.

 

 

 

I've not completed the configuration step yet. So you need to edit the gopher2600 preferences file:

 

Quote

/home/alex/.config/gopher2600/preferences

 

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.

 

 

[alex_79]

Still not working.

 

[JetSetIlly]

6 minutes ago, alex_79 said:

Still not working.

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

 

 

Edited March 11, 2022 by JetSetIlly

[alex_79]

4 minutes ago, JetSetIlly said:

Trailing space maybe after "/usr/bin/festival" maybe?

Ha! That was it!

Thanks!

 

 

[JetSetIlly]

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

 

[+johnnywc]

This is really cool!   

 

I downloaded the latest and ran my current Qyx build on it:

 

• Game runs well!   I especially like the CRT emulation - it looks amazing close to the real thing!  
• The splash screen rolls on startup (it's loading data from the SaveKey which is detected) but doesn't roll in Stella or on real hardware.  Qyx uses MAM=2 so perhaps the ARM cycles computed is less than expected?   EDIT: I found the preferences for the MAM where I can set it to 'Full' and no more screen rolls.   
• I watched the demo and I see you can show the ARM C code - really cool!  Unfortunately I'm getting "No source file available".  It's most likely because of my odd directory structure:
  • Game directory (ie. \qyx)
    • .\output - this is where the BIN, lst and sym files are generated (the 6502 symbols show up with no issue)
    • .\main - this is where all of the C code is located
    • .\main\bin - this is where the .elf/.map/.dmp files are located (all called testarm.*)

Is there a way to specify the location of the .elf file?  Also, my C code is split into many files (for organization) but I just include them in main.c (no individual object files).  Will that be an issue?   I assume I could generate the qyx binary to the Game directory and it would find the elf file in the subdirectory?

 

Thanks so much for all your hard work - this is an amazing dev tool and I'm looking forward to using it in future projects!  

 

John

 

 

 

[+Andrew Davie]

7 minutes ago, johnnywc said:

 

• I watched the demo and I see you can show the ARM C code - really cool!  Unfortunately I'm getting "No source file available".  It's most likely because of my odd directory structure:

First thing is to check the compilation flags. Here are mine, and although it's disorganised, I thought this might help...

 

# C Compiler flags
OPTIMIZATION =  -Os
CFLAGS = -g3 -gdwarf-2 -mcpu=arm7tdmi -march=armv4t -mthumb # -mthumb-interwork
CFLAGS += -Wall -Wextra -Wunused-macros -ffunction-sections # -save-temps #-mlong-calls 
CFLAGS += $(OPTIMIZATION) $(INCLUDES) 
CFLAGS += -Wl,--build-id=none -flto -mno-thumb-interwork -fextended-identifiers

 

[+Andrew Davie]

And I guess a quick test would be to copy your elf file into the bin file is and see if that's the issue right there. as you suspected.

[+johnnywc]

14 minutes ago, Andrew Davie said:

First thing is to check the compilation flags. Here are mine, and although it's disorganised, I thought this might help...

 

# C Compiler flags
OPTIMIZATION =  -Os
CFLAGS = -g3 -gdwarf-2 -mcpu=arm7tdmi -march=armv4t -mthumb # -mthumb-interwork
CFLAGS += -Wall -Wextra -Wunused-macros -ffunction-sections # -save-temps #-mlong-calls 
CFLAGS += $(OPTIMIZATION) $(INCLUDES) 
CFLAGS += -Wl,--build-id=none -flto -mno-thumb-interwork -fextended-identifiers

 

Thanks Andrew - I used these compiler flags and it caught a couple warnings and freed up about 100 bytes.    Question: do you know how to disable a warning just for a function?  I'm getting "unused parameter" warning in myMemset but that's because it's using inline assemble and not referencing them by name.

11 minutes ago, Andrew Davie said:

And I guess a quick test would be to copy your elf file into the bin file is and see if that's the issue right there. as you suspected.

I did copy the BIN file into the same directory as the elf file but still no source.    I also copied the .bin and .elf file to my parent directory and that didn't work either.  Last, I copied the bin and elf file to the .\main directory (where all the source files are) and still no luck. ?  

 

I'll keep poking around and see what I can figure out.

 

Thanks!

John

 

[JetSetIlly]

1 hour ago, johnnywc said:

This is really cool!   

 

I downloaded the latest and ran my current Qyx build on it:

• Game runs well!   I especially like the CRT emulation - it looks amazing close to the real thing!

 

Cheers. I have a couple of other ideas to improve the CRT emulation but I'm glad you like it. I like it too ?

 

1 hour ago, johnnywc said:

• The splash screen rolls on startup (it's loading data from the SaveKey which is detected) but doesn't roll in Stella or on real hardware.  Qyx uses MAM=2 so perhaps the ARM cycles computed is less than expected?   EDIT: I found the preferences for the MAM where I can set it to 'Full' and no more screen rolls.  

 

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.

 

1 hour ago, johnnywc said:

• I watched the demo and I see you can show the ARM C code - really cool!  Unfortunately I'm getting "No source file available".  It's most likely because of my odd directory structure:
  • Game directory (ie. \qyx)
    • .\output - this is where the BIN, lst and sym files are generated (the 6502 symbols show up with no issue)
    • .\main - this is where all of the C code is located
    • .\main\bin - this is where the .elf/.map/.dmp files are located (all called testarm.*)

 

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.

 

1 hour ago, johnnywc said:

Is there a way to specify the location of the .elf file?

 

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.

 

1 hour ago, johnnywc said:

Also, my C code is split into many files (for organization) but I just include them in main.c (no individual object files).  Will that be an

issue?

 

It shouldn't be. I do something similar here and it works fine.

 

1 hour ago, johnnywc said:

 

Thanks so much for all your hard work - this is an amazing dev tool and I'm looking forward to using it in future projects!

 

It's a pleasure. I'm happy to hear about any features you may require that build on this.

[JetSetIlly]

6 minutes ago, JetSetIlly said:

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.

 

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

 

Edited April 7, 2022 by JetSetIlly

[+johnnywc]

59 minutes ago, JetSetIlly said:

 

Cheers. I have a couple of other ideas to improve the CRT emulation but I'm glad you like it. I like it too ?

I'll be interested to see what else you come up with!   

59 minutes ago, JetSetIlly said:

 

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.

RobotWar and Qyx (for now, unless I can optimize the code) uses MAM 2 on entry.  Chris (cd-w) provided me with a hacked CDFJ driver that has MAM enabled on entry (to save 4 bytes  ).  I compared both drivers and there is one byte difference.  Perhaps you can check this byte to see if it should be enabled on startup?  The other option is for me to just use the standard CDFJ driver and set MAM=2 on Initialize which I could do also (although honestly I forgot how to  ).

 

Here are the two CDFJ drivers I use; one with MAM fully enabled and one without.  The only difference is a '2' at offset 0x584 for MAM=2 and '1' for MAM=1:

 

cdfj_driver.bin

cdfdriver_mam.bin

 

59 minutes ago, JetSetIlly said:

 

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.

That did the trick!  I also copy it into my ./output folder and I can see the source files.   I'm sure there is documentation, but what can I actually do with these source files?  Can you set breakpoints, etc, step through code?  I know that's probably asking too much but just having the source available with the addresses, etc. is very helpful.   

59 minutes ago, JetSetIlly said:

 

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.

I'm all set, so what you have now works for me!   

59 minutes ago, JetSetIlly said:

 

It shouldn't be. I do something similar here and it works fine.

 

Same here, I can select from any of the source files in the drop down.   

59 minutes ago, JetSetIlly said:

 

 

It's a pleasure. I'm happy to hear about any features you may require that build on this.

I'm sure I'll come up with a few!   

54 minutes ago, JetSetIlly said:

 

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

 

I altered my Makefile to copy the .elf file into my output directory and it works like a charm.   

 

I'll spend some time with this and let you know if I hit any issues or have any suggestions.   

 

Thanks again!

John

 

[+Andrew Davie]

2 hours ago, johnnywc said:

Thanks Andrew - I used these compiler flags and it caught a couple warnings and freed up about 100 bytes.    Question: do you know how to disable a warning just for a function?  I'm getting "unused parameter" warning in myMemset but that's because it's using inline assemble and not referencing them by name.

 

Not specifically, but I do use inline pragmas for disabling warnings, so it's bound to be one of those.  For example, when falling through in switch/case statements, I use the following "attribute"...

 

  case CH_PART1:

  	if (creature == CH_SAMPLE)
  		creature = *this = CH_DEMON | FLAG_THISFRAME;

  __attribute__ ((fallthrough));

  case CH_PART2: {

	unsigned char _DOWN = CharToType[(*next) & 0x7F];
                    

At a guess, I would think that what you are after is "__attribute__ ((unused))" after the variable in question, but I haven't tested.

 

As to optimising space, I have been in a continuous "space reduction" and "time reduction" process for some weeks now, where I use Gopher firstly to give me the profile (ARM7.../Performance) and then look at the %CPU usage of the code, then drill down by clicking on the function of interest and see the lines of code taking the most time, and then considering how I can reduce that. When you get it up and running I'm sure you'll agree/be astounded at how much it can help improve your code.

 

The other optimisation, space, is a bit of a strange one.  Clearly you can rewrite things to be more efficient, but at some point you find that taking out code can actuall increase code space.  It's all to do, I'm sure, with the linker doing optimisation and internal register usage, etc.  All I'm saying is that sometimes an intuitive and obvious "improvement" can actually result in more bytes in use. So I always look at the "free bytes" output of the compilation and go by that. Sometimes the "bad" version I keep because it's ~20 byte better in a loop/function in question.

 

I'd be happy to share my current project source code/binary with you, if it would help you see how I do things. No doubt we approach things in a different way, and it always helps to look at how others do things. I think my code is now particularly efficient - but then again just a few weeks ago I found a mod that effectively tripled the speed of the entire thing.  It can always help to have others looking over code;  when explaning why my sound system should work I immediately found three bugs showing why it shouldn't

 

But, back to Gopher... it's really quite a remarkable and useful bit of work for @JetSetIlly to have created by himself in such a short time. It's my go-to emulator for regular development and has helped improve my code by orders of magnitude and made programming so much simpler. I hope many other developers have a look at it and recognise what a powerful tool it is, particularly for code optimisation!

 

[JetSetIlly]

Quote

but what can I actually do with these source files?

 

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.

 

Quote

Can you set breakpoints, etc, step through code?

 

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.

 

Edited April 7, 2022 by JetSetIlly

[+Andrew Davie]

Just now, JetSetIlly said:

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

 

Ah yes, I forgot to mention this one - the best of all!  I open this every now and then and not only does it show you any illegal accesses, it takes you to the very source-code line causing each one.  Simple to fix, and has found many-a-bug!

 

[+Andrew Davie]

3 minutes ago, JetSetIlly said:

 

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.

 

... and on the left of each source code line you see %CPU usage for that line.

[+johnnywc]

1 hour ago, Andrew Davie said:

Not specifically, but I do use inline pragmas for disabling warnings, so it's bound to be one of those.  For example, when falling through in switch/case statements, I use the following "attribute"...

 

  case CH_PART1:

  	if (creature == CH_SAMPLE)
  		creature = *this = CH_DEMON | FLAG_THISFRAME;

  __attribute__ ((fallthrough));

  case CH_PART2: {

	unsigned char _DOWN = CharToType[(*next) & 0x7F];
                    

At a guess, I would think that what you are after is "__attribute__ ((unused))" after the variable in question, but I haven't tested.

Thanks, that is very helpful!  I was able to add this to the inline assembly mem functions and the warnings are gone.  

 

void __attribute__((naked)) myMemset(unsigned char* destination __attribute__ ((unused)), int fill __attribute__ ((unused)), int count __attribute__ ((unused))) {

1 hour ago, Andrew Davie said:

As to optimising space, I have been in a continuous "space reduction" and "time reduction" process for some weeks now, where I use Gopher firstly to give me the profile (ARM7.../Performance) and then look at the %CPU usage of the code, then drill down by clicking on the function of interest and see the lines of code taking the most time, and then considering how I can reduce that. When you get it up and running I'm sure you'll agree/be astounded at how much it can help improve your code.

 

The profiler/ CPU% sounds like a dream come true, as right now I need to set ARM timers around suspicious functions, add in debug code to output values in the score display, etc., run on real hardware, rinse and repeat. 

1 hour ago, Andrew Davie said:

The other optimisation, space, is a bit of a strange one.  Clearly you can rewrite things to be more efficient, but at some point you find that taking out code can actuall increase code space.  It's all to do, I'm sure, with the linker doing optimisation and internal register usage, etc.  All I'm saying is that sometimes an intuitive and obvious "improvement" can actually result in more bytes in use. So I always look at the "free bytes" output of the compilation and go by that. Sometimes the "bad" version I keep because it's ~20 byte better in a loop/function in question.

 Great!  Right now my "space reduction" phase is basically just re-compiling and seeing if the available ROM goes up or down. ?  

 

Oh yes, I've had 6 years of 'experience' with trying to find more ROM; sometimes it's writing *more* code to save ROM, sometimes it's declaring a function as static and sometimes not, sometimes it's initializing a global variable, etc.  Other times it's moving code into a function, and other times it's better to not use function and have the code repeat.  It really is a crap shoot but I've managed to squeeze out bytes of ROM here and there when desperately needed.  

1 hour ago, Andrew Davie said:

I'd be happy to share my current project source code/binary with you, if it would help you see how I do things. No doubt we approach things in a different way, and it always helps to look at how others do things. I think my code is now particularly efficient - but then again just a few weeks ago I found a mod that effectively tripled the speed of the entire thing.  It can always help to have others looking over code;  when explaning why my sound system should work I immediately found three bugs showing why it shouldn't

That would be great!  I'm going to spend some time getting familiar with Gopher to see what it can do so I'm not completely in the dark.  My game engine is approaching 6 years and I'm sure I've carried over some bad habits from my days programming as a youth.  It's funny, I dug out some of my BASIC code I wrote back in 1982 and my style hasn't changed that much.  Not sure if that's a good thing or a bad thing.   

1 hour ago, Andrew Davie said:

But, back to Gopher... it's really quite a remarkable and useful bit of work for @JetSetIlly to have created by himself in such a short time. It's my go-to emulator for regular development and has helped improve my code by orders of magnitude and made programming so much simpler. I hope many other developers have a look at it and recognise what a powerful tool it is, particularly for code optimisation!

 

Agreed - great job @JetSetIlly and thank you so much!  Thanks also to you Andrew for your suggestions as I'm sure I'll find them helpful once I get my hands dirty.

1 hour ago, JetSetIlly said:

 

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.

All of this is very helpful!  I'm looking forward to using the profiler - I can't tell you how many months I spent optimizing RobotWar to display 100 enemies on screen.  This sounds like it will be just the ticket!  

1 hour ago, JetSetIlly said:

 

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.

 

That would be awesome!    

1 hour ago, Andrew Davie said:

Ah yes, I forgot to mention this one - the best of all!  I open this every now and then and not only does it show you any illegal accesses, it takes you to the very source-code line causing each one.  Simple to fix, and has found many-a-bug!

 

Thomas added this to the pre-release of Stella 6.7 and it helped me find a few null pointer accesses right away.  It was a bit of a pain to track down the code since all you get is the CPU registers, but with the PC and map file I was able to track them down.  Having it identify the actual line of C code will be a life/time saver!   

1 hour ago, Andrew Davie said:

... and on the left of each source code line you see %CPU usage for that line.

That's the one I'm most looking forward to, especially when I start back up on Turbo.  I need to figure out a faster way to render the screen and decompress data on the fly.  Should be fun!

 

Thanks again!

John

 

[+johnnywc]

 Oh - silly question.  I looked at the Wiki docs briefly but I didn't see anything about command-line parameters (I want to set this up to run automatically in Textpad).  I'm sure it's something simple, but are there any other parameters to automatically set the controllers, etc.?

[JetSetIlly]

7 hours ago, johnnywc said:

 Oh - silly question.  I looked at the Wiki docs briefly but I didn't see anything about command-line parameters (I want to set this up to run automatically in Textpad).  I'm sure it's something simple, but are there any other parameters to automatically set the controllers, etc.?

 

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.

[+johnnywc]

7 hours ago, JetSetIlly said:

 

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>

Thanks - I was able to easily add a Tool hotkey in Textpad and it fires up Gopher with the current ROM I'm working on.   

7 hours ago, JetSetIlly said:

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.

That seems to be a good solution.  Command line parameters would be best of course ... perhaps you can add a -command switch that would allow you to execute commands on startup in lieu of a script file?  (ie. -command peripheral left gamepad; peripheral right savekey)  Just a suggestion of course.   For now I can always start the ROM in debug mode, click on VCS -> peripherals, select what I want to test with and then RESET/RUN from the terminal.    

 

Speaking of which, one 'bug' I may have found:  I selected GAMEPAD for my left peripheral and restarted, but Qyx detects a QuadTari.  I think there was a similar issue in Stella (that was fixed).  The issue I believe is that both paddle lines are 'high' when a GAMEPAD is connected (INPT0 bit 7 =1 INPT1 bit 7=1).  This is how I'm able to detect a QuadTari (INPT0 bit 7=0, INPT1 bit 7=1).  Hope that helps!  PS If you're ever interested in adding QuadTari support, let me know.   

 

7 hours ago, JetSetIlly said:

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.

Hmmm, I'll fiddle around and see if I can figure it out (although I'm not a windows expert by any stretch   ).

 

Thanks for the tips!

 

John

 

[JetSetIlly]

1 hour ago, johnnywc said:

Command line parameters would be best of course ... perhaps you can add a -command switch that would allow you to execute commands on startup in lieu of a script file?  (ie. -command peripheral left gamepad; peripheral right savekey)  Just a suggestion of course.

 

I like that idea. It makes the most sense to me.

 

1 hour ago, johnnywc said:

Speaking of which, one 'bug' I may have found:  I selected GAMEPAD for my left peripheral and restarted, but Qyx detects a QuadTari.  I think there was a similar issue in Stella (that was fixed).  The issue I believe is that both paddle lines are 'high' when a GAMEPAD is connected (INPT0 bit 7 =1 INPT1 bit 7=1). This is how I'm able to detect a QuadTari (INPT0 bit 7=0, INPT1 bit 7=1).

 

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.

 

1 hour ago, johnnywc said:

Hope that helps!  PS If you're ever interested in adding QuadTari support, let me know.  

 

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?

[+johnnywc]

57 minutes ago, JetSetIlly said:

 

I like that idea. It makes the most sense to me.

  

57 minutes ago, JetSetIlly said:

 

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.

That is correct.

57 minutes ago, JetSetIlly said:

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.

INPT0 and INPT1 should be high when a gamepad is connected to the left port and INPT2 and INPT3 should be high when a gamepad is connected to the right port.  (same as paddles)  At least that how it works on my 4-switch and the Sega gamepads I have tested with.  

57 minutes ago, JetSetIlly said:

It would be interesting to track down the problem.

 I may be wrong, but I believe the issue is what Gopher2600 sets INPT0 bit 7 to high on startup when a gamepad is connected.  (at least this is what Stella does)

57 minutes ago, JetSetIlly said:

 

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.

You are correct.  It allows you to connect 2  controllers up to each port for a max of 4.  It was originally designed to allow 2 player co-op mode  in Wizard of Wor Arcade with the AtariVox, but has since been used in other games like Galagon and RobotWar to allow co-op modes with Savekey.  RobotWar actually supports 4 joysticks with 2 player co-op, each player using dual stick control.    Here is more info on it, including a FAQ.

57 minutes ago, JetSetIlly said:

Is there developer documentation for the QuadTari I can reference?

Right now all there is the FAQ unfortunately, but I do have a controller tester app that can detect what controller is connected to each port, including JOYSTICK, GAMEPAD, QUADTARI and SAVEKEY.  It shows basically how to switch between reading controller 1 and 2  and controllers 3 and 4.  (it uses the DUMP_PORTS bit 7 of VBLANK to enable a multiplexer on the QT to determine which controllers to read).  I had a technical discussion with Thomas J. when he developed the support for Stella; I'll dig it up and send it your way if you think it's something you'll want to add to Gopher some time in the future.  

 

Thanks!

John