Jump to content
IGNORED

What's so fantastic about Atari 8 bitters?


SIO99

Recommended Posts

The 6502 had 3 big features IMO:

1. Cheap. Way cheaper than any other CPU at the time. It ushered in an era of affordable computers.

2. Good performace with low clock speeds. The ability to get a lot done with a 1~2MHz clock helped simplify system design.

3. Easy to learn. The instruction set is concise and quite flexible considering the number of opcodes. I rarely have to look up how to do something on the 6502, but I keep the book open at all times for Z80 code.

 

Many of the 6502's limitations simply require a different approach to the problem rather than a straight port of the code. And then there are some things the 6502 doesn't do well at all.

Link to comment
Share on other sites

Are you a double agent from Commodore?

 

Double agent? No, that'd imply that i make some kind of secret of liking or having twenty five years coding experience with the C64. i've also got seven years programming the Atari 8-bit in machine code and a fairly extensive list of other platforms under my belt, but people here seem to forget that as soon as the C64 is mentioned...

 

This is the first time I've heard of any claim of accessing anything like 63K RAM on a Commodore 64. I could try and sum up what a certain magazine said.

 

[snip for brevity]

 

Short version; never trust a magazine to give you correct technical information without consulting a programmer too. =-)

 

The only truly tricky space to use is under the I/O - disabling it turns off the VIC-II, SID and I/O registers as well as the colour RAM (which exists outside of the standard 64K, technically a C64 has a little shy of 65K), but you can still write to the screen RAM in that state and the most common use for that area i've seen is graphics data - which has to be somewhere, so might as well be in the space it's a little harder to keep code in.

 

The Sinclair Spectrum 48K had more RAM free to BASIC than the Commodore 64!

 

No, it has more free RAM for BASIC programs but not to BASIC as a whole. Have a look at the C64's memory map at $c000 to $cfff, that space is available for BASIC to use for storage, data, graphics whatever. 4K on top of the 38K for BASIC programs is 42K.

 

Oh, and getting back onto the topic at hand; what Heaven said about WSYNC.

 

Please post a BASIC program which opens a graphics screen on a Commodore 64, clears the screen of any garbage which I think may be there, then draws a line across the screen. Feel free to post an Assembly Language program that does the same thing.

 

 

I've done some more research into the numbers of BASIC commands on the Commodore 64, as well as on rival computers and here they are.

 

Click here for a full list of Commodore 64 BASIC commands (total 71) -

 

http://www.c64-wiki....hp/C64-Commands

 

Click here for a full list of Sinclair Spectrum BASIC commands (total 86) -

 

http://en.wikipedia..../Sinclair_BASIC

 

Click here for a full list of Amstrad Locomotive BASIC commands (total 165) -

 

http://cpcwiki.eu/in...ocomotive_BASIC

 

Click here for a full list of Atari BASIC XL commands (total 82)

 

http://www.atariarch...ge.php?page=376

 

Note that it only takes 11 more commands (82 instead of 71) to make a reasonable BASIC dialect. I hope this proves conclusively that Commodore either just didn't care, were too stingy to pay anyone to create a new version of BASIC for the Commodore 64, or BOTH! We'll never know how many would be programmers had their confidence shattered by the Commodore 64. I can't help wondering how or why anyone managed to learn how to program it in 6502 Assembly Language, running on the compatible 6510 CPU. My theory is that some programmers learnt on the excellent Atari 8 bit range of computers, then were also able to put this knowledge to use on the Commodore 64. I read that one British software house hated the Commodore 64 so much, that they programmed games for it using a development kit running on the BBC Micro. Apart from anything else, the Commodore 64 was a revamped version of the Commodore Max games console (which included a keyboard), that it seems only went on sale in Japan. This had two versions of BASIC available, one without the ability to SAVE or LOAD programs, the other with only 2047 bytes free to BASIC! I don't know if any RAM upgrades were available. For more information on this botched pile of crap click on the two links below!

 

http://en.wikipedia....ore_MAX_Machine

 

