Topic: What else can the C128 ROM socket be used for ?

[Mark Smith]

Just idle thoughts ...

Can the ROM socket be used for anthing else other than just ROM ?  I was wondering if a RTC (Real Time Clock) could also be added ?  Where the time is just at an address of memory.

Stupid thought ?  I'm sure there's a flaw there otherwise someone else would have done it already ?

Mark

[Guest]

A clock there seems like a great idea to me; the only problem I can think of is who's going to support yet another RTC for the 128?  Most programs that I've seen that support a RTC on the 128 use the CMD method over IEC.

[Mangelore]

There's a hardware project in one of the Twin Cities 128 magazines I have that allows the C128 to have a 32K Static RAM chip inserted in the function ROM socket. The circuit includes battery-backup so the Static RAM could retain its contents while the C128 was powered off. If you already have a ROM in the U36 function ROM socket, the circuit allows the selection of it or the Static RAM via a switch or software. Sounds cool eh? They also list a basic and machine code program.

I've been meaning to build this project for some time now but what put me off was that you also need to jumper a few wires from other IC pins like U11, U6 etc...back to this board.  But maybe I should just use IC test clips like these
http://www.eleparts.com/shop/item_images/detail/4913.jpg
 for those pins (no soldering). Just like the MMU board does for the SuperCPU 128.

This project seems more suited for the C128DCR (metal case). Would any of you guys be interested in one? I could probably make a couple. I'm also happy to PDF the relevant magazine pages at work for anyone that wants them. If I find the AC adapter for my scanner at home I'll scan all of my Twin Cities 128 magazines.

Cheers
Fotios

[Blacklord]

There's a hardware project in one of the Twin Cities 128 magazines I have that allows the C128 to have a 32K Static RAM chip inserted in the function ROM socket. The circuit includes battery-backup so the Static RAM could retain its contents while the C128 was powered off. If you already have a ROM in the U36 function ROM socket, the circuit allows the selection of it or the Static RAM via a switch or software. Sounds cool eh? They also list a basic and machine code program.

I've been meaning to build this project for some time now but what put me off was that you also need to jumper a few wires from other IC pins like U11, U6 etc...back to this board.  But maybe I should just use IC test clips like these
http://www.eleparts.com/shop/item_images/detail/4913.jpg
 for those pins (no soldering). Just like the MMU board does for the SuperCPU 128.

This project seems more suited for the C128DCR (metal case). Would any of you guys be interested in one? I could probably make a couple. I'm also happy to PDF the relevant magazine pages at work for anyone that wants them. If I find the AC adapter for my scanner at home I'll scan all of my Twin Cities 128 magazines.

Cheers
Fotios

I'm guessing this could work as a static RAM disk ?

Lance

[Mark Smith]

There's a hardware project in one of the Twin Cities 128 magazines I have that allows the C128 to have a 32K Static RAM chip inserted in the function ROM socket. The circuit includes battery-backup so the Static RAM could retain its contents while the C128 was powered off. If you already have a ROM in the U36 function ROM socket, the circuit allows the selection of it or the Static RAM via a switch or software. Sounds cool eh? They also list a basic and machine code program.

I don't suppose you have a scan of the magazine do you ?  Be interesting to look at.

Thanks

Mark

[Mangelore]

I'm guessing this could work as a static RAM disk ?

Lance

The article states that you can use Peek, Poke, BLOAD, BSAVE and SYS commands to access the Static RAM.

I don't suppose you have a scan of the magazine do you ?  Be interesting to look at.

Thanks

Mark

I'll try scanning it at work on Monday.

Cheers
Fotios

[Guest]

There's a hardware project in one of the Twin Cities 128 magazines I have that allows the C128 to have a 32K Static RAM chip inserted in the function ROM socket. The circuit includes battery-backup so the Static RAM could retain its contents while the C128 was powered off. If you already have a ROM in the U36 function ROM socket, the circuit allows the selection of it or the Static RAM via a switch or software. Sounds cool eh? They also list a basic and machine code program.

I've been meaning to build this project for some time now but what put me off was that you also need to jumper a few wires from other IC pins like U11, U6 etc...back to this board.  But maybe I should just use IC test clips like these
http://www.eleparts.com/shop/item_images/detail/4913.jpg
 for those pins (no soldering). Just like the MMU board does for the SuperCPU 128.

This project seems more suited for the C128DCR (metal case). Would any of you guys be interested in one? I could probably make a couple. I'm also happy to PDF the relevant magazine pages at work for anyone that wants them. If I find the AC adapter for my scanner at home I'll scan all of my Twin Cities 128 magazines.

Cheers
Fotios

I'm guessing this could work as a static RAM disk ?

Lance

Since you can read it in it's entirety by setting the proper bank then I would imagine that the uses would go far beyond  RAM disk.  This could be a fantastic mod for GEOS users because not only could you boot up instantanesouly, but GEOS could already be in a ready-to-use state as soon as you power up the computer.  As a matter of fact, it could be that way for any OS.

