Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

I remember coding four pages from 99er, to make a little box go from one side of the screen to the other and change colors, while playing a midi tune. More serious business was the epic dungeon text adventures!

plugh! or was it xyzzy?:)there are several Apple II emulators that allow programming in Apple Basic or even Merlin Assembler (65816) for both Mac and Windows. Sweet16 is the best of OS X (a port of Bernie ][ the Rescue from BeOS; originally on Mac Classic), XGS, KEGS and many others are also out there...

I had the 10 ton silver expansion box! 32k baby!!! It was the BEST!:) With the Speech Synthesizer to boot! Doc Watson makes me cry when I think about how much that thing cost me... right out of pocket too from my paper route!!

This particular code made use of CALL SPRITE, but also had the most advanced calls available. Man that brings back memories...

The cartridge was Extended Basic, which was totally elite at the time.:P

We were all designing color output, while the poor VIC-20 guys were still monochrome.

I still remember the text adventure, where if you type look up, a piano falls on your head. I think it was called Asylum or something? Man that is going way back to the summer of 1983, if memory serves.

I was in the Apple store, asking a Genius why Ms. Pac-Man, which ran on an Atari 2600, is taking up almost 20 megabytes on my iPod Nano. He told me it's because they have to fit all those in-game sound effects into the download. Pure genius.

If you wanted a serious answer, it's most likely related to the ties to the graphics and sound libraries, storing sounds as waveforms rather than parameters to tone-generation hardware, and probably packaging overhead.....those are just guesses. I'm no iPod software expert.

I used to have a book with type-in adventures where they obfuscated all the strings by shifting them one character precisely to counter that problem.

Oh and typing in five pages of numbers representing binary code was fun. There were actually checksums printed at the end of each line and a little program showed you the checksums in the corner of the screen after entering each line of code.

Man I feel old. You young whippersnappers don't know how good you have it with your iPhones and your WiFi.

I'm still trying to get my hands on the old Arcade Explorers books. Interesting concept - choose your own adventure, and your choices determine the parameters of the game you type in (via different sections of code). Of course the games were simple, but still neat for their time.

I discovered this, too. My parents bought me a book called "Great Games for the TI-99/4A". I still have it floating around somewhere. Unfortunately, you figured out exactly what _not_ to do by having to program in every permutation of death. But there were other games-- there was an Asteroids clone, if I remember correctly. Of course, I had to write these things multiple times-- the external 5 1/4" floppy drive seemed to only excel at losing data.

I remember a similar demo in the TI/994A Reference Manual. It also had a program to re-define a character to make a little jumping man in an 8x16 grid. One of my first programs was to make a running man move across the screen based on the code in the reference manual.

Hey, I earned some not negligible bucks (at the time) by selling a few TRS-80 BASIC game programs to magazines. The conscientious ones printed the code along with a checksum in a REM at the end of the line, and a small loader routine to verify these sums.

I guess basic is basic unless it's on a machine you're familiar with... I find Freebasic ( www.freebasic.net ) useful, probably because I came from the same era and did all my programming back then too, although I used a Spectrum and I'd never want to have to use that sort of keyboard again.

Freebasic is a fairly recent compiler that makes pretty neat code and has all the common C calls available to it too as well as being able to process native Qbasic programs (if you migrated from the C64 type basic to the PC later) without many of the limitations and nearly complete compatability.

It also allows cross-scripting between Mac, PC and Linux with the same program which I find useful too.

www.freebasic.net

GrpA.

