Activity for GCBASIC

Roger Jönsson posted a comment on discussion Help

Roger Jönsson — Fri, 03 Jul 2026 18:28:58 -0000

I examined the asm for a long time, but I could not make out what to extract, so I took a look in the 18FxxQ84 manual to see if it would help. There was an ADC example which I managed to adopt and succeeded in getting working. So after seemingly wasting a lot of valuable time fiddling around, it turned out it was not wasted after all! I now have a AD-conversion routine that can be started off to do its thing while my code is running. Happy day! :) #CHIP 18F27Q84, 64 #OPTION Explicit DIR PORTA.1 OUT...

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 03 Jul 2026 08:19:16 -0000

In the new online Help already. :-) ikonsgr74 - maybe. I have no idea.

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Fri, 03 Jul 2026 08:17:40 -0000

It would be nice to have info or link on escape characters in the help /Chr. So if I go look for Chr I will be reminded of their existence. :=) Maybe ikonsgr74 managed to make a similar mistake as I did, not copying files to the right places.

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 03 Jul 2026 08:00:46 -0000

The question is.. why does this not work for user ikonsgr74 . I am certian the library is working.

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 03 Jul 2026 07:34:07 -0000

Great. Hopefully useful. There may be ambiguous definitions hidden in libraries awaiting discover. The build also has escape character support in strings. :-)

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Fri, 03 Jul 2026 07:21:26 -0000

Yes, I have been there... Testing with Ambuguity Inspector turned on I get: "Warning: Ambiguous constant/register name(s): PIR3" Good. Very helpful.

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 03 Jul 2026 07:11:04 -0000

You try the new Ambuguity Inspector.... create a constant the same name as Register or Register.Bit Something like #define PIR3 1 . If you have set the option in Prefs Editor then you will get a warning. Clearly, this is an example but a user could have easily created a constant with the same name as a a register and register.bit and they would have no idea why the program would not work. So, hopefully, this helps developers.

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Fri, 03 Jul 2026 06:58:18 -0000

Yes, the #include was missing. Sigh. I'm starting to see things not there. I got the numbers out via Programread in my testprogram and it works as expected. The right numbers are coming out. I also tried Data block romconf as word with programread (@romconf+position*2, Mywordvar) and it works too. While I got this hooked up, is there anything else I should test?

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 03 Jul 2026 06:39:29 -0000

Excellent. Can I confirm the PROGRAMREAD works as expected? Re Glcd error. Missing the #include

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Fri, 03 Jul 2026 06:34:41 -0000

I thought that I dragged all those files into each appropriate folders yesterday. I now see that the lowlevel folder ended up in the GCbasic folder, but it should have been in the include folder. After correcting that, my test code works. Hardware test = ok.

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 03 Jul 2026 06:15:06 -0000

The incorrect system.h is shown in the asm. This needs to be sorted.

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Fri, 03 Jul 2026 06:13:34 -0000

I meant the last used 4words/8 bytes of program memory read back: 0201 0804 2010 8040 // from DATA block: 1,2,4,8,16,32,64,128 Sending over the serial port and displaying in HEX I get: 01 01 04 04 10 10 40 40 And flipping the order of the same DATA block numbers I get: 80 80 20 20 08 08 02 02 It looks like Programread reads the lower byte, even when it should read the high byte.(?)

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 03 Jul 2026 06:11:07 -0000

Looking at the ASM ( the GCBASIC source compiles here ) you have copied the total contents of the 1606 ZIP file into the correct folders. There are many updated libraries. One is system.h and I can see that you are still using the old one. I have inspected the 1606 zip file and this contains the correct system.h So, update your system with the full contents of the zip to the correct folders. This could be something else wrong but the update will hopefully resolve. Evan Mine ;Source: system.h (5472)...

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Thu, 02 Jul 2026 23:38:51 -0000

Reading the program memory back I can confirm that the right numbers are in there. The last 16 bytes of the program memory: 0201 0804 2010 8040 // = DATA block: 1,2,4,8,16,32,64,128 It looks like Programread only reads the lower byte of the word and ignores the higher byte.(?)

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Thu, 02 Jul 2026 21:47:33 -0000

Ok. So I renamed it gcbasic64.exe and the terminal now says GCBASIC (2026.07.01 (Windows 64 bit) : Build 1606). The output is still the same. Using byte DATA block: 1,2,4,8,16,32,64,128 Sending over the serial port and displaying in HEX I get: 01 01 04 04 10 10 40 40 And flipping the order of the same DATA block numbers I get: 80 80 20 20 08 08 02 02 Also, Trying GLCDPrint (0, 0, myvar), it reults in Syntax Error