[adric22]

There's a hardware project in one of the Twin Cities 128 magazines I have that allows the C128 to have a 32K Static RAM chip inserted in the function ROM socket. The circuit includes battery-backup so the Static RAM could retain its contents while the C128 was powered off.

That's funny.  I actually did this project on my Plus/4 a couple of years ago.  I didn't even realize anyone else had ever done it and I had forgotten about the extra socket in the 128.   But yeah, I remove that stupid 3+1 software that comes with the Plus/4 and I found myself thinking, "You know.. I bet a static RAM would fit here."  and it did.  But there was no write line going to the chip, so you could only read it.  All I did was take a jumper wire from the read/write pin on the CPU and connect it to the static RAM.  Worked like a charm.  I now had 96K of RAM in my Plus/4.   Then I started thinking about the battery backup idea.  Unfortunatly, I could never get it to work.  It seems the longer power was off, the more corruption there would be in that area of RAM.  I suspect power was getting drained off into the system somewhere and I didn't make a good enough circuit for the battery part to work.

[Hydrophilic]

A lot of cool ideas.  It seems some actually worked.  I always wanted a second SID.  Dunno why they didn't give us one considering they already gave us 2x CPUs, 2x RAM and 2x VPUs.  Of course this would require a mod like above since there is no read/write line and wrong pinout.

[Mangelore]

I always wanted a second SID.

It's possible... http://www.prophet64.com/sid2sid.php

[papa_november]

    I'd love to see this mod (although it looks complicated).

[airship]

Fotios, did you ever get this article scanned?

I've wondered a few times if you could pull the C64 ROM and replace it with something more fun. Would it work to just stick a cartridge ROM in there?

I mean, I already have a C64.

[Mark Smith]

He did, it's in my e-mail so if you drop me a message with where to e-mail it I'll pass it along .. about 3MB in size.

Mark

[richardc64]

I have registered so I could bump this aged thread because the TwinCities128 Internal Function RAM project was devised and authored by ME, and I must correct a slight misinterpretation of the project's capability.

Although reading the Static RAM, via PEEK and BSAVE (or M.L. equivalents), is straightforward -- or as straightforward as any memory accessing of the '128 banks can be -- writing (POKE, BLOAD, etc.,) is a bit tricky.

As my embarassingly nostalgic web page for this project http://www.sdiy.org/richardc64/c128/ifr.html explains, my circuit bypasses the MMU and PLA logic in enabling the Function ROM area occupied by Static RAM, but those devices still select the underlying system memory, because that's what they do if a write to a location that's supposed to be ROM is attempted. In other words, for Writes, both system memory and the Internal Function RAM are writen to simultaneously. This could corrupt a Basic program in RAM0 or Basic variables in RAM1, depending on which BANK # containing the Internal ROM-now-RAM is in effect.

To get around this, the M.L. routine I provided saves the configuration, switches to a configuration containing the system RAM, reads the byte from the target address and stores it on the stack, then switches the ROM area back in and does the write to the battery-backed Static RAM and system RAM AT THE SAME TIME. Then the byte stored on the stack is restored to the location from whence it came. (whew.) I don't have the original TwinCities issue at hand to scan the assembly listing, and all my CBM stuff is moth-balled, but I'm sure the talented programmers in this forum get the gist of what needs to be done. No  precautions other than the usual ones are needed when SYSing the Static RAM, unless the code therein does writes to itself, in which case it would have to perform the steps I described above.

I'd be interested in knowing if anyone has built this, and if so, what they've done with it.

-- Richard Curcio

[Hydrophilic]

Cool article.  I remember looking up and reading that article after this thread was posted.  I like the web page too!  And those schematics look they were done in GEOS... pretty cool.
 
I get what you are saying about saving the system RAM on the stack and restoring it when writing your SRAM.  This could be a bit time consuming if you need to write a lot of data to the SRAM without trashing system RAM. 
 
An idea I thought of is if you had a spare page of memory, you might be able to swap page 0 under the area of SRAM.  I'm not sure if this would work because the C128 PRG states that page 0/1 redirection doesn't work in regards to the I/O area, but I'm not certain about under ROM... in any case my idea (if it works) would result in writes to SRAM trashing the real zero page but for "normal" operation, zero page would be redirected to the spare page of memory.  The idea being you only have to change memory config once every 256 writes instead of twice every 1 write.  This may be only practical if you want to write a lot of data at once.
 
I noticed there is an unused pin (it's grounded) on the inputs to the 74HC138.  You also say you can have 4 devices controlled by connecting it's Pin 2 (B) to a control line like on the cassette port.
 
I was thinking there are two very often unused outputs of the C128 that are available: the /GAME and /XROM lines of the MMU.  These are normally used as inputs and if a device pulls them low at start-up, then C64 mode will automatically be selected.  However they can also be used as outputs.  So assuming a cartridge doesn't pull the lines low (and if it did C64 mode would be selected and I don't think SRAM would then be available), you could have two lines going to the 74HC138: the one you indicated, Pin 2 (B) and the other unused (grounded) Pin 3 (C).  Wouldn't this allow you to control 8 devices?
 
