I worked at Atari as a game developer back in the day and it was the most difficult thing I’ve ever done in my life. They didn’t even discuss the hardest part of the job. What to do when you run out of your 4K of rom. You would have to hand optimize the assembler to save a few bytes so you could add a fix.
Yeah, figuring out how to squeeze the last few bytes can be a challenge. For Toyshop Trouble, my solution was to invent an 8K cart that used only a single 74LSxx chip. I'd love to tell you more if you want to PM me.
I recall 4K carts retailed for $5 more than 2K carts in 1979. I forget what Asteroids cost (I think that was the first 8K cart). What all were you involved with at Atari? My published works include Strat-O-Gems, Toyshop Trouble, and the menu screen/music for Stella's Stocking, all of which seem pretty well represented on RUclips. I'd be curious to know what you think of them.
I always remember Mike Singleton (RIP, sadly) talking about how short on memory he was when he wrote "The Lords of Midnight" on the Spectrum--it got to the point where he was re-ordering subroutines in memory so that subroutines could run straight into each other rather than having to waste 3 bytes for a CALL instruction!
"Racing the beam" is a technique I used on an Amiga game circa 1989. I was an employee of a small games company that used Atari STs as their main 16/32-bit machines, so I wrote my first game for them on an Atari ST. The vague plan was to port this towards the end of the project to the Amiga. The ST and Amiga store their screen bitmaps in completely different ways, and the ST code was pretty optimised for the ST bitmap architecture, so porting to the Amiga could have turned out to be onerous. My corner cutting (i,e time saving) approach was to run the ST code on the Amiga, generating the ST screen frames in an off-screen buffer, and then transforming this bitmap into a single video line of Amiga "bitmap" on the fly, staying one scan line ahead of the actual screen scan. This sounds a bit insane, until you realise that the Amiga version of the game had to run in 512K, and the ST game similarly already used most of the ST's 512K.. in other words, there was no more available RAM on the Amiga to perform a full bitmap transform; I just didn't have the extra screen of RAM. I guess some elementary technical planning at the start of the project could have foreseen such issues for the ST -> Amiga port, but the company I worked for at the time didn't do planning (full stop). "The good old days" of video games.
This is amazing. I can't believe the difficulty in programming this austere hardware. I was 6 when I got a 2600, and I thought it was the greatest thing ever. I saved a lot of quarters because of it. Thanks for showing this, it brings back a lot of memories. BTW.. I saw the castle for Adventure in there.. a bit of an easter egg. That was my favorite game back then. The "invisible dot" was actually the first real easter egg I'm aware of. I felt like I had discovered something fantastic when my cousin showed me where it was and told me where to bring it lol.
It gets even more fun when you learn that this thing has no interrupts. At all. The TIA allows you to halt the CPU for a pre-determined amount of time, stuff like "wait for the next caline to start", etc. But during that time, the CPU can't do anything else.
You mean the TIA specifically couldn't interrupt the CPU (in the classic run the interrupt handler once interrupt arrives sort of way)? Because you'd need interrupt handling mechanism for user inputs (from joystick buttons or whatever they were called), obviously.
@@EvilSapphireR No, no interrupts at all. The joypad is typically latched by the program once per video frame because it's still too fast for any human to notice.
@@EvilSapphireR Even later consoles don't trigger interrupts for user input. They just read from the controller one or more times each frame. The VCS was synchronized entirely by the RIOT timing chip. The TIA would automatically send an HBLANK signal to the TV every so many cycles, and when it did that it sent a RDY signal to the CPU, so if it was idling after a WSYNC instruction, it would pick up execution again. That's about as close to an interrupt as you got, except for resetting the CPU.
I often wonder what modern hardware could do if it were around long enough for software designers to get behind all its quirks, tricks and non-intended abillities.
So true, i recently found out there's a thing called reverse emulation for the NES, in which a really hacked up code on Raspberry pi resides inside a NES cartridge to mimick a cartridge. A guy managed to get Super Mario Bros on the NES. Yup, that's not a typo. Search "Reverse emulation on the NES" on RUclips.
Oh the elusive raster line interrupt of the VIC... When i was a kid starting with assembler, that one was quite tricky for me since i haven't had any proper documentation. But counting cycles, optimizing code, filling gaps with NOPs, that is something i do remember. 25 years... How things have changed...
6502: the sweetest CPU of all 8-bit era! (Maybe 6309 too!) I love all its addressing modes and its instruction set. Also it served as model for the ARM CPU instruction set. It's lovely when you see ARM assembly code and recognize mnemotecnics like BCS and BEQ.
I wrote a "Breakout" type game on the St back in the 80. There was something about writing in assembler that was so much fun. I still have some code out there on the interwebs for the ST in their "crawlycrypt" archives. Wish I saved all of it, not sure what happened to it. One of the coolest things I wrote was a startup prog for the ST which dialed (yes, with a modem) the Naval observatory in DC and read the date in Julian time. There was at one time (maybe still is?) a line dedicated to just spitting out the current time every second. That time had to be then converted and set to a clock chip bit by bit (the ST didn't have a clock chip, or at least the version I had didn't). It was an aftermarket chip you installed "under" another chip. So the machine would keep time with this clock chip, but once power was cut, it would forget, hence the need to set it on each power up. I had an Atari 800 and learned 6502 as well, but don't recall doing any graphics with it.
I bought my own Atari 2600 VCS back in the 1980s and I have played various games on it ever since. Those programmers did some really amazing work considering the limitations of the system.
True, but I don't know at what point people realized that a cycle-perfect write could work so nicely in "mirror" (as opposed to "copy") mode, and that a game could use the middle 32 pixels with four writes per scan line. Street Racer used four writes/line, but it used "copy" mode so there's a four-pixel gap between the two sides of the screen.
Actually, it is easier to do it in "copy" mode. The timing is off by a color clock (aka "pixel") so that you can't update PF2 at the exact center of the screen. (68 color clocks before the screen, plus 1/2 the screen width of 160, equals 148 color clocks before the center of the screen, which is not divisible by 3). In order to work properly, you need to use the "ball" graphics object (which is the same color as the "playfield") to cover up the seam, or just leave it as it is. The main problem with using "copy" mode is that you probably need to use all 3 playfield registers, which means you need up to 6 reads and writes per line, using at least 36 of your 76 precious cycles just to draw the playfield.
There's a latching stage between the PF registers and the actual PF output, so a write to a PF register in the middle of a PF pixel won't take effect until the start of the next PF pixel. Games like Donkey Kong and Dig Dug which show non-symmetric playfield graphics in the middle 80% of the screen use mirrored mode so as to use four 8-bit PF updates per line rather than four 8-bit updates and two 4-bit updates. Interestingly, because PF1 and PF2 show bits in the opposite order, both halves of the screen show a big-endian byte followed by a little-endian byte. Incidentally, before I saw how other people created 32-pixel non-symmetrical playfields, I had thought the ball was needed to make the timing work, but it actually isn't necessary. I did in one game end up having to use a missile to clean up a playfield pixel at the middle of the screen, but that's because score mode has a circuit that activates the sprite 0 circuit when a playfield pixel is active, and another which activates the sprite 1 circuit when a playfield pixel is active, and the transition between using the two circuits isn't synchronized accurately with the edge of the playfield pixel.
Thank you for that explanation! I had not known that. When I read "2600 101", it sounded like it did not work this way. Now I need to re-write my kernel to take advantage of this wizardry...
People over at the AtariAge forums have created a form of basic that handles the TIA for you. (Called Batari Basic) There's even an IDE nowadays. I managed to build a game for the Atari VCS using these tools and help from people over at the forums, and it was a lot of fun. I really want to do more development eventually. But even with these modern tools it's a challenge, and I have a lot of respect for those back in the day who programmed for this thing. Activision games in particularly very much impress me.
Wait a minute, can you actually program an old Atari to set an old CRT television on fire? I don't watch a lot of Computephile, but I would watch that video. You've got to do that now.
You can do a lot of screwy things to the signal, some of which make the tube emit high-pitched squeals, but a tube that caught fire would've had a lot of other problems besides just a wayward programmer.
There's tales of IBM PC programmers using IBM BASIC on 8088-based machines killing monitors by writing the wrong thing to the wrong part of memory. Seems they somehow ended up getting the CGA hardware to send a malformed signal to the monitor which it couldn't handle.
Even in Windows, the older CRT monitors you could blow up, by wrongly setting the resolution and frequency. Some of the earliest monitors, would break, when rated for 60Hz, and you'd feed it anything higher than 72 or 75Hz. More modern screens have no problems finding, and converting and displaying the right signal on the screen (convert higher frequencies to lower frequencies (like 50 or 60Hz) by dropping frames).
Things definitely got easier when the NES came along. It has a dedicated PPU (Picture Processing Unit). There is an interrupt at the beginning of the vertical blanking interval. Then game program writes to the regions of memory that control what is on the screen Then the PPU sends the image through the video output, until the next vertical blank.
The thing is, the Fairchild Channel F, which predates the 2600, also had a PPU of a sort. It had 2k of video RAM, though it had just 64 bytes(!) of general purpose RAM. You might think the 2600 was the last computer to work like this, but no, it was the ONLY computer to work like this. No one did it before or since.
It's crazy comparing yesterday tech to today. I was thinking of making a adventure game for the Atari 2600, and my first thought was I can't use A* for pathfinding, so you have to simply everything.
Skills that are in a completely different realm than today's average JS front-end developer(just for instance). The overall progress is truly beyond impressive. It tends to bug me if/when they have no conception of how easy we have it now. Everyone should suffer some form of a "punch card boot-camp" weekend imo.
Right. I'm from somewhere in that "middeground" zone I guess. It mostly just had more to do with knowing about the specific hardware/system involved(because you had to) & being forced to write the code as effectively as possible(due to the intrinsic limitations of the time). But like I said the progress has been astonishing, especially in the case of JS(for example). Now, with literally like 10 lines of code you have a solid frame of a full blown "window/app" with all of the bells & whistles(like audio & video etc) that will run on almost every device in the world. However, as a drawback one could say that much of the so called progress comes from the fact that there are layers upon layers of sloppy code all piled up on top of each other. & in the extreme that even if every individual "layer" was implemented as intelligently/efficiently as possible its still a sloppy paradigm. I wouldn't go that far personally. But I do find the history/evolution of technology almost as fascinating as the technology itself.
It took me awhile to figure out he was saying "kudos" at the end. I don't know if that's the standard British pronunciation. To me it sounded like he was saying QDOS.
Man, I was counting cycles and wait-states even with interrupts, going over code line by line, looking them up in my Z80 handbook and figuring out how I could handcraft more optimized sequences to squeeze every bit of performance out of everything; from the memory to CPU, VDP, FD controller, etc ...
It does require some cleverness, but on the flip side the display hardware is controlled so intimately by the processor that the it allows the programmer to make whatever trade-offs are needed in a given situation. In my Strat-O-Gems game which I released in 2005 (but actually wrote display code for a decade earlier(!) most scan lines have six objects which share the same shape but have separate colors. Since the game needs six colored gems per row, but it's okay if they have the same shape, that works out well. If sprites were multiplexed in hardware rather than software, they probably wouldn't offer anything near that level of control.
It's a challenge, but once you understand the system there is a satisfying feeling when you succeed . I am reminded of the days when I first started to understand programming. That urge to make the next greatest gem. Writing some code and finally seeing it work as you imagined it to. Back then however a single person really could make the next great breakthrough game or software on thier own in a reasonable time period. I remember in school when others would finally know enough of code to get the bug. It was a rather fun thing to behold. OK.. enough of this reminiscing of times before a large percentage here were alive.
I have tried it. It is definitely challenging. These days there are tools that take away some of the nightmare, such as Batari Basic. But IMO if you're going to code the 2600, it's 6502 or nothing.
I have recently been learning this very thing. Using an Arcadia Supercharger to load onto the real hardware ( a heavy sixer I rebuilt). It's a hoot. I come from those days of scrimping every last bit to fit everything, so it's not foreign to me, but it is sure different from the excess who cares if its perfectly efficient programming of today.
I had initially thought I would do this on a Tandy 1000 or earlier but then trying to find software to do it that could run on that old of system turned out to be to much of a challenge. No matter, the extra ease of today's computers and software made it something much more likely for me to finish.
I think the original SuperCharger loading was done with an Apple II. The Tandy could have generated the waveforms easily with the proper coding, but I don't think the information needed to do so became public until the Tandy 1000 was obsolete.
Strangely, I find Unreal harder to code with than the 2600 in 6502. Back then, it was all about the game play. Today, it's as much, if not more so, about the visuals. And gamers' expectations are now much higher than they used to be.
Most computers back then had a display memory and were not hard to program games for. The Apple II, and the TRS-80, and the Commodore VIC-20 etc. did not need to do crazy stuff like the Atari 2600 did because they had memory mapped displays. But, the Sinclair ZX-80 and ZX-81 did use the CPU to draw the display, so there were a few like that. :-)
Drawing sprites has also be done in the same scan line routine, meaning, you have to check, whether this is the right scan line to display your player block or not. Since there 3 pixels per CPU cycle and a single instruction takes at least 2 cycles, you are soon out of time and may have passed the right moment. (Displaying multiple things on the same line is, where things tend to become complex.) On the other hand, the piece of code in question is already handling the playfield graphics. So you are probably cheaper off and quicker, while sticking to them. (Remember, there's no notion of a vertical extent on the VCS, therefore there's also no way to just position a sprite anywhere on the screen.)
I'm not sure who else would be interested to see a video on it, but I'd enjoy a video on multiway trees and B-Tree variations like B*-Trees, B+-Trees and such. I say this since you guys have touched on file storage/indexing in some of your videos and I think it could make for an interesting video!
I wonder how the 6502 stack even works on the Atari 2600, because normally the second page of memory holds the stack, memory $0100-$01FF with the SP register indexing within it. But the Atari doesn't even have a single complete page of memory, let alone 2 pages. So the stack would fall outside of RAM. Guessing the 6507 worked differently?
The VCS decodes addresses incompletely, such that the devices mapped in the zero page also show up in page 1. The RAM inside the RIOT chip serves as both variables and stack. This also means the TIA responds to stack accesses too, allowing you, for example, to very quickly enable/disable the missiles and ball (as done in Combat) or to set the horizontal positions of objects in quick succession (this trick allowed the road lines in Pole Position to converge at the horizon).
Ready Player One on your desk!! I hope you're enjoying the book and you should definitely watch the movie. Great videos, love it when y'all talk nerdy to me😉😂
Why do so many people say the Commodore 64 had a 6502 processor? The C64 had the 6510 processor, which is derived from and similar to the 6502 but redesigned so it was able to access 64K of memory. It's the Commodore VIC20 and the PET that had the 6502.
Technically, the 6502 was also able to access 64K of memory. The problem is when you try to stuff 64K of RAM *and* 20K of ROM into a 64K address space. In order to do that, you need bank switching, which they did by adding a general I/O port to the 6510. (You can get the same effect on the VIC-20 by adding another 6522 and some glue logic.)
@@SpearM3064 The 6507 did not have enough address lines to see any more than 8 k. So technically it did not... because the electronic signals were not there. Yeah the instruction set could request it but the hardware could not deliver it.
Man... I'm so interested in how these games were made! I've seen ∞ of these type of videos. Scan line this and sprite that and pixels this and ROM that. I do not understand ANY of it. So frustrating it's painful. I wish this would make as much sense to me as hitting up D major while you're on your way to C# minor from F# minor😭😭
For anyone doubting that you could damage your telly, I can vouch for that - I blew ours up by holding down the game reset switch for too long. I guess lengthy sync pulses were not something early 70s TV designers ever envisioned.
Dave Poo - that was my thought as well. The C64 had 8 hardware sprites. Ingenious use of the raster interrupts could allow more depending on where they were placed on the screen (he correctly stated 8 per line). I forget how many Hardware sprites the Amiga had, though it was a fair few more than 8.
@@Aexomer 8 hardware sprites in 3 colour mode, you could combine 2 sprites together to get 15 colour sprites.. but then you only had 4 sprites at 16 pix wide sprites per scanline.
An interesting feature of the TIA is that they couldn't afford to have proper binary counters, so the players (sprites) were associated with pseudo-random counters instead which cycled exactly once per line. You would wait until the beam was at the horizontal position you wanted and then reset the counter - from then on the player would show up in the same position on each line and the processor could forget it and go do something else. You could select for a few clock cycles to be skipped in the vertical sync and that would move the player slightly to the right or to the left in the next frame. Note that if your player wasn't just a bunch of vertical lines you had to rewrite the bit pattern in the TIA for each line.
Jabre Thornton I remember upgrading my 386 harddrive from 60 Megabytes to 300. I was amazed. Suddenly I didn't have to delete one of my Sierra games to make room for a new one. (They were about 10 megabytes each, enormous in the days before the big CD-Rom games like Myst and The 7th Guest).
On zx spectrum you just placed a byte in certain area of memory and a chip cared for everything else. So it was kind of high level programming back then.
When I started work a mate of mine had a home computer extension for a 2600 with Basic and a tape cassette drive, can't remember what it was called. I seem to remember it looked Atari banded though
To write a vcs game, you need to be well up on 6502 assembly, knowing its intruction set is essential, there is no secondary language i wish it was like ascii art
The first VCS that I had growing up was a 2600. My father's parents had one as well so I almost always brought all my games with me when we came over to visit. I don't remember how many I had, but I had something like a lock box in size to carry them all and that it was pretty full. I do remember having the E.T. game if I remember right, didn't play it much though.
That's what Atari had to do to get the 2600 down to a sufficiently low cost for the North American consumer market back in 1977. Silicon was expensive then, so anything to cut ROM or RAM demands was welcome.
This sounds too retro to be fun. Challenges are fun but these constraints make development more of a mission impossible. What's the best you can hope for? Getting a paddle moving up and down? How much effort does that take? Long hours, days after days getting screens messed up constantly and struggling to find out why? Seeing every instruction spaghetti side effects into your display? That sounds like a programming nightmare.
A small change in gameplay design or graphics would probably need so much of the codebase altering. A game would have to be entirely designed almost before development starts with very little scope for change. Certainly a nightmare.
Atari 2600 is practically raw machine code since Atari 2600 dose not have the CMOS firmware to translate msbasic commands from keyboard or cassette otherwise Atari 2600 would be proto commador which would be amazing for homebrew.
The most common one was a move instruction to the entire hardware register set, so it was quite powerful. I think you could even kick the Blitter chip with it.
In one sense, it is very easy as there are a limited number of instructions. In most senses, though, it's very much more difficult as you have to work out how to achieve what you want using those very low level instructions. Higher level languages give you lots of shortcuts that you can use, assembler (of any sort, but especially for older chips) have a very limited vocabulary.
ct92404 No frame buffer - RAM was too expensive. The design was intended for very simple ‘Pong’ style games. Atari worked on a replacement video game console to do much more than the VCS, but was bought by Warner who changed the brief for the project: and it became the Atari 800 and 400 ‘home computers’. Atari was early ‘Silicon Valley’ lunacy. Very interesting history of the early days, before the suits knew anything about the business and writing code become commodified.
One thing that makes sense after seeing this is the appearance of black lines on the left and right sdes of many 2600 games. Those lines were there to give time to the CPU to run program code and maintain synch.
The lines are actually caused by sprite repositioning. There are just two sprites, but positioning them is rather tricky (in order to keep the hardware cheap): You have to tell the graphics chip where to position a sprite by exact timing. Basically, you just say, "now", and the chip will reset an offset counter. However, the CPU is slower than the graphics chip and to compensate this, fine adjustments may be applied by movement registers, which introduce another offset. In short, whenever those movements are applied, the graphics chip "blanks out" for 8 pixels at the start of the line. The tell-tale sign that sprites have been repositioned to be reused somewhere else (below) on the screen.
It had to be in order to keep its cost down for consumers back in 1977. That cost advantage persisted through its entire life cycle and allowed it to stay in production until 1992.
![Gunna - HIM ALL ALONG [Official Visualizer]](http://i.ytimg.com/vi/HiCxoDeo0hc/mqdefault.jpg)
Masochist. I will always have huge respect for the programmers of the early computer games. So sleek, so efficient, so elegant, so clever!
I worked at Atari as a game developer back in the day and it was the most difficult thing I’ve ever done in my life. They didn’t even discuss the hardest part of the job. What to do when you run out of your 4K of rom. You would have to hand optimize the assembler to save a few bytes so you could add a fix.
Also, you needed to know the number of clock cycles for each instruction in your kernel. I think it was 72 clock cycles, before horizontal blanking.
Yeah, figuring out how to squeeze the last few bytes can be a challenge. For Toyshop Trouble, my solution was to invent an 8K cart that used only a single 74LSxx chip. I'd love to tell you more if you want to PM me.
Flat Finger Tuning hi, congrats on writing a 2600 game. There were 8k carts that used bank switching. Management was against it due to added cost.
I recall 4K carts retailed for $5 more than 2K carts in 1979. I forget what Asteroids cost (I think that was the first 8K cart). What all were you involved with at Atari? My published works include Strat-O-Gems, Toyshop Trouble, and the menu screen/music for Stella's Stocking, all of which seem pretty well represented on RUclips. I'd be curious to know what you think of them.
I always remember Mike Singleton (RIP, sadly) talking about how short on memory he was when he wrote "The Lords of Midnight" on the Spectrum--it got to the point where he was re-ordering subroutines in memory so that subroutines could run straight into each other rather than having to waste 3 bytes for a CALL instruction!
"Racing the beam" is a technique I used on an Amiga game circa 1989. I was an employee of a small games company that used Atari STs as their main 16/32-bit machines, so I wrote my first game for them on an Atari ST. The vague plan was to port this towards the end of the project to the Amiga. The ST and Amiga store their screen bitmaps in completely different ways, and the ST code was pretty optimised for the ST bitmap architecture, so porting to the Amiga could have turned out to be onerous. My corner cutting (i,e time saving) approach was to run the ST code on the Amiga, generating the ST screen frames in an off-screen buffer, and then transforming this bitmap into a single video line of Amiga "bitmap" on the fly, staying one scan line ahead of the actual screen scan. This sounds a bit insane, until you realise that the Amiga version of the game had to run in 512K, and the ST game similarly already used most of the ST's 512K.. in other words, there was no more available RAM on the Amiga to perform a full bitmap transform; I just didn't have the extra screen of RAM. I guess some elementary technical planning at the start of the project could have foreseen such issues for the ST -> Amiga port, but the company I worked for at the time didn't do planning (full stop). "The good old days" of video games.
Really makes me appreciate the geniuses who could make entertaining games with such programming and hardware limitations.
This is amazing. I can't believe the difficulty in programming this austere hardware. I was 6 when I got a 2600, and I thought it was the greatest thing ever. I saved a lot of quarters because of it. Thanks for showing this, it brings back a lot of memories. BTW.. I saw the castle for Adventure in there.. a bit of an easter egg. That was my favorite game back then. The "invisible dot" was actually the first real easter egg I'm aware of. I felt like I had discovered something fantastic when my cousin showed me where it was and told me where to bring it lol.
The programmer wrote his name in the dark maze and that was the Adventure "easter egg"....or so I've heard.
As someone who is both a Computerphile fan and currently writing my first 2600 game, I can't tell you how excited I was that this video exists.
How'd it go?
It gets even more fun when you learn that this thing has no interrupts. At all. The TIA allows you to halt the CPU for a pre-determined amount of time, stuff like "wait for the next caline to start", etc. But during that time, the CPU can't do anything else.
You mean the TIA specifically couldn't interrupt the CPU (in the classic run the interrupt handler once interrupt arrives sort of way)? Because you'd need interrupt handling mechanism for user inputs (from joystick buttons or whatever they were called), obviously.
@@EvilSapphireR No, no interrupts at all. The joypad is typically latched by the program once per video frame because it's still too fast for any human to notice.
@@EvilSapphireR Even later consoles don't trigger interrupts for user input. They just read from the controller one or more times each frame. The VCS was synchronized entirely by the RIOT timing chip. The TIA would automatically send an HBLANK signal to the TV every so many cycles, and when it did that it sent a RDY signal to the CPU, so if it was idling after a WSYNC instruction, it would pick up execution again. That's about as close to an interrupt as you got, except for resetting the CPU.
I often wonder what modern hardware could do if it were around long enough for software designers to get behind all its quirks, tricks and non-intended abillities.
So true, i recently found out there's a thing called reverse emulation for the NES, in which a really hacked up code on Raspberry pi resides inside a NES cartridge to mimick a cartridge.
A guy managed to get Super Mario Bros on the NES. Yup, that's not a typo.
Search "Reverse emulation on the NES" on RUclips.
Guess we'll find out in 30 years or so
Oh the elusive raster line interrupt of the VIC... When i was a kid starting with assembler, that one was quite tricky for me since i haven't had any proper documentation.
But counting cycles, optimizing code, filling gaps with NOPs, that is something i do remember.
25 years...
How things have changed...
6502: the sweetest CPU of all 8-bit era! (Maybe 6309 too!) I love all its addressing modes and its instruction set. Also it served as model for the ARM CPU instruction set. It's lovely when you see ARM assembly code and recognize mnemotecnics like BCS and BEQ.
I wrote a "Breakout" type game on the St back in the 80. There was something about writing in assembler that was so much fun. I still have some code out there on the interwebs for the ST in their "crawlycrypt" archives. Wish I saved all of it, not sure what happened to it.
One of the coolest things I wrote was a startup prog for the ST which dialed (yes, with a modem) the Naval observatory in DC and read the date in Julian time. There was at one time (maybe still is?) a line dedicated to just spitting out the current time every second. That time had to be then converted and set to a clock chip bit by bit (the ST didn't have a clock chip, or at least the version I had didn't). It was an aftermarket chip you installed "under" another chip. So the machine would keep time with this clock chip, but once power was cut, it would forget, hence the need to set it on each power up.
I had an Atari 800 and learned 6502 as well, but don't recall doing any graphics with it.
I bought my own Atari 2600 VCS back in the 1980s and I have played various games on it ever since. Those programmers did some really amazing work considering the limitations of the system.
Changing the playfield in the middle of a scanline isn't just a clever trick; it's one of the oldest. It's how they displayed the score in Combat.
True, but I don't know at what point people realized that a cycle-perfect write could work so nicely in "mirror" (as opposed to "copy") mode, and that a game could use the middle 32 pixels with four writes per scan line. Street Racer used four writes/line, but it used "copy" mode so there's a four-pixel gap between the two sides of the screen.
Actually, it is easier to do it in "copy" mode. The timing is off by a color clock (aka "pixel") so that you can't update PF2 at the exact center of the screen. (68 color clocks before the screen, plus 1/2 the screen width of 160, equals 148 color clocks before the center of the screen, which is not divisible by 3). In order to work properly, you need to use the "ball" graphics object (which is the same color as the "playfield") to cover up the seam, or just leave it as it is.
The main problem with using "copy" mode is that you probably need to use all 3 playfield registers, which means you need up to 6 reads and writes per line, using at least 36 of your 76 precious cycles just to draw the playfield.
There's a latching stage between the PF registers and the actual PF output, so a write to a PF register in the middle of a PF pixel won't take effect until the start of the next PF pixel. Games like Donkey Kong and Dig Dug which show non-symmetric playfield graphics in the middle 80% of the screen use mirrored mode so as to use four 8-bit PF updates per line rather than four 8-bit updates and two 4-bit updates. Interestingly, because PF1 and PF2 show bits in the opposite order, both halves of the screen show a big-endian byte followed by a little-endian byte.
Incidentally, before I saw how other people created 32-pixel non-symmetrical playfields, I had thought the ball was needed to make the timing work, but it actually isn't necessary. I did in one game end up having to use a missile to clean up a playfield pixel at the middle of the screen, but that's because score mode has a circuit that activates the sprite 0 circuit when a playfield pixel is active, and another which activates the sprite 1 circuit when a playfield pixel is active, and the transition between using the two circuits isn't synchronized accurately with the edge of the playfield pixel.
Thank you for that explanation! I had not known that. When I read "2600 101", it sounded like it did not work this way. Now I need to re-write my kernel to take advantage of this wizardry...
I don't know which is funnier, that he shows /that diagram/ and says "it's not that complicated a machine", or that one look and I agree with him
People over at the AtariAge forums have created a form of basic that handles the TIA for you. (Called Batari Basic) There's even an IDE nowadays. I managed to build a game for the Atari VCS using these tools and help from people over at the forums, and it was a lot of fun. I really want to do more development eventually. But even with these modern tools it's a challenge, and I have a lot of respect for those back in the day who programmed for this thing. Activision games in particularly very much impress me.
Wait a minute, can you actually program an old Atari to set an old CRT television on fire? I don't watch a lot of Computephile, but I would watch that video. You've got to do that now.
You can do a lot of screwy things to the signal, some of which make the tube emit high-pitched squeals, but a tube that caught fire would've had a lot of other problems besides just a wayward programmer.
Just insert opcode HCF
There's tales of IBM PC programmers using IBM BASIC on 8088-based machines killing monitors by writing the wrong thing to the wrong part of memory. Seems they somehow ended up getting the CGA hardware to send a malformed signal to the monitor which it couldn't handle.
Roxor128 anything you send to the CRT controller was quite loose for CGA. You could easily send it impossible data rates, which killed the CRT
Even in Windows, the older CRT monitors you could blow up, by wrongly setting the resolution and frequency.
Some of the earliest monitors, would break, when rated for 60Hz, and you'd feed it anything higher than 72 or 75Hz.
More modern screens have no problems finding, and converting and displaying the right signal on the screen (convert higher frequencies to lower frequencies (like 50 or 60Hz) by dropping frames).
Things definitely got easier when the NES came along. It has a dedicated PPU (Picture Processing Unit). There is an interrupt at the beginning of the vertical blanking interval. Then game program writes to the regions of memory that control what is on the screen Then the PPU sends the image through the video output, until the next vertical blank.
The thing is, the Fairchild Channel F, which predates the 2600, also had a PPU of a sort. It had 2k of video RAM, though it had just 64 bytes(!) of general purpose RAM. You might think the 2600 was the last computer to work like this, but no, it was the ONLY computer to work like this. No one did it before or since.
It's crazy comparing yesterday tech to today. I was thinking of making a adventure game for the Atari 2600, and my first thought was I can't use A* for pathfinding, so you have to simply everything.
I was hoping to make Grand Theft Atari...but now, I realize I would be way in over my head without educating myself further.
Skills that are in a completely different realm than today's average JS front-end developer(just for instance). The overall progress is truly beyond impressive. It tends to bug me if/when they have no conception of how easy we have it now. Everyone should suffer some form of a "punch card boot-camp" weekend imo.
Seeing stuff like this makes my head spin, I doubt I'd be able to be a programmer back in those days xD
Right. I'm from somewhere in that "middeground" zone I guess. It mostly just had more to do with knowing about the specific hardware/system involved(because you had to) & being forced to write the code as effectively as possible(due to the intrinsic limitations of the time). But like I said the progress has been astonishing, especially in the case of JS(for example). Now, with literally like 10 lines of code you have a solid frame of a full blown "window/app" with all of the bells & whistles(like audio & video etc) that will run on almost every device in the world. However, as a drawback one could say that much of the so called progress comes from the fact that there are layers upon layers of sloppy code all piled up on top of each other. & in the extreme that even if every individual "layer" was implemented as intelligently/efficiently as possible its still a sloppy paradigm. I wouldn't go that far personally. But I do find the history/evolution of technology almost as fascinating as the technology itself.
Back then, people were struggling with the hardware, which made subduing it much, much more satisfying.
Funny, my 16 year old son, just found my old Atari 2600 this past weekend, he was fascinated. :o
Your son is a man of culture. How he is 19. :-)
"Abuse the balls or the missile"
It took me awhile to figure out he was saying "kudos" at the end. I don't know if that's the standard British pronunciation. To me it sounded like he was saying QDOS.
Jay Miner was a quiet genius who does not get enough credit.
David Crane designed alot of great games for the Atari 2600. Pitfall was my favorite.
Nicely informative video. And a big thumbs up for the Amiga 1000 on the desk in the background! Loved that machine.
Man, I was counting cycles and wait-states even with interrupts, going over code line by line, looking them up in my Z80 handbook and figuring out how I could handcraft more optimized sequences to squeeze every bit of performance out of everything; from the memory to CPU, VDP, FD controller, etc ...
Yikes that sounds like a nightmare to code for
It is! Had to make some simple programs for it on my computer architecture class and it was a fun but painful experience
It does require some cleverness, but on the flip side the display hardware is controlled so intimately by the processor that the it allows the programmer to make whatever trade-offs are needed in a given situation. In my Strat-O-Gems game which I released in 2005 (but actually wrote display code for a decade earlier(!) most scan lines have six objects which share the same shape but have separate colors. Since the game needs six colored gems per row, but it's okay if they have the same shape, that works out well. If sprites were multiplexed in hardware rather than software, they probably wouldn't offer anything near that level of control.
Welcome to demoscene
It's a challenge, but once you understand the system there is a satisfying feeling when you succeed . I am reminded of the days when I first started to understand programming. That urge to make the next greatest gem. Writing some code and finally seeing it work as you imagined it to. Back then however a single person really could make the next great breakthrough game or software on thier own in a reasonable time period. I remember in school when others would finally know enough of code to get the bug. It was a rather fun thing to behold. OK.. enough of this reminiscing of times before a large percentage here were alive.
I have tried it. It is definitely challenging. These days there are tools that take away some of the nightmare, such as Batari Basic. But IMO if you're going to code the 2600, it's 6502 or nothing.
So there were 4k games on the atari :D
There are 4k demoscene productions these days, too. Yep, still cramming cool stuff into 4KB of disk, even when we've got terabytes available.
Although most '4k' demos for Windows, aren't really 4k anymore.
They make use of vast libraries of Directx, for displaying code.
lol, i get it.
Early carts were 2K!
Some game carts were 8k. Atari didn't like paying extra for the bigger chip! One of many barriers that the Activision programmers broke...
I have recently been learning this very thing. Using an Arcadia Supercharger to load onto the real hardware ( a heavy sixer I rebuilt). It's a hoot. I come from those days of scrimping every last bit to fit everything, so it's not foreign to me, but it is sure different from the excess who cares if its perfectly efficient programming of today.
I had initially thought I would do this on a Tandy 1000 or earlier but then trying to find software to do it that could run on that old of system turned out to be to much of a challenge. No matter, the extra ease of today's computers and software made it something much more likely for me to finish.
I think the original SuperCharger loading was done with an Apple II. The Tandy could have generated the waveforms easily with the proper coding, but I don't think the information needed to do so became public until the Tandy 1000 was obsolete.
Every time I watch things like this- I then go and look at footage of the Super Mario, Sonic and Mega Man 2600 ports and say to myself, "HOW?"
Bloody hell. I'll actually have to try this myself.
It was crazy how they did games before. Nowadays it's more and more high level (look at Unreal Engine aso..)
aso = a shitty object?
Strangely, I find Unreal harder to code with than the 2600 in 6502. Back then, it was all about the game play. Today, it's as much, if not more so, about the visuals. And gamers' expectations are now much higher than they used to be.
Most computers back then had a display memory and were not hard to program games for. The Apple II, and the TRS-80, and the Commodore VIC-20 etc. did not need to do crazy stuff like the Atari 2600 did because they had memory mapped displays. But, the Sinclair ZX-80 and ZX-81 did use the CPU to draw the display, so there were a few like that. :-)
Makes me appreciate Tunnel Runner a little more.
Wouldn't it be easier to use the playfield to draw "" then just position a cyan player block on the right side to make a ""?
Drawing sprites has also be done in the same scan line routine, meaning, you have to check, whether this is the right scan line to display your player block or not. Since there 3 pixels per CPU cycle and a single instruction takes at least 2 cycles, you are soon out of time and may have passed the right moment. (Displaying multiple things on the same line is, where things tend to become complex.) On the other hand, the piece of code in question is already handling the playfield graphics. So you are probably cheaper off and quicker, while sticking to them.
(Remember, there's no notion of a vertical extent on the VCS, therefore there's also no way to just position a sprite anywhere on the screen.)
I would watch an hour-long video of Dr Bagley saying "thanks to the wonders of the Internet"
I'm not sure who else would be interested to see a video on it, but I'd enjoy a video on multiway trees and B-Tree variations like B*-Trees, B+-Trees and such. I say this since you guys have touched on file storage/indexing in some of your videos and I think it could make for an interesting video!
I wonder how the 6502 stack even works on the Atari 2600, because normally the second page of memory holds the stack, memory $0100-$01FF with the SP register indexing within it. But the Atari doesn't even have a single complete page of memory, let alone 2 pages. So the stack would fall outside of RAM. Guessing the 6507 worked differently?
The VCS decodes addresses incompletely, such that the devices mapped in the zero page also show up in page 1. The RAM inside the RIOT chip serves as both variables and stack. This also means the TIA responds to stack accesses too, allowing you, for example, to very quickly enable/disable the missiles and ball (as done in Combat) or to set the horizontal positions of objects in quick succession (this trick allowed the road lines in Pole Position to converge at the horizon).
Ready Player One on your desk!! I hope you're enjoying the book and you should definitely watch the movie. Great videos, love it when y'all talk nerdy to me😉😂
Why do so many people say the Commodore 64 had a 6502 processor? The C64 had the 6510 processor, which is derived from and similar to the 6502 but redesigned so it was able to access 64K of memory. It's the Commodore VIC20 and the PET that had the 6502.
Technically, the 6502 was also able to access 64K of memory. The problem is when you try to stuff 64K of RAM *and* 20K of ROM into a 64K address space. In order to do that, you need bank switching, which they did by adding a general I/O port to the 6510. (You can get the same effect on the VIC-20 by adding another 6522 and some glue logic.)
Strictly speaking the 6510 can't access 64K, since one or two of the memory-locations (I don't remember) is used for the IO-port
LueLou ... Not right. The z80 was an 8080 clone with some extra features.
Hahaha! How precise observation you did!
@@SpearM3064 The 6507 did not have enough address lines to see any more than 8 k. So technically it did not... because the electronic signals were not there. Yeah the instruction set could request it but the hardware could not deliver it.
Man... I'm so interested in how these games were made! I've seen ∞ of these type of videos. Scan line this and sprite that and pixels this and ROM that. I do not understand ANY of it. So frustrating it's painful. I wish this would make as much sense to me as hitting up D major while you're on your way to C# minor from F# minor😭😭
For anyone doubting that you could damage your telly, I can vouch for that - I blew ours up by holding down the game reset switch for too long. I guess lengthy sync pulses were not something early 70s TV designers ever envisioned.
14:28 - I think he meant to say C64 (not Amiga) for the 8 hardware sprites.
Dave Poo - that was my thought as well. The C64 had 8 hardware sprites. Ingenious use of the raster interrupts could allow more depending on where they were placed on the screen (he correctly stated 8 per line). I forget how many Hardware sprites the Amiga had, though it was a fair few more than 8.
Annoyingly, no. The Amiga has only 8 hardware sprites.
@@Aexomer 8 hardware sprites in 3 colour mode, you could combine 2 sprites together to get 15 colour sprites.. but then you only had 4 sprites at 16 pix wide sprites per scanline.
Keep up the great content!!!
I had never seen Visual Studio Code until this video and I am liking it so far! I use sublime too but VSC looks super modern.
Of all the retro hardware in the background I think my fave is the Tomy Tutor toy computer on the left-hand side :)
"What would it actually be like to write a VCS game? I wish I'd never started, now."
Wow, short video!
The 6507 not having an interrupt input makes the programming all the more difficult.
It does, there are just no pins connected to it. :-)
You're not really much worse off without it since you have to update the picture every line anyway.
I really like that shirt, but the texture resolution is a little low...
Wonderful!! ... Astounding!!... Delightful!!
An interesting feature of the TIA is that they couldn't afford to have proper binary counters, so the players (sprites) were associated with pseudo-random counters instead which cycled exactly once per line. You would wait until the beam was at the horizontal position you wanted and then reset the counter - from then on the player would show up in the same position on each line and the processor could forget it and go do something else. You could select for a few clock cycles to be skipped in the vertical sync and that would move the player slightly to the right or to the left in the next frame. Note that if your player wasn't just a bunch of vertical lines you had to rewrite the bit pattern in the TIA for each line.
Did a part 2 not get made? I couldn't find it on the channel.
Wow and I thought my old 386DX machine was limited! This is so cool though.
Jabre Thornton I remember upgrading my 386 harddrive from 60 Megabytes to 300. I was amazed. Suddenly I didn't have to delete one of my Sierra games to make room for a new one. (They were about 10 megabytes each, enormous in the days before the big CD-Rom games like Myst and The 7th Guest).
On zx spectrum you just placed a byte in certain area of memory and a chip cared for everything else. So it was kind of high level programming back then.
That's insane... in comparison my BBC Micro was the height of luxury.
I really want to do something like this myself but I don’t know where to go for a clear guide or tutelage
Much like a lot of graphics (especially multicolor stuff) on the Spectrum. Me likey.
2 years later and no follow up video...?
When I started work a mate of mine had a home computer extension for a 2600 with Basic and a tape cassette drive, can't remember what it was called. I seem to remember it looked Atari banded though
Apple II and Amiga 1000 in the background there ;D
I remember using the doubling the number of sprites trick on the C64 when I was a kid, eight at the top of the screen and eight at the bottom I think.
To write a vcs game, you need to be well up on 6502 assembly, knowing its intruction set is essential, there is no secondary language i wish it was like ascii art
The first VCS that I had growing up was a 2600. My father's parents had one as well so I almost always brought all my games with me when we came over to visit. I don't remember how many I had, but I had something like a lock box in size to carry them all and that it was pretty full. I do remember having the E.T. game if I remember right, didn't play it much though.
The 2600 is the VCS.
I bet Sethbling could do this as well. You should invite Sethbling to make a video.
GamerZone Wasn't he the one to make a 2600 emulator in Minecraft?
bsharpmajorscale yup
My genius brother said this level of coding was genius level.
Assembly is the language. An assembler is what assembles that into executable code. There is no compiler.
Can we do some high level programming concepts ? Its been a while
could you completely mirror the logo and then use the playfield graphics to write over the blank part of the C with the background colour?
You should use Stella emulator for cross development pipeline instead of Mame
I feel bad for that food getting stale in the background.
Did you ever get it to work? Cant find the video
Did this video ever get a follow-up. If it did, I can't find it...
Do you want to learn how people coded games for the Atari 2600 while learning computer architecture? Enrol now at @t.
So grateful the NES has enough VRAM to draw a whole screen. Can't imagine refreshing VRAM each scanline. Yikes
That's what Atari had to do to get the 2600 down to a sufficiently low cost for the North American consumer market back in 1977. Silicon was expensive then, so anything to cut ROM or RAM demands was welcome.
This sounds too retro to be fun. Challenges are fun but these constraints make development more of a mission impossible. What's the best you can hope for? Getting a paddle moving up and down? How much effort does that take? Long hours, days after days getting screens messed up constantly and struggling to find out why? Seeing every instruction spaghetti side effects into your display? That sounds like a programming nightmare.
A small change in gameplay design or graphics would probably need so much of the codebase altering. A game would have to be entirely designed almost before development starts with very little scope for change. Certainly a nightmare.
Let’s talk more about this TV catching on fire thing.
Atari 2600 is practically raw machine code since Atari 2600 dose not have the CMOS firmware to translate msbasic commands from keyboard or cassette otherwise Atari 2600 would be proto commador which would be amazing for homebrew.
The copper chip on the Amiga was ace, but only 3 instructions. :)
The most common one was a move instruction to the entire hardware register set, so it was quite powerful. I think you could even kick the Blitter chip with it.
Hello sir I am from Nepal where there no facility of coding plz help me
Nice video.
ps:| I would go nuts of those glare Apple screens lol:P
Is 6502 Assembly Language easier to learn compared to Languages such as python, javascript or C
In one sense, it is very easy as there are a limited number of instructions. In most senses, though, it's very much more difficult as you have to work out how to achieve what you want using those very low level instructions. Higher level languages give you lots of shortcuts that you can use, assembler (of any sort, but especially for older chips) have a very limited vocabulary.
13:52 Q-DOS? I don't remember that operating system. Is that what they're gonna use for quantum computers?
He's saying "kudos" (that'll teach me to google before checking ;-)
Quick & Dirty Operating System. The original DOS before Microsoft bought it.
Quantum computers will use everything at the same time.
@@jajwarehouse1 And once MS bought it it because Disgusting Operating System.
Retro Game Mechanics Explained has a much more detailed explanation for the more technically-minded.
The guy who had to program E.T. in such a short time with all these barriers...
They tried..
Does anybody know what emulator he was using?
128 bytes. Luxury.
So cool
Programming and then doesn't show a single line of code. :/
7:19
Mladen Mijatov this is not a tutorial it is just for entertainment
An IKEA desk! Yeah!
can you flip the mirror? ya know? so it flips it horizontally instead of vertically? then the whole logo would be easy.
This sounds brutal . . .
Damn, you even had to program the screen raster?! Yikes.
ct92404
No frame buffer - RAM was too expensive. The design was intended for very simple ‘Pong’ style games. Atari worked on a replacement video game console to do much more than the VCS, but was bought by Warner who changed the brief for the project: and it became the Atari 800 and 400 ‘home computers’.
Atari was early ‘Silicon Valley’ lunacy. Very interesting history of the early days, before the suits knew anything about the business and writing code become commodified.
It sounds like the 2600 was really a video card that could run games.
Or a computer that could run a video card.
Ready player one on the desk.
in what program he wrotes assembly?
Visual Studio Code
One thing that makes sense after seeing this is the appearance of black lines on the left and right sdes of many 2600 games. Those lines were there to give time to the CPU to run program code and maintain synch.
The lines are actually caused by sprite repositioning. There are just two sprites, but positioning them is rather tricky (in order to keep the hardware cheap): You have to tell the graphics chip where to position a sprite by exact timing. Basically, you just say, "now", and the chip will reset an offset counter. However, the CPU is slower than the graphics chip and to compensate this, fine adjustments may be applied by movement registers, which introduce another offset.
In short, whenever those movements are applied, the graphics chip "blanks out" for 8 pixels at the start of the line. The tell-tale sign that sprites have been repositioned to be reused somewhere else (below) on the screen.
I had no idea the 2600 was so primitive.
It had to be in order to keep its cost down for consumers back in 1977. That cost advantage persisted through its entire life cycle and allowed it to stay in production until 1992.
I wish I was as clever as this guy
0:14 Ah, the notorious “«n» -1” loop count for DBRA on the 68000 family! Did nobody know how to write the loop correctly?
One Atari 2600 game = 4k
One Mac 64x64 icon = 5k
Two foil wrapped food items in the background. To share, or not to share?
Brett Breet does he look like he shares?