Is there anything quite tied/geared to the internals of the system for rasp pi in the same manner as say C64 Basic was? Or does that sort of concern not really matter for today’s CPUs/hardware/aarch?
I’m not really a programmer. The reason I ask is for my 11 yr old to hack around, should I find/use a modern (or if not modern, updated, as you indicated BBC is) Basic like the one you linked, or should I have the kid just do cool stuff and basic stuff inside a C64 emulator on the Pi such as Combian64 etc?
Somebody else brought it up in a separate comment, but because you specifically ask about the Raspberry, I'll mention EndBASIC (https://www.endbasic.dev/) here again :)
Supporting this platform is an ideal goal of the project, and in fact, one of the features (GPIO) only works on the Raspberry Pi today :) But there is a long road ahead to fulfill the promise. My vision is to create a minimal Linux image that boots straight into EndBASIC, and extend EndBASIC to give you more control of the Pi's hardware. The idea is to truly mimic the old C64 experience, but leveraging the power of modern hardware / infrastructure.
Sounds awesome, that would be super cool! I’ll check out endbasic as it is currently which should suffice quite nicely as is for the environment I’m looking for..
It's not exactly what you're asking, but a few years ago I revisited the Spectrum programming of my youth in an emulator using modern editors and assemblers etc outside the emulated hardware. The emulator could pause and trace all the memory locations live which made debugging great.
It was a way easier, more fun and productive experience than doing it for real on an 8bit machine was back in the day.
I understand that "ARM BASIC V" was embedded in the Archimedes in ROM.
If an ARM processor still supports the original 32-bit instruction set, then (I understand) that this version should run on it, to the point of this being an important compatibility test for alternate implementations of the instruction set.
> Is there anything quite tied/geared to the internals of the system for rasp pi in the same manner as say C64 Basic was? Or does that sort of concern not really matter for today’s CPUs/hardware/aarch?
The "Lite" version of RpiOS is probably the closest you'll get. It just boots to the command line. Of course you could use any version of RpiOS and disable boot to GUI in raspi-config to get a similar effect.
RISC OS doesn't support Wifi or >1 CPU, and it is a 32-bit OS with no 64-bit support (yet).
It's the original native OS for the ARM family, designed by some of the same team who designed the ARM processor at Acorn Computers.
It's FOSS now and has been modernized a lot, but at the core, this is a multitasking GUI OS hand-coded in Arm assembly language by a team of about 6 people -- most of whom I interviewed a year or so back:
In 1987 it originally fit entirely into and ran from 512KB of ROM on the Archimedes computer, and ran in 512KB of RAM. The later RISC OS 3 needed 2MB of ROM.
Even now, the core OS fits into about 6MB. That's not the kernel, that's the whole OS, filesystem, GUI, network stack etc.
It is a late-1980s OS, older than Windows 2.0, or MS-DOS 5.0, or NeXTstep. It is almost incomprehensibly tiny by modern standards.
It's a really hard question. The program is not anywhere as close to the hardware as the original would have been, but is it the right place to start? I think you may want to offer a variety of things and see which is the most interesting.
Personally I'd love to have a nice 386 with some hardware to play around with, but then again, that's what I learned on.
As i mentioned in the other thread about VB6, this is not the only attempt and there have been several at the past, going back to when Microsoft was still working on classic VB (the oldest i know of is a VB4 clone) - and all of them had something common: they were not open source and because of that they died.
IMO it is the biggest of follies to consider a proprietary classic VB clone considering that the only reason VB6 died was exactly because its developer decided to stop working on it - it wasn't due to lack of money (Microsoft wasn't broke) or popularity (AFAIK TIOBE had it at #1 at the time and for a long time after that), it was plainly because the only one in control was Microsoft and since it was a deeply proprietary product nobody else could do anything about it (aside from making useless polls that were obviously ignored).
I remember VB was also a bit of a casualty of the move to the .NET framework. Yeah they had later versions of VB with .NET support but it still never really embraced or thrived in the new ecosystem. In general RAD tooling kind of fell out of favor in the 2000s and never really recovered.
Over the last 40 years I have programmed in practically every major language, yet VB.Net remains my all-time favorite for ease of development and code readability.
I would still be writing in it today but there is really zero support now. A real shame.
Interesting justification for their subscription model [0]:
> Naturally, developers benefit from the subscription model by having a more regular income, but customers also benefit because they hold more power over the developer to fix bugs and provide regular updates in mind of you keeping your repeat subscription active.
I'd love to learn of cases for subscription software where subscribed customers were able to successfully pressure a developer to fix bugs by threatening to not resubscribe. Wouldn't bug and feature bounties be a better solution, if indeed empowering customers is the true reason for subcriptions?
I can see how subscriptions might be good for the subset of customers for whom it is easier to use opex funds to subscribe, rather than capex funds for perpetual licenses. It can be the difference between simply submitting a expense report versus going through a months-long series of committee meetings.
>We appreciate that some customers would much prefer a perpetual licence, but to ensure the longevity of this project we ask you to kindly accept the subscription model that we've designed to accommodate our current and future needs.
Shouldn't that be "we kindly ask" ? (a customer should be free to - say - "grudgingly accept").
I think it makes sense as written. They're saying you are being kind if you accept it (even if you accept it grudgingly). "We kindly ask" would imply they are being kind by asking (they may want to try to be kind while asking, but I don't think that's achieved just by saying so).
I'm a nonnative speakers of English although I moved to the US just in time for Kindergarten. Never spoke English at home though.
I still commonly invert word orders like this at 38 years old. Around 25 years old I realized I did it, and am more conscious of it. But I almost do it on purpose now to get people to pay attention more. My justification is "it makes them think a bit!" And I believe that's good for both parties.
I don't know, I am dubious as - AFAICT - "kindly accept" is used (and makes sense) for something that is given to the person, like apologies, a present, an application.
In the context of asking to accept a (imposed as there are no alternatives) licensing model and a fee it sounds to me "strange".
no, "kindly accept" basically means "be so kind as to accept". even disregarding the idiomatic nature of the phrase and just looking at "kindly" as an adverb, grammatically when you say "we ask you to kindly accept" the person being asked is the source of the kindness, and the person doing the asking is the recipient. "kindly ask" does not make much sense, since you are not being kind by asking for something.
I (author of EndBASIC) have been busy with other stuff since this made the front page last time and have not had a chance to touch the project for the last few months, but I do still have plans to grow it.
Just earlier today, and out of coincidence, I added "email subscriptions" to the front page of the project -- just in case any of you want to get notified when a new release comes out :) If you /do/ subscribe, you may get... 2-3 emails a year, and help me gather how many people actually care about this.
It's very cool, although my first BASIC was QBasic from DOS 5.0, so this is more "primitive" than what I remember BASIC being. Keep up the awesome work.
I have great memories of that machine.
Somehow I've got the "Ready" prompt from Locomotive basic etched in my brain.
I even tried to code in Z80 assembler (took an ethernity to load from tape, and hanged the computer if you did it wrong - which was usual).
It's great to see someome doing side projects just because they want, not as a way to make some business on the side.
Looks like there's a free community edition that is mostly feature complete other than only supporting unoptimized 32-bit Windows builds. That should be plenty for a hobbyist to get started. I haven't tested it, but I wouldn't be surprised if the output binaries worked under Wine as well.
hobbyists would likely use something like gambas, where they don't need the 100% vb6 compatibility. this seems more targeted to businesses who want actual vb6 code to run.
The whole point of TwinBasic is that it's to be 100% compatible with VB6 and with VBA.
From that standpoint there's no point comparing it with BBC Basic, Powerbasic, Freebasic, vb.net, purebasic, Xojo or gambas because none of those are in that space.
I'd like to hear more about who twinbasic expects to appeal to and why those people would want it?
Well there's a small but significant community of hobbyists still using it for... we're enthusiastic about it to be subscribing already well it's still in beta to support it.
Lots of businesses still have critical line-of-business VB6 code and can't afford or have other issues with the total rewrite required to move anywhere else.
And one thing almost every commenter who thinks there's no market is overlooking: VBA. VBA is still huge in the business world. 64bit Office has become the default, but if you want to create active-x controls for it? Your options are... nothing without using a whole different language, usually C++. tB already has initial support for creating 64bit controls that can be used in Office VBA (and any other COM host including .NET, on top of being able to compile to 32bit for VB6 if so desired). There's a number of bugs to work out, but I've gotten some of my very complex controls running. Then you can also make VBE addins. All with the same VBAx64 syntax and language features you're used to with dozens of new ones.
.net vb is a completely different language with a completely different set of capabilities. It can't compile VB6 code. There is a lot of legacy VB6 code out there.
https://www.bbcbasic.co.uk/index.html
The Windows version is a £25 purchase, but the SDL and command-line versions are gratis. It's a great language for hacking around on a Raspberry Pi.