White Flame

If you're at all interested in tape software (or have the patience to use that as a transfer medium), you can convert .tap images to .wav and record them as audio onto a cassette for the c2n. Doesn't require any special hardware if you already have an old audio cassette deck and a basic 3.5mm cable. https://github.com/lunderhage/c64tapedecode But if your main goal is a virtual disk drive so you don't need floppies at all, then you really do need to buy a hardware solution.

If you have an RS-232 link between your PC and 64 via user port, I wrote this specifically to solve the transfer bootstrap problem. 51 lines of type-in BASIC: https://codebase64.org/doku.php?id=base:simple_basic_x-modem_receive

Well, I guess I should have checked this thread sooner; nobody had started yet. I retyped the full text, sans all the hex bytes and the symbol table: https://github.com/white-flame/vcs-checkers Run the script to generate it properly formatted, with or without the original address foo. I attached the outputs here as well. listing.txt checkers.asm

How did A and B get onscreen in the first place? The code must have determined a location for them. Don't search the screen, keep the x/y coordinates of each from when you draw them, so you can refer back to their locations directly.

Whenever you type a double quote character, it enters a quote mode which captures most cursor movement and control characters into their literal code byte, for use in strings. You can delete that double quote, but you'll still be in quote mode. You need to type another double quote character (or press Return) to exit quote mode. If you want to print a reverse heart, you should enter reverse mode, type a shift-S, then likely turn reverse mode off. Shift-Off/Rvs (page down on my default VICE mapping) hould turn the reverse mode off (ie, shift performs the top label of the key, namely "off"). Both reverse on and reverse off can be captured in quote mode, so you can programmatically do PRINT "This: {rvs}{shift S}{off} is an reversed heart" as well. Oh, and if you insert spaces (via Shift-Inst/Del) then that's another mode that captures even more keystrokes, but only for the number of spaces you inserted.

Because the Commodore computers, following the old Atari joystick pinout, only had 1 fire button and never successfully progressed from there (though CD32 tried). If it was "one button one move", you'd only ever have 1 move on those platforms. The real problem is that even though the pinout could do 3 buttons easily by repurposing the paddle signals, all the joysticks only ever bothered with 1, and no software "killer app" ever broke out into offering more support.

The "best demos" are those which buck the limitations of the machine the hardest. The biggest achievements on the machine aren't really going to be striking in their intended way if you're not that familiar with those limitations. But still, there's some excellent music, graphics, and full-screen effects to be enjoyed for their own sake.

Frankly, I don't think they're doing any emulation-level programming at all. Whatever VICE does and whatever ARM boards interface with is what you'll end up with.

I do recall quite certainly that a cartridge port was originally promised, and assume the lesser issues of original joystick & IEC ports would be so as well. I believe all of these changes have been done silently, which I am certainly not a fan of.

Complete with a horribly stretched wrong aspect ratio screen. For the size of that case, they might have been able to fit a small CRT.

You don't have to sacrifice the wall charger, if you don't want to. Put a compatible jack on the other end of the c64 power cable and plug the charger into that as with any normal device.

.prg is the correct way to save a Commodore 64 program, be it native on your hard drive, or contained inside a .d64 disk image or .t64 tape image. There aren't many standards to C64 cartridges, besides the rudimentary 8KB/16KB ROM-only carts. Since tapes/floppies held way more and were way cheaper, those went away pretty quickly and cartridges ended up being in the realm of hardware utility functions, not software distribution. Utility carts were produced with whatever funky hardware & wiring they needed to support their features. The .crt file format was created with this extra metadata about utility hardware and cartridge port pins that emulators had to support. If you really want to know how a .crt file works, here's the file format: http://ist.uwaterloo.ca/~schepers/formats/CRT.TXT You'll need to understand the C64's memory mapping facilities fairly well.

For those wondering about lag, 8-bit guy tested both video & audio lag on both versions, on 2 different LCD TVs in game mode: https://youtu.be/p3bwYDRk42w?t=275

Looks like a modem emulator, which is probably running an ESP chip with the same firmware everybody else does. These devices aren't that distinguishable from others being offered (or building yourself out of a NodeMCU).

I played with it at VCFMW. I thought the joystick was absolutely terrible. There's a large dead zone in the middle, so you have to move it pretty far before the signal clicks in, and that distance is different in each direction. I also didn't grow up with that joystick style, and find its ergonomics in generally pretty bad. Playing right next to CRT-connected 80s equipment, there was noticeable lag. However, without that immediate comparison available, it might be okay in that department. And yes, davidcalgary29, the keyboard is nonfunctional and cosmetic only.

Yes, when it comes to graphics, most BASICs loved throwing in Line, Circle, Arc, Fill, etc, which are all but useless for fun, fast, good looking interactive graphics. I'm not aware of any of them that supported tilemap objects or font definitions well. Sprite positioning commands could have been handy, though that's low-hanging fruit that doesn't get you very far with the rest of graphics.

Are these all affiliate/partner referral links being posted? If so, then this really just smells like spam.

As far as graphics go, the PETSCII character set came from machines that did not have bitmap modes, to quickly code interesting shapes from BASIC. I personally believe that for a beginner, it's much easier to stamp around character graphics with PRINT than it is to use line/circle/blit commands to put interesting & interactive graphics on the screen. But yeah, sound would be better with some sort of music commands.

I'd say put a (better) heat sink on your VIC-II chip. The location regularity of the issue coincides with what the VIC-II is doing internally, and it might be failing. Removing more heat could let it stay in a better-functioning state. Stick your finger on it while it's running and see if it's significantly hotter than expected. You might want to swap with a known-working VIC-II as well. I don't think this is indicative of something else killing the chip, but proceed a your own risk as always. How does the error line up with smooth scrolling? POKE 53270, 8 through 15 in order to manually slide things around at the BASIC prompt without reducing to 38-column mode.

As far as I understand it, the VIC-II chip basically generates Y/C signals natively, and the internal color palette is stored in that sort of form. There's nowhere on the motherboard, nor even inside the VIC-II chip itself, that you can tap into RGB. The best you're going to get from the hardware is Y/C. Even if modern TVs had S-Video inputs, they'd still be internal digital conversions & upscales to native resolution. So using an external device to encode to HDMI would generally yield similar or better quality than TV-native S-Video, though maybe also adding latency. The C64 cartridges & replacement motherboards which output VGA and HDMI contain their own FPGA recreation of a fully RGB VIC-II, and aren't using any video source from inside the C64.

It defaults to PAL mode, which is 50Hz. Especially if your system is vsyncing, it'll drift around ±1 fps. There should be Model Settings that will switch to NTSC (60Hz) if you need that compatibility.

I always find it strange when they have lines like "I am the Amiga!" read by a deep male voice.

I love seeing people use full bitmap mode for games that don't require high framerates. It's very underused in the scope of quality C64 games. The character portraits are a bit unintelligible, though. I wonder if those are straight conversions without touchup yet. It looks like this requires EasyFlash, so that's how they can get it looking so good. That's a heck of a lot of graphics on display.

They're using VICE.

and the Time of Day clocks in the CIA chips, but pretty much nothing uses those.