http://www.northnet....or/cbm/max.html

 

As for me, I think I've been psychologically damaged by trying to program a Commodore 64 and I need hypnotherapy to forget all about it. I hope to buy an Atari 8 bit computer from eBay soon, complete with any storage device, as part of some therapy to get over all this. This year is the 30th anniversary of the Commodore 64 being released, but it's certainly nothing to celebrate. The far more advanced Sinclair Spectrum (86 BASIC commands instead of 71) came out the same year.

 

When you refer to Atari BASIC XL, do you mean the rev. B&C Atari BASIC in XL machines, or are you refering to BASIC XL from OSS (original writers of Atari BASIC)? Then there's also BASIC XE to consider and Turbo BASIC. How many commands do they each have?

Link to comment
Share on other sites

I think the SIO system was a really clever idea. Nothing could be easier than connecting your new peripheral to the last one you connected. That way, you don't have cable hell fanning out of the console, and you don't need 10 different kinds of cable at your disposal. Of course, SIO has its limitations, which is why PBI was invented. Overall, it was a very user-friendly approach to expansion.
I agree with that, SIO was like today's USB in many ways, just plug and play. But, though I lack the knowledge of Commodore that I have with Atari, it seems to me that Commodores serial lines worked essentially the same way, with daisy-chaining, so it's not entirely unique to Atari. Is Atari SIO better than Commodore serial? Anyone? It certainly was better than Texas Instruments solution with the 99/4A line, where they just attach the next device to the side of the previous one and end up with a system 10 feet wide! LOL!

Actually, the protocol for Atari's SIO protocol and the USB protocol have a lot of similarities.

 

Commodore's IEC interface details. It also has similarities to SIO and USB.

http://jderogee.tripod.com/project1541_downloads/IEC_1541_info.pdf

 

Keep in mind that Commodore's IEC interface was based on the buss on the PET, which is IEEE-488 which came before IEC and SIO,

So IEC and SIO were just an evolution of existing technology.

Link to comment
Share on other sites

When you refer to Atari BASIC XL, do you mean the rev. B&C Atari BASIC in XL machines, or are you refering to BASIC XL from OSS (original writers of Atari BASIC)? Then there's also BASIC XE to consider and Turbo BASIC. How many commands do they each have?

I think he was referring to Atari BASIC in the XL.

Link to comment
Share on other sites

The 6502 had 3 big features IMO:

1. Cheap. Way cheaper than any other CPU at the time. It ushered in an era of affordable computers.

2. Good performace with low clock speeds. The ability to get a lot done with a 1~2MHz clock helped simplify system design.

3. Easy to learn. The instruction set is concise and quite flexible considering the number of opcodes. I rarely have to look up how to do something on the 6502, but I keep the book open at all times for Z80 code.

 

Many of the 6502's limitations simply require a different approach to the problem rather than a straight port of the code. And then there are some things the 6502 doesn't do well at all.

WOZ said the 6502 was 1/4 the price when the Apple was being designed, but that was the Apple 1. When did they start, 1975?

Sure, the 6502 kicked things off but there were certainly affordable Z80 machines out before the Atari was introduced, so I think price difference was significantly less than that by the time the Atari hit.

 

The Z80 had been big in CP/M computers and the TRS-80 Model I certainly came out before Atari and at a lower price.

For that matter, the TRS-80 Color Computer was introduced around $500 with a 6809 only a year behind the Atari 8 bit.

Price differences couldn't have been that big by then or that wouldn't have been possible.

 

I believe the Z80 had built in DRAM refresh so that simplified system design and required fewer parts.

There are Pros and cons to all of these CPUs.

 

Frankly, if I had to place a difficulty rating on them, the 6800/6803/6809 CPUs were easiest to learn.

The 680X CPUs have fewer register dependencies (accumulator or address) for instructions than with the Z80 (HL, IX, IY, etc... all have special instructions), and the 680X CPUs are less tedious to program than the 6502.

I didn't find any of them particularly difficult to learn though.

