I love these extra-nerdy deep dives! I bet this episode took a long time to make. Thanks!

Base 12 is convenient because it's evenly divided by 2,3,4, and 6 as well as 12. 60 is the smallest base that adds 5 to the mix. So those were logical choices. And today we have 60 seconds in the minute and 60 minutes in the hour or angular degree. 360 degrees in a circle is a nice round number in base 60 and close to the number of days in the year. A largely unappreciated side effect of the 24-hour day is the order of the days in our week. Originally, the seven Greek "planets" (everything visible to the naked eye that moved against the stars: Saturn, Jupiter, Mars, the Sun, Venus, Mercury, and the Moon) were assigned to hours instead of days. The assignment ran in the above order, from slowest to fastest motion through the night sky. When ancient timekeepers switched from hours to days, they named each day after the planet governing its first hour, and since 24 mod 7 is 3, successive days had names separated by 3 in the above list: the Sun, the Moon, Mars, Mercury, Jupiter, Venus, and Saturn. The associations between the planets and day names are more obvious in the Romance languages; in English, only Sun=Sunday, Moon=Monday, and Saturn=Saturday make sense directly. But that's because Old English timekeepers mapped the Roman gods to their own pantheon instead of adopting the rest of the names directly. So Mars, the Roman god of war, was taken to be Tiw (Norse Tyr), whence Tiw's Day->Tuesday, and likewise down the line: Mercury->Woden(Odin)->Wednesday, Jupiter->Thor->Thursday, and Venus->Frigg(Freya)->Friday.

Thanks, yes, the true NTSC spec is as you say. However, most/all 8-bit computers and games consoles were not exactly to spec. They neither ran at exactly 59.94 (or 29.97 depending on how you're counting) Hz, and most did not generate proper odd/even interlacing video either. So I find it's both easier *and* more accurate to just talk about 60 fps video output.

@@8_Bit Yes exactly, coming from a TV background, those missing frames in the timecode was something to really check for or else for example the commercial brakes were not at the correct time and you saw bumpers coming in out off commercial brakes in the middle of the show and you got commercial brakes in the middle of a sentence... Or the a show of 1 hour was short by 108 frames and you got black on air during that time. And it was easy as flipping a switch on a VTR to be in non-drop frame mode...

@@TheBookaroo Ah, the days when commercials interrupting mid-sentence was a bug, not a feature.

I heard the field rate is exactly 60*1000/1001. Would they really have needed drop frames every so often when they could just play video back a tiny bit slower? kzfaq.info/get/bejne/aa16iLBn1anUlas.html

@@csbruce They actually dropped the frequency from 60 to 59.94 but timecode is a number attached (either in an audio extra track (LTC) or embedded in the vertical interval of an image (VITC)) so to be accurate so that an hour long show it's timecode will also be an hour long, you have to skip the numbering of frames going from 10:01:59:29 for example to 10:02:00:01 skipping 10:02:00:00 to compensate so that the timecode stays in sync with the actual duration.

It'd be a neat idea to make an unofficial "KERNAL V4" ROM that incorporates the best fixes/patches people have come up with. I'd be happy if some of my ideas made it in there, but I don't have full confidence that these patches don't have some side effect I haven't noticed. I'm happiest exploring and raising awareness about these strange quirks and if you and/or others want to pull it together with other contributions into a project that produces an alternate ROM that'd be really cool.

On the Mega65's BASIC 10, TI$ and TI are independent variables. TI$ has the current clock time (complete with colons now), while TI is the number of seconds (with fraction) since boot. Neither of them is resettable, either, which makes timing things a little more work.

The CIA's TOD clock is specifically designed for accurate time keeping, and should be more accurate than CIA timer. But I don't think there is a PAL CIA, so I don't think the TOD is accurate on PAL. I don't have PAL machine to check...

@@H2Obsession the pal version does have the cash going on at 60hz, it is used by goes for example 🙃

If Commodore BASIC supported 24-bit integer values it would make sense to just have TI be a permanent entry in the variable table pointing to the jiffy clock. But it has to be converted to floating-point, which is a pretty expensive operation to be doing 60 times a second, every second. Much more efficient to only do that when the program accesses the variable.

@@markjreed makes sense. I always thought of BASIC as this magic box that just works (especially as a kid). I never thought that much about what was in it. Especially now that I use much more modern languages these days.

Good point about the FRE() parameter. In C128 mode it refers to the RAM bank, and it's an ILLEGAL QUANTITY to pass anything other than 0 or 1. FRE(0) is space available for the BASIC program, while FRE(1) is space available for variables.

And if I remember correctly, on the B128 (80-column CBM-II machine) the 128K is split up into four 32K banks. FRE(0) returns free code space, while a parameter of 1, 2, or 3 returns free variable space for each different type: string, scalar, or array, or something similar to that.

@@8_Bit: According to the Anthology (p.43), this corresponds to how the B-series RAM banks were used, though they seem to skip bank 0. Sounds like they fill each of the four RAM banks only half-way for the B128.

POS(x) has a dummy parameter. Even on the C128 where it could conceivably use different values for the 40 and 80 column displays... Even though TI and ST are weird functions, it saves typing and bytes to omit the parentheses...

@@H2Obsession: At 4:10, Robin is talking about the FRE(x) function. On the C128, the FRE() parameter is the RAM bank.

How about fartion :-)

