My ROM/RAM Cartridge Idea

[Kchula-Rrit]

As several on the forum know, I've been thinking of making a board for my cartridge port.  I was originally going to duplicate my Editor/Assem cartridge and have it in parallel with some RAM.  After the demise of my E/A, I had another thought of making my own ROM-Only cartridge.  But I still wanted some RAM in it, so I drew up a schematic for a ROM/RAM cartridge.

It has 64 banks of ROM, with 256 bytes of RAM for data and/or work-space in each bank.

I can take some JPEG screen-shots and post them if anyone would like to look them over.

K-R.

[Gary from OPA]

Sounds like a MBX cartridge. But 1k of ram is better than just 256 bytes, and why do you want it to be different for each bank. It's better for the ram to be not bank switch it makes for easier programming.

 

 

[HOME AUTOMATION]

Well, since we're speculating... 

 

If the programs, were games, and the RAM, persistent, it could be used to maintain related high-scores, and player settings, while maintaining compatibility with TI's HEADER system.

 

As for the TOPIC's title... If you have to ask...

[matthew180]

11 hours ago, Kchula-Rrit said:

I can take some JPEG screen-shots and post them if anyone would like to look them over.

 

Hopefully you are using KiCAD and you could just post the schematic file (KiCAD 8 was just released too).  Or better, just put the project on github.  This makes it a lot easier for people to review.

[Kchula-Rrit]

10 hours ago, HOME AUTOMATION said:

Well, since we're speculating... 

 

If the programs, were games, and the RAM, persistent, it could be used to maintain related high-scores, and player settings, while maintaining compatibility with TI's HEADER system.

 

As for the TOPIC's title... If you have to ask...

Yes, you're right.  It was sort of a dorky way to bring up the subject.  I'm pretty awkward socially, and didn't want to just "blurt it out."

I'm not worried about persistent memory, since I use a NanoPEB at the moment.  More like This Would Be Really Cool To Do, and I'll worry about programming it later.

K-R.

[Kchula-Rrit]

3 hours ago, matthew180 said:

 

Hopefully you are using KiCAD and you could just post the schematic file (KiCAD 8 was just released too).  Or better, just put the project on github.  This makes it a lot easier for people to review.

Actually, I'm using KiCAD 6, which was included in my Linux system.  Never used github, except to occasionally try downloading stuff from it. The project uses some libraries that I made, like for the edge connectors and some of the chips.

I have in mind to make a cartridge with a truly overkill amount of ROM in it.  Some RAM would be there as well, for work-space and/or data.  This came about because I have some 512K ERPOMs in my parts bin that I would like to get some use from.  Also, while going through my parts bins I ran across a handful of 32K RAM chips.  The data sheet says they used to be used as cache RAM when PCs used to have DIP ICs in them.

 

These are 1024x768 JPEG files.  Didn't want to make them too big, but if they're too small I can do 1280x1024.

The first sheet is an overview, really just something to link the two halves of the schematic that are too big to fit in one sheet.

 

 

The second sheet shows the bank-select logic.  A write to address 0x7FFE (MS byte) will select the EPROM bank, while a write to 0x7FFF will select the RAM bank.  I originally had the idea that the writes would go in parallel to the bank registers and the RAM, so that the bank-numbers would be stored there for read-back.  After looking over the schematic I think that last word of RAM/EPROM will be useless because the bank-switch will happen during the write cycle.  Oh, well...

I'm having second thoughts about the separate bank-selects for RAM and EPROM.  That would probably simplify things quite a bit.

 

The third sheet just shows the RAM and EPROM.

 

K-R.

 

 

[Kchula-Rrit]

14 hours ago, Gary from OPA said:

Sounds like a MBX cartridge. But 1k of ram is better than just 256 bytes, and why do you want it to be different for each bank. It's better for the ram to be not bank switch it makes for easier programming.

 

 

I remember hearing of MBX a long time ago, and had the impression it was a sort of mini-expansion box, with built-in speech and other goodies.

The separate bank-selects for EPROM and RAM were just something I thought would be cool to have (delusions of grandeur, anyone?)

