• Please review our updated Terms and Rules here

Fun with CC40's

By any chance, would your memory board work in a TI-74? Looks like a different form factor, but perhaps a converter to the TI-74 could be rigged up?
Not at present, but I can design a specific unit for the 74. The main problem is that one needs to find a source for the connectors for the 74.
PS: I have a large text file of CC-40 info by Dan Eicher dated 12/1/96. Have you seen that? It appears to have a wealth of info about interfacing to the CC-40 from back then.
Yep, dloaded it when I started on my efforts. It is missing a few items:

  • Pin 3 and 17 are listed as unknown, but JGardner's info notes they are PORT 25.2 and .3
  • ALATCH + .. is !OE
  • !WE is not defined (I found it by reverse engineering the RAM cart)
  • A14 is shown inverted, but putting the cc40 on my scope does not show any such inversion.
 
Brain -

The article referenced by SMB is here:

http://ftp.whtech.com/hexbus_cc40_ti74/cc40 ti74 hexbus.txt

Bits 2 & 3 of the Peripheral File register P25 control the cartridge paging

bits present on pin 3 & pin 39 of the cartridge port.
Understood, but I am trying to sort out how it was decided that the two bits were to be used for paging. Are there routines in the ROM using them in that way?
SMB -

There are no equivalent paging bits present in the '74 cartridge port.

However Multi-page cartridges could be enabled by latching <Writes> to

a chosen address (>BFFF comes to mind) for use as the High Address for

a multi-page cartridge. The real problem is the unobtainable (AFAIK) '74

port connector (except by cannibalizing an existing cartridge)...

Hope this helps.

Jack

I'm less concerned about paging bits, as I have created a 512kB ROM/512kB RAM cart that includes a small CPLD. Since all signals are present on the bus, it is trivial to decode a specific address (not in the CART ROM or CART RAM space) and use that register to bank the RAM and ROM. Any externally accessible memory location can be used.

I have a few goals:

  • create 2 banking registers. One for the lower 16kB of memory, and one for the upper
  • Create a config register for the two banks (00 = nothing,, 01 = rw ram, 10 = read only ram, 11 = rom)
  • See if I can map memory into the various unused places in the memory map from the cartridge space, to completely fill the unit with RAM
 
I added some .02 to the CC-40 thread on Atariage:

http://atariage.com/forums/topic/255728-the-compact-computer-40-cc40/?p=3905368

I'm not quite too sure how it did it, but the Editor Assembler cart was 64K and was paged between two 32K banks. Ksarul will have to tell us how A15 was hooked up, but the cart was super simple. One EPROM and one resistor. I'm guessing one of the CC-40 pins was hooked up to A15 on the 27512, and toggled it somehow to switch between the two 32K banks.

Once switched though, if I remember how I dumped it correctly, it stayed in that 32K bank when you quit the program. When you ran the other program in the cart, it switched banks and ran it. Part of the cart has Editor Assembler and part of the cart has Memo Processor. My guess is that they had to modify the cartridge header in both carts, or that the CC-40's ROM by default can scan multiple banks for the program headers itself (and in this case, I'd have to do a DIFF on Memo Processor in EA vs Memo Processor stand alone to prove it's the same or not.)

Edit: The memo processor binaries in the stand alone and the EA cart are both identical. I'm surmising the CC-40 ROM can do paging built in and determine if there are multiple 32K banks to scan. To prove or disprove this, we would have to put two 32K images in a 64K EPROM and hook it up like the EA cart and see if it actually will run either program.
 
The new version of the ROM carts has the PORT25.2 pin connected to the A15 line (via a jumper, not connected by default. By soldering it shut, you can test.
 
I just bought a cc-40 on eBay today. Are either the ram cartridges close to release, or maybe even a multicart of programs?
 
...I am trying to sort out how it was decided that the two bits were to be used for paging. Are there routines in the ROM using them in that way?

Sorry I missed this 1st time through... I loaded Acadiel's dump of his

EA cartridge into a breadboarded 128K RAM which used the pins in

question for paging bits. The 64K EA image worked as advertised, so I

think it's reasonable to assume the presumptive paging bits have been

identified. Also, one of the CC40 User Manual Appendices refers to P25

as the "Page Control Register" - RTFM strikes again... "8)

p.s. - Toggling P25.2 & 3 with DEBUG toggles the appropriate cartridge

port pins - QED...
 
Last edited:
For the guys who don't have a PCIF -

From the BASIC command line, enter the following line:

100 DATA #################################

Yep, that's 33 of them... Now, enter CALL DEBUG. In the monitor,

enter "D 4FD4". Press [ENTER].

Enter the bytes listed in the attachment, pressing [+] after each entry.

Your last entry should be >0A at >4FF4. Double-check your entries.

If it's not exactly as listed results will be "undefined"...


Exit the monitor, & from the BASIC command line enter:

110 PAGE=5

120 CALL POKE(20469,PAGE):CALL EXEC(20436)

130 PRINT "BREAK":pAUSE ! demonstrates that routine returns to BASIC


Once more, the DATA statement must be the first line in your pgm for the

offset addresses to be correct. The routine assumes it's running on an 18K

CC40 - If you have something else then you'll have to recalculate the CALL

addresses. The PAGE offset is 11 bytes from HIRAM; EXEC offset is 43.

If you use the routine from assembler it can go anywhere; put the Page #

in A and call the address @ >4FD7 (in this case.)

I'll post a loadable subpgm soon.


One more thing - If you do have a PCIF, you can enter the pgm as above,

and then SAVE it to PC - The DATA statement looks odd, but can be cut &

pasted without problems, as long as you don't inadvertently truncate it.


Have fun :)
Does this work with the 512k RAM Cartridge?
 
Does anyone know the address(es) of the PAB?
I want to make a peripheral to perform a specific function in my hobby work, and I have the hardware figured out to talk to the HexBus. I need to work on the software now to complete it. I believe using the PAB will help accomplish that goal.
 
Back
Top