Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Pete on July 31, 2019, 09:43:33 pm

Title: Wat up with this?
Post by: Pete on July 31, 2019, 09:43:33 pm
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
Title: Re: Wat up with this?
Post by: SMcNeill on July 31, 2019, 09:46:38 pm
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.
Title: Re: Wat up with this?
Post by: Pete on July 31, 2019, 10:03:02 pm
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
Title: Re: Wat up with this?
Post by: bplus on July 31, 2019, 10:19:37 pm
It's a name conflict with DATA, the following works:
Code: QB64: [Select]
  1. CONST SC.DATr = &H3C5
  2. PRINT SC.DATr
  3.  
Title: Re: Wat up with this?
Post by: Pete on July 31, 2019, 11:26:38 pm
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



Title: Re: Wat up with this?
Post by: bplus on August 01, 2019, 12:04:44 am
https://www.qb64.org/forum/index.php?topic=455.0

Pete have you seen Terry Ritchie's Minesweeper?
Title: Re: Wat up with this?
Post by: Pete on August 01, 2019, 01:20:17 am
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
Title: Re: Wat up with this?
Post by: bplus on August 01, 2019, 09:02:48 am
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?
Title: Re: Wat up with this?
Post by: Pete on August 01, 2019, 11:35:14 am
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

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
Title: Re: Wat up with this?
Post by: Petr on August 03, 2019, 02:07:53 pm
Pete, in your link miss QB.BI file, wchich maybe contains RegTypeX TYPE (Row 13 in source code msduo.bas)
Title: Re: Wat up with this?
Post by: Cobalt on August 03, 2019, 04:26:39 pm
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.
Title: Re: Wat up with this?
Post by: OldMoses on August 03, 2019, 11:24:18 pm
Quote from: Pete on July 31, 2019, 11:26:38 pm
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.
Title: Re: Wat up with this?
Post by: Pete on August 04, 2019, 12:21:45 am
Ah,  Smoky Mountain English. Right up Steve's alley, and then hang  quick right.

Pete
Text Only | Text with Attachments