Now I'm thinking of just using a common select for each bank.

 

It just occurred to me that you're suggesting that the RAM be common to all ROM banks.  That would be much easier, but I was thinking of having a programs in each bank that could call each other but keep their own workspaces, buffers, data and such.

K-R.

[Gary from OPA]

27 minutes ago, Kchula-Rrit said:

I remember hearing of MBX a long time ago, and had the impression it was a sort of mini-expansion box, with built-in speech and other goodies.

The separate bank-selects for EPROM and RAM were just something I thought would be cool to have (delusions of grandeur, anyone?)

Now I'm thinking of just using a common select for each bank.

 

It just occurred to me that you're suggesting that the RAM be common to all ROM banks.  That would be much easier, but I was thinking of having a programs in each bank that could call each other but keep their own workspaces, buffers, data and such.

K-R.

The mbx was designed to add better joystick and voice recognition to video games. And their cartridges used multiple banks of ROM but shared a common 1k of ram. So that why I was suggesting it if you making a rom based assembly game and want it to work without the 32k expansion that one of the best ways and programming wise if you in the ram space when switching banks makes it easier and like you said having your workspace registers as well as there only much you can do with the 256 byte 8300 scratchpad area.

 

Come to think of it I need to unbox MBX and hook it up and killing the resale eBay value.

Edited February 28 by Gary from OPA

[matthew180]

4 hours ago, Kchula-Rrit said:

Actually, I'm using KiCAD 6

 

Excellent for running KiCAD, but I highly recommend you upgrade.  6.x was released way back in 2021, and 7.x (in Feb 2023) had major updates, and 8.x brings some very long awaited capability (not to mention bug fixes, at the very least).  The KiCAD project is now committed to annual major releases, and the new feature sets are awesome.

 

4 hours ago, Kchula-Rrit said:

Never used github

 

It is easy, and a good way to store your projects and share ones you choose.

 

4 hours ago, Kchula-Rrit said:

The project uses some libraries that I made, like for the edge connectors and some of the chips.

 

You can make your own library and share that separately, if you want.  Otherwise, all symbols and footprints are included in the the project files themselves, so even if someone does not have your library, they can still open the schematic and board files.  For example, I also have my own library (symbols, footprints, models) that I use for all my boards and anyone can use it if they want: https://github.com/dnotq/dnotq_kicad_lib

 

4 hours ago, Kchula-Rrit said:

These are 1024x768 JPEG files.  Didn't want to make them too big, but if they're too small I can do 1280x1024.

 

KiCAD has File->Plot->PDF if you don't want to share the project files.  Much better than screenshot images.

 

Nice looking schematics, by the way (from the quick glance I have had time to make).  I like your style, it is easy to follow the flow, and THANK YOU for drawing net-lines rather than just relying on net-label names alone.

Edited February 29 by matthew180

[+FarmerPotato]

On bank switch hardware:

 

The Acadiel cart used one 8-bit latch. This goes way back. A write to cart space 6000 would latch  in the low address bits. So writing to 6000 selects bank 0, writing to 6002 selects bank 1 etc...

Remember the 9900 is read-modify-write, so if you have two latches they need to be at separate words. Unless  your latch has read-back capability, writing to one byte will wreck the other byte.

 

You could have a shared latch where 4 bits control a ROM space (say 6000 to 6FFF) 4 bits  control  RAM space (say 7000-7FFF). This is a pain to maintain...

 

Unless you use CRU addressing. Doesn't work on late consoles--no CRU to cart connector. With CRU, you put in one LS259, it has 8 outputs, and you can address any bit field separately. It has a RESET pin to ensure bank 0 appears at reset.  This is the choice I built-- 3 bits for RAM in upper bank (32K), 4 for ROM in lower bank. (64K)
 

I think about two general schemes: One, the lower bank is ROM and the upper is RAM. Two, either can be ROM or RAM because there is a unified address space.  

 

 

[Retrospect]

Edit: posted to wrong thread.

Edited February 29 by Retrospect

[+FarmerPotato]

