Nooooo this optimization of BASIC seems like something you would find in JavaScript $A = "Hello" + ""

Oh, please keep these fantastic C128 VDC vids coming! incredible, incredible work! 👍👍👍

I enjoyed the video. For the Commodore 64, I have two Basic favorites. The one that comes with the computer and the recently released Vision Basic. As a compiler is faster than Blitz and allows greater flexibility with graphics and inline assembly language programming.

In the late 80s I downloaded a copy of the Austro Speed compiler for C64 from the Quantum Link online service in the US. Insofar as I'm aware now, it was identical or nearly identical to Blitz! apart from the name, though at time I thought it was public domain software. I didn't use it a lot, as I mostly programmed in C128 BASIC, but I did find one great use for it. There was a Rogue-like RPG I really wanted to like called Telengard. It was commercial but written entirely in BASIC, and while quite good it played very slowly and was a test of patience. In 1982 when it came out, I'm sure people didn't have high expectations when it came to performance, but I came to the scene six years later and newer games written in assembly had already spoiled me. Running the Telengard code through Austro Speed made it play fast enough for me to really enjoy playing, and I was able to start making good progress, exploring many more levels of the vast dungeon in much less time. It ended up becoming one of my favorite RPGs, and if it hadn't been for that compiler it might've been something I only played a few times and then moved on.

D.h. der VDC kennt keine Color-Cells wie der VIC-II?

3rd party developers really let that machine down the games could have been better than some nes titles but they only sold 2.5million c128s twice as many as a commodore 16 and that had over 500titles while the c128 had about 27 but thats commodore....they were funny buggers

Super cool, I am really enjoying your work with the 128's VDC. Thanks for sharing!

8:36 There's less flickering if you copy the color attributes before the bitmap.

this is just amazing!

I can't say I recognize him, but I look forward to finding out more.

I would guess the fade-in of the Ultima logo is done by covering the logo by less and less blocks of random black pixels, so basically doing a form of crude dithering. You could do it in reverse by grabbing random blocks of the logo from the back buffer and put them on the visible area of the screen, instead of blitting the whole logo as a whole. The "waving flag" effect could be done by shifting the scan lines left and right in an alternating fashion while copying in the logo.

Wasn't one of the VDC's shortcomings that it didn't have the performance compared to the VIC? A lot of games took heavy advantage of the VIC's hardware capabilities to make them run fast and smooth, I have no idea whether the VDC was also somewhat capable of doing that, or if it was more of a 'dumb' display adapter that just displayed whatever you put in VRAM and not much more. PC's didn't really have that limitation since the EGA was already pretty much a dumb adapter from the start and CPU's were fast enough to handle the simple bit-banging method of generating graphics, so it didn't need any accelerating features like hardware sprites. With regards to graphics quality games like Sierra or LucasArts adventures would really have shined on the C128. Imagine "The Secret of Monkey Island" releasing a few years earlier with Michael Land's music on (stereo?) SID sound.

Great video!

Outstanding video, thanks for your hard work.

ah so there is a work around, I was originally trying to get 160x100 mode working on a 16K chip, by using the offset mode, as I don't care about the bitmap data looping around in memory as the bitmap is identical for the whole screen. But I ran into issues, maybe the solution was to put the Attributes then Bitmap rather than Bitmap then Attributes. Does it behave the same on the other VDC chip? as it has the scrolling offset backwards it might change the fix required in this case as well.

It's too bad that the C128's VDC chip was not utilized more by developers. I know the 8-bit guy's "Attack of the PETSCII Robots" for the C128 allows you to use a second monitor (which uses the VDC chip), but I can't think of another example, sadly.

With so many restrictions, this micro compiler doesn't really bring any advantages to just writing the code in assembler, for example in Turbo Macro Pro and targeting the C=128. It's basically in the same class as the cc65 C compiler, which does not have the basic float and double data types, and therefore cannot do floating point arithmetic, and doesn't come with libc, which pretty much defeats the purpose of writing software for the C=64 in C, or compiling existing body of C software for the C=64. These pieces of software are the antithesis to core UNIX software design principles.

By the by, "variable" in English is pronounced the same way as in German, the only difference being that the "a" in "va" is short, not long. Pronounced "Weriable".

Your vdc videos are the most exciting thing for me on youtube currently. Thank you for these videos and any future videos!

