วีดีโอ

Glad you like it!

The QR Codes grow in steps of 4 (the versions). Each version has a defined "capacity". If less characters are given, the remaining space will be filled with 0xEC 0x11. The Basic generator always generates Version 5 codes, and I think the repeating pattern because of the padding is very visible in these QR-Codes. So, "a" should definitely result in a smaller code than "Commodore". Speed of code generation is mostly similar between versions. So, reducing by a couple of characters only matters if that results in a smaller version.

Fully agreed, that topic is a rabbit hole 😁. Thanks for your feedback

My pleasure! I enjoyed every second of the journey ☺️. Glad you enjoyed it

Glad you liked it! Thanks!

You can set the registers so it displays 40x25. 4 Colors won‘t work in textmode, but 4 shades of gray should work

@the8bittheory thanx. And because I own french tv sets with scart connectors, I can enjoy sharp image on a lcd display. Scart is still the goto

You might be interested in the VDC-Modemania Demo. I think that shows the potential pretty well. Thanks for your input!

I mean to render 32x32 pixel sprites of 1 color.

The transparent parts of the Sprite need to be ORed with the background pixels in CPU RAM and then written to VRAM. Probably one of the slowest things you can do. If the background is predictable you might be able to keep pre-merged Sprite data in VRAM and use block copy.

@@the8bittheory thank you. I use also a technique to render in advance in ram 8 images of the same sprite, bit shifted with 1 bit to the right. So they can be quickly or-ed.

@@the8bittheory I'm sure you're fighting the same speed issues ... Still, I do believe that the vdc should be able to achieve acceptable speeds in 320x200 pixel screen mode.

Working with only screen ram or attribute ram speeds things up quite a bit. For VRAM-only operations it should be fairly quick, I agree

Der Preis versteht sich ohne Monitor und Zubehör. Einführungspreis für den c128 waren 300 $. 500$ für den 128D scheint mir legitim zu sein.

Ha, right :-D

Thanks for the input. I‘ll definitely try to get back into the routine :-)

Glad you liked the video. I also enjoy Vision Basic a lot. I need to find some time working on something serious with it :-)

Es gibt schon auch Color Cells. Die sind aber anders angelegt als die am VIC-II. Deren Größe ist variabel und pro Cell sind nur 2 Farben möglich.

Right. But also, there was next to no documentation of the VDC chip‘s bitmap mode, or it’s 64kb capabilities, for example. So the chip just wasn‘t attractive to any game developer I think. Thanks for your input!

@the8bittheory did u know that a plus 4 can intrupt the raster to produce a resolution of 496x320 graphics with the Ted chip

@the8bittheory the +4 could use raster intrupt and achieve 320x496 they use 6502 assembly in this mode

Thanks for the great feedback! Glad you enjoy it :-)

I‘ll try that. Thanks for the input!

Thanks for the great feedback!

He‘s part of the Ultima 4 opening sequence. Video about that coming soon :-)

Yes that could work. The actual puece if code was already explained in another comment here, but it‘s probably not going to work that way on the Commodore. So, an alternate approach like yours will probably make sense. Thanks!

It‘s mainly the missing sprite capability and the lack of raster interrupts that really limit the chip. In-memory operations are ok in speed, I guess. And 64k of VRAM make up for a lot of things. It‘s no arcade chip, though. EGA was no better, you‘re right. But the 286 and 386 have much more horsepower to make it shine. Soft-sprites are no problem with sufficient processing power. LucasArts games should have worked. Sierra not so much because the vector drawing doesn’t go well alongside the color-resolution limitations of the VDC.

Thank you!

Glad you like it. Thanks for the great feedback!

Interesting thought about the other VDC-chip. Unfortunately I can't verify that as I only own newer VDC chips. And Z64K doesn't offer different VDC-revisions afaik. How does 160x100 work on a 16k chip? I haven't found a way to do squeeze all the data in. Thanks for your input, highly appreciated!

@@the8bittheory well if bitmap offsetting worked what you do put it in memory bitmap row attribute row bitmap roe attribute row now the trick here is you will run out of memory for the bitmap, however the bitmap is just XXXX0000 for every char on every line, so if the bitmap wraps around the 16K mark back to $0000 it will then just get the same bitmap data which is fine. But you then get a unique line for each attribute

