Can i Replace Table/readtable with Data/ProgRead any, benefits?

[ikonsgr74]

I'm using a 18F47Q10 currently with large byte tables and readtable command for getting specific byte from a table. I just saw that there is another GCB command DATA that offers similar functionality so i was wondering if i can replace all my tables with DATA blocks and readtable command with ProgRead, for example:
table romconf as Byte
33,92,192,17,80,67,1....
end table
Readtable (romconf,index,inputvar)
relpaced with:
DATA romconf
33,92,192,17,80,67,1....
end DATA
ProgRead ( @RomConf+index,inputvar)

Also, the index variable i'm using with readtable must be replaced with index-1 to get the same byte?
As i'm using readtable very often and for getting 1000's of table bytes, will it be a significant speed improvement?

[Roger Jönsson]

I'm using big DATA blocks for reading sound samples (up to 100kB!) and it is working great. Yes, DATA blocks are zero based (first value is at adress/index zero). Yes it is significantly faster than tables (nearly as fast as RAM).

There was a bug when using 16-bit/words returning false values. It has been fixed, but not yet in the public download (I think). You can probably ask for an update if you need to use words. Bytes were working great before the update.

[ikonsgr74]

That's great! I'm using only byte tables so that would not be a problem.
I tried to make a test but i'm getting a syntax error 3251 where the ProgRead command is. The code i used:
ProgRead (@format_disk+data_word,PORTD) //(data_word is a 16bit index variable)
DATA format_disk
254,31,1,217,251,237,120,50,255,31,33,25,192,17,0,32....
End DATA

[ikonsgr74]

ok, foun it, the command is programread not progread... :-)

[Roger Jönsson]

Progread does not seem to be working (at least not with 18F27Q84 that I tested on).

I doing this on a 18F27Q84:
Programread(@Sample1+Voice1_sample, Voice1_out)

https://gcbasic.sourceforge.io/help/_programread.html

[Roger Jönsson]

Ok. you found it yourself. Great!

I wonder if the info on ProgRead https://gcbasic.sourceforge.io/help/_data.html is correct or if it is not working for all chips.

[ikonsgr74]

i've tried it with a rather large table/block (~15000 bytes) but when i tried to copmile i get a "not enough program memory" error. Using TABLE isntead of DATA, program fits in PIC's program memory having a few kb unused:
With DATA block
Chip resource usage:
Program Memory: 70640/65536 words (107,79%)

With Table
Chip resource usage:
Program Memory: 63262/65536 words (96,53%)

[Roger Jönsson]

Does it help to declare as byte, like
Data WaveSine as Byte

[ikonsgr74]

i found the problem: i had a readtable command left, for the same table/block and for some reason when program compiled it doubled the size of the table (perhpas puting it both as table and data block..), when i removed readtable i got a few 100's bytes less program memory usage that with table :-)

[Roger Jönsson]

:-)

[ikonsgr74]

ok,i succesfully compiled the code using DATA block and programread command, but it seems like the block is never readed!
@Roger Jönsson i see that you use a 18F27Q84 does this mean that DATA/Programread commands require DMA? Because 18F47Q10 doesn't have DMA...

[ikonsgr74]

i place all bytes of data block in one row (just in case when in DATA BLOCK bytes are not read correctly when placed in multiple lines) but still i get the same thing...
I'm using program and PIC for a board i designed that plugs on expansion port of Amstrad CPC computers, the table i replaced with block is actually the "Rom" of the board, so if Data Block/Table doesn't respond, i got no responce from board when plugged onto an Amstrad CPC....

[Roger Jönsson]

No I am not using DMA. Just:

Programread(@Sawtooth+SampleNo, SAMPLEOUTbyte)
//If SampleNo =1 it will output 1 (the second value in the DATA-block)

Data sawtooth as Byte
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
End data

[ikonsgr74]

have you use it with large blocks of 1000's of bytes?

[Roger Jönsson]

The current sound sample I am working with is 32kB (32000 bytes). It is a drum sound and it plays back flawlessly over and over.

[Roger Jönsson]

Better start testing something simple... Does this work (change to your chip)?

#CHIP 18F27Q84, 64
#OPTION Explicit

DIR PORTA.5 OUT //config. pin 5 on PortA as OUTPUT
DIM Position, Testblock_out as byte

Do
  For Position = 0 to 9
     Programread(@testblock+position, testblock_out)
        If testblock_out = 0 then PORTA.5=0
        If testblock_out = 1 then PORTA.5=1
     wait 200 ms
  next
Loop

Data testblock as Byte
    1,0,1,0,1,0,1,0,0,0
End data

Or output directly to port A:

#CHIP 18F27Q84, 64
#OPTION Explicit

DIR PORTA OUT //config. PORTA as Output
DIM Position as byte