Link to comment
Share on other sites

Most Z80 programmers look at the 6502 like that, but the actual situation is a little more complicated; with the Z80, a register pair has to be used as pointers to a location in RAM so it's possible to run out of registers quite quickly if accessing multiple locations in one pass. With the 6502, the registers don't point at addresses in that way and instead two bytes of the zeropage (the first page of memory, which can be addressed faster than the rest of it) take care of the address and the registers are used for moving data between points and offsets from those addresses.

While that is somewhat true, my experience has been that Z80 code is slightly smaller than 6502 code, mostly due to the lack of 16 bit support in the 6502.

 

True, but i was only really commenting on how some Z80 coders look at the three registers and not past them to the ZP really, not actually thinking about which is better or anything. Personally i use self modifying code a lot in 6502 (if it's mine and not running from ROM, it'll be self mod) so running out of ZP has never been an issue for me (in fact i rarely use the ZP at all and barely touch the stack either apart from stashing registers on the way into an interrupt and grabbing them back before the RTI).

 

I really don't see the 6502 as one of the great features of the Atari except possibly that it made it easier to port existing code to.

 

Personally, i like the 6502 as a CPU, but my experience of Z80 so far has been quite interesting too; either way, if you know what you're doing and the hardware wrapped around it is well designed (or in some cases, minimal enough that it doesn't matter), you can make it jump through all manner of fun hoops.

  • Like 2
Link to comment
Share on other sites

It certainly was better than Texas Instruments solution with the 99/4A line, where they just attach the next device to the side of the previous one and end up with a system 10 feet wide! LOL!

TI pretty much doomed their machine before they even started production.

And that was one of the ways they doomed it.

Edited by JamesD
Link to comment
Share on other sites

It certainly was better than Texas Instruments solution with the 99/4A line, where they just attach the next device to the side of the previous one and end up with a system 10 feet wide! LOL!

TI pretty much doomed their machine before they even started production.

And that was one of the ways they doomed it.

I always thought it was dumb to devote a third of the usable space to a cartridge slot and cram a reduced keyboard in the remaining area. Not sure what they were thinking.

Link to comment
Share on other sites

It certainly was better than Texas Instruments solution with the 99/4A line, where they just attach the next device to the side of the previous one and end up with a system 10 feet wide! LOL!

TI pretty much doomed their machine before they even started production.

And that was one of the ways they doomed it.

I always thought it was dumb to devote a third of the usable space to a cartridge slot and cram a reduced keyboard in the remaining space. Not sure what they were thinking.

"We are TI, bow down before us!"

?

 

I wondered about the lack of internal RAM expansion.

among other things

Edited by JamesD
Link to comment
Share on other sites

claim that it had 64K RAM, although it turned out there was no way of using more than about 38-39K using Machine Code.

 

Actually there are some games that use just over 50K FYI :)

 

At the time when my friend had his 800 and I'd got a C64 we used to have marathon gaming sessions on either.

 

What I really liked about the 800 my friend had was the punchy sound effects in games, sort of like a VCS++ :)

Edited by oky2000
  • Like 1
Link to comment
Share on other sites

Barring some of those things, I liked the Atari BASIC because it did include commands for some of the better machine features, and it was fairly quick compared to some. APPLESOFT was slower, though the integer BASIC was significantly faster. You know, the VIC 20 was damn fast in BASIC. That BASIC didn't do much, but a little assembly added, and I thought it was pretty sweet. You all benchmarked the various machines right? We did.

I'm pretty sure Applesoft benchmarked as being faster than Atari BASIC in Amazing Computing. I think Atari was dead last actually. I did see some posts about what could be done to speed up the Atari, turning off some sort of interrupts(?)... but that may only make sense for benchmarking since you are disabling something that may be needed by some programs. Besides, other machines could have been sped up for the benchmarks with POKEs.