I think I understand. That could work. Address-Increment-per-Row set to 81 and visible columns to 79. Not for scrolling, but for having interleaved memory addresses. The start of Attribute-RAM would be at 0 Start of Screen-RAM would also be at 0. Bitmap data 0x0F is filling 80-159, 240-319, 400-479, etc (the "interleaved" screen-rows) Attribute data is FG/BG-color filled into 0-79, 160-239, 320-399, etc (the "visible" screen-rows) While this looks like visible and invisible memory areas are overlapping, it should actually be not. Because of the weird latching(?) behavior that's responsible for the 79-bytes offset between screen-ram and attribute-ram. Let me know if you get around to trying that :-) Maybe I'll find the time to try that, too

I tried this now, but it only really works for the top half of the screen. However, I had to set both, starts of Attribute-RAM and Screen-RAM to 80 to make it look right. So, I'm still pretty sure I misunderstand something about memory alignment. We'll see ...

@@the8bittheory there is something with the memory layout in 16K emulation with 64K ram installed which might explain why "half the screen works" maybe in that it doesn't give the same actual bits that you are skipping/rely upon in the latch issue?

The c64 port of Eye of the Beholder also uses it for displaying the Automap. But it‘s only used as a secondary display, not fully using its potential. Thanks for your input!

@@the8bittheoryNow that you mention it, I do remember reading about that. This is the home brew version of Eye of the Beholder, right? (The original version for the Amiga is my brother's all-time favorite game on any system ever. He used to sit and play that game for 10 or 12 hours at a time, or until our mom said, "Go outside and play for crying out loud!")

@JustWasted3HoursHere Right, that‘s not an official release. Sounds like my mom 😁

@@the8bittheoryThe homebrew scene is red-hot right now and I'm loving every minute of it. We're seeing what's possible when you can take your time and work on it until it's perfect, instead of being rushed so that it can be ready for the upcoming holiday season. Funny thing about my mom: She was always making fun of us kids when we'd play some of those old games and yell at the screen, "Oh come on! That guy was nowhere close to me!" etc. But, she's going to be 81 this year, and guess who discovered video games after she retired and now does the same thing? Yep! Also funny: She's played Tetris Attack on the SNES so much that I can't even beat her. She's an inhuman monster on that game! [side note: That's one of the best designed puzzle type games I have ever seen on any system.]

From today's perspective that's completely right. Back then, the micro compiler was a type-in program. It basically came for free (well, the price of the magazine), which was one of the main benefits, I guess. All the restrictions only make it useful for targeting very specific tasks, not for writing full programs. Any probably only for people who aren't familiar with assembly language.

I'll keep that in mind, thanks! Highly appreciate your feedback :-)

@@the8bittheory ...and I appreciate how much you go into detail, and also that you've decided to do a series of videos on the C=128, because it's not a well documented, well understood system, and there should be more (modern) software for it to exploit its full capabilities in comparison to the C=64.

Glad you like the content! It’s amazing stuff for me, too :-) Thanks for the amazing feedback!

That‘s probably the best way to do this. Maybe I can even extract the data table from the original DOS source code Thanks for your input!

Absolutely agreed. Did I say something different?

@@the8bittheory I might have misunderstood, but I thought you said the c128 was good at playing slower type games implying it couldn't handle faster arcade type games.

You understood right. I was referring to the VDC chip, but probably wasn‘t very clear on that. With the VIC-II, the c128 is great for fast paced action and arcade games.

@@the8bittheory Oh, I see! Yes, I can see that. I'm not too familiar with the C128 architecture, but the vdc was the 128s text display chip? Ok, I can definitely see how that applies then. Thanks for clarifying!

You‘re very welcome. Thanks for your input!

Thanks for providing these insights! Right, I'm also pretty sure the Ultima IV Logo won't work that way by using VDC-Basic.

Thanks for the input, I didn’t think about that before :-)

You may even be able to exploit that to accomplish the fade-in effect. Since you can just place the pixel data without modifying the attribute data, you can put random data blocks in the attribute memory to manipulate the color (going from black to the eventual colour), and use the pixel data to shift the logo around in the meantime, so you don't have to render in the entire logo pixels every time.

Happy New Year! Thanks for the great feedback and welcome on board :-)

I agree with everything you said. And you can even add sound and music to the comparison. For gaming, the c64 was the much better option for the price. Maybe the c128 with it’s 80 column output is closer to the PC‘s definition. With regards to gaming, I like the CGA-composite you‘re bringing up. This wasn’t an option for non-NTSC regions, btw. Thanks for your input!

