Who would have thought that 40 years after it’s introduction, I would be ENJOYING watching a type-in BASIC program being explained. Thanks for this. Keep it up!
Well, the basic loader just loads in the machine code where the real magic happens. I remember back then typing in long data statements wondering what the heck do they actually do. heh
I was on Compunet (A UK C64 multi-user BBS) back when this sprite in the border trick was discovered, and the knowlege of how to do is spread rapidly around the demo community on there. At the time it was an amazing trick, our jaws hit the floor when we saw it for the first time. Of course games started using the technique soon afterwards.
@@csabasanta5696 Unfortunately, no. It was decades ago, and memories fade unfortunately. I just remember demos using this trick and being amazed it was possible. A friend of mine who was a better coder than I worked out how to do it and wrote a nice sprites in the border scrolling message routine for me.
Credit goes to Radwar from Germany, while the discovery of the side-border opening is still open to dispute by Dutch 1001 Crew and Danish infamous coder Sodan. Expanded side-border sprites are credited to Dutch crew The Judges, in their demo series Think Twice.
@@ProBloggerWorld - Side border expansion is amazing but really difficult due to timing issues and the relatively slow CPU of the C64. Nevertheless, it's possible with some restrictions.
Very well explained. I love that we really don't know who figured this out but they must have had a blast when they did. And imagine working out that the pattern shown comes from $3FFF. It's all very machine specific knowledge that is important to preserve somehow.
@@lonewretch at the time there was a lot of debate about who 'discovered' it, especially on the fledgling demo scene and Compunet. We had Tony Crowther making claims that he discovered it (and published it in a demo as Ratt with music by Ben), but I think it originally came from 1001 Crew (Joost Honig) and then we all ripped off 'their' code (including Tony Crowther). I ripped it off too in a very early demo of my own , with some Hubbard music and a scroller to go with it. For quite a few people my demo was the first time they saw 'border sprites' and thought I'd discovered it. As a young teenager I didn't do anything to dispell this falsehood (althought I did own up to ripping the code from Ratt's demo in the accompanying scroller.)
@@lonewretchI don't think so. Modern programming is a far different beast but to think there are not people doing magical stuff today is a little silly
I got dinged on a program I wrote on a PET back in high school for using “end” in the middle of a program. I then flipped ahead in the textbook and pointed to the use of “end” in the middle of a program. The teacher said it should only be used at the end of a program. I responded with, “that’s utterly pointless.”
There are some technical reasons why a STOP would be better than END, particularly when it comes to preserving variables. But in such a short routine as this it isn't essential.
Rather strangely, in C64 BASIC it seems that END and STOP are identical, except that STOP prints "BREAK IN 10" or whatever line number the STOP statement was executed on. Both STOP and END preserve the variables and can be CONTinued equally. For a quick test, try this program: 10 A=5:STOP 20 PRINT A RUN and then CONT and the program will print out 5. Change the STOP to END, RUN and CONT and it will print out 5 just the same.
@@8_Bit What happens if you delete line 20. Run the "10 A=5:STOP " and then do a PRINT A after the program stops, and then do the same with "10 A=5:END"? Does it preserve the the value of A so you can print the value in the editor?
@@8_Bit Ok, thanks! Intriguing! Maybe this could be a new video where you check out the ASM and find out why there are two so similar statements and find out when to use them and why. ;)
Memory flood here. I clearly remember investigating this code back in the 80's and also discovering that the border was shrunk to hide the junk that appears when smooth scrolling, although most i had forgotten so this was a nice refresher.
Being an Australian who was born in 1984, I didn't have that much experience with the Commodore 64 when it was current, but when I was maybe 5 or 6, maybe even a bit younger, I remember playing Bowling Night and Road Duel at my cousin's house when I'd go to visit them. They had a Commodore 64C.
Glad you mentioned how difficult opening the side borders is, I managed it a couple of my demos but the code was never perfect. It's still interesting to see games exploit that border space, like the recent Galaga conversion. (Oh, and nice to see the Exploding Fish tape on the desk there, I had a lot of fun doing the music for it and testing the game).
Yes, the side borders are really tricky; I also managed it once but it took ages. I believe I had a scrolltext going through some sprites there at the sides. That's probably the most common use for it? Exploding Fish is a lot of fun, great job with the music on it!
@@8_Bit The title screen for the new-ish C64 demo "Trapped Again" (an homage to the classic original) draws some graphics on the side borders, some diagonal lines. I was scratching my head wondering how they did it. Probably sprites. Here it is if you want to see what I mean: ua-cam.com/video/JeNEyiCiZr0/v-deo.html (it should start at that exact spot).
You could fake the effect simply enough by setting the border color to the screen color using raster interrupts, but that is of course just a cheap visual effect, no sprites allowed.
@@8_Bit For a split second I was thinking that the programmer was changing the border color in such a precise and rapid way that it was creating those diagonal lines but quickly realized that would DEFINITELY be doing it the hard - if not impossible - way! Pretty slick though. Makes me wonder what other glitches or hidden "features" is the VIC-II chip hiding from us? You'd think after nearly 40 years we'd know them all by now!
You are a brave soul to run a machine language program POKEd in from DATA statements without saving first. I learned the hard way that I would always type something in wrong and invariably crash the machine. Since I didn't have a Super Snapshot or other cartridge with a reset from which I would recover, I got into the habit of saving constantly.
I was 17 at the time of the zzap edition. I remember looking into sprites in the border, side borders etc. you have seriously dusted off some cobwebs in my head today. Wow.
The now defunct "World's Biggest Bookstore" shop in Toronto carried both "ZZap! 64" and "Commodore Format" magazines during the early/mid 90s. One of these magazines often had a cassette affixed to the cover, which included demo versions of various games. Of course, most of these games were for PAL machines and only few were playable on an NTSC system.
Yes, bizarrely Commodore Format and Zzap (later rebranded as Commodore Force) were available at a bookstore up here in Thunder Bay around '93 to '94 so I bought many issues. It actually helped keep my dream of becoming a game developer alive, reading those late game designer diaries and so on.
Here in Poland we didn't have magazines with cassetes (too expensive back then), though we could get c64 games ...for free... through the radio transmissions, during evening auditions. The copyright law was introduced in 1994. Before that date some radio stations had computer themed auditions. Sometimes the presenters asked the listeners to prepare cassetes for recording and then weird sounds were played on air. Once you recorded it (granted you had no transmission errors / no other noise... ), you had a new game / program on c64, fully legally.
Thank you so much Robin. It reminded me of good memories ; especially the cover design "The last Ninja". it inspired my friends to create another game for C64 which is called Beauty and the beast.
After 35 years finally I got the answer how to put sprites on the border. I didn't observe that I was sooo close to the answer when I did smooth scrolling back in that days. Thx
I stoped the video and typed it in. I had 2 typos and after that I tripple checked the code and couldn't find any errors. Made me crazy until I gave up and watched the rest of the video. When you got the same error, I was so relieved, haha.
I have that exact same magazine somewhere, must dig it out! That error in the code I remember from typing it in, several people wrote in and told Gary Liddon that the code was wrong and he corrected it the next month, also Mental Procreation with Andrew Braybrook was his diary of a game, the game being Morpheus. He also did another diary of a game in 1985, covering the classic Paradroid (a game I still play even now) ZZAP 64 was a tremendous magazine, brilliantly put together with reviewers who knew their games, Julian Rignall, Gary Penn, Gary Liddon, Paul Sumner etc. I was lucky enough to meet them all at the Commodore show in 1987 with my mate Wally Beben (yes, THE Wally Beben the musician, the man behind Tetris, RISK and Dark Side) and they were friendly to everyone.
Awesome video. thanks! This is why I love the C=64. It got me thinking that you could probably achieve a sprites-OVER-the-borders effect by opening the top and bottom borders like this but essentially rendering them by setting the background color to the border color for the appropriate scan lines.
Back in the 80s I used to have a metal copy holder that attached to the side of the monitor. It had a plastic ruler on a rail, and the ruler had slight magnification in the middle so you could "highlight" your current line.
Cool. I found some of those but they just seemed to accommodate a single page width, while I wanted something that could handle magazines without having to fold them backwards or whatever.
@@8_Bit yeah mine only did a single page as well. Of course back then there was no thought of holding onto magazines when you were done with them so I just tore the listings out.
This is neat; when I was a kid and had my 64 I used to wish that the borders could be turned off; not just color-wise, but allow text and graphics to extend out to the full edge of the screen, but I never could figure out how to do it.
Would love to see the side borders as well exactly because it is so tricky! And yes, your explanation made perfect sense. I love these technical dives into the inner workings of the C64. Thanks!!
The problem is that it has to be cycle exact, there is no X-pos IRQ, though the Y-pos raster IRQ flag is set at exact spot every time, the 6510 will finish its instruction first so you don't know if it was 1 to 7 cycle delay. There are two solutions: Double IRQ, the first one end with just NOPs and then the second raster IRQ happens it will not be a random 1-7 cycles anymore, but 1-2 and that can be found. 2nd solution: IRQ triggers a x-pos lightpen latch and then you read the value and jump through a list of NOP depending of the value.
Reminds me of an issue of Compute! that had a game called ricochet that looked like laser air hockey. I typed it in.......never worked. I found several mistakes in my typeing, but I went over it several times for weeks...........eventually as far as I could tell it matched the listing perfectly. I think I eventually found the pure ASM version on the internet and tried it on an emulator. Not that exciting. But it was definitely the game that was supposed to be in BASIC data statements.
Oh yeah, I can't tell you how many times I typed in one of those old programs and couldn't get it to work even though I went over the code numerous times looking for a mistake....then in the next issue they publish their addendum: "Oops! We made a mistake on line 7326! Variable A should equal 3 instead of 4!"
The absolutely most impressive things I saw on the c64 was stuff drawn only using the background (border) color register when the screen is in off mode. This requires extreme cycle correct timing. My best example of this is XaKK / No Sleep II. In there you can see a full screen scroller ONLY made with the background color. With music at the same time (music takes different cycles every frame, think about that). And this was done in the old days.
First step to open side border is stable raster cycle, here is my Double-IRQ that works from Basic screen IRQtop INC $D012 ; we only have as little a 18 cycles left... 6 LDX #$35 ; ...as kernal delay is 38-45 cycles 2 STX $01 ; turn off kernal so ram is now our vector 3 STX $D019 ; acknowledge the interrupt by clearing flag 4 CLI ; enable IRQ 2 NOP ; only 2 cycle instructions untill IRQ hits NOP ; so no longer 1-7 jitter but 1-2 NOP NOP NOP NOP NOP ; IRQsync address was init to ram $FFFE IRQsync ASL $D019 ; acknowledge the interrupt by clearing flag LDX #$37 ; turn on kernal so rom is now our vector STX $1 ; do some real work instead of dummy loop PLA ; wait exactly 1 lines worth of cycles PLA ; restore stack pointer as no rti here PLA ; and we did not have time to use TSX LDX #249 ; this IRQ open top/bottom border STX $D012 ; set 249 for next LDX #IRQ249 ; ... as I open top/bottom borders too STX $0315 ; ... and open side borders in the top BIT $EA ; just a dummy 3cycle for alignment NOP NOP NOP ;
I remember typing in a program listed in a new (brief) C64 magazine that claimed it doubled the CPU speed. I typed it in, debugged it, disassembled it and it boiled down to a single poke. Which halved the delay of the cursor blink! Bastards!
100 years from now, and people will still be playing with early generation computers because of their relative simplicitiy (8 bit coding etc). Excellent stuff to learn things on before transcending to 32 and 64 bit programming(128-bit CPUs probably won't ever exist with the exception maybe of 128 bit memory addressing when our personal computers smash the Exabyte barrier)
I remember seeing an article in one of the UK computer magazines in the mid to late 1980s describing how to put sprites in the borders (and to clear the junk out of the relevant memory locations). Unfortunately that got lost (read: thrown out, not by me) and it wasn't until the advent of the Internet and all these fantastic resources coming from enthusiasts such as yourself, until I could rediscover this.
Funny detail, jiffydos128 also forgets to mask bit 7 of $d011 when blanking/unblanking the screen, which at times results in the system interupt never happening (in 128 mode, the c128 uses a raster interupt instead of a timer interupt for things like keyboard scan)
"The vertical borders give you lots of wiggle room" as compared to what you called the "horizontal borders." But since the horizontal ones are the top and bottom ones, you got this mixed up. They _expand and shrink_ vertically, though, of course.
Excellent video and in-depth explanation, thank you! While you walked us through a high-level summary of handling the horizontal borders, towards the end, any chance that I’ve somehow missed that episode, good sir?
I don't know if my method was better, in that I had the first interrupt, but in that set the interrupt to occur again to shrink the borders, which set it back to occur at the first again. Honestly I didn't know if that gave the foreground task any significant amount of processing. But I was about 10yo and my knowledge of this trick was from the Action Replay cart and hacking apart existing code.
3:24 The loader would take less code with an explicit FOR loop instead of using an sentinel value. 5:55 That was a problem way back then. And you'd have to wait months for a correction if you couldn't figure out the error for yourself. 7:41 Are the actually skinnier? In the video capture, it looks like they have the same thickness but are dimmer. 7:47 I guess it thinks it's fetching a glyph or bitmap byte, so this doesn't take any additional time, considering that the CPU can't use the bus on the VIC's half-cycles. That's one difference between hardware and software. Hardware is naturally highly parallelized, so if a component isn't needed, you still have to give it something useless to do, at least in the era before fine-grained power management. 10:16 What happens if you use a sprite frame where the character set appears? 14:26 One complication is that the TOD in NTSC-land will run at the wrong frequency. Since it'll think it's getting a 50-Hz power-mains signal when it's actually getting 60 Hz, the clock will run 20% fast. 19:13 Is there a reason that it waits for 7 scanlines instead of just four? The routine could probably just call the normal IRQ code as a subroutine (with some hackery), knowing that that will run for many scanlines worth of time on its own. A complication in PAL-land is that the system IRQ will run at 50 Hz instead of 60 Hz. TI$ will run 17% slow. 21:42 Are you saying "Watch the bottom" or "Watch the bum"?
When I go from POKE 16383,129 to POKE 16383,1 the bars do look somewhat skinnier to me, but they don't look half the width, and yes, the overall effect is that they're dimmer. I assume this is a video artifact related to the reason that most C64 fonts don't use have single-pixel widths. And yes, I think the character graphics shown in the border are just the VIC-II doing a useless fetch as it would presumably take additional logic to fully disable the fetch. If you point sprites at the character ROM, with e.g. POKE 2040,64 (64*64 = 4096 or $1000, which is where the character ROM appears to the VIC-II) then you do get the character ROM, scrambled because of the linear way sprite data is interpreted. This seems like a flaw in the C64's design, but I guess there wasn't any mechanism to allow sprites (and bitmaps) to fetch from RAM while characters fetch from ROM. It does sound like I say "bum" when I mumble "bottom". Fortunately, the two words are pretty much interchangeable!
"What happens if you use a sprite frame where the character set appears?" Would not look like any text as sprite is 3 bytes wide and then the problem with VIC not seeing the Char Rom and Spite Data at same time, complex bank switching done by the PLA. You could copy font to ram first though: LDA #$33 ; switch in I/O mapped registers, $33 for CPU to see the font. $37 so vic can see them again. STA $01 .
Pretty sure NTSC land has 60Hz mains - a reason NTSC has 60 fields per second (2 fields per frame) is to match the mains frequency so that the smoothing of the rectified 60Hz AC mains power to create DC voltages didn't "beat" and cause visual oddities in picture. Also, that's what the B&W video standard NTSC was bolted onto used (Unlike PAL, which has some thought put into, unlike Never Twice Same Color :D )
At 19:13, my take is that the best thing would be to set another raster interrupt 4 lines later, then alternate back to the first one. No use in actively wasting cycles like that.
I never did see Crash in Australia, but then I didn't know anyone with a ZX Spectrum there either. The C64 was very popular at least amongst my schoolmates in Perth.
Thanks for the video, Robin. You explain this very well! :) regarding the oneshot mode of the timer, I'm not completely sure, but I think they want to restart the timer at a certain point rather than running it continuously .. ?
Nice to be reminded that "Copy/paste from Stack Overflow" is not really a NEW concept. :D Also, I seem to recall that this technique is pretty popular in the Demo scene (and maybe originated with a cracktro? Might explain the relative lack of attribution. Or maybe people just cared less about who originated it back then?) - anyway, great explanation for this, thanks!
A friend of mine had every single Zapp!64 stashed down in his basement, and asked if i wanted them since i´m retro gaming collector. I said - YEEES!!!, but 2 days later the rain hit us hard, and his basement got flooded so the magazines ended up being ruined. Never got over the loss ☹☹☹☹
Im definatly NOT sure, but i remebember there was even in the standard manual (at least in the german one...) a listing with sprites moving across the borders. But I may remember that wrongly... That was 35 years ago... 😂
Another reason to set $D011 in the initialization part is to set bit 8 of the raster register to 0, otherwise the interrupt never fires. (As you point out later when $D011 is adjusted in the interrupt routine). For some reason the kernal initializes bit 8 to 1.
But he clears it at every IRQ, kernel would never set it back? and as scrolly trick is in the same register just write $1B and $13 and msb will always be cleared. Sure not nice to assume the other bits, but if they are not default boot values, when the programmer knows what he is doing as it's not running from basic anymore. I ended up just copy a table of all VIC-II settings I want from $D000 to $D02E, the read-only registers don't create "errors" from writes. _D011 BYTE $1B ; Control register 1
The UK had some really great mags for the C64 and the Amiga back in the day. Hell, my mates who owned spectrums also had their own decent batch of mags as well. Good times.
I think the ZX Spectrum had the biggest user base and merchandise of all in the UK. It was one of the few countries where the C64 was not king. Also, the C64 had huge competition from the BBC Micro. I think the big attractor to the C64 for coding gurus, were the easter eggs hidden in the thing, like playing with interrupts for smooth border scrolling and border sprites. Also more than 8 sprites simultaneously was a thing. It really enticed the users to squeeze every last drop of performance out of it.
Then to complicate the horz. border even further, every 8'th line in the visual screen area is a "bad" line where the vic fetches the sprite data, changing the timing vastly.
The interrupt routine doesn't start with a PHA instruction and have a PLA instruction before the RTI, to push and pull the contents of the accumulator. I'm surprised it doesn't clobber anything!
This is using the KERNAL IRQ vector which handles pushing the registers on the stack before jumping through $0314/$0315, and then the pulling/popping is handled in the $EA31 routine that's JMPed to at the end of the routine. It's only if you switch out the KERNAL ROM and use the hardware $FFFE/$FFFF IRQ vector that you need to worry about handling that stuff yourself.
Short explanation: The VIC chip's border rendering logic is flawed in that sense, that it works along the lines "IF [number of scan line currently drawn]=[where border begins] THEN [set border drawn bit]" "IF [number of scan line currently drawn]=[where border end] THEN [clear border drawn bit]" "IF [border drawn bit set] THEN [draw border]" instead of the more sensible "IF [number of scan line currently drawn] >= [where border begins] AND [number of scan line currently drawn]
There probably isn't any code but a latch that gets set and reset by 2 equality-only comparators completely implemented in hardware. Uses less components compared to using magnitude comparators and sufficient to implement the required functionality. To me it is not more sensible to make it more complex than is required, quite the opposite. KISS rules.
The VIC uses hardware flipflops for border and the number it sets it at is based on a absolute match of that raster line, but raster line number is different if scroll mode is enabled.
@@Kris_M totally agree! The vic is not a cpu like chip. There is an obvious challenge building a circuit to detect >= vs. a couple of simple bit checks as you explained well!
These kinds of safeguards are important for software, but no so much for hardware. The VIC chip is a real-time device, so if it misses a scanline, it can only be because its design is borked. Really, if it misses even a single pixel, the picture will wiggle around on the screen, which would be unacceptable.
Hi Robin, I'm sure you get lots of requests for videos but one I'd like to see is you looking at digital audio samples on the c64, such as Ghostbusters and Impossible Mission. I'm sure you mentioned in your frog game that the snare drum was a digital sample. Perhaps this may be easier with modern tools such as Audacity and some cross platform tools?
Hi Nick, yes the drums in Frogs & Flies are "digis". I do have this subject on my long list of potential episode ideas. In the meantime look for my episode called "C128 BASIC Hack: Playing Digital Samples" which partly explores the idea in a kind of weird way.
Hello, great video. I wold like to ask; It is possible save the .bas with the border code, and after, load it in an other program? To use it, like a c library +-, but just load in the other code and use a goto to turn it running. I hope you understand my question. A way to load a code inside other piece of code.
Oh Lord. Typing in code from a paper magazine. I did that, too. Although it was machine code listings,and I did _not_ like it, especially as I did not have a checksumming program to prevent mistakes ;)
That's why other UA-cam channels delegate typing in program listings to their kids 😉. Robin mentioned a "daughter number one" in one of his videos but maybe she is too old now.
It's very annoying that whoever was in charge of layout (not just at Zzap but nearly everywhere) took WAY too long to figure out they couldn't just willy-nilly rearrange things like was done here. How hard would it have been to use 40 monospace columns for the listing? I suppose the nerds got their revenge in that layout was soon computerised and the people who used to destroy BASIC listings eventually all got fired...
I remember the next month's issue had a letter asking "do you get anyone to check your listings or the mess your printers make of them"? To be fair, typesetting companies weren't used to this kind of thing back then, and some cheaper magazines used a less elegant but more reliable system, which was to just reproduce a printout made directly to a dot matrix printer or a 1520 printer/plotter (definitely the best method, and I had a 1520).
The funny thing about shrinking the top and bottom borders is that it probably wasn't necessary to have that feature in the first place. Anyone wanting to scroll the screen vertically and avoid garbage could just use a raster interrupt to change the contents of the "top" row at any point during the screen draw, and then change them back during the border draw. So this trick is probably the only useful thing to ever come out of it.
I don't think you can scroll text both smoothly onto and off of the screen scanline-by-scanline without switching to 24 rows. The Y-smooth scroll feature will produce black lines on the top or bottom of the screen and whole characters will instantly "appear" on the top or bottom.
Will you please make us a video showing what happens when you just remove the stop command and run it, and then when you add an end command in that spot?
Is it possible to have ALL of the borders open at the same time? I don't think I've ever seen it done. Also, some may wonder why those borders exist in the first place on those old computers (not just the C64), but the reason is simple: Many people used regular televisions as their monitors back in the day and they vary wildly in how the screen is positioned, so this was a way to give them some wiggle room so that all graphics can be seen. Modern TVs and monitors don't have this issue of course.
It's possible, I saw a picture that was hyper screen. it used expanded sprite on all sides of border as to extend bitmap out,......31years ago As you would need 8 expanded color sprites for top and bottom, they keep it same for all of the bitmap data, so it looked blocky, did take away a little of the wow factor. Was some space shooter motive I think, like a zaxxon.
The VIC20 had much easier control of the borders and screen size, and many Commodore cartridges defaulted the screen position to the top left of the raster and the opening instructions told you to use the cursor keys to centre the screen to your liking.
@@JustWasted3HoursHere Without a VIC20 or emulator to hand I think 36880 and 36881 controlled top and left origin points and 36882-3 were screen width and height. There was also a double height mode which you got by setting a certain bit in one of the nearby registers which also switched between single and multicolour pixels. All of those changes of course turned the screen into a mess without remapping lots of other stuff, it didn't keep everything neatly aligned for you, of course.
"There's nobody I can ask," claims Gaz. Whoops, I guess there actually _was_ someone he could ask! And if I were him, I would also have asked how this was figured out.
Hi.. Great video..... sorry I'm not exactly a programmer but express an interest... could u tell me how u get the machine code up if u know what I mean
Hi, I'm using the machine language monitor built into the Super Snapshot v5 cartridge. Action Replay cartridge also has one built in. Emulators such as VICE also have one built in, look for "VICE Mon" or "Monitor" in the settings.
So the now open border area can be used by sprites that would otherwise be covered by the border? But the text still has 25 lines? Or does it have 26, 27 or 28 lines?
There's still just 25 text lines, but yes, the sprites can be shown in the border. Some games use sprites in the border area to show score, lives counter, etc.
These and techniques like FLI were probably first discovered or hinted at (likely independently by multiple people) by being clued in when seeing things like flicker and other oddities when timing wasn't taken into account. If you've ever played with the scrolling and border-size settings in BASIC you've noticed this. And of course word spreads from there. It wasn't until the mid-'90s when I first saw this and about passed out. I think it was an intro to a game called Terminal City. Not to toot my own horn but I tried this in BASIC sometime back: ua-cam.com/video/-5ASyabVrxg/v-deo.html ua-cam.com/video/Kh8FlwG4T80/v-deo.html
Yes, I had noticed momentary, single line or single frame dropouts in border whenever I switched between modes, and surmised it would be possible to make them occur repeatedly. I managed the vertical borders but never the sides.
"I remember typing that in back in 1987...." but never saved it? Or lost the disk, or...? Also, since there was that published error, will you correct it in your magazine for future look/use, just like you made some adjustments in your programmers' guide?
When will we se full breakdown of opening left and right borders? Remember ripping the code from 1001 crew and repurposing it in my own demos. Timing was a b@## and I did not fully get it. 13yrs old with c64 reference guide... and Norwegian...
Why would NTSC let the computer cut more stuff off by just sending more picture lines than the monitor has, rather than just not even having those lines available to send to the monitor for NTSC, and then having them available in the machines that were sent out to PAL countries?
NTSC has lower vertical resolution (fewer scanlines) than PAL. The C64 screen within the borders has 200 pixels of vertical resolution regardless of region. On NTSC, these 200 lines take up more of the viewable screen space than on PAL, which is why text and sprites appear taller in NTSC than they do in PAL. You can see the result of this in games made in the different regions. Circles made in American games appear as wide ovals on PAL C64s, and circles made in European games appear as tall ovals on NTSC C64s.
Turn off CIA I saw in an example, As I use a table for all VIC-II settings, I removed the AND/STA $D011 as redundant for my own code. SEI ; set bit, make the CPU ignore interrupt LDA #%01111111 ; switch off interrupt signals from CIA-1 STA $DC0D AND $D011 ; get bits already set STA $D011 ; stop 505 non-existent line crash LDA $DC0D ; acknowledge pending interrupts from CIA-1 LDA $DD0D ; acknowledge pending interrupts from CIA-2
@@8_Bit I do love this video - when I helped code Revenge/Chrome in 1992, I knew how to knock out the vertical borders but I never understood how it worked - I could never get my head around NMIs so I tended to resort to brute force coding. Even now I am amazed that it worked at all.
There's a couple of other tricks that can be done with the open border - Quetzal/Chrome discovered by accident that you can open just the bottom border but leave the top one intact. Having discovered this, he forgot about it until a few years later when demo group Crest released a demo showcasing the effect. I found out that you can also scroll the screen down so you can display the bottom row of text in the lower border. I think I used this in the "Multiscrollers" part of Revenge so I could fit the nine scrollers on the screen due to my hideously inefficient code relying on waiting for a certain raster line rather than using the NMI.
Yes INC/DEC $D016 at exact cycle on every line you want the side open, the problem is to align your code, but I did it last week ua-cam.com/video/XwO_lPWxqfc/v-deo.html
Honestly every video you do is like meeting up with an old friend despite having never met you. Keep it up dude.
Heartwarming, fascinating, and educational. :)
I spent a year in Western Australia too. That was also 1987. Still here. Loong year.
Been here for so long that we're not permitted to leave.
Hopefully Claremont News still sells Zzap!64.
Who would have thought that 40 years after it’s introduction, I would be ENJOYING watching a type-in BASIC program being explained. Thanks for this. Keep it up!
Well, the basic loader just loads in the machine code where the real magic happens. I remember back then typing in long data statements wondering what the heck do they actually do. heh
I was on Compunet (A UK C64 multi-user BBS) back when this sprite in the border trick was discovered, and the knowlege of how to do is spread rapidly around the demo community on there.
At the time it was an amazing trick, our jaws hit the floor when we saw it for the first time.
Of course games started using the technique soon afterwards.
Do you remember who discovered it?
@@csabasanta5696 Unfortunately, no. It was decades ago, and memories fade unfortunately. I just remember demos using this trick and being amazed it was possible. A friend of mine who was a better coder than I worked out how to do it and wrote a nice sprites in the border scrolling message routine for me.
Credit goes to Radwar from Germany, while the discovery of the side-border opening is still open to dispute by Dutch 1001 Crew and Danish infamous coder Sodan. Expanded side-border sprites are credited to Dutch crew The Judges, in their demo series Think Twice.
@@ProBloggerWorld Thanks for the info, interesting!
@@ProBloggerWorld - Side border expansion is amazing but really difficult due to timing issues and the relatively slow CPU of the C64. Nevertheless, it's possible with some restrictions.
Very well explained. I love that we really don't know who figured this out but they must have had a blast when they did. And imagine working out that the pattern shown comes from $3FFF. It's all very machine specific knowledge that is important to preserve somehow.
They were coding magicians back then. only books and understanding to go on. all lost, relatively, in the era of point and click...
@@lonewretch at the time there was a lot of debate about who 'discovered' it, especially on the fledgling demo scene and Compunet. We had Tony Crowther making claims that he discovered it (and published it in a demo as Ratt with music by Ben), but I think it originally came from 1001 Crew (Joost Honig) and then we all ripped off 'their' code (including Tony Crowther). I ripped it off too in a very early demo of my own , with some Hubbard music and a scroller to go with it. For quite a few people my demo was the first time they saw 'border sprites' and thought I'd discovered it. As a young teenager I didn't do anything to dispell this falsehood (althought I did own up to ripping the code from Ratt's demo in the accompanying scroller.)
@@lonewretchI don't think so. Modern programming is a far different beast but to think there are not people doing magical stuff today is a little silly
I got dinged on a program I wrote on a PET back in high school for using “end” in the middle of a program. I then flipped ahead in the textbook and pointed to the use of “end” in the middle of a program. The teacher said it should only be used at the end of a program. I responded with, “that’s utterly pointless.”
There are some technical reasons why a STOP would be better than END, particularly when it comes to preserving variables. But in such a short routine as this it isn't essential.
Rather strangely, in C64 BASIC it seems that END and STOP are identical, except that STOP prints "BREAK IN 10" or whatever line number the STOP statement was executed on. Both STOP and END preserve the variables and can be CONTinued equally.
For a quick test, try this program:
10 A=5:STOP
20 PRINT A
RUN and then CONT and the program will print out 5. Change the STOP to END, RUN and CONT and it will print out 5 just the same.
@@8_Bit What happens if you delete line 20. Run the "10 A=5:STOP " and then do a PRINT A after the program stops, and then do the same with "10 A=5:END"? Does it preserve the the value of A so you can print the value in the editor?
@@stefankarlsson4652 Yes, you can PRINT A in immediate mode after RUNning either version of line 10 and it will print 5.
@@8_Bit Ok, thanks! Intriguing!
Maybe this could be a new video where you check out the ASM and find out why there are two so similar statements and find out when to use them and why. ;)
Memory flood here. I clearly remember investigating this code back in the 80's and also discovering that the border was shrunk to hide the junk that appears when smooth scrolling, although most i had forgotten so this was a nice refresher.
Being an Australian who was born in 1984, I didn't have that much experience with the Commodore 64 when it was current, but when I was maybe 5 or 6, maybe even a bit younger, I remember playing Bowling Night and Road Duel at my cousin's house when I'd go to visit them. They had a Commodore 64C.
Glad you mentioned how difficult opening the side borders is, I managed it a couple of my demos but the code was never perfect. It's still interesting to see games exploit that border space, like the recent Galaga conversion.
(Oh, and nice to see the Exploding Fish tape on the desk there, I had a lot of fun doing the music for it and testing the game).
Yes, the side borders are really tricky; I also managed it once but it took ages. I believe I had a scrolltext going through some sprites there at the sides. That's probably the most common use for it?
Exploding Fish is a lot of fun, great job with the music on it!
@@8_Bit The title screen for the new-ish C64 demo "Trapped Again" (an homage to the classic original) draws some graphics on the side borders, some diagonal lines. I was scratching my head wondering how they did it. Probably sprites. Here it is if you want to see what I mean: ua-cam.com/video/JeNEyiCiZr0/v-deo.html (it should start at that exact spot).
@@JustWasted3HoursHere Cool, yeah, it would be sprites carefully made and lined up to match the bitmap shown on the screen.
You could fake the effect simply enough by setting the border color to the screen color using raster interrupts, but that is of course just a cheap visual effect, no sprites allowed.
@@8_Bit For a split second I was thinking that the programmer was changing the border color in such a precise and rapid way that it was creating those diagonal lines but quickly realized that would DEFINITELY be doing it the hard - if not impossible - way! Pretty slick though. Makes me wonder what other glitches or hidden "features" is the VIC-II chip hiding from us? You'd think after nearly 40 years we'd know them all by now!
You are a brave soul to run a machine language program POKEd in from DATA statements without saving first. I learned the hard way that I would always type something in wrong and invariably crash the machine. Since I didn't have a Super Snapshot or other cartridge with a reset from which I would recover, I got into the habit of saving constantly.
Living dangerously! Yeah, I learned the hard way too in my pre-reset / Super Snapshot days.
I was 17 at the time of the zzap edition. I remember looking into sprites in the border, side borders etc. you have seriously dusted off some cobwebs in my head today. Wow.
Amazing :) That’s my code with my horrible typo.
Thanks for all you've done over the years!
What a brilliant and clear explanation how that works! Fully understood!
The now defunct "World's Biggest Bookstore" shop in Toronto carried both "ZZap! 64" and "Commodore Format" magazines during the early/mid 90s. One of these magazines often had a cassette affixed to the cover, which included demo versions of various games. Of course, most of these games were for PAL machines and only few were playable on an NTSC system.
Yes, bizarrely Commodore Format and Zzap (later rebranded as Commodore Force) were available at a bookstore up here in Thunder Bay around '93 to '94 so I bought many issues. It actually helped keep my dream of becoming a game developer alive, reading those late game designer diaries and so on.
Here in Poland we didn't have magazines with cassetes (too expensive back then), though we could get c64 games ...for free... through the radio transmissions, during evening auditions. The copyright law was introduced in 1994. Before that date some radio stations had computer themed auditions. Sometimes the presenters asked the listeners to prepare cassetes for recording and then weird sounds were played on air. Once you recorded it (granted you had no transmission errors / no other noise... ), you had a new game / program on c64, fully legally.
Thank you so much Robin.
It reminded me of good memories ; especially the cover design "The last Ninja". it inspired my friends to create another game for C64 which is called Beauty and the beast.
That's pretty neat! Another great video!
After 35 years finally I got the answer how to put sprites on the border. I didn't observe that I was sooo close to the answer when I did smooth scrolling back in that days. Thx
Thank you for this great content!
Zzap! was a way of life for Commodore 64 users in UK in the 1980s.
I stoped the video and typed it in. I had 2 typos and after that I tripple checked the code and couldn't find any errors. Made me crazy until I gave up and watched the rest of the video. When you got the same error, I was so relieved, haha.
Great video! Can't wait for that side-border one :)
3:06 I really like the way you utilise the screen, with it split in 3 like that :)
This is ASMR gold.
I have that exact same magazine somewhere, must dig it out! That error in the code I remember from typing it in, several people wrote in and told Gary Liddon that the code was wrong and he corrected it the next month, also Mental Procreation with Andrew Braybrook was his diary of a game, the game being Morpheus. He also did another diary of a game in 1985, covering the classic Paradroid (a game I still play even now) ZZAP 64 was a tremendous magazine, brilliantly put together with reviewers who knew their games, Julian Rignall, Gary Penn, Gary Liddon, Paul Sumner etc. I was lucky enough to meet them all at the Commodore show in 1987 with my mate Wally Beben (yes, THE Wally Beben the musician, the man behind Tetris, RISK and Dark Side) and they were friendly to everyone.
Awesome video. thanks! This is why I love the C=64.
It got me thinking that you could probably achieve a sprites-OVER-the-borders effect by opening the top and bottom borders like this but essentially rendering them by setting the background color to the border color for the appropriate scan lines.
Your explaination is possibly the best i have ever heard. Many thanks for taking the time to dissect how it's all working under the hood !
Back in the 80s I used to have a metal copy holder that attached to the side of the monitor. It had a plastic ruler on a rail, and the ruler had slight magnification in the middle so you could "highlight" your current line.
Cool. I found some of those but they just seemed to accommodate a single page width, while I wanted something that could handle magazines without having to fold them backwards or whatever.
@@8_Bit yeah mine only did a single page as well. Of course back then there was no thought of holding onto magazines when you were done with them so I just tore the listings out.
Very clever... great explanation!
This is neat; when I was a kid and had my 64 I used to wish that the borders could be turned off; not just color-wise, but allow text and graphics to extend out to the full edge of the screen, but I never could figure out how to do it.
Would love to see the side borders as well exactly because it is so tricky!
And yes, your explanation made perfect sense. I love these technical dives into the inner workings of the C64. Thanks!!
The problem is that it has to be cycle exact, there is no X-pos IRQ, though the Y-pos raster IRQ flag is set at exact spot every time,
the 6510 will finish its instruction first so you don't know if it was 1 to 7 cycle delay. There are two solutions:
Double IRQ, the first one end with just NOPs and then the second raster IRQ happens it will not be a random 1-7 cycles anymore, but 1-2 and that can be found.
2nd solution: IRQ triggers a x-pos lightpen latch and then you read the value and jump through a list of NOP depending of the value.
Reminds me of an issue of Compute! that had a game called ricochet that looked like laser air hockey. I typed it in.......never worked. I found several mistakes in my typeing, but I went over it several times for weeks...........eventually as far as I could tell it matched the listing perfectly. I think I eventually found the pure ASM version on the internet and tried it on an emulator. Not that exciting. But it was definitely the game that was supposed to be in BASIC data statements.
Oh yeah, I can't tell you how many times I typed in one of those old programs and couldn't get it to work even though I went over the code numerous times looking for a mistake....then in the next issue they publish their addendum: "Oops! We made a mistake on line 7326! Variable A should equal 3 instead of 4!"
@@JustWasted3HoursHere fun times
To my mind, you have turned the raster interrupt check into a game of 'find the lady'. Nice! I hope those sprites have got their passports 😉
Great video Robin.
The absolutely most impressive things I saw on the c64 was stuff drawn only using the background (border) color register when the screen is in off mode. This requires extreme cycle correct timing. My best example of this is XaKK / No Sleep II.
In there you can see a full screen scroller ONLY made with the background color. With music at the same time (music takes different cycles every frame, think about that). And this was done in the old days.
Bring back the 80s! Can't wait to try some of this out on an actual breadbin.
Perfect Robin. I needed this for my game.
First step to open side border is stable raster cycle, here is my Double-IRQ that works from Basic screen
IRQtop INC $D012 ; we only have as little a 18 cycles left... 6
LDX #$35 ; ...as kernal delay is 38-45 cycles 2
STX $01 ; turn off kernal so ram is now our vector 3
STX $D019 ; acknowledge the interrupt by clearing flag 4
CLI ; enable IRQ 2
NOP ; only 2 cycle instructions untill IRQ hits
NOP ; so no longer 1-7 jitter but 1-2
NOP
NOP
NOP
NOP
NOP
; IRQsync address was init to ram $FFFE
IRQsync ASL $D019 ; acknowledge the interrupt by clearing flag
LDX #$37 ; turn on kernal so rom is now our vector
STX $1 ; do some real work instead of dummy loop
PLA ; wait exactly 1 lines worth of cycles
PLA ; restore stack pointer as no rti here
PLA ; and we did not have time to use TSX
LDX #249 ; this IRQ open top/bottom border
STX $D012 ; set 249 for next
LDX #IRQ249 ; ... as I open top/bottom borders too
STX $0315 ; ... and open side borders in the top
BIT $EA ; just a dummy 3cycle for alignment
NOP
NOP
NOP ;
I remember typing in a program listed in a new (brief) C64 magazine that claimed it doubled the CPU speed. I typed it in, debugged it, disassembled it and it boiled down to a single poke. Which halved the delay of the cursor blink! Bastards!
Sneaky...
I'm lying in bed at 2am watching a Canadian bloke typing in endless DATA statements from a magazine into his Commodore 64.
another great video sir
Beautiful!
Thank you for another amazing videoclip
Like always, a tonne of good infos. Thumb’s up.
100 years from now, and people will still be playing with early generation computers because of their relative simplicitiy (8 bit coding etc). Excellent stuff to learn things on before transcending to 32 and 64 bit programming(128-bit CPUs probably won't ever exist with the exception maybe of 128 bit memory addressing when our personal computers smash the Exabyte barrier)
I remember seeing an article in one of the UK computer magazines in the mid to late 1980s describing how to put sprites in the borders (and to clear the junk out of the relevant memory locations). Unfortunately that got lost (read: thrown out, not by me) and it wasn't until the advent of the Internet and all these fantastic resources coming from enthusiasts such as yourself, until I could rediscover this.
Funny detail, jiffydos128 also forgets to mask bit 7 of $d011 when blanking/unblanking the screen, which at times results in the system interupt never happening (in 128 mode, the c128 uses a raster interupt instead of a timer interupt for things like keyboard scan)
Zzap was the gaming bible for c64. In Australia it was very, very popular.
Love the outro tune!
"The vertical borders give you lots of wiggle room" as compared to what you called the "horizontal borders." But since the horizontal ones are the top and bottom ones, you got this mixed up. They _expand and shrink_ vertically, though, of course.
Excellent video and in-depth explanation, thank you! While you walked us through a high-level summary of handling the horizontal borders, towards the end, any chance that I’ve somehow missed that episode, good sir?
I don't think I've covered opening the side borders in detail unfortunately. Would be a good topic to cover eventually!
@@8_Bit yes sir, I agree, and in perusing the comments on this episode, I wouldn’t be alone!
Thanks again for your great content. 👍
The Head and Heels on that cover are nitghtmare fuel!
I don't know if my method was better, in that I had the first interrupt, but in that set the interrupt to occur again to shrink the borders, which set it back to occur at the first again. Honestly I didn't know if that gave the foreground task any significant amount of processing. But I was about 10yo and my knowledge of this trick was from the Action Replay cart and hacking apart existing code.
Thanks for another great video.
3:24 The loader would take less code with an explicit FOR loop instead of using an sentinel value.
5:55 That was a problem way back then. And you'd have to wait months for a correction if you couldn't figure out the error for yourself.
7:41 Are the actually skinnier? In the video capture, it looks like they have the same thickness but are dimmer.
7:47 I guess it thinks it's fetching a glyph or bitmap byte, so this doesn't take any additional time, considering that the CPU can't use the bus on the VIC's half-cycles. That's one difference between hardware and software. Hardware is naturally highly parallelized, so if a component isn't needed, you still have to give it something useless to do, at least in the era before fine-grained power management.
10:16 What happens if you use a sprite frame where the character set appears?
14:26 One complication is that the TOD in NTSC-land will run at the wrong frequency. Since it'll think it's getting a 50-Hz power-mains signal when it's actually getting 60 Hz, the clock will run 20% fast.
19:13 Is there a reason that it waits for 7 scanlines instead of just four? The routine could probably just call the normal IRQ code as a subroutine (with some hackery), knowing that that will run for many scanlines worth of time on its own. A complication in PAL-land is that the system IRQ will run at 50 Hz instead of 60 Hz. TI$ will run 17% slow.
21:42 Are you saying "Watch the bottom" or "Watch the bum"?
When I go from POKE 16383,129 to POKE 16383,1 the bars do look somewhat skinnier to me, but they don't look half the width, and yes, the overall effect is that they're dimmer. I assume this is a video artifact related to the reason that most C64 fonts don't use have single-pixel widths.
And yes, I think the character graphics shown in the border are just the VIC-II doing a useless fetch as it would presumably take additional logic to fully disable the fetch.
If you point sprites at the character ROM, with e.g. POKE 2040,64 (64*64 = 4096 or $1000, which is where the character ROM appears to the VIC-II) then you do get the character ROM, scrambled because of the linear way sprite data is interpreted. This seems like a flaw in the C64's design, but I guess there wasn't any mechanism to allow sprites (and bitmaps) to fetch from RAM while characters fetch from ROM.
It does sound like I say "bum" when I mumble "bottom". Fortunately, the two words are pretty much interchangeable!
"What happens if you use a sprite frame where the character set appears?"
Would not look like any text as sprite is 3 bytes wide and then the problem with VIC not seeing the Char Rom and Spite Data at same time,
complex bank switching done by the PLA. You could copy font to ram first though:
LDA #$33 ; switch in I/O mapped registers, $33 for CPU to see the font. $37 so vic can see them again.
STA $01 .
Pretty sure NTSC land has 60Hz mains - a reason NTSC has 60 fields per second (2 fields per frame) is to match the mains frequency so that the smoothing of the rectified 60Hz AC mains power to create DC voltages didn't "beat" and cause visual oddities in picture. Also, that's what the B&W video standard NTSC was bolted onto used (Unlike PAL, which has some thought put into, unlike Never Twice Same Color :D )
At 19:13, my take is that the best thing would be to set another raster interrupt 4 lines later, then alternate back to the first one. No use in actively wasting cycles like that.
Now for side borders!
Peak years of C64 gaming.
A magazine bought in Australia, on a stand given by your friend Sheila...is this a coincidence?
Now, if this could be in kick assembler...it would be very nice
The other edition was Crash ZX Spectrum. I bought that very often.
I never did see Crash in Australia, but then I didn't know anyone with a ZX Spectrum there either. The C64 was very popular at least amongst my schoolmates in Perth.
@@8_Bit
en.wikipedia.org/wiki/Crash_(magazine)
en.wikipedia.org/wiki/Zzap!64
Same publisher
Thanks for the video, Robin. You explain this very well! :) regarding the oneshot mode of the timer, I'm not completely sure, but I think they want to restart the timer at a certain point rather than running it continuously .. ?
Nice to be reminded that "Copy/paste from Stack Overflow" is not really a NEW concept. :D Also, I seem to recall that this technique is pretty popular in the Demo scene (and maybe originated with a cracktro? Might explain the relative lack of attribution. Or maybe people just cared less about who originated it back then?) - anyway, great explanation for this, thanks!
Zzap was awesome
A friend of mine had every single Zapp!64 stashed down in his basement, and asked if i wanted them since i´m retro gaming collector. I said - YEEES!!!, but 2 days later the rain hit us hard, and his basement got flooded so the magazines ended up being ruined. Never got over the loss ☹☹☹☹
Ugh :(
That machine code just pokes a series of numbers into key registers…
Im definatly NOT sure, but i remebember there was even in the standard manual (at least in the german one...) a listing with sprites moving across the borders. But I may remember that wrongly... That was 35 years ago... 😂
Nice to see some UK 64 items, Zzap 64 was a great magazine.Almost as good as Crash.....
Way to make me look strange as I TRIED shouting at the screen when you made your mistake on line 100 (I'm sitting in my office at work!) :)
I hope your boss didn't hear ;)
Oh, right...
Great video! Maybe sometime you can make one about corrections to mistakes in Mapping the 64, eh? :)
Activision were famed for putting their logo in the bottom border. It was like an industry secret.
Another reason to set $D011 in the initialization part is to set bit 8 of the raster register to 0, otherwise the interrupt never fires. (As you point out later when $D011 is adjusted in the interrupt routine). For some reason the kernal initializes bit 8 to 1.
But he clears it at every IRQ, kernel would never set it back? and as scrolly trick is in the same register just write $1B and $13 and msb will always be cleared.
Sure not nice to assume the other bits, but if they are not default boot values, when the programmer knows what he is doing as it's not running from basic anymore.
I ended up just copy a table of all VIC-II settings I want from $D000 to $D02E, the read-only registers don't create "errors" from writes.
_D011 BYTE $1B ; Control register 1
The UK had some really great mags for the C64 and the Amiga back in the day. Hell, my mates who owned spectrums also had their own decent batch of mags as well. Good times.
I think the ZX Spectrum had the biggest user base and merchandise of all in the UK. It was one of the few countries where the C64 was not king. Also, the C64 had huge competition from the BBC Micro. I think the big attractor to the C64 for coding gurus, were the easter eggs hidden in the thing, like playing with interrupts for smooth border scrolling and border sprites. Also more than 8 sprites simultaneously was a thing. It really enticed the users to squeeze every last drop of performance out of it.
Then to complicate the horz. border even further, every 8'th line in the visual screen area is a "bad" line where the vic fetches the sprite data, changing the timing vastly.
Not in the border.
@@riwilo Granted. Vic hasnt started yet to fetch. Precious time.
The interrupt routine doesn't start with a PHA instruction and have a PLA instruction before the RTI, to push and pull the contents of the accumulator. I'm surprised it doesn't clobber anything!
This is using the KERNAL IRQ vector which handles pushing the registers on the stack before jumping through $0314/$0315, and then the pulling/popping is handled in the $EA31 routine that's JMPed to at the end of the routine. It's only if you switch out the KERNAL ROM and use the hardware $FFFE/$FFFF IRQ vector that you need to worry about handling that stuff yourself.
Short explanation: The VIC chip's border rendering logic is flawed in that sense, that it works along the lines
"IF [number of scan line currently drawn]=[where border begins] THEN [set border drawn bit]"
"IF [number of scan line currently drawn]=[where border end] THEN [clear border drawn bit]"
"IF [border drawn bit set] THEN [draw border]"
instead of the more sensible
"IF [number of scan line currently drawn] >= [where border begins] AND [number of scan line currently drawn]
There probably isn't any code but a latch that gets set and reset by 2 equality-only comparators completely implemented in hardware. Uses less components compared to using magnitude comparators and sufficient to implement the required functionality.
To me it is not more sensible to make it more complex than is required, quite the opposite. KISS rules.
The VIC uses hardware flipflops for border and the number it sets it at is based on a absolute match of that raster line, but raster line number is different if scroll mode is enabled.
@@Kris_M totally agree! The vic is not a cpu like chip.
There is an obvious challenge building a circuit to detect >= vs. a couple of simple bit checks as you explained well!
These kinds of safeguards are important for software, but no so much for hardware. The VIC chip is a real-time device, so if it misses a scanline, it can only be because its design is borked. Really, if it misses even a single pixel, the picture will wiggle around on the screen, which would be unacceptable.
Hi Robin, I'm sure you get lots of requests for videos but one I'd like to see is you looking at digital audio samples on the c64, such as Ghostbusters and Impossible Mission. I'm sure you mentioned in your frog game that the snare drum was a digital sample. Perhaps this may be easier with modern tools such as Audacity and some cross platform tools?
Hi Nick, yes the drums in Frogs & Flies are "digis". I do have this subject on my long list of potential episode ideas. In the meantime look for my episode called "C128 BASIC Hack: Playing Digital Samples" which partly explores the idea in a kind of weird way.
@@8_Bit I must have missed this video. I'll check it out. Thanks for the reply
Hello, great video. I wold like to ask; It is possible save the .bas with the border code, and after, load it in an other program? To use it, like a c library +-, but just load in the other code and use a goto to turn it running. I hope you understand my question. A way to load a code inside other piece of code.
Oh Lord. Typing in code from a paper magazine. I did that, too. Although it was machine code listings,and I did _not_ like it, especially as I did not have a checksumming program to prevent mistakes ;)
That's why other UA-cam channels delegate typing in program listings to their kids 😉. Robin mentioned a "daughter number one" in one of his videos but maybe she is too old now.
The knight on the zzap64 cover looks like he whisking away judge Judy.
It's very annoying that whoever was in charge of layout (not just at Zzap but nearly everywhere) took WAY too long to figure out they couldn't just willy-nilly rearrange things like was done here. How hard would it have been to use 40 monospace columns for the listing? I suppose the nerds got their revenge in that layout was soon computerised and the people who used to destroy BASIC listings eventually all got fired...
I remember the next month's issue had a letter asking "do you get anyone to check your listings or the mess your printers make of them"?
To be fair, typesetting companies weren't used to this kind of thing back then, and some cheaper magazines used a less elegant but more reliable system, which was to just reproduce a printout made directly to a dot matrix printer or a 1520 printer/plotter (definitely the best method, and I had a 1520).
The funny thing about shrinking the top and bottom borders is that it probably wasn't necessary to have that feature in the first place. Anyone wanting to scroll the screen vertically and avoid garbage could just use a raster interrupt to change the contents of the "top" row at any point during the screen draw, and then change them back during the border draw. So this trick is probably the only useful thing to ever come out of it.
I don't think you can scroll text both smoothly onto and off of the screen scanline-by-scanline without switching to 24 rows. The Y-smooth scroll feature will produce black lines on the top or bottom of the screen and whole characters will instantly "appear" on the top or bottom.
Awesome! I love your visual explanation of this technique. I would love it if you did a side border video too. Are you up for the challenge? :-)
That might happen! :) I will need to dig out some of my old code and shake the rust off...
Will you please make us a video showing what happens when you just remove the stop command and run it, and then when you add an end command in that spot?
Is it possible to have ALL of the borders open at the same time? I don't think I've ever seen it done.
Also, some may wonder why those borders exist in the first place on those old computers (not just the C64), but the reason is simple: Many people used regular televisions as their monitors back in the day and they vary wildly in how the screen is positioned, so this was a way to give them some wiggle room so that all graphics can be seen. Modern TVs and monitors don't have this issue of course.
I just questioned myself that, and now when you mention it it's obvious why. Thanks for that! :)
It's possible, I saw a picture that was hyper screen. it used expanded sprite on all sides of border as to extend bitmap out,......31years ago
As you would need 8 expanded color sprites for top and bottom, they keep it same for all of the bitmap data, so it looked blocky, did take away a little of the wow factor.
Was some space shooter motive I think, like a zaxxon.
The VIC20 had much easier control of the borders and screen size, and many Commodore cartridges defaulted the screen position to the top left of the raster and the opening instructions told you to use the cursor keys to centre the screen to your liking.
@@markboulton954 Interesting. I never owned a Vic20.
@@JustWasted3HoursHere Without a VIC20 or emulator to hand I think 36880 and 36881 controlled top and left origin points and 36882-3 were screen width and height. There was also a double height mode which you got by setting a certain bit in one of the nearby registers which also switched between single and multicolour pixels. All of those changes of course turned the screen into a mess without remapping lots of other stuff, it didn't keep everything neatly aligned for you, of course.
"There's nobody I can ask," claims Gaz. Whoops, I guess there actually _was_ someone he could ask!
And if I were him, I would also have asked how this was figured out.
I see you have a correction at $DC0E. What other addenda do you have in Mapping the Commodore 64? :)
the vice emulator does a cpu jam. lol
Hi.. Great video..... sorry I'm not exactly a programmer but express an interest... could u tell me how u get the machine code up if u know what I mean
Hi, I'm using the machine language monitor built into the Super Snapshot v5 cartridge. Action Replay cartridge also has one built in. Emulators such as VICE also have one built in, look for "VICE Mon" or "Monitor" in the settings.
So the now open border area can be used by sprites that would otherwise be covered by the border? But the text still has 25 lines? Or does it have 26, 27 or 28 lines?
There's still just 25 text lines, but yes, the sprites can be shown in the border. Some games use sprites in the border area to show score, lives counter, etc.
These and techniques like FLI were probably first discovered or hinted at (likely independently by multiple people) by being clued in when seeing things like flicker and other oddities when timing wasn't taken into account. If you've ever played with the scrolling and border-size settings in BASIC you've noticed this. And of course word spreads from there. It wasn't until the mid-'90s when I first saw this and about passed out. I think it was an intro to a game called Terminal City. Not to toot my own horn but I tried this in BASIC sometime back:
ua-cam.com/video/-5ASyabVrxg/v-deo.html
ua-cam.com/video/Kh8FlwG4T80/v-deo.html
Yes, I had noticed momentary, single line or single frame dropouts in border whenever I switched between modes, and surmised it would be possible to make them occur repeatedly. I managed the vertical borders but never the sides.
A hypothetical US audience would not have been able to cope with all of the coloUr.
"I remember typing that in back in 1987...." but never saved it? Or lost the disk, or...?
Also, since there was that published error, will you correct it in your magazine for future look/use, just like you made some adjustments in your programmers' guide?
When will we se full breakdown of opening left and right borders? Remember ripping the code from 1001 crew and repurposing it in my own demos. Timing was a b@## and I did not fully get it. 13yrs old with c64 reference guide... and Norwegian...
Why would NTSC let the computer cut more stuff off by just sending more picture lines than the monitor has, rather than just not even having those lines available to send to the monitor for NTSC, and then having them available in the machines that were sent out to PAL countries?
NTSC has lower vertical resolution (fewer scanlines) than PAL. The C64 screen within the borders has 200 pixels of vertical resolution regardless of region. On NTSC, these 200 lines take up more of the viewable screen space than on PAL, which is why text and sprites appear taller in NTSC than they do in PAL. You can see the result of this in games made in the different regions. Circles made in American games appear as wide ovals on PAL C64s, and circles made in European games appear as tall ovals on NTSC C64s.
Please tell us about Nigel's psychedelic Commodore.
Turn off CIA I saw in an example, As I use a table for all VIC-II settings, I removed the AND/STA $D011 as redundant for my own code.
SEI ; set bit, make the CPU ignore interrupt
LDA #%01111111 ; switch off interrupt signals from CIA-1
STA $DC0D
AND $D011 ; get bits already set
STA $D011 ; stop 505 non-existent line crash
LDA $DC0D ; acknowledge pending interrupts from CIA-1
LDA $DD0D ; acknowledge pending interrupts from CIA-2
Dang! Where did you live in Australia at the time? Claremont is just West of Perth whereas I was very East of Perth of the time.
I lived just west of Claremont in Cottesloe, on Grant Street just a few blocks from the beach!
@@8_Bit I do love this video - when I helped code Revenge/Chrome in 1992, I knew how to knock out the vertical borders but I never understood how it worked - I could never get my head around NMIs so I tended to resort to brute force coding. Even now I am amazed that it worked at all.
There's a couple of other tricks that can be done with the open border - Quetzal/Chrome discovered by accident that you can open just the bottom border but leave the top one intact. Having discovered this, he forgot about it until a few years later when demo group Crest released a demo showcasing the effect.
I found out that you can also scroll the screen down so you can display the bottom row of text in the lower border. I think I used this in the "Multiscrollers" part of Revenge so I could fit the nine scrollers on the screen due to my hideously inefficient code relying on waiting for a certain raster line rather than using the NMI.
Try going after the side border now! If I recall it was a $D016 hack ?
Yes INC/DEC $D016 at exact cycle on every line you want the side open, the problem is to align your code, but I did it last week ua-cam.com/video/XwO_lPWxqfc/v-deo.html
Funny how Darren was last in the list. He seems to always like to have the last word...
Never knew Jordan Peterson was so into the C=64. 🤣
very interesting. my brain now hurts...