When you copy the logo and paste it an you copy out psudo random parts and past them on so it appears in blocks. You would need to create a data table of the copy positions but it should work and look passible.

What? The c64 was famous for its arcade ports and fast games. It was comparable to the nes.

And fwiw, drawing the Ultima IV logo the same way as the DOS version is going to be hard to do with that VDC basic extension, as you would probably have to draw it pixel by pixel, which will be too slow. Looking at the drawing code of the DOS version, it blits the logo 56 times, and uses the table at D_32D0 to mask out different pixels in each step. It's the code at C_17C1 that's ANDing the mask for each of the four bit planes that are being written. At offset 56, that table contains a mask of ffffh, so then all pixels will be set.

The Ultima IV logo doesn't appear in one go, because it takes to long to copy the data within one frame, so you can see it for one frame without the correct attribute data. I'd try to copy the attribute data first, before copying the pixel data.

Happy and healthy new year! Very interesting video, you got a new subscriber! Thank you very much!

Your study of EGA and the C64 is amazing! It brings up questions I have had recently about the relative merits of an early x86 PC with EGA versus the Commodore 64. It seems as if the C64 was a really great gaming computer for its time. Better than the early IBM PC with CGA. With EGA, it becomes somewhat closer. A 286 with EGA could run games like Keen 1. However, that setup is much more expensive than a C64, and came much later. So it feels as if the value proposition of a C64 was very high relative to IBM, for a long time. EGA cards were bitmap-based in their drawing, I think. VIC-II had HW sprites. So the latter would have been far more efficient for platforming and other functions. I'm just wondering, what do you get for all that $$$ and giant EGA card in an IBM? It seems EGA had an advantage in bitmap graphics. If you look at some of the adventure games that ran on it, they were more detailed and higher-resolution than what a C64 would produce. And 8086 with EGA could run a game like F-19 Stealth Fighter sharper than C64. But it shouldn't have been so close! I guess maybe an IBM PC with composite CGA-out would have been a closer match to a C64. The Commodore had many games optimized for it come out, but IBM PC with composite CGA had far fewer games that were optimized for that specific configuration. Otherwise, gaming on that particular model of PC could have been better. So it's partly about optimization.

Very nice video, great work! 👍

So did you report this bug to the VICE team? If not, it will obviously not be fixed...

Interesting stuff! 👍 ps. There is a loud 15.5khz flyback transformer whine in the background whenever there is a monitor on the screen. Unfortunately I am still "fortunate" enough to hear it. :D I would suggest filtering the audio track with a low-pass filter whenever there is a monitor on the video. Or maybe even low-pass it all the time.

"Bounces" has a fantastic fade intro that I was always fascinated by. I'm certain it must be done by algorithm, I would love to one day sort out how it's done. (It's all over within 3 seconds into this video, the entire fade is 14 frames long. You can step frame-by-frame with , and . buttons.) kzfaq.info/get/bejne/psyVqb2mu66tZZc.html

I am repeating myself, but imagine now C128 on the left screen with 4MHz :-)) And on top of that with 121 colors from Plus 4. haha... That would have blew the competition away with ease back in the days! Thanks for the efforts btw. It is always interesting to see what Commodore computers were since always capable to do even with limited resources.

Well, it obviously can be done. Nice work! ... VDC is a complicated piece of hardware and accessible only through two registers (if i can recall correctly). Running unfortunately only at 2MHz instead of 4MHz. The engineers did the same mistake with VIC and C128 normal mode in general. They did add tons of extras directly accessible with better BASIC. Built-in ML monitor. Added more memory, better keyboard compared to C64 and they put even C64 inside of C128. But they made a catastrophic mistake. You had to drive with Fiat Punto to explore the big C128 area. Same car as you had with C64, but slower in C128 mode! That's unforgivable and only a few million sold C128 are good evidence for it. Otherwise every existing C64 owner would back then also buy C128 after selling his C64. After all that were more than 20 million units. Old customers could use all the C64 software and would hold this in his hands: Imagine: 4MHz 8502 CPU inside of a C128! Without defect Z80, and without incompatible VIC! That would have written totally different story for us as customers and also for the Commodore company back then. And make C128 significantly cheaper and better accessible. I see more than 20 million sold units because developers would have surely develop also for the C128 and could still sale C64 software because of the compatibility. But 1MHz C128??? What were they thinking (Management and Engineers). Hope some smart guy (not me, haha...) can develop a module for Commodore C128 with 4MHz 8502 CPU and 4MHz compatible VIC version. I would immediately buy it because i love my C128 even if it's full of mistakes 😁