ps. Basic may not be dead, but you still get funny looks when people see you programming in it. I think some consider it even more ancient and antiquated than cobol (which it's not).

Given it stands for "Beginners All-purpose Symbolic Instruction Code" I'd say just about any language or variation of it that meets this requirement and uses a similar syntax structure could be called BASIC.

I have to say, Commodore BASIC was one of the worst BASIC interpreters available in the "home computer" market. It's pretty clear the C64 was really a game console with a keyboard, so it could be (very successfully, and legitimately so) sold as a computer. If you actually wanted the C64 to do anything interesting, you had the choice of assembly, or BASIC that looked like assembly but ran like crap. As far as I can tell, the C64 BASIC didn't use any of the techniques used by other BASICs from the same era to not run like a total dog.

Don't get me wrong, the C64 was a great machine. It just wasn't a great machine for BASIC programming.

I'm actually quite curious what the differences would be that would make it a bad interpreter.

C64 was my first exposure to programming (I was 8 when I got my hot little hands on it), and not having tried anything else from that particular era of home computing I don't have a yardstick to measure that sort of thing.

A few things that made Commodore BASIC slow compared to some of the BASICs of the time:

A lot of parsing was done at runtime, rather than at entry time or program startup time. This meant that a lot of work got done over and over rather than once per execution, and also encouraged practices that made programs hard to read, like omitting comments and whitespace.

No support for integer-only arithmetic.

Very few high-level constructs. This didn't just turn programs into a mess of POKE statements, but frequently meant that a lot of them were needed -- all of which involved two floating-point to integer conversions to set a single byte.

Most BASICs at the time would at least tokenize at entry time, and many even converted programs to P-code for execution. It was still much slower than true assembly, but it wasn't anywhere near as bad as the CBM basic. Similarly, most (but again, not all) BASICs of the time supported integer-only arithmetic at least as an option.

I have to admit to being a bit spoiled at the time, since I first learned to program on the Swedish ABC80 [abc80.org] computer, which had a very fast BASIC interpreter. Its follower, ABC800, even had a decent collection of high-level programming constructs in its BASIC. Too bad neither had acceptable graphics, nor a reasonable price point for home use (they ended up being sold mostly into schools and small offices.)

Actually, that isn't true. You could specify integer variables by suffixing them with a percent sign (eg. i%=1). But most people were lazy and omitted the percent sign, so their programs ended up doing a lot of floating point math unnecessarily.

encouraged practices that made programs hard to read, like omitting comments and whitespace.

I think that is a bit unfair. Given the limited memory of the C64, best programming practice was to omit comments in favour of code. Remember, C64 BASIC was interpreted, not compiled, so comments chewed up memory... memory measured in KILObytes. Comments (actually, they were called REMarks back then) were a luxury.

I was a bit young to do any serious programming on the C64, but I do remember my father rewriting a line

I guess all the poor kids were using the Aquarius from Mattel, or any one of several other competing systems all based on the Zilog Z80 processor. This was the first time I came in contact with anything from "Microsoft"

Being less talented than your average/.er, Commodore *64* basic reduced me to whimpers at that tender age. I pulled out all the stops and mortgaged my childhood in chores to upgrade to the Commodore 128, and that is basically the best value in an upgrade I'll ever see. Helped by the extra passage of years, on the 128 I made maze programs, a Dodge-The-Mall-Traffic Simulator as a joke, Ethnic dialects of Eliza including the Angry New Yorker, and a few quasi-utilities that were more basic concept exercises. T

Since Commodore Basic [wikipedia.org] was originally written by Microsoft, that seems almost approriate. However, I learned to program using PET Basic and it didn't seem that bad to me at the time. It least you could do lower case characters with it.

Since Commodore Basic was originally written by Microsoft, that seems almost approriate.

I heard that the reason the C64's BASIC sucked so hard was that C= got the license to the original MS BASIC for the PET on very good terms, and didn't want to renegotiate this and pay them more for a newer version (that would have done the hardware justice).

The BASIC on the C16/Plus4 machines is supposed to be much improved (maybe they forked out?) but as those computers bombed commercially it was all to no avail.

Actually Atari Basic was arguably worse the Basic 2.0.
Atari Basic had totally none standard String handling.
C64 Basic lacked extensions for graphics and sound but other than that it wasn't terrible.

Atari BASIC was no worse than a lot of 8-bit BASICs. Nothing amazing- it lacked structured programming beyond GOTO (but then so did most 8-bits apart from the BBC Micro) and it wasn't too fast, but it was respectable enough.

Yeah, the string handling was a bit nonstandard (and slightly annoying in some ways), but that was hardly the end of the world. Supported lettered device handler names and access to drivers via XIO. I'd take that over a mess of POKEs and control characters for even the most simple faci

Yes, Commodore BASIC was slower than integer BASIC on the Apple ][. That's because Commodore BASIC used all floating point numbers. It was the same speed as Applesoft BASIC, since both of them came from the same Microsoft codebase and ran on the same CPU.

So unless you're comparing Commodore BASIC to Apple Integer BASIC, what are you talking about?

I agree that Commodore BASIC was horrible. I first learned BASIC on a Commodore PET 3008 and it was very limited unless you started POKEing into memory. Sinclair BASIC for the ZX81 (my first computer) wasn't much better. The best BASIC of the era came on the BBC Micro which supported REPEAT UNTIL loops, PROCs and so on so you didn't have to write code full of GOTOs. Oh, and it was easily the fastest machine on the block for years after release despite being based on the 6502 just as the CBM machines wer

I learned BASIC on an Apple and then moved to the C16 then to a C128 with C64 embedded. I really enjoyed BASIC on the Commodore platform. I loved POKE and PEEK. The with my Super Snapshot card I could get into a pretty good machine language decompiler. From there I could create programs in the $c000 range, store them to a floppy, and sys them. I loved monitoring the raster ($d018 or somewhere close) and changing it's color when it's at various positions to create screenshots better than what the C64 normally allowed.

I never have got as deep with the x86 platform.

The thing I've found with most emulators is that this trickery just doesn't work right. A lot of it depended on the set Mhz rate of the hardware.

The Vic-20 was the wo-rst of both worlds,bad games, crappy basic, and only 22 columnsacross. Oh yea, and a300-baud modem and nodisk drive, just cassette. Still, INFOCOM had a few good text adventures on it.

If you have any of those old CBM-BASIC listings from 80's computing magazines, it's full of POKE x,y statements (and sometimes the program is just a hex loader with bunch of READ...DATAs). So I'm really not so sure of the value of this experiment.

(One of the longest "commercial" CBM-BASIC programs I remember - that actually used it for lots of things - was Sid Meier's Pirates! [wikipedia.org]. (Haven't tested the newest Remake - I did like Pirates Gold!, the first remake, a lot)

I found it odd that it took 1.8 MB of source code to compile to an interpreter that used to fit in 8K of ROM space

Don't forget that the commodore cpu was 8 bit and current cpu's are 32 or 64 bit: Most of the commands were 8 bit and their equivalents are bigger nowadays. That explains the 8KB of ROM

And they did not need fancy memory protection stuff, they hacked straight into the hardware. No dll's, so's to use or API's to follow. Even if it is a lot assembly code, there are a lot more bytes in assembly source than in binary executables.

Is that, some old assembly hackers ought to be able to whip up a fairly tiny basic interpreter. It should be fun in a way and still easier than in the old days of 6502. You have more registers, some basic string instructions, and outstanding support for floating point. I doubt it could be quite as small though, as, the big thing that would bloat it up would be that instructions themselves in 32 bit. For an easier and almost weekend job of it, you could do it in 64 bit assembly for Linux only. That spar

But the real question is....Why would anybody do this?? Port Commodore64 BASIC to a PC?

I used to have a Commodore64 and learned 6502 Assembler on it. When I got a PC (a 286) I felt nostalgic for the C64 and bought a cheap one. I used it about ten minutes and realized what a mistake it was. Fortunately I was able to sell it right away.

Never look back. There is is nothing that was written for Commodore 64 that isn't 1000 times better on modern PCs. Nothing. Don't give me any BS about the wonderful SID chip and its KOOL mickey-mouse MOD files. They suck, really. Don't tell me about that fantastic game that you used to play on the C64 and have never been able to recreate the excitement on a PC. It's because you were a kid discovering video-games, not the Commode64.

Are you going to tell me that you miss spending four minutes to load a 25K file from the excretable 1541 disk drive? Or spending 40 minutes to download a 25K file on a 300 baud modem from a long-distance BBS when you're paying the phone bill? Or the stupid PEEKs and POKEs. Do you miss typing in hundreds of numbers from Compute's Gazette because the program is written in super-fast 6502 1.2MHz machine code?

The only good thing about the C64 was the keyboard. And once you start talking to your 3GigaHertz PC and having your words appear on the screen as you speak, you don't miss the keyboard. Regardless of how good it is.

Commodore 64's rule!! But, really they suck. Never look back on trash.

I agree that there is nothing wonderful about C64 BASIC, and also wonder why someone would port an awful archaic language to modern PCs, when there are far better BASIC interpreters around already.

However, hardware sound reproduction is something else. SID chips produce a noticeable sound, and sound decks with SIDs built in are worth several thousand dollars and used by many popular recording artists today.

You'll also find the Gameboy has a popular sound production scene associated with it. Look on Yo

I miss ONE particular game that I don't think anyone has managed to re-create. I'd very much appreciate a new version of PSI-5 Trading co [mobygames.com]. You have your standard Elite-esque "trade stuff between planets A, B & C"-thing go on...but the beef is that you command your spaceship *completely* by just giving your crew orders - and they attempt to execute them. So you become Captain Kirk and just bark orders for your Sulu, Chekov and Scotty. I haven't heard of other such games - I mean, you are *always* expecte

Of course this is a useless project! Almost as useless as model airplanes and magic tricks and football and all of the other wonderfully useless things people do to amuse themselves. Don't care for it? Fine, but no need to insult it.

I disagree, though it took me a minute to formulate the counter-reason.

No one is going to attempt to run Pixar graphics on this. The point is a form of "Limited Time Machine" in which we can return to portions of the past (here, the language) but abuse modern hardware to get sickening speed increases. Then we just drift back in our memories a little about that program we wrote Back In The Day, but now it eats Crays for breakfast.

As for SID tunes, yea, that hardware implementation has passed its prime, but e

I used to have a Commodore64 and learned 6502 Assembler on it. When I got a PC (a 286) I felt nostalgic for the C64 and bought a cheap one. I used it about ten minutes and realized what a mistake it was. Fortunately I was able to sell it right away.

When you were young, did your parents forced you to use a C64 while chained to a wall, while expecting for the dialy meal of a dry bread and a dirty glass with tap water?

I've never had a C64, I had a MSX instead but I respected the capabilities of the former.
I don't regret my 8-bit days, the resources were limited but I've learned to write software and enjoyed the games from an era when each improvement was like "wow" instead of "yawn, more polygons per second" of the current games.

And yet, with all the powerful CPUs we have now, CBM still surpasses us in one regard: In the 1980s computers like CBM were sold with a programming language by default, so any new computer owner could (and often had) to learn programming, but today in the 2000s computers are sold with spyware and adware without any mention of programmability, so new computers owners now tend to see the computer as something working automagically like a TV. CBM encourages you to learn programming, today's PCs don't even me

I have an old book on how to build your own telescope from the 1980's that included how to hook up a C64 and use a joystick to control the telescope's movements all written in C64 Basic. I remember porting it to QBasic circa 1994/5 and using it for a telescope I had to account for planetary motion for photography. (Back before every telescope came with such features).

That would almost be fun...wow I really am a geek....*shudders* I'm going back to my cave now.

The main advantage to BASIC is that it's trivial to get simple graphics going so you can learn how to make a wide variety of games without having to get overloaded with information about APIs and whatnot. Unfortunatly most games don't have terrible graphics so beginning programmers tend not to be satisified with large solid colored blocks.

It may be worthwhile to come up with a compiler that expands the BASIC commands to include functions which load various graphics formats into sprites and allow you to dis

5 CLS
10 INPUT "WHAT IS YOUR NAME?"; A$
15 IF A$ = "JOE" THEN GOTO 50
20 PRINT "YOU ARE NOT AS COOL AS JOE, SORRY!"
30 FOR I = 1 TO 10000
35 NEXT I
40 GOTO 5
50 FOR I = 1 TO 20
55 PRINT "JOE IS COOL!"
60 NEXT I
70 FOR I = 1 TO 10000
80 NEXT I

I remember coding a nuissance program in 6510 assembler on my C-64 that sat in the background and when a key was pressed it had a tiny chance not to echo it to the screen or to echo it twice. After installing it on several classroom computers off the old 1541 floppy it drove some students batty, they thought they had sticky keys. This was before real viruses:)

Actually I would guess that it could be the multiplatform code that takes up so much space.I have to hope that they don't support Poke and Peek.C64 basic doesn't support any of the cool features like Sprites and sound.

Version 2 might have to. Poke & his little brother Peek were the Bastard Twins of Commodore Basic. The Commodore 128 took some steps into making a usable Basic, but the '64 was completely unusable without them.