The computer gremlins get quirky at night

the byte of 83

Was that the byte of '87?!

Hor hor hor hor

Why

I'd consider using a cheap microcontroller like an ATtiny for precise and adjustable timing, as the timing is slightly different for other KERNALs like JiffyDos. The exact timing can be figured out with a scope or logic analyzer watching the reset and ROML lines while EXROM is held low-after reset you'll see two clusters of accesses to ROML, first to check the signature, then later for the memory test. For the timing circuit EXROM should be released between those two points, otherwise MEMTOP will be set to $8000 instead of $A000.

Check the link to Sven's Techsite - he did exactly that. I think a better solution could be to do the normal memory test first and only check the signature if ROM is detected there (MEMTOP set to 8000)

After market reset switch mods seem to have been pretty popular. The C64 I showed in the video had one installed at a repair shop in 1983 according to the receipt in the box.

Ive just been rewatching IT crowd, so thanks Roy!

I used a metallic paperclip to short GND and RESET on the user port. Later on I rigged a switchable short connected to pins on the SID chip directly on the board. It worked to install POKES in many older games. More recent games, not so much. Some used the CBM80 trick (Krakout did this) to prevent the user from resetting. Moreover, the cold start routine destroys some of the contents of the RAM, like bits of the stack and BASIC/KERNEL variables below $400, as well as the screen memory at $400-$7ff. Larger games liked to store data or code in there. So I bought an Action Replay cartridge in 1989. It also had freeze functionality.

I imagine this is several decades old news to long time C64 assembly coders, but it was new to me and I thought it would be a fun project to learn KickAssembler.

Same

You're correct, the lines start climbing back up while the button is held down, not when it's released. I didn't design this circuit; it's an old one that had been shared in a few places, but I agree there's room for improvement. Ray Carlsen's circuit portcommodore.com/rcarlsen/cbm/c64/RESET%20CIRCUITS/c64%20cold%20reset.jpg looks like an improvement, but would need to be done internally rather than on the cartridge port lines. I'm already working on a follow up using a single microcontroller which will watch the ROML line for when to release EXROM, rather than relying on a capacitor for crude timing.

It does sound quite extreme, perhaps an urban legend. In the link to Sven's Techsite, he shows a series of memory dumps where it took several times switching the power off, up to 60 seconds, before the CBM80 signature cleared out (though you can see corrupted bytes here and there even after 5 seconds).

@@TrevorMakes maybe the commodore shouldve had a routine in rom to clear (and test)all the ram addresses before everything else, like in most sinclair machines ?😉

@andygozzo72 There is a non-destructive memory test, but it just sets the top of free BASIC RAM to wherever it fails first, usually either cartridge or BASIC ROM. Not really a proper diagnostic. (but I do think that the memory test should have been done first and skipped the signature check if RAM had been found there) I think there is some benefit to not clearing the RAM though, since it does allow you to recover what was there previously... Commodore just goofed by making the old contents of RAM able to influence the startup and NMI procedures.

It would strongly depend on temperature

The link in the description to Sven's Techsite mentions Gyruss using this, but otherwise I never found a specific list of games. My impression from forum posts and other articles was that this was mainly used for copy protection in games as you suggest. I do think a more practical use for this type of reset circuit would be for cracking copy protected code which would otherwise be cleared from RAM if you switch the power off.

I think those use VICE for emulation, which should work, but I'm not sure if there are buttons mapped for reset and restore. Give it a try!

fr 💀

thumbnail bouta make me act up

The UNO does have 32K Flash for just code which is pretty comfortable, but the 2K RAM is definitely easy to use up.

@@TrevorMakes yeah, I've never had problems with ROM size, but those 2K of RAM are apain sometimes hahah

They finally implemented ASM there? Good to know, I never used Arduinos TBH, as I only like coding in ASM for those AVRs (both for fun and work, as I hate micro-optimizing the C code there), and it only takes a somewhat $5 programmer for the job :)

@@TheBypasser In the end it's an Atmega 328P, you can program any microcontroller in ASM :) You can access the registers in the Arduino IDE tho, gotta have a very good reason to spend the extra time writing directly in Assembly imo.

