Commodore 64 vs Apple II

[The Usotsuki]

I wonder if Cybernoid would be doable on an Apple ][+. There's already a sound engine that could be dropped in, with the Spectrum sounds.

[high voltage]

Wonder if the OP is even still interested in this thread?

[JamesD]

I wonder if Cybernoid would be doable on an Apple ][+. There's already a sound engine that could be dropped in, with the Spectrum sounds.

The number of on screen objects is probably a bit much to ask from a 1MHz 6502 with no sprite hardware.

[potatohead]

Well, the number of objects on that game is similar to ROBOTRON, which actually plays very well on the Apple.

 

IMHO, some tweaks here and there could make that game work well on the Apple. IMHO, a motion priority system, dropping to byte level moves, and or frame skips on lower priority things would be necessary to preserve the feel of the game.

 

Sound? Hope there is a Mockingboard, or some great sounding game loops

[JamesD]

Well, the number of objects on that game is similar to ROBOTRON, which actually plays very well on the Apple.

 

IMHO, some tweaks here and there could make that game work well on the Apple. IMHO, a motion priority system, dropping to byte level moves, and or frame skips on lower priority things would be necessary to preserve the feel of the game.

 

Sound? Hope there is a Mockingboard, or some great sounding game loops

I think Robotron does the same thing as Gremlins. Not all robots are updated every frame.

[potatohead]

Exactly. There are some primary objects that need good, precise movement and some that really don't. Both byte level moves and movement priorities are used in ROBOTRON with great results. the MSDOS port is similar, BTW.

[Segataritensoftii]

The number of on screen objects is probably a bit much to ask from a 1MHz 6502 with no sprite hardware.

Have you ever seen I.O Silver?

Well, the number of objects on that game is similar to ROBOTRON, which actually plays very well on the Apple.

 

IMHO, some tweaks here and there could make that game work well on the Apple. IMHO, a motion priority system, dropping to byte level moves, and or frame skips on lower priority things would be necessary to preserve the feel of the game.

 

Sound? Hope there is a Mockingboard, or some great sounding game loops

Isn't there a sound routine for the Apple II that allows you to play back crystal clear 8-bit samples? Edited December 13, 2012 by Segataritensoftii

[JamesD]

I think Gremlins uses a simple round robin approach for it's updates but I haven't looked at the disassembly in years.

I've never seen a disassembly or Robotron but BYTE level moves alone would make a huge difference. Robotron had sprites jump in steps anyway so that would work really well for it.

[JamesD]

Have you ever seen I.O Silver?

Isn't there a sound routine for the Apple II that allows you to play back crystal clear 8-bit samples?

I haven't played I.O Silver. I just looked at it in an emulator but didn't figure out the control scheme. I remember seeing it before but that's about it.

It looks like it has 6 or so large moving sprites on the first level? Are there more as the game progresses?

 

People have done playback of 8 bit samples on the Apple II but I'm not sure I'd call them crystal clear. Speech is certainly understandable. I do believe it also stops all action on screen to do it though.

 

 

Cybernoid has a lot of moving objects that often cross each other.

Your ship, the thing that orbits it and it's trail looks like 10 sprites.

I also just counted 14(?) shots fired at the ship and 10(?) pieces of debris from an explosion on screen? Maybe some of those aren't shots.

There are also two other animated objects that are 16x16.

So easily over 20 sprites, some of them large, on screen at once?

They aren't all being updated at once though and the game might combine some of them.

 

The fast moving sprites appear to be a byte wide by 8 pixels high. Most of the larger objects move slower so they wouldn't be difficult at all. My concern was for when you end up with a lot of shots and objects from explosions all going at the same time.

 

One thing you'd have to be careful of is Cybernoid looks difficult to begin with. You wouldn't want to make it any tougher.

[potatohead]

honestly a lot of debris on the screen might slow some things down

 

that is not a bad effect sometimes...

 

i cannot type shifted characters into atari age replies now from my android phone now. wierd

[+FujiSkunk]

People have done playback of 8 bit samples on the Apple II but I'm not sure I'd call them crystal clear. Speech is certainly understandable. I do believe it also stops all action on screen to do it though.

 

Any sound on the Apple II stops all action on screen. That's why games that actually try to have background music, Moon Patrol and Dig Dug for example, do it with a very staccato, xylophone-like style.

 

The worst example I can think of is Gauntlet. In the bonus levels with all the treasure chests, you have the poor Apple II trying to juggle two simultaneous players, scrolling in all directions, and background music. It's... not a pretty sight. Or sound.

[The Usotsuki]

Sound? Hope there is a Mockingboard, or some great sounding game loops

 

The sound engine I was referring to was for the Mockingboard.

[potatohead]

I don't have one. Not sure what it's capable of, and I've only heard it in tandem with the Ultima IV or V game that supported it. Maybe both did.

 

BTW: 8 bit weapon uses a program called DMS Drummer they had somebody develop for them that sounds really pretty good. There is a DMS Music too, both are a lot of fun, and they output via cassette port.

 

Clearly not game type sound, just dedicated, but still better than one would expect.

 

When I wrote game loops, one of the easier Apple sound tricks is to simply drop accesses to the clicker or cassette port into various places in the code. Some loops are very interesting, others not so much. When good ones are found, you have the sound linked to the game for free!

 

A similar thing works on the VCS with TIA to pretty good effect, and I suppose many machines really. I always liked it done that way.

[The Usotsuki]

Well, it's the same sound chip as the MSX, and more or less the same as the Atari ST, so...

[magnusfalkirk]

I don't have one. Not sure what it's capable of, and I've only heard it in tandem with the Ultima IV or V game that supported it. Maybe both did.

 

BTW: 8 bit weapon uses a program called DMS Drummer they had somebody develop for them that sounds really pretty good. There is a DMS Music too, both are a lot of fun, and they output via cassette port.

 

Clearly not game type sound, just dedicated, but still better than one would expect.

 

 

DMS Drummer and DMS Synthesizer were both written by Michael J Mahon, the same person who developed the AppleCrate, AppleCrate II and NadaNet. In fact DMS Synthesizer can be downloaded for free from Michael's page here: http://home.comcast.net/~mjmahon/ down toward the bottom of the page as RT Synth.

[Keatah]

I found the sudoku solver to be an interesting thing. A buddy of mine is champion at this stuff and she's constantly amazed this works so quickly while running on a 1970's hobbyist's computer.

 

http://home.comcast.net/~mjmahon/Sudoku.html

Edited December 14, 2012 by Keatah

[JamesD]

The sound engine I was referring to was for the Mockingboard.

Well, it's the same sound chip as the MSX, and more or less the same as the Atari ST, so...

Be careful, the AY chip may be clocked at a different frequency when going from one platform to another.

The code has to be modified to adjust for the frequency shift or it won't sound the same.

If the software just uses tables for notes or sound settings and separate song or noise data, you have to update the tables.

If the noise or song is just data to be dumped to the AY (like the player I wrote), the music may be off key and sounds will be higher or lower.

If the software uses any type of calculations to determine sound output... ouch. That could be tough to duplicate.

Tables are the most portable but playing sounds takes more clock cycles than just dumping data out.

[JamesD]

I found the sudoku solver to be an interesting thing. A buddy of mine is champion at this stuff and she's constantly amazed this works so quickly while running on a 1970's hobbyist's computer.

 

http://home.comcast....hon/Sudoku.html

Nothing like an efficient algorithm and assembly!

 

Did you check out his SQR function implementation?

[Keatah]

Checking it out now.

[JamesD]

Nothing like an efficient algorithm and assembly!

 

Did you check out his SQR function implementation?

Checking it out now.

For those of you that won't bother, the USR function used in place of the regular SQR is around 9 times faster... but it's 170 bytes.

Since 6502 machines based on Microsoft BASIC all use the same code, they could all benefit from some variation of that code.

Just think of how much faster BASIC could have been if it were bank switched instead of having to fit in a small ROM.

[potatohead]

Yes, so many constraints back then. (I didn't bother, deep into a project at the moment) 9 times faster and 170 bytes! I'll deffo have a look see at some point.

 

I would trade that for more variants on BBC Basic though. IMHO, the inline assembly capability was exactly the right thing to do back then.

[JamesD]

Yes, so many constraints back then. (I didn't bother, deep into a project at the moment) 9 times faster and 170 bytes! I'll deffo have a look see at some point.

I'll give you the abridged version of what it does for now... lots of bit shifts. It's an interesting approach.

 

I would trade that for more variants on BBC Basic though. IMHO, the inline assembly capability was exactly the right thing to do back then.

I don't know, I spent hours trying to decipher the Elite source code. It's not what I'd call a full featured assembler and it's ugly to read as BASIC. On the other hand... it certainly works and it's a pretty fast version of BASIC even without assembly.

 

Lately I've come to the conclusion that a built in PCode interpreter and a separate BASIC compiler would have been a better option. Without having to put all the parsing in ROM you have a lot more room for functions and you end up with a much faster program even without assembly. The lower code density of the 6502 wouldn't be such an issue and whatever ROM space you free up could be used to speed up run time functions like SQR. One of the big advantages of a compiler is that you don't need to loose integers to fit it in the ROM. TRS-80 Level II BASIC supports integers and it's competitive with faster clocked systems as a result. PCode programs are also likely to take less RAM so you can build larger programs. And lets face it, a lot of people didn't write BASIC code, they just used other people's programs.

 

If you dig up the old thread on benchmarking BASIC, the PCode compilers would execute things in under 30 seconds that would normally take several minutes in an interpreter.

[JamesD]

Just for the record, I realize it's a bit much to expect a compiler when the Apple II was introduced, but Woz did include the Sweet 16 interpreter which is a simplified PCode interpreter of sorts. By the time the C64 was introduced, a compiler would have been a very real possibility. I've found Small-C compilers that output PCode that date to the late 70s or early 80s.

[JamesD]

<deleted> Wrong thread

Edited December 17, 2012 by JamesD

[JamesD]

Without hijacking the current thread direction, I found the original box for my Videx 80-column card (slot 3 for the II+). It has a price tag of 379.95 on it.

The May 1981 issue of MICRO 6502 Journal has an ad listing 80 column cards for $335.

The Apple language card with Pascal was $425! Ouch! In a 1980 issue I think it was over $500 and 3rd party versions were $225.

An Apple serial or parallel card was $155.