The future of 'BBC BASIC for Windows'

[Hated Moron]

I'm awaiting with interest feedback from DDRM and hellomike on their progress.

With nothing heard from either I suppose we must conclude that this work has been abandoned (if indeed it was ever started), which is a great shame.

Is anybody else interested in attempting to port some or all of the WINLIB? libraries from BBC BASIC for Windows to the Windows edition of BBC BASIC for SDL 2.0 (initially 32-bit only)? With so little known about whether this is likely to be easy, difficult or impossible, the only way to find out is to try it.

As I've said before I'm more than happy to give what assistance I can should progress get stalled by an intractable problem, but I'm not in a position to do all the work myself.

[JeremyNicoll]

With nothing heard from either I suppose we must conclude that this work has been abandoned ...

We are right in the middle of the summer holiday season. Maybe they're too busy doing other things?

[Hated Moron]

We are right in the middle of the summer holiday season.

Summer holiday season? You do know what the weather's like in the UK at the moment, I suppose?!

Being serious, it did occur to me that they might be out of email/forum contact, but if my experience is any guide the one thing you can guarantee is that people make sure they can still access the internet at all times and in all places! So not even being in a position to say "Sorry, I'm away at the moment and will report when I get back" is a pretty remote possibility in every sense.

[hellomike]

Today I read the whole "The future of 'BBC BASIC for Windows'" thread again. What progress is expected from me, i.e. did I offer in porting delivered BB4W libraries into BBCSDL format/functionality?

Please elaborate.

Regards,

Mike

[Hated Moron]

Please elaborate.

This: "I have questions and during migrating certainly new ones will arise. It will be a valuable source (group) and in my opinion making it easier to start or consider starting, migrating all (my) BBC4W code to BBCSDL".

And this: "For the time being, any migrating questions / issues I will put in the 'Desktop platforms and IDEs' folder".

If you are no longer planning this migration, fair enough.

Incidentally I found this comment from a Microsoft 'independent advisor' in 2019, which states "There are so many 32 bit apps that I don't expect it to be discontinued any time soon".

What I would say, though, is that this was only his personal opinion and the "so many 32-bit apps" remark applied just as much to MacOS and to Android, yet they either have removed, or are in the process of removing, 32-bit support.

[DDRM]

Hi Richard,

Actually, I HAVE been out of email contact for much of the last week, bobbing around on the Broads (not far from your neck of the woods, I think!).

As I said in a PM, I'll have a look at one or more of the Winlib libraries over the next month or so, and see if I can make some progress.

Best wishes,

D

[Hated Moron]

Actually, I HAVE been out of email contact for much of the last week, bobbing around on the Broads

I would have hoped you might get 4G data coverage there. The last time I was unable to connect to the internet for an extended period was on a cruise ship, in a part of the world poorly served by satellite connectivity. But coverage (and speed) is improving all the time.

I' like to think I can cope better without internet access than many of the younger generations could, but to be unable to check email for several days would be quite anxiety-making. Of course you probably have family and/or friends as a distraction, something of which I have no experience.

[hellomike]

Currently I'm trying to port one of my own BB4W libraries to BBCSDL and.... it is time consuming.

There is the filename issue for which I made a post and now I constantly run into the No Room message, probably because I use Windows API like:

Code: Select all

      SYS "GlobalAlloc",64,n% TO ptrblk%

Yesterday I made an attempt to change all address-related variables to 64 bit so the line now reads:

Code: Select all

      SYS "GlobalAlloc",64,n% TO ptrblk%%

But still the No Room message.

Any suggestions where to look anyone?

Thanks

Mike

[Hated Moron]

But still the No Room message.
Any suggestions where to look anyone?

Are you still struggling with this? I would not have expected a program ported from BB4W to BBCSDL to report 'No room' messages.

As I have explained, the 32-bit x86 editions of BBCSDL (Windows and 32-bit Linux, principally) use pretty much the identical interpreter to BB4W, including the assembler. I would expect code which is not OS-dependent to run exactly the same, without any modifications at all.

The only thing I can think of which might, conceivably, be the cause is the way memory is allocated. This is different between BB4W and BBCSDL, so the absolute addresses of memory areas (BASIC program, variables, heap, stack etc.) may be significantly different.

If your code has a bug which makes it dependent on absolute memory addresses in some way, perhaps that might be responsible.

Please keep us informed of progress because I am very concerned than an impression is being given that porting programs from BB4W to BBCSDL is difficult. This should absolutely not be the case, unless the program interacts with the OS in some way which makes it incompatible with BBCSDL.

There's little more I can do to dispel that impression, other than reiterating what I genuinely believe and is borne out by my own experience.

[Hated Moron]

On 23/08/2023 18:10, stevef@sensigent.com wrote (cross-posted from the Discussion Group):

It has been years so I can't recall any details but I had the same No Room message and after looking over the memory map solved it with this statement near the beginning of the program:
HIMEM = PAGE+200000000

It's true that whilst BB4W (v6) provides up to 512 Mbytes of heap memory (if you are lucky) BBCSDL provides no more than 256 Mbytes. So if you attempt to raise HIMEM by an amount between those values (say 300 Mbytes) then the program will most likely run successfully in BB4W but will definitely fail with a 'No room' error in BBCSDL.

But if that was the cause of the OP's problem the program would fail at the very beginning (since raising HIMEM can only be done when the stack is not in use) and it would be totally obvious. Indeed I suggested that he renumber the program and run it in TRACE mode, so it would produce an output like the screenshot below, which would be a giveaway.

I should add, whilst we're on the subject, that allocating either 512 or 256 Mbytes is conditional on that amount of contiguous virtual memory being available. There is no guarantee of that so you shouldn't do it unless you absolutely have to.

noroom.png