Using gtemuAT67 on macOS

[kervinck]

It's improving! My machine is a 2018 MacBook Pro with 16GB and four i7 processor cores at 2.7 GHz.

After today's update, it starts without tricks and boots in ROM v4 by default. I found I can navigate the arrows with WASD and used space to restart the system and such (I tried the arrow keys earlier and that didn't work. My mistake).

There are random "static" noise glitches coming out at random intervals (about once every second or more).

The menu bar is the system's, not the program's. And the bottom of the screen is missing. There is no debug area on the right.

When I pan out all windows, the full screen window appears to be larger than the screen. Only then the debug part becomes visible (but you can't operate a program in that mode). I think I would like to operate mine as a window, instead of a full-screen application.

[at67]

The emulator is capable of switching between fullscreen and any combination of windowed modes using a configuration file named _graphicsconfig.ini If this file doesn't already exist, create it and add the following to it, (in the same directory as your executable).

[Monitor]               ; case sensitive
Fullscreen   = 0        ; windowed = 0, fullscreen = 1
Resizable    = 1        ; disable/enable resizable, only works in windowed mode
Borderless   = 0        ; disable/enable borderless, only works in windowed mode and overrides Resizable
VSync        = 0        ; disable/enable VSync, (not normally of value to enable)
Width        = 640      ; Desktop or <value>, only works in windowed mode
Height       = 480      ; Desktop or <value>, only works in windowed mode
Xpos         = 40       ; <value>, only works in windowed mode
Ypos         = 40       ; <value>, only works in windowed mode

I'll be checking in some better defaults shortly so that it has better behaviour out of the box on most platforms.

P.S. I have no idea what's going on with the sound emulation, apart from the random noise does the rest of the sound system function correctly?

P.P.S. CTRL H is your help key and all the keys are configurable in _inputconfig.ini

[kervinck]

Great, it all works nicely now. Apart from the "ticks", the sounds is what you expect. Tetronis music plays ok. These "ticks" must be some kind of realtime issue with a buffer running empty (just guessing here). I can imagine sound is the hardest thing to run smooth.

[at67]

Aaaaah the obvious question I should have asked first is; does the emulation hit 60FPS constantly? On my personal PC's the emulation is always at 60 FPS or higher, (adjustable with the '-' and '=' keys.

I prioritised the audio code for low latency, but to achieve this it requires the minimum FPS to be hitting 60 or higher, anything lower and the audio starts to break apart.

If this is the issue I can come up with an alternative audio code path that sacrifices latency for lower distortion for PC's that can't hit 60FPS.

[kervinck]

It's pretty stable at 60.0, with an occasional glitch to something else. Too short to read, but probably 59.9.

[at67]

I've experimented on my Win10 laptop, my linux box and my kids machines, all with different CPU/GPU/MB configurations and I can't replicate any audio issues when sitting idle in the menu.

Obviously the big difference is macOS and I can't test that, I might try an older Audio code path with the next checkin and see if that makes any difference on your laptop.

[kervinck]

Thanks. Don't need to rush, it's not a big issue for me. I'm very busy with work at this moment.

[kervinck]

After synching this:

commit 5be876b13139e0327c92463874ec57c177a9812b (HEAD -> master, origin/master, origin/HEAD)
Merge: a14b385 d8a6b03
Author: Marcel van Kervinck <marcelk@bitpit.net>
Date:   Thu Oct 3 22:41:19 2019 +0200

    Merge pull request #115 from at67/master

    Ver 0.8.3

I get this:

[ 30%] Building CXX object CMakeFiles/gtemuAT67.dir/graphics.cpp.o
/Users/marcelk/Projects/Gigatron-1/Software/gtemuAT67/Contrib/at67/graphics.cpp:313:21: error: use of undeclared identifier 'SDL_HINT_RENDER_BATCHING'
        SDL_SetHint(SDL_HINT_RENDER_BATCHING, "1");
                    ^
/Users/marcelk/Projects/Gigatron-1/Software/gtemuAT67/Contrib/at67/graphics.cpp:736:24: warning: enumeration value 'NumMemoryModes' not handled in switch [-Wswitch]
                switch(Editor::getMemoryMode())
                       ^
/Users/marcelk/Projects/Gigatron-1/Software/gtemuAT67/Contrib/at67/graphics.cpp:736:24: note: add missing switch cases
                switch(Editor::getMemoryMode())
                       ^
/Users/marcelk/Projects/Gigatron-1/Software/gtemuAT67/Contrib/at67/graphics.cpp:751:32: warning: enumeration value 'NumMemoryModes' not handled in switch [-Wswitch]
                        switch(Editor::getMemoryMode())
                               ^
/Users/marcelk/Projects/Gigatron-1/Software/gtemuAT67/Contrib/at67/graphics.cpp:751:32: note: add missing switch cases
                        switch(Editor::getMemoryMode())
                               ^
2 warnings and 1 error generated.
make[2]: *** [CMakeFiles/gtemuAT67.dir/graphics.cpp.o] Error 1
make[1]: *** [CMakeFiles/gtemuAT67.dir/all] Error 2
make: *** [all] Error 2

I tried on a fresh clone environment as well. Same issue.

[at67]

I've fixed the error, that was a mistake on my part by relying on newer versions of SDL2. The warnings are nonsense, you can ignore them.

[kervinck]

Don;t worry about the warnings. There are hundreds of them, and that's normal if you use a compiler that's different from the developer.

[kervinck]

BTW: the sound stage is still giving static ticks. Perhaps you can take a peek at gtrun in Contrib/dhkolflib/gtemu. It performs very well. I'm closing the issue, because functionally it all seems to work.

[kervinck]

Some new issues emerged (2 compilation errors):

Scanning dependencies of target gtemuAT67
[  3%] Building CXX object CMakeFiles/gtemuAT67.dir/assembler.cpp.o
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:394:31: warning: format string is not a string literal
      (potentially insecure) [-Wformat-security]
            sprintf(mnemonic, _nativeOpcodes[instruction]._mnemonic.c_str());
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:394:31: note: treat the string as an argument to avoid this
            sprintf(mnemonic, _nativeOpcodes[instruction]._mnemonic.c_str());
                              ^
                              "%s", 
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:409:36: warning: format string is not a string literal
      (potentially insecure) [-Wformat-security]
        (!jump) ? sprintf(instStr, _nativeOpcodes[inst]._mnemonic.c_str()) : sprintf(instStr, _nativeOpcodes[0xE0 + addr]._mnemonic.c_str());
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:409:36: note: treat the string as an argument to avoid this
        (!jump) ? sprintf(instStr, _nativeOpcodes[inst]._mnemonic.c_str()) : sprintf(instStr, _nativeOpcodes[0xE0 + addr]._mnemonic.c_str());
                                   ^
                                   "%s", 
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:409:95: warning: format string is not a string literal
      (potentially insecure) [-Wformat-security]
        (!jump) ? sprintf(instStr, _nativeOpcodes[inst]._mnemonic.c_str()) : sprintf(instStr, _nativeOpcodes[0xE0 + addr]._mnemonic.c_str());
                                                                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:409:95: note: treat the string as an argument to avoid this
        (!jump) ? sprintf(instStr, _nativeOpcodes[inst]._mnemonic.c_str()) : sprintf(instStr, _nativeOpcodes[0xE0 + addr]._mnemonic.c_str());
                                                                                              ^
                                                                                              "%s", 
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:550:28: warning: enumeration value 'BadSize' not handled in switch
      [-Wswitch]
                    switch(byteSize)
                           ^
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:550:28: note: add missing switch cases
                    switch(byteSize)
                           ^
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:491:20: warning: enumeration value 'NumMemoryModes' not handled in
      switch [-Wswitch]
            switch(memoryMode)
                   ^
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:491:20: note: add missing switch cases
            switch(memoryMode)
                   ^
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:569:83: error: non-const lvalue reference to type
      'basic_string<...>' cannot bind to a temporary of type 'basic_string<...>'
            dasmCode._text = (memoryMode == Editor::RAM) ? Expression::strToUpper(std::string(dasmText)) : Expression::strToLower(std::string(...
                                                                                  ^~~~~~~~~~~~~~~~~~~~~
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/expression.h:48:42: note: passing argument to parameter 's' here
    std::string& strToUpper(std::string& s);
                                         ^
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/assembler.cpp:569:131: error: non-const lvalue reference to type
      'basic_string<...>' cannot bind to a temporary of type 'basic_string<...>'
  ...dasmCode._text = (memoryMode == Editor::RAM) ? Expression::strToUpper(std::string(dasmText)) : Expression::strToLower(std::string(dasmText));
                                                                                                                           ^~~~~~~~~~~~~~~~~~~~~

[kervinck]

Also, when use an older compilation, it isn't clear how to load a GT1 file. The help says 'Alt-F5'. There's no Alt-key on the Mac. There is an 'Option' key, but Option-F5 crashes the emulator after first writing a lot of zeroes to the terminal window, like this:

0
0
0
0
0
0
0
0
Floating point exception: 8

[at67]

The error you posted above and most of those warnings should be fixed in the latest version of the code, (your version of the code looks different to mine, but that is probably because I haven't done a Pull Request in a while).

ALT-F5 is for executing the current code loaded at the execution address on real hardware, CTRL-F5 does the same thing but in the emulator. All of these keys are re-definable in _inputconfig.ini.

You normally don't use either of these functions unless you are hand editing code in the Hex Editor.

To launch any of the following, ( .gt1, .gasm, .gbas, .gcl, *.gtb), go to browser mode, CTRL-B and just left click on the file. Right clicking on the file will send it to real hardware through an Arduino interface if it is correctly configured in _loaderconfig.ini. For *.gcl and *_.gtb_ to upload correctly you must also configure the path to the GCL build tools in _loaderconfig.ini**.

[kervinck]

I just merged the BASIC compiler. Please advertise it on the forum. It looks like such a magnificent piece of work. I can play with it this weekend I hope.

[at67]

It's not ready yet, there's a few fundamental pieces missing, like string concatenation, multi-dimensional arrays. INPUT command, stand alone compiler and most importantly documentation. So I'll probably post in a week or two when these issues are finalised and it can go to a Beta.

[kervinck]

It should be great for writing Gigatron games. I hope we can see more people do that now this exists....

[kervinck]

For string operations, you may want to study Apple-1 BASIC. It's different from the DEC-style LEFT$,MID$,RIGTH$ expressions and very close to how I intended to add them to Tiny BASIC. See them more as arrays than as values. It's a simple system, but you still get substrings in expressions. It has concatenation by means of indexed assignments.

http://jefftranter.blogspot.com/2012/03/apple-1-basic.html

Edit: I just pushed their BASIC User Manual in Docs/Apple-1/

[at67]

I've already actually finished 99% of the string handling, (it uses a traditional LEFT$, MID$, RIGHT$ system), it's just the parsing of the concatenation that needs to be finished.

Whatever you add to Tiny BASIC I'll attempt to replicate for gtBASIC.

[kervinck]

Ah great. I added hexadecimal number support recently ($....). It could be squeezed in without affecting the free memory.

I don't plan to expand further on Tiny BASIC soon, although its todo list (in the source) is rather long. At this moment, the added value of new features there is much lower than the other sub-projects. Foremost I want to get "GTOS" running. Perhaps a next incarnation of Tiny BASIC can run in that. After that, the resolution doubler. Then, maybe, v8080 and CP/M.

[kervinck]

BTW: After the alpha-preview merge, there are now these errors: https://pastebin.com/X7H21mzh

[at67]

I've gone through and removed most of the warnings that VisualC++ did it's best job of hiding from me, hopefully this compiles on MacOS.

If it doesn't, I'll bite the bullet and get a MacOS VM running and build it here on my end.

[kervinck]

It gets a lot further now: https://pastebin.com/EzXcvaMv

[kervinck]

Update: https://pastebin.com/dNeTAUct

BTW, I will be offline for most of the rest of the week.

[at67]

Ok, I give up; it compiles fine under Windows and Linux, so I'll take a break from this for a while and setup a VM here in the next few days.

Talk to you when you get back.

[kervinck]

I was just thinking, why not add you as GitHub 'collaborator' to the main repo. It should give you direct commit rights. There should be an invite in your mailbox...

[at67]

Cheers, invitation accepted.

[kervinck]

Good! 100% built on my Mac after today's merge. For reference I pasted the warnings here: https://pastebin.com/JpERn02x

I'm still mostly offline, but I'll see if I can take it out for a spin soon.

[at67]

No problem, I'm just pushing the latest code; hopefully it takes care of most of, (if not all of), the warnings.

[kervinck]

Discard my earlier message, there are almost no warnings when there's almost nothing to rebuild (d'oh). Here's the current status in a clean environment. https://pastebin.com/raw/EAQYuCRt The devil is in unused expressions and incomplete switch statements.

[at67]

The new code I checked in should have hopefully fixed all these.

[kervinck]

Pretty clean. I can spot only one warning when I build it in a fresh clone: https://pastebin.com/raw/ddRvXcff

[at67]

The last warning should be fixed now.

[kervinck]

Another small warning crept in. Not with today's commit, but I'm severely distracted from Gigatron developments at this moment to follow-up in a timely manner. Apologies for that.

BTW: Clock1.gt1 is gorgeous!!! A couple of gbas/*.gt1 files crash on ROMv4 btw (and also on dev.rom). But I suppose you're aware.

Your Horizon.gt1 is a lot better than the C version, especially in size. Our LCC port has too many loose ends. Properly removing unused code is just one of them.

Anyway, here is the clang warning:

[  7%] Building CXX object CMakeFiles/gtemuAT67.dir/compiler.cpp.o
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/compiler.cpp:1860:20: warning: 6 enumeration values not handled in switch:
      'Number', 'String', 'TmpVar'... [-Wswitch]
            switch(numeric._varType)
                   ^
/Users/marcelk/Projects/Gigatron-1/Software/gigatron-rom/Contrib/at67/compiler.cpp:1860:20: note: add missing switch cases
            switch(numeric._varType)
                   ^
1 warning generated.

[kervinck]

I should also add that last time I fired up gtemuAT67, the sound continuity issues seemed gone. I don't know if that was after a commit, or after the upgrade to Catalina.

[at67]

Don't worry about being unable to test/play with the compiler, it gives me plenty of time to refine it and add new features. I also have a decent VM setup here so I am able to test different OS's and compilers pretty easily and quickly.

There are two gbas samples that crash by design, (one requires a 64K memory model to run, it's a torture test of memory allocation conflicts), and the other crashes when it starts poking outside of screen space. Before I release the compiler to Beta, I'll have these two samples sorted out. Also some of the gt1 samples may have been built with a different memory model, it's always safest to recompile the gbas samples on your own system before running the gt1's.

Great news about the Audio, I was able to replicate random glitches, stutters and pops under my VM and it all comes down to not hitting 60FPS 100% of the time, (the FPS counter is not a good indicator of random frame drops), resizing the window is a simple way of proving/showing the problem.

The emulator does a LOT of extra work in the background due to the debugger, disassembler, graphics, etc, (the graphics/text/menus/etc are all done with the equivalent of pokes and peeks into a memory buffer, SDL is purely used to blit that buffer to a texture and get it onto the screen).

P.S. Cheers about the clock sample, it was fun coding it.

[kervinck]

It is understood that 64K files can crash a 32K system during loading, so even before the program can do a proper romType check. The proposal in Docs/GT1-files.txt is to add "_64K.gt1" to the name in that case. There's no need to jump through hoops for this scenario, because that would be unreasonably hard on the design.

Other than that, the desire is that no .gt1 file should ever crash when loading on a Gigatron with any released/versioned Gigatron ROM. So currently, that is v1...v4. It doesn't have to work fully (or work at all), but it shouldn't crash the system.

Still, if a program does require some non-standard ROM to run, Docs/GT1-files.txt suggests to give those files the .gt1x extension instead. (The 'x' to signal that those are experimental.)

[at67]

I'll add this naming convention to my TODO list.

[kervinck]

it's always safest to recompile the gbas samples on your own system before running the gt1's.

This confuses me a bit. How can the host system affect the GT1 file for the target system? Non-determinism? One of the reasons I check in .gt1 files is that it gives good regression testing when fiddling with the tool chain. If the binary changes, there must be a reason and I investigate. If the reason is sound, I just check in the updated gt1. But usually it's an oversight when I'm refactoring things in Core/.

[See also Docs/Versioning.txt . We gradually arrive to the point where we can compile all those writings into a single system PDF.]

[at67]

When you build a gbas source file there are currently a number of ways of determining where the runtime should be stored and memory allocations for strings/arrays/etc occur.

1: There are compiler hints that can build a 32Kbyte or 64Kbyte GT1 file, (these hints control where the runtime/strings/arrays are statically allocated).

2: If there are no compiler hints present, then the compiler chooses the current memory model of the emulator when clicking on a gbas file to compile it. i.e. If you toggle the Emulator to 64Kbyte memory model, then clicking on a gbas file to compile it will build a GT1 file as if you had used 64Kbyte hints within the source code and vice versa for the 32Kbyte memory model.

It's setup this way purely for debugging purposes so that I can test new runtimes, new gbas code, etc in both memory models without having to change the source code. A couple of key presses and I can check new code with both memory models very easily.

It won't be like this once the compiler goes to Beta.

Once the compiler becomes a standalone console executable, I'll remove the automatic memory model detection and have it controlled by source code hints and/or compiler flags.