My CoCo spent most of it's life at double speed (POKE 65495,0) and I know temporarily disabling keyboard handling through POKEs (altering the interrupt handler) would speed up a few machines as well. It seems to me that bypassing keyboard polling would speed up some machines by over 20% since they polled during every vertical blank interrupt and it was a time consuming operation. But then how far are you willing to go to get better benchmark results?

 

Benchmarks don't always guarantee faster results anyway; it depends on what you are doing. Atari's programmable fonts, Player-Missile graphics, etc... could make screen draws faster than Apple II's bitmapped graphics. Compute programmers seemed to like font based games from what I remember. It usually meant Applesoft versions were much larger.

Compute did eventually publish a program that let you have programmable fonts on a hi-res display from Applesoft. Several games were based on it because it made porting easier.

 

I don't think I ever saw a decent CoCo version of a game in Compute. I don't remember them ever using Extended Color Basic and didn't seem to be interested in 6809 assembly at all. Any wonder why CoCo enthusiasts never wanted to subscribe to their magazine? Strange considering they could have been almost identical to IBM versions.

 

 

 

Another awesomeness was the goodies one found in the magazines! What a great time! Miss that the most. Go with Mom to snag some food, and score BYTE, COMPUTE, ANTIC, etc... Run home, fire up the machine, and GO! Good stuff would happen or a type in game. COMPUTE actually published some pretty great ones, featuring assembly language.

I have to agree. For the cost of a magazine and a little time, you could have several new programs.

This is something that has disappeared from the computing culture today.

You had the source code and could customize it however you wanted.

Link to comment
Share on other sites

I've done some more research into the numbers of BASIC commands on the Commodore 64, as well as on rival computers and here they are.

 

Click here for a full list of Commodore 64 BASIC commands (total 71) -

 

http://www.c64-wiki....hp/C64-Commands

 

Click here for a full list of Sinclair Spectrum BASIC commands (total 86) -

 

http://en.wikipedia..../Sinclair_BASIC

 

Click here for a full list of Amstrad Locomotive BASIC commands (total 165) -

 

http://cpcwiki.eu/in...ocomotive_BASIC

 

Click here for a full list of Atari BASIC XL commands (total 82)

 

http://www.atariarch...ge.php?page=376

 

Note that it only takes 11 more commands (82 instead of 71) to make a reasonable BASIC dialect. I hope this proves conclusively that Commodore either just didn't care, were too stingy to pay anyone to create a new version of BASIC for the Commodore 64, or BOTH! We'll never know how many would be programmers had their confidence shattered by the Commodore 64. I can't help wondering how or why anyone managed to learn how to program it in 6502 Assembly Language, running on the compatible 6510 CPU. My theory is that some programmers learnt on the excellent Atari 8 bit range of computers, then were also able to put this knowledge to use on the Commodore 64. I read that one British software house hated the Commodore 64 so much, that they programmed games for it using a development kit running on the BBC Micro. Apart from anything else, the Commodore 64 was a revamped version of the Commodore Max games console (which included a keyboard), that it seems only went on sale in Japan. This had two versions of BASIC available, one without the ability to SAVE or LOAD programs, the other with only 2047 bytes free to BASIC! I don't know if any RAM upgrades were available. For more information on this botched pile of crap click on the two links below!

First of all, starting in 1984, Commodore sold a Basic Upgrade Cart for the C64 called Simon's Basic that added 91 additional commands to C64 BASIC. If you wanted or needed more commands, they were certainly available.

 

Second, your statement about a "reasonable BASIC dialect" is opinion.

Some magazines regularly carried programs for both machines and the C64's BASIC seemed up to the task.

While some things had to be done with POKEs or machine language, the same can be said about Atari BASIC.

Try moving an Atari Player sprite image up and down quickly, or make it animate without machine language. Those things could be done fast in C64 BASIC just POKEs.

Face it, all machines from that time had their own advantages and disadvantages.

If you spent much time programming a machine, you learned the tricks for that machine.

To this day I still remember some of the ROM CALL addresses for Applesoft BASIC. (CALL -151 for example)

 

