The Compact Computer 40 (CC40)

[+Vorticon]

41 minutes ago, brain said:

Hopefully someone can put the missing ones into the archive

CC-40 cartridges.zip 161.53 kB · 1 download

I tried uploading the files but access is restricted.

[+mizapf]

Let me do, I have write access.

[+mizapf]

34 minutes ago, Vorticon said:

I'm having a hard time getting these modules to be recognized by MAME and I think it's related to the location and naming. Any tips on where these files should go and what is the expected naming convention?

You just reference the cartridge in the command line, or you use the File manager via the OSD. You should be able to put the file anywhere you want, as long as you provide the full path name.

 

mame cc40 -window -cart "Editor Assembler.bin"

 

(Why do people always have to use spaces in file names...)

 

I don't know how to work with the CC40, so you will have to check.

[+Vorticon]

29 minutes ago, mizapf said:

You just reference the cartridge in the command line, or you use the File manager via the OSD.

 

mame cc40 -window -cart "Editor Assembler.bin"

 

(Why do people always have to use spaces in file names...)

 

I don't know how to work with the CC40, so you will have to check.

It does not look like the cartridge is being detected or the dump is bad. The CC40 emulation runs without errors, but RUN "ALDS" gives a program not present error.

Actually in trying a different cart, I'm getting the same error. So maybe my loading process is flawed. Sigh... I'll keep playing with it.

Edit: No, I think it's a problem with the emulation of the CC40. The stock emulation with BASIC runs as it should without issues, but none of the carts are being recognized.

[+mizapf]

I found the software list definition for the CC40. Have a look at hash/cc40_cart.xml in the MAME directory.

 

You see the entries "software name=...". This name must be added behind "-cart", for example,  "-cart ea".

 

In the lines "rom name=" you see how the file has to be named. So you have to rename "Editor Assembler.bin" to "ea.bin". Then you should ZIP the file as "ea.zip", only containing the ea.bin" file.

 

You have to put the ZIP file into the ROMPATH. You can also add another folder to the ROMPATH, like "cc40_cart".

 

This is how it looks for me:

 

mame cc40 -window -rompath roms\;cc40_cart -cart ea

 

(The backslash is required for Linux in order to escape the semicolon.)

 

However, I am getting a warning that the dump is not correct. You may still try, or do the same with the other dumps.

[+Vorticon]

So I tried it in Linux and same issue. An error warning comes up in the console about a wrong checksum with the carts. The emulation runs but none of the carts are being seen by the system. Only BASIC works.

Again I think there is a problem with these dumps or the emulation is incomplete.

 

[+mizapf]

The point is that there are no notes or caveats about the cartridges for the CC40, so I assume that they worked at least at some time, or that this dump is indeed broken. We'll have to contact the maintainer.

[+Vorticon]

Yup... Who is the maintainer?

[+mizapf]

"hap", according to the credits in the cc40.cpp file. I just sent him a message.

[+mizapf]

Here they are, working. I tried them

 

http://ftp.whtech.com/CC40/CC-40 Cartridges.zip

 

Unpack the zip file into your rompath, do not unpack the contained zips.

[+Vorticon]

1 hour ago, mizapf said:

Here they are, working. I tried them

 

http://ftp.whtech.com/CC40/CC-40 Cartridges.zip

 

Unpack the zip file into your rompath, do not unpack the contained zips.

They do!

So what was the change?

 

On the sad part, I can confirm that the EA cart still is buggy when it comes to the editor and linker...

[+Vorticon]

I should clarify that without a Hexbus drive emulation in MAME, it will not be possible to work with the EA cart anyway. I did connect with the CC40 emulation maintainer and there is no longer any interest in working on this. So we should focus on the real hardware side of things if that's possible. Any progress on your end @acadiel?

[+acadiel]

Yep, @Vorticon!  I think we have a winner.   (Thanks for everyone's patience.  I got COVID after getting back from England, and although I'm vaccinated, it's been challenging.  Plus, I also started my new leadership position at work.  It's been a crazy nuts month.)

 

TL;DR:  32K and 64K carts need two chip enables returned to the CC-40.  If you don't have both going back, you get unpredictable behavior.  The Multicart will need modification to work as a 32K E/A cart.

 

Here's the details:

 

1) I've uploaded two schematics which I've found - I thought these were lost, but it took a bit of digging - I found them in an old email account from over 10 years ago.   One is the 32K cartridge schematic.  One is the 64K E/A + MP hybrid cart that is pictured above.

 

