Fröhn

Yes about 30% more cycles. Not 80% which you imply when you pull out your 1.77 vs 0.985 MHz comparision and by far not the "A8 is 2x faster than C64" which you often said already. EDIT: 30% when comparing PAL machines. When comparing NTSC machines the difference is 20%.

The A8 loses: 9 DRAM refresh cycles per rasterline (2808 cyles per PAL frame, 2358 cycles per NTSC frame) bitmap 160x192 @ 4 colors / bitmap 320x192 @ 2 colors / bitmap 80x192 @ 16 colors: 7680 cycles per frame + ~200 cycles for display list text mode 40x24 characters: 8640 cycles per frame + ~30 cycles for display list - 192 refresh cycles not executed Modes with less bytes/rasterline also need less cycles, i.e. double pixel height modes will only eat half the cycles. PMs eat 5 cycles per rasterline every rasterline if enabled.

That's kinda my point too: The collision bits of the A8 ARE superiour, but I don't think that feature is that important at all. It has it's limits (I explained already) and when a game wants to pass this limits, it has to do it's own software implementation.

Especially the A8 doesn't have sprites to be wasted. And I wouldn't waste a sprite on C64 either only to avoid coding a bounding box collision detection routine. Also this still would not solve the problem of finding the actual collision point.

You have completely misunderstood the purpose of bounding boxes. The reasons for bounding boxes are: Having different hit-zones than the sprite gfx itself to improve gaming experience (bigger hitzones for enemies, smaller for players). Avoiding the "jump-back"-feeling when you have a collision detection for sprites/background you cannot pass. If you used the hardware collision detection, you would first walk into the other sprite, then a collision is detected and then the game engine would move you back outside the other sprite. With bounding boxes you can virtually move the sprite into another sprite without displaying that AND you have the ability to calculate the exact position of the collision instead of having a "already gone inside the other object" position. A "sprites may touch but don't cover pixels"-collision detect, i.e. walking on top of other sprites and stuff like that. All the things you have in more sophisticated games and none of them can be done by the hardware collision detection.

No, it's "useless" because once you really code a game engine you will use bounding boxes anyway for multiple reasons already explained. WSYNC is simply overrated. In most situations a few NOPs would give you the same result.

Yes it's doing 640 px but over composite you will only get blurred stuff which has an effective resolution of ~320 (but looks smooth at that). Y/C or RGB is a different matter ofcourse.

Composite cannot handle the 640 px resolution. Even 320 is pretty much at the limit what composite can do.

Sprite multiplexing is a major reason to have IRQs not bound to character lines. WSYNC is not as important as you might think. For most things (sprite mux'ing, rasterbars, screen splitting, sprite stretching, open upper/lower border etc) you don't need it.

Quoted for the truth. Quoted for being a biased sidekick. If you can't present it in poem-style, then you have no point! No, seriously, what Frohn stated is just how the more advanced C64 shmups do it. And the less frustrating ones use a hitbox that is a _little_ smaller than the sprite for the player and maybe one that is a _little_ larger for the enemies. Yeps that's the main reason to prefer bounding boxes, but there are other scenarios where hardware based collision detection will not help you at all: Detecting collisions before they actually happen and a touching collision where no pixel covers another pixel (for example: game character standing on top of another sprite but not IN the other sprite). EDIT: Especially when you are actually "colliding" (as in: you cannot move past another sprite) bounding boxes are highly superiour. With hardware based collision detection you will move a bit inside the other sprite, then the collision detection will notice that there was a collision and the game then will move you back outside this sprite. The result is a very jerky collision detection with a bad look & feel.

Green Beret uses bounding boxes too. Games using hardware collision detection are usually pretty old (1984 or earlier).

Good games do a bounding box based collision detection anyway. It's always a horror when a game lets you die because the out pixel at your shoe touched the topmost hair pixel of a bad guy.

I have the same feeling when watching A8 stuff. The larger palette seems to lead people to choose more similar (often monochrome) colors.

Verify: OPEN 1,8,15,"V":CLOSE 1 Format: OPEN 1,8,15,"N:<disk header>,<id>":CLOSE 1 Rename: OPEN 1,8,15,"R:<new filename>=<old filename>":CLOSE 1 Delete (Scratch): OPEN 1,8,15,"S:<filename>":CLOSE 1 With a cartridge you can use either @<dos command> or DOS"<dos command>" instead of the OPEN/CLOSE stuff. There also is a copy command but it only works on the old dual disk drives for PET.

Yes. Theoretically you can install a driver for it by redirecting the DOS vectors. That's also how fast loaders are installed. There's also dedicated data exchange programs like "Big Blue Reader" which reads MS-DOS disks, and ofcourse there is CP/M for C128 which reads CP/M disks.

"*" is a wild card and LOAD"*",8 would load the first file from disk. $ is the directory file, not a wild card. 8 is just the first disk drive. 1 would be the tape drive, 4 would be a printer, 9 would be the 2nd disk drive etc.

Yes. The drives are programmable down to "encoded bits on disk" level.

Well for a CBM user it's also strange to use an Atari. CBM users are used to having all DOS options available without booting anything. Ok, most C64 users are used to those multifunction cartridges which also have DOS wedge extensions so the comparision is a bit unfair, but it was pretty much standard to have such a thing. The cart DOS extensions made it a hell lot of easier and faster to use the C64. Instead of typing BASIC commands, you simply used the F-keys and Cursor-keys. Action Replay type of carts worked like this: F3 for directory, F1 for load + run. If you pressed F1, it would simply load the first program on disk and run it. If you moved the cursor to a line in the directory and pressed F1, it would load that file and run it. I found this much easier to use than the DOS'es I have encountered on A8.

I wish you had said, "It is possible to use some different cartridge ROMs than the built-in ones." Doing so isn't directly supported and therefore there are no guarantees that the user will meet with success. Definitely a YMMV situation. I never said "all". Would be a bit too much anyway when looking at the many different cartridges out. Anyway, running 8k and 16k game ROMs shouldn't be much trouble.

yes I got carried away there. as the Retro Replay -which is pretty old tech by now - makes it possible to use different .crt files I thought the new 1541U does the same straight away. I was wrong. It is possible to use different cartridge ROMs than the built in ones. When flashing the 1541U firmware, simply replace one of the cartridge image BIN files with a different one from compatible hardware (for example: I replaced RR3.8 NTSC with TFR ROM this way).

No COM port and the COM-port-card I bought doesn't work with SIO2PC. In the future COM and LPT ports will be gone anyway.

But on the other hand C64 doesn't need to boot the DOS from disk all the time since the DOS is in ROM. I have to pull out my 10 year old PC to do that. None of my current PCs are SIO2PC compatible.

Depends on what you want. For pure speed ofcourse Apple2 drives were the best because the main computer handled all the drive hardware stuff and because of that everything was loaded directly to memory. But if you want to do anything else during loading, the 1541/1050 method of having an external drive read the data from the physical disk and buffer it for you until the computer downloads the data from drive memory is the way to go.

C64 load routines can also be written in ways that they allow for other tasks aswell. Look at all the demos and games which do fast loading while all kinds of stuff is happening on the screen. And concerning the uploaded fastload routine size: The drive has a memory of 2k, so all fastloaders are smaller than that. Probably around 1k.

No. Most C64 users had a fastload or multifunction cart plugged in so you had a fastloader available when you switched the machine on. Some games also came with their own fastload routines, especially cracked versions where the crackers added a fastloader & packed the game files.