Wat up with this?

[Pete]

CONST SC.DATA = &H3C5             ' SC Data Register's port

QB64 error: Expected CONST name = value/expresion

Can QB64 not convert that to 965?

I'm posting this, because a member at QBF posted a neat looking mine-sweeper game, all written in QuickBasic, with several expressions like the one above. I no longer have QuickBasic on any of my systems, so I can't check into it.

The full program code is available as a download at: https://www.tapatalk.com/groups/qbasic/minesweeper-duo-quickbasic-4-5-source-and-dos-exec-t39533.html#p212922

There is also a screen shot of the game, on that page.

So incompatibility issue?
 
Pete

[SMcNeill]

Remove the remark and try it.

Edit:  https://www.qb64.org/forum/index.php?topic=1544.msg107691#msg107691

Not sure when remarks became an issue; they work fine still for me, but bplus reported problems with them.

[Pete]

Removed remark but no change. I haven't found a problem with any of my code when I remark CONST statements, so "wat" else you got?

Pete

[bplus]

It's a name conflict with DATA, the following works:

Code: QB64: [Select]

1. CONST SC.DATr = &H3C5
2. PRINT SC.DATr
3.  

[Pete]

Well one Scooby Doo mystery down. Yep, the .DATA isn't accepted by QB64, but I have to assume it was in QuickBasic. Hopefully someone will be able to have that confirmed. I've tried othr keywords with TYPE definitions and they work. I don't think that's good practice, but whatever; .DATA just doesn't cut it.

So the next problem is VARPTR: vPtr = VARPTR(SB) and other statements like it.

Pete

[bplus]

https://www.qb64.org/forum/index.php?topic=455.0

Pete have you seen Terry Ritchie's Minesweeper?

[Pete]

I think I tried that one, but maybe I'm confusing it with the MS version. I so seldom play any games, but I have tried someone's version of Minesweeper.  I've always wanted to make my own version, and call it MimeSweeper. The only differences is, it plays in a box, instead of a window.

Well it looks like Mike is using VARPTR with a TYPE, which may be the problem. There are 5 statements like that I can remark them out, and the program will compile, but it does nothing.

Pete

[bplus]

Terry's was almost complete copy of MS, easy to confuse.

The only tricky part of Minesweeper is the recursive sub that reveals ones and 0's unless you go really fancy.

Do you want to make one for screen 0?

[Pete]

Make one, no. We had this one posted as a .rar file, with QuickBasic source included: https://www.tapatalk.com/groups/qbasic/minesweeper-duo-quickbasic-4-5-source-and-dos-exec-t39533.html#p212924

I can't get it to run in QB64. You figured out QB64 won't except .DATA as a type. Changing it to .DATr worked perfectly, as expected; however there was one more problem. It involves an another apparent incompatibility with another TYPE variable, which is used with VARPTR. Here is the part of the code where VARPTR throws errors...

Code: QB64: [Select]

1. SELECT CASE selector
2.         CASE "SB"
3.             vSeg = VARSEG(SB)
4.             vPtr = VARPTR(SB)
5.         CASE "JOY"
6.             vSeg = VARSEG(joyCfg)
7.             vPtr = VARPTR(joyCfg)
8.         CASE "ENGINE"
9.             vSeg = VARSEG(engine)
10.             vPtr = VARPTR(engine)
11.         CASE "GAME"
12.             vSeg = VARSEG(game)
13.             vPtr = VARPTR(game)
14.         CASE "TEMP"
15.             vSeg = VARSEG(tempCfg)
16.             vPtr = VARPTR(tempCfg)
17.         CASE ELSE
18.             IF (LEFT$(selector, 6) = "PLAYER") THEN
19.                 id = VAL(RIGHT$(selector, LEN(selector) - 6))
20.                 vSeg = VARSEG(player(id))
21.                 vPtr = VARPTR(player(id))
22.             ELSE
23.                 INI.getPointer% = 0
24.                 vSeg = 0
25.                 vPtr = 0
26.             END IF
27.     END SELECT
28.  

Of those statements, the VARPTR(player(id)) IS accepted. It is a DIM array, while the others are all declared TYPE variables; so again, I suspect it is something about the TYPE variables used with VARPTR that QB64 won't accept. The error message is interesting: "Compiler error (check for syntax error) (Reference:18980).

I'll elaborate a little more on the first error, vPtr = VARPTR(SB). I noted Mike used: DIM SHARED SB AS SBStruct and then used SBStruct as a TYPE...

Code: QB64: [Select]

1. TYPE SBStruct ' SOUNDBLASTER CONFIGURATION
2.     BasePort AS INTEGER ' 2 - SoundBlaster base port
3.     LoDMA AS INTEGER ' 2 - SoundBlaster Low DMA
4.     DMAMask AS INTEGER ' 2 - DMA Mask index
5.     DMAMode AS INTEGER ' 2 - DMA Mode index
6.     DMAClear AS INTEGER ' 2 - DMA Clear index
7.     DMAStatus AS INTEGER ' 2 - DMA Status index
8.     DMAPage AS INTEGER ' 2 - DMA Page port
9.     DMAAddr AS INTEGER ' 2 - DMA Address port
10.     DMALen AS INTEGER ' 2 - DMA Length port
11. END TYPE

I've never use VARPTR statements in QB or QB64, and I only recently started using TYPE statements, other than in some old QB mouse routines. Maybe you or someone else would be familiar enough to figure out what the incompatibility is. I would think that if the errors in VARPTR in the code posted above could be corrected, Mike's QuickBasic coded Minesweeper game should run in QB64.

Pete

[Petr]

Pete, in your link miss QB.BI file, wchich maybe contains RegTypeX TYPE (Row 13 in source code msduo.bas)

[Cobalt]

I didn't think we could use the INTERRUPT stuff from QB45 anymore? Not sure just what VARPTR and VARSEG are going to be able to do in QB64 either, as the memory they use is simply emulated(I believe). VARPTR points to a specific area in a VARSEG memory area.

DIM Test(1024) as INTEGER

Seg&=VARSEG(Test(0))
Ptr&=VARPTR(test(256))

so the memory segment is for the array Test
and the pointer is set to the 256th element of Test

Granted its been over 12 years since I've really put work into anything with QB45 so my memory is not super in that area anymore but I believe thats how it worked. And to use the INTERRUPT code you have to be able to use the QB library from 4.5 which we cannot in QB64. So my hunch is to convert that game to QB64 will require a large amounts of recodeing, probably making it more reasonable to just make a whole new game rather than try and convert that one.

[OldMoses]

Well one Scooby Doo mystery down. Yep, the .DATA isn't accepted by QB64, but I have to assume it was in QuickBasic. Hopefully someone will be able to have that confirmed. I've tried othr keywords with TYPE definitions and they work. I don't think that's good practice, but whatever; .DATA just doesn't cut it.

I ran into the same issue running someone else's older program. It would seem that QB64 prefers that you talk to it in an Appalachian accent.

[Pete]

Ah,  Smoky Mountain English. Right up Steve's alley, and then hang  quick right.

Pete