I am going to try and repair/Replace the RAM chips in a commodore 64B (breadbox, grey function keys) I have the chips and am going to replace all of them rather than checking which ones are broken. (only displays 900ish bytes of RAM) How would I go about doing this and what tools do I need besides a soldering iron?
That done, I also have a Commodore 64C that I've been using up to this point. what would you suggest I could do to mod and upgrade it? Since I have 2 and the 64B is the more classic design, I will keep it as it is.
>>912436
All classic micros have a flat memory layout: a single address bus and data bus wend their way around the system, connecting RAM, ROM and peripherals to the same flat address space.
The C64 has basic bank switching, but all it really amounts to is a helper chip fiddling with some address lines to shadow the ROMs.
Write yourself a version of memtest86, step through the areas where RAM is supposed to be, and when you find the addresses where the RAM isn't working, that'll point you to what isn't working.
You can even do it in basic, provided you don't overwrite your program or the BASIC interpreter. You won't be able to test the area that shadows the BASIC ROM though. Given the entire program is just a FOR loop, though, you should be able to write it up in assembler.
http://sta.c64.org/cbm64mem.html
Actually, looking at the C64's expansion port pinout, you could hook a Pi or similar to it, request DMA so the processor disconnects from the bus, and then bit-bang the address and data lines to test all the RAM chips directly.
https://www.c64-wiki.com/index.php/Expansion_Port
>>912436
AFAIK there was never a "B" model, it's just a plain C64. The "C" was originally "CR" for "cost reduced", but Commodore changed the name since they actually raised the price.
There's some mods for the audio circuitry, but other than that people mostly use external expansions, for compatibility.
>>912454
If you do decide to write a memory tester, remember that the color RAM is only 4 bits wide, and the upper nybble is essentially random.
as Far as upgrades go, I want to try an internal SD expansion, a reset button, a RAM expansion to 128k. I also want to see if their is any way to make the read speed or loading time frequency reduce. If this can be fixed by simply more RAM, I'm all for that, be it internal or external.
>>912454
>Actually, looking at the C64's expansion port pinout, you could hook a Pi or similar to it, request DMA so the processor disconnects from the bus, and then bit-bang the address and data lines to test all the RAM chips directly.
I would fucking lauch if somebody uses that rpi compute module to make an expansion card for a C64. Could it in theory take over the machine as the processor by bit-banging the busses to manipulate shit?
>>912523
Yes.
All you do is assert DMA and leave it asserted, and the processor disconnects from the bus and never reconnects again.
Though I'm not sure you could still call that a C64. Far better to assert that you're a cartridge (and thus get yourself mapped over ~40k of the address space), and become the greatest peripheral the C64 has ever seen.
>>912502
For an SD card you'll have to make a floppy emulator, or replace the kernel ROMs (which will break compatibility). For a RAM expansion you'll have to figure out a workable memory map and banking scheme.
How familiar are you with the internals of the C64 and 1541? The majority of C64 software that accesses the disk (practically all games and demos) uses their own speedloaders, which are very closely tied to the hardware. You'd basically have to adapt every piece of software individually. The disk usage patterns are also different from modern computers, most games will load each data item only once. There are of course exceptions like the Ultima series, Pirates! and other open world-style games. Single-file apps can of course be made to load instantly, but they're not that interesting.
There were two styles of memory expansions sold for the C64. Commodore's own was basically a memory disk that used DMA to transfer data back and forth. GeoRAM mapped the expansion memory into the C64's memory map and used bank switching.
See also http://www.1541ultimate.net/
>>912629
The cartridge slot sees everything that goes over the data bus. No reason it couldn't impersonate the actual floppy disk device and avoid every one of these compatibility problems.
>>912643
The floppy drive is connected over a bit-banged serial bus. You can see accesses to the CIA chips, but that won't help you much.
>>912662
Yes it will, because you can map them out and impersonate them.
>>912794
Writes to them are easy to catch, but what are you going to do with reads? Overdrive the bus brutally enough so that your data wins?
>>912794
It's not going to help you load any faster, because you're still clocking in the bits in software. Plus, you still need to provide the 1541 emulation, so you'll end up with the 1541 Ultimate anyway. For speeding up single files, you're better off writing an expansion ROM that hooks the kernel file load routine and then talks to the expansion hardware. Again, like the 1541 Ultimate does.
Just in case you were not aware, the 1541 drive has its own CPU, and speedloaders upload their own code that executes on the drive, replacing the communications routines, and sometimes also bits like GCR decoding.
If you don't care about compatibility, there are mods like DolphinDOS that achieve much greater speedups. It might also be possible to undo the hardware bug that forced Commodore to use the slow bit-banged serial instead of the hardware shift registers as originally intended (a 1571 in burst mode is essentially what the 1541 was intended to be).
>>912800
I don't think you understand how bank-switching works.
Once you've unmapped the device, it will neither read from, nor write to the bus; the emulated device in your cartridge will instead.
>>912844
I think you lack ambition.
Detect a read or write to the device, then assert DMA to disconnect and halt the CPU. Dump all the RAM that's mapped. Overwrite it with a landing zone, and code that maps the rest of the RAM back in, and dumps the processor state. The cartridge snoops the writes, saves the processor state, reasserts DMA, dumps the remaining memory. Processor enabled again, maps I/O back in.
State is used to emulate a C64 and its disk drive inside the cartridge, as fast as it can go. MMIO that's not the floppy drive is passed to the real hardware.
When there's been no disk access for several emulated wall-seconds, the same technique in reverse DMAs the emulated processor and RAM state onto the real processor and RAM, and execution resumes as normal.
Compatibility is as good as you can emulate the drive, and (assuming no real-world I/O during the load) the C64's memory bandwidth would allow the whole operation to occur in less than 20ms.
>>912902
If you halt the CPU you fuck up everything that does something else at the same time (plays music, draws graphics etc.) You can't have cycle-exact timing and also fast forward.
>>913015
That will do irreparable harm to your doing-nothing-and-watching-the-computer-load experience?
>>912862
Apparently not how C64's variety works. Usually IO chips aren't a part of it.
I guess I'll read about it some time.
>>912467
>AFAIK there was never a "B" model
The BBC Mirco had a B model.
>>913215
>Next I'm sure you'll tell us how that's relevant.
Maybe that's where the confusion arose. Next I'm sure you'll tell us how being that obtuse IRL makes you popular.
>>913221
Or maybe it's because it came before the C model. But don't worry, I'm sure your mum likes you very much.
>>913277
>Or maybe it's because it came before the C model
That's also a possibility. We can only speculate on the inner workings of the minds of others.
>>913215
Y'said it was impossible to do a fast-load through the cartridge slot.
If the issue was instead whether you'd enjoy using said, you should have said so upfront.
Personally, I'd rather the game loaded in 80ms, but each to his own.