@matthew180 When you posted  last year about  style, I fully converted my schematics (G2020)  to a top-level block diagram, then fully routed wires on each   hierarchical sheet. So, thanks! 

 

[Kchula-Rrit]

1 hour ago, FarmerPotato said:

On bank switch hardware:

 

The Acadiel cart used one 8-bit latch. This goes way back. A write to cart space 6000 would latch  in the low address bits. So writing to 6000 selects bank 0, writing to 6002 selects bank 1 etc...

 

Remember the 9900 is read-modify-write, so if you have two latches they need to be at separate words. Unless  your latch has read-back capability, writing to one byte will wreck the other byte.

 

You could have a shared latch where 4 bits control a ROM space (say 6000 to 6FFF) 4 bits  control  RAM space (say 7000-7FFF). This is a pain to maintain...

I saw the description of a Guidry cart at Stuart's Web-site.  I assume the Acadiel scheme is similar?

The bank-select register is wired in parallel with the RAM at 7FFE/F, so that writing to the bank-select would write to the RAM at the same time.  Reading the 7FFE/F would retrieve the bank number.  Looking at the way the 74HC174 works, it occurred to me that the RAM address would probably change during the write cycle.  This would obviously result in an unreliable bank number stored in the RAM.

 

I'm leaning toward using the same bank-select latch for RAM and EPROM.

1 hour ago, FarmerPotato said:

Unless you use CRU addressing. Doesn't work on late consoles--no CRU to cart connector. With CRU, you put in one LS259, it has 8 outputs, and you can address any bit field separately. It has a RESET pin to ensure bank 0 appears at reset.  This is the choice I built-- 3 bits for RAM in upper bank (32K), 4 for ROM in lower bank. (64K)

I think about two general schemes: One, the lower bank is ROM and the upper is RAM. Two, either can be ROM or RAM because there is a unified address space.  

 

My other thought was to use the CRU.  This would work for me, since my consoles are the black-and-silver ones.  If I were to post the design for others to use, it would lock-out those with v2.2 consoles.  I'm probably over-thinking it; it's a problem I have.

 

K-R.

[matthew180]

5 hours ago, Kchula-Rrit said:

have in mind to make a cartridge with a truly overkill amount of ROM in it.  Some RAM would be there as well, for work-space and/or data.  This came about because I have some 512K ERPOMs in my parts bin that I would like to get some use from.  Also, while going through my parts bins I ran across a handful of 32K RAM chips.

 

I think we all go through a something similar, eventually.  I did a Bank Switch Mini board way back, because I had a bunch of TI Invaders cartridge boards that I was struggling to just toss out.

 

https://forums.atariage.com/topic/170072-bank-switch-mini-256k/

 