2) If you look at either of these, you notice there are two chip enables and a very specific way that they have to be wired to work for a 32K and up cartridge.  And they go back to VCC (CC-40 pin 39) through a resistor.

 

3) The CC-40 E/A 32K image is expecting this setup; the likely reason the cart isn't working right or autonumbering right is because we need to fix its wiring with the chip enable so the CC-40 knows what's going on.  

 

4) Steve Reid and I have verified that the binary in the multicart *is* the correct binary.

 

5)  I'd suggest just burning an EPROM with all 32K EA images all over it, and flipping your switches or figuring out some way to make sure you know where you are in the memory map with the switches before you make these mods.  It will make the cart partially unsuable for a multicart once you make the mods, or you will have to figure out how to switch it back/forth.  I haven't thought out all the wiring changes, but I suggest simplifying by putting something like a 27512 (with E/A on it twice) and doing slight solder bodges to make adjustments.

 

@brain - we will need to make some edits to the multicarts to work per below schematics for the 32K and 64K variants - per CC-40 wanting two chip enables for 32K and 64K carts.   I don't know how this impacts the multicart as a whole, though. 

 

Oh, as an added bonus, I've also uploaded "cc40m2ro", which is a three-in-one combination cart that Michael Becker never produced - E/A, Memo Processor, AND SRAM!  According to Steve Reid, it's largely complete, save this:  "I think it just needs pull-ups on both chip CE pins coming out of the hc139.  And probably some additional bypass caps on vcc to gnd. He’s got a 0.1, should have a couple, not just 1."  If @brain wants to put this to a board - I think it would be a REALLY great cart - and might be a better solution than modifying the multicart for us to use Editor Assembler (if the solution works - we don't know since I don't think any have ever been made.)

 

Edit:  Here’s a screen grab of what the 32K cart looks like with the circled part of what needs to be modified, @Vorticon

 

 

 

cc40mech.pdf cc40mmp.pdf cc40m2ro.pdf

 

Also, here’s how the CC-40 memory matches the memory in the EPROM for a 32K module.  So, they have to be arranged like this on the EPROM to work correctly in the CC-40.

 

* 9000-cfff has its own chip enable in the cc-40 logic, and 5000-8fff has its own as well.

* 8K and 16K were on a single chip enable at 9000, while 32k ram or rom modules used both enables.

 

[+acadiel]

Here's the last three of the schematics.  8 and 16K SRAM and ROM.

cc40m8k.pdf cc40m16k.pdf cc40rom2.pdf

[+Vorticon]

Thanks! So here's my question: if it's a hardware issue, why is the EA misbehaving in MAME as well?

[+acadiel]

2 minutes ago, Vorticon said:

Thanks! So here's my question: if it's a hardware issue, why is the EA misbehaving in MAME as well?

Implementation.  We likely didn’t implement the chip enable correctly there either.  Hap will need to fix it.  Says a lot if it behaves like it does on physical hardware as well as the emulation!   Hap and I worked quite a bit over email with cartridge images and trying things out before we got it working, and there wasn’t much after that - just “it works”, and that was it.

 

There’s lots we didn’t know about this which wasn’t documented when we originally did it.  When Jim Brain and I designed the boards, there were several unknown signals on the board - and with the schematics above, my CB Wilson documentation, and with Steve Reid helping us, we’re gradually putting together a better picture.  (Steve Reid who we keep talking about  - @ksarul and I made friends with him several years back.  He started with TI around 1984ish.  He didn’t work on the CC-40; he arrived right after, and worked on the prototype CC-70, and then the TI-74 and TI-95.  He’s pretty familiar with the systems and a great guy to bounce ideas off of.)

 

About the 74… 

 

Paging on the 74 is similar to the CC-40 but not exactly the same, and it’s locked in an TI organizational knowledge black-hole.  There’s some predefined hooks in ROM for bank switching that aren’t documented except in a TI 74 SDK, and TI’s not going to open source the 74 SDK any time soon.  And, the hooks aren’t documented anywhere outside of TI.  So good luck with creating TI-74 512K bank switched carts… plus, the cartridge connector was specially made for the 74 and all were destroyed when it was discontinued.  (We’d have to make custom ones somehow.)  

 

