Видео

In an earlier video I made an Arduino project that interfaces with a simple Z80 computer bus and gives you a HESMON-like monitor over the serial port. See ruclips.net/video/A0VpPRWrqHc/видео.html I'd recommend figuring out how to adapt that project to the S100 bus signals: in particular how the Arduino takes control of the bus using BUSRQ, how the Arduino synchronizes with the S100 PHI clock, and maybe extending the monitor commands to include reading/writing I/O ports. Build that into a circuit board for an S100 card and then proceed to poke around on the address bus; dump memory where the ROMs should be and verify they're not corrupted, and see if you can talk directly to any of the other S100 cards given any documentation you can find. You might also look into building an adapter board from your S100 bus to an RC2014 module as you might be able to find some existing modules to do some of the stuff you want or at least give you a starting point for designing your own S100 cards.

I think it would be cheaper/simpler to use an ATtiny instead of a timer and discrete parts. There are several KERNAL switcher mods that use a timer on the restore key like that. Adrian's Digital Basement has a video doing this with an Arduino, and Sven Petersen and bwack adapted this to PIC/ATtiny chips. Ah, I also found a project that works like you suggest and does a reset when you hold restore down: GitHub.com/alexkazik/restore-reset

I'm glad you found it helpful! Let me know how it works out.

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!

I got mine from iFixit and would recommend that. You can also just look up the battery model number on iFixit and use that to search on other sites.

@@TrevorMakeshello. I recently got a used pixel 3a because I so love the design. Just want to ask if Ifixit replacement batteries are worth it? I’m planning to ask my friend from the us to buy me one but not yet decided because I haven’t found much review of their batteries.

The battery from iFixit that I showed in this video is still working great. There are cheaper options, but I think it was worth it. The only thing I didn't like was that the only two options were battery-only and battery + adhesive + tools. You need the adhesive to reattach the back cover of the phone, so they kind of push you to get the tools even if you don't need them.

fr 💀

thumbnail bouta make me act up

Cuz your Wi-Fi is bad 😂

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.

Same

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

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

:(]

He corrected it on the C128.

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.

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.

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.

Good idea! Yeah, I've been thinking about doing exactly that when I pick this project up again

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?

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)

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.

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

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.

The computer gremlins get quirky at night

the byte of 83

Was that the byte of '87?!

Hor hor hor hor

Why