Thinking about writing a BASIC interpreter

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

na_th_an
Posts: 558
Joined: Mon May 27, 2013 9:40 am

Thinking about writing a BASIC interpreter

Post by na_th_an »

... in fact, an hybrid between compiler and interpreter, as the source code would be converted to a easily parseable bytecode, complete with tokenized commands, reverse polish notation for expressions, jump tables, etc. by a "compiler" running on the PC which would output a working NES ROM containing the bytecode interpreter plus the program and assets. A simple and easy to produce UNROM 64K would work nice, with the fixed page for the interpreter, one page to contain graphics, and two for the program itself. Expanding to UNROM 128K or any kind of oversize would be trivial.

Still not sure how to manage data which is external to the program. Probably will turn DATA blocks to const data, or something like that.

Apart from the basic BASIC stuff (loops, selective instructions, etc) and basic IO (PRINT / INPUT / joypad read) I was planning on adding a simple and easy layer of assets such as metasprites, metatiles, a background of metatiles, functions to define actors and bounding boxes, simple collision detection... you name it.

The idea is in my mind since I read about the original Hudson Soft BASIC for the NES which may be cumbersome to use as it requires a not very common peripheral, plus you can't really sell carts of your games because they would contain copyrighted code. My main goal would be providing something simmilar but allowing people to actually produce their games in carts and sell them (still have to decide which kind of licensing I would like to apply), plus allowing to work on PC.

Maybe just replicating the existing BASIC interpreter would be a nice start, but I don't really know its inner workings other that it doesn't let you use your own graphics, which is something I don't like.

I just wanted to know what you guys think about this project and if you have any comments about the kind of BASIC dialect or the features it should support.

Thanks.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Thinking about writing a BASIC interpreter

Post by infiniteneslives »

Would be very nice to see something like this especially well polished and actively in use.

Reminds me a little of uc65 which I tinkered with a few years back. There were some good discussions there that might be of valuable reference.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Thinking about writing a BASIC interpreter

Post by pubby »

reverse polish notation for expressions
I mean, if you're going to do that why not just make it a FORTH dialect?
User avatar
NovaSquirrel
Posts: 483
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Thinking about writing a BASIC interpreter

Post by NovaSquirrel »

pubby wrote:
reverse polish notation for expressions
I mean, if you're going to do that why not just make it a FORTH dialect?
Or a FALSE dialect, like I attempted to make for NES before back during the second compo.

Not having keyboard input wasn't as bad when all the commands are 1 character, and the interpreter was pretty easy to do.
na_th_an
Posts: 558
Joined: Mon May 27, 2013 9:40 am

Re: Thinking about writing a BASIC interpreter

Post by na_th_an »

That's only for the bytecode. The BASIC dialect will be the classic 8-bit BASIC which was ubiquitous in the 80s. The plan is to transform the BASIC listing into something the interpreter in the NES can process as fast as possible. Tokenized listings, easy to digest expresions, precalculated jumps, etc.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Thinking about writing a BASIC interpreter

Post by Pokun »

So it will be mostly syntax compatible with Family BASIC and V3? And support for the official keyboard would also be nice too. But we really need a PS/2 -> Famibe Keyboard adapter.

I think Family BASIC has been disassembled somewhere here on the forum.
Also there are hacks of Family BASIC to VRC7 and MMC5 that have a character generator that allows to create the pattern data for BG/sprite characters.

BTW the Family BASIC set is a quite common item and not that expensive either (not counting shipping of course). This has been on Famicom World forums for a while, and no one are buying it, it seems.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Thinking about writing a BASIC interpreter

Post by tepples »

na_th_an wrote:That's only for the bytecode. The BASIC dialect will be the classic 8-bit BASIC which was ubiquitous in the 80s. The plan is to transform the BASIC listing into something the interpreter in the NES can process as fast as possible.
Or you could translate BASIC into FALSE and execute the FALSE. That way you can at least debug the FALSE on the target machine.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Thinking about writing a BASIC interpreter

Post by rainwarrior »

I learned to program with BASIC on my Atari ST. I think it was a pretty good language for learning.

