Commodore BASIC .TXT listing out and in

This image shows a quick-reference for how to LIST out to a file, and have BASIC type in a listing from a file.  This is not original work except for fixing the port to plus/4 and similar.

Links:

• https://www.sx64.net/info/disk_commands.html
• https://www.scribd.com/document/1055555189/Twin-Cities-128-Issue-08

(plus/4,16,116 version is a careful and thoughtful port of the sx64.net version, meaning AI Gemini tried really hard, but kept getting confused by C64 knowledge.  AI got the 2035 and 810 addresses right, but I had to research the values to poke.  Informing AI of the correction, it kept trying to supplement the answer getting it more wrong, so I put an end to that!)

Extending C128 BASIC using REM statement parameters

 

So on the C64 you could have commands like SYS 49152,X,Y,"TEXT" where your machine/assembly code could specifically parse the commas and numbers.  The result was a way to interface between BASIC and Assembly to use the best of both worlds.   BASIC is easy to edit, debug, and change.  6502 is fast and can do some low level operations including accessing all 64K RAM, and all the ROMs.

BUT!!!   On the C128, the SYS command was extended to allow ease of passing registers.  This is fine if you want to transfer data in 0..255 chunks.  But coordinates on the screen are 320x200, so that goes past a byte, and addresses are 0..65535, they definitely go past a byte.  And strings are another animal.

On the C128 the statement SYS 4864,1,2,3 will call the routine with .A, .X, .Y registers populated with 1, 2, and 3 respectively.  That's fine and dandy, but if you want to do something more, you have to do it another way.

Here comes the new syntax:

SYS 4864 : REM 300, 65535, "Hello C128"

