I started to learn src rom code and difficulties appeared.
I do not understand line 0012 ? Please give me a hint.
------------------- 0003 0001 ld $01--------------;
.countMem0:----0004 d601 st [$01],y---------;
------------------- 0005 00ff ld $ff---------------;
------------------- 0006 6900 xora [y,$00]------- ;
------------------------------------------------------- ;
--------------------0007 ca00 st [y,$00]---------;
--------------------0008 c200 st [$00]-----------;
------------------- 0009 6900 xora [y,$00]------- ;
--------------------000a ec0a bne $000a--------- ;
---------------------------------------------------------;
---------------------------------------------------------;
---------------------------------------------------------;
---------------------------------------------------------;
---------------------------------------------------------;
--------------------000b 00ff ld $ff-----------------;
------------------- 000c 6900 xora [y,$00]---------;
------------------- 000d ca00 st [y,$00]-----------;
------------------- 000e 6100 xora [$00]-----------;
------------------- 000f f013 beq .countMem1----;
--------------------0010 0101 ld [$01]-------------;
--------------------0011 fc04 bra .countMem0----; branch always
------------------- 0012 8200 adda ac--------------; AC+$00 I do not understand how this instructions
--------------------------------------------------------; is started, if before it branch always instruction,and
--------------------------------------------------------; not other link to it ?!?!
.countMem1:----0013 00ff ld $ff-----------------------------------------------------------------------------------
Help to understand src rom code
Forum rules
Be nice. No drama.
Be nice. No drama.
Help to understand src rom code
Last edited by livec on 20 Nov 2019, 06:34, edited 1 time in total.
Re: Help to understand src rom code
Because of the instruction pipelining, (there's a good explanation of how it works here https://gigatron.io/media/gigatron-hackerhotel.pdf), there is always a branch delay slot following every branch in native code.
In simpler terms; every instruction following a branch is always executed, (even if the branch is taken).
The simple way to deal with this is to insert a NOP after every branch in your code and call it a day, or you can do what Marcel has done and take serious advantage of this free feature and use it to do some pretty cool stuff.
Marcel can do a more thorough job of explaining how he has used it to good use in the ROM.
In simpler terms; every instruction following a branch is always executed, (even if the branch is taken).
The simple way to deal with this is to insert a NOP after every branch in your code and call it a day, or you can do what Marcel has done and take serious advantage of this free feature and use it to do some pretty cool stuff.
Marcel can do a more thorough job of explaining how he has used it to good use in the ROM.
Re: Help to understand src rom code
Exactly. Earlier I wrote something about how to embrace it:
https://hackaday.io/project/20781-gigat ... subroutine
The Gigatron as it is now won't work without this feature. For example it enables random read access from most of the program memory. That is a bit special in the context of a Harvard architecture. Originally I intended to use long sequences offor ROM data transfer. But by exploiting the branch delay slot we discovered new possibilities.
https://hackaday.io/project/20781-gigat ... subroutine
The Gigatron as it is now won't work without this feature. For example it enables random read access from most of the program memory. That is a bit special in the context of a Harvard architecture. Originally I intended to use long sequences of
Code: Select all
...
st $dd,[y,x++]
st $dd,[y,x++]
st $dd,[y,x++]
...
Re: Help to understand src rom code
This is of course the first native assembly routine that people encounter, and they may not have watched one of Walter's Gigatron lectures. Only at the third branch instruction the delay slot is really important. So better point it out in the comments. I just updated this in GitHub.
The memory count tests up to 8 addresses. It restores their value in case this might be needed after a warm restart.
P.S: after a cold restart, the memory is practically never in an all-zero state. SRAM bits are made from bistable circuits and those come up in an arbitrary state. It is mostly random, but with some biases that vary from chip to chip. The Gigatron extracts entropy from it for the random number generator. No two games of Snake will be the same .
The memory count tests up to 8 addresses. It restores their value in case this might be needed after a warm restart.
Code: Select all
address
| encoding
| | instruction
| | | operands
| | | |
V V V V
0006 0001 ld $01 ;Quick RAM test and count
.countMem0: 0007 d601 st [$01],y ;Store in RAM and load AC in Y
0008 00ff ld $ff
0009 6900 xora [y,$00] ;Invert value from memory
000a ca00 st [y,$00] ;Test RAM by writing the new value
000b c200 st [$00] ;Copy result in [0]
000c 6900 xora [y,$00] ;Read back and compare if written ok
000d ec0d bne $000d ;Loop forever on RAM failure here
000e 00ff ld $ff
000f 6900 xora [y,$00] ;Invert memory value again
0010 ca00 st [y,$00] ;To restore original value
0011 6100 xora [$00] ;Compare with inverted copy
0012 f016 beq .countMem1 ;If equal, we wrapped around
0013 0101 ld [$01]
0014 fc07 bra .countMem0 ;Loop to test next address line
0015 8200 adda ac ;Executes in the branch delay slot!
.countMem1:
Re: Help to understand src rom code
Thanks,now I understand this part of code
I will move on.
I will move on.