I'm only talking about the BASIC supplied by Commodore on the internal ROM, because this was the version that was installed on all Commodore 64 computers. I don't think the BASIC ROM was ever updated, but I think the Kernal ROM was, because I typed in a very long program from a book, checked it thoroughly for errors and it wouldn't RUN! I also read some articles in magazines which suggested there were different ROM versions. I think Commodore should have provided free BASIC ROM upgrades for all Commodore 64 users. It seems to me their attitude was "We've already got their money, so now why should we care?" The reasons I'm not talking about Simon's BASIC, is because that or another extended BASIC by Commodore should have been the BASIC on the Commodore 64. Simon's BASIC was only any good for writing programs for personal use, or for a small number of people. This is because programs written under Simon's BASIC could only run on a Commodore 64 which had Simon's BASIC installed. Due to the fact that most computer owners (over 90%?) of that time didn't do programming, this meant that hardly anyone would have Simon's BASIC installed, so there was no market for budding programmers' software written using Simon's BASIC. I think it cost about £50. The solution was to sell your Commodore 64, then buy another computer with the proceeds plus the £50 you saved by not buying Simon's BASIC! Don't forget, there were also lots of other extended BASIC interpreters for the Commodore 64 available, on cassette and cheaper, which made Simon's BASIC even less popular than it might have been. One of these was called "Turbo BASIC", which probably had no connection with Atari Turbo BASIC. There was a fantastic magazine about programming called "Input", published in 52 instalments. This contained listings for the Sinclair Spectrum, Commodore 64, Acorn Electron/BBC, Dragon 32/Tandy CoCo, plus some programs for the Sinclair ZX81, and Commodore Vic-20. I only started buying this from Issue 4, missing the all important Issue 3, which revealed how seriously lacking Commodore 64 BASIC was. I later bought a complete set from eBay. I don't think I'm allowed to quote three paragraphs from "Input" here, so I'll sum up in my own words what they said. The Commodore 64 has varied and powerful graphics, but Commodore 64 BASIC isn't designed to use the hires graphics, only the alphanumeric and graphics characters. It's best to start by buying the extra Simon's BASIC cartridge, which provides commands necessary to use sound and graphics. It contains 18 graphics commands, but programs written in Simon's BASIC won't run unless this cartridge is fitted.

 

BTW, I'm still waiting for a program from any Commodore 64 apologists which draws a line across the screen, either in Commodore BASIC V2.0 or Assembly Language.

Edited by SIO99
Link to comment
Share on other sites

the 6502 was a good CPU for the Atari.

 

You think people didn't pay enough heed to the abilities of the Atari as it was? Just look at what happened with the Amstrad CPC - having a Z80 and a screen that could be configured in a similar manner to the Spectrum meant ports got shovelled across and looking no better than the Speccy originals. Had the Atari had a Z80 at its heart I'm pretty sure you'd have got the same.

Link to comment
Share on other sites

the 6502 was a good CPU for the Atari.

 

You think people didn't pay enough heed to the abilities of the Atari as it was? Just look at what happened with the Amstrad CPC - having a Z80 and a screen that could be configured in a similar manner to the Spectrum meant ports got shovelled across and looking no better than the Speccy originals. Had the Atari had a Z80 at its heart I'm pretty sure you'd have got the same.

 

There were some ports from the Spectrum where the graphics looked similar (i.e. large areas with the same foreground colour), but others with better graphics. I'm sure people can also say that the Atari had ports from the Commodore 64 which didn't look any better than the originals. The Amstrad CPC also had various games where the graphics were in the same resolution as the Commodore 64, meaning 160x200 with 16 colours, but on the Amstrad the 16 colours could be from a palette of 27 colours, instead of always the same 16 colours, and each colour could be absolutely anywhere on the screen, instead of being limited to 4 colours in each 8x8 character cell.

Link to comment
Share on other sites

the CPC was a lovely static graphics machine, but it was let down on 3 fronts:

 

1) too similar to spectrum - see previous post

