Just by looking at the hex dump (ctrl-M) of Pasm, it is putting a relative address into the LOC. It works if you use the back-slash to force an absolute address.
LOC would always want an absolute address I'd think. Maybe that should be changed in Pasm.
con
lut_start = 0
dat
org 0
loc ptra,#\palette
setq2 #16-1
rdlong lut_start,ptra
jmp #$
orgf $1f0
orgh $400
'====================================================================
'24 bit color format = rr_gg_bb_00
'====================================================================
palette long 0 'black
long $0000aa00 'blue
long $00aa0000 'green
long $00aaaa00 'cyan
long $aa000000 'red
long $aa00aa00 'magenta
long $aa550000 'brown
long $aaaaaa00 'gray
long $55555500 'dark gray
long $5555ff00 'bright blue
long $55ff5500 'bright green
long $55ffff00 'bright cyan
long $ff555500 'bright red
long $ff55ff00 'bright magenta
long $ffff5500 'yellow
long $ffffff00 'white
'====================================================================
The orgh $400 works but just a plain orgh does not. The palette is <$400.
I can change the $400 -> $404, $600, etc and it works fine, but if I make it $300 it fails.
Hmm, experimenting with ORGH $100, even as relative addressing, there is something wrong with what Pasm is generating by the looks of the hex dump:
If palette is <$400 then #@palette and #palette give incorrect results...
#\palette is the only one to always give the correct result.
DAT
orgh 0
org 0
entry
loc ptra,#@palette ' wrong!!! relative
loc ptra,#palette ' wrong!!!
loc ptra,#\palette ' correct use of absolute hub address :)
here jmp #here
DAT
orgh
'====================================================================
'24 bit color format = rr_gg_bb_00
'====================================================================
palette long 0 'black
long $0000aa00 'blue
long $00aa0000 'green
long $00aaaa00 'cyan
long $aa000000 'red
long $aa00aa00 'magenta
long $aa550000 'brown
long $aaaaaa00 'gray
long $55555500 'dark gray
long $5555ff00 'bright blue
long $55ff5500 'bright green
long $55ffff00 'bright cyan
long $ff555500 'bright red
long $ff55ff00 'bright magenta
long $ffff5500 'yellow
long $ffffff00 'white
'====================================================================
Brian,
It's not that either. Cluso's original source of LOC ptra,#@palette produced $3c. At the time I assumed it was relative addressing but it's not correct for that. There's an extraneous leading "3", assuming relative hub addressing.
Have a read of that dump above. The first code is a LOC instruction as per Cluso's example. I'm using ORGH $100 instead of $400.
The resulting address appears to be $3fc, which is way too high and, again, has an extraneous leading "3" for relative hub addressing. If it was assembling as absolute cog addressing then the address should have been $40. If relative cog addressing then it should have been $3f. If absolute hub addressing then it should have been $100. If relative hub addressing then it should have been $fc.
DAT
org 0
....
loc pa,#@gfx '\ launch graphics demo
coginit #16,pa '/
....
'====================================================================
orgh $400 ' REQUIRED TO BE >=$400
org 0
gfx jmp #demo 'launch hubexec code
This requires not only #@gfx to be used, but gfx code must be >=$400
I had problems with the ROM code. We solved it at the time although I was not convinced of the solution. It was probably that the ROM code resides in $FC000... so thankfully it worked.
Oh, okay, so the machine coding for branching is effectively hub addressing all the time. Cool.
Doesn't fix my example of $3fc though. It should have been $fc.
Here's the source:
con
lut_start = 0
dat
org 0
loc ptra,#palette
setq2 #16-1
rdlong lut_start,ptra
jmp #$
orgh $100
'====================================================================
'24 bit color format = rr_gg_bb_00
'====================================================================
palette long 0 'black
long $0000aa00 'blue
long $00aa0000 'green
long $00aaaa00 'cyan
long $aa000000 'red
long $aa00aa00 'magenta
long $aa550000 'brown
long $aaaaaa00 'gray
long $55555500 'dark gray
long $5555ff00 'bright blue
long $55ff5500 'bright green
long $55ffff00 'bright cyan
long $ff555500 'bright red
long $ff55ff00 'bright magenta
long $ffff5500 'yellow
long $ffffff00 'white
'====================================================================
For reference, here is test code that I used to verify the results.
Note that I am using the ROM monitor and serial code to display the results, and then I call the monitor so that I can examine cog/lut/hub memory.
pnut will compile it as a spin file or you can rename it spin2.
This has been brought up several times over the last couple of years.
Need to find some of the old posts on this.
IIRC Chip said this was a bit of a headache.
DAT
00000 orgh 0
00000 000 org 0
00000 000 entry
00000 000 fed0003c loc ptra,#@palette ' wrong!!! relative
00004 001 fed00038 loc ptra,#palette ' wrong!!!
00008 002 fec00010 loc ptra,#\palette ' correct use of absolute hub address :)
0000c 003 fd9ffffc here jmp #here
DAT
00010 orgh
'====================================================================
'24 bit color format = rr_gg_bb_00
'====================================================================
00010 00000000 palette long 0 'black
00014 0000aa00 long $0000aa00 'blue
00018 00aa0000 long $00aa0000 'green
0001c 00aaaa00 long $00aaaa00 'cyan
00020 aa000000 long $aa000000 'red
00024 aa00aa00 long $aa00aa00 'magenta
00028 aa550000 long $aa550000 'brown
0002c aaaaaa00 long $aaaaaa00 'gray
00030 55555500 long $55555500 'dark gray
00034 5555ff00 long $5555ff00 'bright blue
00038 55ff5500 long $55ff5500 'bright green
0003c 55ffff00 long $55ffff00 'bright cyan
00040 ff555500 long $ff555500 'bright red
00044 ff55ff00 long $ff55ff00 'bright magenta
00048 ffff5500 long $ffff5500 'yellow
0004c ffffff00 long $ffffff00 'white
'====================================================================
Cluso,
Stop using LOC. It doesn't seem to be a benefit for what you are doing.
MOV lmm_x, ##gfx ' will always give an absolute address and takes same code space as LOC + MOV.
I don't think LOC has any real use for a PC-relative mode at all. Changing the assemblers to only encoding absolute addresses will probably solve Chip's headache.
Chip uses loc everywhere.
It's in the VGA programs that I think Chip wrote originally.
That's what I am working on, but every time I moved something it broke
BTW loc is a single instruction, not 2 as in mov xx,##xxx.
Just realised what you meant. No, that LOC + MOV was just so I could see what LOC was doing. It's regularly loading up PTRA/PTRB.
I've just done a blanket search&replace on Brian's LA program and aside from the LOC's preceding the three COGINIT's every LOC that was using an @ now uses a \
Seems to run fine. I've actually plugged in a VGA monitor now, didn't think about it before, and can get INFO and RUN buttons to trigger the display.
I will be frank. A lot of the proposed solutions are really ugly. What we have here is only confusing because we haven't visited the discussion for a while, nor was it presented or documented cleanly at the time. We should do those things first before doing anything else.
Potatohead,
No. The use is inconsistent so it’s a pnut bug.
When I last fell foul of it we were trying to get the rom to onsemi.
We just need a consistent way to override its use.
Okay, the reason why #\ doesn't always work is because it generates a label's address with respect to an issued ORG rather than always a hubram address of the loaded code. An ORGH brings it right. This will be as intended.
So, #@ is meant to be the be-all for forcing an address to a label as first loaded to hubram. Sadly, #@ when used on a LOC instruction will inappropriately generate a PC-relative address if pnut perceives the label to be in the same addressing domain as the executing code.
What's interesting is this mechanism is fine for encoding branch instructions directly. It's only a problem for LOC. Basically, LOC has no purpose supporting relative addressing.
I think this has come up before. For a label "foo" that's in hub, "#@foo" and "#foo" mean exactly the same thing: "@x" means "the hub value of x", so if x is already a hub address then there's no difference.
"#\foo" is the syntax to use if you want to force an absolute (not relative) address
"#\@foo" is the syntax to use if you want to force an absolute hub address, even if "foo" is defined in COG
It's confusing because we're used to thinking of "@foo" as "the address of foo", which implies an absolute address. But "@foo" just means "use the hub value for label foo" and implies nothing about whether absolute or relative addressing will be used.
PNut, p2asm, and fastspin all agree on this, AFAICT.
Comments
Just by looking at the hex dump (ctrl-M) of Pasm, it is putting a relative address into the LOC. It works if you use the back-slash to force an absolute address.
LOC would always want an absolute address I'd think. Maybe that should be changed in Pasm.
setq2 #16-1 rdlong lut_start,#@paletteEDIT: And, because ORGH is declaring it as hubram, you don't even need the @
setq2 #16-1 rdlong lut_start,#palettecon lut_start = 0 dat org 0 loc ptra,#\palette setq2 #16-1 rdlong lut_start,ptra jmp #$ orgf $1f0 orgh $400 '==================================================================== '24 bit color format = rr_gg_bb_00 '==================================================================== palette long 0 'black long $0000aa00 'blue long $00aa0000 'green long $00aaaa00 'cyan long $aa000000 'red long $aa00aa00 'magenta long $aa550000 'brown long $aaaaaa00 'gray long $55555500 'dark gray long $5555ff00 'bright blue long $55ff5500 'bright green long $55ffff00 'bright cyan long $ff555500 'bright red long $ff55ff00 'bright magenta long $ffff5500 'yellow long $ffffff00 'white '====================================================================Hmm, experimenting with ORGH $100, even as relative addressing, there is something wrong with what Pasm is generating by the looks of the hex dump:
First machine code is $fed003fc. I read that as relative address $3fc. $0fc would be more like it.
#\palette is the only one to always give the correct result.
DAT orgh 0 org 0 entry loc ptra,#@palette ' wrong!!! relative loc ptra,#palette ' wrong!!! loc ptra,#\palette ' correct use of absolute hub address :) here jmp #here DAT orgh '==================================================================== '24 bit color format = rr_gg_bb_00 '==================================================================== palette long 0 'black long $0000aa00 'blue long $00aa0000 'green long $00aaaa00 'cyan long $aa000000 'red long $aa00aa00 'magenta long $aa550000 'brown long $aaaaaa00 'gray long $55555500 'dark gray long $5555ff00 'bright blue long $55ff5500 'bright green long $55ffff00 'bright cyan long $ff555500 'bright red long $ff55ff00 'bright magenta long $ffff5500 'yellow long $ffffff00 'white '====================================================================Pnut interprets addresses below $400 as COG/LUT addresses.
It's not that either. Cluso's original source of LOC ptra,#@palette produced $3c. At the time I assumed it was relative addressing but it's not correct for that. There's an extraneous leading "3", assuming relative hub addressing.
Have a read of that dump above. The first code is a LOC instruction as per Cluso's example. I'm using ORGH $100 instead of $400.
The resulting address appears to be $3fc, which is way too high and, again, has an extraneous leading "3" for relative hub addressing. If it was assembling as absolute cog addressing then the address should have been $40. If relative cog addressing then it should have been $3f. If absolute hub addressing then it should have been $100. If relative hub addressing then it should have been $fc.
Consider the following code. Pnut generates the following output.
Notice the relative offsets need to be shifted right 2 places to be cog/lut offsets.
DAT org 0 .... loc pa,#@gfx '\ launch graphics demo coginit #16,pa '/ .... '==================================================================== orgh $400 ' REQUIRED TO BE >=$400 org 0 gfx jmp #demo 'launch hubexec codeThis requires not only #@gfx to be used, but gfx code must be >=$400I had problems with the ROM code. We solved it at the time although I was not convinced of the solution. It was probably that the ROM code resides in $FC000... so thankfully it worked.
Doesn't fix my example of $3fc though. It should have been $fc.
Here's the source:
con lut_start = 0 dat org 0 loc ptra,#palette setq2 #16-1 rdlong lut_start,ptra jmp #$ orgh $100 '==================================================================== '24 bit color format = rr_gg_bb_00 '==================================================================== palette long 0 'black long $0000aa00 'blue long $00aa0000 'green long $00aaaa00 'cyan long $aa000000 'red long $aa00aa00 'magenta long $aa550000 'brown long $aaaaaa00 'gray long $55555500 'dark gray long $5555ff00 'bright blue long $55ff5500 'bright green long $55ffff00 'bright cyan long $ff555500 'bright red long $ff55ff00 'bright magenta long $ffff5500 'yellow long $ffffff00 'white '====================================================================Note that I am using the ROM monitor and serial code to display the results, and then I call the monitor so that I can examine cog/lut/hub memory.
pnut will compile it as a spin file or you can rename it spin2.
Need to find some of the old posts on this.
IIRC Chip said this was a bit of a headache.
Okay, no problem. Sounds like it'll be sorted out when Pnut is replaced.
What concerns me more though, is it could cause a problem in the ROM and that could be a disaster
DAT 00000 orgh 0 00000 000 org 0 00000 000 entry 00000 000 fed0003c loc ptra,#@palette ' wrong!!! relative 00004 001 fed00038 loc ptra,#palette ' wrong!!! 00008 002 fec00010 loc ptra,#\palette ' correct use of absolute hub address :) 0000c 003 fd9ffffc here jmp #here DAT 00010 orgh '==================================================================== '24 bit color format = rr_gg_bb_00 '==================================================================== 00010 00000000 palette long 0 'black 00014 0000aa00 long $0000aa00 'blue 00018 00aa0000 long $00aa0000 'green 0001c 00aaaa00 long $00aaaa00 'cyan 00020 aa000000 long $aa000000 'red 00024 aa00aa00 long $aa00aa00 'magenta 00028 aa550000 long $aa550000 'brown 0002c aaaaaa00 long $aaaaaa00 'gray 00030 55555500 long $55555500 'dark gray 00034 5555ff00 long $5555ff00 'bright blue 00038 55ff5500 long $55ff5500 'bright green 0003c 55ffff00 long $55ffff00 'bright cyan 00040 ff555500 long $ff555500 'bright red 00044 ff55ff00 long $ff55ff00 'bright magenta 00048 ffff5500 long $ffff5500 'yellow 0004c ffffff00 long $ffffff00 'white '====================================================================Stop using LOC. It doesn't seem to be a benefit for what you are doing.
MOV lmm_x, ##gfx ' will always give an absolute address and takes same code space as LOC + MOV.
It's in the VGA programs that I think Chip wrote originally.
That's what I am working on, but every time I moved something it broke
BTW loc is a single instruction, not 2 as in mov xx,##xxx.
Just realised what you meant. No, that LOC + MOV was just so I could see what LOC was doing. It's regularly loading up PTRA/PTRB.
I'm guessing non-LOC instructions are the ones that have problems with backslash.
Seems to run fine. I've actually plugged in a VGA monitor now, didn't think about it before, and can get INFO and RUN buttons to trigger the display.
No. The use is inconsistent so it’s a pnut bug.
When I last fell foul of it we were trying to get the rom to onsemi.
We just need a consistent way to override its use.
So, #@ is meant to be the be-all for forcing an address to a label as first loaded to hubram. Sadly, #@ when used on a LOC instruction will inappropriately generate a PC-relative address if pnut perceives the label to be in the same addressing domain as the executing code.
What's interesting is this mechanism is fine for encoding branch instructions directly. It's only a problem for LOC. Basically, LOC has no purpose supporting relative addressing.
"#\foo" is the syntax to use if you want to force an absolute (not relative) address
"#\@foo" is the syntax to use if you want to force an absolute hub address, even if "foo" is defined in COG
It's confusing because we're used to thinking of "@foo" as "the address of foo", which implies an absolute address. But "@foo" just means "use the hub value for label foo" and implies nothing about whether absolute or relative addressing will be used.
PNut, p2asm, and fastspin all agree on this, AFAICT.