I ran a (mostly) Commodore-related BBS on an Atari 130xe from 1990-1996, all the while being a member of both computer's user groups. If this existed in the same time frame as my participation in the user group(s) I could have blown some minds. I did actually transport an Atari system to the meeting, ran the BBS on it, and hooked a Commodore 64 up to it with RS232 null modem cable to demonstrate what the user would see, and what the BBS is doing, simultaneously. I even had new users sign up with that system, then when I got it home I copied the new-user data to the actual online system so the next time they called in with their computers at home, their accounts would be active. Being a fan of the Commodore and the Atari 8-bit systems made this video especially interesting to me. Thanks for posting and keep up the grrreat work!
I did a lot of the same! I ran my BBS mostly on an Atari 800XL with a 1mb MIO RAMDisk hosting Oasis BBS which supported ASCII, ATASCII, PETASCII, ANSI and VT52 all off this one computer's BBS software. It was lovely and long before a lot of other BBS's started to do similar things near the end of the dial-up era. I loooove Atari's and Commodores, both, but the Atari's were always my favorite.
@@nickolasgaspar9660 I think the XE line gets some undeserved criticism. Yes, the kb isn't as good as the mitsumi ones on the XL but not every XL has mitsumi kbs. Also some of the XL's kbs flex cables fall apart very easily, including mitsumi. Then theres the claim that the XE had worse internal components despite arguably having comparable defect rates and better video output. The PCB is said to be of worse quality which may be true but personally my XE's PCB wasn't nearly as unforgiving when modding as often claimed. And then theres the futuristic ST design which people either love or hate.
@@haraldhimmel5687 well I have both and I can only judge and comment on those specific models. My XL has an 800xlf motherboard. The pros and cons of this machine are: Pros 1. 4 colors/materials used resulting to a superior aesthetic. 2. Mechanical keyboard with a good ribbon cable. 3. Connected Chroma great video overall 4. Superior quality PCB.(fully socketed without any issues). Cons. 1. MT Ram chips 2. Svideo not separated from composite 3.Bad flip flop chip. My 65XE has a 900XLF motherboard. Pros. 1. No problems with ICs or any other part. 2. Good Ram chip brand 3. svideo Cons 1. Plastics are chemically deteriorating (hot summers in Greece!) 2. Awful keyboard 3.low quality PCB. Some traces were lifted during socketing. The traces on the back side of the board are oxidized. 3. Aesthetics of a toy computer when placed next to the XL. Having it alone on the bench or next to an Amiga it looks great.
We see all these obscure POKEs to hack the screen editor. If only there were footage of using SHIFT-ATARI to go into lowercase mode. That chord feels very satisfying and natural on an 800XL where they're next to each other. I never considered how different the 1200XL's keyboard layout is. I wish I'd thought of the upside-down POKE at 21:05.
The Video Reflect mode at 21:05 was likely born out of Atari's Arcade lineage where some games (to get a larger apparent display) employed mirrors. I imagine that the people who designed this feature had the idea of mounting this computer (or some derivative of it) in an arcade cabinet or (for more practical applications) using a mirror to simulate a large screen for a business presentation in a meeting room.
That's what I assumed too, except it doesn't flip the entire screen, just individual character graphics? Seems like that would make designing the thing harder; you'd have to actually have a mirror handy instead of just coding the game as if it were normal and then adding the "flip" code just prior to shipping.
This reminds me of that crazy project where Atari ST TOS was ported to run on an Amiga. It was a hacked ST TOS ROM shoved onto an Amiga 1000 kickstart disk. so you could boot directly into ST-TOS. It was pretty neat, but iirc, disk routines weren't complete, so you couldn't write to disks yet.
How about Magic SAC? It was a cartridge for the Atari ST in which you installed Mac ROMs and with boot software lets you run Macintosh software on the ST.
@@theannoyedmrfloyd3998 : oh my, I thought I was the last soul on earth to have heard of Magic Sac ! The concept was incredibly neat and if memory serves, it almost doubled the screen real estate compared to the original mac, at the expense of the sound that couldn't be emulated.
FYI: You can now boot an Amiga from disk to ST Desktop, with MiNT & full GCC toolchain (Vampire as well). Check out EmuTOS on SourceForge (yes there is a ROM replacement as well).
@@theannoyedmrfloyd3998 There were similar items on the Amiga as well like AMax. It let you have different Mac ROMs plugged in for emulation and also provided peripheral ports to use Mac devices with. Later on, you could emulate a Mac in software with Shapeshifter and have the Amiga run MacOS faster than a Mac could natively which was a little amusing. It helps a lot when all three machines using the 68k processor as it removes a lot of complexity with emulation as well as extra over head.
0:39 Yes all 1200XL's have socketed ROMs and yes all of the IC's are socketed, except perhaps one. They have excellent build quality. The OS chips usually have 24 pin sockets however about 1/6th of 1200XL's have 28 pin sockets which make it easier to install OS upgrades. Another variation with 1200XL's is that when the case top is removed, the cart plug connector uses stiff hard wires to the motherboard but some utilize a flex cable. I've seen them with 300ns RAM (which works) or 200ns RAM.
Awesome effort. I am reminded of how I complained that the monochrome Apple II we were using at school wasn’t as good as my 64. I quickly mocked up the start-up screen text of a 64 on the Apple, and disabled the reset key. I then declared the Apple “fixed”. The teacher was no amused. Can’t imagine her face if she saw this type of system takeover.
Is it weird that I'm watching this hoping someone actually further updates this to use all the hardware features so games & demos can be made to push this hybrid to its limits? ..for science and fun, ofcourse!
Damn, that web browser intro reminded me that I wrote an intro when Flash 3 first came out (1998?), to demonstrate to the other developers what was possible. Later I wrote a Javascript (DHTML?) intro for my Mom, "the living christmas card" :)
15:41 It does prove that clock speed isn't everything. Architecture can make just as much of a difference. Sometimes the two work together, sometimes they cancel out, sometimes it falls somewhere in between.
Yes, the Atari screen is wider by 8:7 compared to the C64. Each Atari character is exactly 4 chroma cycles wide. Each NTSC C64 character is exactly 3.5 chroma cycles wide. The Apple ][ also had characters that were exactly 3.5 chroma cycles wide, but Woz designed each character to be 7 pixels wide. Along with various other specifics, this allowed composite color artifacts to be used for color. The C64 (and actually also VIC-20) went the opposite route - trying to eliminate composite color artifacts by reversing chroma phase alignment each field. The 3.5 chroma cycle width was combined with having an odd number of video chip cycles per scanline, and an odd number of scanlines per field. Voila! The color fringe artifacts are reversed each field, visually eliminating them. Composite color artifacts could be exploited on almost all the other computers ... Apple ][, Atari 8-bit, IBM PC, CoCo ... but the cost was ugly color fringe artifacts. The VIC20 and C64 had nicer displays, but it was not possible to take advantage of composite color artifacts. (Well actually, it was possible if you switched between two different screens each field, but AFAIK no one took advantage of this.)
My grandfather bought the first edition C64s, where the VIC chips had a different number of cycles per scanline. This made a lot of intros and demos have oddly-shaped raster bars until I replaced it. But I also noticed that text got a lot clearer when I got the new chip; before, certain color combinations would distort the letters. This must be because the oldest VICs lacked that phase reversal thing you just described. yes, the old VIC chip had sparkly sprites too. i think this is the run they skipped QA on so they could get the 64 out in time for Christmas.
@@nickbensema3045 That is correct, but I'm just going by deduction from what I know of the early C64 hardware. I've never seen it myself, nor seen any footage of the early hardware on TH-cam or screen shots. I'm so glad to hear my suspicions confirmed, though! Back when I was a kid, I had absolutely no idea what was going on technically. I just knew that other computers had what I called "color distortion" at the time. And the VIC-20 and C64 (as far as I knew) did not have it. I had something of an idea of how color worked on the Apple ][ because the school computers had monitors with a color/monochrome button. In monochrome mode, you'd see colors turn into vertical stripe patterns. But when I tried to render vertical stripe patters on my C64 ... no color. So I knew something different was going on, but it would be years before I learned enough details of NTSC color to understand what it was.
Composite arctefacting technically possible, but quite a bit more difficult in PAL. Systems dependent on composite arctefacts therefore were NTSC only, i.e. the Apple II was monochrome in PAL countries, while IBM PC's with CGA had to rely on their RGB output. Commdore and Atari machines, on the hand, had proper chroma signal generation, and allthough not perfect, they were reasonably transparant between PAL and NTSC and did therefore allow for a global software library. This was a major factor in the success of these computers and explains why e.g. the Commodore 64 sold much more PAL than NTSC units.
@@danielmantione While it's true that the Apple ][ was crippled in PAL countries, the C64 faced stiff competition from ZX Spectrum, BBC Micro, and Amstrad machines which were practically not available in the USA. Note that the Apple ][ didn't really sell as well as the C64 here in the USA either. But they cost a lot more, so it was able to keep Apple in business. If there's any one factor explaining why so many more PAL C64s sold than NTSC C64s, it's the NES. Commodore USA desperately wanted to be perceived as a serious business computer brand, so the C64 (and later Amiga 500) weren't pushed so hard as games machines. So, people who just wanted to buy a game machine for their kids bought an NES. The USA videogame crash of 1983 made a lot of companies wary of being perceived as a game machine maker. By the time it was clear there wasn't going to be a second crash, Nintendo already took over.
I never owned an Atari or a C64 (sorry went the MSX route in my youth ;-)), but this is really impressive and I enjoyed watching you tinker around with an Atari running C64 BASIC greatly. Thanks.
Same (SVI 728), but later I got access to a C64 + FastLoad Cart, and even later I built up Atari 8 Bit system with 4x Floppy (when you could get a complete system from garage sale for 20$)
Very nice! I like how the Atari handles cycling through the different shades of each colour, that could become hypnotic if you stare at it for very long.
Color indirection was absolutely an Atari feature that the c64 couldn't match. That's why, unless you are testing just the CPU and memory response times, there is no good apples to apples, if you will, way to compare graphics performance. Both systems will display graphics, but the way each one does it is very different. Each system overcomes the straight bitmap limitation on memory with trade-offs. When you owned one of these systems, you were, by necessity, an early adopter who had to live with the trade-offs of their respective systems.
@@Chordonblue Actually, in its multicolor character mode (with a redefinable character set, of course), the C64 uses a combination of 1 color map and 3 color indirection registers. You can choose between this and multicolor bitmap mode, which instead effectively uses 3 color maps and one color indirection register. These modes can be mixed on the screen vertically as needed using raster interrupts. And if you want a fully addressable multicolor bitmap that uses more color indirection, that can be accomplished using raster interrupts, as well, with the multicolor character mode--just split the screen vertically into 5 sections, changing the character set definition pointer appropriately for each section. Obviously, the C64 and A8 have different capabilities, but I think the C64 is significantly more powerful and versatile than the vast majority of A8 fans realize. The A8 can still do some things the C64 cannot, but the reverse is also true. For instance, the C64 has 256 redefinable characters compared to the A8's 128, and can mix hi-res and multicolor characters on the same line, not just on different lines on the same screen.
I still remember the rivalry my 2 friends and I had: I had a c64, friend 1 had an Atari 800 and friend 2 had a TRS80. We used to argue to the point of not speaking to one another (sometimes for days) because we steadfastly defended our position as our computer being the finest. I still have my old C64 which my young son loves to write basic programs on. I have to admit I still have a secret desire to buy an Atari to see what the machine is all about. Videos like this make my late night eBay browsing gravitate towards a retro purchase. Don’t tell my old friends!
The prices on these things are going up fairly quickly, so go for it! If you're still unsure, you could always try out the Atari with an emulator such as Altirra. One of the coolest things about the Atari 8-bits, aside from their large (for the time) palette of colors, is their graphics architecture, which sort of formed the basis of the Amiga's graphics later (in fact, the lead designer was the same guy: Jay Miner). While the C64 could do the same sorts of things through raster interrupts, it's neat to be able to construct the screen piece-by-piece using display lists, which are sort of like machine code for a coprocessor known as ANTIC. The architecture is also very flexible and has a lot of modes that I think you'll enjoy exploring. The C64 does some things better, such as sprites and high resolution (for the time) in general, but the Atari has its own strengths to match, and does other things better. They are very different computers that are pretty evenly matched on the whole, which makes the comparison interesting. Unfortunately for one of your friends, I don't think that the TRS-80 quite matches up, although the Model 4 did have 80 columns, which is an advantage for some things. All of these old 8-bit computers are cool, though, as far as I'm concerned.
Would be great to see someone implement a workalike of the classic C= hot air balloon BASIC sprite demo in Atari 64, of course with the Atari symbol instead. Perhaps a charitable donation bounty?
Well, you could place 3 Atari sprites next to each other for a 24 pixel width, but these would be twice as wide as the C64 balloon sprite because Atari sprites don't have the high resolution capability of C64 sprites.
One limitation will be that it'll be difficult to move them vertically. You'll notice that the sprite in the video covered the entire height of the screen. In more practical sprite modes, the ANTIC chip assigns a 128-byte or 256-byte slice of RAM to each "player", and to move something vertically, you have to repaint it in the new position. in BASIC this is prohibitively slow.
@@nickbensema3045 I can think of a trick to make it work faster. You can tell C64 BASIC to place the screen in a different location (and this works in Atari 64 as demonstrated in this video). At that point, you can use a fast PRINT statement to redraw the sprite's data at a different starting byte. Back in the day, I used PRINT statements for fast sprite animation, but with the much cruder trick of simply PRINTING invisible characters in the top 2 rows (same color as background). The animation was fast, but it was also pointless ... it would be even faster to just POKE the sprite pointer for animation. It was amusing, though.
@@IsaacKuo interesting; you can move a sprite vertically with INSERT and DELETE characters that way. it's the kind of hack that would have made a demanding introduction to a would-be programmer. there was a dancing mouse animation that moved only vertically and had a few frames of animation -- that might not be so hard to adapt.
There are some 'simple' things on the C64 that can also be done on an Atari... with a little more work. I'm certain this isn't meant to be a "mine's better than yours" video. For every pro there's a con on each machine, and apart from marketing department/fanboy rhetoric, there's no real winner or loser. CBM were certainly better at marketing in the early days than Atari were, which helped sell more units... but from a technical point of view, there's no decisive winner. Besides... the Atari 800 came out two full years before the C64, and in computer terms, that's a long time. 😁
If you mean inverse characters, then on a C64, just press Ctrl-9, and you'll get inverse characters. Internally, while it is true that the C64 doesn't have an actual inverse character mode as a feature, as a trade-off it has 256 characters in its character set instead of 128. The extra 128 characters are defined in the ROM character set definitions as inverse characters, so effectively the most significant bit acts as an inverse flag. The nice thing, though, is that it doesn't have to be inverse: the additional 128 character definitions can be redefined to be anything you want.
Imagine what sort of "community" there would have been if this had been done around the time of ANTIC magazine. There would have been games and demos that run on _both_ systems :)
Although, it probably would have ended up in a slagging match, where demos would be created with the specific purpose to point out the flaws in the other system. 😆 I owned the Atari back then, and I remember the micro wars. It was a very real thing. Truthfully, people wanted to protect their investments. When you spent over $1,000 on computer, monitor, disk drive, etc, you had every incentive to want to see your system succeed over the other ones.
For me it has always been a concern that for something as fundamental as a computer different incompatible and short-lived systems exist, making it difficult or impossible to exchange software or data, more so over time. That's actually one reason why I got into retro computing - an old platform doesn't change anymore, which is kind of a relief. Which computer platform has the most potential to become an immortal, timeless classic, with replicas of the original hardware still being made and emulators still running on then current machines decades in the future? The funny thing is: If you want to write a program that will still run on current machines in 20 years, better write it for C64 (VICE). Second best choice I guess would be DOS(Box). I can't see a program for current Windows, Linux, Android, or iOS still running on any current machine in 20 years - and I can't see an ephemeral smartphone that quits working (or rather gets discarded despite still working) this afternoon being replicated in the future.
Actually no. Most C64 games completely bypassed the Kernal (unless text based or accessed the disk) and did their own thing as the Kernal had no graphics routines. They accessed the SID and display directly. A "demo" would not have been any different on either machine, as demos bypass the ROMs anyway. Games would not have worked either. The sound and display architectures of each machine were vastly different. The C64 shares more commonality with a ZX Spectrum in display design than with an Atari. Color cells are a Commodore and Sinclair feature. Atari used palette mapping and display lists instead. You could have multicolored text on Ataris, but doing it in BASIC was incredibly difficult. To use the SID or draw graphics in BASIC for a C64 you also had to POKE it to the screen, as the Commodores had no graphics commands (until the 264 series). This is why porting the Kernal and BASIC wasn't a big task. Commodore BASIC is mostly a text only language. Whereas on Ataris and other machines, BASIC had graphics commands.
@@richardkelsch3640 Yet with the great graphical characters or own (modified) characters and sprites, C64 BASIC allows for better graphics than the usual graphics commands.
Regarding ANTIC interrupting the CPU to fetch graphics: you can of course turn ANTIC off. The 1200XL, in fact, had a Function-key combo to do this! In BASIC you could, say, POKE 559,0, do your CPU-intesive stuff, and then POKE 559,34 to turn the screen back on. In fact, clever programs like Bob Puff's SuperARC and SuperUnARC did this, but for MOST of the screen. A single status line in the center showed the (de)compression status. All thanks to Display List Interrupts! ;)
Nice video. I think if this was fully written to take advantage of the Atari and run from ROM not RAM, it would probably be about 50 percent faster than a C64.
It's weird seeing the C64 font with Atari's color palette. This would of absolutely blown my mind in the 80s! I also used to wonder why Atari computers didn't have a blinking cursor, this proves it could've been done!
This brings me back to the 1970s and early 1980s, when I used to notice things like whether a particular computer offered inverse and/or flashing characters. It's not that I didn't know those things later, but it seemed like a bigger deal at the time, for some reason. Actually, neither the Atari nor the C64 offer flashing characters in hardware, unlike the Apple II series, which does. It's done in software (ROM firmware in this case) on the C64, and of course it can be done on the Atari in the same manner, as well.
Wow, kewl beans. I never used an Atari before, but I had considered buying one back in the day, but after some research the C64 won out for me. It was interesting to see how the colour and sprites work. Looks like the Atari would have been just as fun to program as the C64. Nice intro as well, Doc should have no problem learning 6502, it's easy and fun to learn and program.
I had always wanted an Atari as a little kid back in 1979, but my family couldn't afford to buy a decent-enough computer for several more years. I wished I had an Apple IIe, too, because it's what I mostly used at school a few years later; it's obviously not as awesome as the Atari, but I liked how it was so different, and it had some nice features of its own. I ended up with a C64 because it's a very good and affordable 8-bit computer, and frankly it was more "happening" back then, as in it had a larger user base and greater software support. It surprised me with its capabilities, as well, trading punches, so to speak, with the Atari, toe-to-toe. I became a programmer on it (nowadays often called a software engineer or developer, of course), and soon after getting my first job, which paid a lot more than my family was used to, I bought several examples of all of the 8-bit computers I had ever been interested in! :D Yeah, I had a PC (compatible), but that was for work, mostly, as well as the Internet later. The 8-bit computers are my real computers. ;) I should have bought more of them while they were still cheap! I got my Apple IIe for $15 (plus $20 shipping) in the 1990s. It was in nice shape except for some broken key switches, which only took a few minutes to replace. I don't think I paid more than $30 each for my Ataris and Commodores. I also still have my original C64, which is 100% functional but worn smooth on the front (where my hands rested) like very few I've seen--the poor thing has had a hard life of intense use, but it's still going.
I remember you showed that the Sid Meier's Pirates! game was written in basic. It'd be interesting to see how much would work on the Atari 64. Of course, if you can't load, that makes it difficult :)
@@danielmantione Yeah, I figured. Still sounds like a fun experiment, even though I know it would likely not get very far at all. Robin showed that at least some machine code could be executed by basic. I know that it was much simpler than what would be in a game though.
It is amazing how the Commodore sold millions more units and supported for a longer period of time but Atari is getting cooler accessories such a FujiNet, simple cheap ram expansions, etc...
0:13 Ataris running Commodore firmware! Human sacrifice! Dogs and cats living together! Mass hysteria! 3:46 The color RAM isn't a great place to put the character set since lots of BASIC games for the C64 will POKE there. They kind of need to intercept every POKE and PEEK operation and remap them, perhaps bit-for-bit. They could also have some kind of "shadow register" concept where the shadow registers are applied and/or updated on every system interrupt. 10:56 The C64 effectively runs at 2.04 MHz with the video chip and the processor double-teaming the system bus. 16:25 One typo and you crash the system. Though, I suppose that SAVE isn't working anyway. 27:15 There must be some kind of cheat that can be used to load the RAM using the Atari system before activating the C64 system and reinstate the loaded program afterward.
If you install this in ROM, that won't be a problem, but, like, that's drastic. but as for the executable in RAM, maybe I can try to detect XE RAM and hide the character set in there.
Atari cannot display high-resolution text or high-resolution graphics with more than 2 colours per scanline, there is no colour RAM. I guess the best you can do is ignoring any write to D800-DFFF
@@paulwratt You can't put them there, as the character set is already there. A better choice would be remove support for all kinds of C64 peripherals (as they won't work anyway) and in that newly freed space, add support for one Atari peripheral, for example the tape.
Good catch on the different scrolling on the two platforms (there is no color RAM to scroll). I wonder how much of the remaining difference is due to differences in the interrupt handler. A C64 probably (I am not an expert as I've never written IRQ code on C64) does a fair amount more in the IRQ than Atari64 because it is trying to support the real hardware on a C64. This software merely ignores hardware beyond the screen and keyboard. I don't mean to make this sound like I'm denigrating the effort. It is freakin' awesome! Very impressive. I doubt that the 17% to 20% difference can be attributed completely to the potentially shorter interrupt handler in Atari64, and the difference could be near 0%. Clearly having a faster CPU clock is going to help the Atari64 in almost every case. Just the only thought that came to me that I didn't hear expressed in the video. Great job on the presentation and to the Atari64 author.
The 17% difference is almost purely due to the difference in CPU performance. The 20+% difference was because of the lack of color RAM on the Atari (in addition to the CPU). The C64 Kernal (sic) and BASIC, even on a real C64, don't do a whole lot that is related to the specific hardware. The BASIC environment on the C64 was ported almost straight from the original PET. The character sets were modified and support for the color map was added, but not much, if anything, more. Many PET programs, even the games (which use graphics characters), will run on the C64 with few or no changes. That's why porting it to the Atari was so easy (relatively speaking).
13:42: Some of the Atari's speed advantage here has to be due to it scrolling less frequently, due to the greater width. EDIT: My mistake, it's the same number of character, just rendered with a slightly different aspect.
I would make a quick loop to poke the first 4 bytes of all the characters, with half the value, effectively bitshifting them all 1 bit to the right, for an italic c64 font.
If you turn off the display on the Atari, you can benchmark it for speed without ANTIC slow down. As to I/O. It may be possible to patch the Kernal to use SIO to talk to a 1541.
I wonder if it also isn't setting color on print if it's not moving it on scroll - that would give the Atari another small performance advantage... Probably not much but if guess a percent or two
There is no color map to process on the Atari, so yes. The development page even says that this code was removed/skipped. On the Atari, you can only have one hue and two values (brightnesses) in this text mode, while on the C64 the background and each character all have their own independent colors.
Well, yesterday Matt Hefferman uploaded a video comparing the speed of 8bit computers. The Atari 800 and C64 (among others) competed at generating a Mandelbrot Set fractal. (NEW CONTENDERS! 8-Bit Battle Royale Round 1 Continues) The numbers were interesting! Atari 800 2:16 C64 3:23 This tested the speed of Basic and in a future episode he will test their machine language.
@@nickolasgaspar9660 It would be interesting to use the Altirra BASIC used on modern emulators too. It’s rather faster, and often installed on real hardware today (I have it on my 800XL)
@@Doug_in_NC Maybe use OSS's Basic XL or XE? What Atari Basic would have been, had Atari not limited them to just 8K. 😁 Perhaps good old Turbo Basic XL would give a really good showing too?
@@another3997 it would certainly be interesting to run them all against C 64 Basic and whatever other variants of Basic were written fir the 64 like Simon’s Basic
I noticed that the flashing cursor is not flashing at a consistent rate. Occasionally there's a shorter delay between flashes and sometimes a longer delay.
Somehow I missed this previously, but your video said that 53281 might be the "mirror" of 53249, and it isn't. The VIC-II has 47 registers, and the repeats happen every 64 bytes, not 32. In any case, I was rewatching this video because I've just developed the Commodore 800, or C800 for short, Atari 800 (non-XL) emulator. 😁 Currently, this functional prototype actually is more of an emulator than a port because I made so few changes to the OS-B ROM (7 in-place patches of 1-3 bytes each plus a small key-click subroutine versus rewriting and reassembling portions of the ROM code as with the Atari64) and none to Atari BASIC (Rev. C). For the most part, the Atari ROM code "believes" it is running on an Atari 800, because the C64 can swap in RAM in place of the I/O map, and there is a "master" interrupt routine that emulates the essential POKEY, ANTIC, and GTIA chip functions through this RAM. Of course, functionality is limited to BASIC, as currently the user cannot access the C64's I/O map, although that can be changed, I'm sure. Atari BASIC's graphics commands do not work with the C64, although they could be ported to some degree in the future. For the time being, this is a simple proof-of-concept prototype that demonstrates that the Atari OS and BASIC can run on the C64 (an answer to the Atari64, I suppose), and in the case of the C800, in a nearly unmodified form with some actual hardware emulation, as opposed to being entirely ported. Unfortunately, there is some overhead due to the emulation, which causes a minor slowdown. Benchmarks on the Atari64 are generally far more accurate because the C64 OS and BASIC were ported. But I think it's cool that the C800 is actually an emulator, which is possible because the C64 can access all 64K of its RAM (not possible on the stock 800XL or 1200XL because the I/O map cannot be swapped out). All of the Atari keys are mapped (try the C64's cursor keys in addition to the standard Control keys) except for the ones off to the right, which can be done (with the C64's function keys) but just haven't been yet. The C800 emulator runs Atari BASIC by default, but can also run the Memo Pad--to do this, after LOAD "C800",8 run it with RUN:REM MEMO instead of just RUN. Now for the binary. It seems that TH-cam almost always, if not always, deletes any post I make that has links, so I'll put them in a reply to this comment. If they disappear, then I will email them to you. Any feedback would be welcome. Make sure that your sound is on so that you can hear the C64 emulate the Atari key-click sound; this is important for that authentic Atari experience. 😉
Thanks Robin. Now I know my life is a lie, and that an Atari is a faster Commodore 64 than an actual Commodore 64. :( Seriously though, this video was a ton of fun!
@@polluks2 But the C128 wasn't around at the time Atari released their 600/800/1200XL machines, nevermind the original 1979 Atari 400/800. So nerrrr! 😉 In hindsight, the C128 was interesting. A weird beast, grossly overcomplicated and neither one thing or the other... but probably a fitting end for their 8 bit range. I'd quite like one myself.
Only at running the C64's BASIC, and not entirely, at that. It can't do a lot of things the C64 can do, and likewise the Atari can do things the C64 can't do. In this case, overall the Atari's processor was slightly faster, which everyone already knew. It doesn't mean the Atari can run the C64's software (except for the most basic BASIC code) at all, let alone better.
This is neat. I am surprised since it was claimed how easy it was that it took this long to get ported over. I am curious to see how far this project will go, and if we will see the reverse where Atari basic and OS is running on the C64.
I don't know whether we'll see the reverse anytime soon, but I'm sure it is doable, as it is much like porting any program, such as a game, from one computer to another of similar capability. It would probably involve more work, though, if the Atari OS and BASIC depend more on the specific hardware of the Atari. The C64's BASIC and OS are barely even aware that they are in a C64. They might as well be in a Commodore PET, where they were ported from originally.
The reason the Atari isn't as fast as the clock speed would suggest is because video DMA steals cycles from the CPU. On the C64, the cpu is run at roughly half the speed all the time and interlaced with video DMA cycles. This means the Atari runs faster during blanking periods and the C64 does not.
if you want to run a program on the atari and you dont need screen for something turn the screen off poke 559,0 screendma=peek(559):poke 559,0: do cpu intensive no screen needed program:poke 559,screendma or direct address if the emulator does not update the shadow register 559=54272 approx 30% increase in speed
21:49: Could you have pre-written the POKE 54273,2 line below the READY before hitting return on the POKE 54273,0, and would this have allowed you to just press return again after turning cursor blinking off?
I wounder if you could still use DMA for the sprite poke 53277 poke with 3 for sprite player and sprite missiles or 2 for just players 1 for just missiles then you can reserve some memory and put some real data in for the sprites
Sure, this is just a simple, partial port of an 8-bit BASIC environment. The computer is still physically and logically an Atari in every way and a C64 in none. It's like porting a game from one computer to another.
When comparing the scrolling speed, it’s also worth noting the Atari text mode was only 24 rows tall while the c64 text mode is 25 rows tall. The Atari has one less row to scroll.
I thought about that so I counted the on screen lines ... 25 lines! So, even though the normal Atari modes were 24 rows tall (192 scanlines), the video chip is actually capable of displaying 25 lines instead (200 scanlines).
Depends on how the scroll is implemented. If the video memory space if fixed and the cpu has to redraw all the characters on the screen then yes an extra line would impact performance. If the video memory space is adjustable then there's virtually no performance difference with an extra-line.
@@zbdot73 The scroll is implemented by copying bytes to shift them 40 or 80 bytes (depending on whether it's scrolled one or two lines), and filling the rest with spaces.
The Atari 64 "emulator" is highly accurate when it comes to benchmarks, actually. Let me give you the real numbers at the hardware level for comparison. I'll stick with NTSC because I know that best. The C64's clock runs at 1,022,727 Hz, but loses some of these to DMA for "bad lines" (text data and/or dual color maps) and sprites. Each display frame has 65 cycles/line * 263 lines/frame = 17,095 total cycles/frame. Bad lines subtract 40 cycles/line * 25 lines/frame = 1000 DMA cycles/frame (in all five graphics modes) from the total. And two bytes (out of four, including the pointer) for each sprite comes from DMA, so for 8 sprites being displayed (a "typical" scenario), that's 8 * 2 * 21 = 336 DMA cycles/frame. The main color map at $D800 has dedicated data lines running to the VIC-II and 1024 nybbles of SRAM on a separate 2114 chip, so there is no DMA penalty. Without sprites, the C64 effectively runs at 16095/17095 * 1022727 = 962,901 cycles/second or Hz, and with 8 sprites active, it effectively runs at 942,799 Hz. Meanwhile, the Atari 8-bit has 114 cycles/line * 262 lines/frame = 29,868 cycles/frame. And its per-frame DMA (in the main text mode at normal screen width) consists of 40 * 24 (equivalent to C64 "bad lines") + 40 * 24 * 8 (glyph data for every character) + 9 * (262 - 24) + 24 (DRAM refresh cycles: 9 per normal scanline and 1 per "bad line") + 32 (display list) = 960 + 7680 + 2166 + 32 = 10,838 DMA cycles/frame. Player-missile graphics add 5 * 240 = 1200 DMA cycles/frame. So with player-missile graphics the Atari 8-bit effectively runs at 19030/29868 * 1789773 = 1,140,330 Hz, and with player-missile graphics it effectively runs at 1,068,423 Hz. So without sprites/PMGs the Atari 8-bit runs at 1140330/962901 = 18.4265% faster than the C64, and with sprites/PMGs it runs 1068423/942799 = 13.3246% faster than the C64. The measured figure that you got is subject to various factors, but it's pretty close to what the precise cycle-by-cycle comparison indicates (and, truth be told, even the method I just used isn't exact because the Atari 8-bit, in halting the CPU more frequently, loses a not-completely-predictable number of cycles more than the C64 does per frame, so it's actually a little slower in comparison to the C64 than the figures I've given seem to indicate). The bottom line is that the CPU of the Atari 8-bit is always faster, but not by nearly as much as the vast majority of people think, and *depending on the type of game* , the C64's sprites, which are faster than player-missile graphics in several ways, can more than make up for the difference.
By the way, if we count every cycle, we can find out how much faster the Atari's CPU is when the two computers' displays are blanked. The C64 loses no cycles to DMA, so it runs at 1,022,727 Hz. The Atari, however, still loses 9 cycles per line for DRAM refresh, which comes to 9 * 262 = 2358 cycles/frame, so it effectively runs at 27510/29868 * 1789773 = 1,648,475 Hz. So with their displays blanked, the Atari 8-bit runs 1648475/1022727 = 61.1843% faster than the C64. Many say it's 79% or even "twice" for short, but it's actually a touch over 61%, even with the displays blanked. By the way again, the Apple II runs at 1,020,484 Hz, or ever so slightly slower than the C64 with its display off and the VIC-20 (with its display on), and a bit faster than the C64 with its display on. Why the slight discrepancy? That's a highly technical subject (that I can now explain completely after a bunch of research) that involves the NTSC standard and Steve Wozniak saving a few transistors, as usual. 😉
This video doesn't really say much on that subject, except that the Atari's CPU is faster, as we all already knew, but not nearly as much faster as most people had thought--more like 17% versus the 79% many probably had in mind. There was one example in which the Atari was 20+% faster, but that's only because it doesn't have to manipulate the color map, since it doesn't have one. 17% is pretty accurate and very close to the theoretical advantage the Atari has over the C64 when all relevant technical factors are considered. This only applies to CPU speed.
Wow, interesting! Now let's see all those less-familiar pokes on the real C64, and all of the same pokes in native 800! And any other comparisons between the hybrid and native 800 that you think would be interesting. And then come full circle by trying those other things on the real C64 as well. I guess "BASICally" 😁 all comparisons between the 3 systems you think would be cool ("This is what happens if you try this Atari-based poke on the real C64, and this is what it the same looks like in regular A800 mode," etc.). Try some of the SID pokes in all 3 modes and then try some of the 800's versions of sound pokes on all 3, etc.
I haven't really had enough experience with Atari BASIC to say for sure; from what I can tell, Atari BASIC has some nice features over C= BASIC, but C= BASIC is overall more robust/stable, and is faster.
It's a reproduction of a real badge worn by Commodore security employees at their headquarters. The repro was made by my friend DLH who runs the excellent archives at bombjack.org. I just think it's really cool (and a bit funny) so I put it in shot a lot.
Oh, the performance difference should be bigger in PAL-land. PAL had a lot more scanlines, but the PAL versions of the C64 and Atari 8-bits didn't take advantage of it. So, there were simply a lot more scanlines where the video chip wasn't strealing any cycles. So, the performance edge of the PAL Atari 8-bit over the PAL C64 should be better.
Yes, it'd be interesting to see some benchmarks for PAL hardware as it should be faster. By the way, I recently learned that the Atari still needs to steal cycles for DRAM refresh even when there's no video being displayed so even when in vblank or with the video disabled, you can never get all the cycles available to the CPU.
@@8_Bit Correct, 9 cycles are stolen for DRAM refresh on each scanline, of which there are 262 with NTSC and 312 with PAL per frame. One exception is that there is only 1 refresh cycle stolen on lines during which text screen data are fetched (analogous to "bad lines" on the C64). These refresh DMA cycles must happen regardless of any settings, or else obviously data would be lost. Each scanline has 114 cycles, by the way.
Ah, thanks for the correction. For some reason I thought the GTIA didn't show up until the 600XL/800XL, but upon further reading it seems even some original 400/800 shipped with the GTIA!
@@8_Bit Yeah the GTIA did show up in the originals. Apparently the GTIA was supposed to be the original chip but to get it to market they released the CTIA...so rumor has it.
@@gamedoutgamer They're even more uncommon because the GTIA was offered as an upgrade, and apparently a lot of people did that, given the apparent scarcity of 400/800s with CTIA chips.
The 256-color palette only applies to graphics mode 9 (BASIC), though, doesn't it? That's the bitmap mode with 80x192 resolution (1 hue of 16 per row and 16 luminances). All other modes have the same 16 hues but only 8 luminances for a palette of 128 colors. If you find this difficult to believe, then try it for yourself. In the BASIC editor, PEEK(709) will return a value of 202, which is the color of the text. If you POKE709,203 the color will not change at all. But if you POKE709,204 the text will brighten. This means that the least significant bit of the luminance field is still ignored, even with the GTIA chip, and there are indeed 8 luminance levels in this mode rather than 16. This is actually true of all display modes with the sole exception of GRAPHICS 9.
It would be wrong to imply that the Atari halts 22% of the time. It simply hands off the graphics processing to the Antic, which also runs at 1.79Mhz while halting the CPU, so there is no real penalty other than the time required to pass the display list.
If I said "the Atari halts" I surely meant the Atari's CPU halts; all my comments were in the context of explaining how the Atari's CPU throughput is not 1.75 or 2.00 times the speed of the C64's, despite what a simple comparison of 1.79 MHz vs. 1.02 MHz might imply.
Actually, the memory also runs at 1.79 MHz, so every fetch halts the CPU, not just for the display list. Overall, the Atari's system is more efficient than the C64's because the Atari's CPU gets to run at its full 1.79 MHz speed when ANTIC RAM fetches aren't happening, while the C64's CPU is always stuck at 1.02 MHz regardless of what the VIC-II is doing. The difference is not 1.79/1.02 = 75%, but more like 17-20%, as demonstrated in this video.
@@rbrtck Yes, the ANTIC is granted DMA control while graphics is being drawn. This alone is not additional overhead though, because the task is just being handed off from the 6502. The ANTIC is not really a "graphics chip" but a second processor similar in some ways to a 6502. The Atari equivalent to the VIC is the GTIA. Atari could have chosen to get rid of the ANTIC and connect the GTIA directly to the address bus as was done with the VIC on the C64, but the Atari was built for smooth graphics and gameplay. Because normal system tasks can't interrupt the Antic, we get fine scrolling at 60Hz with no jitter, for example, even under heavy 6502 load. For 100% CPU usage at 1.79Mhz for heavy calculations on the Atari, just disable automatic DMA control to the ANTIC.
@@redleader7988 It's additional overhead because the CPU is halted whenever the ANTIC needs to read from RAM. While it's nice that the CPU doesn't have to do all of the work that the Atari VCS/2600's CPU does, it still has to share the same RAM cycles with the ANTIC. The good thing is that the CPU can run at its full 1.79 MHz speed whenever the ANTIC is not fetching from RAM. For comparison, the C64's RAM runs at 2 MHz, so the VIC-II chip rarely has to steal additional cycles, but although they usually don't contend for RAM, working on different halves of the RAM cycles, when the VIC-II is idle, it can't let the CPU have the extra cycles because the CPU runs at only 1 MHz no matter what. The 2 MHz RAM is just sitting there half-used for much of the time. The overall result is that when the ANTIC is fetching data to display a typical screen, the Atari's CPU runs about 17% faster than the C64's CPU. It would be 79% faster if it were not for the ANTIC stealing so many cycles with DMA, but it has to, and this has a significant effect because 17% is a lot less than 79%. There must be a reason for this, right? You're wrong about how the graphics chips compare, too, I'm afraid. The GTIA is much more like the TIA in the 2600 console than the VIC-II. Just look at the GTIA's registers in the Atari's I/O map--it's all about colors and player-missile horizontal positions, and no graphics modes (aside from selecting color interpretation). It can't do anything without some kind of processor to drive it. In the case of the 2600, because there was no memory for a frame buffer anyway, the CPU "raced the beam" to feed the TIA data (from ROM or calculations) in a carefully timed manner in order to generate a display. The difference in the Atari 8-bit computers is that a separate coprocessor called the ANTIC drives the GTIA instead, feeding it data from various sources so that the CPU and its software do not have to worry (for the most part) about the real-time aspects of generating displays. Contrary to what you said/implied, the VIC-II does the same thing--it is a complete graphics processor in a single-chip package that generates displays generally independently of the CPU (which only has to worry about manipulating registers and frame buffers). It has its own "ANTIC" and "GTIA" equivalents on a single chip. If Atari could have fit the ANTIC and GTIA on the same chip, then they probably would have. In fact, look up the CGIA and KERI chips. Both were attempts by Atari to fit everything on a single chip, in order to reduce cost, but for whatever reasons, this never happened (maybe it was too late in the game and they had so many ANTIC and GTIA chips in stock anyway--Atari was infamous for manufacturing too many of everything). Now, a lot of people consider the ANTIC a super-special coprocessor because like a CPU it has its own sort of machine code, but that's only sort of true. Its "opcodes" are just a sequential list of the modes that it can operate in that describes the type of display that the software wants to be shown. The only things it can do on its own, aside from simply feeding data to the GTIA for display generation, are changing modes according to the display list, optionally changing the memory addresses from which to fetch data from RAM, and optionally interrupting the CPU (a DLI) to do everything else after a row of graphics is displayed. That's not real fancy for a coprocessor, and it doesn't even change the color registers, which is done a lot on Atari computers--the CPU has to do that and everything else the ANTIC doesn't do. While it's true that the VIC-II does even less, it is still a graphics coprocessor that automatically does all of the DMA RAM fetches it needs in order to generate a display, as well as interrupt the CPU on specific scanlines (a raster interrupt) to take action as needed for split screens, sprite multiplexing, changing color registers, and such. The hardware arrangement is different, but what these chips do is not so different. Their overall capabilities are pretty similar, as well. The Atari obviously has an advantage in colors, while the C64 has an advantage in resolution (everything from sprite pixels and horizontal positioning to smooth scrolling is done in half-clock increments rather than full color clocks like on the Atari in most cases), and so on. The GTIA does less than what you believe--it is not a standalone graphics solution at all. The VIC-II does more than what you believe--it does everything needed to generate displays with many different modes, all by itself. The ANTIC is not what you believe. It actually does more than what you believe to generate displays on the Atari because the GTIA does much less--it is the ANTIC that creates all of the graphics modes, while all the GTIA does is apply colors and creates signals on a line-by-line basis. The ANTIC is in full control here and does most of the work. On the other hand, it is less of a "coprocessor" than you believe, and not in any way comparable to a CPU. It has display lists, which is a nice architecture, but it's not like a second CPU attached to a full-fledged graphics chip. It is the front half of a graphics processor while the GTIA is the back half. Together they form a very capable graphics processor that was too hard to fit on one chip, while the VIC-II is a full and also very capable graphics processor that does fit on a single chip. Without the display list and a lot of kind of useless modes the ANTIC has (such as the giant blocky character modes and other modes that are hardly ever used), Commodore managed to get everything on one chip, and it still works great. They even saved enough silicon to include an improved sprite system. The ANTIC + GTIA are also great, but one can't work without the other.
@@rbrtck Only the CPU would be halted. It wouldn't be doing anything anyway. That's the point I keep making. I wasn't making any of those outlandish claims about the ANTIC being a Super Co-Processer. It does do all of the graphics processing to the point that the CPU can be turned off for a while, so it's adequate for the task of being a graphics co-processor, in addition to the tacked-on low level timing for the GTIA. Graphics processing on the Atari does take priority over the CPU cycles, but I believe that's what Atari intended in their grand vision, this being their next gen games system. I got the functionality of the GTIA and relationship to the ANTIC way wrong though, as you pointed out.
Great video. I don't know much about the world of Atari's, but this was really fun video. Matt Hefernan has made a video about BASIC speed between three 8-Bit machines, too. The Commodore C64, the ZX Spectrum and Commander X16 in Part 1 and in an other video he brought new contenders: ZX Spechrum Next, the Amstrad CPC 464, the Apple ][, the Atari 800, and the BBC Micro. This were now an opportunity to test the Atari 64. :-)
The player (Atari sprite) pixels are twice as wide as those of the 40-column, single-color-character text modes (ANTIC modes 2 and 3, GRAPHIC 0 in BASIC), so I suppose you could say that they are at a lower resolution (another way of looking at it): 160 pixels across a normal screen instead of 320. This makes players, by default, two characters wide. For comparison, C64 sprite pixels are about half as wide (and the same width as the 40-column, single-color-character text modes). So despite having 24 pixels across versus 8 horizontally, a C64 sprite is only 50% wider than an Atari player across the screen. In addition, players can be doubled or quadrupled in width, while C64 sprites can be doubled at the most. This means that at their widest, Atari players can be 33% wider than C64 sprites despite having one-third the resolution.
@@8_Bit No, in single-width mode, a player spans two 40-column characters, so it starts out with pixels that are twice as wide in comparison, and can be doubled or quadrupled in width from there. This can easily be seen in games that use players, and is why characters in Atari games (certain types of games, of course) aren't as well defined as in some corresponding C64 games, such as _Mail Order Monsters_ (C64 sprites have the same pixel width as players when in multicolor mode, though, so this isn't always true). What I've long wondered, by the way, is why all of this information isn't as easily accessible as it is for many other systems. Reference texts really should spell this stuff out, but few, if any, do.
Atari vs C64 clock speeds & differences: I believe that some of your explanations miss the mark. The timer is linked in both original Atari OS and in C64 kernal to the VBLANK which will be exactly same on both machines (if both are same TV standart PAL or NTSC). In other words the speed of the processor can not influence the timer test. The other tests ... all good.
The C64 KERNAL timer isn't tied to vblank, it's instead part of the regular system IRQ that's triggered by the CIA at about 60 Hz on both NTSC and PAL C64s. I didn't want to assume that the Atari 64's TI$ was accurate, so that's why I did the stopwatch test with it for a full minute and saw that it seemed very accurate, before using TI$ to benchmark C64 vs. Atari 64. I was making sure TI$ was working consistently between C64 and Atari 64, and then was able to calculate the 1.17 difference in the BASIC benchmarks between the two machines.
Well, for text mode it could work. The bizarre byte layout of the screen should be doable, or at least it could be copied over to the real screen from a fake screen. But the way the Apple had 7 pixels per byte rather than 8 pixels per byte ... no practical way to deal with that.
It can't really emulate the C64, though--only the most basic of BASIC programs that don't use characters of more than one color, which in the real C64 world tend to be very rare. Even if we're not talking about emulation of BASIC but just trying to do the same things in any way possible, there are things the C64 can do that the Atari 8-bits cannot, and vice versa.
@@IsaacKuo And if we include graphics, since Apple's BASIC has graphics commands, it couldn't be done completely because of the way the Apple II handles color. Using the hi-res mode with artifacting would partially work, if translated, but there is no practical way to get the two additional colors (on each scanline) on the Atari.
@@rbrtck There were plenty of C64 BASIC programs which didn't use color, just not many commercial games (outside Infocom text adventures). Are these programs of much interest to retro enthusiasts? Okay, not really.
@@rbrtck I was just thinking of monochrome emulation, but there is a trick the Atari could use to emulate Apple ][ color. You could switch between two fields, where one field is black/purple/green/white and the other field is black/orange/blue/white. Each field, only the screen pixels corresponding to the displayed palette are shown. However, performance is going to be abysmal due to bit shifting during conversion from 7 pixels per byte to 8 pixels per byte.
Yes, but for various technical reasons, it would probably take a lot more work. This has nothing to do with which computer is supposedly more capable, it's just how their characteristics happen to align.
The main issue I see is the floating point ROM at $d800.$dfff, on the Commodore 64 the $d000..$dfff area needs to be switched between I/O and RAM, while on Atari the I/O at $d000.$d7fff is always visible. You would need to rewrite Atari BASIC to switch $dxxxx between I/O and RAM and Atari machine code programs that try to call routines in the floating point ROM won't work.
@@danielmantione It might be easier and better to relocate this 2K floating point ROM to $C800-$CFFF, which should be available if the 800's OS ROM is used instead of the 800XL's. Then the C64 I/O map can be left banked in (as well as the color map, although that might not be used after initialization) to avoid all of the switching and extra code that would require. Running machine code doesn't matter much, because the idea of _Atari 64_ is really to port the other computer's BASIC and default environment. Most machine code would run anyway, unless it calls the floating point routines, and of course the I/O will always be different.
Yes, it would most definitely be possible, although it would be a lot more work for reasons that have nothing to do with how the computers compare technologically.
From the main Atari 64 github page there's a "Releases" link on the right, and that page has the atari64.xex executable. I'm surprised there isn't a tab at the top of the page for it; that might be why I didn't realize there was an executable at first either. github.com/unbibium/atari64/releases
So instead of coloring the characters, you are redefining them. That's a pretty cool trick in its own right, but then what you did here would not work on a regular C64.
Maybe I don't understand what you're saying, but C64 definitely allows redefining characters. You can't modify the ROM, but you can copy the character set from ROM to RAM and edit them in that way.
@@casaderobison2718 What I was saying is that what redefines the colors on C64 redefines the chars on A64, as the video clearly shows. If you use the A64 poke instead of the standard C64 pokes to redefine the chars, however, you'll redefine the colors instead, and thus the "modified" program would not work so you should still use the standard poke to redefine the chars anyway.
@@kespeth2 I think I see what you're saying. Yes, the memory map is going to remain a stumbling block to things like this. Frankly, I think it is amazing it is able to do as much as it does.
@@casaderobison2718 That's right, and you don't even need to copy the ROMs at all--the VIC-II chip doesn't care whether the character set definitions are in ROM or RAM, so just load yours from disk or DATA statements in BASIC or whatever, and point the VIC-II to its address. Copying from ROM first is just done because maybe only a few character definitions will be redefined. I'm sure you know this, but for public consumption, especially by Atari fans who might not be very familiar with the C64, I thought I'd mention it. There is another little difference, by the way. The Atari's character set has 128 characters addressed by 7-bit character codes. When the 8th bit (the highest one, with a value of 128) of the character code is set, the character is displayed in reverse/inverse coloring (foreground color switches with background color). The exact same thing seems to happen on the C64 despite the fact that its character set has 256 characters, but that is only because its built-in character set definitions (in ROM) have 128 inversed definitions following the first 128 definitions. Unlike on the Atari, they do not have to be reversed--they can be anything you want, which means that the C64's character set really has 256 characters that are addressed by full 8-bit character codes.
Yes, it's a customized Microsoft BASIC. MS provided the original version used on the Commodore PET, which included some customizations such as the SYS command, and then Commodore programmers modified it further for later PET revisions, and then for the VIC-20, and then a little more for the C-64. The integrated full-screen editor is also a Commodore feature.
You could redefine the colors (including graphics mode and player/missiles objects) for each display line on Atari tho (not scrolling but fixed per line). Copperbar demos are usually just shifting background colors for each display line up and down.
@@TheDemoTube Problem is, that would change the color of the entire scan line. The C-64 can have any arbitrary color in each 8x8 character cell, potentially putting all 16 colors on each scanline without even using raster-synchronized color changing tricks, and this can be done in the (otherwise decidedly "not good") basic 2.0 that the system shipped with, using just the PRINT command. Also, I don't think that he touched on this, but the C-64 also has video fetch issues that freeze the processor. The C-64's memory is actually double-clocked at 1Mhz (DDR access long before most people heard of DDR memory) and the VIC-II automatically gets every other slot. But every 8 scan lines, the processor gets locked out for 40 cycles for retrieving SCREEN RAM. Also, any sprites that are active on a given scan line each stall the processor for 2 additional cycles. In an absolute worst case scenario (where sprites are being multiplexed and it is always displaying 8 on each scanline), the processor is locked out for (((40{screen ram cycles}+(2{sprite data cycles}*8{sprites active}*8{scanlines of sprite per character row})))*25{character rows}*60{frames per second}) = 252,000/1,022,725 = 24.6% of the available clock cycles, effectively operating at 770khz. Without the sprites, it ends up being 962khz effective frequency. Typically sprites aren't multiplexed, and with only 8 sprites on screen it ends up effectively being ((40*25)+(8*2*21)))*60 = 80160 cycles, or 942khz.
@@glenndoiron9317 You are correct that on the C64 the VIC-II does halt the CPU for DMA, but it's nowhere near as much as on the Atari 8-bit, since *all* of the graphics data is fetched through DMA on the latter. The hit the C64's CPU takes with 8 sprites active (and in any graphics mode) is 1336 cycles/frame out of 17095 cycles/frame total, while in the default text mode (GRAPHICS 0), the hit the Atari's CPU takes with player-missile graphics active is 12038 cycles/frame out of 29868 cycles/frame total. So the C64's CPU loses about 8% of its cycles to graphics DMA, while the Atari's CPU loses about 40% of its cycles, which is obviously a big difference. Per-frame, in this scenario, the C64's CPU has 15759 cycles available compared to 17830 cycles for the Atari's CPU, making the Atari's CPU only about 13% faster (while their frame rates are slightly different at 59.82611 Hz for the C64 and 59.92275 Hz for the Atari, this does not make much of a difference in the final result, which still has the Atari's CPU about 13% faster).
Hey Robin, when you go to a meetup, you should print a tshirt that has your hands on it, so people know who you are. Or just your right hand that has your "hi" hand motion on it.
It's a 6502 program running on a different 6502 computer. Essentially, it was ported to the Atari. The Atari still can't run any C64 software except for the simplest of BASIC programs. No sorcery involved.
I reckon the dislikes are from Apple users... after spending that much money on a system that didn't play games very well. 😁Speccy owners knew their system wasn't the best, but they had the cheapest system and the cheapest games library. 😉 My ZX81 was replaced by an Atari, but I nearly got a Spectrum. Atari had some great games, but never had the sheer number of games they did.
Atari users must not be very bright, then. j/k ;) Running the C64's BASIC is one thing, and it can't even change character colors in BASIC like on a real C64. Nearly everything else about these computers' hardware is different, so no.
I actually consider this to be a virus. Atari BASIC and its cousins (BASIC XE, Turbo BASIC XL) are far more powerful with their commands to support sound and graphics directly whereas Commodore Basic requires a ton of POKEs to get anything exciting to happen. And the handling of strings in Atari BASIC is so powerful. At least the border is black on the venerable Atari. I don't know how Commodore users put up with that border. I downloaded a copy of the Atari 64 (more of a joke program and less of a virus) to see if it really lets me POKE 764,255 to clear the keyboard debounce or PRINT CHR$(125) to clear the screen. I don't have it, but Atari did license and produce a version of Microsoft BASIC for the 8-bits. It loaded from disk last time I knew anything about it. BASIC XE from Optimized Systems Software even adds support for sprites, among its many new features. That screen memory poke should not have worked. Screen memory is pointed to with 88,89. And the author could have saved memory space by using the Atari font in ROM. This interpreter should not be mapping Commodore 64 POKEs to the Atari hardware. The Atari 8-bit can turn off its screen to speed it up, and you should try Turbo BASIC XL to really see the speed. For a short ML bit, POKE it into Page $600 (1536). That 53272 poke would have been a SETCOLOR. The Atari 8- bit actually has 256 colors. 16 colors * 16 luminances. You can set up a string in Atari BASIC to contain all Sprite data and set PM BASE to point at it but it has to start on the edge of a page in memory. Then you can use Atari BASIC string manipulation to move it vertically if you want. ;) The one thing missing it the keypress sound. Nick should get a copy of Mapping the Atari and something for the Atari OS routines and jump tables.
Clearly Commodore BASIC v2 was not the best BASIC in the world. I don't know anyone, even die hard Commodore fans, that would try to claim otherwise. Though having to peek and poke so much to access the hardware did help one learn more about the underlying hardware and was beneficial when one tried to transition to assembly. But that's just looking for the silver lining. That being said, memory addresses map to one of two things more or less. Memory or hardware registers. This technique (a simple port of C64 firmware to the Atari) can't do anything about hardware register locations (probably; it is possible to have relocatable registers, but I am not aware of many or any 8-bit machines that did such a thing). When it comes to RAM values though, the utility of those are defined by the firmware of the system. Mapping the Atari would be a useful book (I assume, having not read it) to know where hardware features live. I bet it, or something like it, was used in this very port. Other addresses though would change the instant the firmware changed Atari to Commodore. As for using the Atari font instead of the Commodore font, what's the fun in that? If you want to make it simulate (as much as is reasonably possible) a different computer, you need the font! :)
I have never seen any convincing graphics commands in BASICs, those circles and boxes get old soon. The C64 BASIC being that sparse and sleek has the advantage of more address space being available for code and data.
@@NuntiusLegis True, but of course it depends on what you're trying to do with the graphic commands. High grade gaming, no. Business graphics, yes. Of course, the latter isn't going to get much traction today, but they were valuable 40 or so years ago.
There were alternative BASIC interpreters available for the C64. It wasn't limited to what was built in (and the 400/800 technically didn't have any BASIC built in).
I would argue that the Atari at ~1.7MHz is approximating twice as fast as the C64's ~1.0MHz. Consider the 700KHz difference *and* that the VIC-II isn't stealing cycles on the Atari! Consider also how much faster the Atari's disk drive is... EDIT: didn't consider the video mode cycles, it's probably just down to the disk drive not being several hours of waiting on an Atari Also, it looks like those screen colors are closer to the C64 viewed over RF. As a C64 and Apple II user you have now encouraged me to buy an Atari 8 bit computer.
The default setup of the 1541 interface ended up at 1/8th of the intended speed (somewhat easily modified) and I'm uncertain if this was inherited from the VIC-20.
Nope. The VIC-II only sometimes steals cycles from the CPU. It usually doesn't have to because the RAM is twice as fast, and the VIC-II and CPU share it equally without interference. As long as a screen is visible, generally the VIC-II will only steal about 6% of the CPU's cycles, and with 8 sprites visible, the total is about 9%. Meanwhile, the Atari's ANTIC chip steals everything it needs from the CPU when anything is being displayed (as you acknowledged in your edit). Even with just a BASIC text screen being displayed, that 1.79 MHz gets chopped down to about 1.15 MHz. It's still faster than the C64, but not by all that much. As for the drives, there are and were many simple options available that boosted C64-1541 speed well beyond that of the stock Atari-1050. Even purely software-based fastloaders (commonly built into commercial software) could be very fast, comparable to Apple II drive speed. Think of it as a DOS upgrade. The Atari could also be sped up, and many users did that, but even then, it still wasn't faster than the sped-up C64. All of these 5 1/4" floppy drives used similar formats and mechanisms, so none were really faster than the others, in terms of potential. What matters is the protocols used.
@@josephkanowitz6875 The story is kind of sad, lame, and complicated. :) First let's start with the Apple II, as an example for illustration. It had expansion slots from the start, so a floppy drive card could be created to interface it with floppy drives, and the way Steve Wozniak implemented all of this was very simple, efficient, and elegant (as usual for him). Contrary to popular belief, drive speed (concerning the kind of drives we're talking about) has nothing much to do with serial versus parallel cables and data transfer. The disks stored data in a serial manner regardless, and that's how they were read, even on the Apple II. Most of the wires in the parallel ribbon cables were for the computer's CPU to be able to control every aspect of the very basic, "dumb" Apple Disk II drive mechanisms. The raw GCR data was read bit-by-bit, translated into the actual data, and stored in memory by the CPU in the Apple II computer itself, all in real time. That's why the Apple II is so fast with its floppy drives, in comparison to other 8-bit computers--from the Atari/Commodore point of view, the Apple II computer pretty much *is* the drive, and the drive mechanism is part of it. The reason Commodore instead used "intelligent" drives with separate interfaces and various protocols to transfer data, in the first place, was that the PET wasn't designed with expansion slots, and therefore would not have a floppy disk controller. For future expansion, an IEEE-488 port was provided, and it did have parallel transfer at up to one megabyte per second, which was way faster than necessary for floppy drives. Commodore also had to put another 6502 CPU in the drives to do the reading and translation, hence the "intelligent" drives that were like limited computers in and of themselves. The drive's CPU was internally interfaced with the mechanism like the Apple II computer's CPU, and then it had to transfer data to the main computer after reading it. Commodore also decided that most of the low-level DOS would be on the drive itself, and that the computer would communicate at a higher level within its own ROM. Like Atari (who must have had their own reasons for doing things in a similar way), they were, perhaps accidentally, ahead of their time, and sometimes that comes with a price. This setup worked fine for the PET, and even allowed it to do cool and pragmatic things like share a single drive or set of drives between a set of PET computers, which you can't do on an Apple II (at least with floppies). But when it came time to make a drive for the VIC-20, the 1540, they decided to go with a still somewhat innovative but much cheaper 6-pin serial port. It was *much* slower than the IEEE-488 standard, but it was fast enough for most peripherals, and the floppy drive speed was intended to be quite high by using the 6522 VIA I/O chip's hardware serial interface. Unfortunately, it turned out that the 6522 had an unexpected bug in its serial transfer function, and there wasn't enough time to fix it, so they defaulted to a very slow but utterly reliable protocol. It didn't matter anyway because the VIC-20 only had so much memory to load into, and Commodore fully expected the vast majority of users to use a Datasette tape drive instead, for cost reasons. When the C64 was being designed, along with the 1541 drive (compatible with both the C64 and VIC-20), both were slated to use the 6526 CIA I/O chip, which had perfectly functional and very fast hardware serial transfer. Unfortunately, however, the new ROM code for the fast serial transfer (to be known as "burst mode") had not been written yet, and at the same time, the C64 main board had to be redesigned slightly to accommodate a couple of additional mounting holes. It turned out that the lines (copper traces on the board) that enabled the fast serial transfer ran right through those hole locations, and looking through the current ROM code, the idiots at the factory didn't see anything using those lines, so they were removed from the design, which was easier than rerouting them or moving the holes. When the C64's designers found out, it was too late, as about 250000+ defective C64 main boards had already been manufactured. The designers were livid! They wanted to give up on the C64 and quit their jobs right there--they didn't, but that's how they felt. Management decided that since not many people were expected to buy the 1541 anyway, because the C64 was, after all, a home computer rather than a business computer, the fast serial transfer would officially be deleted, and the C64 would use the very slow transfer protocol of the VIC-20 (modified to work with the VIC-II's DMA) because that was the safe route and, as usual, there was no time left to do better. The C64 kept its 6526 chips because it made use of its other features, while the 1541, which was still being designed, was given the bugged 6522 because it was slightly cheaper and the 1541 no longer needed fast hardware serial transfer. :( Commodore management, of course, was dead wrong about the 1541, which sold like hotcakes (especially in the US and Canada) despite the slow transfer protocol and its somewhat high cost. Solutions to the problem would soon arrive, however, because the 1541 was programmable by the computer through the serial port, so much faster protocols could be developed, tested (now that there was some time for that), and uploaded to the drive. Cartridges and ROMs would also be available to greatly speed up drive data transfer when using software that didn't have its own such system (or pirated software that often had their fastloaders removed for technical reasons). And Commodore's "burst mode" would finally be implemented on the C128 (but only in 128 mode with the 1571 drive), which of course doesn't help the C64. Not that the C64 needed help, once the user forked over a little cash to buy a fastloader cartridge or, even better, a JiffyDOS ROM set (one for the C64 and one for each 1541).
This is impressive work, but fairly pointless because the Atari XL computers are excellent, ancestors of the Amiga computers! What's really needed is Atari BASIC and OS on the C64. The only problem some people might find is the lack of LEFT$, MID$, and RIGHT$ commands, but this is because string handling is totally different in Atari BASIC. There was a listing in a Compute! book to implement Atari BASIC graphics commands on the C64. I hope someone can reverse this Atari 64 software to make the Catari or C64XL!
Other problems: Slower floating point arithmetic, no string arrays, no integer variables, no bit-wise operators, line editor instead of full screen editor.
It's also pointless because the Atari still can't run any C64 software, except for the most simple, vanilla BASIC programs. But nonetheless it's interesting.
Going the other way isn't needed, either, because there are better BASICs available for the C64 (in cartridge format), and the C64 can't run non-BASIC Atari software any more than the Atari can run non-BASIC C64 software. It would be kind of fun to "return the favor", though, and this did cross my mind as a project I might take on. The problem, however, is that I think it would be a lot harder (and much more work) to port the Atari OS and BASIC to run on the C64. The reason has nothing to do with which computer is supposedly more capable, but simply how some of their characteristics happen to align by chance. The main problem is that the C64 can support the Atari's extra 2K of ROM at $D800-$DFFF with RAM, but only by switching out both the color map at those locations, which is no problem, and the memory-mapped I/O at $D000-$D7FF, which is a major problem. Unfortunately, the C64 wasn't designed to switch out one or the other (only both at once or neither), or else porting the Atari OS and BASIC would probably be just as easy as the other way around. The C64 could have had this functionality easily enough, but it wasn't considered necessary, so it wasn't done, and that's that. Again, it is not a matter of relative capability. The Atari (800XL being the minimum variant required for _Atari 64_ ) can switch out ROM for RAM (in this case, it was used for the C64's character set) at $D800-$DFFF while keeping I/O at $D000-$D7FF because it can't switch out the I/O at all. This 2K of RAM that is physically present on the board cannot be accessed by the CPU at all, which means that the 800XL, for example, is effectively a 62K computer. The C64, on the other hand, not only can access all 64K of RAM, it also has an additional 512 bytes (in the form of 1024 4-bit nybbles of color map RAM), which technically makes it a 64.5K computer. Well, it does lose two bytes at addresses 0 and 1 to provide the port for bank switching, so it's actually 64.5K minus 2 bytes. The Atari can't switch out the I/O bank because that's where the bank-switching port itself is located. Luckily, though, this isn't necessary for the Atari to run the C64 OS and BASIC without much effort, while getting the Atari OS and BASIC to run on the C64 would be more challenging and involve a lot more legwork. It could certainly be done, just like how any software could be ported to work on either computer, but the probable amount of work that would be required to create a _Commodore 800XL_ isn't worth it. I won't spend weeks or months slaving over something that will end up being a quaint little curiosity--there are simply too many demands on my time. That's too bad, but maybe it's important enough to another programmer for them to give it a try. EDIT: After typing all that, I guess I'll give it some more investigation and thought, as it seems that this 2K ROM area at $D800-$DFFF only contains the floating point math functions. If I could relocate it (and change all of the calls and/or hooks in BASIC), then maybe it wouldn't be so hard to get everything to run on the C64 after all.
How about the Commodore 800 or C800? 😁 After revisiting and investigating this matter further a few days ago, I figured that it actually might be a bit easier than I had initially thought. A few days later, I now have a working prototype of an Atari 800 (non-XL) "emulator" for the C64. It's actually more of an emulator than the Atari64 (which is more of a port), since one of my goals was to make the fewest changes possible to the ROM code, as well as do the least possible amount of work (because I'm busy enough as it is). A few small patches in the OS ROM were necessary (7 that range from 1-3 bytes each), but otherwise I didn't port the Atari ROMs to work on the C64--they actually "believe" that they are running on an Atari 800. Atari BASIC's (Rev. C, of course) code is entirely untouched. That's because the C64 can switch out its I/O map address space for RAM, which I then managed the values of from a "master" interrupt routine that works outside of the control of the OS. This routine emulates the essential functions of the POKEY, ANTIC, GTIA, and PIA chips, storing the values they provide to the OS in this RAM (at the appropriate addresses, of course). The OS reads these values as though they were provided by the chips, and is none the wiser. 😄 The master interrupt routine also reads the values stored there by the OS, and acts on them when necessary. Atari interrupts are all emulated in this system, as well, and happen when the C800 wants them to happen. Of course, this "emulation" is very limited, similar to the Atari64 in this way (i.e. really only supports BASIC, albeit not the graphics commands since Atari BASIC hasn't been modified for the C64 in any way), and unfortunately the method I used incurs a small overhead, slowing the emulation down a bit, but on the plus side, I can claim that the C800 actually is kind of an emulator rather than a port, which is something that can't be done on the stock Atari 800XL in exactly the same way (it would take a huge number of ROM patches) because it can't switch out its 2K I/O map address space for RAM (therefore it can only access 62K of its 64K of RAM, while the C64 can access all 64K plus an additional 0.5K of color/attribute memory). I will finalize the prototype this weekend and put a working binary on a file server, probably in a .d64 file. All that remains to be done, at least at this point, is to get the click for keyboard input sounding right (important for an authentic Atari experience!) and implement a convenient way to select between BASIC (which on the 800 requires the BASIC cartridge) and the Memo Pad (the 800's default built-in application). I've managed to make the SID sound a lot like the 800's click, but it's slightly off, so instead I might try to use digital output based on the same click routine in the Atari OS. This will require another patch that consists of a small subroutine (different from all of the others), but I have to get that Atari click sound as accurate as possible. It shouldn't take too long, and if all else fails, the SID sound I made sounds pretty convincing, so I could always use that. Stay tuned for further developments.
@@NuntiusLegis Eh, it's just a stunt anyway, but it kind of annoyed me that it only went one way, so ultimately I decided to return the favor, and now have done so in a different manner that took a lot less work (I think?) yet is a real emulator in some ways, as opposed to a port like the Atari64. The C800 (or Commodore 800) will be coming soon (like in a day or two). It's just a prototype, but I think it is fully, if minimally, functional, and of course more functionality can be added. Stay tuned. I will probably release the source code at some point, but it's a mess that only I could understand readily, because this project was originally intended as a "quick and dirty" proof of concept that I didn't know would ever work, as designed. It needs serious cleanup, which I plan to do, but for now, I'll finish and release the prototype once I'm happy enough with the keyboard click sound. Read the comment above for more details.
![[LIVE] : ONE ลุมพินี 88 | คู่เอก "ป้อมเพชร vs อัสลามจอน"](http://i.ytimg.com/vi/1ZqTVVbMgbo/mqdefault.jpg)
I ran a (mostly) Commodore-related BBS on an Atari 130xe from 1990-1996, all the while being a member of both computer's user groups. If this existed in the same time frame as my participation in the user group(s) I could have blown some minds.
I did actually transport an Atari system to the meeting, ran the BBS on it, and hooked a Commodore 64 up to it with RS232 null modem cable to demonstrate what the user would see, and what the BBS is doing, simultaneously. I even had new users sign up with that system, then when I got it home I copied the new-user data to the actual online system so the next time they called in with their computers at home, their accounts would be active. Being a fan of the Commodore and the Atari 8-bit systems made this video especially interesting to me. Thanks for posting and keep up the grrreat work!
I did a lot of the same! I ran my BBS mostly on an Atari 800XL with a 1mb MIO RAMDisk hosting Oasis BBS which supported ASCII, ATASCII, PETASCII, ANSI and VT52 all off this one computer's BBS software. It was lovely and long before a lot of other BBS's started to do similar things near the end of the dial-up era. I loooove Atari's and Commodores, both, but the Atari's were always my favorite.
The Atari was such a beautiful looking machine. In my humble opinion.
Yes, I like the 1200XL in particular, and the 600/800XL are nice too.
The later model Atari cases seem to want to emulate the Commodore machines overall. Jack Tramiel influenced these later case similarities?
@@CityXen Tramiel carried his supermarket/toy mentality wherever he went.
I have an 800XL and a 65XE and the difference in quality shocking.
@@nickolasgaspar9660 I think the XE line gets some undeserved criticism. Yes, the kb isn't as good as the mitsumi ones on the XL but not every XL has mitsumi kbs. Also some of the XL's kbs flex cables fall apart very easily, including mitsumi. Then theres the claim that the XE had worse internal components despite arguably having comparable defect rates and better video output. The PCB is said to be of worse quality which may be true but personally my XE's PCB wasn't nearly as unforgiving when modding as often claimed. And then theres the futuristic ST design which people either love or hate.
@@haraldhimmel5687 well I have both and I can only judge and comment on those specific models.
My XL has an 800xlf motherboard.
The pros and cons of this machine are:
Pros
1. 4 colors/materials used resulting to a superior aesthetic.
2. Mechanical keyboard with a good ribbon cable.
3. Connected Chroma great video overall
4. Superior quality PCB.(fully socketed without any issues).
Cons.
1. MT Ram chips
2. Svideo not separated from composite
3.Bad flip flop chip.
My 65XE has a 900XLF motherboard.
Pros.
1. No problems with ICs or any other part.
2. Good Ram chip brand
3. svideo
Cons
1. Plastics are chemically deteriorating (hot summers in Greece!)
2. Awful keyboard
3.low quality PCB. Some traces were lifted during socketing. The traces on the back side of the board are oxidized.
3. Aesthetics of a toy computer when placed next to the XL. Having it alone on the bench or next to an Amiga it looks great.
We see all these obscure POKEs to hack the screen editor.
If only there were footage of using SHIFT-ATARI to go into lowercase mode. That chord feels very satisfying and natural on an 800XL where they're next to each other. I never considered how different the 1200XL's keyboard layout is.
I wish I'd thought of the upside-down POKE at 21:05.
The Video Reflect mode at 21:05 was likely born out of Atari's Arcade lineage where some games (to get a larger apparent display) employed mirrors. I imagine that the people who designed this feature had the idea of mounting this computer (or some derivative of it) in an arcade cabinet or (for more practical applications) using a mirror to simulate a large screen for a business presentation in a meeting room.
That's what I assumed too, except it doesn't flip the entire screen, just individual character graphics? Seems like that would make designing the thing harder; you'd have to actually have a mirror handy instead of just coding the game as if it were normal and then adding the "flip" code just prior to shipping.
This reminds me of that crazy project where Atari ST TOS was ported to run on an Amiga. It was a hacked ST TOS ROM shoved onto an Amiga 1000 kickstart disk. so you could boot directly into ST-TOS. It was pretty neat, but iirc, disk routines weren't complete, so you couldn't write to disks yet.
How about Magic SAC? It was a cartridge for the Atari ST in which you installed Mac ROMs and with boot software lets you run Macintosh software on the ST.
@@theannoyedmrfloyd3998 : oh my, I thought I was the last soul on earth to have heard of Magic Sac ! The concept was incredibly neat and if memory serves, it almost doubled the screen real estate compared to the original mac, at the expense of the sound that couldn't be emulated.
@@ordinosaurs Much later there was the reverse, too.
FYI: You can now boot an Amiga from disk to ST Desktop, with MiNT & full GCC toolchain (Vampire as well). Check out EmuTOS on SourceForge (yes there is a ROM replacement as well).
@@theannoyedmrfloyd3998 There were similar items on the Amiga as well like AMax. It let you have different Mac ROMs plugged in for emulation and also provided peripheral ports to use Mac devices with. Later on, you could emulate a Mac in software with Shapeshifter and have the Amiga run MacOS faster than a Mac could natively which was a little amusing. It helps a lot when all three machines using the 68k processor as it removes a lot of complexity with emulation as well as extra over head.
0:39 Yes all 1200XL's have socketed ROMs and yes all of the IC's are socketed, except perhaps one. They have excellent build quality. The OS chips usually have 24 pin sockets however about 1/6th of 1200XL's have 28 pin sockets which make it easier to install OS upgrades. Another variation with 1200XL's is that when the case top is removed, the cart plug connector uses stiff hard wires to the motherboard but some utilize a flex cable. I've seen them with 300ns RAM (which works) or 200ns RAM.
I didn’t know the cart port had differences my 1200xl I’ve owned since new has the 28 pin sockets and hard wires, haven’t looked at the ram.
Awesome effort. I am reminded of how I complained that the monochrome Apple II we were using at school wasn’t as good as my 64. I quickly mocked up the start-up screen text of a 64 on the Apple, and disabled the reset key. I then declared the Apple “fixed”. The teacher was no amused. Can’t imagine her face if she saw this type of system takeover.
Is it weird that I'm watching this hoping someone actually further updates this to use all the hardware features so games & demos can be made to push this hybrid to its limits?
..for science and fun, ofcourse!
Damn, that web browser intro reminded me that I wrote an intro when Flash 3 first came out (1998?), to demonstrate to the other developers what was possible. Later I wrote a Javascript (DHTML?) intro for my Mom, "the living christmas card" :)
No doubt at least 1 person will scream "heathen blasphemer", but it won't be me. I've always liked both companies 8bit systems.
15:41 It does prove that clock speed isn't everything. Architecture can make just as much of a difference. Sometimes the two work together, sometimes they cancel out, sometimes it falls somewhere in between.
Yes, the Atari screen is wider by 8:7 compared to the C64. Each Atari character is exactly 4 chroma cycles wide. Each NTSC C64 character is exactly 3.5 chroma cycles wide.
The Apple ][ also had characters that were exactly 3.5 chroma cycles wide, but Woz designed each character to be 7 pixels wide. Along with various other specifics, this allowed composite color artifacts to be used for color.
The C64 (and actually also VIC-20) went the opposite route - trying to eliminate composite color artifacts by reversing chroma phase alignment each field. The 3.5 chroma cycle width was combined with having an odd number of video chip cycles per scanline, and an odd number of scanlines per field. Voila! The color fringe artifacts are reversed each field, visually eliminating them.
Composite color artifacts could be exploited on almost all the other computers ... Apple ][, Atari 8-bit, IBM PC, CoCo ... but the cost was ugly color fringe artifacts. The VIC20 and C64 had nicer displays, but it was not possible to take advantage of composite color artifacts. (Well actually, it was possible if you switched between two different screens each field, but AFAIK no one took advantage of this.)
My grandfather bought the first edition C64s, where the VIC chips had a different number of cycles per scanline. This made a lot of intros and demos have oddly-shaped raster bars until I replaced it. But I also noticed that text got a lot clearer when I got the new chip; before, certain color combinations would distort the letters. This must be because the oldest VICs lacked that phase reversal thing you just described.
yes, the old VIC chip had sparkly sprites too. i think this is the run they skipped QA on so they could get the 64 out in time for Christmas.
@@nickbensema3045 That is correct, but I'm just going by deduction from what I know of the early C64 hardware. I've never seen it myself, nor seen any footage of the early hardware on TH-cam or screen shots.
I'm so glad to hear my suspicions confirmed, though!
Back when I was a kid, I had absolutely no idea what was going on technically. I just knew that other computers had what I called "color distortion" at the time. And the VIC-20 and C64 (as far as I knew) did not have it.
I had something of an idea of how color worked on the Apple ][ because the school computers had monitors with a color/monochrome button. In monochrome mode, you'd see colors turn into vertical stripe patterns. But when I tried to render vertical stripe patters on my C64 ... no color. So I knew something different was going on, but it would be years before I learned enough details of NTSC color to understand what it was.
Composite arctefacting technically possible, but quite a bit more difficult in PAL. Systems dependent on composite arctefacts therefore were NTSC only, i.e. the Apple II was monochrome in PAL countries, while IBM PC's with CGA had to rely on their RGB output.
Commdore and Atari machines, on the hand, had proper chroma signal generation, and allthough not perfect, they were reasonably transparant between PAL and NTSC and did therefore allow for a global software library.
This was a major factor in the success of these computers and explains why e.g. the Commodore 64 sold much more PAL than NTSC units.
This is only true in the world of Enty Essie. My PALs prefer 4.5 chroma cycles per character.
@@danielmantione While it's true that the Apple ][ was crippled in PAL countries, the C64 faced stiff competition from ZX Spectrum, BBC Micro, and Amstrad machines which were practically not available in the USA. Note that the Apple ][ didn't really sell as well as the C64 here in the USA either. But they cost a lot more, so it was able to keep Apple in business.
If there's any one factor explaining why so many more PAL C64s sold than NTSC C64s, it's the NES. Commodore USA desperately wanted to be perceived as a serious business computer brand, so the C64 (and later Amiga 500) weren't pushed so hard as games machines. So, people who just wanted to buy a game machine for their kids bought an NES.
The USA videogame crash of 1983 made a lot of companies wary of being perceived as a game machine maker. By the time it was clear there wasn't going to be a second crash, Nintendo already took over.
I never owned an Atari or a C64 (sorry went the MSX route in my youth ;-)), but this is really impressive and I enjoyed watching you tinker around with an Atari running C64 BASIC greatly. Thanks.
Same (SVI 728), but later I got access to a C64 + FastLoad Cart, and even later I built up Atari 8 Bit system with 4x Floppy (when you could get a complete system from garage sale for 20$)
Very nice! I like how the Atari handles cycling through the different shades of each colour, that could become hypnotic if you stare at it for very long.
Color indirection was absolutely an Atari feature that the c64 couldn't match. That's why, unless you are testing just the CPU and memory response times, there is no good apples to apples, if you will, way to compare graphics performance.
Both systems will display graphics, but the way each one does it is very different. Each system overcomes the straight bitmap limitation on memory with trade-offs.
When you owned one of these systems, you were, by necessity, an early adopter who had to live with the trade-offs of their respective systems.
@@Chordonblue I had a TRS-80 Colour Computer 2 growing up, very different from both of these!
@@Chordonblue Actually, in its multicolor character mode (with a redefinable character set, of course), the C64 uses a combination of 1 color map and 3 color indirection registers. You can choose between this and multicolor bitmap mode, which instead effectively uses 3 color maps and one color indirection register. These modes can be mixed on the screen vertically as needed using raster interrupts. And if you want a fully addressable multicolor bitmap that uses more color indirection, that can be accomplished using raster interrupts, as well, with the multicolor character mode--just split the screen vertically into 5 sections, changing the character set definition pointer appropriately for each section.
Obviously, the C64 and A8 have different capabilities, but I think the C64 is significantly more powerful and versatile than the vast majority of A8 fans realize. The A8 can still do some things the C64 cannot, but the reverse is also true. For instance, the C64 has 256 redefinable characters compared to the A8's 128, and can mix hi-res and multicolor characters on the same line, not just on different lines on the same screen.
I still remember the rivalry my 2 friends and I had: I had a c64, friend 1 had an Atari 800 and friend 2 had a TRS80. We used to argue to the point of not speaking to one another (sometimes for days) because we steadfastly defended our position as our computer being the finest.
I still have my old C64 which my young son loves to write basic programs on.
I have to admit I still have a secret desire to buy an Atari to see what the machine is all about.
Videos like this make my late night eBay browsing gravitate towards a retro purchase. Don’t tell my old friends!
The prices on these things are going up fairly quickly, so go for it! If you're still unsure, you could always try out the Atari with an emulator such as Altirra. One of the coolest things about the Atari 8-bits, aside from their large (for the time) palette of colors, is their graphics architecture, which sort of formed the basis of the Amiga's graphics later (in fact, the lead designer was the same guy: Jay Miner). While the C64 could do the same sorts of things through raster interrupts, it's neat to be able to construct the screen piece-by-piece using display lists, which are sort of like machine code for a coprocessor known as ANTIC. The architecture is also very flexible and has a lot of modes that I think you'll enjoy exploring.
The C64 does some things better, such as sprites and high resolution (for the time) in general, but the Atari has its own strengths to match, and does other things better. They are very different computers that are pretty evenly matched on the whole, which makes the comparison interesting. Unfortunately for one of your friends, I don't think that the TRS-80 quite matches up, although the Model 4 did have 80 columns, which is an advantage for some things. All of these old 8-bit computers are cool, though, as far as I'm concerned.
Would be great to see someone implement a workalike of the classic C= hot air balloon BASIC sprite demo in Atari 64, of course with the Atari symbol instead. Perhaps a charitable donation bounty?
Oh, that's a cool idea
Well, you could place 3 Atari sprites next to each other for a 24 pixel width, but these would be twice as wide as the C64 balloon sprite because Atari sprites don't have the high resolution capability of C64 sprites.
One limitation will be that it'll be difficult to move them vertically. You'll notice that the sprite in the video covered the entire height of the screen. In more practical sprite modes, the ANTIC chip assigns a 128-byte or 256-byte slice of RAM to each "player", and to move something vertically, you have to repaint it in the new position. in BASIC this is prohibitively slow.
@@nickbensema3045 I can think of a trick to make it work faster. You can tell C64 BASIC to place the screen in a different location (and this works in Atari 64 as demonstrated in this video). At that point, you can use a fast PRINT statement to redraw the sprite's data at a different starting byte.
Back in the day, I used PRINT statements for fast sprite animation, but with the much cruder trick of simply PRINTING invisible characters in the top 2 rows (same color as background). The animation was fast, but it was also pointless ... it would be even faster to just POKE the sprite pointer for animation. It was amusing, though.
@@IsaacKuo interesting; you can move a sprite vertically with INSERT and DELETE characters that way. it's the kind of hack that would have made a demanding introduction to a would-be programmer.
there was a dancing mouse animation that moved only vertically and had a few frames of animation -- that might not be so hard to adapt.
Every time I see NEXT without a variable: "ERROR coming… oh wait, right, lol"
Wanted to say thank you for the DTV , I have one.
The 64 may not have inverse video but there is nothing preventing you from inverting the character set. It just takes more work.
There are some 'simple' things on the C64 that can also be done on an Atari... with a little more work. I'm certain this isn't meant to be a "mine's better than yours" video. For every pro there's a con on each machine, and apart from marketing department/fanboy rhetoric, there's no real winner or loser. CBM were certainly better at marketing in the early days than Atari were, which helped sell more units... but from a technical point of view, there's no decisive winner. Besides... the Atari 800 came out two full years before the C64, and in computer terms, that's a long time. 😁
If you mean inverse characters, then on a C64, just press Ctrl-9, and you'll get inverse characters. Internally, while it is true that the C64 doesn't have an actual inverse character mode as a feature, as a trade-off it has 256 characters in its character set instead of 128. The extra 128 characters are defined in the ROM character set definitions as inverse characters, so effectively the most significant bit acts as an inverse flag. The nice thing, though, is that it doesn't have to be inverse: the additional 128 character definitions can be redefined to be anything you want.
That's really interesting, a hybrid Atari 64 demo could be something very different.
Imagine what sort of "community" there would have been if this had been done around the time of ANTIC magazine. There would have been games and demos that run on _both_ systems :)
Or an _actual_ community instead of a fake/figurative-only one inside quotes.
Although, it probably would have ended up in a slagging match, where demos would be created with the specific purpose to point out the flaws in the other system. 😆
I owned the Atari back then, and I remember the micro wars. It was a very real thing.
Truthfully, people wanted to protect their investments. When you spent over $1,000 on computer, monitor, disk drive, etc, you had every incentive to want to see your system succeed over the other ones.
For me it has always been a concern that for something as fundamental as a computer different incompatible and short-lived systems exist, making it difficult or impossible to exchange software or data, more so over time. That's actually one reason why I got into retro computing - an old platform doesn't change anymore, which is kind of a relief.
Which computer platform has the most potential to become an immortal, timeless classic, with replicas of the original hardware still being made and emulators still running on then current machines decades in the future?
The funny thing is: If you want to write a program that will still run on current machines in 20 years, better write it for C64 (VICE). Second best choice I guess would be DOS(Box). I can't see a program for current Windows, Linux, Android, or iOS still running on any current machine in 20 years - and I can't see an ephemeral smartphone that quits working (or rather gets discarded despite still working) this afternoon being replicated in the future.
Actually no. Most C64 games completely bypassed the Kernal (unless text based or accessed the disk) and did their own thing as the Kernal had no graphics routines. They accessed the SID and display directly. A "demo" would not have been any different on either machine, as demos bypass the ROMs anyway. Games would not have worked either. The sound and display architectures of each machine were vastly different. The C64 shares more commonality with a ZX Spectrum in display design than with an Atari. Color cells are a Commodore and Sinclair feature. Atari used palette mapping and display lists instead. You could have multicolored text on Ataris, but doing it in BASIC was incredibly difficult.
To use the SID or draw graphics in BASIC for a C64 you also had to POKE it to the screen, as the Commodores had no graphics commands (until the 264 series). This is why porting the Kernal and BASIC wasn't a big task. Commodore BASIC is mostly a text only language. Whereas on Ataris and other machines, BASIC had graphics commands.
@@richardkelsch3640 Yet with the great graphical characters or own (modified) characters and sprites, C64 BASIC allows for better graphics than the usual graphics commands.
Interesting release, and great informative video :)
Cool! I just learned about Atari 64 a couple of days ago. Thanks for showing it off.
I like the simplicity and efficiency of the benchmarks.
Regarding ANTIC interrupting the CPU to fetch graphics: you can of course turn ANTIC off. The 1200XL, in fact, had a Function-key combo to do this! In BASIC you could, say, POKE 559,0, do your CPU-intesive stuff, and then POKE 559,34 to turn the screen back on.
In fact, clever programs like Bob Puff's SuperARC and SuperUnARC did this, but for MOST of the screen. A single status line in the center showed the (de)compression status. All thanks to Display List Interrupts! ;)
Nice video. I think if this was fully written to take advantage of the Atari and run from ROM not RAM, it would probably be about 50 percent faster than a C64.
There has always been a strong link from both the points of view of engineering and management between Atari and Commodore throughout their history.
It's weird seeing the C64 font with Atari's color palette. This would of absolutely blown my mind in the 80s! I also used to wonder why Atari computers didn't have a blinking cursor, this proves it could've been done!
There was plenty of Atari software that used a blinking cursor, but it was not implemented in the standard text mode.
This brings me back to the 1970s and early 1980s, when I used to notice things like whether a particular computer offered inverse and/or flashing characters. It's not that I didn't know those things later, but it seemed like a bigger deal at the time, for some reason.
Actually, neither the Atari nor the C64 offer flashing characters in hardware, unlike the Apple II series, which does. It's done in software (ROM firmware in this case) on the C64, and of course it can be done on the Atari in the same manner, as well.
Like all dark magic: the feat is impressive but you pay the price of damning your soul to hell.
Wow, kewl beans. I never used an Atari before, but I had considered buying one back in the day, but after some research the C64 won out for me. It was interesting to see how the colour and sprites work. Looks like the Atari would have been just as fun to program as the C64. Nice intro as well, Doc should have no problem learning 6502, it's easy and fun to learn and program.
I had always wanted an Atari as a little kid back in 1979, but my family couldn't afford to buy a decent-enough computer for several more years. I wished I had an Apple IIe, too, because it's what I mostly used at school a few years later; it's obviously not as awesome as the Atari, but I liked how it was so different, and it had some nice features of its own. I ended up with a C64 because it's a very good and affordable 8-bit computer, and frankly it was more "happening" back then, as in it had a larger user base and greater software support. It surprised me with its capabilities, as well, trading punches, so to speak, with the Atari, toe-to-toe. I became a programmer on it (nowadays often called a software engineer or developer, of course), and soon after getting my first job, which paid a lot more than my family was used to, I bought several examples of all of the 8-bit computers I had ever been interested in! :D Yeah, I had a PC (compatible), but that was for work, mostly, as well as the Internet later. The 8-bit computers are my real computers. ;)
I should have bought more of them while they were still cheap! I got my Apple IIe for $15 (plus $20 shipping) in the 1990s. It was in nice shape except for some broken key switches, which only took a few minutes to replace. I don't think I paid more than $30 each for my Ataris and Commodores. I also still have my original C64, which is 100% functional but worn smooth on the front (where my hands rested) like very few I've seen--the poor thing has had a hard life of intense use, but it's still going.
I'd love to see you play around with Atari Basic rev C or Basic XL in a video! IDK, I think that would be an interesting video!
I remember you showed that the Sid Meier's Pirates! game was written in basic. It'd be interesting to see how much would work on the Atari 64. Of course, if you can't load, that makes it difficult :)
The core was written in BASIC, but it contains quite a bit of machine code.
@@danielmantione Yeah, I figured. Still sounds like a fun experiment, even though I know it would likely not get very far at all. Robin showed that at least some machine code could be executed by basic. I know that it was much simpler than what would be in a game though.
Even if it just uses character color in BASIC, then it would fail.
Boy the Atari series of computers always seem to come out shining in retro reviews. There seem to be more mods for them as well.
It is amazing how the Commodore sold millions more units and supported for a longer period of time but Atari is getting cooler accessories such a FujiNet, simple cheap ram expansions, etc...
Robin bashing the poor C64 for 29 minutes and I still like the video. BTW there was a ZX spectrum emulator for C64 that also emulates mostly basic
Of course being a Commodore PET 2001 guy I like the proposal to take a step back from the C64 to try loading/saving PET games.
0:13 Ataris running Commodore firmware! Human sacrifice! Dogs and cats living together! Mass hysteria!
3:46 The color RAM isn't a great place to put the character set since lots of BASIC games for the C64 will POKE there.
They kind of need to intercept every POKE and PEEK operation and remap them, perhaps bit-for-bit. They could also have some kind of "shadow register" concept where the shadow registers are applied and/or updated on every system interrupt.
10:56 The C64 effectively runs at 2.04 MHz with the video chip and the processor double-teaming the system bus.
16:25 One typo and you crash the system. Though, I suppose that SAVE isn't working anyway.
27:15 There must be some kind of cheat that can be used to load the RAM using the Atari system before activating the C64 system and reinstate the loaded program afterward.
If you install this in ROM, that won't be a problem, but, like, that's drastic. but as for the executable in RAM, maybe I can try to detect XE RAM and hide the character set in there.
Atari cannot display high-resolution text or high-resolution graphics with more than 2 colours per scanline, there is no colour RAM. I guess the best you can do is ignoring any write to D800-DFFF
@@vytah .. and maybe squeeze the load and save routines in there
@@paulwratt You can't put them there, as the character set is already there. A better choice would be remove support for all kinds of C64 peripherals (as they won't work anyway) and in that newly freed space, add support for one Atari peripheral, for example the tape.
@@vytah or just squeeze in the tiny translation layer for tape load/save subroutines instead of writing them from the scratch in ML
Good catch on the different scrolling on the two platforms (there is no color RAM to scroll). I wonder how much of the remaining difference is due to differences in the interrupt handler. A C64 probably (I am not an expert as I've never written IRQ code on C64) does a fair amount more in the IRQ than Atari64 because it is trying to support the real hardware on a C64. This software merely ignores hardware beyond the screen and keyboard.
I don't mean to make this sound like I'm denigrating the effort. It is freakin' awesome! Very impressive. I doubt that the 17% to 20% difference can be attributed completely to the potentially shorter interrupt handler in Atari64, and the difference could be near 0%. Clearly having a faster CPU clock is going to help the Atari64 in almost every case.
Just the only thought that came to me that I didn't hear expressed in the video. Great job on the presentation and to the Atari64 author.
The 17% difference is almost purely due to the difference in CPU performance. The 20+% difference was because of the lack of color RAM on the Atari (in addition to the CPU). The C64 Kernal (sic) and BASIC, even on a real C64, don't do a whole lot that is related to the specific hardware. The BASIC environment on the C64 was ported almost straight from the original PET. The character sets were modified and support for the color map was added, but not much, if anything, more. Many PET programs, even the games (which use graphics characters), will run on the C64 with few or no changes. That's why porting it to the Atari was so easy (relatively speaking).
13:42: Some of the Atari's speed advantage here has to be due to it scrolling less frequently, due to the greater width. EDIT: My mistake, it's the same number of character, just rendered with a slightly different aspect.
Your videos are fantastic...
I would make a quick loop to poke the first 4 bytes of all the characters, with half the value, effectively bitshifting them all 1 bit to the right, for an italic c64 font.
If you turn off the display on the Atari, you can benchmark it for speed without ANTIC slow down. As to I/O. It may be possible to patch the Kernal to use SIO to talk to a 1541.
I wonder if it also isn't setting color on print if it's not moving it on scroll - that would give the Atari another small performance advantage... Probably not much but if guess a percent or two
There is no color map to process on the Atari, so yes. The development page even says that this code was removed/skipped. On the Atari, you can only have one hue and two values (brightnesses) in this text mode, while on the C64 the background and each character all have their own independent colors.
Well, yesterday Matt Hefferman uploaded a video comparing the speed of 8bit computers. The Atari 800 and C64 (among others) competed at generating a Mandelbrot Set fractal. (NEW CONTENDERS! 8-Bit Battle Royale Round 1 Continues)
The numbers were interesting!
Atari 800 2:16
C64 3:23
This tested the speed of Basic and in a future episode he will test their machine language.
Interesting. Atari BASIC is notoriously slow, especially with FOR loops, but the Atari runs at just under 2 MHz vs approx 1 MHz for the C64.
@@Doug_in_NC This fact makes Matt's future test on assembly language really interesting.
@@nickolasgaspar9660 It would be interesting to use the Altirra BASIC used on modern emulators too. It’s rather faster, and often installed on real hardware today (I have it on my 800XL)
@@Doug_in_NC Maybe use OSS's Basic XL or XE? What Atari Basic would have been, had Atari not limited them to just 8K. 😁 Perhaps good old Turbo Basic XL would give a really good showing too?
@@another3997 it would certainly be interesting to run them all against C 64 Basic and whatever other variants of Basic were written fir the 64 like Simon’s Basic
That's rad! Totally awesome!
I noticed that the flashing cursor is not flashing at a consistent rate. Occasionally there's a shorter delay between flashes and sometimes a longer delay.
That might just be my jump cuts where I cut out dead air; otherwise my 30 minute videos would be 40 minutes.
Somehow I missed this previously, but your video said that 53281 might be the "mirror" of 53249, and it isn't. The VIC-II has 47 registers, and the repeats happen every 64 bytes, not 32.
In any case, I was rewatching this video because I've just developed the Commodore 800, or C800 for short, Atari 800 (non-XL) emulator. 😁 Currently, this functional prototype actually is more of an emulator than a port because I made so few changes to the OS-B ROM (7 in-place patches of 1-3 bytes each plus a small key-click subroutine versus rewriting and reassembling portions of the ROM code as with the Atari64) and none to Atari BASIC (Rev. C). For the most part, the Atari ROM code "believes" it is running on an Atari 800, because the C64 can swap in RAM in place of the I/O map, and there is a "master" interrupt routine that emulates the essential POKEY, ANTIC, and GTIA chip functions through this RAM. Of course, functionality is limited to BASIC, as currently the user cannot access the C64's I/O map, although that can be changed, I'm sure. Atari BASIC's graphics commands do not work with the C64, although they could be ported to some degree in the future. For the time being, this is a simple proof-of-concept prototype that demonstrates that the Atari OS and BASIC can run on the C64 (an answer to the Atari64, I suppose), and in the case of the C800, in a nearly unmodified form with some actual hardware emulation, as opposed to being entirely ported.
Unfortunately, there is some overhead due to the emulation, which causes a minor slowdown. Benchmarks on the Atari64 are generally far more accurate because the C64 OS and BASIC were ported. But I think it's cool that the C800 is actually an emulator, which is possible because the C64 can access all 64K of its RAM (not possible on the stock 800XL or 1200XL because the I/O map cannot be swapped out). All of the Atari keys are mapped (try the C64's cursor keys in addition to the standard Control keys) except for the ones off to the right, which can be done (with the C64's function keys) but just haven't been yet. The C800 emulator runs Atari BASIC by default, but can also run the Memo Pad--to do this, after LOAD "C800",8 run it with RUN:REM MEMO instead of just RUN. Now for the binary. It seems that TH-cam almost always, if not always, deletes any post I make that has links, so I'll put them in a reply to this comment. If they disappear, then I will email them to you. Any feedback would be welcome. Make sure that your sound is on so that you can hear the C64 emulate the Atari key-click sound; this is important for that authentic Atari experience. 😉
Yep, sure enough, my comment with the links was deleted. I'll email the binaries directly to you.
Thanks Robin. Now I know my life is a lie, and that an Atari is a faster Commodore 64 than an actual Commodore 64. :( Seriously though, this video was a ton of fun!
You can have the same speed if you use C128's 2 MHz in the border.
If you want (way!) more than the original speed nowadays, just fire up VICE in warp mode.
@@polluks2 But the C128 wasn't around at the time Atari released their 600/800/1200XL machines, nevermind the original 1979 Atari 400/800. So nerrrr! 😉 In hindsight, the C128 was interesting. A weird beast, grossly overcomplicated and neither one thing or the other... but probably a fitting end for their 8 bit range. I'd quite like one myself.
Only at running the C64's BASIC, and not entirely, at that. It can't do a lot of things the C64 can do, and likewise the Atari can do things the C64 can't do. In this case, overall the Atari's processor was slightly faster, which everyone already knew. It doesn't mean the Atari can run the C64's software (except for the most basic BASIC code) at all, let alone better.
This is neat. I am surprised since it was claimed how easy it was that it took this long to get ported over. I am curious to see how far this project will go, and if we will see the reverse where Atari basic and OS is running on the C64.
I don't know whether we'll see the reverse anytime soon, but I'm sure it is doable, as it is much like porting any program, such as a game, from one computer to another of similar capability. It would probably involve more work, though, if the Atari OS and BASIC depend more on the specific hardware of the Atari. The C64's BASIC and OS are barely even aware that they are in a C64. They might as well be in a Commodore PET, where they were ported from originally.
The time has come for Turbo Macro Pro XL. xD
The reason the Atari isn't as fast as the clock speed would suggest is because video DMA steals cycles from the CPU. On the C64, the cpu is run at roughly half the speed all the time and interlaced with video DMA cycles. This means the Atari runs faster during blanking periods and the C64 does not.
if you want to run a program on the atari and you dont need screen for something turn the screen off poke 559,0
screendma=peek(559):poke 559,0: do cpu intensive no screen needed program:poke 559,screendma
or direct address if the emulator does not update the shadow register 559=54272 approx 30% increase in speed
21:49: Could you have pre-written the POKE 54273,2 line below the READY before hitting return on the POKE 54273,0, and would this have allowed you to just press return again after turning cursor blinking off?
I wounder if you could still use DMA for the sprite poke 53277 poke with 3 for sprite player and sprite missiles or 2 for just players 1 for just missiles then you can reserve some memory and put some real data in for the sprites
Sure, this is just a simple, partial port of an 8-bit BASIC environment. The computer is still physically and logically an Atari in every way and a C64 in none. It's like porting a game from one computer to another.
In Jim Ignatoski's voice....uuugghh...you guys are freaking me out!
When comparing the scrolling speed, it’s also worth noting the Atari text mode was only 24 rows tall while the c64 text mode is 25 rows tall. The Atari has one less row to scroll.
I thought about that so I counted the on screen lines ... 25 lines! So, even though the normal Atari modes were 24 rows tall (192 scanlines), the video chip is actually capable of displaying 25 lines instead (200 scanlines).
@@IsaacKuo wow, learning something new about the Atari even after 40 years 😊
Depends on how the scroll is implemented. If the video memory space if fixed and the cpu has to redraw all the characters on the screen then yes an extra line would impact performance. If the video memory space is adjustable then there's virtually no performance difference with an extra-line.
@@zbdot73 The scroll is implemented by copying bytes to shift them 40 or 80 bytes (depending on whether it's scrolled one or two lines), and filling the rest with spaces.
I still have an 800XL lying around somewhere..
What a beautiful machine.
Oh hey, it's Nick's thing!
Very interesting stuff
The Atari 64 "emulator" is highly accurate when it comes to benchmarks, actually. Let me give you the real numbers at the hardware level for comparison. I'll stick with NTSC because I know that best.
The C64's clock runs at 1,022,727 Hz, but loses some of these to DMA for "bad lines" (text data and/or dual color maps) and sprites. Each display frame has 65 cycles/line * 263 lines/frame = 17,095 total cycles/frame. Bad lines subtract 40 cycles/line * 25 lines/frame = 1000 DMA cycles/frame (in all five graphics modes) from the total. And two bytes (out of four, including the pointer) for each sprite comes from DMA, so for 8 sprites being displayed (a "typical" scenario), that's 8 * 2 * 21 = 336 DMA cycles/frame. The main color map at $D800 has dedicated data lines running to the VIC-II and 1024 nybbles of SRAM on a separate 2114 chip, so there is no DMA penalty. Without sprites, the C64 effectively runs at 16095/17095 * 1022727 = 962,901 cycles/second or Hz, and with 8 sprites active, it effectively runs at 942,799 Hz.
Meanwhile, the Atari 8-bit has 114 cycles/line * 262 lines/frame = 29,868 cycles/frame. And its per-frame DMA (in the main text mode at normal screen width) consists of 40 * 24 (equivalent to C64 "bad lines") + 40 * 24 * 8 (glyph data for every character) + 9 * (262 - 24) + 24 (DRAM refresh cycles: 9 per normal scanline and 1 per "bad line") + 32 (display list) = 960 + 7680 + 2166 + 32 = 10,838 DMA cycles/frame. Player-missile graphics add 5 * 240 = 1200 DMA cycles/frame. So with player-missile graphics the Atari 8-bit effectively runs at 19030/29868 * 1789773 = 1,140,330 Hz, and with player-missile graphics it effectively runs at 1,068,423 Hz.
So without sprites/PMGs the Atari 8-bit runs at 1140330/962901 = 18.4265% faster than the C64, and with sprites/PMGs it runs 1068423/942799 = 13.3246% faster than the C64. The measured figure that you got is subject to various factors, but it's pretty close to what the precise cycle-by-cycle comparison indicates (and, truth be told, even the method I just used isn't exact because the Atari 8-bit, in halting the CPU more frequently, loses a not-completely-predictable number of cycles more than the C64 does per frame, so it's actually a little slower in comparison to the C64 than the figures I've given seem to indicate). The bottom line is that the CPU of the Atari 8-bit is always faster, but not by nearly as much as the vast majority of people think, and *depending on the type of game* , the C64's sprites, which are faster than player-missile graphics in several ways, can more than make up for the difference.
By the way, if we count every cycle, we can find out how much faster the Atari's CPU is when the two computers' displays are blanked. The C64 loses no cycles to DMA, so it runs at 1,022,727 Hz. The Atari, however, still loses 9 cycles per line for DRAM refresh, which comes to 9 * 262 = 2358 cycles/frame, so it effectively runs at 27510/29868 * 1789773 = 1,648,475 Hz. So with their displays blanked, the Atari 8-bit runs 1648475/1022727 = 61.1843% faster than the C64. Many say it's 79% or even "twice" for short, but it's actually a touch over 61%, even with the displays blanked.
By the way again, the Apple II runs at 1,020,484 Hz, or ever so slightly slower than the C64 with its display off and the VIC-20 (with its display on), and a bit faster than the C64 with its display on. Why the slight discrepancy? That's a highly technical subject (that I can now explain completely after a bunch of research) that involves the NTSC standard and Steve Wozniak saving a few transistors, as usual. 😉
🔬 🔬 🔬
Very interesting vieo. I also tried to compare Atari 800XL vs Commodore 64 but from fully different perspective.
This video doesn't really say much on that subject, except that the Atari's CPU is faster, as we all already knew, but not nearly as much faster as most people had thought--more like 17% versus the 79% many probably had in mind. There was one example in which the Atari was 20+% faster, but that's only because it doesn't have to manipulate the color map, since it doesn't have one. 17% is pretty accurate and very close to the theoretical advantage the Atari has over the C64 when all relevant technical factors are considered. This only applies to CPU speed.
Wow, interesting! Now let's see all those less-familiar pokes on the real C64, and all of the same pokes in native 800! And any other comparisons between the hybrid and native 800 that you think would be interesting. And then come full circle by trying those other things on the real C64 as well.
I guess "BASICally" 😁 all comparisons between the 3 systems you think would be cool ("This is what happens if you try this Atari-based poke on the real C64, and this is what it the same looks like in regular A800 mode," etc.).
Try some of the SID pokes in all 3 modes and then try some of the 800's versions of sound pokes on all 3, etc.
Now someone has to make a SID cartridge for the Atari. Also, which BASIC interpreter would you say is better? Atari BASIC or Commodore BASIC 2.0?
I haven't really had enough experience with Atari BASIC to say for sure; from what I can tell, Atari BASIC has some nice features over C= BASIC, but C= BASIC is overall more robust/stable, and is faster.
Can it run "Green Delicious" ?
it's gonna be AWESOME!
Ha ha, yes, recursive emulation, let's do it!
@@stevethepocket Will it work ?
Can everyone enlighten me what the „Commodore Security“ badge is all about? Im dying here out of curiosity!
It's a reproduction of a real badge worn by Commodore security employees at their headquarters. The repro was made by my friend DLH who runs the excellent archives at bombjack.org. I just think it's really cool (and a bit funny) so I put it in shot a lot.
@@8_Bit Thank you, Robin. Now i may sleep well and dont die stupid😂
Just for kicks, here's 10 PRINT running in native Atari BASIC; it's a few bytes shorter than the C64 version! th-cam.com/video/PpNTY0Hoy7c/w-d-xo.html
Can you do one on the CBM-Transfer tool?
Oh, the performance difference should be bigger in PAL-land. PAL had a lot more scanlines, but the PAL versions of the C64 and Atari 8-bits didn't take advantage of it. So, there were simply a lot more scanlines where the video chip wasn't strealing any cycles.
So, the performance edge of the PAL Atari 8-bit over the PAL C64 should be better.
Yes, it'd be interesting to see some benchmarks for PAL hardware as it should be faster. By the way, I recently learned that the Atari still needs to steal cycles for DRAM refresh even when there's no video being displayed so even when in vblank or with the video disabled, you can never get all the cycles available to the CPU.
@@8_Bit Correct, 9 cycles are stolen for DRAM refresh on each scanline, of which there are 262 with NTSC and 312 with PAL per frame. One exception is that there is only 1 refresh cycle stolen on lines during which text screen data are fetched (analogous to "bad lines" on the C64). These refresh DMA cycles must happen regardless of any settings, or else obviously data would be lost. Each scanline has 114 cycles, by the way.
That 1200xl should have 256 colors... that should be a GTIA, not a CTIA. The GTIA was upgraded to do 256 colors using that bit.
Ah, thanks for the correction. For some reason I thought the GTIA didn't show up until the 600XL/800XL, but upon further reading it seems even some original 400/800 shipped with the GTIA!
@@8_Bit Yeah the GTIA did show up in the originals. Apparently the GTIA was supposed to be the original chip but to get it to market they released the CTIA...so rumor has it.
@@8_Bit Yes most 400/800's came with GTIA. Any machine made from November 1981 and afterwards has GTIA. CTIA machines are uncommon.
@@gamedoutgamer They're even more uncommon because the GTIA was offered as an upgrade, and apparently a lot of people did that, given the apparent scarcity of 400/800s with CTIA chips.
The 256-color palette only applies to graphics mode 9 (BASIC), though, doesn't it? That's the bitmap mode with 80x192 resolution (1 hue of 16 per row and 16 luminances). All other modes have the same 16 hues but only 8 luminances for a palette of 128 colors.
If you find this difficult to believe, then try it for yourself. In the BASIC editor, PEEK(709) will return a value of 202, which is the color of the text. If you POKE709,203 the color will not change at all. But if you POKE709,204 the text will brighten. This means that the least significant bit of the luminance field is still ignored, even with the GTIA chip, and there are indeed 8 luminance levels in this mode rather than 16. This is actually true of all display modes with the sole exception of GRAPHICS 9.
This is really cool.
Weird but awesome!
This is fun!
So cool!
It would be wrong to imply that the Atari halts 22% of the time. It simply hands off the graphics processing to the Antic, which also runs at 1.79Mhz while halting the CPU, so there is no real penalty other than the time required to pass the display list.
If I said "the Atari halts" I surely meant the Atari's CPU halts; all my comments were in the context of explaining how the Atari's CPU throughput is not 1.75 or 2.00 times the speed of the C64's, despite what a simple comparison of 1.79 MHz vs. 1.02 MHz might imply.
Actually, the memory also runs at 1.79 MHz, so every fetch halts the CPU, not just for the display list. Overall, the Atari's system is more efficient than the C64's because the Atari's CPU gets to run at its full 1.79 MHz speed when ANTIC RAM fetches aren't happening, while the C64's CPU is always stuck at 1.02 MHz regardless of what the VIC-II is doing. The difference is not 1.79/1.02 = 75%, but more like 17-20%, as demonstrated in this video.
@@rbrtck Yes, the ANTIC is granted DMA control while graphics is being drawn. This alone is not additional overhead though, because the task is just being handed off from the 6502. The ANTIC is not really a "graphics chip" but a second processor similar in some ways to a 6502. The Atari equivalent to the VIC is the GTIA. Atari could have chosen to get rid of the ANTIC and connect the GTIA directly to the address bus as was done with the VIC on the C64, but the Atari was built for smooth graphics and gameplay. Because normal system tasks can't interrupt the Antic, we get fine scrolling at 60Hz with no jitter, for example, even under heavy 6502 load. For 100% CPU usage at 1.79Mhz for heavy calculations on the Atari, just disable automatic DMA control to the ANTIC.
@@redleader7988 It's additional overhead because the CPU is halted whenever the ANTIC needs to read from RAM. While it's nice that the CPU doesn't have to do all of the work that the Atari VCS/2600's CPU does, it still has to share the same RAM cycles with the ANTIC. The good thing is that the CPU can run at its full 1.79 MHz speed whenever the ANTIC is not fetching from RAM. For comparison, the C64's RAM runs at 2 MHz, so the VIC-II chip rarely has to steal additional cycles, but although they usually don't contend for RAM, working on different halves of the RAM cycles, when the VIC-II is idle, it can't let the CPU have the extra cycles because the CPU runs at only 1 MHz no matter what. The 2 MHz RAM is just sitting there half-used for much of the time. The overall result is that when the ANTIC is fetching data to display a typical screen, the Atari's CPU runs about 17% faster than the C64's CPU. It would be 79% faster if it were not for the ANTIC stealing so many cycles with DMA, but it has to, and this has a significant effect because 17% is a lot less than 79%. There must be a reason for this, right?
You're wrong about how the graphics chips compare, too, I'm afraid. The GTIA is much more like the TIA in the 2600 console than the VIC-II. Just look at the GTIA's registers in the Atari's I/O map--it's all about colors and player-missile horizontal positions, and no graphics modes (aside from selecting color interpretation). It can't do anything without some kind of processor to drive it. In the case of the 2600, because there was no memory for a frame buffer anyway, the CPU "raced the beam" to feed the TIA data (from ROM or calculations) in a carefully timed manner in order to generate a display. The difference in the Atari 8-bit computers is that a separate coprocessor called the ANTIC drives the GTIA instead, feeding it data from various sources so that the CPU and its software do not have to worry (for the most part) about the real-time aspects of generating displays. Contrary to what you said/implied, the VIC-II does the same thing--it is a complete graphics processor in a single-chip package that generates displays generally independently of the CPU (which only has to worry about manipulating registers and frame buffers). It has its own "ANTIC" and "GTIA" equivalents on a single chip. If Atari could have fit the ANTIC and GTIA on the same chip, then they probably would have. In fact, look up the CGIA and KERI chips. Both were attempts by Atari to fit everything on a single chip, in order to reduce cost, but for whatever reasons, this never happened (maybe it was too late in the game and they had so many ANTIC and GTIA chips in stock anyway--Atari was infamous for manufacturing too many of everything).
Now, a lot of people consider the ANTIC a super-special coprocessor because like a CPU it has its own sort of machine code, but that's only sort of true. Its "opcodes" are just a sequential list of the modes that it can operate in that describes the type of display that the software wants to be shown. The only things it can do on its own, aside from simply feeding data to the GTIA for display generation, are changing modes according to the display list, optionally changing the memory addresses from which to fetch data from RAM, and optionally interrupting the CPU (a DLI) to do everything else after a row of graphics is displayed. That's not real fancy for a coprocessor, and it doesn't even change the color registers, which is done a lot on Atari computers--the CPU has to do that and everything else the ANTIC doesn't do. While it's true that the VIC-II does even less, it is still a graphics coprocessor that automatically does all of the DMA RAM fetches it needs in order to generate a display, as well as interrupt the CPU on specific scanlines (a raster interrupt) to take action as needed for split screens, sprite multiplexing, changing color registers, and such. The hardware arrangement is different, but what these chips do is not so different. Their overall capabilities are pretty similar, as well. The Atari obviously has an advantage in colors, while the C64 has an advantage in resolution (everything from sprite pixels and horizontal positioning to smooth scrolling is done in half-clock increments rather than full color clocks like on the Atari in most cases), and so on.
The GTIA does less than what you believe--it is not a standalone graphics solution at all. The VIC-II does more than what you believe--it does everything needed to generate displays with many different modes, all by itself. The ANTIC is not what you believe. It actually does more than what you believe to generate displays on the Atari because the GTIA does much less--it is the ANTIC that creates all of the graphics modes, while all the GTIA does is apply colors and creates signals on a line-by-line basis. The ANTIC is in full control here and does most of the work. On the other hand, it is less of a "coprocessor" than you believe, and not in any way comparable to a CPU. It has display lists, which is a nice architecture, but it's not like a second CPU attached to a full-fledged graphics chip. It is the front half of a graphics processor while the GTIA is the back half. Together they form a very capable graphics processor that was too hard to fit on one chip, while the VIC-II is a full and also very capable graphics processor that does fit on a single chip. Without the display list and a lot of kind of useless modes the ANTIC has (such as the giant blocky character modes and other modes that are hardly ever used), Commodore managed to get everything on one chip, and it still works great. They even saved enough silicon to include an improved sprite system. The ANTIC + GTIA are also great, but one can't work without the other.
@@rbrtck Only the CPU would be halted. It wouldn't be doing anything anyway. That's the point I keep making. I wasn't making any of those outlandish claims about the ANTIC being a Super Co-Processer. It does do all of the graphics processing to the point that the CPU can be turned off for a while, so it's adequate for the task of being a graphics co-processor, in addition to the tacked-on low level timing for the GTIA. Graphics processing on the Atari does take priority over the CPU cycles, but I believe that's what Atari intended in their grand vision, this being their next gen games system. I got the functionality of the GTIA and relationship to the ANTIC way wrong though, as you pointed out.
Great video. I don't know much about the world of Atari's, but this was really fun video. Matt Hefernan has made a video about BASIC speed between three 8-Bit machines, too. The Commodore C64, the ZX Spectrum and Commander X16 in Part 1 and in an other video he brought new contenders: ZX Spechrum Next, the Amstrad CPC 464, the Apple ][, the Atari 800, and the BBC Micro. This were now an opportunity to test the Atari 64. :-)
Trying to poke into colormap must be strange 🤔
22:53: Only eight pixels wide? But isn't this 16 pixels wide, or are the sprite pixels a lower resolution than the text?
I believe there's another register that controls how many screen pixels wide each sprite pixel is. It probably defaults to double-wide?
The player (Atari sprite) pixels are twice as wide as those of the 40-column, single-color-character text modes (ANTIC modes 2 and 3, GRAPHIC 0 in BASIC), so I suppose you could say that they are at a lower resolution (another way of looking at it): 160 pixels across a normal screen instead of 320. This makes players, by default, two characters wide.
For comparison, C64 sprite pixels are about half as wide (and the same width as the 40-column, single-color-character text modes). So despite having 24 pixels across versus 8 horizontally, a C64 sprite is only 50% wider than an Atari player across the screen. In addition, players can be doubled or quadrupled in width, while C64 sprites can be doubled at the most. This means that at their widest, Atari players can be 33% wider than C64 sprites despite having one-third the resolution.
@@8_Bit No, in single-width mode, a player spans two 40-column characters, so it starts out with pixels that are twice as wide in comparison, and can be doubled or quadrupled in width from there. This can easily be seen in games that use players, and is why characters in Atari games (certain types of games, of course) aren't as well defined as in some corresponding C64 games, such as _Mail Order Monsters_ (C64 sprites have the same pixel width as players when in multicolor mode, though, so this isn't always true).
What I've long wondered, by the way, is why all of this information isn't as easily accessible as it is for many other systems. Reference texts really should spell this stuff out, but few, if any, do.
You could have a done a POKE 559,0 before the speed tests. And POKE 559,34 afterwards 😉
Games run a lot faster with DMA turned off, too. And they're more challenging. ;)
Atari vs C64 clock speeds & differences:
I believe that some of your explanations miss the mark. The timer is linked in both original Atari OS and in C64 kernal to the VBLANK which will be exactly same on both machines (if both are same TV standart PAL or NTSC). In other words the speed of the processor can not influence the timer test. The other tests ... all good.
The C64 KERNAL timer isn't tied to vblank, it's instead part of the regular system IRQ that's triggered by the CIA at about 60 Hz on both NTSC and PAL C64s. I didn't want to assume that the Atari 64's TI$ was accurate, so that's why I did the stopwatch test with it for a full minute and saw that it seemed very accurate, before using TI$ to benchmark C64 vs. Atari 64. I was making sure TI$ was working consistently between C64 and Atari 64, and then was able to calculate the 1.17 difference in the BASIC benchmarks between the two machines.
Wow!
Could the Atari then also emulate the Apple II since it would not have to worry about much color, no sprites, and no sound chip?
Well, for text mode it could work. The bizarre byte layout of the screen should be doable, or at least it could be copied over to the real screen from a fake screen. But the way the Apple had 7 pixels per byte rather than 8 pixels per byte ... no practical way to deal with that.
It can't really emulate the C64, though--only the most basic of BASIC programs that don't use characters of more than one color, which in the real C64 world tend to be very rare. Even if we're not talking about emulation of BASIC but just trying to do the same things in any way possible, there are things the C64 can do that the Atari 8-bits cannot, and vice versa.
@@IsaacKuo And if we include graphics, since Apple's BASIC has graphics commands, it couldn't be done completely because of the way the Apple II handles color. Using the hi-res mode with artifacting would partially work, if translated, but there is no practical way to get the two additional colors (on each scanline) on the Atari.
@@rbrtck There were plenty of C64 BASIC programs which didn't use color, just not many commercial games (outside Infocom text adventures). Are these programs of much interest to retro enthusiasts? Okay, not really.
@@rbrtck I was just thinking of monochrome emulation, but there is a trick the Atari could use to emulate Apple ][ color. You could switch between two fields, where one field is black/purple/green/white and the other field is black/orange/blue/white. Each field, only the screen pixels corresponding to the displayed palette are shown. However, performance is going to be abysmal due to bit shifting during conversion from 7 pixels per byte to 8 pixels per byte.
Can you do the reverse? Make a C64 become an Atari? :3
Yes, but for various technical reasons, it would probably take a lot more work. This has nothing to do with which computer is supposedly more capable, it's just how their characteristics happen to align.
Well….if that way is possible…can the reverse be done too ?
The main issue I see is the floating point ROM at $d800.$dfff, on the Commodore 64 the $d000..$dfff area needs to be switched between I/O and RAM, while on Atari the I/O at $d000.$d7fff is always visible. You would need to rewrite Atari BASIC to switch $dxxxx between I/O and RAM and Atari machine code programs that try to call routines in the floating point ROM won't work.
@@danielmantione It might be easier and better to relocate this 2K floating point ROM to $C800-$CFFF, which should be available if the 800's OS ROM is used instead of the 800XL's. Then the C64 I/O map can be left banked in (as well as the color map, although that might not be used after initialization) to avoid all of the switching and extra code that would require. Running machine code doesn't matter much, because the idea of _Atari 64_ is really to port the other computer's BASIC and default environment. Most machine code would run anyway, unless it calls the floating point routines, and of course the I/O will always be different.
Yes, it would most definitely be possible, although it would be a lot more work for reasons that have nothing to do with how the computers compare technologically.
Pure sacrilege. Isn’t anything sacred anymore.
I was looking for a link to get the executable. Did I miss it?
From the main Atari 64 github page there's a "Releases" link on the right, and that page has the atari64.xex executable. I'm surprised there isn't a tab at the top of the page for it; that might be why I didn't realize there was an executable at first either. github.com/unbibium/atari64/releases
@@8_Bit
Thanks! That took me right to it.
Keep up the great work!
So instead of coloring the characters, you are redefining them. That's a pretty cool trick in its own right, but then what you did here would not work on a regular C64.
Maybe I don't understand what you're saying, but C64 definitely allows redefining characters. You can't modify the ROM, but you can copy the character set from ROM to RAM and edit them in that way.
@@casaderobison2718 What I was saying is that what redefines the colors on C64 redefines the chars on A64, as the video clearly shows. If you use the A64 poke instead of the standard C64 pokes to redefine the chars, however, you'll redefine the colors instead, and thus the "modified" program would not work so you should still use the standard poke to redefine the chars anyway.
@@kespeth2 I think I see what you're saying. Yes, the memory map is going to remain a stumbling block to things like this. Frankly, I think it is amazing it is able to do as much as it does.
@@kespeth2 Got it, sorry for the confusion. So many contexts to try to keep track of. :)
@@casaderobison2718 That's right, and you don't even need to copy the ROMs at all--the VIC-II chip doesn't care whether the character set definitions are in ROM or RAM, so just load yours from disk or DATA statements in BASIC or whatever, and point the VIC-II to its address. Copying from ROM first is just done because maybe only a few character definitions will be redefined. I'm sure you know this, but for public consumption, especially by Atari fans who might not be very familiar with the C64, I thought I'd mention it.
There is another little difference, by the way. The Atari's character set has 128 characters addressed by 7-bit character codes. When the 8th bit (the highest one, with a value of 128) of the character code is set, the character is displayed in reverse/inverse coloring (foreground color switches with background color). The exact same thing seems to happen on the C64 despite the fact that its character set has 256 characters, but that is only because its built-in character set definitions (in ROM) have 128 inversed definitions following the first 128 definitions. Unlike on the Atari, they do not have to be reversed--they can be anything you want, which means that the C64's character set really has 256 characters that are addressed by full 8-bit character codes.
I'm not thrilled about a hand or a pair of hands that pretends to be a complete human.
Commodore 64's Basic is actually MS Basic.
Yes, it's a customized Microsoft BASIC. MS provided the original version used on the Commodore PET, which included some customizations such as the SYS command, and then Commodore programmers modified it further for later PET revisions, and then for the VIC-20, and then a little more for the C-64. The integrated full-screen editor is also a Commodore feature.
Imitation is the sincerest form of flattery.
If you've ever watched the likes of "Spitting Image", you will know that imitation can be anything BUT flattering! 😁
@@another3997 A caricature is not a 1:1 imitation.
I wonder if the Atari is copying color memory like the C64 is when scrolling.
Edit: Then he brings the point up.
You could redefine the colors (including graphics mode and player/missiles objects) for each display line on Atari tho (not scrolling but fixed per line). Copperbar demos are usually just shifting background colors for each display line up and down.
@@TheDemoTube Problem is, that would change the color of the entire scan line. The C-64 can have any arbitrary color in each 8x8 character cell, potentially putting all 16 colors on each scanline without even using raster-synchronized color changing tricks, and this can be done in the (otherwise decidedly "not good") basic 2.0 that the system shipped with, using just the PRINT command.
Also, I don't think that he touched on this, but the C-64 also has video fetch issues that freeze the processor. The C-64's memory is actually double-clocked at 1Mhz (DDR access long before most people heard of DDR memory) and the VIC-II automatically gets every other slot. But every 8 scan lines, the processor gets locked out for 40 cycles for retrieving SCREEN RAM. Also, any sprites that are active on a given scan line each stall the processor for 2 additional cycles.
In an absolute worst case scenario (where sprites are being multiplexed and it is always displaying 8 on each scanline), the processor is locked out for (((40{screen ram cycles}+(2{sprite data cycles}*8{sprites active}*8{scanlines of sprite per character row})))*25{character rows}*60{frames per second}) = 252,000/1,022,725 = 24.6% of the available clock cycles, effectively operating at 770khz. Without the sprites, it ends up being 962khz effective frequency. Typically sprites aren't multiplexed, and with only 8 sprites on screen it ends up effectively being ((40*25)+(8*2*21)))*60 = 80160 cycles, or 942khz.
@@glenndoiron9317 You are correct that on the C64 the VIC-II does halt the CPU for DMA, but it's nowhere near as much as on the Atari 8-bit, since *all* of the graphics data is fetched through DMA on the latter. The hit the C64's CPU takes with 8 sprites active (and in any graphics mode) is 1336 cycles/frame out of 17095 cycles/frame total, while in the default text mode (GRAPHICS 0), the hit the Atari's CPU takes with player-missile graphics active is 12038 cycles/frame out of 29868 cycles/frame total. So the C64's CPU loses about 8% of its cycles to graphics DMA, while the Atari's CPU loses about 40% of its cycles, which is obviously a big difference. Per-frame, in this scenario, the C64's CPU has 15759 cycles available compared to 17830 cycles for the Atari's CPU, making the Atari's CPU only about 13% faster (while their frame rates are slightly different at 59.82611 Hz for the C64 and 59.92275 Hz for the Atari, this does not make much of a difference in the final result, which still has the Atari's CPU about 13% faster).
Hey Robin, when you go to a meetup, you should print a tshirt that has your hands on it, so people know who you are. Or just your right hand that has your "hi" hand motion on it.
Band members should not wear their own merch.
Atari case design 17% percent prettier too. Just sayin.
I do like the 1200XL in particular.
Yeah the XLs have a very nice design. Some of the older ones (like the original 400/800), not so much.
Prettier than the bread bin, but than the C? Nah, the C64 C is the most streamlined computer to date.
@@LordRenegrade The XLs are nice, but I actually prefer the designs of 400 and 800. :)
@@NuntiusLegis The original C128 might actually be a bit sleeker, although this is offset by its relative bulk.
what sorcery is this
It's a 6502 program running on a different 6502 computer. Essentially, it was ported to the Atari. The Atari still can't run any C64 software except for the simplest of BASIC programs. No sorcery involved.
Atari users be like... "See we can run C64 stuff too!"... 9 dislikes, must be jealous Spectrum ZX owners. 🤣
I reckon the dislikes are from Apple users... after spending that much money on a system that didn't play games very well. 😁Speccy owners knew their system wasn't the best, but they had the cheapest system and the cheapest games library. 😉 My ZX81 was replaced by an Atari, but I nearly got a Spectrum. Atari had some great games, but never had the sheer number of games they did.
Atari users must not be very bright, then. j/k ;) Running the C64's BASIC is one thing, and it can't even change character colors in BASIC like on a real C64. Nearly everything else about these computers' hardware is different, so no.
Blasphemy! :)
I actually consider this to be a virus. Atari BASIC and its cousins (BASIC XE, Turbo BASIC XL) are far more powerful with their commands to support sound and graphics directly whereas Commodore Basic requires a ton of POKEs to get anything exciting to happen. And the handling of strings in Atari BASIC is so powerful. At least the border is black on the venerable Atari. I don't know how Commodore users put up with that border.
I downloaded a copy of the Atari 64 (more of a joke program and less of a virus) to see if it really lets me POKE 764,255 to clear the keyboard debounce or PRINT CHR$(125) to clear the screen.
I don't have it, but Atari did license and produce a version of Microsoft BASIC for the 8-bits. It loaded from disk last time I knew anything about it.
BASIC XE from Optimized Systems Software even adds support for sprites, among its many new features.
That screen memory poke should not have worked. Screen memory is pointed to with 88,89. And the author could have saved memory space by using the Atari font in ROM.
This interpreter should not be mapping Commodore 64 POKEs to the Atari hardware.
The Atari 8-bit can turn off its screen to speed it up, and you should try Turbo BASIC XL to really see the speed.
For a short ML bit, POKE it into Page $600 (1536).
That 53272 poke would have been a SETCOLOR. The Atari 8- bit actually has 256 colors. 16 colors * 16 luminances.
You can set up a string in Atari BASIC to contain all Sprite data and set PM BASE to point at it but it has to start on the edge of a page in memory. Then you can use Atari BASIC string manipulation to move it vertically if you want. ;)
The one thing missing it the keypress sound.
Nick should get a copy of Mapping the Atari and something for the Atari OS routines and jump tables.
Clearly Commodore BASIC v2 was not the best BASIC in the world. I don't know anyone, even die hard Commodore fans, that would try to claim otherwise. Though having to peek and poke so much to access the hardware did help one learn more about the underlying hardware and was beneficial when one tried to transition to assembly. But that's just looking for the silver lining.
That being said, memory addresses map to one of two things more or less. Memory or hardware registers. This technique (a simple port of C64 firmware to the Atari) can't do anything about hardware register locations (probably; it is possible to have relocatable registers, but I am not aware of many or any 8-bit machines that did such a thing). When it comes to RAM values though, the utility of those are defined by the firmware of the system. Mapping the Atari would be a useful book (I assume, having not read it) to know where hardware features live. I bet it, or something like it, was used in this very port. Other addresses though would change the instant the firmware changed Atari to Commodore.
As for using the Atari font instead of the Commodore font, what's the fun in that? If you want to make it simulate (as much as is reasonably possible) a different computer, you need the font! :)
@@casaderobison2718 Port Simons' BASIC. ;)
I have never seen any convincing graphics commands in BASICs, those circles and boxes get old soon. The C64 BASIC being that sparse and sleek has the advantage of more address space being available for code and data.
@@NuntiusLegis True, but of course it depends on what you're trying to do with the graphic commands. High grade gaming, no. Business graphics, yes. Of course, the latter isn't going to get much traction today, but they were valuable 40 or so years ago.
There were alternative BASIC interpreters available for the C64. It wasn't limited to what was built in (and the 400/800 technically didn't have any BASIC built in).
Can't wait until neat year for April 1st. LOL
I would argue that the Atari at ~1.7MHz is approximating twice as fast as the C64's ~1.0MHz.
Consider the 700KHz difference *and* that the VIC-II isn't stealing cycles on the Atari! Consider also how much faster the Atari's disk drive is...
EDIT: didn't consider the video mode cycles, it's probably just down to the disk drive not being several hours of waiting on an Atari
Also, it looks like those screen colors are closer to the C64 viewed over RF.
As a C64 and Apple II user you have now encouraged me to buy an Atari 8 bit computer.
The default setup of the 1541 interface ended up at 1/8th of the intended speed (somewhat easily modified) and I'm uncertain if this was inherited from the VIC-20.
Nope. The VIC-II only sometimes steals cycles from the CPU. It usually doesn't have to because the RAM is twice as fast, and the VIC-II and CPU share it equally without interference. As long as a screen is visible, generally the VIC-II will only steal about 6% of the CPU's cycles, and with 8 sprites visible, the total is about 9%. Meanwhile, the Atari's ANTIC chip steals everything it needs from the CPU when anything is being displayed (as you acknowledged in your edit). Even with just a BASIC text screen being displayed, that 1.79 MHz gets chopped down to about 1.15 MHz. It's still faster than the C64, but not by all that much.
As for the drives, there are and were many simple options available that boosted C64-1541 speed well beyond that of the stock Atari-1050. Even purely software-based fastloaders (commonly built into commercial software) could be very fast, comparable to Apple II drive speed. Think of it as a DOS upgrade. The Atari could also be sped up, and many users did that, but even then, it still wasn't faster than the sped-up C64. All of these 5 1/4" floppy drives used similar formats and mechanisms, so none were really faster than the others, in terms of potential. What matters is the protocols used.
@@josephkanowitz6875 The story is kind of sad, lame, and complicated. :) First let's start with the Apple II, as an example for illustration. It had expansion slots from the start, so a floppy drive card could be created to interface it with floppy drives, and the way Steve Wozniak implemented all of this was very simple, efficient, and elegant (as usual for him). Contrary to popular belief, drive speed (concerning the kind of drives we're talking about) has nothing much to do with serial versus parallel cables and data transfer. The disks stored data in a serial manner regardless, and that's how they were read, even on the Apple II. Most of the wires in the parallel ribbon cables were for the computer's CPU to be able to control every aspect of the very basic, "dumb" Apple Disk II drive mechanisms. The raw GCR data was read bit-by-bit, translated into the actual data, and stored in memory by the CPU in the Apple II computer itself, all in real time. That's why the Apple II is so fast with its floppy drives, in comparison to other 8-bit computers--from the Atari/Commodore point of view, the Apple II computer pretty much *is* the drive, and the drive mechanism is part of it.
The reason Commodore instead used "intelligent" drives with separate interfaces and various protocols to transfer data, in the first place, was that the PET wasn't designed with expansion slots, and therefore would not have a floppy disk controller. For future expansion, an IEEE-488 port was provided, and it did have parallel transfer at up to one megabyte per second, which was way faster than necessary for floppy drives. Commodore also had to put another 6502 CPU in the drives to do the reading and translation, hence the "intelligent" drives that were like limited computers in and of themselves. The drive's CPU was internally interfaced with the mechanism like the Apple II computer's CPU, and then it had to transfer data to the main computer after reading it. Commodore also decided that most of the low-level DOS would be on the drive itself, and that the computer would communicate at a higher level within its own ROM. Like Atari (who must have had their own reasons for doing things in a similar way), they were, perhaps accidentally, ahead of their time, and sometimes that comes with a price.
This setup worked fine for the PET, and even allowed it to do cool and pragmatic things like share a single drive or set of drives between a set of PET computers, which you can't do on an Apple II (at least with floppies). But when it came time to make a drive for the VIC-20, the 1540, they decided to go with a still somewhat innovative but much cheaper 6-pin serial port. It was *much* slower than the IEEE-488 standard, but it was fast enough for most peripherals, and the floppy drive speed was intended to be quite high by using the 6522 VIA I/O chip's hardware serial interface. Unfortunately, it turned out that the 6522 had an unexpected bug in its serial transfer function, and there wasn't enough time to fix it, so they defaulted to a very slow but utterly reliable protocol. It didn't matter anyway because the VIC-20 only had so much memory to load into, and Commodore fully expected the vast majority of users to use a Datasette tape drive instead, for cost reasons.
When the C64 was being designed, along with the 1541 drive (compatible with both the C64 and VIC-20), both were slated to use the 6526 CIA I/O chip, which had perfectly functional and very fast hardware serial transfer. Unfortunately, however, the new ROM code for the fast serial transfer (to be known as "burst mode") had not been written yet, and at the same time, the C64 main board had to be redesigned slightly to accommodate a couple of additional mounting holes. It turned out that the lines (copper traces on the board) that enabled the fast serial transfer ran right through those hole locations, and looking through the current ROM code, the idiots at the factory didn't see anything using those lines, so they were removed from the design, which was easier than rerouting them or moving the holes. When the C64's designers found out, it was too late, as about 250000+ defective C64 main boards had already been manufactured. The designers were livid! They wanted to give up on the C64 and quit their jobs right there--they didn't, but that's how they felt. Management decided that since not many people were expected to buy the 1541 anyway, because the C64 was, after all, a home computer rather than a business computer, the fast serial transfer would officially be deleted, and the C64 would use the very slow transfer protocol of the VIC-20 (modified to work with the VIC-II's DMA) because that was the safe route and, as usual, there was no time left to do better. The C64 kept its 6526 chips because it made use of its other features, while the 1541, which was still being designed, was given the bugged 6522 because it was slightly cheaper and the 1541 no longer needed fast hardware serial transfer. :(
Commodore management, of course, was dead wrong about the 1541, which sold like hotcakes (especially in the US and Canada) despite the slow transfer protocol and its somewhat high cost. Solutions to the problem would soon arrive, however, because the 1541 was programmable by the computer through the serial port, so much faster protocols could be developed, tested (now that there was some time for that), and uploaded to the drive. Cartridges and ROMs would also be available to greatly speed up drive data transfer when using software that didn't have its own such system (or pirated software that often had their fastloaders removed for technical reasons). And Commodore's "burst mode" would finally be implemented on the C128 (but only in 128 mode with the 1571 drive), which of course doesn't help the C64. Not that the C64 needed help, once the user forked over a little cash to buy a fastloader cartridge or, even better, a JiffyDOS ROM set (one for the C64 and one for each 1541).
This is impressive work, but fairly pointless because the Atari XL computers are excellent, ancestors of the Amiga computers! What's really needed is Atari BASIC and OS on the C64. The only problem some people might find is the lack of LEFT$, MID$, and RIGHT$ commands, but this is because string handling is totally different in Atari BASIC. There was a listing in a Compute! book to implement Atari BASIC graphics commands on the C64. I hope someone can reverse this Atari 64 software to make the Catari or C64XL!
Other problems: Slower floating point arithmetic, no string arrays, no integer variables, no bit-wise operators, line editor instead of full screen editor.
It's also pointless because the Atari still can't run any C64 software, except for the most simple, vanilla BASIC programs. But nonetheless it's interesting.
Going the other way isn't needed, either, because there are better BASICs available for the C64 (in cartridge format), and the C64 can't run non-BASIC Atari software any more than the Atari can run non-BASIC C64 software. It would be kind of fun to "return the favor", though, and this did cross my mind as a project I might take on. The problem, however, is that I think it would be a lot harder (and much more work) to port the Atari OS and BASIC to run on the C64. The reason has nothing to do with which computer is supposedly more capable, but simply how some of their characteristics happen to align by chance. The main problem is that the C64 can support the Atari's extra 2K of ROM at $D800-$DFFF with RAM, but only by switching out both the color map at those locations, which is no problem, and the memory-mapped I/O at $D000-$D7FF, which is a major problem. Unfortunately, the C64 wasn't designed to switch out one or the other (only both at once or neither), or else porting the Atari OS and BASIC would probably be just as easy as the other way around. The C64 could have had this functionality easily enough, but it wasn't considered necessary, so it wasn't done, and that's that.
Again, it is not a matter of relative capability. The Atari (800XL being the minimum variant required for _Atari 64_ ) can switch out ROM for RAM (in this case, it was used for the C64's character set) at $D800-$DFFF while keeping I/O at $D000-$D7FF because it can't switch out the I/O at all. This 2K of RAM that is physically present on the board cannot be accessed by the CPU at all, which means that the 800XL, for example, is effectively a 62K computer. The C64, on the other hand, not only can access all 64K of RAM, it also has an additional 512 bytes (in the form of 1024 4-bit nybbles of color map RAM), which technically makes it a 64.5K computer. Well, it does lose two bytes at addresses 0 and 1 to provide the port for bank switching, so it's actually 64.5K minus 2 bytes. The Atari can't switch out the I/O bank because that's where the bank-switching port itself is located. Luckily, though, this isn't necessary for the Atari to run the C64 OS and BASIC without much effort, while getting the Atari OS and BASIC to run on the C64 would be more challenging and involve a lot more legwork.
It could certainly be done, just like how any software could be ported to work on either computer, but the probable amount of work that would be required to create a _Commodore 800XL_ isn't worth it. I won't spend weeks or months slaving over something that will end up being a quaint little curiosity--there are simply too many demands on my time. That's too bad, but maybe it's important enough to another programmer for them to give it a try.
EDIT: After typing all that, I guess I'll give it some more investigation and thought, as it seems that this 2K ROM area at $D800-$DFFF only contains the floating point math functions. If I could relocate it (and change all of the calls and/or hooks in BASIC), then maybe it wouldn't be so hard to get everything to run on the C64 after all.
How about the Commodore 800 or C800? 😁 After revisiting and investigating this matter further a few days ago, I figured that it actually might be a bit easier than I had initially thought. A few days later, I now have a working prototype of an Atari 800 (non-XL) "emulator" for the C64. It's actually more of an emulator than the Atari64 (which is more of a port), since one of my goals was to make the fewest changes possible to the ROM code, as well as do the least possible amount of work (because I'm busy enough as it is). A few small patches in the OS ROM were necessary (7 that range from 1-3 bytes each), but otherwise I didn't port the Atari ROMs to work on the C64--they actually "believe" that they are running on an Atari 800. Atari BASIC's (Rev. C, of course) code is entirely untouched.
That's because the C64 can switch out its I/O map address space for RAM, which I then managed the values of from a "master" interrupt routine that works outside of the control of the OS. This routine emulates the essential functions of the POKEY, ANTIC, GTIA, and PIA chips, storing the values they provide to the OS in this RAM (at the appropriate addresses, of course). The OS reads these values as though they were provided by the chips, and is none the wiser. 😄 The master interrupt routine also reads the values stored there by the OS, and acts on them when necessary. Atari interrupts are all emulated in this system, as well, and happen when the C800 wants them to happen.
Of course, this "emulation" is very limited, similar to the Atari64 in this way (i.e. really only supports BASIC, albeit not the graphics commands since Atari BASIC hasn't been modified for the C64 in any way), and unfortunately the method I used incurs a small overhead, slowing the emulation down a bit, but on the plus side, I can claim that the C800 actually is kind of an emulator rather than a port, which is something that can't be done on the stock Atari 800XL in exactly the same way (it would take a huge number of ROM patches) because it can't switch out its 2K I/O map address space for RAM (therefore it can only access 62K of its 64K of RAM, while the C64 can access all 64K plus an additional 0.5K of color/attribute memory).
I will finalize the prototype this weekend and put a working binary on a file server, probably in a .d64 file. All that remains to be done, at least at this point, is to get the click for keyboard input sounding right (important for an authentic Atari experience!) and implement a convenient way to select between BASIC (which on the 800 requires the BASIC cartridge) and the Memo Pad (the 800's default built-in application). I've managed to make the SID sound a lot like the 800's click, but it's slightly off, so instead I might try to use digital output based on the same click routine in the Atari OS. This will require another patch that consists of a small subroutine (different from all of the others), but I have to get that Atari click sound as accurate as possible. It shouldn't take too long, and if all else fails, the SID sound I made sounds pretty convincing, so I could always use that. Stay tuned for further developments.
@@NuntiusLegis Eh, it's just a stunt anyway, but it kind of annoyed me that it only went one way, so ultimately I decided to return the favor, and now have done so in a different manner that took a lot less work (I think?) yet is a real emulator in some ways, as opposed to a port like the Atari64. The C800 (or Commodore 800) will be coming soon (like in a day or two). It's just a prototype, but I think it is fully, if minimally, functional, and of course more functionality can be added. Stay tuned.
I will probably release the source code at some point, but it's a mess that only I could understand readily, because this project was originally intended as a "quick and dirty" proof of concept that I didn't know would ever work, as designed. It needs serious cleanup, which I plan to do, but for now, I'll finish and release the prototype once I'm happy enough with the keyboard click sound. Read the comment above for more details.
Why? Because you can... 😂