2) too much screen memory to shovel around and build a game around it. There were some good efforts when people got used to it though, and the upgraded plus machines were a brilliant vision of what could have been given hardware sprites, albeit far too late.

3) the bloody greenscreen model. my cousin had one and we thought the games looked okay-ish, but we figured it'd all be so much better in colour. One colour modulator later and you found that there were some bloody *hideous* colour combinations chosen because they gave better contrast on the greenscreen.

Link to comment
Share on other sites

the CPC was a lovely static graphics machine, but it was let down on 3 fronts:

 

1) too similar to spectrum - see previous post

2) too much screen memory to shovel around and build a game around it. There were some good efforts when people got used to it though, and the upgraded plus machines were a brilliant vision of what could have been given hardware sprites, albeit far too late.

3) the bloody greenscreen model. my cousin had one and we thought the games looked okay-ish, but we figured it'd all be so much better in colour. One colour modulator later and you found that there were some bloody *hideous* colour combinations chosen because they gave better contrast on the greenscreen.

 

Well, this thread isn't about the Amstrad CPC, it's about Atari 8 bitters. Please try to stay on topic! Here's a more general question, which could apply equally to the Atari, as well as to the Amstrad CPC. When I got my Amstrad CPC, I thought that I'd be able to do absolutely anything on it, including writing some games, or even drawing a portrait of something just by using BASIC commands. Unfortunately, I failed to do either of these things. So, here's a question about the fundamentals of games programming. By "games programming" I don't necessarily mean shooting at things. A more original game could be to do with any way of interacting with people around you. Your Player graphic would still need to go up to another character in the game, though. The fundamental thing about this is that if your coordinates are X1 and Y1 and your opponent's coordinates are X2 and Y2, IF X1=X2 AND X2=Y2 THEN GOSUB [linenumber]. Unfortunately, things aren't quite that simple, otherwise I'd have written some games on the Amstrad CPC. I hope people reading this can explain what else is involved and what can go wrong.

 

At the moment I'm studying the book "The Creative Atari" and am just finishing the section on Player Missile Graphics. This is followed by user defined graphics characters (UDGs), which was the only method on various computers, including the Amstrad CPC, Sinclair Spectrum, BBC Micro/Electron, Dragon, Tandy Coco, Apple II, and some others. Before getting out of bed today, I designed a Player in a classic superhero pose, which is 8 pixels x 28 pixels!

Edited by SIO99
Link to comment
Share on other sites

What's so fantastic?

 

As already mentioned by experts in issue 5 of ZZAP!64 (a Commodore 64) magazine, and later confirmed in Retro Gamer magazine, Atari 8 bit, the Porsche of home computers:

 

atarifromretromag.jpg

 

nuff said !!!!!!!!

 

I wish I could read that article!

 

Anyway, I've just adapted the last program in The Creative Atari book section on Player Missile Graphics to display the player I designed earlier today and move it across the screen, as well as in whatever colour I want! One disappointment was that it came out too short or squat, which is to do with one of the register values I haven't yet managed to use. I thought it was POKE 559,46 instead of POKE 559,62, but all I achieved with 46 was to make my Player disappear! Can someone point out what I need to do instead? For now I'll study the next chapter on user defined graphics characters or UDGs.

Link to comment
Share on other sites

