About 30 years ago I got a 1764. One day I was walking by a computer store and noticed some SIMMs in the bushes outside (some litterbug). I picked them up and they were filled with 41256 chips! I think someone upgraded their Mac and just tossed the old modules out. Different times I guess. Once at home I managed to transplant the chips and was rewarded with a 512K REU. I still use it today with those chips. And I have the same straightener too! Oh and the cartridge needs to be supported if it's used without the case, it hangs down too much and I think that might explain the contact issues. Use standoffs or something. And yes, those PLCC sockets are also weirdly unreliable. I remember putting a spacer under the REC to force better contact in the socket.
I just wish Commodore would have put a cartridge pass-thru on these units like they did with the Magic Voice and SFX Sound Expander, so you have the benefit of the extra RAM while still being able to use other utility cartridges and stuff. Excellent video as always, Jan!
You could do this with a port expander, but most utility cartridges cannot coexist with the REU, even if you manage to physically connect them using a port expander. Even some of the larger than 16k game cartridges will not work when it is present. The reason is that it uses the io2 area ($df00-dfff) and many utility cartridges require that area as well. There are 2 which are known to work together with an REU as they limit themselves to the io1 area: - supersnapshot - retro replay But none of the action replay, final cartridge, epyx fastload, expert cartridge etc can coexist with it. All those cartridges need io space to do their bank switching and redirecting of the io vectors.
@@c128stuff Thank you! I figured that maybe the power draw from both an REU * and * a cartridge would be too much for the expansion port to handle, or something like that. I didn't consider how the carts all fit into the memory map. Very interesting!
@@LeftoverBeefcake When using the upgraded power supply which was supposed to come with the 1764 (some shops would sell those separately for some reason.. money? nah), power should be no problem. Same for the C128. With an original C64 power supply... the 1764 already pushes that over the limit.. but it will work often.. just stresses that brick of death even more. I'm (still) using a 128D, which has a mostly equivalent internal PSU, which currently powers an extra sid chip, an U2+ cart with usb storage and a pi zero with rgb2hdmi hat from the cartridge port. The same machine also has an sd2iec powered from the user port, and a 1531 datasette which uses the regulated 5v line for its electronics. That all has to come from the common regulated 5v rail. I am pretty close to the limit with that probably.. and am certainly over the 450ma max draw on the cartridge port, but there are 2 5v traces there, so I'm not too worried about that, and the psu is not being stressed yet (and has active cooling)
I have been watching many of the episode you have put out, and I just have to say that they are nice, and that I have both enjoyed them and found inspiration in them. Thank you, Herr Beta!
I bought a 1764 last year to play Sam's Journey (NTSC) but it has remained on the shelf until Sonic was released. I got the itch and upgraded to 512k as well so the entire game can be loaded to the REU. It works quite well, especially with the fast loader and Sonic on a 1581 disk. (small flex) Acetone makes a great glue for broken ABS plastic. It fully dissolves ABS so when it dries it is as strong as new. It can be tricky to keep the ABS wet long enough to adequately dissolve the interface between the broken parts though because acetone evaporates so quickly. Sometimes I dissolve PVC pieces cut up from plumbing fittings in acetone over night (with occasional stirring) and use it as glue the next day. It works great as it is both a filler and it holds on to the acetone longer so it really bonds to the broken parts well.
I foresee it's quickly going to become a very frequently used tool in the Beta lab. People kept mentioning it in the comments so I finally gave in and don't regret it... :D
I had one of those. With a bit of soldering and chip piggybacking and a tweaks to the software you can have one with 2 megabytes in it. Couldn't get the cash to fully populate it that far, but 1 meg worked. You needed a few glue chips (IIRC a few gates and a couple latches.).
I had a 1750 connected to my 128 back in the day for a custom programmed bulletin board system I used and had it storing the BBS messages in the extra banks of RAM. It was a nice addition, even if it did not actually expand the amount of usable memory for core BASIC programs. If the Sonic the Hedgehog game had been available back at that time then Commodore would have sold a million of the 1764/1750 modules, but since it essentially was just a GEOS RAM disk for normal users, it was rarely ever seen.
You should populate the EPROM too. I see a jumper (not populated) there which can be the chip select for the EPROM. Maybe can be used to keep the expansion cart related software there?
The PCB looks like the exact same color of solder mask as my beloved Amiga 500. I wonder if the same production facility built both machines. I know green solder mask is pretty much universal from this era, but this color is somewhat distinct.
Great stuff Jan. I have both an upgraded 1764 (256k to 512k) as well my 512k 1750 that I ran my BBS off of, Color 64 BBS using it as a 512k RAM Disk. The BBS would boot off a start disk and it could copy all of the system overlays over to the RAMDisk when you'd boot the BBS the first time and then only the message bases, password file, etc, ran off the floppy drives but navigating around the BBS the different areas of the BBS would load nearly instantly. With SFD-1001 floppy drives they worked really great for the era, late 80s, early 90s. Later on I had an ICT Data Chief HD that was fast enough you didn't need the ram disk anymore, but they sure worked great. I also used it a bit for GEOS 64 and GEOS 128 which it also worked great for.
@@JanBeta Yeah those were such fun days! Met some lifelong friends through the C64 BBS scene :) I wish I still had the ICT Data Chief as I don't think I've ever seen one since I sold mine to another sysop in the mid 90s.
@@danjmcs SFD-1001 is a very nice drive indeed. I had one of the very first to come out of Commodore, later got a second one. My dad had 2 8250 drives, and I used the 1001s as development platform for software I wrote for his company. I used the Commodore IEEE-488 interface, tho one which was slightly modified with help from Commodore.
I saw a documentary about that BBC ident once: It was know as the "Computer Originated World". It was basically a posh version of what Jan just demoed - a dedicated hardware box with a (for the time) colossal amount of memory which was enough to store all of the frames of the spinning globe, and it just flicked between them to produce the animation effect.
Commodore did make the REU RAM available in BASIC 7, but obviously BASIC 2 was already many years old before the REU was available for the Commodore C64
Love your content Jan! Do you know Robin here on youtube? (8-bit show and tell) he's a really lovely guy - would be cool to see you guys do a hardware/software collab on investigating strange and unusual C64 carts!
On a 1700 and 1750, there is a socket for a C128 external function rom. As a 1764 uses the same pcb (and can easily be modified to be 'c128 compatible'), the place for that socket is there as well.
I wonder what the address space of that rom socket is.. Could some clever programmer hack GEOS to get the OS onto a ROM and have an instant on expanded GOES on there? A few bytes for a startup routine that checks for one of the function keys being held down at startup. If so, launch into geos, if not, unmap the ROM from memory and startup normally. Now that would be a cool setup!....
I added a three-position slide switch along the case edge, to choose what range of address the ROM appears. The address are cuttable pad pairs, that can reclose with a ball of solder.
Judging by those crappy "QC pass" & "Burn In" stickers, looks like it was probably made in the same factory that was also producing the Amiga A500's at the time.
I remember learning about these things, but they were never too useful since barely any software took advantage of them. It's a bit of a chicken/egg problem. They're hard to sell because it was mostly just GEOS that used it, and it's hard to justify writing software for it because there's so few people that bought them. So it's very cool that someone managed to use the REU in a game. It maybe have taken more than 3 decades, but I'm quite impressed by the effort.
For GEOS it was totally worth having tho. Besides GEOS, there are some development tools which can use it as temp storage for assembly/compilation, and there is ramdos which lets you use it as a ramdisk. Of course.. while BASIC 2 does not support it, BASIC 7 on the C128 does.. but.. that is mostly usefull for people who were writing software.. for the typical non developer and non GEOS user, there wasn't a real use for them.
Hello and another great video!!! As always!! I have two 1764's my unmodified 256K runs Sonic perfectly on my C64. My 2nd on has 512K wrote on the case with a black permanent marker. When I've tried to use that one three times its shows the loading bar but then just sit there never starting the game? I download the RAM test disk and when I ran it on the 256K it passed first time. when I ran it on the 512K one I got an error report (should of wrote it down or took a screen shot!) so I ran it again and it passed. I then ran it around 15 more times and it always passed. Any thoughts? I had read a post somewhere that someone was having problems and they had faster RAM for the added 256K and they changed the old RAM to the same faster speed and then the REU worked great. Any thought on why my 512K is doing this? I saw you used faster RAM for the extra RAM. I haven't opened it up to see if mine even has different RAM speeds.
I know it's a two year old video. Yes, everything but the plcc chip can be bought and found. The plcc can not be gotten at all anymore outside of another reu.
Maybe somebody knows where the story is for this (told by Bil Herd), but isn't this the cart they made for the C128 because Commodore printed billboard adverts saying that the C128 was upgradeable to 512kb, but nobody had even designed that ram expansion yet, so they had to build it. When the press asked the marketing guy where the memory expansion would go on the C128, he said "in the back"
I remember when I got my C64 and fixed it. I needed the U2+ so I could run Sam's Journey. But the game was super glitchy as hell. I'm like what's going on? Eventually I got it to work, but I didn't know what I had done. What had happened was I was using Epyx as my fast load and it was incompatible with the REU so it was disabled. I accidentally told the U2+ to bypass it one time. Eventually I discovered that Retro Replay worked perfectly with the REU. Now I don't even need the REU support for Sam's Journey since my C64 now does both PAL and NTSC instead of just NTSC. Anyway.......it occurs to me you could pop a retro replay ROM into that extra spot and it would work just fine with a built in compatible fast loader. I can configure mine from 256kb to16mb. Honestly I don't think it matters. I'm not sure anything uses that much memory anyway. In games the only reason for it to exist is to copy memory faster. They don't even use the ram.
The socket can be used for rom, but without modification this only works on a C128 in 128 mode. To use a retro replay rom, you'd need some additional modifications, because a retro replay, like other utility cartridges, has additional hardware to handle the bank switching it needs.
A modern replacement could maybe be made with a 512K static RAM and some programmable logic. VIAs are only for interconnection. When it takes a pin in is a pad.
There are open source RAM carts available out there with at least 2 megs of memory (if not more), though they act like the old GeoRAM devices since they are missing Commodore's special DMA chip for the blazing fast data transfers. Also the 1541 Ultimate cartridges have REU support.
@@LeftoverBeefcake there is an open source REU clone in development, but.. it does take a bit more than one would expect. The timing requirements for getting DMA right are rather tight, and combined with the number of registers makes for needing a pretty fast microcontroller, or a small fpga.
@@MarianoLu I don't think the source for it is public yet, but they have been posting regular progress updates to some of the c64 related groups on facebook.
C= were an odd company. They cut costs on the case (no screws) but the thing had to ship with an uprated PSU (expensive and heavy). I suppose there was no way to lower power consumption back in the day. Thanks for the fascinating video Jan.
CMD later bought the remaining rec chips from Commodore and made the 1750XL REU, which uses more modern ram chips, and has low enough power consumption to not require an upgraded power supply.
I think the timings are very marginal, so it probably fails frequently with slight contact issues or interference from wonky power supplies. Took me quite some time to clean up the cartridge connector to keep it working reliably. :D
Considering that loading cartridges was the fastest and generally most convenient way of loading programs onto the C64, was this expansion only expected to work in GEOS for productivity tasks or was there something like a port splitter to allow more than one device to use the cartridge port at the same time? I know the ROM was never implemented by Commodore but if it had been it would make sense to me if it was set up to load GEOS or some other utility that could really make use of the expanded RAM. I suppose it could be preloaded with Sonic instead...
First of all, port expanders exist. Second, cartridges, for most of the lifespan of the C64 were far from the preferred way to load games. Yes, they were faster than disk, but initially they were limited to either 16k, or very expensive to make due to additional hardware to handle multiple rom banks. That made them way expensive compared to disk releases until much later in the 1980s, after the REU was already released. The C64GS did revive the cartridges somewhat and they are more popular now than they have ever been... but are still not the primary way in which most people load games.
If SEGA released this on the C64, nobody would even have bought the game: They would share it for free on the schoolyard - thanx to cracker groups. The caps are for decoupling, not for smoothing the voltage. Without them, current peaks would cause voltage drops on the other chips, causing them to glitch. Peaks would induce changing currents that would flow all over the board from/to the buffer caps instead of staying local near the chips, causing broad spectrum interference and messing up the local ground and supply potentials.
Piracy aside, since nobody but the most hard core enthusiast would have had an REU, they couldn't have sold many copies anyway and many of those sold would have been returned as not working by people who didn't read or understand the system requirements! Also, just think how long the tape loading would have taken! :-)
I was wondering two things: * The original set of RAM chips had a set of supporing capacitors, presumable to stabilise charge retention. Why didn't the new chips require them? * The original 1750 took some extra amperage and required a more powerful PSU than the usual one to work on the C64. Why didn't your upgrade (which, as you say, turned the 1764 into a 1750) require any of that? What did Commodore do wrong? Or, what did you do right?
Both questions are answered in the video, if I remember correctly. ;) The capacitors for the additional RAM were already populated (for whatever reason, probably because it was cheaper to have the board ready for additional RAM for the 1750 production runs with the same PCB). I used my home made power supply which is beefier than the original C64 PSU. Using the original PSU would probably blow it up relatively quickly as the additional RAM chips draw quite a bit of current on the 5V rail (which is somewhat marginal on the og PSU anyway).
GEOS is helped by more ram, but that especially matters for how big a document you can use in applications. GEOS does not have virtual memory, does not do swapping/paging, so more memory does not make the core OS faster as such. Loading stuff from a ram disk of course does make things faster. But, the REU does make GEOS faster in another way also. GEOS has quite a need to copy blocks of ram around, and an REU can be used as a kind of primitive blitter. This is something which also affects screen updates etc a lot, and hence will be most noticeable. That is also why GEORAM is not a 100% alternative for an REU. It does get you the ability to use larger documents and have a ram disk, but it can't do this blitter like stuff.
Yes! I only read about that after finishing this video. Tested it on my C128 in the meantime and didn't run into any issues (yet) without the resistor. Must be a very slight tweak. I added a document mentioning it to the video description, too. Thanks for mentioning it!
@@JanBeta if I remember correctly, it is a pull-up on the dma line. There is also a pull-up on that line in the 64/128. That could make dma go active a fraction slower, and inactive a fraction faster. Fred Bowen said it was needed, but I haven't heard of cases where not having made thatt change caused trouble on either a 128 or 64.
Good day Jan from the US - Quick question about the links above... most of them work fine, but the ones for commodore.software come up with errors... wanted to check to see if there is something up with the link, or if on your end, they work fine.... Planning to do this exact same thing you are - the schematics and the software are certainly a plus... Thanks for keeping vintage commodore alive!
Sehr schöne Info Doku Tuning Anleitung ! Top. Leider nur in Englisch ! Bitte das gleiche in Deutsch. Und wenn es sein muß eben mit englischen Untertiteln. Danke und gesund bleiben.
64k but basic only can access 32k? And some clever (careful) code can access 68k? and some REALLY clever code to access 512k lol. Sonic on the C64 wow, that would have been a killer app back in the day.
I have yet to try it in GEOS but as far as I know it's super useful for it and speeds up the whole system a lot in GEOS. It allegedly can load the whole base system into RAM plus use it as a RAM disk.
I have a working 1700 but it is so precious I do not use it. I am happy with my 1541 Ultimate II+ that can be configured from a 128KB to 16MB REU. Congratulations on having a working 1764 version.