First of all in 1986-1987, which is when both PC gaming took off and the C64 was at its peak, a turbo XT clone with 640k 8088@8mhz and EGA cost just over US$500. By 1989-1990 a 286@12-16mhz with VGA cost the same. By comparison a c64c with a 1541c disk drive was $420. PC clones were actually cheaper than the C128 (with a disk drive) while offering more memory, faster & cheaper storage options, better resolutions, better keyboards, and the ability to run real software. In terms of gaming, the c64 was definitely better than the original IBM 5150 but it was purely a business machine not intended for gaming or the home market and hence games in 1981-1985 were never made to take advantage of its capabilities. However a turbo XT with EGA was capable of running games well beyond what the C64 could do and was actually reasonably competitive with the ST and Amiga other than sound. For examples Prince of Persia, Quest for Glory, Monkey Island, Ultima 6, F-19 stealth fighter, Pools of Radiance, and Commander Keen to name a small list. Even older titles like Elite and Ultima 5 played far better on a turbo XT thanks to the faster cpu, higher memory and much faster storage. A fast 286 with VGA was actually more capable than the Amiga 500 hence why the PC game market started to pull ahead of the Amiga one by 1990-1991.

Thanks for the great feedback! Glad you like it

Not yet, I still have to check with daily builds. But you‘re right, I need to do that. Thanks for bringing this up!

Thanks for bringing this up. I‘ll definitely do that. I‘m one of the fortunate ones it seems 😁

​@@the8bittheory Haha, the sound brings back the memories. Always remember hearing that as a kid but we all were used to it anyways so I didn't really bother so much.😄 Oh and happy new year!

Thanks! Have a happy new year, too !

Oh yes, this is really great. I'd also love to know how these are done. I'll have to dig into that :-) Thanks for bringing this up!

Actually, MHz don‘t compare 1:1 between 6502 and 8088 architectures. Given the PCs 4,77 MHz, the c128 with 2MHz should be an equal contender (the MHz Ratio changed with 286s, though)

Right, more speed would have been great. I think the story, why things went the way they did, has already been told by Bil Herd. It‘s still a great machine though, I completely agree with that last sentence of yours :-) Thanks for your input !

@@the8bittheory haha...true, the story went the way it did. But if a broken C128 close to 40 years later can be fixed, it should be possible to also fix the C128 story itself. I bet Bil Herd could do that, to give a new birth to C128 with less mess inside, and focus only on what is of importance (as mentioned)... People made CommanderX16 now, but new C128 (with mentioned specs) would be far more interesting (at least for me)... I thought CX16 could be a good replacement, but hmmm... The VERA part is more complicated than the C128 VDC especially if one is not 24/7 CX16 user. My first Commodore was C128 (parents bought me that) and then i had no idea what it was (back then i was a concerned little village citizen in Croatia, we had no road and availability of electricity was a lottery show ;-). Instruction was in German language. I had only C128, and small b/w (i still have that one) TV)... Anyway, as said i hope someone, anyone can create this module (4MHz CPU and working VIC) for C128... That would be amazing! Guten Rutsch und all the best wishes bald im neuen Jahr.

Thanks! Best wishes, too!

@@miselzivanovic2181 The problem with any new-build Commodore computer today is in the video chip. Nobody is producing or can affordably produce the specialized video hardware. Something like a VIC-II chip is very difficult to produce affordably. If you want a custom chip for a better C128, that is going to cost even more. That is why CX16 went with FPGA for the video card - it's the only way to do it. And it's not inauthentic - some 1980s hardware used 'chip-on-a-chip' type solutions. But yes, VERA is very capable, and with capabilities from late 1980s. I don't know if a C128 with better chips and video card would have been possible or not. Would have to review Bill Herd's story again. I think that maybe the Commodore retro community should have come together to release some kind of enhanced C64. Something with more RAM, dual SID chips, basically all the improvements that already exist. But standardized in one build. That way, it would be reverse-compatible with C64 software. But you could also release new programs for it, taking advantage of added RAM and dual-SID. Kind of a "C64 NEXT" like the ZX Spectrum has. Except with real hardware [since most compatible parts are in production.]