Anobium posted a comment on discussion Open Discussion

Anobium — Thu, 02 Jul 2026 20:27:10 -0000

No. 1604 is minimum for Q10 and ProgramRead. The ZIP I post has GCBASIC.EXE for 64bit, so, copy as gcbasic64.exe

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Thu, 02 Jul 2026 20:19:04 -0000

Sigh. I have been testing on: 2026.06.17 (Windows 64 bit) : Build 1603 There was no GCbasic64.exe in the download. I didn't realize that until now. The complier for win11 is the 64bit, right? But 1603 shouldn't work at all with data-block-programread?? -Odd?

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Thu, 02 Jul 2026 19:52:04 -0000

I ran a short running lights test program (with byte, data block). with DATA 1,2,4,8,16,32,64,128 to PORTD, it skips setting PORTD pins 1, 3, 5, 7. with DATA 128,64,32,16,8,4,2,1, it skips setting PORTD pins 0, 2, 4, 6 Sending over the serial port and reading in HEX I get: 01 01 04 04 10 10 40 40 And flipping the order of the same DATA block numbers I get: 80 80 20 20 08 08 02 02 I tried using the SSD1306 GLCD to see the numbers, but I get syntax error on: GLCDPrint (0, 0, myvar). I can't even print...

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Thu, 02 Jul 2026 19:50:03 -0000

I ran a short running lights test program (with byte, data block). with DATA 1,2,4,8,16,32,64,128 to PORTD, it skips setting PORTD pins 1, 3, 5, 7. with DATA 128,64,32,16,8,4,2,1, it skips setting PORTD pins 0, 2, 4, 6 Sending over the serial port and reading in HEX I get: 01 01 04 04 10 10 40 40 And flipping the order of the same DATA block numbers I get: HEX 02 02 80 80 20 20 08 08 I tried using the SSD1306 GLCD to see the numbers, but I get syntax error on: GLCDPrint (0, 0, myvar). I can't even...

Anobium posted a comment on discussion Help

Anobium — Thu, 02 Jul 2026 16:18:23 -0000

The configuration ( not poking about! ) in shown in your ASM. This is the best place to look. This is configured for your chip and therefore works. It is not a case of copying the a-d.h , this is a case of use the ASM produced and copying the required GCBASIC instructions to your program. There will only be a few GCBASIC instructions required. This approach can be repeated across all 1500 microcontrollers. So, look in the ASM at the GCBASIC source added as part of the compilation for a specific ...

Anobium posted a comment on discussion Open Discussion

Anobium — Thu, 02 Jul 2026 16:14:18 -0000

The latest build. https://1drv.ms/u/c/2f87ffe77f3dbec7/IQAUbj0_nkAgS4_E_SW_OYUXAYESWLhomrZDY3GH6YWuYCM?e=yMAOnP It may have issues, but, I have completed hours of tests and there are no know bugs, This has the new Ambiguity Inspection. To enable use the new Prefs Editor.

Roger Jönsson posted a comment on discussion Help

Roger Jönsson — Thu, 02 Jul 2026 16:13:13 -0000

Yes, I understand that the existing sub is poking around with the registers. My question should have been: can I do it using GCbasic commands? (set it off, leave the chip to do its A/D magic and get the output later). Looking at a-d.h I figured it would be too hard for me to distill what I need. My guess is that it would be easier to try to figure out what register settings are needed, throw them in (I guess that is what you call inline code) and see if I can get it to show any sign of life. I will...

Anobium posted a comment on discussion Help

Anobium — Thu, 02 Jul 2026 15:31:14 -0000

All possible. I would rationalise the ADC read ( using the existing sub routine ) but put the code inline to do what you want. Fiddling with registers ( lol ) is what the existing sub does anyway. You are moving from sequencial to inline. All doable.

Roger Jönsson posted a comment on discussion Help

Roger Jönsson — Thu, 02 Jul 2026 14:33:55 -0000

I have an interrupt routine playing back audio from memory to DAC. 18F27Q84. I simultaneously need to sample an analog input with the ADC. I could start it off, do the DAC-stuff and there would be enough delay for the ADC to complete its work without the need for a stand still with AD_Delay. The question is can I do something like this in GCbasic: StartADC - do some other stuff - GetADC or to do this I will have to fiddle with chip registers manually? Not that I absolutely need it now, but it would...

Anobium posted a comment on discussion Open Discussion

Anobium — Thu, 02 Jul 2026 06:18:42 -0000