Then you could have an extra 8x32k = extra 256k of RAM?  That sound's too good to be true!  Is my logic failing me?

[richardc64]

Cool article.  I remember looking up and reading that article after this thread was posted.  I like the web page too!  And those schematics look they were done in GEOS... pretty cool.

Thanks very much. Yes, the drawings were originally done in GEOS, but the graphics on the web page are scans from the TC128 article, retouched in Windows M$ Paint.
 

I get what you are saying about saving the system RAM on the stack and restoring it when writing your SRAM.  This could be a bit time consuming if you need to write a lot of data to the SRAM without trashing system RAM.

A little less time would be consumed if the MMU pre- and load configuration registers were used to do the bank switching, but I did not try that.

If the SRAM were written to before a Basic program or whatever was stored in system RAM then byte-by-byte bank switching would be unnecessary.
 

An idea I thought of is if you had a spare page of memory, you might be able to swap page 0 under the area of SRAM.

(Shudders) I never completely understood the page 0/1 swap, so I can't say anything certain about your idea. I can only assume swapping affects only system memory, and it shouldn't matter if the pages are under any ROM, but I don't know for sure.

...in any case my idea (if it works) would result in writes to SRAM trashing the real zero page but for "normal" operation, zero page would be redirected to the spare page of memory.

Wouldn't it be better to trash the substitute zero page , then restore the normal ZP? (Actually, I'm not comfortable with idea of "trashing" either the "real" or substitute ZP, but better programmers than I ever was might be able to pull it off -- IF no ZP locations are used as address pointers for memory moves, which is kinda impractical.)

All these complications are why I considered my SRAM as primarily a substitute for EPROM, containing utilities and such, and not for any rapid, and/or frequent writing.

I noticed there is an unused pin (it's grounded) on the inputs to the 74HC138.  You also say you can have 4 devices controlled by connecting it's Pin 2 (B) to a control line like on the cassette port.
 
I was thinking there are two very often unused outputs of the C128 that are available: the /GAME and /XROM lines of the MMU.  ... you could have two lines going to the 74HC138: the one you indicated, Pin 2 (B) and the other unused (grounded) Pin 3 (C).  Wouldn't this allow you to control 8 devices?
 
Then you could have an extra 8x32k = extra 256k of RAM?  That sound's too good to be true!  Is my logic failing me?

Yeah, just a little. All 8 'HC138 outputs would be available if all three Select inputs (A, B, C,) were available, but in this incarnation, A (pin 1) detects when MS1=1, which in combination with MS0=0 indicates an Internal Function ROM access. For this reason, only 4 of the 'HC138 were usable, depending on the states of inputs B and C. If MS1 were inverted and applied to Enable pin /E2 (pin 5 -- some data sheets label these enables "G",) then 8 x 32k could be selected. At the time I did not want to add another IC just to get an inverter, but now I realize a single npn transistor would've done the job. D4mn hindsight.

/GAME and /XROM as outputs is a good idea, as long a user didn't plug in anything that also wanted to use them as such, in which case some mechanism for disabling the SRAM would be needed. The only thing available for that would be the afore-mentioned /E2 input.

Sorry to be so long-winded on such an ancient topic; I just want to make sure there's no misunderstanding of how this thing works and what it's good for.

[SmallCleverDinosaur]

I have registered so I could bump this aged thread because the TwinCities128 Internal Function RAM project was devised and authored by ME, and I must correct a slight misinterpretation of the project's capability.

Richard, nice to see you here

Someone was once kind enough to post a scan of your TwinCities article here in the forum. About a year ago I took the liberty to somewhat "clean it up" by OCR'ing it. So now it's searchable and much more readable You can download it here.

I now also visited your nostalgic webpage for this project. I don't think it's embarassingly nostalgic though. After all, nostalgia, that's what we do here I actually used the pictures on your webpage to update the "cleaned" pdf, since the quality of the original scanned ones was poor, at best.

I've also taken the Basicloader and the ML assembler-code that was in the pdf and put it in a D64, here.

I hope you don't mind me "cleaning" the article. I haven't changed anything though I hope it will be of use to someone

[richardc64]

I hope you don't mind me "cleaning" the article. I haven't changed anything though I hope it will be of use to someone

Why would I mind? You did a beautiful job!

Seeing the article again, I realize I had forgotten a lot in regard to software concerns, specifically the need to initialize the IFR at $FFFA-FFFF, the fact that I had used a Load Configuration Register in an effort to slightly speed up bank switching, and, most importantly, that my mem mover routine used the stack to hold some "relay" code! Yikes!

Obviously, there's room for improvement.