I’ve found this interesting: a modern computer that is programmed in BASIC. It is amazing how fast the interpreted BASIC is running (when comparing with computers from the 80ies - early 90ies).
The Colour Maximite 2 is a small self contained computer inspired by the home computers of the early 80’s such as the Tandy TRS-80, Commodore 64 and Apple II.
It uses a USB keyboard and outputs to a standard VGA monitor. Programs are saved on a full size SD card and it includes its own sophisticated BASIC interpreter with a full screen program editor.
The Colour Maximite 2 is designed to be to simple use, easy to program and provide endless hours of fun.
personal use only and cannot be reused for commercial purposes
And immediately they’ve contradicted themselves. Always a good start…
cannot be redistributed (modified or not)
In other words, if you fix a bug or modify the code in any way you can’t even share it with your friends,
which defeats the point of making the code available in the first place.
It wouldn’t be quite as impressive but getting BASIC working on the Pokitto probably wouldn’t be that difficult depending on how many instructions needed to be supported.
Ok, I was trying to answer the question “is it debuggable” by @HomineLudens
To me “is it debuggable” = “can I stick a hardware debugger in and step through instructions with full source” … because that I think is what @HomineLudens asking, he can correct me if I am wrong.
The source is available (or will become available) as you pointed out, so the answer to the question is yes.
I do not see this comparison relevant to the question at hand. The world was a different place back then and Commodore was a big company, not an enthusiast project.
But since you brought it up, the unavailability of the Commodore ROM source codes and the often contested legal status of ROMs has been a major stumbling block of the Commodore legacy. If they had been open sourced at some point, we probably would have had several new “Amiga Nexts” by now. It is still a problem, 40 years later.
This is not intended as criticism of the Maximite. Filippo asked if the device was “debuggable”. Well, its based on a WaveShare off-the-shelf ARM board so evidently it is. But since the terms are what they are, you can’t freely use Maximite as a springboard to a derivative hardware or freely publish firmware modifications, which limits the usefullness of hw debugging. So the final answer is “yes with some limitations”
I hope that is a truthful answer for the moment.
Edit: in fact… If you want to code in assembler for Maximite, how are you going to distribute your program? See how a potential problem arises quickly, once you start to think about it.
If the Maximite firmware was closed source and unpublished, someone could write their own firmware and publish that, which is evidently possible, given that it is a WaveShare board. And they could easily demonstrate its written from scratch.
Now that the source will be published but not open source, how are you going to demonstrate that you do not infringe, when your open source alternative firmware is bound to have very similar elements?
This has a potential to be a worst of the two worlds problem.
First of all, I agree with the points in your reply. I missed you were addresing the “is it debugable?” question. My argument was that I don’t think open source firmware is a requirement for success.
Anyway, I bet hw debugging of a BASIC program can be very funny.
Easy, clean room engineering. Stick to the API and language reference docs, do not look too close to the source code and you’ll be fine.
But there’s no need to write a new firmware: if you find a bug, just report it so it can be fixed in the next fw release.
Yeah, totally agree with you, I do not want to get into an argument over someone elses project. It is really none of my business.
Personally, I would not buy a Maximite for hw level coding precisely because of the the aforementioned limitations. And I have no interest in Basic. So I won’t buy a Maximite.
For similar reasons I never bought any model of teensy either.
I bought a Teensy 4.0 with audio shield a few weeks ago, it was pretty cheap and it looked pretty powerful. I have not got into higher grounds yet, but every heavy processing C++ program I have sent to this beast runs at incredible speed. I have yet to connect a cheap 8 bit parallel 320x200 LCD screen (I could not get a 16 bit parallel cheap one on Amazon), but I have been busy and I recon I’m a total disaster when it comes to hw projects, so I am reading a lot about wiring and initializing the LCD controller before the surgery.
Please tell me what problem have you found with those Teensy boards, as you’re an experienced hw hobbyist and have worked with many MCU boards.
My opinion:
I expect that the Colour Maximite 2 is just there for people who want to do some stuff in Basic at reasonable speed and who do not want to bother with assembler or even C(++).
I would also expect that for people who like to code demos, this is totally not interesting. Because there seems to be no room for very smart tricks and optimizations to speed up things. The speed is only achieved because of the horse power of the chip.
That’s right. This and other demos are just an eye candy to show the high potential and high performance of the BASIC interpreter and MCU. Which, tbh, is impressive.
I’m coding a new half baked demo and I’m having trouble reaching this performance level on ARM Cortex M0+ at 220x176 16bit hicolour. I hope I can have a working preview this weekend with some new effects. I have overloaded RAM and I’m spending a lot of time figuring out how to free enough RAM for more simultaneous effects without driving the dynamic memory allocation crazy.
There is one major problem. If I ever create anything worthwhile on a Teensy, how will I migrate that project (and users) onto my own board design? Unless I pay up and buy the (imho expensive) bootloader chip from Paul, my own board will not be compatible with the Teensy tools = my users will not benefit from the Teensy heritage.
So why program on a Teensy? Why not start from another base board from the get go?
Building on top of a Teensy or a RPi is a dead end in my way of thinking. Its pretty harsh but that is exactly my reason. Nothing to do with any religion.
Wow, I come here a few moments later and seems like my question rise a nice discussion.
I’m sure the board is C++ debuggable, but my question was more related to the Basic language, with break points attachable to code, watch window etc.
And no, printout is not debug for me.
I see. That’s something I was not aware of. But I will have to handle it, as I want SBDL to be able to run on different MCU boards and provide a minimalistic hw abstraction layer for the code that runs on top. I supposed it was barely enough by just isolating custom initialization and also custom I/O (communications with LCD controller, button polling, audio output, interrupt handling, expansion port) but it seems it’s going to be a bit more difficult.
, a demo coded in BASIC, and it looks very good!