#177869 - WriteASM - Sat Apr 13, 2013 2:42 pm
Hello everyone. I have spent the past few months working on a BASIC and ASM integrated development environment for the GBA (coded in 100% ARM7TDMI ARM and THUMB ASM.) It's one of those projects that just has to be shared with others, and perhaps may express my appreciation to those of the GBA programming community (GBADev and beyond) who have freely given of their expertise, source code, and ideas.
Currently, BASIC works quite well; ASM is a relatively recent implementation, and may have few bugs.
bASMic was not designed with gaming in mind, but rather with "utilty" in mind, and particularly towards making use of the versatile link port. One possible use is making a simple "front-end" for a microprocessor project. At any rate, with POKE and PEEK--and especially with ASM--you can do practically anything with the GBA. One of my first projects was a GBA BIOS dumper ;-)
bASMic can save programs to cartridges, but I do not have a cartridge with SRAM backup, or a FLASH cartridge, for that matter. Consequently, I cannot guarantee proper operation on either of those. I would recommend using a game cartridge with FLASH. Using bASMic, erase the "savegame" chip (see helpfile on "File Handling"), and then you can save/load programs.
Anyone want to port bASMic IDE to the GBC? I've been thinking about that, but three months (and 700KB of ASM source code) for the GBA version is about enough for me. Obviously, there would be some scaling back (for example: only 26 64-byte strings, keypad sized down and put on the "window", etc.). The GBC has its own share of "pluses", including 5v throughout, and a physical IR port.
If you find, or come across any of the following, please post it here, or send me a PM:
- Bugs (check the helpfile to make sure it wasn't intended to act that way, though)
- Code lines appearing a bright red (please include a binary data dump from $02010000 if in an emulator, or the steps to replicate the error.)
- System Hang (and what was done is of utmost importance!)
- Any typos or needed clarifications in the helpfile (or anywhere in the program, for that matter.)
- A better display font. I have found two other 8x8 tiled fonts, but they aren't easier to read.
- A "Unknown JEDEC ID" message on file load/save. Please post the two codes (if not $00,$00 or $FF,$FF), and the part number of the memory chip. (Unfortunately, the error also means that it won't work.) What I really need, in addition to the JEDEC ID and the chip's part number, is chip size and sector erase size.)
- "Debug Memory Viewer" popping up upon Link&Run when not requested. Interrupts again, of course, especially if you can't get out of the viewer!
- How does the "ATN" BIOS call work? Thanks to GBADev, ATN2 is usable (ATNXY! in bASMic), but ATN...
- Anyone know of a table-free method for calculating SINe, perhaps using ATN/ATN2/SQRT? Currently, it's being iteratively-calculated, although that uses the DIV BIOS call (read: precise, but slow).
- Suggestions, improvements, etc. NOTE: I do NOT intend to make bASMic a gamedev tool.
This program will NOT run on MappyVM (BIOS calls cause malfunction there); load/save do not appear to work on VisualBoyAdvance. Apparently, VisualBoyAdvance tricks bASMic into thinking the cartridge has SRAM...then refuses writes.
Some notes:
- FLOAT: -32767.00000 to 32767.99998, with 4.5-digit precision. It's really a fractional-extended integer, and not the slightest bit related to the IEEE standard for floating-point.
- EXTRAM waitstates are set to 0Eh at startup. It works fine on my GBASPs, but if you get a white screen when running it, by all means let me know.
- bASMic is fully relocatable...but I'm not so sure about devKitPRO's "crt0.s". If someone knows right off how to disable it, I'd gladly do that.
- High-resolution graphics are slow (HGR). That's the penalty for using Mode 0, unless someone has written some really good graphics routines for Mode 0. (Bitmap modes have only one visible map at a time, and text isn't as fast: two reasons I used Mode 0.) If you change the display mode (with a POKE), the Break "Debug Memory Viewer", messageboxes, inputboxes, etc. will probably not be visible. (The appropriate keys will still work on the invisible windows.) As long as interrupts are enabled, the bASMic ISR is in place, and the keypad interrupt handler hasn't been disabled, BREAK will work.
- The "STOP" ASM command currently assembles to SWI #0x3C0000. A BIOS file is required for VisualBoyAdvance to emulate this correctly.
- "DIM" is called "ARYST", is slightly different, and very specialized. I suppose I haven't really understood how "malloc" works in C-style coding, but my general intention is to make everything as fast as possible, although that sometimes compromises 'logical and familiar'.
- Perhaps the BASIC variable memory allocations should be slightly different?
- There are some bugs with the "Debug" screen's ASM view. BREAK gets everything correctly, but everything is different with a code "Stop".
I'm using a ADM232 (MAX232) for the RS-232 interface; it works without any problems at 3.3v, even at 115200 baud. If you don't have a MAX232 or equivalent, Parallax has a schematic for very simple '232-to-Propeller interface using transistors. As both the Propeller and the GBA are 3.3v, it'll probably work just fine.
Download the 58K ZIP here. The archive includes the 46K multiboot binary, some example programs, and a simple RS-232 communicator program (may require Visual Basic 6 runtime.) "46K" includes 9K of APLib-compressed helpfile.
If you're using a real GBA, the example files can be sent over RS-232. If using an emulator, put the file contents at $02010000, or in the CartRAM/FLASH area at $0E000000
UPDATE: April 24, 2013: Fixed a serious ASM bug, screen map VRAM locations, misc. other bugs.
_________________
"Finally, brethren, whatever is true, whatever is honorable, whatever is right, whatever is pure, whatever is lovely, whatever is of good repute, if there is any excellence and if anything worthy of praise, dwell on these things." (Philippians 4:8)
Currently, BASIC works quite well; ASM is a relatively recent implementation, and may have few bugs.
bASMic was not designed with gaming in mind, but rather with "utilty" in mind, and particularly towards making use of the versatile link port. One possible use is making a simple "front-end" for a microprocessor project. At any rate, with POKE and PEEK--and especially with ASM--you can do practically anything with the GBA. One of my first projects was a GBA BIOS dumper ;-)
bASMic can save programs to cartridges, but I do not have a cartridge with SRAM backup, or a FLASH cartridge, for that matter. Consequently, I cannot guarantee proper operation on either of those. I would recommend using a game cartridge with FLASH. Using bASMic, erase the "savegame" chip (see helpfile on "File Handling"), and then you can save/load programs.
Anyone want to port bASMic IDE to the GBC? I've been thinking about that, but three months (and 700KB of ASM source code) for the GBA version is about enough for me. Obviously, there would be some scaling back (for example: only 26 64-byte strings, keypad sized down and put on the "window", etc.). The GBC has its own share of "pluses", including 5v throughout, and a physical IR port.
If you find, or come across any of the following, please post it here, or send me a PM:
- Bugs (check the helpfile to make sure it wasn't intended to act that way, though)
- Code lines appearing a bright red (please include a binary data dump from $02010000 if in an emulator, or the steps to replicate the error.)
- System Hang (and what was done is of utmost importance!)
- Any typos or needed clarifications in the helpfile (or anywhere in the program, for that matter.)
- A better display font. I have found two other 8x8 tiled fonts, but they aren't easier to read.
- A "Unknown JEDEC ID" message on file load/save. Please post the two codes (if not $00,$00 or $FF,$FF), and the part number of the memory chip. (Unfortunately, the error also means that it won't work.) What I really need, in addition to the JEDEC ID and the chip's part number, is chip size and sector erase size.)
- "Debug Memory Viewer" popping up upon Link&Run when not requested. Interrupts again, of course, especially if you can't get out of the viewer!
- How does the "ATN" BIOS call work? Thanks to GBADev, ATN2 is usable (ATNXY! in bASMic), but ATN...
- Anyone know of a table-free method for calculating SINe, perhaps using ATN/ATN2/SQRT? Currently, it's being iteratively-calculated, although that uses the DIV BIOS call (read: precise, but slow).
- Suggestions, improvements, etc. NOTE: I do NOT intend to make bASMic a gamedev tool.
This program will NOT run on MappyVM (BIOS calls cause malfunction there); load/save do not appear to work on VisualBoyAdvance. Apparently, VisualBoyAdvance tricks bASMic into thinking the cartridge has SRAM...then refuses writes.
Some notes:
- FLOAT: -32767.00000 to 32767.99998, with 4.5-digit precision. It's really a fractional-extended integer, and not the slightest bit related to the IEEE standard for floating-point.
- EXTRAM waitstates are set to 0Eh at startup. It works fine on my GBASPs, but if you get a white screen when running it, by all means let me know.
- bASMic is fully relocatable...but I'm not so sure about devKitPRO's "crt0.s". If someone knows right off how to disable it, I'd gladly do that.
- High-resolution graphics are slow (HGR). That's the penalty for using Mode 0, unless someone has written some really good graphics routines for Mode 0. (Bitmap modes have only one visible map at a time, and text isn't as fast: two reasons I used Mode 0.) If you change the display mode (with a POKE), the Break "Debug Memory Viewer", messageboxes, inputboxes, etc. will probably not be visible. (The appropriate keys will still work on the invisible windows.) As long as interrupts are enabled, the bASMic ISR is in place, and the keypad interrupt handler hasn't been disabled, BREAK will work.
- The "STOP" ASM command currently assembles to SWI #0x3C0000. A BIOS file is required for VisualBoyAdvance to emulate this correctly.
- "DIM" is called "ARYST", is slightly different, and very specialized. I suppose I haven't really understood how "malloc" works in C-style coding, but my general intention is to make everything as fast as possible, although that sometimes compromises 'logical and familiar'.
- Perhaps the BASIC variable memory allocations should be slightly different?
- There are some bugs with the "Debug" screen's ASM view. BREAK gets everything correctly, but everything is different with a code "Stop".
I'm using a ADM232 (MAX232) for the RS-232 interface; it works without any problems at 3.3v, even at 115200 baud. If you don't have a MAX232 or equivalent, Parallax has a schematic for very simple '232-to-Propeller interface using transistors. As both the Propeller and the GBA are 3.3v, it'll probably work just fine.
Download the 58K ZIP here. The archive includes the 46K multiboot binary, some example programs, and a simple RS-232 communicator program (may require Visual Basic 6 runtime.) "46K" includes 9K of APLib-compressed helpfile.
If you're using a real GBA, the example files can be sent over RS-232. If using an emulator, put the file contents at $02010000, or in the CartRAM/FLASH area at $0E000000
UPDATE: April 24, 2013: Fixed a serious ASM bug, screen map VRAM locations, misc. other bugs.
_________________
"Finally, brethren, whatever is true, whatever is honorable, whatever is right, whatever is pure, whatever is lovely, whatever is of good repute, if there is any excellence and if anything worthy of praise, dwell on these things." (Philippians 4:8)