Hi, congratulations on getting a MEGA65! Yes, all these special symbols are shown in the C64 Programmer's Reference Guide on pages 72-74, when describing the various special Quote Mode, Insert Mode, etc. They're a bit quirky, but also quite powerful and efficient.

@@8_Bit Ahhhhh....yes, I see them now! Thanks a lot!! I was searching for them in the appendix etc. ps, the C64 core for the MEGA65 is amazing, but also the C64 mode ("GO64") in MEGA65/C65 is already quite compatible.

No. The wrap-around code will work just fine if the first constant is zero. Using 1 instead is definitely a bug. However, if you reverse the order of subtraction then the correct first constant would be 1 (because of the way CPU carry flag works. You can test this yourself by copy ROM to RAM and modify like Robin did. I guess maybe they had the order of subtraction reversed at sometime, then reversed the order, but the constant was not updated. Who knows? What is surprising is it wasn't fixed on C128.

I'm in the process of compiling a pretty comprehensive list of bugs in the kernal and basic roms. More comprehensive than any I have ever seen, really. I may publish it some day when it's complete.

@@ge97aa Great, looking forward to reading it!

On a stock C64, RAM and ROM are the same speed. On my SuperCPU accelerator for the C64 (which is unfortunately quite rare) then the RAM is a lot faster and it does copy/shadow the ROMs into RAM like the IBM clones did.

No, that would be a much more elaborate patch and the original authors didn't appear to even attempt that level of error checking. They did seem to want a numeric digit check and as it was easy to implement, I tried it :)

That's not the C128, but the term "jiffy" has been used for other subsecond intervals. The 0.01-second version shows up mostly in Linux. Microsoft file and directory timestamps count from 1601-01-01T00:00:00Z the number of 100-nanosecond periods (= one ten-millionth of a second), which are also sometimes called "jiffies".

These Commodore BASICs all have a 2 character limit on variable names anyway, so TIMOTHY gets treated the same as TI; extra letters are just ignored.

@@8_Bit Oh... well, I suppose not having touched a C64 in a... never-mind-how-long time, can excuse me for forgetting that little detail. No? Thx for replying.

Yes, I think there's a lot of uncertainty surrounding this topic; I wasn't sure about several things until I really dug into it for this video. Though now that you mention it, I didn't even talk about the AC input! Or how the system IRQ timer is set in the first place.

@@8_Bit: Also, the bulk of the C64 ROM content was just copied in a hurry from the VIC-20. The VIC used a timer configured for a 60 Hz IRQ, so that just got copied into the C64.

@@csbruce Sure, but the VIC-20 also had a PAL version. Weren't those the same other than the VIC chip itself?

@@markjreed CPU in the C64 was different too, controlled the bank switching.

The TOD in the CIAs is indeed clocked by the mains frequency in most C64 variants but the CPU interrupt is timer driver. TOD tick is derived from the 9VAC supply. If you want a less drifty time of day read the CIA registers instead of relying on TI etc. There's gotchas such as ensuring the CIA is configured for the mains frequency in your area. This isn't necessarily correct. Apparently different ROM versions didn't work it out properly, and of course you could be using a C64 intended for an NTSC country in a PAL country and vice-versa.

I was looking into this a week or two ago. Some programs just check if they're running on PAL/NTSC and assume 50/60 AC based on that. A large % of the time that is an okay assumption. However it's wrong for some edge cases, such as the SX-64 which has a 60 Hz TOD no matter whether PAL or NTSC as it has an internal 60 Hz crystal generating the signal instead of using AC. A better solution is to start a CIA timer (cycle counter) and set the TOD to 60 Hz and count the cycles it takes for the TOD to reach a certain amount of time (like a 10th of a second or whatever). Then that cycle count can be used to see if the TOD is really running at 60 Hz, or if it's too far out, 50 Hz must be right.

@@8_Bit Great, thank you!

Were you on a PAL machine? I used an NTSC C128 as my main computer for years and only very rarely noticed any flickering in the split-screen graphics modes.

@@markjreed it's fine on my ntsc machine. I was having the issue on my emulator setup. Got Robin's help with a workaround.

@@alexmcd378 Ah, emulators. I know VICE x128 in NTSC mode simply does not handle split-screen graphics; the entire text portion of the screen flashes, rendering it completely unusable. In PAL mode there's a much more minor flicker of just a scan-line or so. Which was also on the PAL machine in this video, so maybe that's accurate to the real hardware!

@@markjreed that's it exactly. If you use draw routines to cover the bottom couple rows of pixels of the graphics area, it reduces the flicker to a single row of pixels. Not ideal, but much less distracting

@@alexmcd378 Hm, adding lines to he bottom of the graphics area doesn't seem to help. I must be misunderstanding.

The CIA does get 50 or 60 Hz from AC for the TOD but to be clear (I'm not sure if you're implying otherwise or not) that's not used by the C64 for the TI or TI$ functions at all; they're driven by the system IRQ which is driven by a CIA timer interrupt set to roughly 1,000,000 / 60 microseconds. The TOD functions are an interesting and under-utilized feature of the C64 I think.

@@8_Bit I see, I did not remember that, makes sense since disabling interrupts makes TI skip counts.

Hi Magnus. Sorry I don't know anything about that game, especially since it's in German, but here's a good website with info and links to another website with a manual. You can see if it even supports a save feature: www.c64-wiki.de/wiki/Vermeer Are you playing on a C64 with a real disk? You might need to insert a blank, formatted disk to get the save to work. I'm just guessing though; let me know more of the symptoms and maybe I'll have other ideas.

I'm sorry but I don't follow. The TI variable is counting jiffies which are approximately 1/60th of a second but have nothing to do with the NTSC or PAL video standards. Jiffies are counted each system IRQ which is driven by the CIA timer interrupt which counts cpu/system cycles.

I think you're under the impression that the Time of Day source is the video crystal, but it actually comes directly from the A/C line from the power supply. Only the interrupt routine on the C128 runs from vsync, not the TOD timer itself. There should be some error involved since the interrupt and timer updates don't sync, but the error is still pretty small. The system timers make a lot of sense on the C64 and C128. The Amiga is what has me all confused, since most of those systems *DO* get the TOD source from vsync. I haven't figured out yet how AmigaOS determines whether the hardware uses a 59.94 Hz or 60 Hz timer.

TI$ is not stored in RAM, but TI is. It is at addresses $00A0..$00A2. It is big-endian, in units of 1/60 seconds. Evaluation of the TI$ variable reads the TI value and converts it to the more human-readable HHMMSS form.

@@ge97aa Thank you for your answer! But: Which routine(s) does (do) converts $00A0..$A00A2 into TI / TI$ and where can it be found in the RAM?

@@madmartigan1498 As for TI, I'm not sure what you mean by converting $00A0..$00A2 to TI, since for all intents and purposes $00A0..$00A2 **is** TI. You can get this value in an interrupt-safe manner by calling the kernal's RDTIM function at $FFDE. It returns the three bytes in the Y, X, and A registers in order from high to low. As for TI$, this is done by the routine that evaluates a BASIC variable within a BASIC expression. This routine is located at $AF28 in ROM. This routine calls another routine at $BE68 which does the actual work of the numeric conversion (incidentally, this function is also used by the routine that converts a floating point value to a decimal string). The resulting 6-character string is stored in BASIC String RAM at a location chosen by the BASIC interpreter. A 3-byte descriptor for this string is pushed to BASIC's temporary string stack (located at $19..$21) and a pointer to that descriptor is returned in memory locations $64/$65. Additionally, an interim working copy of the string will be found at $00FF..$0104, but this will be overwritten by any subsequent conversion of a numeric value to a string. I'm not sure if you are asking purely for curiosity's sake, but if you're thinking about writing code to use this built-in feature, there are a number of things you must consider. First, the routine at $AF28 starts by reading a variable name from the BASIC command buffer. This means that there MUST be a valid active BASIC command buffer pointer that currently points to the first character of the TI$ variable name. If you simply want to get the TI$ value "on the fly", I suppose you could bypass the command buffer read by instead calling into the routine at $AF48. Remember, though, that this routine is part of the BASIC interpreter, and it expects and requires a fully operational BASIC environment. Additionally, you would need to make sure that you properly deregister the temporary result string from BASIC's string stack by loading the the pointer at $64/$65 into the Y and A registers (low byte in A, high byte in Y) and calling the routine at $B6AA. This will return a pointer to the string data in memory locations $22/$23. This string should be used for your intended purpose before invoking any additional functions in the BASIC interpreter, as there is a good chance that pointer will be overwritten by the interpreter. If you DON'T want to have a full BASIC environment active (e.g. String RAM, Variable RAM, program memory, temporary string stack, garbage collector, etc.), you could just use the conversion routine at $BE68. Here's how you would do it: 1. Call the routine at $AF84 to convert TI to a 32-bit big-endian integer at $0062..$0065. 2. Store the value 0 in memory location $5E. 3. Store the value #$FF in memory location $71. 4. Store the value 6 in memory location $5D. 5. Load the Y register with the value #$24. 6. Call the conversion routine at $BE68. 7. The resulting 6-character string can then be read from memory at $00FF..$0104. Note that this method requires the use of the following memory locations, so you would have to be sure they aren't in use by other parts of your code: $0047, $005D, $005E, $0062..$0065, $0071, $00FF..$0105.

It comes directly from the 60hz AC power supply signal.

@@ImYourProblem I've done some reading since my comment and it seems that the jiffy clock comes from a CIA hardware timer and the CIA TOD real-time clock comes from the mains.

Yes, apparently the Time Of Day on the SX-64 is driven by a crystal at 60 Hz on both PAL & NTSC models instead of AC mains power at 50 or 60 Hz.

Something was definitely goin' down there.

Even in the C128 schematics the TOD pins from CIA1 and 2 are hooked up to the 9V AC. Through a Smitt Trigger and Zener and some timing circuitry. I don't have any own tools or something to do any measurements but it could well be this indeed is always 60 because you are just not changing your line phase.

Well, even though this doesn't have to do directly with the video standard, most PAL regions use 50 Hz AC power, while most NTSC regions use 60 Hz. I guess this is where the thought comes from. But you are correct, even on a PAL C64, a Jiffy is a 60th of a second. (Or close to at least, it seems to be kinda inaccurate)

​@@paulkoopmans4620 There seems to be an assumption that the TOD in the CIA has something - anything to do with TI and TI$, but it doesn't. TI is incremented as part of the main system IRQ which is driven by a looping CIA timer (cycle counter) set to approximately 1 000 000 / 60 cycles. TOD is driven by AC, but it's not used by the TI functions at all.

All CPU and video timings on the C64 and C128 are derived from a crystal oscillator of 14.31818 MHz for NTSC and 17.734475 MHz for PAL, and have nothing to do with the AC frequency. The only thing the 50 or 60 Hz AC does is drives the Time Of Day (TOD) clock on the CIA chip, but that is not the source of the system IRQ. The system IRQ is driven by a CIA system cycle counter / timer in C64 mode at approximately 60 Hz, or by the video refresh on a C128 (at 50 Hz in PAL or 60 Hz in NTSC), but none of those 50 or 60 Hz for video or system interrupts have anything to do with the AC power frequency.

These can be hardly called errors / bugs because under all practical circumstances, it all works. No one sets the time to 99:99:99 (and even then nothing explodes), or cares if TI$ is off a second when running for months.

@@NuntiusLegis Appart from hackers.

Honestly though, a lot of the bugs are CAUSED by the need to cram everything into such a small space. Add to that the fact that it was all programmed in handmade assembly... lots of very ugly hacks are used to get the job done. In a modern O/S, many of these kind of bugs would be avoided by adherence to proper coding standards and the use of MUCH better development tools.

Also, the kernal ROM is only about 6.5 kB. The BASIC interpreter is around 9.5 kB.