QB64, QB4.5, assembler: open talk

[NOVARSEG]

@George McGinn


I came across QB64 some months ago. It resembles QB45 in some ways but with more features.  I still like to program with QB45 and A86 assembler.  The only problem is QB45 programs won't run on new OS es

[George McGinn]

I haven't programmed in QB45 since the 1990's.

If you are used o QB45 and/or QBasic, you will find a lot is the same here, except for the advancements in the language over the years. I mostly program in Linux and macOS (I don't have a Windows install) and I love QB64. I wish QB64 was also on mobile devices. There I use TechBASIC, because my second computer was an Apple IIGS, and I programmed in GSoft BASIC. TechBASIC is GSoft BASIC, written by Mike Westerley, whom I do work closely with, even today.

I am working on converting a game (Roulette) I wrote in QB45 to QB64. It sold as shareware from 1991 to 2000.

Back then I even had to check whether or not a person was using a monochrome or color monitor/TV. So far that code works fine in QB64.

I did have issues trying to remove DEFSNG and DEFDBL statements, probably because back then Functions, like in QB64 could be defined as STATIC.

So when I post it, it will still have some QB45 conventions, but QB64 handles them very well.

Good luck with QB64. I find it just as feature-laden as PowerBASIC, who I also worked with the late Robert Zale, who developed it. Since it's written in Assembler, I did some work form him on various versions (we both live in Venice, Florida). Robert had no interest in porting it to MAC or Linux. I even wrote corporate applications in it. Now I use QB64 and PYTHON as needed.

If I can help, let me know. I may have senior moments, like with the FONT issue I screw up on, but every programmer, hobbyist or professional has them!

George.

@George McGinn


I came across QB64 some months ago. It resembles QB45 in some ways but with more features.  I still like to program with QB45 and A86 assembler.  The only problem is QB45 programs won't run on new OS es

[NOVARSEG]

@George McGinn


Like so many, we all seem to go through the computers of the day.  My first computer was a TRS 80 with 48k ram. It had Zilog chips. It came with BASIC 80 and I think it had dual sided floppies of 160Kb per floppy.  Very primitive but fun.  spent some time with GW basic and then Quick Basic v4.5.  Finally got into A86 assembler and for a while thought it was the ultimate until XP was discontinued and so these ancient 16 bit programs would not run on other OSes.

Even so 16 bit programs can run on Qb64 with a little work but the problem is that all of my 16 bit programs made heavy use of the DOS interrupts (INT21h etc) and these interrupts are not supported in any modern computer.  What we have instead is Windows API which to me is REALLY complex stuff and I don't want to invest the time need to become good at it.

For example: to find out how to  READ  a file using API go to
  https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile

For anyone to learn this API properly,  they must spend, say, at least 100 hours to research all the links - and there are MANY of them and each link leads to 10 others!.

Now compare this to  http://www.ctyme.com/intr/rb-2783.htm

So which is easier to learn?

One might argue that WIN API is complex because OSes have grown complex but I'd take

http://www.ctyme.com/intr/rb-2783.htm

any day for something as simple as a file read.

[SMcNeill]

OPEN file$ FOR INPUT AS #1
DO UNTIL EOF(1)
    LINE INPUT #1, text$
    PRINT text$
NEXT

Not much simpler than that and no interrupts are required.

[NOVARSEG]

QB64 makes it easy to do that.   

Just thought of something.  Instead of spending 10 years to learn WIN API, I should spend that time learning how to design CPU chips and make a programmer friendly CPU.

What would happen if

protected mode and privilege levels were eliminated?

What would happen if all memory protection schemes were removed

SSM ram gone

no ring -2

no vendor specific templates allowed.

[SMcNeill]

QB64 makes it easy to do that.   

Just thought of something.  Instead of spending 10 years to learn WIN API, I should spend that time learning how to design CPU chips and make a programmer friendly CPU.

What would happen if

protected mode and privilege levels were eliminated?

What would happen if all memory protection schemes were removed

SSM ram gone

no ring -2

no vendor specific templates allowed.

What would happen is someone’s cat would access their memory, corrupt their data, and launch nuclear missles and destroy the world.

[George McGinn]

If you do that, you'll have more issues than making it programmer friendly.

For example, us Assembler programmers would probably lose access to all those interrupts and memory addresses we use so much. Also registers may become useless.

Any changes to the chip must be also changed in the assembler language used, which is why assembler is CPU specific.

Anyway, API's are also part software, so any chip change also changes the API, and that is what gives programmer's headaches when their code that ran for 5 years suddenly stops working.

It is a nice thought, and if it can be done without impacting many 4GL languages, all the better.

In 1999-2000 I led the team that ported a mainframe batch system for Verizon to run on Dell Servers, and I had Micro-Focus change their COBOL compiler to become ISO compliant and robust enough to handle the processing. Instead of using API's, I wrote inline assembler routines instead. This way, if the hardware changed, minimal needed to be done to the source.

George

QB64 makes it easy to do that.   

Just thought of something.  Instead of spending 10 years to learn WIN API, I should spend that time learning how to design CPU chips and make a programmer friendly CPU.

What would happen if

protected mode and privilege levels were eliminated?

What would happen if all memory protection schemes were removed

SSM ram gone

no ring -2

no vendor specific templates allowed.

[NOVARSEG]

Instead of using API's, I wrote inline assembler routines instead. This way, if the hardware changed, minimal needed to be done to the source.

There is some use for inline assembler in QB64.

Custom operations on variables and strings

interfacing with hardware and peripherals like raspberry pi,  arduino

proprietary code for secure communications

A simple example

DIM A AS LONG

A = 1000000

'****
'mov eax, [A]
'add eax, 1

'mov [A], eax

'****

PRINT A

Evidently C++ can implement inline assembler   https://en.wikipedia.org/wiki/Inline_assembler

but no mention is made of the usual linking of ASM object files with C++ object files

It might take a pre-parser to it properly. I wrote one to implement the IF  END IF construct into A86.   The hard part is to get this to work with the QB64 compiler.  Im not sure if it uses a linker.

[SpriggsySpriggs]

I think we've discussed inline code for C++ and things like that before in the past and we decided against it.

[NOVARSEG]

Well I did not start this thread  (Im not sure who did)  It is just talk nothing definite.

[SpriggsySpriggs]

@NOVARSEG It shows that you started the thread lol. Anyways, you guys are talking about file I/O? The way Steve showed is really the only way that you would want to read a file in QB64 unless (and I say this with quite a large sum of emphasis) you absolutely require file pointers and things like that. No need to complicate things by using the WinAPI to read a file.

[George McGinn]

I responded to a post that got moved here. I though I was responding to something in "Using the embedded icon handles in programs".

While it would be nice to have inline assembler, the QB64 developers would have to code their own version of a watered down assembler, or use the assembler for each specific machine (not necessarily each OS). The CPU chip determines the assembler, not the OS.

I understand why SpriggsySpriggs and other developers are not considering it.

And in-line assembler is used for more than just file I/O. Say you need access to flat memory or protected mode? Or the BASIC syntax isn't up to the job or the structure isn't suitable for your task, such as the discussion we had last night where I would like FLOOR function that does not exist, or I want to change the INT function to not round up using the decimal places; or I need to modify registers, store data in specific memory addresses; do real bit processing. And there is plenty more including manipulating the stacks, including the FPU (Floating Point Unit or co-processor).

PowerBASIC in Windows has inline assembler, and the late Robert Zale, who created PowerBASIC, loved or hated me sometimes because I found bugs in that part. I wound up contracting for him in new development, as the entire product is written in assembler.

I don't expect in-line assembler in QB64, as it would be a tough and even radical departure for its architecture. And you can damage your CPU if you are not careful!

My comments were more like a dream. You know, if only if....

George.

[bplus]

The CPU chip determines the assembler, not the OS.

That is good to know, thanks!

we had last night where I would like FLOOR function that does not exist, or I want to change the INT function to not round up using the decimal places; or I need to modify registers, store data in specific memory addresses; do real bit processing.

When does the INT function not round down in QB64? Ans: Only when it is an integer.
QB64 has _CEIL if you want to go the other way.
And it has _ROUND if you don't know which you want LOL

Probably not as fun because not as fast but you could build something that works like Assembler or heck, go to Assembler forum, if you have such a hankering ;-))  I know you would miss the ease and wonderful IDE QB64 has. :) Syntax checking, OK? How can you resist ;-))