Do
 For Position = 0 to 9
  Programread(@testblock+position, PORTA) //Output on PORTA (A.0 and A.1 with this DATA block)
  wait 200 ms
 next
Loop

Data testblock as Byte
    1,0,1,0,1,0,1,0,2,0
End data

[Anobium]

And, here is the latest build of the compiler. It may have fixes that you need.

https://1drv.ms/u/c/2f87ffe77f3dbec7/IQDp8Axo1km_QpLGrx8G-lZeAToq8bRldCgVxcFf1XI1I_0?e=qTJ5ec

Fixes are shown, same URL as normal, here:
https://1drv.ms/x/c/2f87ffe77f3dbec7/IQDHvj1_5_-HIIAvMggBAAAAAfEb4kIZhvdltkCiEIh4gWY?e=zV0FL3

There are many new features to explore but some of the changes are directly related to DATA Blocks. Roger has been part of these changes and he knows them well.

I hope this helps.

[ikonsgr74]

I've tried the new compiler (i just replace all files in GCstudio\gcbasic folder) but i still get the same results, like bytes from data block never readed....
I also developed a small "test" function: whenever i give a INP command at specific port amstrad should respond with the byte from the data block in sequencial order e.g. startting from DataBlock(0) next INP should give DataBlock(1) etc.
The first bytes of data block are:
DATA romconf as byte
33,92,192,17,80,67...
end data
and i'm using the command:

programread (@romconf+byte_sel, PORTD)
byte_sel=byte_sel+1

where byte_sel is a word pointer (starting from 0 value and increased by 1 on every INP) and PORTD is Amstrad CPC data bus.
Unfortunately all INP commands respond with 0 instead of 33,92,192
Did i made a mistake somewhere in the code, or datablock doesn't work with PIC18F47Q10?

[Anobium]

We need the test code.

There are no constraints on using this across any microcontrollers.

[ikonsgr74]

Well the "test code" i'm using is inside a HUGE gcb source code which used in an expansion board i also developed. The exactly Datablock i used and the command for getting the bytes from it are the ones i mentioned above. In anycase if you want i can give you all the gcb code to check it.

[ikonsgr74]

btw this is the assembly code for the programread command:
;programread (@romconf+byte_sel, PORTD)
movlw low(ROMCONF)
addwf BYTE_SEL,W,ACCESS
movwf EEADDRESS,ACCESS
movlw high(ROMCONF)
addwfc BYTE_SEL_H,W,ACCESS
movwf EEADDRESS_H,ACCESS
banksel 0
call PROGRAMREAD
movff EEDATAWORD,PORTD

And this is the asm code for PROGRAREAD routine called above:

;Source: system.h (5424)
PROGRAMREAD
;EEDataWord = 0x00
clrf EEDATAWORD,ACCESS
clrf EEDATAWORD_H,ACCESS
;Dim EEAddress As Word Alias PMADRH, PMADRL
;Dim EEDataWord As Word Alias PMDATH, PMDATL
;Dim NVMREGSState as Bit
;Disable Interrupt
;IntOff
bcf SYSINTSTATESAVE0,1,BANKED
btfsc INTCON,GIE,ACCESS
bsf SYSINTSTATESAVE0,1,BANKED
bcf INTCON,GIE,ACCESS
;Select program memory
;Start read, wait for it to finish
;SET RD ON
bsf NVMCON1,RD,ACCESS
;NOP
nop
;NOP
nop
;Enable interrupt
;IntOn
btfss SYSINTSTATESAVE0,1,BANKED
bcf INTCON,GIE,ACCESS
btfsc SYSINTSTATESAVE0,1,BANKED
bsf INTCON,GIE,ACCESS
return

[Anobium]

That does not help.
Does the basics work?

[Anobium]

My test code.

#chip 18f47q10
#option Explicit

dim byte_sel = 0

Dir PORTD Out

DATA romconf as byte
33,92,192,17,80,67
end data

repeat 6
    programread (@romconf+byte_sel, PORTD)
    byte_sel=byte_sel+1
end Repeat

Using the new debugger I can see the programread returns 0x00.
The LST files shows the Datablock as correct.
The issue is in ProgramRead - at the moment this has nothing to do with DataBlocks,

---

Debugger

Show EEDATAWORD as 0x00 and this should be 33

---

I can have a look tomorrow morning.

Evan

[Roger Jönsson]

So this is a chip related error?
Measuring on hardware 18F27Q84 PortA it settles at 67.
Programread (@romconfl, PORTA) returns 33 as expected.
(using PORTA since there is no PORTD)

[Anobium]

No. This is not implemented for the Q10. The Q10 has different registers etc all all other Qseries chip for reading program memory.

So, needs to be implemented.