Nor will TI make any new agreements or allow new users of the 74 SDK because of the status of the 74 as a discontinued product.   Open source might be an option, but to open source the SDK, Steve would have to be the one to review it and certify it, as he’s the only one left from that era, BUT he’s fully booked with other TI work.  So, it won’t happen any time soon.   Can Steve just tell us?  Yes… can he get in trouble?  Definitely.  He’s still working for TI.

 

Back to this fix…

 

In concept, Steve and I are confident that this should fix this - but until someone (or me) actually thinks through and mods the board slightly and gets it to work, it’s unproven.  It should work.  I mean, the binary is fine.  The order of the 4K banks is fine.  The resistor value was OK.  We just didn’t have the chip enables tied together to make the CC-40 happy, and Steve said that would cause unpredictable behavior the way this was designed.  Originally, there were two chips - two 16K ones.  Likely, each one had its own CE, that’s the origin of two.  But, you can’t just leave one floating - digital logic.

 

Apologies for the brain dump - wanted to put some of this there while I had a clear mind and remembered it.  Brain fog has been getting the best of me lately and making it really hard to concentrate.

[+Vorticon]

Is it just a matter of tying together the chip enables lines? If I just solder on a jumper wire would that work?

[+Vorticon]

Would the tying of the CE lines together work on the multicart as well?

[+acadiel]

1 hour ago, Vorticon said:

Would the tying of the CE lines together work on the multicart as well?

I need to meter out the current board, but yes, you should technically can just tie the two CE lines together on the CC-40 side, make sure they are tied to CE on the EEPROM, and there’s a pull up resistor on all three of those that goes to to VCC if I read this right.  I think the 3.3K resistor is default already.

 

The only thing I’m worried about is how that pull up/CE is connected on the current multicart when it comes to the four switches and such.  The worst thing that can be done is short VCC and GND together — so just verify everything first and double check.  And, I’m not sure what happens to <32K carts will behave when you have both CE’s tied together, since 16K and 8K carts only need one of the CEs.  Testing will need to be done.

 

[brain]

I'm happy to help, but I am confused.

 

The schematics show D0 on 22, but the materials I saw have it on pin 40.  D7 is shown on 14 but is actually on 34 on reference docs.

 

I know TI named lines backwards, but none of the data line numbers match up, nor do address lines.  I'm leery of modifying until I can reconcile.

 

I *think* the conversion is:

(01) 1  GND                          (40)21  !CS_CROM
(03) 2  Vbatt                        (38)22  A6
(05) 3  P25.2                        (36)23  A5
(07) 4  A9                           (34)24  A4
(09) 5  A11                          (32)25  A2
(11) 6  !OE                          (30)26  A0
(13) 7  !RESET                       (28)27 GND
(15) 8  INT3                         (26)28  D2
(17) 9  CLKOUT                       (24)29  D1
(19)10  R/!W                         (22)30  D0
(21)11  !ENABLE                      (20)31  D6 
(23)12  !A14                         (18)32  D5
(25)13  ALATCH                       (16)33  D4
(27)14  D3                           (14)34  D7
(29)15  A1                           (12)35  !CS_CRAM
(31)16  A3                           (10)36  A10
(33)17  P25.3                        (08)37  A8
(35)18  A12                          (06)38  A15
(37)19  A7                           (04)39  !WE
(39)20  Vplug                        (02)40  A13

 

 

Which is wild and horrific, but it seems the match up.

 

But, if so, then CS_CRAM and CS_CROM are mapped this way already in the cart, with the 3K3 resistor.

 

 

[brain]

3 hours ago, acadiel said:

Yep, @Vorticon!  I think we have a winner.   (Thanks for everyone's patience.  I got COVID after getting back from England, and although I'm vaccinated, it's been challenging.  Plus, I also started my new leadership position at work.  It's been a crazy nuts month.)

 

TL;DR:  32K and 64K carts need two chip enables returned to the CC-40.  If you don't have both going back, you get unpredictable behavior.  The Multicart will need modification to work as a 32K E/A cart.

The multi-cart already has this in place.  Notice pins 35 and 21 on the cart are tied together:

 

https://github.com/go4retro/CC40_ROMCart/blob/master/pcb/CC40 ROM Cart PCB.png

 

3 hours ago, acadiel said:

 

2) If you look at either of these, you notice there are two chip enables and a very specific way that they have to be wired to work for a 32K and up cartridge.  And they go back to VCC (CC-40 pin 39) through a resistor.