I'm only talking about the BASIC supplied by Commodore on the internal ROM, because this was the version that was installed on all Commodore 64 computers. I don't think the BASIC ROM was ever updated, but I think the Kernal ROM was, because I typed in a very long program from a book, checked it thoroughly for errors and it wouldn't RUN! I also read some articles in magazines which suggested there were different ROM versions. I think Commodore should have provided free BASIC ROM upgrades for all Commodore 64 users. It seems to me their attitude was "We've already got their money, so now why should we care?" The reasons I'm not talking about Simon's BASIC, is because that or another extended BASIC by Commodore should have been the BASIC on the Commodore 64. Simon's BASIC was only any good for writing programs for personal use, or for a small number of people. This is because programs written under Simon's BASIC could only run on a Commodore 64 which had Simon's BASIC installed. Due to the fact that most computer owners (over 90%?) of that time didn't do programming, this meant that hardly anyone would have Simon's BASIC installed, so there was no market for budding programmers' software written using Simon's BASIC. I think it cost about £50. The solution was to sell your Commodore 64, then buy another computer with the proceeds plus the £50 you saved by not buying Simon's BASIC! Don't forget, there were also lots of other extended BASIC interpreters for the Commodore 64 available, on cassette and cheaper, which made Simon's BASIC even less popular than it might have been. One of these was called "Turbo BASIC", which probably had no connection with Atari Turbo BASIC. There was a fantastic magazine about programming called "Input", published in 52 instalments. This contained listings for the Sinclair Spectrum, Commodore 64, Acorn Electron/BBC, Dragon 32/Tandy CoCo, plus some programs for the Sinclair ZX81, and Commodore Vic-20. I only started buying this from Issue 4, missing the all important Issue 3, which revealed how seriously lacking Commodore 64 BASIC was. I later bought a complete set from eBay. I don't think I'm allowed to quote three paragraphs from "Input" here, so I'll sum up in my own words what they said. The Commodore 64 has varied and powerful graphics, but Commodore 64 BASIC isn't designed to use the hires graphics, only the alphanumeric and graphics characters. It's best to start by buying the extra Simon's BASIC cartridge, which provides commands necessary to use sound and graphics. It contains 18 graphics commands, but programs written in Simon's BASIC won't run unless this cartridge is fitted.

I don't disagree, just saying it was available if you wanted it. The C64 really should have had the BASIC that came in the Plus/4.

 

BTW, I'm still waiting for a program from any Commodore 64 apologists which draws a line across the screen, either in Commodore BASIC V2.0 or Assembly Language.

Drawing lines isn't difficult, I just don't think any of the C64 people here are quite that adept at programming.

A Bresenham line routine in BASIC would be kinda slow so assembly would probably be best.

 

There is assembly source to a fast line drawing routine in one of the web magazines someone put out.

Commodore hacker or something like that. It was part of a 3D library.

I have no idea how to adapt it for use with C64 BASIC though.

 

A C64 hacker could also base one on a line routine for the Atari I found on the web.

I used the Atari one as a partial guide for a line routine for the Tandy MC-10.

Link to comment
Share on other sites

I'm pretty sure Applesoft benchmarked as being faster than Atari BASIC in Amazing Computing. I think Atari was dead last actually.

 

Seriously? Worse than Commodore BASIC V2 for speed?! That really surprises me.

 

I have to agree. For the cost of a magazine and a little time, you could have several new programs.

This is something that has disappeared from the computing culture today.

You had the source code and could customize it however you wanted.

 

There was a type-in in the 100th issue of Retro Gamer a few months back... but it's all machine code as data statements and SIO99 will utterly hate it because it's for the C64. =-)

Link to comment
Share on other sites

Atari Basic is slow for 3 main reasons.

 

Floating Point package based on generic code which crippled it from the onset. As a comparison, Commodore's Basic has to convert constants from Ascii to FP before doing calculations but still manages to do them quicker.

 

Regardless of destination, it scans from the start of the program for GOTO / RETURN / NEXT etc. jumps. Commodore's Basic at least bothers to compare the high byte of the destination and scan ahead if it's greater, some other Basics gain speed by putting actual line addresses onto the stack for loops/subroutines.

 

Tight size - there's a lot in that 8K compared to many comparable Basic interpretors, speed optimisations sacrificed to provide more functionality.

Link to comment
Share on other sites

Well, I don't think there's any point comparing Commodore 64 BASIC's speed in the few things it can do, to Atari BASIC's speed in the many things it can do.

 

Progress report - I've just managed to redefine an Atari character into one I've just designed myself! I'm sure that at this rate I'll soon have all the Players and UDGs ready for a game I'm writing. :-))

Link to comment
Share on other sites

