at67 emulator

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
at67
Posts: 55
Joined: 14 May 2018, 08:29

Re: at67 emulator

Post by at67 » 19 Nov 2018, 03:05

bmwtcu wrote:
18 Nov 2018, 16:26
Thanks MCD for compiling it.

This might be more a question for at76. It looks like the emulator emulates PS2 keyboard entry, but does it also work with the save/CTRL-F3 mechanism to save BASIC programs? I tried and while save seems to have done something, when I tried CTRL-F3, it didn't look like it worked.

Thanks.
The emulator did initially emulate the PS2 keyboard entry with varying degrees of success, (this was well before the V3 ROM and it wasn't 100% correct on racer), but I haven't updated it as Marcel has updated BabelFish.

There shouldn't be any reason for it it not to be able to emulate any new PS2 keyboard functionality.

at67
Posts: 55
Joined: 14 May 2018, 08:29

Re: at67 emulator

Post by at67 » 19 Nov 2018, 03:13

Maniccyberdog wrote:
16 Nov 2018, 07:35
Hi,

I have made some progress on at67 emulator and now have it compiling under windows. My next problem to solve is the message ‘CPU stall...’ keeps being echoed to the screen, has anyone else seen this?
You had this problem because you built the code in /SUBSYTEM:CONSOLE mode instead of /SUBSYTEM:WINDOWS mode.

In /SUBSYTEM:CONSOLE mode you need to comment out line 306, (as you found out):

Code: Select all

306	//if(!AllocConsole()) return;
In /SUBSYTEM:WINDOWS mode, (which is what the cmake script I wrote sets it to), you don't have to do anything, it just compiles and works.

P.S. As far as how the emulator runs in /CONSOLE or /WINDOWS mode I can see no discernible difference in terms of performance or functionality, SDL2 weaves it's ifdef preprocessor main/winmain magic based on these build variables and compiles the correct code.

at67
Posts: 55
Joined: 14 May 2018, 08:29

Re: at67 emulator

Post by at67 » 19 Nov 2018, 03:25

marcelk wrote:
18 Nov 2018, 22:59
There're some quirks. It's reaching 96% speed if I interpret the indicator correctly, but 36 fps? It defaults to a non-standard 64K and the the startup sound is choppy (probably due to the speed). I haven't figured out much the controls. F11 switches between controlling the Gigatron and the hex editor. Delete, PageDown and PageUp seem to be mapped to the correct game controller signals. The emulation of video mode 2 looks quite messy.
- The CPU usage bar only makes sense if you setup the correct fences in the vasm code, (you can do it in GCL code as well), the examples I wrote show you how to do it. It's purpose is to get an approximate idea of how much CPU time you have left per frame after the firmware does it's bit bashing magic and after the vCPU interpreter has interpreted your code outside the fences. I used this to fine tune my tetris example so that the sound never stuttered, (by finding the appropriate places in the code to call playMidiAsync). So the 96% figure you are seeing is probably nonsense as the fences are not set correctly for the code initially running, (the menu).

- If the emulation doesn't hit 60FPS or close, then sound will start to chop/stutter as the the gaps between output samples become too large.

- 'h' will give you a help screen.

- The emulation of video modes is the original native code that I wrote to disable scanlines, I wouldn't expect it to work with any ROM's apart from the original and in fact there are a bunch of patches applied to the ROM at emulator startup that absolutely rely on the correct ROM version. (I just never had a chance to refactor this code, before I ran out of time on this project).
marcelk wrote:
18 Nov 2018, 22:59
P.S.2: Do you have a GitHub account? I think we should archive the zip file in Contrib/<yourname> instead of just in a forum post.
I'd personally be really unhappy with this, as the implication is that the executable/DLL's were built/obtained from a reliable source with my name attached to them. I am in no way responsible for what happens to anyone who downloads these or any pre-built versions of my code. The only code I will attach my name to and endorse is the original source code that anyone can build as I have shown in this thread.

Maniccyberdog
Posts: 11
Joined: 11 Nov 2018, 13:18

Re: at67 emulator

Post by Maniccyberdog » 19 Nov 2018, 07:02

Hi at67,

I followed your steps for windows on a clean windows 10 LTSB. I found that it sets the build to windows/gui as you say but it still wouldn’t build. I totally agree with your point about posting exe, and yes it is a risk for end users. Although to be fair if I wanted to distribute a payload I would want it to hit more than 8 computers. :-)

I’m not a C++ programmer, but it would be helpful to know why I needed to carry out the above steps?

Are you planning anymore work on this project or is it dead?

at67
Posts: 55
Joined: 14 May 2018, 08:29

Re: at67 emulator

Post by at67 » 19 Nov 2018, 09:49

Maniccyberdog wrote:
19 Nov 2018, 07:02
I’m not a C++ programmer, but it would be helpful to know why I needed to carry out the above steps?
I have no idea, we would have to look at the project settings that cmake produced for VS on your system. If I were to guess, I would say that /SUBSYTEM:CONSOLE was being forced in your build somewhere after the cmake settings.

Your solution was the right one.
Maniccyberdog wrote:
19 Nov 2018, 07:02
Are you planning anymore work on this project or is it dead?
The project is not dead, I just need to find another chunk of time, (probably just after Christmas), I have already completed the foundations of a BASIC compiler and it is producing very fast optimised vCPU code on some simple test cases already; (it's in the repo).

Maniccyberdog
Posts: 11
Joined: 11 Nov 2018, 13:18

Re: at67 emulator

Post by Maniccyberdog » 19 Nov 2018, 13:27

That's great to hear the project isn't dead. I would be happy to help test any builds in the future. I think it would be nice if 'we' could offer a MSI installer for the windows people (happy to do this). We would need to 'be trusted' by the other members of this community, what do you think?

wtlprnft
Posts: 2
Joined: 28 Nov 2018, 20:21

Re: at67 emulator

Post by wtlprnft » 29 Nov 2018, 07:31

Hi,
I tried to build on OS X. configure and generate with cmake OK, also make OK, but when I start the executable I get following error:

Graphics::initialise() : failed to create SDL surface.

Any idea what I did wrong?

thanks
peter

User avatar
marcelk
Posts: 120
Joined: 13 May 2018, 08:26

Re: at67 emulator

Post by marcelk » 29 Nov 2018, 10:23

wtlprnft wrote:
29 Nov 2018, 07:31
I tried to build on OS X. configure and generate with cmake OK, also make OK, but when I start the executable I get following error:

Graphics::initialise() : failed to create SDL surface.

Any idea what I did wrong?
I've spent an evening on it before trying to crack it, unfortunately to no avail. Same error. I must say that "Cmake" and "SDL" are completely foreign to me.

at67
Posts: 55
Joined: 14 May 2018, 08:29

Re: at67 emulator

Post by at67 » 29 Nov 2018, 12:59

I haven't had a chance to build/run it under OSX yet unfortunately.

By default the emulator will try and run in fullscreen mode, try putting it in windowed mode and see what happens.

Create a file named "graphics_config.ini" and save it with the following contents into the same directory as the executable.

You can also try putting in actual values for window size rather than "Desktop".

Code: Select all

[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       = Desktop  ; Desktop or <value>, only works in windowed mode
Height      = Desktop  ; Desktop or <value>, only works in windowed mode
P.S. It's all case sensitive.

Post Reply