It is a shame that the VDC display wasn't more accessible. Some people tell me that some VGA monitors can support the C128's VDC, but I didn't find any that work in the UK, so I'm guessing it was NTSC machines that worked with some VGA monitors, not PAL machines.

Beautiful scenery. Thank you ! xoxo

I have to admit, EGA version has warmer and more vibrant colours.

I would not call it scrolling flawlessly until I see some smooth scrolling. Maybe it’s the videos capture issues. But all I see is some rather choppy scrolling compared to what the VICII hardware scroll does

Programming was always a mystery to me. Tbh, i still dont know how C64 games were programmed.

I had a pirated copy of Blitz back in the 80s, but beyond using it on BASIC programs, I never knew how to use it. I knew it had various options and other things you could do with it, but since I never had a manual for it, all I could do was run it on a BASIC program and hope it worked. If I recall correctly, I used it on a few simple conversion programs I made. Like one to convert Printshop graphics from Commodore to non-Commodore printer formats by doubling all the pixels horizontally. Or my program to convert a copy of Championship Lode Runner into a data disk for use with the original game (so you could use the built-in cheats). I seem to recall having some other BASIC compiler as well, but I forget what it was called. Then there was one published by Compute!'s Gazette. It only worked on a subset of BASIC commands, but produced really fast results. I think it converted the commands directly to ML, which is probably why it only allowed the use of certain commands.

The 960x540 mono with blue or red really looks SO crisp

That ends up looking quite acceptable in the end. Congratulations! It's great that there is someone doing this on the C128 with a focus on clear, understandable code. This is the sort of thing that will get more people trying things out themselves, which will really enhance the community. Thanks for what you are doing!

so why not compile to assembler, directly, from basic. no interpreter required. way too complex "compiler solution". so you already have the code and jump tables, why not compile to c64 assembler directly. even the unoptimized assembler code translation is way faster. this was totally non required speed up software, you are smart. also modules/libraries work if you...

Very nice! One further optimization you could do is to fill the entire bitmap with %00001111. If two pixels are the same color, just set the attribute to the same color for both foreground and background. This way you can clear the bitmap with fast block fills of %00001111 and only have to individually set the color attribute RAM bytes. Going beyond that, there is also a double-width mode with which you can do theoretically do a 320x200 mode, which only takes up 8000 bytes of bitmap, and then treat it as 160x100x16 as here. I can't recall what that does to the color attributes though. There's also something in my memory about timing weirdness in double-width mode which can result in it requiring doing a slightly smaller horizontal width. So in actuality it might end up being something strange like 304x200, leaving you with 152x100. I'm without a C128 at the moment (but expecting to have one again soon) so I can't reliably experiment to reproduce the mode. It's also entirely possible that I just wasn't adjusting something correctly and could've gotten 320x200 working reliably with different settings. Even with the VDC's limitations compared to the VIC-II's strengths, I still find it a fascinating chip, and think more could've and would've been done on the graphics and gaming side in the 80s and 90s if people had understood it better. It's great to see people like yourself doing videos like these, and I hope it'll inspire more people to see what they can make the VDC do. One more thing regarding the double-width mode is that since it reduces the bitmap to only needing 8000 bytes, I wonder if the mode I described above could be done on the 16K chip? With attributes taking up 8000 bytes, we'd be at 16000 total. Seems like it could be doable, but I may be missing something that would change the math.

wizzable is a great word!

basic(s) is never useless

Congrats! Nicely done. Now use the soft-scroll-registers to make it smooth 🙂

Freakin awesome! Now we only need someone to finally make more new C128 games! I would pay for it... Thank you for this great research and video!

You know ... I'm 53 now and I always wondered if scrolling was possible on the VDC. Note you've proven that it is!

Nice! Show Bill Herd. Now I'm also wondering if Attack of the Petscii Robots' form of scrolling can use these modes. Show the 8 Bit Guy

That's some nice detective work!

320 x 200 x 16 is still CGA, 320 x 200 x 256 onscreen out of 262,144 colors (18 bit palette) is MCGA, EGA supports: 640 × 350 × 16 colors on screen out of 64 colors

I liked hte Commander X16 part!