bASMic IDE for GBA

[DSLSC]

Hello fellow GBATemp'ers. (Hope this is in the right place, if not would a mod please move it?) Thanks to the documentation and tools provided free-of-charge by the online GBA devving community, it's pretty easy to get started with GBA devving. As an electronics hobbyist (any of those here?), I enjoy tinkering with new devices, including CMOS image sensors. As time has gone on, the parallel and serial ports on computers have gotten less and less accessible, finally disappearing.
Enter the Nintendo GBA: it has a 16MHz ARM CPU, a 240x160 color LCD (and controller!), built-in sound, a couple of buttons, more memory than most MCUs...and a 6-pin link port. The port provides 3.3v and four fully-controllable I/O lines. Also in the deal are two special hardware port modes: RS-232 and shift-clock. Programming the GBA to take advantage of the link port generally requires a computer. At first, I did hardware interfacing and tweaking via a "dumb multiboot" cable, but that quickly got tiring. The idea (started by Jeff Frohwein's "GBBasic" for the GBC) was: Why not do the programming right on the GBA itself?
After a couple of months writing in 100% ASM (both ARM and THUMB), "bASMic IDE" is quite useable, and almost bug-free. You can write code in a variant of BASIC (interpreted, but well compressed for high speed), as well as ARM7TDMI ASM. File load/save can theoretically be done on any Nintendo game cartridge that has SRAM or FLASH gamesave, as well as RS/232.
If anyone has implemented DLDI patch files on a GBA project (preferably in ASM), I would very gladly implement a version of libfat. (bASMic is currently 47KB in size, with a maximum of 64K. "libfat" is 60K...that's not going to work.) If I'm on my own, I'll probably stick with making bASMic's "libfat" support hardware-specific to the Supercard Mini SD.

Why did I write it entirely in ASM? Well...when writing code for both the GBC and GBA, I started out writing in C. After getting frustrated at the very slow operation, large output file size, and technical gymnastics required to make the compiler do what I intended, it was an easy decision to learn ASM. Of course, that had a steep learning curve. (No offense to those of you who love programming in C.) Of course, with 14,998 lines of code in 11 code files, it's definitely a big project!

Features:
-Fast BASIC execution, simple use
-Built-in helpfile (any clarifications, suggestions, let me know)
-Small (47K, including 10K of helpfile and 4K of palette/font)
-PS/2 keyboard support for faster code entry. (Yes, at 3.3v from the GBA, all but one keyboard tested has worked.)
-Unique on-screen keyboard for code entry
-Supports "FLOAT" (16:16 fractional, not true IEEE)
-Supports strings (31 255-character strings--they use a lot of memory!)
-Supports a small graphics library (GR/HGR, PSET/RECT/ELLIPSE/FILL, etc.)
-Supports true ASM, run from IWRAM for best speed.
-Minimal array support

Known issues:
-Something in interrupts--identified by a total lockup, where "BREAK" doesn't work. Not sure what exactly is wrong.
-ASM's "STOP" pseudo-command does not provide a completely accurate list of CPU registers. Let's face it, they're not easy to get!
-HGR Graphics are a little slow. That's what we get for using a tiled bitmap screen, and supporting low-res graphics as well.
-Cannot chip-erase an SRAM gamesave chip. Easy enough to do with a little BASIC program. 'Tis a pretty dangerous function, anyway.
-EXTRAM is run at the fastest functional waitstate setting, making the program run slowly in emulators. Seems to work fine on GBA/NDS.

As said above, I wrote this to make it easy to use the GBA's link port for hardware interfacing. For example: put a magnet on your bicycle wheel, connect a Hall-effect sensor to the link port, and a little coding later, you have a bicycle speedometer. Or launch that model rocket with one keypress on the GBA...make a race timer...etc. Not sure about an audio codec, but the possibilities are limited only by your imagination :-). Note that I am not liable for any damages.

Bug reports, suggestions, questions: just post and ask. I do not intend to port this to the Nintendo DS, as it doesn't have a link port...which is the point of the entire project.
The attached ZIP archive contains the multiboot- and regular-boot .GBA binary, two example programs, and a simple RS-232 communication program I wrote in VB6. (Nope, not trying Intel 80486 ASM yet. It's not worth the crashes .) If using an emulator, you can load code dumps to/from 0x02010000.
Note that bASMic runs from EXTRAM, so after it is started, you can remove the cartridge, and use the cartridge bus for an I/O port. Or plug in a ROM cartridge with gamesave memory.

Thanks to all of the GBA development community for making this project possible.

 

[FAST6191]

I know we already discussed aspects of this but I am certainly interested to see the release of it.
Ignoring modern windows and http://gbatemp.net/threads/nintendo-ds-assembly-inerpreter.345384/ (which is not quite full use) I am not sure I have ever played with a kind of walled off assembly interpreter (though that does not seem like an accurate term). Yay for unintentional user/self modifying code I guess.

On the serial/parallel stuff I can still get them and they appear often enough, though I do have to seek them out and will often keep an older machine around as some of them are a bit suspect/not quite what you count as full support. Similarly and though the screen probably counts for a lot on the electronics front is this not why we have the likes of the arduino, raspberry pi, teensy++ and other such devices? Anyway that is getting way off topic.

Others wanting a crash course in ARM assembly I highly suggest http://www.coranac.com/tonc/text/asm.htm

 

[DSLSC]

Yes, I have a 600MHz Toughbook with Windows XP for those times when a serial port or parallel port is required for a project. My main PC doesn't have either of those--or enough USB ports, for that matter . And if it did, Windoze 7 and 8 have so many "permissions" that they block the general user and programs far better then the well-informed viruses and worms. (8 being by far the worst at that.)

That DS program appears to be an "interpreted ASM" program, which in my opinion really fails the entire concept of using ASM. In bASMic, code written in a #ASM section is compiled to IWRAM, and directly run by the CPU. In other words, there are no protections or permissions (CPU in System mode), as the BIOSDumper example shows. Fortunately, the joypad interrupt (Start+Select) always works as long as interrupts aren't broken, and one can then examine the CPU registers, and decide to continue or stop the program right there. #BASIC code in bASMic, by contrast, is run-time interpreted, although well compressed in the correct sequence for fast program execution.

Sure, Arduino, Raspberry Pi, etc. don't have a screen--and in finished projects, they'd probably be used just that way. For that matter, Microchip PICs don't have screens, either. But on occasion, a little GUI (configuration, status, etc.) can be handy. (As the aforementioned don't have a display or controller, they save that expense.) A GBA could be used to provide a cheap and fairly simple "front end" when needed. Just an idea.

 

[DSLSC]

Here is a photo of a GBA interfacing project I did in 2010. Visible on the GBA screen is part of an inkjet printer, a clock, and some books. I was experimenting with a CMOS image sensor (VV6410), using a Parallax Propeller (8-core 32-bit CPU) to capture the image data from the sensor, store it, and then provide it to the GBA when requested. At the time, I was programming the GBA with C. It ran slow, but it worked. The circuit on the top of the breadboard was a 29F010 programmer based on a PC parallel port. Which is how I got started on GBC devving.

I did later revise the CMOS image sensor interface to use the link port at 115.2KBaud RS-232. Currently, I am working on a port of Jeff Frohwein's JPEG decoder (gfxlib), but in 100% ASM. The point is to see just how fast the GBA can decode a JPEG. Encoding a JPEG on the Propeller may be challenging due to the very small amount of memory available, but with 8 cores at 20MIPS (or faster), there's no lack of processing power.

 

[cearp]

@DSLSC - this is fantastic stuff. very very impressive.
i hope you are still doing similar stuff!

 

[DSLSC]

@DSLSC - this is fantastic stuff. very very impressive.
i hope you are still doing similar stuff!

Yeah, I'm still in the electronics field, though haven't used the GBA in quite some time. My next quarry is probably going to be the Raspberry Pi Zero, programming it with Ultibo (FreePascal) for "bare-metal" control.