BASIC for XM?

[+Allan]

I've been dying to find out how the 7800 Basic is. Since it was written by OSS of BASIC XE fame I'm really curious to see what they came up with.

 

Then we need a 7800 keyboard Magazine like Antic and Analog so people can type in user-programmed games and utilities. Just like the old days.

 

Allan

[GroovyBee]

I've been dying to find out how the 7800 Basic is. Since it was written by OSS of BASIC XE fame I'm really curious to see what they came up with.

 

I suspect it'll need a ton of work before its remotely usable on XM .

[+Allan]

I've been dying to find out how the 7800 Basic is. Since it was written by OSS of BASIC XE fame I'm really curious to see what they came up with.

 

I suspect it'll need a ton of work before its remotely usable on XM .

Why? Isn't the whole point of eventually bringing out the keyboard is to be able to use the software that was written for it?

 

Allan

[GroovyBee]

Why? Isn't the whole point of eventually bringing out the keyboard is to be able to use the software that was written for it?

 

The original keyboard designed by GCC connected to the 7800 via its joystick interface. The keyboard also has its own controller and EPROMs on board. Without looking at binary images and schematics its difficult to say what will have to change. However the BASIC will know nothing of POKEY or how to access the additional banked RAM on the XM module. I can't imagine 4K BASIC programs would be all that interesting these days .

[The Usotsuki]

Which is why a BASIC would need to be custom-written for the XM. (That, and would it support SIO disk drives?)

 

I'd like to use an existing source code (I've ported a couple BASIC dialects around on 6502 before) but I'd be worried about legality if I were using such a codebase, since obviously burning something to a cart is...a bit different than copying it to a disk.

[+Allan]

Which is why a BASIC would need to be custom-written for the XM. (That, and would it support SIO disk drives?)

 

I'd like to use an existing source code (I've ported a couple BASIC dialects around on 6502 before) but I'd be worried about legality if I were using such a codebase, since obviously burning something to a cart is...a bit different than copying it to a disk.

The original basic was designed to work with the SIO port. Of course it would need a DOS but I don't think GCC got that far. Maybe Curt can give us more of a clue.

 

Allan

[+Allan]

Why? Isn't the whole point of eventually bringing out the keyboard is to be able to use the software that was written for it?

 

The original keyboard designed by GCC connected to the 7800 via its joystick interface. The keyboard also has its own controller and EPROMs on board. Without looking at binary images and schematics its difficult to say what will have to change. However the BASIC will know nothing of POKEY or how to access the additional banked RAM on the XM module. I can't imagine 4K BASIC programs would be all that interesting these days .

I was under the assumption that the controller ports on the XM were put there for the Keyboard. As far as the 4K issue, GCC had designed carts with more RAM on them so you could do more with programs like BASIC and the word processor. I'm sure Curt will clear that all up in time.

 

Allan

[GroovyBee]

I'm quite happy to look at getting OSS BASIC going on the XM. It'll just get added to my ever growing list of things to do on the 7800.

 

However I think a 7800 version of batari Basic would see more people using it. Maybe I should do a BASIC to "C" converter to take advantage of my 7800 "C" development system?

[jaybird3rd]

However I think a 7800 version of batari Basic would see more people using it. Maybe I should do a BASIC to "C" converter to take advantage of my 7800 "C" development system?

This gets a little off-topic, but in my opinion, those who are serious about programming for the 7800 (in something other than assembly language) should learn to do so in C. It really isn't that much more difficult than learning a proprietary language would be, and it would avoid having to tie up developer time and effort to build the proprietary language. Besides, once you learn C, you can take that knowledge to just about any other system, if and when you're ready to move on to something else; with a proprietary language, you'll have to start from scratch.

[The Usotsuki]

To me, using a BASIC compiler wrecks the purpose of BASIC.

[GroovyBee]

A new thread for discussions concerning BASIC for the upcoming XM module.

 

Effectively carrying on from here :-

 

http://www.atariage.com/forums/topic/171861-7800mx1-plastic-tooling-update/page__view__findpost__p__2128759

 