I will package up 1606 build when a get time today. This has the new Ambiguity inspection ( used the updated Preferences Editor to enable the feature.

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Wed, 01 Jul 2026 19:34:59 -0000

This is itching. Having just received a 18F47Q10 chip I am hoping for a relief by testing the above on hardware. If this is of interest gimme build 1605.

Anobium posted a comment on discussion Contributors

Anobium — Wed, 01 Jul 2026 13:54:33 -0000

This was a little more complex than I thought to add this inspection but it works well. In the 1000s of demos.. there were seven cases when the use of a constant was the same as a register.bit. UP, DOWN, ON, OFFand a few I2c registers. Enjoy this improvement in the quality of the compiler.

Anobium posted a comment on discussion Contributors

Anobium — Wed, 01 Jul 2026 13:50:43 -0000

New: Added EnableAmmbiguityInspection. Compiler will not report ambiguous use of constant when register or register.bit have the same title name. Added to use.ini [gcbasic] EnableAmmbiguityInspection = y ...

Anobium committed [r1896] on Code

Anobium — Wed, 01 Jul 2026 13:29:52 -0000

New: Added EnablAmmbiguityInspection. Compiler will not report ambiguous use of constant when register or register.bit have the same title name.

Anobium posted a comment on discussion Open Discussion

Anobium — Sun, 28 Jun 2026 11:06:07 -0000

I am confident the revised library now supports Q10 with respect to ProgramRead() I have merged back into the main library and it is included in build 1605 or greater.

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 17:22:38 -0000

the problem is that i don't have a dev board with 18F47Q10 to check the test code as it is, i can only test it in the way i already described. And i don't think that the integration of the test code affects it in any way, since everything works perfect, and the only modifications is to add a datablock and a programread command that is activated when a specific I/O address is read (and functionality of I/O reading surely works ok as i use it in many other occasions in the code)

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 17:21:09 -0000

Anobium modified a comment on discussion Open Discussion

Anobium — Sat, 27 Jun 2026 16:09:57 -0000

Yes, this returns a word. The first job is to get the read operation working. Only then would you integrate into an existing program. This is one step at a time. So, please use the test program I provided. We need to know the basics word first. You are asking questions about integration issues, when we dont know the basic operations work.

Anobium modified a comment on discussion Open Discussion

Anobium — Sat, 27 Jun 2026 16:08:24 -0000

Anobium posted a comment on discussion Open Discussion

Anobium — Sat, 27 Jun 2026 16:06:37 -0000

Yes, this returns a word. The first job is to get the read operation working. Only then would you integrate into an existing program. This is one step at a time.

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 15:31:52 -0000

I just noticed at programread() function that the output is declared as word: sub ProgramRed(In EEAddress, Out EEDataWord) Dim EEAddress As Word Dim EEDataWord As Word but all data block elements are bytes and also the call of programread is made using directly an 8bit PORT of PIC MCU as output: programread (@romconf+byte_sel, PORTD) Perhpas this is the problem?

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 15:30:18 -0000

I just noticed at programread() function that the output is declared as word: sub ProgramRed(In EEAddress, Out EEDataWord) Dim EEAddress As Word Dim EEDataWord As Word but all data block elements are bytes and also the call of programread is made using directly an 8bit PORT of PIC MCU as ouput: programread (@romconf+byte_sel, PORTD) Perhpas this is the problem?

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 15:29:38 -0000

I just noticed at programread() function that the output is declared as word: sub ProgramRed(In EEAddress, Out EEDataWord) but all data block elements are bytes and also the call of programread is made using directly an 8bit PORT of PIC MCU as ouput: programread (@romconf+byte_sel, PORTD) Perhpas this is the problem?

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 15:24:06 -0000

I've attached the code i'm using. As already noted, i integrated the programread routine and calling of it, into a very large code which i'm using with an expansion borad connected to an Amstrad CPC, and from Basic prompt i give: PRINT INP(&FBC8) command which should return the value of the 1st element in romconf datablock (line 1208 of gcb code) , and every other PRINT INP(&FBC8) returns the next element.

Anobium posted a comment on discussion Open Discussion

Anobium — Sat, 27 Jun 2026 14:57:14 -0000

post the program. I will put through the debugger.

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 14:04:22 -0000

I replaced the test block with: DATA romconf as byte 1,2,4,8,16,32 end data And the values i get from progread fucntion: 16,0,16,0,0,56

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 13:52:37 -0000

I used a diffrent table, all values are decimal

Anobium posted a comment on discussion Open Discussion

Anobium — Sat, 27 Jun 2026 11:49:44 -0000

I think you have hex and ascii mixed up. 0x31,0x32,0x34 etc

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Sat, 27 Jun 2026 11:45:28 -0000

ok, tried new programread() with 1523 compiler and it brings values that are wrong. With new 1604 compiler still brings values that are also wrong: data[0]: 68 correct value: 33 data[1]: 84 correct value: 92 data[2]: 92 correct value: 192 data[3]: 64 correct value: 17 data[4]: 56 correct value: 80 data[5]: 0 correct value: 67 data[6]: 0 correct value: 1 Also the same worng values i get every time i run the program

Anobium posted a comment on discussion Open Discussion

Anobium — Sat, 27 Jun 2026 10:55:16 -0000

Well ... resolved. The Q10 also uses TBLRD just like the Q43! The difference is it doesn't use NVMCON1 at all for reads. Here's the adapted code is below. This is almost identical to the Q43 block — the only real difference is the #IF BIT(SECRD) guard instead of #IF BIT(NVMCMD0). No NVMEN, no NVMCON1, no NVMADR registers needed at all for reading. The SECRD/NVMCON1 path is only needed for sector-level operations like erase and write ( which was tested/validated). This works in the new debugger. The...

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 16:53:17 -0000

@evanvennn btw, when the new compiler will be official included in gcb installation? The latest "official" compiler is Version: 2025.10.04 (Windows 64 bit) : Build 1523) and the new is Build 1604 which also produces a quite smaller program (~10kb less flash program memory used with build 1604!)

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 16:50:18 -0000