I think BASIC has some appeal as being relatively easy to interpret / implement, and straightforward to understand as an imperative programming model. Similar to assembly, but instead of opcode you have much higher level operations, so it's not as teious/difficult. Part of why it's good for learning is that you can make a really nice library of high level things to use.


Anyhow, GOSUB and RETURN would by my "feature of choice" to include. A lot of older BASIC dialects omit this, though many later "structured BASIC" dialects go even further, with subroutines having arguments, local storage for re-entrant/recursive subroutines, etc. but even just the basic functionality of GOSUB itself is great to have.


(Was the FALSE suggestion not just a joke? "I designed this language in '93 with two particular objectives: confusing everyone with an obfuscated syntax...")
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Thinking about writing a BASIC interpreter

Post by tepples »

In any case, the language is probably among the least impractical of the esoteric programming languages. It's not unlike a tokenized form of Forth.

But I guess it'd probably be better to design a custom stack machine.
Garth
Posts: 246
Joined: Wed Nov 30, 2016 4:45 pm
Location: Southern California
Contact:

Re: Thinking about writing a BASIC interpreter

Post by Garth »

Although I've never used EhBASIC, it did appear to be an outstanding BASIC for 6502 when I looked into it years ago. Unfortunately the originator, Lee Davison, died unexpectedly a few years ago; but it has been kept available by others. See it at http://web.archive.org/web/201209130428 ... index.html and the github pages at https://github.com/jefftranter/6502/tre ... sm/ehbasic . With the source code available, you should be able to modify it however you need to.
http://WilsonMinesCo.com/ lots of 6502 resources
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Thinking about writing a BASIC interpreter

Post by Oziphantom »

BASIC has a flaw. IT EATS RAM, sure you will be storing the tokens and interpreter code in ROM, but none the less with 2K to hold the interpreters state and vectors, sure you add an extra 8K of RAM on the cart so you up to 10K going to be tight..

The C64 BASIC 2.0 ROM has been dissembled here http://www.ffd2.com/fridge/docs/c64-diss.html ( this also has the KERNAL, but BASIC also uses some of the KERNAL space for commands ). One of the more Spartan BASICS around though. If you want to make things easy you might want to dive into BASIC 7.0 which has graphics, music, sprites, joystick control, high level structures etc It is documented from page 195 of https://archive.org/details/Compute_s_M ... modore_128 but you will probably need to dive into the crazy world that is a 128 to follow it.

The Commodore BASICs have floating point support which is nice, but perhaps not needed for NES games.

BASIC 2.0 is basically pure MS-BASIC as it was made by Microsoft internally, even has some Bill Gates code in it. BASIC 7.0 is a custom Commodore extension so doesn't quite follow the normal rules.
na_th_an
Posts: 558
Joined: Mon May 27, 2013 9:40 am

Re: Thinking about writing a BASIC interpreter

Post by na_th_an »

I am very fond of modern BASIC dialects in the fashion of the standard introduced by Microsoft in their QuickBasic line. All my converters and toolchain utilities are compiled with FreeBasic. But the dialect I'm aiming for is the good ol', classic BASIC with GOSUB and RETURNs, no structs, no multiline IF, no procedures, etc. I've coded in many "classic" BASIC dialects along the years, including the original from 1964. I'll study the one used on the NES and try to make something simmilar, as every dialect has suble differences. I was risen using the Sinclair BASIC dialect as used in the ZX80, ZX81 (Timex 1000) and ZX Spectrum computers. It's pretty well featured yet contact, I seem to remember that it was fairly complete with just 80 keywords, but has some constructs which differ greatly of what's considered "standard BASIC".

Of course, it will support only integer numbers, maybe fixed point (or tools to use integer numbers as fixed easily) in the future.

Once the basic BASIC is interpreted, I'll work on the extensions, mainly aimed to writing games, trying to keep them simple yet useful. I will try to include support for bit fiddling early on, though. Many BASICs lack proper bit operations support, and I consider that very important for game development. But first things first: I'd rather have a VPOKE command from the beginning so users can, for example, alter palettes before I add proper support for such a task.

Still a long way, though, I've written simple interpreters in the past but not for real turing complete languages. My time is very limited and I think that if I stop and study how other people in the past made simmilar things, I will probably run out of steam before starting my own. I'll try my favourite route: self teaching and learning from mistakes.