@@brendanstone3073 CX16 is an interesting machine, and VERA is a very capable chip. It's probably going to be something out of it with a proper basic/compiler solution. Because not everyone can do ML coding, but everyone wants to have fun nevertheless. You can have that only with proper dev tools (unless you do cross-compiling. Then you need just the HW... Retro feeling ? Not at all... ) Back in the days they had 8502 with 4MHz for C128, however they took the 2MHz version instead, combined with the incompatible VIC is then what we got eventually. Probably was that a cheaper solution then taking 4MHz which also wouldn't work with VIC. Better C128 is actually already existing (Mega 65). Basic version 10 and 40 MHz speed (also 1, 2, 3.5 MHz frequencies possible). That's then good, but it's stealing the 8-bit magic. That's why I said C128 4MHz and compatible VIC. Everything else can remain the same... Retro feeling preserved, happy about 4MHz and...don't even need 121 colors from the previous version Plus 4. 15 colors is enough. Can even be a FPGA solution. Shouldn't cost more than CX16. Well, can be that someone can make this wish come true for the next Christmas 🎄🎁 😁 Thanks for your feedback. Have a great new year and hopefully we will be blessed with 4MHz for C128 😉

I think support for 15kHz hor freq is the key requirement. With that, only a few resistors are required to make a working connection. Otherwise you need at least a scandoubler to make it work.

VGA monitors that support the necessary scan rates exist, but are unusual. It is basically a CGA signal.

Right, at least on PAL C64s. Supposedly, NTSC C64s had at least a bit more vibrant colors. Really good point, thanks for bringing this up!

Correct. It‘s not smooth scrolling. I was so excited that I didn‘t make a difference. Smooth scrolling is possible but requires use of Assembly language. Not sure when I will be able to cover that. Thanks for your input!

@@the8bittheory haha no worries. Also depending on the setup of the hardware do asm really make it possible? I mean do the chip have enough brute force power to push the requirement data in 60fps? One thing is the code to excite the data copy to the chip. That for sure could be speeds up. Still really cool to see someone taking time to explore this “forgotten” chip :)

The VDC has a shift register for pixel-level scrolling, just like the VIC-II. For setting this from 7 to 0 (or vice versa), vblank needs to be leveraged. Otherwise it jitters. 60 fps won’t be possible. I think for fullscreen, 10 is a more realistic number.

@@the8bittheory yes that was I feared. For me 10fps is unbearable. 25fps can work depending on scenario tho

The VDC chip will never become an Arcade powerhouse 😁

But you‘re very interested in the topic anyways, right? Game programming is probably the most attractive field in programming, but also the most complex one.

Conversion programs are a great use case :-). For both, Basic and Basic compilers. I also made a video about micro compilers. That‘s probably close to the one from Computer Gazette you mentioned. Thanks for your input!

Good to know, I‘ll have to give that a try ☺️ Thanks for the input!

Your channel is a great source of inspiration for this. Thanks for the great feedback!

There‘s other compilers that do directly compile to assembler, so you can do that - at least for the c64. But on the c128 options are really limited. Thanks for your input!

like vision basic but that seems to lack some parenthesis functionality, of basic, so not full basic compatibility, I dont care of the extra if the basic is not working@@the8bittheory

but if so and common, why would blitz even exist, are they all paid@@the8bittheory

You might want to take a look at MOSpeed. www.c64-wiki.com/wiki/MOSpeed

how about c/c++ to c64/128 asm/executable?@@the8bittheory

Thanks for the input! Double width mode also halves the color resolution, unfortunately. That would have been a great memory saver. Wrt 8000 bytes: if you‘re good with greyscale, you can really use textmode to fake graphics just as CGA does for the 160x100 mode. Also, thanks for the great feedback. I also hope that this inspires more people to look into the c128‘s unique capabilities.

@@the8bittheory Ah, thank you for correcting my flawed memory! Maybe you can also help me recall how attribute RAM works with interlace. Is it interleaved the same way as the bitmap is, so for example byte 1 of color RAM in 8x2 mode would choose the colors for lines 1 and 3, or does it behave in a contiguous way and it would color lines 1 and 2? I believe it's interleaved, but I don't trust my memory on it. Contiguous would be extremely useful, but seems unlikely.

Unfortunately, I haven’t found the time to look into interlaced mode yet. But it‘s on the list :-)

😁 it‘s just really hard to use it correctly. That made my day, thanks for bringing it up 😁

@@the8bittheory I used it in an AI image generator prompt and liked the result (-:

Ha, nice!