tried it with new 1604 compiler too, same result. I even set byte_sel as byte value, but didn't make any difference...

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 16:50:12 -0000

tried it with new 1604 compiler too, same result. I even set byte_sel as byte value, but didn't make any difference...

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 16:39:30 -0000

tried it, still i get zeroes... Maybe the problem is with chip's data file? I remember that in more than one occasions in the past, the "problem" was peculiarities in Q10 data file...

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 16:37:24 -0000

tried it, still i get zeroes...

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 26 Jun 2026 15:42:36 -0000

I don't think I ever did a full set of demos for the Q10. Why do the demos matter? The demos are reference code that tests many of the library functions. So, no demo = not tested...therefore, may work, may not, may be implemented, may be not. There is zero guarantee that previous libraries or the compiler works with chips that do not have demos. So, as you have learnt... updating libraries is needed when you try an unvalidated capability. There is nothing 'custom'. This is an implementation of a...

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 15:03:58 -0000

btw, when the new compiler will be official included in gcb installation? The latest "official" compiler is Version: 2025.10.04 (Windows 64 bit) : Build 1523) and the new is Build 1604 which also produces a quite smaller program (~10kb less flash program memory used with build 1604!)

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 15:02:58 -0000

btw, when the new compiler will be official included in gcb installation? The latest "official" compiler is Version: 2025.10.04 (Windows 64 bit) : Build 1523) and the new is Build 1604 which laso produces a quite smaller hex file (~10kb smaller flash program memory used!)

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 15:01:12 -0000

btw, when the new compiler will be official included in gcb installation?

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 14:44:03 -0000

@evanvennn so if i get it right, most probable programread needs a "custom" implementation for Q10 series? This remindes me other weird issues we also had in the past (with hw serial port, large tables etc) and in the end, all had to do with the "peculiarities" of the Q10 series (especially in the chip data file) I'm starting to think that the specific Q10 was a bad choice after all... :-)

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 26 Jun 2026 14:07:25 -0000

This could work. Does the set the PORTD ? I cannot test. This has a prototype PROGREAD in the program. The should read the Progmem and set the portD(LEDs?). If you can try then you may get a solution. The is not optimised yet, as when this is working we can optimise to be faster than readtable. Evan #chip 18f47q10 #option Explicit dim byte_sel = 0 Dir PORTD Out DATA romconf as byte 1,2,4,8,16,32 end data repeat 6 programread (@romconf+byte_sel, PORTD) byte_sel=byte_sel+1 wait 1 s end repeat end sub...

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 26 Jun 2026 13:21:23 -0000

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.

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Fri, 26 Jun 2026 13:07:16 -0000

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 modified a comment on discussion Open Discussion

Anobium — Fri, 26 Jun 2026 11:51:30 -0000

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

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 26 Jun 2026 11:39:57 -0000

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 program read 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 EESATAWORD as 0x00 and this should be 33 I can have a look tomorrow morning. Evan

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 26 Jun 2026 11:27:02 -0000