By using the token getter, you can check for colon, REM token, then proceed to parse values and variables as before on C64.  (With the exception that I couldn't get expressions like 2+3 to work, maybe something to do with REM.  But we can work around that.)

Check out the github repository for program listings including commented assembly for more details, and to grab a copy of the D64 containing the PRG.

Touch points and buttons on M5Core 2" displays, Tab 5" display, and Sunton 7" display for keyboard emulation

I have targeted the following M5 Stack models with my C64/C128/Vic-20/Apple 1 emulator:

• M5Stack Fire IoT
• M5 Core2
• M5 CoreS3

(Even though I have targeted other boards, I had only implemented touch on the CoreS3)

The primary reason for targeting these boards was the common 2" 320x240 display perfect for most C64 emulation, and the availability of a wristband that works with Core2 and CoreS3 (it works with the Fire if and only if you never need to charge the battery - not aware of a universe where that works out long term).

[aside... Originally I had supported the M5 Core Basic, but without PSRAM, it was difficult to support the different computer models that currently load into that memory.  So M5 Core BASIC was dropped after its initial development.]

The Basic and Fire have three UI hardware buttons.   The Core2 has three virtual touchscreen buttons (touchscreen expands farther down from the LCD screen to allow for capacitive touch button points, and the M5 library abstracts them similar to physical buttons, so your code doesn't even have to know the difference).  The CoreS3 has no UI buttons, but I've manually implemented virtual touch screen buttons at the bottom of the screen.   From left to right the buttons are known to M5 as A, B, and C.

So button support for Basic, Fire, and Core2 was straightforward.

• press Button A: Cursor UP
• press Button B: RETURN
• press Button C: Cursor Down

With hold functionality as well.

• hold Button A: toggle computer model (C64, C128, Vic-20, Apple 1, repeats)
• hold Button B: LOAD"*",8 / RUN for Commodore, snapshot system for Apple 1
• hold Button C: STOP

Thus, one can demonstrate the emulator loading a menu of programs, scrolling though the listing, and choosing one.  And toggle between the emulators.   The Apple 1 snapshot system allows choosing a snapshot and loading or saving it.

I support other hardware targets, and I have BLE pairing functionality.  So I am thinking of expanding support of the virtual buttons, including more virtual buttons, and providing 8-position joystick inputs (and button) too.  But for now, here is the documentation for the existing buttons.

And then just like that, the CoreS3, Tab5, and Sunton 7" now have more touch points implemented for their capacitive touch screens to allow for more virtual keys.

BLE HID coprocessor for microcontrollers

 

Teensy in green, ESP32-C3 in blue

I have a Teensy 4.1 operating as a Commodore 64 (and Vic-20, and 128, and Apple 1) emulator.  It already supports USB Host (via 5 pin header on top) and web page helper (via USB CDC).

The Teensy doesn't have wireless capability, but I wanted to add BLE keyboard support.  So enter the ESP32-C3 as a coprocessor.  It is running a custom firmware using the NimBLE library to enumerate BLE HID devices in pairing mode, and connects as soon as it finds one. If everything works successfully, it sends HID reports as ASCII over the UART channel (received at Teensy RX pin 0).  

While the Teensy is busy driving the LCD with a bunch of connections, the ESP32-C3 is only wired at 5V input, ground, and a TX pin.  The ESP firmware is built without USB CDC support so that the Serial line defaults to GPIO.  

Shown is a USB only ESP32-C3 board with the advantage of being slightly cheaper.  When I purchased it years ago when ESP32-C3 was relatively new, it was about US$2 on AliExpress.  Looking today, there's even more choices available in all sorts of price ranges and sizes.

So the Teensy is doing what it is good at, and the ESP32-C3 is filling in a wireless connection gap.  The red jumper is provided to be able to pull power.  Though the power connection does have its advantage that the ESP32-C3 has a USB-C port, while the Teensy has a USB-Micro connector.

Look Ma -- no wires!

Mouse, Trackpad, and Gamepad/Joystick are supported as well.  Gamepads and Joysticks will require HID maps which are loaded but not interpreted yet, nor passed on the interface (work to be done).  Joystick support is not implemented yet in my emulators, but stay tuned!

Update (2026-07-03): coprocessor firmware updated to support my custom BLE CBM keyboard sources, and optionally convert standard HID reports to Commodore key scan codes.  By focusing on Commodore scan codes, the integration with the emulators is now simpler, and seamlessly supports more of my keyboards -- while also as being an option, the coprocessor can be used by those that expect standard HID bytes. (Note: no conversion from Commodore to keyboard HID, only the other way around.)

Added Tab5 Keyboard support for my portable emulators for Commodore

 

Tab5 Keyboard is a convenience add-on

I added native keyboard support to my emulators already running on M5Stack's Tab5.

There were already 64/Vic-20/128 original keyboards, CardKB, web page adapter, Palm Portable Keyboard, and custom BLE support.  

Now there is also attached keyboard accessory support.  The Tab5 is a 5" ESP32-P4 handheld tablet with high resolution 1280x720 LCD.  The keyboard plugs into the bottom of the tablet, extending the size, and the capabilities.

The implementation scans all 70 keys for presses and translates to a list of C128 key scan codes into ASCII comma separated and newline terminated form, which the emulators already know how to translate into Commodore model specific keyboard scan codes.  As these are pressed scan codes, the press is persisted in the emulated system until the physical key is released.  These are symbolic mappings, not positional mappings because that is my preference.  Want different?  This is open source!

All visibly labeled keys are supported mostly as is.  Keys not Commodore specific are mapped to a Commodore PETSCII character already mapped to the proper ASCII character for the minimal environment (left arrow, underscore, caret, curly braces, pipe, backslash, backquote, tilde).  In addition, shift [Aa] supports letters, and numbers and punctuation to do the normal shifted characters.  Both [sym] and shift [Aa] do the symbols.   Additional keys worthy of documentation are:

• _=             RIGHT SHIFT
• tab            COMMODORE C=
• sym tab        TAB
• esc            STOP
• shift esc      LOAD RUN
• sym esc        ESC
• ctrl sym del   STOP RESTORE
• shift del      INSERT
• \              £
• sym shift \    SHIFT £
• shift -        LEFT ARROW
• sym shift -    SHIFT -
• shift +        =
• sym shift +    SHIFT =
• sym shift *    SHIFT *
• sym up         HOME
• sym shift up   CLEAR
• sym 1          F1
• ...
• sym 8          F8

As a reminder the emulators included are:

• Commodore 64
• Commodore 128
• Commodore Vic-20
• Environment similar to an Apple 1 (minimalistic 6502/6850/ROM/RAM plus terminal)

Links:

https://github.com/davervw/c-simple-emu6502-cbm/tree/unified-pio

Extended Screen for C128

Finally, Commodore 128 can provide the 80 column screen that multiple monitor folks need - extended screen.  Spread those columns across two separate monitors for a wider view.

Instructions

1. Download disk image, and use as is with modern tools, or image to floppy.
2. Click the 80 column keyboard button into position to make it the default.
3. Attach two monitors to your C128.  Composite on the left, digital RGB on the right.
4. Start up (or reset) C128 with disk attached.  Boot sector will load and run 80DUAL by default.
5. Enjoy screen extended 80 columns!

It works by reinitializing the VDC 8563/8568 registers to display 40 columns offset by 40 columns, and each line thereafter also offset by 40 columns.  Since the KERNAL hasn't been told any differently, it will continue to treat the VDC as an 80 column display, but the VDC settings are now to display only the right hand 40 columns.  An IRQ routine is installed to copy 5 lines from VDC RAM to VIC-II screen RAM (hardwired to address 1024 currently) and color RAM.  The effect is that as text is typed or displayed on the 80-column virtual and physical display, the hidden left-hand side of the screen will also be displayed on the composite monitor.

This is a proof of concept, and has limitations.  

• The machine language routines use $1300-$15ff for code and data
• The code uses self-modification techniques so can't be moved to ROM as is
• Character set changes are not handled
• Changing to composite screen is not handled, will continue to be overwritten from VDC RAM
• No graphics support
• Slow, less than 12 frames per second operation
• Not compatible with SNAKE
• Will interfere with programs that write text to VDC screen using own (not ROM) routines.  It has a fixed list of ROM addresses to avoid interrupting, and doesn't include RAM.

Why?

• It was a challenge I set myself
• Because it's ridiculous and outrageous, has little practical purpose.  I like the bizarre possibilities.
• Related to my rgb64

Link: github.com/davervw/dual80-for-c128

"VDC Hires," or "If you want to program a Commodore right, do it yourself, because AI is not your friend"

AI: What could go wrong?🤔

Don't get me wrong.  I love AI.  I also hate AI.  It's been great to me for writing C# utilities for work, or SQL queries, reviewing code, writing scripts in languages I don't even know (LUA) -- yeah that looks right, let's put that in production.

But for Commodore?  Spoilers -- it's really horrible.  I'll get back to that later.

My "fun" task for the day?  I want to finally program high resolution graphics on my C128 VDC 80 column screen.  It's well capable of 80x25.  And I bought my C128D with 64K RAM specifically knowing it could do that high resolution graphics well.  The original only came with 16K, and when it arrived COD at my door in 1987, I refused it and sent it back because of 11th hour nearly buyers remorse, delaying my gratification to wait a few more weeks for the newer C128D to arrive with more RAM.

The C64 could only do 320x200 graphics because it's a 40 column machine.  The C128 had 80 columns and thus twice the resolution because it included two graphics chips and had two separate video outputs.  BASIC 7.0 finally supported 320x200, but not graphics specific to the 80 column chip.  I even purchased GEOS 128 with mouse and 1750 memory expansion, and saw the fulfillment of 640x200 graphics.

But was I fulfilled? No.

I am a programmer.  Features don't exist until I code the programs that make them exist.  I enjoy the process of learning APIs and languages, and developing new skills.

Later in 1988 I investigated the VDC (C128's 80 column video display controller) closer, with the guide of some magazine articles, and close scrutiny of the Commodore 128 Programmer's Guide which had a mere 4 pages of a minimalistic datasheet.  I remember wanting to know how to do it.  But as far as I got with changing and programming the VDC registers was a 40 column mode, and an 80x50 interlaced text mode.  The former was released as RGB64, and the later was released as node-m (a unique terminal program).  Graphics abilities unique to the C128 were not accomplished by me.  Not in the 80s.

Now it's nearly 40 years later.  VDC graphics programming is still a challenge I want to conquer.  It's 2026, in the golden age of AI, technical assistants available at our fingertips.

Could AI provide me a working sample?  No.  I went round and round with it for hours.  Gave up, and came back another weekend day for hours.  Did it work?  No.  Was I close?  Maybe.

One web link from AI gave a hint though.  The reference was Commodore 128 Programming Secrets.  The sample program on page 274, Figure 5-4, was short, just 25 lines, and didn't look very complicated.  Obviously this was a joke, you can't achieve such a lofty goal as complicated VDC graphics in just 25 lines.  There weren't even very many VDC register writes.  But I typed it in, and once I figured out some decent parameters to feed it at runtime (10, -10, 1, -1), the results were presented on screen.

Commodore 128 Programming Secrets
640x200 monochrome graphics sample

But how could this be?  All that I learned researching with AI taught me it was so much more complicated than this.  Then I reviewed the code, and my assumptions, and the paths AI had taken me down had to be set aside.

The algorithm in a nutshell is 

• Initialize raster graphics mode, giving up text screen, attributes, and character images
• Write to screen memory as bytes going across, then down.  First and high bits are on the left, last and low bits are on the right.  In other words, use math.
• Follow VDC register rules.  And use block fill feature for speed.

I already knew the rules.  Well, I did in 1988.  And I've learned and relearned them over the years as I've dabbled in VDC programming.  Nothing too special, but enough to know the basics.  But there is the trappings too.  And when you don't use something every day it's easy to forget even the basics. So let's write down the rules here so we all can refer back to them someday.

VDC rules

1. Access to VDC is through two C128 memory-mapped locations:
• D600 is generally used to store a register number (and read status)
• D601 is used to store a register value
2. VDC is controlled through its registers.
3. Access to VDC RAM (16K or 64) is only through the registers as well.
4. Want to write to a register? Store the register index in D600, then wait for the high bit to be set on D600 before storing the desired value in D601.
5. Want to read a register? store the register index in D600, then wait for the high bit to be set on D600 before reading the value from D601.
6. Want to write to memory?  At some point you have to set the address using registers 18, 19. After that you can set the value in register 31.
7. For a block fill, you must write one memory value first, then you can write a count of the remaining slots you also want to fill.  If you want to store 100 bytes total, you store 99 here.
8. Values in registers 18 (high), 19 (low) auto-increment, so either reading or writing various values to consecutive bytes doesn't require rewriting the address.  But reading from the address, and writing back to it will require rewriting the address, otherwise it has jumped forward by one.
9. Screen memory is pointed to by registers 12, 13.
10. Attribute memory is pointed to by registers 20, 21.
11. Character images is pointed to by register 28 (high 3 bits).  Shift those bits down and multiply by $2000 to get the VDC RAM address, or in reverse shift up.
12. VDC defaults to 16K RAM operation.  64K mode will scramble how the data is addressed, so would require reinitializing the screen, attributes, and characters.
13. Graphics mode (bit 7 of register 25) means that the VDC will render to the monitor line and byte by byte or bit by bit from screen memory.
14. 640x200 monochrome requires 16000 bytes, so not enough left for screen, attributes, characters.
15. Other graphic modes are possible including using attributes for choosing different colors for cells, and even changing the dimensions of the cell (allows for more color changes).  I'm not versed in this yet.
16. There are plenty of registers you should not change unless you understand them well, or are willing to take a risk.
17. C128D includes 8568 chip with the addition of an IRQ line when command completed (not wired to anything), and Sync Polarity options in a new register 37.
18. Attributes are different than C64 color memory.  These are whole bytes!  The lower 4 bits are RGBI (red/green/blue/intensity).  The upper 4 bits are (character set, reverse, underline, and blink).  The character set bit option lets you have 512 different characters on screen at any one time.  And the reverse bit is useful for game developer, but not necessary for the Commodore character sets as they already have reverse in their latter half of their sets.
19. Attributes are optional.  See AttrEnable bit 6 in register 25 for turning it off (0).

Tricks

• BANK 15 (shown as the first F digit below in the monitor listing) is the default bank when C128 starts up.  This memory map has access to I/O and KERNAL ROM.
• C128 KERNAL already has routines for writing/reading to/from the VDC registers.  These can be leveraged from BASIC as needed, especially useful for prototyping.
  SYS DEC("CDDA"),,R : RREG V : REM Read VDC Register
  SYS DEC("CDCC"),V,R : REM Write VDC register
• C128 KERNAL has a routine to reset character images in the VDC RAM.  JSR FF62.  (Thanks AI for that tidbit scraped off the web.)
• SCNCLR is a good way to reset screen and attribute memory.  Similar to GRAPHIC 5,1 and PRINT CHR$(147).

. fcdca  a2 1f    ldx #$1f
. fcdcc  8e 00 d6 stx $d600
. fcdcf  2c 00 d6 bit $d600
. fcdd2  10 fb    bpl $cdcf
. fcdd4  8d 01 d6 sta $d601
. fcdd7  60       rts

. fcdd8  a2 1f    ldx #$1f
. fcdda  8e 00 d6 stx $d600
. fcddd  2c 00 d6 bit $d600
. fcde0  10 fb    bpl $cddd
. fcde2  ad 01 d6 lda $d601
. fcde5  60       rts

Arguing with AI

I got fed up with AI.  Mostly because it didn't work just vibe coding.  I kept delivering results from programs, and they still wouldn't work.  But I also argued.

• I had to explain I didn't have BASIC 8.0, only 7.0
• Explaining GRAPHIC 5 doesn't actually have anything to do with graphics
• No, the processor doesn't have direct access to VDC RAM
• Variable names cannot have underscores
• Variable names must be two letters at most to differentiate from each other
• Spaces are not required between keywords and variable names
• Just arguing about nonsense that the AI had completely backwards.
• AI putting in comments REM Completely Fixed Version
• Explaining the right way of doing things, and AI insisting it was right instead
• Explaining the right way of doing things, and AI treating me as I had led it astray in the first place, that it was my fault
• No you can't prompt for values on the same screen trying to draw graphics.  But you can use the 40 column screen simultaneously using GRAPHIC 0
• No, that order of code is correct, if we change it, it will fail worse
• Telling me there are two bugs, then listing three bugs
• Outright hallucinations

So maybe it's a little unfair.  These AIs have been around for a short time, and modern programming is a lot different than Commodore 128 programming.  And there are so many options with the VDC, many not quite documented, more trial and error, through experience, not examples.  With folks talking about the various options, AI can get these intertwined and mixed up.

Now that we know the answer, can we assist AI in providing us a working answer?  I have a collection of AIs available to me.  Let's try a simple prompt, and a complex prompt, and turn up the thinking as high as we can go.

Short prompt

Please provide me a Commodore 128 BASIC 7.0 working example of drawing a circle on the VDC 640x200 display in monochrome bitmapped mode using any facilities in a stock C128 available.   Please provide a BASIC listing output in lowercase text only that will be accepted by a Commodore 128.

LLMs tested:

Qwen2.5-Coder 14B

gpt5-mini (High)

Windows 11 Copilot

Gemini

OpenAI 5.3-Codex (High)

Claude Sonnet 4.6 (Adaptive)

AI results

Out of the gate, Qwen2.5-Coder 14B, running on my own GPU mind you, produced remarks in uppercase, thought that simple pokes to addresses based on the coordinates would hit video memory, but worst of all used bit shifting ala C which is not present in Commodore BASIC 7.0.  Also the while/wend loop should have been do while ... loop.

110 d = 3 - (radius << 1)

120 rem draw circle using Bresenham's algorithm
130 while x <= y

140 rem plot eight points of the circle
150 poke cx + x, cy + y : poke cx - x, cy + y

Actually Codex got the closest... it followed directions, produced a valid program free of syntax errors, it runs, and while it fails to clear the screen, an oval shape does appear.

5.3-Codex (High) result

I should have started and stayed with Codex a bit longer.  I could have worked from this sample, fixing clearing the screen, and changing the aspect ratio of the circle would have been challenges I could have worked through.  Looking back at my history I had started with it, and it had failed for me though, and led me down some more complicated paths.

In contrast, Windows 11 CoPilot produced a version with syntax errors.  It didn't quite understand the syntax of Commodore BASIC 7.0.  That's not how functions work, and you don't assign a value to a sys command.

30 def fnw(v,r):bank15:sys52684=0:rem placeholder

Gemini produced this listing:

10 graphic 5,1
20 color 0,2,1
30 circle 1,320,100,60,60
40 getkey a$
50 graphic 0,1

Resulting in the following, because CIRCLE doesn't work in 80 column mode, because it's a text mode, not a graphics mode.  No GRAPHIC command will put you in a graphics mode using VDC.

?NO GRAPHICS AREA ERROR IN 30

Claude Sonnet 4.6 (Adaptive) thought for 19m 2s and I reached my 5 hour limit before being prompted to upgrade to a paid plan.  That was a lot of thinking!  I'm not upgrading to program an 8-bit computer.  Wake up the next morning, hit continue, and immediately it produces a similar program like Gemini did.  Similar error resulted, this time in line 40.   Nice, line 50 draws on the text screen.  But line 60 thinks inkey$ does something...  it stays empty forever.   Sonnet, if you were taking notes from Gemini, you should have copied it's line 40 instead.  And switching to the 40 column screen was unnecessary.  The other commands are nice though, but no circle produced.

10 graphic 5,1
20 color 0,1
30 color 1,2
40 circle 1,320,100,80,80
50 char 1,1,23,"press any key to exit"
60 do : loop until inkey$<>""
70 graphic 0,1
80 end

gpt5-mini (High) keeps prompting in Visual Studio Code for browsing web pages and is stuck on thinking Commodore has vpeek/vpoke, and because of Graphic command in BASIC 7.0, it must have commands for VDC, but it keeps looking and looking...  after about 8 prompts to browse web pages I'm stopping it, it just keeps looking at general programming html sites (and one PDF).

My solution (disclaimer: Claude did earlier find a logic error in my code that fixed a problem I was having, turned into one of my rules for VDC about register reads auto advancing the memory pointer, and having to reset it to write a changed value).  So reviewing code worked out, but generating it not so much.  My own developed solution is attached:

No AI generated code here, but was AI reviewed

100 rem-----------------------------------------------------------------------
110 rem vdc 640x200 monochrome
120 rem copyright (c) 2026 by david r. van wagner
130 rem mit license
140 rem
150 rem davevw.com
160 rem github.com/davevw
170 rem mit license
180 rem-----------------------------------------------------------------------
190 def fnac(x)=2*atn(sqr(1-x*x)/(1+x))
200 trap 900
210 graphic5,1:fast
220 for i=1 to 21:print chr$(17);:next
230 data 1,2,4,8,16,32,64,128:dimbi(7):fori=0to7:readbi(i):next
240 print"screen";:r=12:gosub 1040:gosub 1050:sc=ad
250 print"attrs ";:r=20:gosub 1040:gosub 1050:at=ad
260 print"chars ";:r=28:gosub 1000:ad=int(v/32)*8192:gosub1050:cr=ad
270 for i=1 to 1000:next:scnclr
280 r=25:gosub 1000:v=v and (255-64) or 128:gosub 1010
290 ad=sc:gosub1060:wait dec("d600"),128:f=0:c=16000:gosub 1070
300 for x=0 to 639:a=fnac((x-320)/321):y=int(99*sin(a)+100):gosub1080
310 y=199-y:gosub 1080:next x
320 getkey a$
900 r=25:gosub 1000:v=v and 127 or 64:gosub 1010:sys dec("ff62"):scnclr
910 if er<>-1 then print err$(err)" at line "el
999 end:rem ******* reusable subroutines *******
1000 sys(dec("cdda")),,r:rreg v:return:rem ** read vdc reg r into v **
1010 sys(dec("cdcc")),v,r:return:rem ** write vdc reg r value v **
1020 sys(dec("cdcf")),v:return:rem ** write next byte **
1030 sys(dec("cddd")):rreg v:return:rem ** read next byte **
1040 gosub 1000:ad=v*256:r=r+1:gosub 1000:ad=ad+v:return:rem ** get address **
1050 printusing" ##";r-1;:printusing" ##";r;:printusing" #####";ad:return:****
1060 r=18:v=ad/256:gosub1010:r=19:v=adand255:gosub1010:return:rem *update addr*
1070 i=0:do while i<c:rem ** block fill (begin) **
1071 r=31:v=f:gosub 1010
1072 v=c-i-1:if v>0 then begin
1073 :ifv>255thenv=255
1074 :r=30:gosub1010
1075 bend
1076 i=i+v+1
1077 wait dec("d600"),128
1078 loop
1079 return:rem ** block fill (end) **
1080 ad=sc+int(y)*80+int(x/8):gosub1060:rem ** plot (begin) **
1081 r=31:gosub1000:n=v or bi(7-(xand7)):gosub1060:r=31:v=n:gosub1010
1082 return:rem ** plot (end) **

Granted, this is more of an oval.  I was going for a large oval on all of the screen: 319 radius on the x axis, and 99 radius on the y axis.  The arc cosine is my attempt at a more intact circle.

Conclusion

I will continue to use AI for certain things, but Commodore vibe coding is not there yet for my needs when I don't have the answers.  AI and myself went down a long path of unknowns, assumptions, inaccuracies, and under/over-complexities.  What ended up working was digging in for myself, trying little things, and lots of credit goes to Commodore 128 Programming Secrets as it produced a sample program that did the job.

The elusive detail was that when turning on bitmap mode in the VDC, screen memory (not character memory) is where the raster data goes.  And with an original 16K RAM attached to VDC, there's no room for attributes, so disable them.  How would an AI know this?  

Noted, I may have tricked the AIs, by not giving them all the detail they needed, especially that VDC graphics primitives are not present in Commodore 128 ROMs and BASIC commands.  And some of my earlier AI prompts dived right into 64K options that overcomplicated the situation.

I could update the prompts to guide AI closer to the answers, now that I know the answers, but what's the point?  I didn't have all the answers, so I was searching.  I should have probably stuck with web searches rather than trust AI to solely come up with the answer.

You have to be pretty smart to use AI effectively.  I may have failed myself this round using AI.  Throwing too much faith into AI is also a mistake.

Remember there are no guarantees.  So try to have fun on the journey, learning, even when some paths lead to failure.    But in the end, don't give up.  There are other paths and you may find them next time.  Don't give up on programming/researching yourself, and don't give up on AI as its capabilities are remarkable.  Learn new things, learn new ways of doing things, and next time might be better and more efficient solution.