If a mod could do the honours and split the thread that'd be cool.

[The Usotsuki]

I mentioned on a couple threads I was willing to contribute in any way I could to such (since once you have a keyboard, a DOS and a BASIC interpreter, all the other elements already exist for a neo-vintage micro built on the XM platform...disk drives can be migrated, in theory, from teh 800s).

 

OTOH, I have reasons for preferring to start from scratch, something I'm not sure the others here would be as agreeable to.

 

1. I am one who prefers to keep cart releases fully legit (disk releases, otoh, I don't care about because de-imaging them is more or less trivial, where this isn't so for cartridges). This would rule out any OSS-derived or Microsoft-derived BASIC. (Unless we could ascertain that the current holders of the Atari Basic copyrights would not be averse to such a port being done.)

 

2. Cart releases necessitate commercial exploitation, which is fine if the code is licensed for such use (see #1 above). This would rule out EHBASIC, unless it were loaded from a disk. These two leave me without a BASIC to port, although I'd be happy to do so. I'd also be willing to contribute to a new BASIC interpreter - which obviously wouldn't be so bound.

 

That said - there's room for more than one BASIC if people want to take both approaches. The TRS-80 had Tiny Basic and Microsoft Basic. The Apple ][ had Integer Basic and Floating Point (Applesoft - APPLE + microSOFT) Basic. The Atari 400 line had Atari Basic and Atari Microsoft Basic... there's no reason why both approaches could not be taken, apart from the infighting and market division that would cause.

 

I tend to prefer the Microsoft Basic approach, which EHBASIC also takes. It is, however, radically different from what those of you who grew up on Atari computers may be familiar with. It is what I am most familiar with.

[GroovyBee]

You'll also need emulator support for file and keyboard I/O. Personally, I think that most people interested in developing BASIC games would not develop directly on the 7800 except out of curiosity.

[The Usotsuki]

The disk drive stuff could be done with code from an Atari 800/XL emulator. It's the same hardware. I wouldn't be surprised if even the keyboard support could be taken from such.

 

The option of programming in BASIC isn't so much about making games as about instant gratification and the fact that, well, almost every 8-bit had some dialect of BASIC on it, which is my main interest. xD

[Rybags]

Part of me just says "take Atari Basic and the FastROM Floating-Point routines from Newell".

 

Disadvantage of course is Atari Basic is a bit slow, even with better FP. And it'd also need a good deal of stuff from the OS included too like adapted CIO routines.

 

Doing the keyboard is nothing - Pokey already does most of the work, you can virtually get away with a 64 byte translation table and a bit of code to handle it.

[GroovyBee]

The disk drive stuff could be done with code from an Atari 800/XL emulator. It's the same hardware. I wouldn't be surprised if even the keyboard support could be taken from such.

 

Personally I'd skip the legacy support and invent a new scheme that could be used as a transport mechanism to read FAT16 formatted media. This would mean new hardware too.

 

The option of programming in BASIC isn't so much about making games as about instant gratification and the fact that, well, almost every 8-bit had some dialect of BASIC on it, which is my main interest. xD

 

I don't think that many people interested in the XM want instant gratification. They just want to create a game in the fastest and most user friendly way. That means a PC development route with testing on final hardware.

[The Usotsuki]

I'm not talking from the dev's standpoint. Those writing BASIC are the devs.

 

In order to understand the Apple ///, I wrote some code that allowed Applesoft BASIC to run on it. This allowed me to poke around the internals and see what did what, as well as to write little programs that did things. This kind of stuff is easiest done with something like that, BASIC or a monitor (or both).

 

I guess I just, because of my own experience with 8-bitters, see BASIC as one of the fundamental building blocks of an 8-bit computer, which is why I want to see BASIC on the XM. xD

 

(As for FAT - I fully intended to suggest that the filesystem of whatever DOS would be written for an XM be FAT! Makes cross-development much easier >)

[+Gemintronic]

The disk drive stuff could be done with code from an Atari 800/XL emulator. It's the same hardware. I wouldn't be surprised if even the keyboard support could be taken from such.

 

Personally I'd skip the legacy support and invent a new scheme that could be used as a transport mechanism to read FAT16 formatted media. This would mean new hardware too.

 

The option of programming in BASIC isn't so much about making games as about instant gratification and the fact that, well, almost every 8-bit had some dialect of BASIC on it, which is my main interest. xD

 

I don't think that many people interested in the XM want instant gratification. They just want to create a game in the fastest and most user friendly way. That means a PC development route with testing on final hardware.

 

This is my thought as well. Develop from the comfort of a desktop PC and compile binaries for 7800 with XM extensions.

 

Some had suggested using C for 7800 programming. C is just as archaic as assembler for most folks. I remember writing a 7 line "Hello World" program in C that generated over a dozen errors. BASIC is not just for beginners. BASIC is for focusing on gameplay rather than syntax checking and compiler errors.

 

A Batari BASIC-like compiler for the 7800 would push me over into the MUST BUY category regarding the XM.

Edited November 4, 2010 by theloon

[GroovyBee]

Some had suggested using C for 7800 programming. C is just as archaic as assembler for most folks.

 

Its not a suggestion. I actually do program in "C" on the 7800.

 

I remember writing a 7 line "Hello World" program in C that generated over a dozen errors. BASIC is not just for beginners. BASIC is for focusing on gameplay rather than syntax checking and compiler errors.

 

Writing good/efficient/fast "C" for a constrained platform is an art form .

 

A Batari BASIC-like compiler for the 7800 would push me over into the MUST BUY category regarding the XM.

 

I'm sure somebody will step up to the plate at some point. Writing a language parser isn't something that I'm particularly motivated to do.

[+Gemintronic]

Not dissing your C skills at all GroovyBee. Some people grew up with C. Some BASIC. Wish I had both skillz

 

I think the middle ground is to find C source for a dialect of BASIC and go from there. BASIC runtimes don't necessarily have to be bloated sloths.

 

UPDATE: HEY! What about nBasic?

 

http://bobrost.com/nes/resources.php#documents

 

Could a NES BASIC compiler be assimilated (being a 6502 variant)? Like they say: resistors are futile!

Edited November 4, 2010 by theloon

[Madaracs]

You'll also need emulator support for file and keyboard I/O. Personally, I think that most people interested in developing BASIC games would not develop directly on the 7800 except out of curiosity.

 

Could this be used to eventually incorporate maybe an ADL Engine of some type for text adventures?

[GroovyBee]

UPDATE: HEY! What about nBasic?

 

http://bobrost.com/nes/resources.php#documents

 

It doesn't seem to have been updated in 6 years looking at that page.

[+Gemintronic]

UPDATE: HEY! What about nBasic?

 

http://bobrost.com/nes/resources.php#documents

 

It doesn't seem to have been updated in 6 years looking at that page.

 

May not be an issue. I think it's public domain and someone would be gutting the input, sound and graphics routines anyway.

Edited November 4, 2010 by theloon

[The Usotsuki]

Aren't those compilers though? When I, for one, talk about BASIC on the XM, I'm talking about the kind of BASIC we used to use on 8-bit computers (I mentioned EHBASIC which has its roots in the same base as Commodore BASIC, Applesoft BASIC and CoCo BASIC). (This of course assumes the keyboard addon happens, although I could write some temp code to enter ASCII with a joypad).

[GroovyBee]

Aren't those compilers though? When I, for one, talk about BASIC on the XM, I'm talking about the kind of BASIC we used to use on 8-bit computers (I mentioned EHBASIC which has its roots in the same base as Commodore BASIC, Applesoft BASIC and CoCo BASIC). (This of course assumes the keyboard addon happens, although I could write some temp code to enter ASCII with a joypad).

 

I'll take the modernist approach with a BASIC compiler on the PC producing cart binaries . However, if the BASIC that Curt has available is adaptable to run on the XM I don't see why both approaches wouldn't be possible.