That does not help. Does the basics work?

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 11:15:27 -0000

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...

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 11:14:10 -0000

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 11:12:15 -0000

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 posted a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 11:11:31 -0000

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 what i mention above. In anycase if you want i can give you all the gcb code to check it.

Anobium posted a comment on discussion Open Discussion

Anobium — Fri, 26 Jun 2026 10:46:50 -0000

We need the test code. There are no constraints on using this across any microcontrollers.

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 10:42:26 -0000

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...

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Fri, 26 Jun 2026 10:41:54 -0000

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 alsodeveloped a small "test" function: whenever i give a INP command at specific post 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...

Anobium posted a comment on discussion Contributors

Anobium — Fri, 26 Jun 2026 08:31:26 -0000

Background GCBASIC supports user-defined CONSTANTS, which allow a programmer to assign a fixed value to a named symbol. GCBASIC also supports two directives, #samevar and #samebit, which are intended to resolve the changing nature of the flat Microchip namespace across registers and bits. The problem is that Microchip does not maintain a universally consistent namespace across all microcontrollers. This inconsistency, combined with the way GCBASIC handles #samevar and #samebit, can introduce ambiguity...

Ralf Pagel posted a comment on discussion User Submitted Projects, Demos & Guides

Ralf Pagel — Thu, 25 Jun 2026 11:27:03 -0000

Yes, of course. I would be very happy about that.

Anobium posted a comment on discussion User Submitted Projects, Demos & Guides

Anobium — Thu, 25 Jun 2026 07:03:46 -0000

Great project. I do have the radio clock receiver. I will build this one. May i summarise and put into GitHub?

Ralf Pagel posted a comment on discussion User Submitted Projects, Demos & Guides

Ralf Pagel — Wed, 24 Jun 2026 20:05:46 -0000

Hello, I'm pleased to present a practical application for my suggestion from January 26, 2026. It concerned the display of large digits on an inexpensive LCD2004. The enclosure (124 x 72 x 38 mm) likely comes from China and is offered here by various online retailers under different names (Reichelt: Box4u 4U-120704, Conrad: TRU COMPONENTS TC-7910892). The circuit board and the LCD fit perfectly into the enclosure. Attached are the program, some pictures, and the corresponding KiCad files. Best regards,...

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Wed, 24 Jun 2026 10:30:23 -0000

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...

Anobium posted a comment on discussion Open Discussion

Anobium — Wed, 24 Jun 2026 06:07:36 -0000

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.

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 17:35:06 -0000

Better start testing something simple... Does this work (change to your chip)? #CHIP 18F27Q84, 64 #OPTION Explicit DIR PORTA.5 OUT //***Blinky 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

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 17:34:11 -0000

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 17:28:47 -0000

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 17:28:29 -0000

Better start testing simple... Does this work (change to your chip)? #CHIP 18F27Q84, 64 #OPTION Explicit DIR PORTA.5 OUT //***Blinky 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

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 17:27:11 -0000

Does this work (change to your chip)? #CHIP 18F27Q84, 64 #OPTION Explicit DIR PORTA.5 OUT //***Blinky 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

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 15:47:24 -0000

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.

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 15:34:32 -0000

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

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 12:06:42 -0000

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

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 12:03:34 -0000

No I am not using DMA. Just: Programread(@Sawtooth+SampleNo, SAMPLEOUTbyte) Data sawtooth as Byte 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 End data

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 11:30:37 -0000

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....

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 11:27:39 -0000

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 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....

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 11:19:11 -0000

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 posted a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 11:18:46 -0000

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/Prograread commands require DMA? Because 18F47Q10 doesn't have DMA...

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 10:57:27 -0000

:-)

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 10:56:05 -0000

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 posted a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 10:53:25 -0000

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

ikonsgr74 modified a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 10:51:41 -0000

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%)

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 10:50:40 -0000

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 black 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 modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 10:45:32 -0000

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.

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 10:44:32 -0000

Ok. you found it yourself. Great! I wonder if the info on using ProgRead https://gcbasic.sourceforge.io/help/_data.html is correct or if it is not working for all chips.

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 10:43:12 -0000

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 true for all chips.

Roger Jönsson posted a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 10:41:05 -0000

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

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 10:40:32 -0000

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

ikonsgr74 posted a comment on discussion Open Discussion

ikonsgr74 — Tue, 23 Jun 2026 10:23:47 -0000

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

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 10:22:01 -0000

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.

Roger Jönsson modified a comment on discussion Open Discussion

Roger Jönsson — Tue, 23 Jun 2026 10:21:09 -0000