at67 emulator

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
dwesti
Posts: 15
Joined: 31 Jan 2020, 05:37

Re: at67 emulator

Post by dwesti » 01 Feb 2020, 04:26

thank you

so, code

Code: Select all

SYS_SpriteCopy_118  .LD     [srcAddr],X         ; src line 0
                    .LD     [srcAddr + 1],Y
                    .LD     [Y,X] 
looks like

Code: Select all

X=peek(srcAddr]
Y=peek(srcAddr+1]
A=peek[y*256+X]
?

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

Re: at67 emulator

Post by marcelk » 01 Feb 2020, 05:45

dwesti wrote:
31 Jan 2020, 13:19
Finally, I assemble one xD
xor_ttl.zip
Congratulations, well done :-)

prb.png
prb.png (94.06 KiB) Viewed 3817 times
dwesti wrote:
01 Feb 2020, 04:26
so, code

Code: Select all

SYS_SpriteCopy_118  .LD     [srcAddr],X         ; src line 0
                    .LD     [srcAddr + 1],Y
                    .LD     [Y,X] 
looks like

Code: Select all

X=peek(srcAddr]
Y=peek(srcAddr+1]
A=peek[y*256+X]
?
Exactly.

dwesti
Posts: 15
Joined: 31 Jan 2020, 05:37

Re: at67 emulator

Post by dwesti » 02 Feb 2020, 08:28

Again ussue with emulator: slowly respond to Ctrl+keys (
As I see same happens with SDL.
Attachments
xa.zip
(1.25 KiB) Downloaded 112 times

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

Re: at67 emulator

Post by at67 » 02 Feb 2020, 10:39

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:

Code: Select all

gtasm xa.gasm 0x0200 .
This assumes that gigatron.i and macros.i are in the same directory as xa.gasm

dwesti
Posts: 15
Joined: 31 Jan 2020, 05:37

Re: at67 emulator

Post by dwesti » 02 Feb 2020, 11:33

I used CallTable, because assembler reject source with message "Assembler::assemble() : Label missing : 'huj' : in 'xa.gasm' on line 165"
I found example, so why I use it.
Thanks for the tip

User avatar
ECL
Posts: 26
Joined: 01 Feb 2020, 17:56

emulator works well in Linux

Post by ECL » 02 Feb 2020, 13:42

the ./gtemuAT67 Linux elf binary works pretty well here.

ROM4 is best here with most intuitive keys when set to PS2 which means PC host keyboard or whatever. maybe use more clarified terms in input.ini in the keyboard section, to avoid users resorting to trial & error methodology .

The emulator gives you a good feeling of what the real thing is that you are going to sink your hard-earned 100+ € into... and its worth every penny! :mrgreen:
Last edited by ECL on 02 Feb 2020, 17:01, edited 1 time in total.

User avatar
ECL
Posts: 26
Joined: 01 Feb 2020, 17:56

emulate the "prb.gt1" binary in firefox

Post by ECL » 02 Feb 2020, 14:32

dwesti wrote:
31 Jan 2020, 13:19
I assembled one Gigatron application binary named prb.gt1
awesome app! works like a charm :idea: when loaded into the emulator at :arrow: https://gigatron.io/emu/
Attachments
prb.gt1
gigatron binary showing a cool screen
(49 Bytes) Downloaded 119 times

dwesti
Posts: 15
Joined: 31 Jan 2020, 05:37

Re: at67 emulator

Post by dwesti » 02 Feb 2020, 16:51

classic XOR-texture.Chang XOR to AND and you get another pattern

User avatar
ECL
Posts: 26
Joined: 01 Feb 2020, 17:56

Re: at67 emulator

Post by ECL » 04 Feb 2020, 18:45

dwesti wrote:
02 Feb 2020, 16:51
Change XOR to AND and you get another pattern
is it possible to do that on-the-fly using WOZmon at https://gigatron.io/emu/ ? Or does the .gt1 get deleted when one enters WozMon ?

dwesti
Posts: 15
Joined: 31 Jan 2020, 05:37

Re: at67 emulator

Post by dwesti » 05 Feb 2020, 15:01

Do you plan to add breakpoints for debugger ?

Post Reply