The design is based on working on the source in your PC, so no keyboard peripheral support is needed. The produced ROM will run in any emulator and will be easily produced on cart or burn into a powerpak or Everdrive to play, with no lincensing issues, and no fiddly and hacky solutions needed.

The goal is having as much as possible in ROM, the interpreter stuff in ZP, and the user variables using a simple heap in BSS. I've coded games in BASIC in the Sinclair ZX81 (Timex 1000 in the U.S.) where you had just 1K of RAM for the display, the BASIC listing, and the variables. I think I can manage without needing extra WRAM. My main concern is string support. BASIC are usually quite well featured sporting variable length strings, which are usually slow to handle and eat RAM. Have to think deeply about this.

To keep things simple, the initial versions will output NROMs, but as I've mentioned, I plan to support UNROM or simmilar. My main goal is producing the simplest form of ROM possible so people can use the system to create games for the nesdev compo or have them published for cheap.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Thinking about writing a BASIC interpreter

Post by Pokun »

na_th_an wrote:I'll study the one used on the NES and try to make something simmilar, as every dialect has suble differences.
NS-HuBASIC is based on Hudson's HuBASIC they made for Sharp computers to be compatible with Microsoft's BASIC on C64 and such computers. Hudson later developed Family BASIC together with Nintendo. It's pretty much standard basic, but it of course has a few commands for doing NES-specefic things. The manuals for Family BASIC and V3 (check earlier link, V3 commands are found here) explains every command in detail and in English.
I will try to include support for bit fiddling early on, though. Many BASICs lack proper bit operations support, and I consider that very important for game development. But first things first: I'd rather have a VPOKE command from the beginning so users can, for example, alter palettes before I add proper support for such a task.
NS-HuBASIC has bitwise operators like AND but not bit rotation or shifting. For VRAM and OAM stuff it has commands like PALET, COLOR, SPRITE and such. V3 also adds FILTER for manipulating the color emphasis bits. Otherwise POKE can access the PPU ports like in assembly.
For sound it has BEEP and PLAY which involves an MML that can use the Squares and the Triangle channel, but not noise (and DPCM is pretty much impossible on Famibe I think).
The design is based on working on the source in your PC, so no keyboard peripheral support is needed. The produced ROM will run in any emulator and will be easily produced on cart or burn into a powerpak or Everdrive to play, with no lincensing issues, and no fiddly and hacky solutions needed.

The goal is having as much as possible in ROM, the interpreter stuff in ZP, and the user variables using a simple heap in BSS.
Now I'm confused, it is an interpreter that is meant to run on the hardware, but the source is done on a PC? What's the point of the BASIC interpreter then?
I can manage without needing extra WRAM.
No way, even Famibe is using on-board WRAM to keep the program. Or is the program in ROM in this solution?
na_th_an
Posts: 558
Joined: Mon May 27, 2013 9:40 am

Re: Thinking about writing a BASIC interpreter

Post by na_th_an »

Thanks for the pointers :)

The thing is, I find it easier to write a bytecode interpreter rather than a compiler for my first attempt. The bytecode interpreter could easily be ported to other (more powerful) platforms and would be able, ideally, to run the same package (program bytecode + data) with no changes. I could also translate BASIC to C and have cc65 compile it, that's another possibility. I'm still not proficient enough in 6502 assembly to have a proper compiler which would do BASIC->assembly.

Yes, the idea is that the bytecode interpreter runs the program from ROM. RAM would only hold the variables.
slobu
Posts: 276
Joined: Tue Jul 12, 2011 10:58 am

Re: Thinking about writing a BASIC interpreter

Post by slobu »

In a previous career I was a software tester. I've made commercially available homebrew using BASIC compilers for the Atari 2600 and sega genesis. Currently working on a commision for an Intellivision game using a BASIC compiler.

If you need someone to test and use your project I'd be more than excited to do so. I've got an original NES, flash carts, Infinitelives boards and more NOAC clones than reasonable.


I've suggest looking into how batari BASIC for the 2600 works. It uses hand tuned assembly game engines coupled with translated BASIC to assembly for game logic code.
Post Reply