I don't think the BASIC ROM was ever updated, but I think the Kernal ROM was, because I typed in a very long program from a book, checked it thoroughly for errors and it wouldn't RUN!

 

Here's what the Commodore 64 Programmer's Reference Guide has to say about the Kernel:

 

One of the problems facing programmers in the microcomputer field is the question of what to do when changes are made to the operating system of the computer by the company. Machine language programs which took much time to develop might no longer work, forcing major revisions in the program. To alleviate this problem, Commodore has developed a method of protecting software writers called the KERNAL.

 

Essentially, the KERNAL is a standardized JUMP TABLE to the input, output, and memory management routines in the operating system. The locations of each routine in ROM may change as the system is upgraded. But the KERNAL jump table will always be changed to match.

 

In other words no, the reason the program didn't work wasn't because the Kernel ROM was changed; if it was BASIC then Commodore BASIC uses the jump table, if it was machine code and didn't use the jump table like the official reference guide says to, you have to look at the programmer for not coding it correctly rather than the C64. And of course, since it was a type-in there's a very good chance that the listing itself was at fault, errors crept into many of them during the typesetting process and any magazine publishing listings usually had to carry corrections later on.

 

BTW, I'm still waiting for a program from any Commodore 64 apologists which draws a line across the screen, either in Commodore BASIC V2.0 or Assembly Language.

 

Feel free to keep waiting, although with your attitude i can't see why anyone'd write sample code for you - right now you're coming across like the nutter on the bus because everybody is saying the same thing as you about how bad Commodore BASIC V2 is, but for some reason you're still banging on about it.

Link to comment
Share on other sites

I don't think the BASIC ROM was ever updated, but I think the Kernal ROM was, because I typed in a very long program from a book, checked it thoroughly for errors and it wouldn't RUN!

 

Here's what the Commodore 64 Programmer's Reference Guide has to say about the Kernel:

 

One of the problems facing programmers in the microcomputer field is the question of what to do when changes are made to the operating system of the computer by the company. Machine language programs which took much time to develop might no longer work, forcing major revisions in the program. To alleviate this problem, Commodore has developed a method of protecting software writers called the KERNAL.

 

Essentially, the KERNAL is a standardized JUMP TABLE to the input, output, and memory management routines in the operating system. The locations of each routine in ROM may change as the system is upgraded. But the KERNAL jump table will always be changed to match.

 

In other words no, the reason the program didn't work wasn't because the Kernel ROM was changed; if it was BASIC then Commodore BASIC uses the jump table, if it was machine code and didn't use the jump table like the official reference guide says to, you have to look at the programmer for not coding it correctly rather than the C64. And of course, since it was a type-in there's a very good chance that the listing itself was at fault, errors crept into many of them during the typesetting process and any magazine publishing listings usually had to carry corrections later on.

 

BTW, I'm still waiting for a program from any Commodore 64 apologists which draws a line across the screen, either in Commodore BASIC V2.0 or Assembly Language.

 

Feel free to keep waiting, although with your attitude i can't see why anyone'd write sample code for you - right now you're coming across like the nutter on the bus because everybody is saying the same thing as you about how bad Commodore BASIC V2 is, but for some reason you're still banging on about it.

 

Yes, Commodore BASIC V2 is really bad! I typed in a program from a book, so there was no correction later on, like with some magazines. It was a graphics program. How should I have known what to do about it?

 

Of course, the Commodore 64 hasn't had much publicity for being a computer with an antique BASIC compared to nearly all other computers on the market at the same time, so I feel I need to publicise that.

 

Anyway, another progress report is that I've discovered that the Player I designed was 4 times the width it was supposed to be, because the program I adapted to display it had POKEd the relevant memory location to do that. I found out from another program that this location was 53256, so then I changed the value POKEd from 3 to 0, then to 1. Of course, it would've been more helpful for the original program to have a REM pointing out what this location was, or to define it as something meaningful, such as SIZE0, but it didn't take me long or cause me that much stress to find out. Well done Atari!

Edited by SIO99
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...