It is currently Sun Oct 22, 2017 6:48 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri May 05, 2017 7:51 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 351
... 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.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Fri May 05, 2017 8:02 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Fri May 05, 2017 2:42 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 199
Quote:
reverse polish notation for expressions

I mean, if you're going to do that why not just make it a FORTH dialect?


Top
 Profile  
 
PostPosted: Fri May 05, 2017 2:59 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 211
Location: Fort Wayne, Indiana
pubby wrote:
Quote:
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.


Top
 Profile  
 
PostPosted: Fri May 05, 2017 3:00 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 351
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.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Fri May 05, 2017 3:35 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 808
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Fri May 05, 2017 3:57 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri May 05, 2017 4:08 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5730
Location: Canada
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...")


Top
 Profile  
 
PostPosted: Fri May 05, 2017 4:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri May 05, 2017 8:27 pm 
Offline

Joined: Wed Nov 30, 2016 4:45 pm
Posts: 88
Location: Southern California
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


Top
 Profile  
 
PostPosted: Fri May 05, 2017 11:20 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 248
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.


Top
 Profile  
 
PostPosted: Sat May 06, 2017 1:04 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 351
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.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Sat May 06, 2017 3:00 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 808
Location: Sweden
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.

Quote:
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).

Quote:
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?

Quote:
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?


Top
 Profile  
 
PostPosted: Sat May 06, 2017 3:31 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 351
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.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Mon May 15, 2017 7:35 am 
Offline

Joined: Tue Jul 12, 2011 10:58 am
Posts: 264
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Gilbert and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group