If you know C well, I bet you could build a library for Assembler, oh but all those different CPUs, oh well...

[George McGinn]

I don't plan on going anywhere, as QB64 is the BOSS on Linux.

If I need to use assembler, I'll create a BASH shell program, execute what I need, write it to a file, the have my QB64 program read the results and continue processing.

Fillippe said that the INT works the same way that it did in QB45 and even Visual BASIC (Both Microsoft products) and in other languages, including TechBASIC on iPads, INT only gives the integer part of the number, which is why I mis-understood how INT works in QB64. We did have a great discussion where I learned a lot about the internal workings of QB64, something I needed.

Besides, Fillippe just showed me how to use the C++ FLOOR and I'm back in business.

I have plenty to do without having to write my own inline assembler, so I will continue to write using multiple languages as needed. If I need really fast performance, I am more likely to write that in Fortran. (I run the latest Ubuntu Linux distro)

George.

That is good to know, thanks!

When does the INT function not round down in QB64? Ans: Only when it is an integer.
QB64 has _CEIL if you want to go the other way.
And it has _ROUND if you don't know which you want LOL

Probably not as fun because not as fast but you could build something that works like Assembler or heck, go to Assembler forum, if you have such a hankering ;-))  I know you would miss the ease and wonderful IDE QB64 has. :) Syntax checking, OK? How can you resist ;-))

If you know C well, I bet you could build a library for Assembler, oh but all those different CPUs, oh well...