PASM - Writing to HUB RAM
lanternfish
Posts: 366
Hi all. A bit of a newbiewith PASM so bear with me.
I have an annoying issue with writing a 'table' to HUB RAM. I can't see where I have gone wrong and thought (a) fresh brain(s) could help.
Attached is PASM to read RGB data from a FIFO buffer (no addressing needed). The data format is 00000000_00rrrrrr_00gggggg_00bbbbbb. The FIFO RD pulse is on P7.
The first major part of the code reads in the data and stores it in COG RAM from $100. This appears to work fine.
The second major part (below) reads two longs from COG RAM, averages the two bytes and is meant to store it in HUB RAM from $0000. It doesn't! It stores it from $100 and the number of longs stored is inconsistent. It should be 100.
Any advice with sorting this problem will be much appreciated.
EDIT: Corrected HUB RAM - COG RAM comment error (as pointed out by Ale #2)
I have an annoying issue with writing a 'table' to HUB RAM. I can't see where I have gone wrong and thought (a) fresh brain(s) could help.
Attached is PASM to read RGB data from a FIFO buffer (no addressing needed). The data format is 00000000_00rrrrrr_00gggggg_00bbbbbb. The FIFO RD pulse is on P7.
The first major part of the code reads in the data and stores it in COG RAM from $100. This appears to work fine.
{{DecimatePixels}} PUB Main {Launch cog to DecimatePixels} cognew(@ReadFIFO, 0) 'Launch new cog CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 DAT {ReadFIFOData} org 0 'Begin at Cog RAM addr 0 ReadFIFO mov dira, FIFOReadPin 'Set P7 output (FIFO RD pulse +ve) mov outa, #0 'P7 Low GetRGBData xor outa, FIFOReadPin 'P7 High nop 'Wait for data to settle ' mov RGBValue, ina 'Read RGB value from FIFO and store at address RGBAddress mov RGBValue, PseudoIna 'Store pseudo-ina data at address RGBAddress xor outa, FIFOReadPin 'P7 Low WriteTable movd WriteRGB, COGPointer 'Prepare self modifying code that nop 'will write RGB data to COG RAM WriteRGB mov 0-0, RGBValue 'Write RGB data to COG RAM add COGPointer, #1 'Point to next COG RAM address djnz PixelCounter, #GetRGBData 'If PixelCounter not zero then repeat @ GetRGBData SignalNextCog wrbyte NextCOG, COGSync 'COGSynch Address = $1FFF: HUB RAM Cog Synch address
The second major part (below) reads two longs from COG RAM, averages the two bytes and is meant to store it in HUB RAM from $0000. It doesn't! It stores it from $100 and the number of longs stored is inconsistent. It should be 100.
DecimatePixels mov PixelCounter, #100 'Get ready to read 200 RGB longs (2 at a time) mov COGPointer, #$100 DecimateLoop movs RGBRead1, HUBPointer 'Prepare self modifying code that nop 'will read 1st RGB long from COG RAM RGBRead1 mov RGBValue, 0-0 'Read 1st RGB long from COG RAM add COGPointer, #1 'Next COG RAM address movs RGBRead2, COGPointer 'Prepare self modifying code that nop 'will read 2nd RGB long from COG RAM RGBRead2 mov RGB2Value, 0-0 'Read 2nd RGB long from COG RAM DecimatePixel add RGBValue, RGB2Value 'Add 1st and 2nd RGB longs shr RGBValue, #1 'Divide by 2 (get average of two longs) RGB2Table movd RGB2HUB, HUBPointer 'Prepare self modifying code that nop 'will write RGB long to HUB RAM RGB2HUB wrlong RGBValue, HUBPointer 'Write RGB data to [B]HUB[/B] RAM add HUBPointer, #4 'Point to next HUB RAM long address djnz PixelCounter, #DecimateLoop 'If PixelCounter not zero then repeat @ DecimateLoop ForeverLoop jmp #ForeverLoop PseudoIna long %00000000_00101010_00010101_00101010 NextCOG byte 2 COGSync long $1FFF FIFOReadPin long |< 7 PixelCounter long 200 COGPointer long $100 RGBValue long $0000 RGB2Value long $0000
Any advice with sorting this problem will be much appreciated.
EDIT: Corrected HUB RAM - COG RAM comment error (as pointed out by Ale #2)
Comments
And this part...
WIll change the d-field of wrlong (it is the source, that is constant in your program, RGBValue).
It should be...
Ale
Will try it out.
Use it as I wrote above. Here is the simulation, it did two cycles through the loop
Edit: **** NOTE *** There is a variable in COG RAM that is of byte size... make it long !
Lanternfisch: You need COGPointer as kuroenko showed (that is what I meant above !, not the comment.... I didn't see the comment, because it doesn't get compiled!)
I am at work when I read this so will fix my code when I get home. Thanks for finding my mistakes. Obvious when I look at it with a clear head and no distractions.
The Propellor is quite a shift from my previous coal-fired processor assembler experience (Z80, 6502) 100 years ago.