pin 39 is what we used to call pin 20 (Vplug)

3 hours ago, acadiel said:

 

3) The CC-40 E/A 32K image is expecting this setup; the likely reason the cart isn't working right or autonumbering right is because we need to fix its wiring with the chip enable so the CC-40 knows what's going on.  

I think there is another issue, as the CS stuff is correct.

3 hours ago, acadiel said:

@brain - we will need to make some edits to the multicarts to work per below schematics for the 32K and 64K variants - per CC-40 wanting two chip enables for 32K and 64K carts.   I don't know how this impacts the multicart as a whole, though. 

I think it's already there.  I guess, show me where I am mistaking things.

3 hours ago, acadiel said:

 

Oh, as an added bonus, I've also uploaded "cc40m2ro", which is a three-in-one combination cart that Michael Becker never produced - E/A, Memo Processor, AND SRAM!  According to Steve Reid, it's largely complete, save this:  "I think it just needs pull-ups on both chip CE pins coming out of the hc139.  And probably some additional bypass caps on vcc to gnd. He’s got a 0.1, should have a couple, not just 1."  If @brain wants to put this to a board - I think it would be a REALLY great cart - and might be a better solution than modifying the multicart for us to use Editor Assembler (if the solution works - we don't know since I don't think any have ever been made.)

 

I'll look at this, and see what it is doing. 

 

3 hours ago, acadiel said:

I think this is just due to A14 being inverted on the address lines.

[+Vorticon]

I think I'm going to wait until you hardware gurus sort it out before I modify my cart. The last thing I want is kill my CC40 (the last one went for over $300 so... ).

[+Vorticon]

I do have a more generic question about the carts: how does the CC40 know there is a cart inserted? I assume some specific pins need to be in a specific state or tied to some other pins?

The reason behind my question is that I'd like to be able to output data to the D0-D7 lines on the cartridge port (@>5000), but my preliminary testing is indicating that the CC40 cannot do that unless it recognizes that there is a cart inserted...

[+acadiel]

12 hours ago, brain said:

I'm happy to help, but I am confused.

 

The schematics show D0 on 22, but the materials I saw have it on pin 40.  D7 is shown on 14 but is actually on 34 on reference docs.

 

I know TI named lines backwards, but none of the data line numbers match up, nor do address lines.  I'm leery of modifying until I can reconcile.

 

I *think* the conversion is:

(01) 1  GND                          (40)21  !CS_CROM
(03) 2  Vbatt                        (38)22  A6
(05) 3  P25.2                        (36)23  A5
(07) 4  A9                           (34)24  A4
(09) 5  A11                          (32)25  A2
(11) 6  !OE                          (30)26  A0
(13) 7  !RESET                       (28)27 GND
(15) 8  INT3                         (26)28  D2
(17) 9  CLKOUT                       (24)29  D1
(19)10  R/!W                         (22)30  D0
(21)11  !ENABLE                      (20)31  D6 
(23)12  !A14                         (18)32  D5
(25)13  ALATCH                       (16)33  D4
(27)14  D3                           (14)34  D7
(29)15  A1                           (12)35  !CS_CRAM
(31)16  A3                           (10)36  A10
(33)17  P25.3                        (08)37  A8
(35)18  A12                          (06)38  A15
(37)19  A7                           (04)39  !WE
(39)20  Vplug                        (02)40  A13

 

 

Which is wild and horrific, but it seems the match up.

 

But, if so, then CS_CRAM and CS_CROM are mapped this way already in the cart, with the 3K3 resistor.

 

 

Yeah, we probably want to get on Discord with Steve, @brain and figure this out.  Let’s make a channel in HexTIr for this.  What we do know I put above - is that the binary layout is fine and consistent to what Steve owns, everything is where the CC-40 is supposed to be seeing it on 4K boundaries, as seen by CC-40 DEBUG, etc.  The only thing left he and I can think of that is left is the paging, and something isn’t happening that either the CC-40 expects, or something is either high/low and throwing off the execution (i.e. AUTO starting at 00000 instead of 00001 and other things malfunctioning).  As a good example to how CE can throw off execution of the cart, remove the 3.3K resistor that goes to CE and watch the whole system lock up (and not reset until you replace the resistor or remove the cart and hit the reset button.)

 

 

 

 

 

[brain]

OK, done.  FYI:  https://discord.gg/pkPfdBR