Whilst on lockdown I decided to revisit the C64. My family got a C64 when they came out (we also had a Vic20). I've written a 'Game of life' editor/simulator in assembler that runs a 76*40 (fully visible) world at a decent speed which I'm quite proud of :) Happy times.
I haven't seen a PET in decades but I first learned on a PET 4000 series in grammar school back in like 1980. Big chunky keys, and the monochrome screen, and a whole room filled with them. Great times. Funny enough the strongest memory I have of PETs from that era was all the black fuzz sticking out around the rim of the monitor.
@@NeilRoy Or the VIC-20 character set. Since I had both a VIC-20 and C64 back in the day, one of the things I did was copy the VIC-20 ROM at $8000 [i.e. the character set] to disk so I could use it on the C64, since dark text on a light background using the VIC-20 character set looks better than dark on light with the C64 set, even though the VIC-20 set was horrible for light-on-dark text on a TV set.
Or just copy the set from $D000-$D7FF to let's say $3800 and then correct the characters with some AND work. Like C=+N ($3B28-$3B2F) needs AND #1, C=+G ($3B50-$3B57) needs AND #128 etc.....
Seeing the smooth scrolling on the PET at the beginning of this video was pretty crazy. It's cool to learn how you did it and used the character set to give the illusion of smooth scrolling. It's clever stuff like this that makes old computers fun imo.
I remember a machine code horizontal scrolling routine for the CBM, back in the day, probably came with some magazine Scramble game... teachers said it wouldn't work on the VIC-20. What did they know - it did. Wrote a scrolling banner text program that used this routine, and took characters from the map and enlarged them. There was another good MC routine that instantly inversed the entire screen. Good for explosions.
Another great video, and such a delight to watch. It inspired me to implement something similar from scratch (but with custom, 1-pixel line width character set, to avoid the C64 problem described at 8:10). Back in the 80s the ZX Spectrum guys used similar tricks with custom character sets to implement smooth scrolling (or just smooth movement of software "sprites"). Pretty much all 8-bit computer users had to do the same, except of course we, the C64 guys, who could simply use hardware sprites and look down at the rest of the 8-bit world who couldn't do the same. For long banners, however, even C64 guys should use something similar, or sprite multiplexing. Speaking of multiplexing, I think it deserves at least one video, Robin.
Now that was cool. And here I thought I was an adolescent genius making a smooth progress bar type "animation" on a PET in highschool. You are the master, for sure.
Back in the 80s I programed something similar that made it look like a portal opening and closing on the PET screen for a game I wrote back then. I'll send a copy over IF I can find it.
Very clever, Robin! When I first saw the video, I thought that you can't do this with the standard video hardware and was intrigued. I'm currently writing a PET scroller space game, but am having to shift the star field background and earth one character at a time. At the right speed it doesn't look too bad and uses a parallax effect to give the feel of depth.
Cool, I'd love to see your game when it's done! Shifting a full character at 60 Hz (matching the vblank rate) looks perfectly smooth, but unfortunately it will only stay on screen for 40/60 = 2/3 of a second :) Or if you could make something out of the quarter character graphics and shift them half a character at a time, then that could stay on screen for 80/60 = 4/3 of a second.
@@8_Bit - Thanks for the advice, Robin. BTW, I haven't seen you mention CBM prg Studio when you talk about Commodore development. This IDE is just so amazing. It's go the lot, sprite and screen designers, loads of excellent tools and just about all the CBM machines are targeted. It's free too! I'll send over a link to my game and the code, when it's a bit more playable :-)
1:00 Anthony Crowther as you rightly mention was a prolific games writer for the C64 for companies like Alligata, Quicksliva, Gremlin. Its interesting your video is about smooth scrolling since Tony Crowther's games were among the first to feature silky smooth multiple field scrolling, games like Loco, Suicide Express, Potty Pigeon, Gryphon and they also featured excellent tunes many of which he also wrote or adapted himself.
When I see these examples of creativity within the limitations of the 8-bit hardware I think the word hacker as the best meaning for it (contrary to what mass media popularized and gave the word a bad reputation)
I remember a "space invaders" game on the PET that used this for the player's gun at the bottom of the screen. It may have come from a "CURSOR" tape, if memory serves.
Really neat seeing how this effect was done. Going to have to play around with this at some point, perhaps playing with the vertical set of these characters. I originally thought I saw a small optimization where the convert table could be placed in zero page since it was so sparce, but then I checked my cycle count table and found that surprisingly LDA n,X and LDA nn,X both take 4 cycles (nn just takes 1 more byte). Though LDA nn,X will add a cycle if nn+X crosses a page boundary. So perhaps aligning convert to a page boundary could still save a few hundred cycles in that loop if convert isn't already close to one.
I wrote a suite of Hires graphics routines in assembler for the C64 using a PET! Tricky but I managed toi fully debug on the PET and the worked first time on porting to the C64.
In my school we had Apple II's and one PET (I think the same model as yours), and when you were typing just now on the PET keyboard it reminded me of something: The quality of the PET keyboard was much better than the C64. It had a very "solid" feel to it. Atari 8 bits (at least the early ones, not the 400!) had excellent keyboards too. Anyway, great video and I too did not know that there were duplicated characters in the C64's character set, though the reasons make sense. Custom character sets could be made for the C64 of course, but a little bit more work.
Yes, the PET keyboards are very good quality and are very solid. Later Atari keyboards such as the XE series are terrible, as they used a membrane, but yes I think the 800 and 800XL keyboards were good. My 130XE barely works and will need work. I'm pretty happy with the C64 keyboard as it just keeps on working pretty reliably, but it's true it doesn't feel as solid as the PET.
@@8_Bit What would you say is the Achilles heel of old 8 bit computers? The thing that causes them not to work anymore 10 or more years down the road? Is it busted/leaking capacitors? I see that ALL THE TIME on old retro repairing channels like Jan Beta's and Adrian Black's channel. If it weren't for that I think many of those old systems would keep on going for a lot longer. Oh, and internal clock batteries (leaking) too in some cases.
In TMP you can also use: .byte "1","0","3","7" instead of: .byte $31,$30,$33,$37 See: turbo.style64.org/docs/turbo-macro-pro-tmpx-syntax. Sometimes that can make one's source code a tiny bit more easy to read. :) P.S. Thanks for another excellent video to learn something about Assembly programming. I especially appreciate that you develop *for* the C64 *on* the C64. Most other RU-vidrs program on a modern PC/Mac for this 80's system. Takes all the nostalgia out of it if you ask me. Brrrrrr.
Good point re: .byte "1" etc! And yeah, when I was starting this channel I was checking out what was being done for C64 development on RU-vid and was disappointed to just see captures of PC desktops. It just wasn't interesting to me. Of course, emulators are a fine tool (I used one for a lot of research for my recent Ninja episode), and some of the information in those videos was still good, but it didn't bring back the fun nostalgia. Thanks for the comment.
@@8_Bit Wat's also very nice about your channel is that the video's are relatively short and well researched/practiced. Some YT video's are long and comprise a large and very complicated topic. Some mumble a bit over typing in code for 40 minutes where a rehearsed video might take 20 mins. Your channel puts the fun back into (Assembly) programming. P.S. A few pseudo-ops do not work in TMP but only in it's cross-assembly version: TMPx. See: turbo.style64.org/docs/portability-considerations-re-syntax. The most handy one that's not supported by TMP is .binary to include binary data from an external file, like bitmap data, character set, etc. So I hate to admit it: but a cross assembler does have added value. Grrrr. P.S.2 Another great place for us Commodore lovers: www.lemon64.com/forum. I'll stop harassing you now. ;-)
Since they're into retro computers, and they are bringing a PET, I wonder if they're also going to bring a Sun along for the party too? I think a nice Sun 3/60 would be a nice machine at a wedding. They could say they had a Sun together out of wedlock.
Yes, definitely possible. In fact, it now occurs to me that I probably could have done that in the "3 into 1" editor near the beginning of the episode and possibly explained it that way too! Oh well :)
I like the use of built-in characters to achieve smooth scrolling. Do you think the couple would appreciate a program that included contributions from other well-wisher Commodore enthusiasts as well? >:*3 I was thinking it might be interesting to have a routine scroll the inverse single-vertical-pixel characters between the blocks of the letters, and also perhaps create a horizontal striping effect by, after waiting for raster, using delay loops to count scan lines and selectively blanking or unblanking the display at various times. Alternatively, if you're only using the middle portion of the screen and don't need to display any "normal" text, I think you could set the CRTC to show four lines per character instead of 8, double the programmed value for total lines per frame, and adjust the number of lines before vsync to yield a roughly-centered display; doing this would double the vertical resolution.
If you look at Manic Miner it used pre shifted sprites. So the main character was 2*2 character cells in copies shifted 0,3,4,6 pixels - you can bake the animation into the pre shifting. Storing that would take 4*4=16 characters, but you need left and right versions which takes you to 32. You could just about do that on a PET using pure character graphics. Each moving object would need 32 chars for all the pre shifting. Assume one main character and one enemy that's 64 chars. And you've still got 64 chars for the background objects. I've got no idea if Pet games did this, but it looks like it would work.
Excellent solution to a problem. I was always unsure of how the BMI and BPL and other branch commands could be used without the CPY or CPX before them. My thinking is how does the CPU know which register you are comparing when it goes below 0? I assume something is set by the preceding DEX or DEY.
If you have a copy of the C64 Programmer's Reference Guide (or download it from archive.org), check out page 242 for the DEX instruction. In the top right corner there are check marks under the N (negative) and Z (zero) flags. Each instruction has that little chart to show what processor flags (if any) are affected by the instruction. The flags are valid only until another instruction changes them, so they generally should be tested with the desired branch instruction immediately after. You can also save and restore the processor status with PHP and PLP.
It's certainly possible but it would be a) less flexible (it'll scroll any "bitmap" currently, not just pre-defined characters) b) less readable since only 5 (or part of 6) characters could be seen on screen at a time (40 columns / 8 = 5) c) would limit the message to ~22 characters because of other current constraints (256 / 8 = 32 characters, with 5 blank on each end) d) more code :) While editing the video I think I did figure out ways around most of these problems but it would be significantly more work. Maybe I'll come back to it in the future, or someone else will do it first :)
@@8_Bit hey Robin I'm certainly not trying to make more work for you :) Actually I thought it would be *less* code (in terms of resulting binary) but I see what you mean, much more logic. It's got me thinking. Anyway please feel no pressure I idly pondered if it would have been less overall work to reuse the characters already defined for the source bitmap and now I can see that it would not! P.S. love the videos as always ☮️
19:32 I thought I understood this but maybe not. At $801 you'll have the pointer to the next line number but why do you need three bytes at the top (.basicend) and not two?
The first zero byte indicates the end of the line of BASIC, and then the next two bytes are the 16-bit pointer to the next line of BASIC. If this is $0000, it indicates the end of the program.
0:05 Okay, you're using full characters. Commodore -wasted- invested a large number of character codes into covering every possible position of vertical and horizontal lines, I guess to allow for high-precision bar graphs on a machine that doesn't have hi-res graphics. They can also be used for smooth-scrolling blocky text. 0:43 Everyone should use ISO date format, 2020-05-29. If it were on the 6th of May, it would be hard to guess what 06.05.2020 means. Most people would show up a month late. 2:33 Dark blue doesn't have a very good contrast with a black background. 8:10 They probably shouldn't have doubled up the vertical line on char 103 since you'd normally use that by placing it next to some other character. The pixel doubling also makes the maze produced with CHR$(205.5+RND(1)) a little jagged. Of course, you can redefine the characters where needed on the C64 and have plenty of memory left over. 8:42 The VIC-20 also used the PET characters, which wasn't a problem since the VIC's pixels were almost twice as wide as the C64's. 16:51 ".ifeq" doesn't sound like a good name for a boolean operator. It makes a little more sense with BEQ, since that will normally follow a CMP. ".ifz" might be a better name, if not ".ifnot". Does TMP have a ".else" directive? That would make your code cleaner. 19:33 Why WOULDN'T you want the BASIC stub? 23:19 In this case, looping backwards with BPL doesn't make it much faster since the loop already takes so many clock cycles that saving a two-cycle comparison is only a small-percentage gain. 30:57 256 bytes on a machine that has at least 32K bytes isn't that wasteful. Sometimes I use lookup tables of 64K words on machines with 2 GiB per processor since that's only 0.02% of the available RAM.
I prefer YYYY-MM-DD myself too, but it seems this format is common in much of Europe where the wedding is taking place. They provided the text and I didn't argue :) It's funny how I don't notice the poor contrast while I'm recording (whether it's the default C64 colours, or this default blue-on-black in this editor) but yes, it's not optimal. If I use this editor in a video again hopefully I'll remember to change the colours. Unfortunately, no .else in TMP and yes, that would have been nicer. The reason for not including the BASIC stub during development is that after assembly, TMP only offers a "Start" (S) option which JMPs to the assembly origin, which causes the BASIC stub to be executed as object code, and usually causes a crash. So either I make the stub optional, or I put a JMP START before the stub, and then have to remember to delete it later.
@@8_Bit From en.wikipedia.org/wiki/Date_format_by_country the DD-MM-YYYY is by far the most common date format (parts of Europe, all Latin-America, all Africa, parts of Asia)
@@MattKasdorf It is from an algorithmic pov, but you cant change that in the majority of countries around the world based on that fact, because the DD-MM-YYYY format predates computers and thus people base their lives on ancient custom not pragmatic sorting advantages
The stutteryness gives it a Windows-like look, heh. Couldn't you have moved the character ROM into RAM and fixed the pixel issue though with a small custom utility though?
First question: I noticed you didn't have a "closing" CLI after setting the disable interrupt with SEI. Is it not necessary to reenable it? Or is it not needed for this scrolling banner program? It seems like so far, from what I've been reading, it's supposed to be reenabled at some point. Also, I've modified the program so much now, that I'm not sure why it's not working and even what all I've done. But mainly I took out the test for the PET, and since I only wanted it to run on the C64 emulator, I didn't think that would be an issue.. My next question is based on some assumptions on my part: I'm thinking those .IF statements are specific to that Assembler you are using. I don't see a corresponding set of commands in CBS prg Studio. Also, I don't see any mention of .block and .bend in CBM prg Studio, and you didn't mention what those do in your video, so I have no idea how to even approach that in fixing this. Do you know what the corresponding .IF and .ENDIF syntax would be for other assemblers? What about .block and .bend? If those are too involved, I guess I can try finding an add-on for the VICE emulator -maybe?- and see if I can do it that way. And IF that's an option, do you have this program available (the assembly one in your video) so I don't have to reenter it again in completed form (I modified it). It's kinda hard piecing together some of these longer programs when the video doesn't show one contiguous listing and jumps around a bit.
This program has no need of interrupts, so it's fine leaving them disabled with the SEI. When the computer is reset or power cycled then they'll automatically be re-enabled. .if and .endif are conditional assembly blocks. The code inside the .if block only gets assembled if the statement is true. .block and .bend mark a local label area which allows label re-use. Usually labels are global, meaning there can only be one occurrence of any given label in the whole program. But inside a .block you can re-use labels which is handy for common labels like "loop" etc. Sorry I don't know much about CBM prg Studio but that should be enough info to find the equivalent in the documentation.
For sure, it's just a few lines of code anyway :) But note that it won't do anything on earlier PETs which have the small 9" screen. That's a feature of the later PETs with the CRTC chip, that are only in PETs with 12" screens as far as I know.
The badge on the top, and model tag underneath both just say "Commodore 64" even though the box it was sold in says "64C". So I don't feel too bad about not being specific :)
Hm... Wonder if my super HI-RES 8032 could do something like this... Then it would actually do something cool and kinda "useful" in the time of my ownership 😁😉.. As my dual diskdrive doesn't work and I have no software on datasette it has only been doing simple 10 print "XXXXX" 20 GOTO 10 and such... what a pitiful old age
@@8_Bit Thanks for answering and keep up the good work.. TBH I have a bad habbit of commenting before watching video to the end like in this case.. You are absolutely right.. SD2PET is now on my wish list 😉.. I have a bad hunch though that it some day will turn on die with either a BANG or PUFF.. but so far I have luckily been proven wrong .. In my country we also had the imported UK C64 magazines (my preferred magazine was Zzap!64) in selected "international" kiosks / bookshops (the kind you find at central transport hubs etc) even when the future was no longer 8-bit.. The magazines were very well made with very exciting visuals.. and most often came bundled with exciting promos, game-demos and even sometimes full titles (afair always on tape)
That's pretty cool, however I don't ever see these "computers" having any real applications outside of doing gimmicky things like this. They looks fun for hobbyists, but I just don't see them having any real long term impact on society & business
“When wireless is perfectly applied the whole earth will be converted into a huge brain, which in fact it is, all things being particles of a real and rhythmic whole. We shall be able to communicate with one another instantly, irrespective of distance. Not only this, but through television and telephony we shall see and hear one another as perfectly as though we were face to face, despite intervening distances of thousands of miles; and the instruments through which we shall be able to do his will be amazingly simple compared with our present telephone. A man will be able to carry one in his vest pocket.” - Nikola Tesla (1926) What a dope - nobody wears vests anymore!
I was disappointed you didn't write a routine to enter a string and then look it up in the PET character ROM in order to produce the character map, or avoid having to create a map at all if speed wasn't an issue. 🇨🇦
It'd be possible, of course, but giant 8-character-wide letters are a lot less readable because only 5 full characters would fit on the 40-column screen. At any moment you could only see things like "MARRI" or "5.29.", or 4 characters and fractions of the two surrounding it.
In order to fit more characters, instead of reading from ROM you could in principle define your own font, e.g. 4x6 or 6x6 pixels as long as it is fixed width. I've made a few C64 intros with that kind of font, using the chunky 4x4 subpixels and of course the smooth scrolling, while you have to use full width characters and simulate scrolling with graphics symbols. Now that I think of it, the custom font could be combined with another table that defines the width of each character, enabling proportional banner fonts in order to fit even more characters. Probably that is beyond the scope of this example but if you're planning to make a living on producing scrolling banner texts, it could be a worthwhile addition for V2.
