QuickBASIC to QB64 Conversion Challenge!

[Pete]

A member over at QBF posted this neat minesweeper clone, all in QuickBASIC. He has a unique coding style that involves directly storing variables in memory. Check out the code, it's pretty cool. Anyway, thanks to Mark (BPlus) I got past one compatibility in the fact that QB64 doesn't allow a TYPE made with .DATA, so we changed that to .DATr. I found another incompatibility, where changing a DIM to a REDIM got rid of a duplicate definition error. The one remaining problem is with a DIM TYPE, that is used in 5 VARPTR statements. If anyone can figure out a way to get those working, the code will run.

Here is a link to the code. I've included the QB.bi file in the code, so nothing else to download. Due to forum space restrictions, you will need to copy and paste the entire program from 3 code reply blocks, in that order, into your IDE.

https://www.tapatalk.com/groups/qbasic/viewtopic.php?f=648955&t=39534&p=212932#p212932

Here is some more info in these threads. One includes a screenshot of the program...

https://www.tapatalk.com/groups/qbasic/minesweeper-duo-quickbasic-4-5-source-and-dos-exec-t39533.html#p212930

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

... or maybe this is something that could be further added to QB64, as a QuickBASIC compatibility modification. Any thoughts?

Pete

[bplus]

Variable Pointers seems like something Steve might know something about. I'd be interested in his thoughts about VARPTR of Type variables.

[Pete]

I think everyone, including Fell, is stumped on this one. I seldom see Luke around, and I have no idea if he ever worked with VARPTR in QB. I have not, and I don't even have QB anymore. My hunch is this is something Rob never came across, and didn't code for it.

If wiki work around here is going to pick up, it would at least be nice to lit this along with the few other incompatibilities in QB to QB64. Now _MEM... statements should be able to replace the VARPTR ones, but I don't know if anyone here, other than Steve, uses those enough to see a way to make that substitution in a rather complex program.

I have to play the pessimism card here. I don't think anyone will be able to stand up to this challenge, including me.

Pete

[SMcNeill]

I was looking at VARPTR earlier, and it’s not readily swappable with _OFFSET or _MEM.

VARPTR points to a spot in cmem (basically a QB64 Array, where QB64 tries to emulate conventional memory for PEEK/POKE access), and not to the actual position of where that spot is in memory. 

A = 100
PRINT VARSEG(A) * 256 * 256 + VARPTR(A)
PRINT _OFFSET(A)

I’d always assumed those 2 would give us the same value in a 32-bit version of QB64, but they point to two different spots in memory.

User Defined Type variables don’t seem to go into cmem(the emulated conventional memory), which VARPTR points to; instead, they’re just handled in “normal memory”, with _OFFSET values...

....

At least that’s my take from my preliminary digging into the issue earlier.  If somebody knows otherwise, kindly correct me on the issue. 

[TempodiBasic]

Hi guys
just a first question...
Does It work on Windows 10 with DOSBOX?

[luke]

I have used QB's VARPTR/DEF SEG/CALL ABSOLUTE stuff before. How much of it I remember is another matter.

Even after brushing up on it, I'd say it'd be easier to just rewrite the sections wholesale than try and fix it surgically. In any case you'll have to deal with the rest of the program that's basically a pathological case of non poortable QB code: EMS, Sound Blaster, etc.

[TempodiBasic]

Fine english joke of pronunciation

poortable  vs poor portable

Just about EMS I don't know if it is possible under Windows because I remember it in OldDOSDays to expand ram use.
So the use of soundblaster and RAM Iin windows10 I think it needs of DirectX or another library for graphic ram and sound.

But that are all void words if it runs under DOSBOX.

so....I'm waiting

[Cobalt]

I have used QB's VARPTR/DEF SEG/CALL ABSOLUTE stuff before. How much of it I remember is another matter.

Even after brushing up on it, I'd say it'd be easier to just rewrite the sections wholesale than try and fix it surgically. In any case you'll have to deal with the rest of the program that's basically a pathological case of non poortable QB code: EMS, Sound Blaster, etc.

I'm with Luke on that, it would probably make more sense to rewrite the program than try and convert that. My work with DirectQB required lots of VARSEG and VARPTR use and I was fairly proficient with it but after 12 years or so.. ehhh. Its one thing bringing back some older BASIC code by the likes of David Ahl and the early magazine examples, but when you start getting into things that require DOS level access, like QB45s INTERRUPT code, it becomes less viable.

[TempodiBasic]

You can agree that some kind of access and use of hardware is limited by Windows and not by the compiler.
There are simpler ways build in QB64

[Pete]

This takes me back to the days of hearing about Ralf Brown's interrupt list. I know Rob worked out the mouse for call interrupt, which I believe uses EMS, whereas call absolute mouse routines were not supported, and I believe they use XMS.

Well, I guess this one is a no-go, but thanks for PEEKING into it, guys.

Pete