I can't reproduce your issue with CTRL+H or SDL on multiple PC's and Laptops here at home and no one else has ever reported anything like what you seem to be experiencing.
I am not really sure what your issue is with SDL; are you saying other SDL programs have problems on your PC?
I would update ALL drivers that can be updated, i.e. GPU, (internal Intel?), Chipset, etc.
Try some of the sample SDL graphics programs, the way I am using SDL is so simple it's hard to imagine what is going wrong. Basically I create a texture, copy the Gigatron's emulated memory buffer to it and then display it once per frame, (60Hz), using a basic SDL render pattern, i.e.
Code: Select all
SDL_UpdateTexture(_screenTexture, NULL, _pixels, SCREEN_WIDTH * sizeof(uint32_t));
SDL_RenderCopy(_renderer, _screenTexture, NULL, NULL);
renderHelpScreen();
SDL_RenderPresent(_renderer);
if(synchronise) Timing::synchronise();
If you like I can build you a version without the
renderHelpScreen(); as that relies on hardware Alpha blending.
Also I had a look at xa.gasm, it's very nifty!
A few suggestions:
1: Don't fall into the habit of relying on the
_callTable_ as it becomes increasingly hard to juggle as your code gets bigger, (even though it offers a substantial performance and code size benefit).
2: Also the system requires some parts of page 0 to be constant free at .gt1 load time, due to the way it works, (if you want specific detail I can point you to a thread discussing the gory details). Currently 0x30 to 0x44 and 0xC0 to 0xFF must be constant free at load time, otherwise the loader will not be impressed, (you can still use variables in your code at these locations, just NOT constants). e.g. You can't let the CallTable enter these zones and you can't use DB or DW in these zones. Also be careful of the vCPU Stack colliding into your data, the Stack grows downwards from 0xFF, (it points to 0x00 when it is empty and grows for every PUSH).
3: Parts of your code use LDWI for positive constants less than 256, you can use LDI and they are expanded to their full 16 bit values in vAC. LDI is faster and shorter.
To change from using the CallTable to manually setting up and calling, you would do something like this:
Code: Select all
; comment out or delete CallTable
; _callTable EQU 0x007E
Replace every occurrence of CALL LABEL with:
Code: Select all
LDWI LABEL
CALL giga_vAC ; giga_vAC is defined in gigatron.i
Obviously if you do this you have to possibly save and restore vAC if your previous CALL relied on the contents of vAC, e.g.
Code: Select all
vAC_tmp EQU 0x30
...
...
STW vAC_tmp
LDWI LABEL
CALL giga_vAC ; giga_vAC is defined in gigatron.i
...
...
LABEL LDW vAC_tmp
...
RET
P.S. If you are just using the emulator to assemble your code, there is also a standalone console version of the assembler in the tools directory. I checked it and the one I built for you assembled your code fine, use it something like this:
This assumes that
gigatron.i and
macros.i are in the same directory as xa.gasm