The link to my website is broken (because I'm a slacker and changed my website), but archive.org has me covered:

 

https://web.archive.org/web/20111104152910/http://codehackcreate.com/archives/208

 

I used a GAL for the decode logic, which reduces the chip-count a lot.  Looking around at what is available today, it seems there are still quite a few options like the Microchip ATF16V8B-15SU:

 

https://www.mouser.com/ProductDetail/Microchip-Technology/ATF16V8B-15SU?qs=2mdvTlUeTfBa0f1%2BhGhreg%3D%3D

 

I might have to revisit this, since I still have those cartridge boards kicking around. 😩

[Kchula-Rrit]

1 hour ago, matthew180 said:

 

Excellent for running KiCAD, but I highly recommend you upgrade.  6.x was released way back in 2021, and 7.x (in Feb 2023) had major updates, and 8.x brings some very long awaited capability (not to mention bug fixes, at the very least).  The KiCAD project is now committed to annual major releases, and the new feature sets are awesome.

My Linux distribution uses KiCAD v6.  Debian seems to only have v7, and I'd have to upgrade to the Debian-12.  The system I use for CAD is a 8GB Raspberry Pi, with Debian-11.  Again, I'll have to upgrade at some point.  I have a Windows 7 system, and v7 wants Win10.  Sorry to say, I'm holding out as long I can.  What I have seems to work well enough for my purposes.

1 hour ago, matthew180 said:

It is easy, and a good way to store your projects and share ones you choose.

That's a thought, and I'll have to check it out if I decide to share it with a wider audience.

1 hour ago, matthew180 said:

You can make your own library and share that separately, if you want.  Otherwise, all symbols and footprints are included in the the project files themselves, so even if someone does not have your library, they can still open the schematic and board files.  For example, I also have my own library (symbols, footprints, models) that I use for all my boards and anyone can use it if they want: https://github.com/dnotq/dnotq_kicad_lib

Cool!  Glad to hear about the symbols and footprints.  I looked at my KiCAD files and they are really small, compared to my screen-shots.  I'll post them instead of the shots.

1 hour ago, matthew180 said:

KiCAD has File->Plot->PDF if you don't want to share the project files.  Much better than screenshot images.

Again, cool!  I can do a print to PDF, but haven't tried it yet.

1 hour ago, matthew180 said:

Nice looking schematics, by the way (from the quick glance I have had time to make).  I like your style, it is easy to follow the flow, and THANK YOU for drawing net-lines rather than just relying on net-label names alone.

Thanks!  Appreciate the comments.  The net-lines are the fan things on the addr/data buses?  I'll probably make some revisions and post the project files.  I assume the files to post are the .kicad_sch (schematics, I assume), and the .kicad_pro (project file?)

 

As always, i appreciate the advice.

 

K-R.

[Kchula-Rrit]

43 minutes ago, matthew180 said:

 

I think we all go through a something similar, eventually.  I did a Bank Switch Mini board way back, because I had a bunch of TI Invaders cartridge boards that I was struggling to just toss out.

 

https://forums.atariage.com/topic/170072-bank-switch-mini-256k/

 

The link to my website is broken (because I'm a slacker and changed my website), but archive.org has me covered:

 

https://web.archive.org/web/20111104152910/http://codehackcreate.com/archives/208

 

I used a GAL for the decode logic, which reduces the chip-count a lot.  Looking around at what is available today, it seems there are still quite a few options like the Microchip ATF16V8B-15SU:

 

https://www.mouser.com/ProductDetail/Microchip-Technology/ATF16V8B-15SU?qs=2mdvTlUeTfBa0f1%2BhGhreg%3D%3D

 

I might have to revisit this, since I still have those cartridge boards kicking around. 😩

I looked over the archive.org article.  Impressive!  The GAL looks fascinating (especially at $1.22 for a 20-pin DIP).  I'm using 74HCT chips because I know them, but I may have to try to find a "GAL for Dummies" type book.

 

And last, I cannot thank you enough for inventing the F18A!  I bought one of the originals in 2012(?) and it revived my interest in the TI.

 

K-R.

[matthew180]

16 minutes ago, Kchula-Rrit said:

My Linux distribution uses KiCAD v6.  Debian seems to only have v7, and I'd have to upgrade to the Debian-12.  The system I use for CAD is a 8GB Raspberry Pi, with Debian-11.  Again, I'll have to upgrade at some point.  I have a Windows 7 system, and v7 wants Win10.  Sorry to say, I'm holding out as long I can.  What I have seems to work well enough for my purposes.

 

You don't have to stick to the versions in the system's application manager, but do what is best for you.  Although, I would stress that you reconsider connecting a Win7 machine to the Internet, that's just asking to have your computer compromised.  At the very least be a hold-out running Win10 on a machine that Microsoft deems inadequate to run Win11.  I switched to an Ubuntu LTS desktop about a year ago, and it has worked out pretty well (have not needed to boot into Windows for over 6 months now).

 

You didn't mention what Rpi you are using, but if a Rpi-4 or Rpi-5 with Pi OS, that is Debian-based and should have `apt` installed.  I would suspect you can use the PPA solution, or at the very least download the FlatPak.  Anyway, KiCAD 7.x is great, and 8.x is awesome.

 

26 minutes ago, Kchula-Rrit said:

I'll have to check it out if I decide to share it with a wider audience.

 

Even if you don't share, it is a great way to have a backup of your work that you can also access from anywhere you have Internet access.  Even if you don't use github, using git stand alone is a great tool for any kind of work you might want to have revisions of, especially code projects.

 

30 minutes ago, Kchula-Rrit said:

I looked at my KiCAD files and they are really small,

 

All KiCAD project files are text-based, which makes them awesome with chocolate on top.  The formats are also published, human readable, and easy to parse for external tools.  They are going to be small unless you put a lot of images into your schematics (I do).

 

32 minutes ago, Kchula-Rrit said:

I can do a print to PDF, but haven't tried it yet.

 

KiCAD will export (plot) a PDF directly, it is not done with the system "print to PDF", it is literally right in KiCAD's Plot dialog.

 

In the schematic editor, choose File->PLOT (not print).  Set the output format to PDF and hit the "all pages" button.

 

36 minutes ago, Kchula-Rrit said:

The net-lines are the fan things on the addr/data buses? 

 

Net-lines are literally the lines you draw between pins and such.  But people are not doing that these days, since all pins that have the same label are "connected", people skip drawing the lines on the pages.  It really makes it hard to track down all the connected pins, and it is easy to miss connections.  Here is an example of mostly-net connected schematic.

 

 

This hurts my eyes to look at, and you have to scan the whole page carefully to see all the places any net might be connected.  This schematic is a huge fail, IMO.

[Kchula-Rrit]

Thanks for the KiCAD stuff.  My R-Pi is a 8GB Pi-4 that I originally bought to operate my telescope.  Popped a Raspbian SD into it and, suddenly, it's a development system and Web access.  When telescope season comes around (and I get my equipment debugged) the AstroBerry SD goes in.

 

I strongly agree with you about that "schematic!"  It just looks like a collection of parts on a page.  But then, I'm a nerd Rip van Winkle; learned about electronics and computer in the 1970s/early 80s.

 

K-R.

[Kchula-Rrit]

Here are my schematics in PDF and KiCAD formats.  First, what I call the NAND cartridge because I used a NAND gate to select the bank register:

NAND Cartridge.pdfNAND Cartridge-2024-02-29_181352.zip

 

Here's one that I changed today to use CRU selection.  I gather CRU selection is frowned-upon these days, but it somehow appeals to me:

CRU Cartridge.pdfCRU Cartridge-2024-02-29_182341.zip

 

Thanks for checking them out.

 

K-R.

[Kchula-Rrit]

Here's my latest version, dubbed the "ROM/RAM Cartridge," in PDF and a KiCAD v6 zip file.  By upping the RAM to 1K, I was able to get rid of an IC.  I decided to go with the Guidry-style bank-select.  Now, I have to try to fit the parts to my board outline.  I've been trying to get the parts to fit but they just don't seem to want to!

 

RAM-ROM Cartridge-2024-03-09_135954.pdf

RAM-ROM Cartridge-2024-03-09_135954.zip

 

And, I was able to GET RID of that dorky title for this conversation!

K-R.

Edited March 9 by Kchula-Rrit

[Kchula-Rrit]

I finally got my hardware to work!  For testing, I figured the easiest thing to do would be to program a 512KB EPROM with 16 sets of Fred Kaal's Ed/Assem IV.  Then I could program the PLD to generate only EPROM selects and bank-writes.  I could look for the appropriate signals with my logic analyzer and tweak the

PLD accordingly.  Seems to work well.

 

The EPROM extended bank address is set by writing to >60XX, where XX is the bank address left-shifted by one bit, just like the Guidry cartridges do.  Unlike the Guidry scheme, my banks are non-inverted.  The RAM banks will be selected by writing to >68XX.  At the moment, the PLD is set to require the most-significant cartridge-address bits (A3-A8 in TI talk, A11-A7 for everyone else) be zeroes to do a bank-write.  Is that over-kill, or is it just as well to use the two MS bits to distinguish between EPROM and RAM bank-writes?

 

Now I have to write some test programs to generate RAM selects.  First thing is to write something to convert a program-image into an Intel-Hex file for my PROM burner.

 

K-R.