The following suggest themselves as obvious:
30-pin SIMMS (the 8-bit-wide kind) are so obsolete as to be essentially free.
Cartridge cases and prototyping boards are less so, but still commonly available on eBay.
REUs are hard to find and expensive to obtain once you do.
There is almost nothing in the Commodore REUs, just RAM chips and some glue-logic chips AFAICT.
So, why not roll my own? The trouble is, I have no idea what I'd need to do to make it compatible with all the existing ones, like the Commodore ones and the SuperCPU's RAMCard and the 1750XL and so on and so forth. What sort of API do they present? Do I need to graft the thing in to the C128 memory map at some certain range of addresses? How does it work?
Quote from: gsteemso on May 18, 2008, 03:36 PM
The following suggest themselves as obvious:
30-pin SIMMS (the 8-bit-wide kind) are so obsolete as to be essentially free.
Cartridge cases and prototyping boards are less so, but still commonly available on eBay.
REUs are hard to find and expensive to obtain once you do.
There is almost nothing in the Commodore REUs, just RAM chips and some glue-logic chips AFAICT.
So, why not roll my own? The trouble is, I have no idea what I'd need to do to make it compatible with all the existing ones, like the Commodore ones and the SuperCPU's RAMCard and the 1750XL and so on and so forth. What sort of API do they present? Do I need to graft the thing in to the C128 memory map at some certain range of addresses? How does it work?
The key to the REU's operation is its custom DMA controller, not the RAM or glue logic. Your questions would be best answered by perusing the Commodore 128 programmer's reference guide, as well as other literature that is available here. Trying to explain the REU in a post is a bit like trying to explain the workings of the stock market in a 100 word essay.
BTW, calling this device a "RAM expansion unit" is technically incorrect, as it does not appear anywhere in the 128's memory map other than as a few registers in the I/O block.
QuoteBTW, calling this device a "RAM expansion unit" is technically incorrect, as it does not appear anywhere in the 128's memory map other than as a few registers in the I/O block.
While what you say is true, these units have been called REUs since the beginning. They even have "RAM EXPANSION" stamped on their cases. The reason they're so lame is that they were made to be C64-compatible, which couldn't do banks like the C128. The reason they're so great is because of the super-speedy DMA controller. Why they didn't build THAT into the C128 is beyond me. It would have made banking much more fun.
Trying to figure out just how CBM's REUs' DMA controllers work has worn down many a fine Commodore hacker. (Hey! THREE acronyms in a row! Bonus points for a double possessive! I win!)
Quote from: airship on May 19, 2008, 06:56 AM
While what you say is true, these units have been called REUs since the beginning. They even have "RAM EXPANSION" stamped on their cases.
I know they have been, which never should have been the case. Oops! Accidental pun!
CBM should have made it possible to add RAM to the interior of the 128, accessible through MMU register twiddling. The REU was, in my dinosaurish opinion, a poor substitute.
At one time I was looking at trying to use the DMA controller in the REU to interface with an NCR 53C90A SCSI ASIC as part of an upgraded Lt. Kernal host adapter. Unfortunately, CSG was unwilling to provide the needed technical info about the DMA controller and the project never got past the head-scratching stage.
Quote from: airship on May 19, 2008, 06:56 AMWhile what you say is true, these units have been called REUs since the beginning. They even have "RAM EXPANSION" stamped on their cases.
Bil Herd corrected me when I called them "ram expansion units". He said they (the engineers) always called them "ram expanders".
Quote from: airship on May 19, 2008, 06:56 AMTrying to figure out just how CBM's REUs' DMA controllers work has worn down many a fine Commodore hacker.
I wonder how far Adrian "dW" Gonzalez has progressed in cloning the REC chip. I should send him an e-mail.
Truly,
Robert Bernardo
Fresno Commodore User Group
CommVEx v4 website - http://www.portcommodore.com/commvex
Unless I'm mistaken, I believe Mangelore is working at making his own RAM expander, based on the design of CMD's 1750XL.
-Andrew
Gideon Zweijtzer has included a 1750-compatible REU in the 1541 Ultimate, presumably re-impmenting the DMA controller in the FPGA together with the 1541 electronics and mechanics. He has vowed to eventually make the FPGA core open source, IIRC. Using an FPGA with the REU part of Gideon's core is probably the way to go.
Quote from: bacon on May 20, 2008, 12:38 AM
Gideon Zweijtzer has included a 1750-compatible REU in the 1541 Ultimate, presumably re-impmenting the DMA controller in the FPGA...
From where did you get that information?
Truly,
Robert Bernardo
Fresno Commodore User Group
CommVEx v4 website - http://www.portcommodore.com/commvex
Quote from: Andrew Wiskow on May 19, 2008, 11:57 PM
Unless I'm mistaken, I believe Mangelore is working at making his own RAM expander, based on the design of CMD's 1750XL.
The CMD 1750XL uses the same custom DMA controller chip as Commodore's 1750, which no-one has successfully cloned so far.
Quote from: RobertB on May 20, 2008, 01:48 AM
Quote from: bacon on May 20, 2008, 12:38 AM
Gideon Zweijtzer has included a 1750-compatible REU in the 1541 Ultimate, presumably re-impmenting the DMA controller in the FPGA...
From where did you get that information?
If you tootle over to http://www.1541ultimate.net you shall see for yourself ... plus I have in my grubby mitts a 1541Ultimate with 32Mb of RAM and it does indeed give you an REU of up to 16Mb in size :-)
Go order one now .. you know you NEEEEEEEDDDDD it! ;-)
Mark
Quote from: Mark Smith on May 20, 2008, 06:23 AM
If you tootle over to http://www.1541ultimate.net you shall see for yourself ...
Specifically, I was asking if a DMA controller was implemented (cloned) in the 1541 Ultimate. I see no evidence of that at the website. However, if I meet up with Gideon in mid-June, I will ask him directly.
Quote from: Mark Smith on May 20, 2008, 06:23 AM...it does indeed give you an REU of up to 16Mb in size
There has been no verification that GEOS/Wheels makes full use of the 1541 Ultimate's 16 meg (unlike the full use of a RAMLink with 16 meg or a SuperCPU with 16 meg). The only verification I have is that 2 megs is usable with GEOS/Wheels.
Quote from: Mark Smith on May 20, 2008, 06:23 AM
Go order one now .. you know you NEEEEEEEDDDDD it! ;-)
Heh, today I ordered another MMC2IEC (with SD2IEC firmware) from NKCElectronics.com At $45 US (not including postage), that is an easier price with which I can live. This extra board will be a gift to a European friend.
Truly,
Robert Bernardo
Fresno Commodore User Group
CommVEx v4 website - http://www.portcommodore.com/commvex
Robert, the MMC2IEC looks very promising. I assume it uses little enough current that you could steal the DC supply voltage it needs from the user port?
Quote from: airship on May 21, 2008, 01:25 AM
I assume it uses little enough current that you could steal the DC supply voltage it needs from the user port?
Yes, IIRC it is less than 200 milliamps, and so getting power from the user port is possible.
Truly,
Robert Bernardo
Fresno Commodore User Group
CommVEx v4 website - http://www.portcommodore.com/commvex
Cheese, what a nuisance. Does anyone know who currently owns the design for the REC chip? If they could be persuaded to release it (or at least its design parameters) into the public domain, a lot of things would get easier.
Quote from: gsteemso on May 21, 2008, 03:34 PM
Cheese, what a nuisance. Does anyone know who currently owns the design for the REC chip? If they could be persuaded to release it (or at least its design parameters) into the public domain, a lot of things would get easier.
<Grin> Commodore Semiconductor Group owns the REC design. Let us know if you are able to contact them.
Quote from: RobertB on May 20, 2008, 03:05 PM
Quote from: Mark Smith on May 20, 2008, 06:23 AM
If you tootle over to http://www.1541ultimate.net you shall see for yourself ...
Specifically, I was asking if a DMA controller was implemented (cloned) in the 1541 Ultimate. I see no evidence of that at the website. However, if I meet up with Gideon in mid-June, I will ask him directly.
Note that I used the word "presumably". Since the REU in the 1541 Ultimate is 17XX compatible (AFAIK), it's reasonable to presume that the functional equivalence of the REC chip, or at least enough of it to make it compatible, is implemented in the FPGA. By what other mechanism do you propose that he might have made the REU compatible?
Quote from: bacon on May 22, 2008, 01:33 AM
Note that I used the word "presumably".
Since you cannot wait until I talk to Gideon face-to-face, I have sent him an e-mail. I'll let you know the results.
Truly,
Robert Bernardo
Fresno Commodore User Group
CommVEx v4 website - http://www.portcommodore.com/commvex
Oh, I can wait. I was just engaging in some idle speculation.
Quote from: bacon on May 22, 2008, 01:33 AM
Since the REU in the 1541 Ultimate is 17XX compatible (AFAIK), it's reasonable to presume that the functional equivalence of the REC chip, or at least enough of it to make it compatible, is implemented in the FPGA.
It is compatible and your presumption is both reasonable and accurate. This appears to be a case of someone not having the technical savvy to comprehend the matter they're discussing.
Quote from: Golan Klinger on May 22, 2008, 11:44 PM
It is compatible and your presumption is both reasonable and accurate. This appears to be a case of someone not having the technical savvy to comprehend the matter they're discussing.
From: Gideon Zweijtzer
Date: Thu, May 22, 2008 1:22 am
Hi Robert!
What a surprise to hear from you! It has sure been a long time since we
have met. If you are there on the Commodore Show in Maarssen on June 21,
then I'll make sure that I'll be there, too. I would love to know about
the 'scene' in the USA.
> In the 1541 Ultimate Plus, you have implemented a ram
> expander; question - is it an exact clone of the
> Commodore 17xx Ram Expansion Unit? Have you been
> able to duplicate the functions of the REC chip
> within the Commodore 17xx Ram Expansion Unit?
The basic answer is "yes". The 1541U+ has a 17xx compatible RAM expander
mode, with selectable amount of memory. I have successfully tested it with
some programs, but now that the 1541U+ is "in the field", there are some
problems still with the REC emulation, still. This will be addressed soon,
now that I have an actual 1764 on my desk.
Gideon
Quote from: BigDumbDinosaur on May 22, 2008, 12:32 AM
Quote from: gsteemso on May 21, 2008, 03:34 PM
Cheese, what a nuisance. Does anyone know who currently owns the design for the REC chip? If they could be persuaded to release it (or at least its design parameters) into the public domain, a lot of things would get easier.
<Grin> Commodore Semiconductor Group owns the REC design. Let us know if you are able to contact them.
AFAIK CSG is defunct. When I asked who owned it, I meant "Who owns it -now-?"
Did the patents for all of CSG's chips end up with GMT Microelectronics Corporation ? Who bought their assets when they went into liquidation ?
Well, after considerable research I've found that the EPA considers Rockwell Automation (formerly Allen-Bradley) to be the 'responsible party' in ongoing Superfund cleanup operations at the GMT Microelectronics (Commodore Semiconductor) site. Since the documents say only that GMT Microelectronics was 'liquidated' by EPA order, one can assume that Allen-Bradley bought their assets lock, stock, and barrel. So if anyone owns the rights to the CBM chips (including the REU), it has to be Rockwell Automation.
However, my guess is that they dumpsterized the documentation for them, as they were probably only interested in the physical plant.
That being the case, old engineers like Bil Herd remain our best hope for uncovering that kind of information. As with most of this old stuff, I think who owns it is pretty much moot. Even if a company KNOWS they own the rights, it's highly unlikely they would come after a hobbyist for resurrecting it.
As one example, INFO went bankrupt and the bank seized our assets, but they were really only interested in the computers and office equipment that they could sell off at the liquidation sale. Though they technically own the rights to our words, I doubt they'd come after us even if we compiled and sold a 'Best of INFO' book, since the revenues would not equal the legal costs.
Quote from: BigDumbDinosaur on May 19, 2008, 01:40 PMCBM should have made it possible to add RAM to the interior of the 128, accessible through MMU register twiddling. The REU was, in my dinosaurish opinion, a poor substitute.
This actually is possible. I can't remember where, but I have seen hobbyist instructions for expanding a 128 to 256KB of internal RAM.
Edit: Ah, found it. (http://www.ktverkko.fi/~msmakela/8bit/memory/index.en.html) Looks like you can actually push it all the way up to 1MB, holy cow.
Too lazy to go look right now, but if I remember right that mod needs a second MMU, which you'd have to pull from another C128. If CBM had fully implemented the MMU's internals and added some RAM sockets, as I understand it you could have gone to 256K onboard.
Yeah, it does require a second MMU (although it gives the name of a company which still sells them, so you don't necessarily have to cannibalize one from a 128,) and it takes some doing, but it is possible.
Twin Cities 128 also published a pair of articles (issues #30 and #31) on expanding the internal RAM of the C128 to 256k and beyond. I've scanned it and uploaded it here (http://home.mchsi.com/~airship2/TC128_RAM.pdf). It comes complete with very nice GeoPaint renderings of the component layouts and wiring! :)
Here's a sample (reduced by 50%):
(http://home.mchsi.com/~airship2/Sample.jpg)
Quote from: airship on September 02, 2008, 02:23 AMTwin Cities 128 also published a pair of articles (issues #30 and #31) on expanding the internal RAM of the C128 to 256k and beyond.
I've always thought that the idea of expanding the C128's memory to be interesting (Raymond Day has done it). However, what program would make use of that expanded memory?
On the road, now in Grants Pass, Oregon,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
It adds banks, so you can use the BANK command to access it for whatever use you want. Good for ML, screens, multitasking, just about anything. It works with the REU, too. I think there's even a patch to make STASH, SWAP, and FETCH work with it.
Quote from: airship on September 02, 2008, 08:33 AM
It adds banks, so you can use the BANK command to access it for whatever use you want. Good for ML, screens, multitasking, just about anything. It works with the REU, too. I think there's even a patch to make STASH, SWAP, and FETCH work with it.
Which begs the question, "Which programs work with it?"
Now in Stockton, California,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
LOL! :D
I guess I have to do ALL the work for you Robert!
(1) Any program you write yourself, either BASIC 7.0 or M/L, which is specifically designed to make use of the new BANKs.
(2) Any commercial or PD program that does the same. Many make use of the REUs, and I suppose if they take the FETCH/SWAP/STASH route they can possilby be aware (or be made aware) of the extra RAM, but I don't know that for sure.
(3) If there is a utility, or if someone writes a utility, to make the use of this extra RAM relatively transparent to other programs, then compatible software would be able to use it.
I know that's not specific, but as I don't (a) have expanded RAM, or (b) lots of software to test with it, that's the best I can do for now.
If you RTFA, you'll see some BASIC and M/L demo programs that load pictures into the various banks, and move memory chunks from bank to bank. There's even a list of changes (only 7 BASIC lines!) to make the 'pound' animation demo for the REU run in these banks instead.
Quote from: airship on September 03, 2008, 04:51 AMI know that's not specific...
I remember when I asked Raymond Day about what he ran on his expanded-memory C128. He smiled but gave no definitive answer. In other words, it was an exercise in expanding the memory but other than that...
Back in California,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Quote from: RobertB on September 03, 2008, 09:56 PM
I remember when I asked Raymond Day about what he ran on his expanded-memory C128. He smiled but gave no definitive answer. In other words, it was an exercise in expanding the memory but other than that...
Yes, but just because something hasn't been used doesn't mean it isn't useful. It's the old chicken-and-egg thing. Nobody has expanded RAM, so no one ever wrote any software for it. And the guys who do expand their C128s are mostly hardware guys. The only software they're interested in is what it takes to get the hardware up and running.
A perfect example is the RAMBoard. It was a commercial product, but as far as I know only one (maybe a couple) disk copy program made use of it. Why? Because the market was too small (and they were almost all pirates). Even though the right software could have turned a 1541 or 1571 into a stand-alone coprocessor.
Quote from: airship on September 04, 2008, 07:09 AM
It's the old chicken-and-egg thing. Nobody has expanded RAM, so no one ever wrote any software for it.
Yup.
Quote from: airship on September 04, 2008, 07:09 AMA perfect example is the RAMBoard. It was a commercial product, but as far as I know only one (maybe a couple) disk copy program made use of it.
I only know of the RAMBoard utility that came with it.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The MMU doesn't have output lines for additional RAM banks. As you can see from the diagram, a 2nd MMU is needed (a little hard to get maybe) and it must be addressed seperately as can be seen from the decode lines, although I can't tell what address it maps to from the image.
Anyway, it would not work with BANK, STASH, etc. unless you modified the ROMs to access the 2nd MMU. Cross-bank operations would become slower too (need to fiddle 2 register sets).
Off-topic, the GEOS image reminds me of something I noticed today while processing invoices. It's not uncommon to get stock forms filled out with dot-matrix printers. But I noticed several today that looked like they were filled out with GEOS, specificaly the California font. ...I guess it could be a low-end PC printer using MS Sans Serif...