I just ❤this video. But you know, maybe the VIC-II can run at 2 MHz and maybe it can't, I don't know about that. In any case, the real reason for this FAST/SLOW feature, is that it shares its screen memory with the CPU, just like on the C64. So, the computer actually runs at 2 MHz all the time, but is multiplexing the RAM-access between the CPU and the VIC-II. One could be tempted to say that each get 1 MHz, but that is not exactly the complete story, since their access is obviously interwoven. This is also why the CPUs clock signal is generated by the VIC-II chip. Going into fast-mode doesn't turn off the VIC-II, because that would just produce a black picture regardless of the border color. No, it only disables the multiplexing and thereby the VIC-II's connection to the RAM (it is still producing a video signal), practically turning the entire 40 column screen into one big pixel. It also hands the full 2 MHz over to the CPU. Although, this doesn't happen when you do the equivalent "1-pixel-poke" on the C64, where for some reason the CPU remains at 1 MHz regardless. But on a C128 in C64 mode this actually still happens when using this poke... which is a bit strange. - The VDC doesn't have to share memory with the CPU, since it has its own dedicated VRAM. But that also means that the CPU can't write directly to the VRAM. Everything has to go through the VDC. - The wedge C128s were all sold with 16KB of VRAM, some of the C128Ds came with 16KB and some with 64KB, and all of the C128DCRs had 64KB as default. Or in other words, when counting RAM, you could say that every C128 had at least 144KB and at most 192KB by factory default. - You can today get a fairly cheap daughter-board to install into you wedge/C128D to upgrade it to 64KB without soldering. You just take the VDC chip out of its socket, put the daughter-board in, and place the VDC into the socket on top of the daughter-board, and then the on-board 16KB gets disabled and replaced by the 2×32KB chips on this daughter-board. - This obviously gives your C128 more RAM for 80 column graphic screen modes. But you will also need to put a Basic v8.0 "Internal Function ROM" into the C128s U36 socket, if you want BASIC to support them. - Whether Pascal 128 supports these 64KB 80 column graphic screen modes or not... I have no idea, and would be very interested to know if it does. I love Pascal, but didn't begin programming in it until I got my Amiga 500. So, I find the idea of Pascal on my C128 very intriguing.
Thank you very much for this comment. I learned a lot from this, and I think others will as well. I only ever used the C128 to go into C64 mode to play games when our family had one when I was an early teenager. I had my own C64, but back then that ran my BBS, so I used the C128 to play games that users uploaded to it to ensure the BBS had more up time. I think we only had the 128 for a year (if that long) before we traded up to an IBM PC XT. I had no idea how much depth there was to the 128 until I started exploring software of the 1980s this past few months.
@@fuzzybad Well, the VIC-II is definitely receiving a 2MHz clock signal, since it otherwise obviously wouldn't be able to pass it onto the 8502 when in fast-mode. Again, the VIC-II's video signal doesn't get disabled. Because if "you" were to probe it with an oscilloscope while in fast-mode, you will undeniably still find both horizontal- and vertical- sync signals imbedded inside the composite-video or the luma/chroma (S-Video) signals, and also see the border color covering the entire screen within the timing. So, it is clearly still doing its hardwired pixel-counting. If we flicker the border color really fast when in fast-mode using machine code, we also still see lines or elongated blocks of colored pixels on the screen. Many C64 turbo-loaders and demos also make use of this effect for indicating that they haven't crashed, but are still doing stuff. Although only really gaining the 2MHz speed boost when running on a C128 in C64 mode. Nope, on an electronical level the VIC-II is clearly still doing everything "as usual" during fast-mode, except receiving pixel-data from its designated screen-area in RAM. Its connection to the data-bus has simply been severed. So, it just defaults back to the $D021 (53281) border color nibble, since that's all the color information it still has access to. - If you were to force me to go hunting for the Major design flaw in the Commodore C128, this wouldn't even remotely qualify. Especially since it only really seems like a slightly improved (as in higher speed) handed down "genetical quirk" from the C64. Nope, think about it for a moment, here is a computer with 2 CPUs: a MOS 8502 and a Zilog Z80. Yet, at any given moment one of them is sitting comfortably in its office armchair with its feet up on the table, idly lollygagging the day away puffing on a big stogie, while the other is carrying all the workload. Granted mostly the Z80, although not that this is really any of the computers fault. - Now, imagine the sheer "Unlimited Power!" (Emperor Palpatine voice) we would have had, if both were to rule the galaxy like father and son... ehm... sorry, I meant share the workload with some wicked (some may even claim unnatural) parallel processing. The no. 2 "Captain" design flaw 😄 of the C128, would be that according to Commodores marketing division, likely the predecessors to the Sirius Cybernetics Corporation, who was the first against the wall when the revolution came in 1994 (yeah, I wish). Anyway, according to them, the C128 is upgradable to 512KB of RAM. - Well, if "you" were to MacGyver some piggyback-solution on top of its internal RAM chips or maybe another daughter-board, you should be able to squeze it up to 256KB. But 512KB?... not unless you drill a hole in Bil Herd's MMU (Memory Management Unit) chip, to find its 19th. address-bus pin (A18), which is in there on the dye, but just not drawn out onto an exterior pin. - Yeah, I think Homer Simpson said it best when he loudly proclaimed: DOH!! BTW. The GeoRAM and the REU cartridges behave more like RAM-disks than actual memory expansions. Which do have their perks, especially in case of the REUs DMA features, like the C64 port of Sonic The Hedgehog.
Excellent presentation! You are a master educator. If Abacus Software had hired you to promote their products through TH-cam videos, they would've sold a million copies.
Excellent content, your entire back catalog is now in my watch queue! I hope you cover some of the C environments next. It would be cool to do a side by side with Pascal. I've only ever looked at these CBM machines as either BASIC or ASM machines, now I wish I'd given more attention to these programming environments a long time ago.
My first computer was a Commodore 64 in 1986. I learned BASIC programming with it and even did a very small amount of machine code (usually through POKE or DATA block statements as I didn't have a 6502 Assembler). In my high school computer class, the teacher could tell I was bored using Apple II BASIC, so he let me play with PASCAL. I *hated* it! I never understood the need to predefine variables, etc, and then I saw this video! Not only is that good programming practice but PASCAL is *compiled*! And, it even supports the Records data structure that is the forebear of modern day objects and classes. My friend and I were going to upgrade to the 128D in 1987 but ended up purchasing Amigas late that year instead. I'll tell you one thing, as a developer for work, if I ever get upset with modern day IDEs or text editors, I'll refer back to this video to remember what a pain in the butt line numbers were! :) Great video!!!
Besides the self-taught BASIC, Pascal was the first language I properly learned in college in the mid 90's. I never knew there was a Commodore version. Cool!
I'm a little surprised they didn't use a custom character set to make the left arrow look like an underscore. I think they did that with their Super C 128, but of course doing C on a computer without curly brace characters probably required a little more innovation.
I remember that Turbo Pascal had a RANDOMIZE procedure to seed the random number generator, otherwise you get deterministic output. I wonder if that's standard pascal supported by Super Pascal.
Nice intro, good to see that working all these years later. Watching that it dawned on me that I do not remember really using that compiler much, even though I bought it at the time. I checked on my shelf of C128 manuals, and sure enough it was there, but, right next to Oxford Pascal 128. That being the reason I hardly used Super Pascal. I think the clunky editor, and line numbers(!), put me off. The Oxford version just had a much nicer "feel" IMHO running with a proper editor, mixed case source code etc.
One other comment, this is really a tutorial on Super Pascal for the C128. An excellent one, but you might want to change the title. You might want to do a 5 minute review on Super Pascal too on how it compares to the old Borland Turbo Pascal.
I never used anything like this back in the day, it was all turbo assembler. It’s neat, but wow the UX of repeated edits is awful, having to shift lines and so on. A real screen editor would make this a lot more useful. Cool video!
Wow, thank you! The story of the C128 is so sad. It is a shame that most users just used the GO64-Mode and that the software library was so small. This software could have turned the fate of the C128 around.
Grate video! Hmm. I was hoping the C128 version would have better editor. Oh well. Also the speed of program execution is not very impressive. 5000 loops of simple +1, even if integer is 16 bit, and needs to be emulated by few 8-bit operations, plus equality check and jump, that is maybe what, 10-15 instructions per iteration, maybe 20 if the compiler is really bad? And X should be in some register or page zero maybe. At 4MHz, I would expect this to finish maybe in maybe 25 milliseconds. I wonder if startup of the program is the bottleneck, or if compiler and optimizer is really that poor. Might be worth dissembling things. Oh. I see, it is using VIC-II, not the Z80. That is pretty obvious, as it is just a port from C64 compiler.
The RAM disk is a real game changer compared to the C64 version, and the 80-column mode is also a welcome luxury. Too bad the C64 version didn't support REUs...
![ว้าว!ลุงบีมแบกทองมารับขวัญหลานกันยกบ้าน [cc] แดนแพทตี้ SS2 | EP.49 |](http://i.ytimg.com/vi/Osihq1OAs-4/mqdefault.jpg)
I just ❤this video.
But you know, maybe the VIC-II can run at 2 MHz and maybe it can't, I don't know about that. In any case, the real reason for this FAST/SLOW feature, is that it shares its screen memory with the CPU, just like on the C64. So, the computer actually runs at 2 MHz all the time, but is multiplexing the RAM-access between the CPU and the VIC-II. One could be tempted to say that each get 1 MHz, but that is not exactly the complete story, since their access is obviously interwoven. This is also why the CPUs clock signal is generated by the VIC-II chip. Going into fast-mode doesn't turn off the VIC-II, because that would just produce a black picture regardless of the border color. No, it only disables the multiplexing and thereby the VIC-II's connection to the RAM (it is still producing a video signal), practically turning the entire 40 column screen into one big pixel. It also hands the full 2 MHz over to the CPU. Although, this doesn't happen when you do the equivalent "1-pixel-poke" on the C64, where for some reason the CPU remains at 1 MHz regardless. But on a C128 in C64 mode this actually still happens when using this poke... which is a bit strange.
- The VDC doesn't have to share memory with the CPU, since it has its own dedicated VRAM. But that also means that the CPU can't write directly to the VRAM. Everything has to go through the VDC.
- The wedge C128s were all sold with 16KB of VRAM, some of the C128Ds came with 16KB and some with 64KB, and all of the C128DCRs had 64KB as default. Or in other words, when counting RAM, you could say that every C128 had at least 144KB and at most 192KB by factory default.
- You can today get a fairly cheap daughter-board to install into you wedge/C128D to upgrade it to 64KB without soldering. You just take the VDC chip out of its socket, put the daughter-board in, and place the VDC into the socket on top of the daughter-board, and then the on-board 16KB gets disabled and replaced by the 2×32KB chips on this daughter-board.
- This obviously gives your C128 more RAM for 80 column graphic screen modes. But you will also need to put a Basic v8.0 "Internal Function ROM" into the C128s U36 socket, if you want BASIC to support them.
- Whether Pascal 128 supports these 64KB 80 column graphic screen modes or not... I have no idea, and would be very interested to know if it does.
I love Pascal, but didn't begin programming in it until I got my Amiga 500. So, I find the idea of Pascal on my C128 very intriguing.
Thank you very much for this comment. I learned a lot from this, and I think others will as well.
I only ever used the C128 to go into C64 mode to play games when our family had one when I was an early teenager. I had my own C64, but back then that ran my BBS, so I used the C128 to play games that users uploaded to it to ensure the BBS had more up time.
I think we only had the 128 for a year (if that long) before we traded up to an IBM PC XT. I had no idea how much depth there was to the 128 until I started exploring software of the 1980s this past few months.
The VIC-II unfortunately cannot run at 2MHz. When you enable fast mode on the 128, the 40-col display is disabled. Biggest flaw of the system imo
@@fuzzybad Well, the VIC-II is definitely receiving a 2MHz clock signal, since it otherwise obviously wouldn't be able to pass it onto the 8502 when in fast-mode.
Again, the VIC-II's video signal doesn't get disabled. Because if "you" were to probe it with an oscilloscope while in fast-mode, you will undeniably still find both horizontal- and vertical- sync signals imbedded inside the composite-video or the luma/chroma (S-Video) signals, and also see the border color covering the entire screen within the timing. So, it is clearly still doing its hardwired pixel-counting. If we flicker the border color really fast when in fast-mode using machine code, we also still see lines or elongated blocks of colored pixels on the screen. Many C64 turbo-loaders and demos also make use of this effect for indicating that they haven't crashed, but are still doing stuff. Although only really gaining the 2MHz speed boost when running on a C128 in C64 mode.
Nope, on an electronical level the VIC-II is clearly still doing everything "as usual" during fast-mode, except receiving pixel-data from its designated screen-area in RAM. Its connection to the data-bus has simply been severed. So, it just defaults back to the $D021 (53281) border color nibble, since that's all the color information it still has access to.
- If you were to force me to go hunting for the Major design flaw in the Commodore C128, this wouldn't even remotely qualify. Especially since it only really seems like a slightly improved (as in higher speed) handed down "genetical quirk" from the C64.
Nope, think about it for a moment, here is a computer with 2 CPUs: a MOS 8502 and a Zilog Z80. Yet, at any given moment one of them is sitting comfortably in its office armchair with its feet up on the table, idly lollygagging the day away puffing on a big stogie, while the other is carrying all the workload. Granted mostly the Z80, although not that this is really any of the computers fault.
- Now, imagine the sheer "Unlimited Power!" (Emperor Palpatine voice) we would have had, if both were to rule the galaxy like father and son... ehm... sorry, I meant share the workload with some wicked (some may even claim unnatural) parallel processing.
The no. 2 "Captain" design flaw 😄 of the C128, would be that according to Commodores marketing division, likely the predecessors to the Sirius Cybernetics Corporation, who was the first against the wall when the revolution came in 1994 (yeah, I wish). Anyway, according to them, the C128 is upgradable to 512KB of RAM.
- Well, if "you" were to MacGyver some piggyback-solution on top of its internal RAM chips or maybe another daughter-board, you should be able to squeze it up to 256KB. But 512KB?... not unless you drill a hole in Bil Herd's MMU (Memory Management Unit) chip, to find its 19th. address-bus pin (A18), which is in there on the dye, but just not drawn out onto an exterior pin.
- Yeah, I think Homer Simpson said it best when he loudly proclaimed: DOH!!
BTW. The GeoRAM and the REU cartridges behave more like RAM-disks than actual memory expansions. Which do have their perks, especially in case of the REUs DMA features, like the C64 port of Sonic The Hedgehog.
Excellent presentation! You are a master educator. If Abacus Software had hired you to promote their products through TH-cam videos, they would've sold a million copies.
*Abacus produced some really good compilers and software tools*
They also had some really nice books. One was on writing adventure codes.
I loved their COBOL-128. I used this SuperPASCAL back in the day. Great memories.
Fantastic video! loving the C128 content! 👍
Excellent content, your entire back catalog is now in my watch queue!
I hope you cover some of the C environments next. It would be cool to do a side by side with Pascal. I've only ever looked at these CBM machines as either BASIC or ASM machines, now I wish I'd given more attention to these programming environments a long time ago.
My first computer was a Commodore 64 in 1986. I learned BASIC programming with it and even did a very small amount of machine code (usually through POKE or DATA block statements as I didn't have a 6502 Assembler). In my high school computer class, the teacher could tell I was bored using Apple II BASIC, so he let me play with PASCAL. I *hated* it! I never understood the need to predefine variables, etc, and then I saw this video! Not only is that good programming practice but PASCAL is *compiled*! And, it even supports the Records data structure that is the forebear of modern day objects and classes. My friend and I were going to upgrade to the 128D in 1987 but ended up purchasing Amigas late that year instead. I'll tell you one thing, as a developer for work, if I ever get upset with modern day IDEs or text editors, I'll refer back to this video to remember what a pain in the butt line numbers were! :) Great video!!!
Good Skill! Good Explain! Thank so much!
Besides the self-taught BASIC, Pascal was the first language I properly learned in college in the mid 90's. I never knew there was a Commodore version. Cool!
The CP/M Pascal for the C128 was superior.
I'm a little surprised they didn't use a custom character set to make the left arrow look like an underscore. I think they did that with their Super C 128, but of course doing C on a computer without curly brace characters probably required a little more innovation.
I remember that Turbo Pascal had a RANDOMIZE procedure to seed the random number generator, otherwise you get deterministic output. I wonder if that's standard pascal supported by Super Pascal.
Nice intro, good to see that working all these years later. Watching that it dawned on me that I do not remember really using that compiler much, even though I bought it at the time. I checked on my shelf of C128 manuals, and sure enough it was there, but, right next to Oxford Pascal 128. That being the reason I hardly used Super Pascal. I think the clunky editor, and line numbers(!), put me off. The Oxford version just had a much nicer "feel" IMHO running with a proper editor, mixed case source code etc.
Very nice video, thanks.
One other comment, this is really a tutorial on Super Pascal for the C128.
An excellent one, but you might want to change the title.
You might want to do a 5 minute review on Super Pascal too on how it compares to the old Borland Turbo Pascal.
I did so much Pascal programming in college, mainly on DEC VAX terminals, if I recall correctly. I did zero Pascal programming after that.
I never used anything like this back in the day, it was all turbo assembler. It’s neat, but wow the UX of repeated edits is awful, having to shift lines and so on. A real screen editor would make this a lot more useful.
Cool video!
Wow, thank you!
The story of the C128 is so sad. It is a shame that most users just used the GO64-Mode and that the software library was so small.
This software could have turned the fate of the C128 around.
Cool.. I had and have Commodore 128, but basically just programmed using its built-in BASIC.
👍👍👍👍👍👍
You're driving me nuts using the left-arrow char as a replacement for underscore lol
Would be great if you gave a tour of the recently re-discovered COBOL-128 from Abacus Software. It's a step up from the C64 version.
Cobol is something you do because you get paid to do it. If not - stay away and never ever admit you know how to code in Cobol
I love this idea... Stay tuned..
Can you set random to be based on clock in this system?
Grate video!
Hmm. I was hoping the C128 version would have better editor. Oh well.
Also the speed of program execution is not very impressive. 5000 loops of simple +1, even if integer is 16 bit, and needs to be emulated by few 8-bit operations, plus equality check and jump, that is maybe what, 10-15 instructions per iteration, maybe 20 if the compiler is really bad? And X should be in some register or page zero maybe. At 4MHz, I would expect this to finish maybe in maybe 25 milliseconds.
I wonder if startup of the program is the bottleneck, or if compiler and optimizer is really that poor. Might be worth dissembling things.
Oh. I see, it is using VIC-II, not the Z80. That is pretty obvious, as it is just a port from C64 compiler.
The RAM disk is a real game changer compared to the C64 version, and the 80-column mode is also a welcome luxury. Too bad the C64 version didn't support REUs...
Ah cool a record is Pascal’s struct