@@orti1283 I thought they have implemented it in the IDE. Never tried it tho, as IMO the best IDE for AVRASM is the older AVRStudio 4 (the pre-VS-one), as the debugging is just awesome there. And yes, there are numerous reasons to use ASM for those cores (which is not that long to code, and takes way less time compared to micro-optimizing the C code), especially for the industrial devices: no "code chaos" (e.g. changing one line will not affect the whole Flash - the address constants only, and that is it), clock-accurate routines, overlapping interrupt code, fast port control by pre-loading the port states on the registers and keeping them static throughout the whole process etc.

Yup, but only if the code hasn't prevented you from being able to exit the program to type in BASIC commands. Side note, even with the reset circuit in this video, you still need to do the poke as you describe to get STOP+RESTORE to work again.

Get Bill Gates on the line, there's a critical bug in his BASIC code

:(]

He corrected it on the C128.

Good idea about periodically refreshing the signature and other vectors-would be pretty annoying to have both the IRQ and NMI going and patching up each other's vectors and timer flags. I suppose you could also add a BASIC wedge that would silently block POKEs to just those address ranges.

​@@TrevorMakesI'm not sure about what should be achieved here... given these computers' mostly isolated nature, real viruses are hard to write, as they need to propagate, and that's nontrivial in this case. Any hacks, even like this in the video can be classified as intended behavior, hard to catch this as infection..

@chipetke this is a completely contrived example meant for nothing more than displaying an interesting animation. The Codebase64 site does have a page about C64 viruses if you'd be interested in reading further.

In VICE at least it does work. "Reset machine CPU" will keep the signature in tact, while "Power cycle machine" will clear it out. Doesn't really cause any harm

@@TrevorMakes Well, of course "no harm", but it's good to know that VICE is so accurate that it can get borked like a real C64

The CPU starts executing the code at FCE2 (vector from FFFC), shown in the last part of the video. The subroutine at FD02 is where it checks the signature. I suppose they could have put the signature in the other cartridge ROM at A000, which defaults to BASIC ROM instead of RAM.

Right.. It's not the CPU, but the kernal ROM that checks for the cartridge signature in the memory map at 8000, so it's not that insanely stupid. It's needed so the cartridge can run automatically when inserted and the machine is powered on, otherwise you would have to type something like SYS 49152 or SYS 32768 to start the cartridge. This is the reason SYS 32768 (8000), SYS 49152 (C000) or SYS 64738 (soft reset) were often used to start games that were dumped from cartridge to disk. This, along with bank switching to RAM for almost the entire memory map is also what made it possible to dump cartridge games to disk and have it work with little or no modification (unless there was copy protection in the cartridge ROM)

@@seansretroverse9082 The point is, I'm not a C64 user. I was a BBC Micro user and wrote a fair amount of commercial games, so I knew a lot about how the 6502/6510 initialized itself before starting to execute instructions. The BBC didn't have all the extra memory layout of the C64, just had 0000 - FFFF with everything above 8000 being paged in ROMs and other hardware registers at FE00. Now the MOS will initialise through the reset vector at FFFC, which is actually a CPU requirement and then start to initialize the ROMs, offering services to each in terms of grabbing its own workspace etc. The fact that the MOS looks at 8000 before starting the ROM servicing is a little insane. I can get why they did it, but if the cartridge slot had been interfaced correctly, it could have been the first one offered the services rather than some crazy memory hack to make it happen. Like I said, I don't know the C64 well, since I never had one, but one of the things that made BBC stand out was the bonkers attention to detail in the MOS. Even to the point that it had values for colours for up to 24bit depth, but obviously that never came, but it was still an amazing bit of programming. Then the BBC Master with it's paged RAM, and ROM initialization was another piece of coding wizardry. It's just mental having something so hacky in a machine like the C64 that I love watching demos on.

What's insanely stupid is that the reset code doesn't check it's actually ROM that is checked for the signature before going there on reset. I suppose by having the ROM cartridge itself switch out the RAM it made it harder to get a ROM image into that RAM to be able to modify it in any way - an early form of DRM?

Cuz your Wi-Fi is bad 😂