- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Fun with CC40's
- Thread starter JGardner
- Start date
krebizfan
Veteran Member
What do you do with 512kB RAM on that?
krebizfan
Veteran Member
...What do you do with 512kB RAM on that?
Just about anything you might do with a PDP-8.
Except run up a big electric bill. Easier to move too...
I knew TI was reluctant to produce data storage for the CC40 but that looks like a lot of work just to get DECTape running.
It is an impressive feat though.
ClassicHasClass
Veteran Member
Wafertape, ladies.
That is all.
(Yes, I have one of them. It works okay last I tested it, though I never used it heavily.)
That is all.
(Yes, I have one of them. It works okay last I tested it, though I never used it heavily.)
byates
Experienced Member
Any chance of a better look at the circuit? It would be interesting to see if it could be adapted to a TI-74.
Hi byates -
Unfortunately this scheme won't work with a TI-74. The CC40 cartridge port has two paging
bits available; as intended by the designers it will support 128K. I use those two bits as an
I2C bus to control a MCP23008 (a so-called 'port expander') to specify the high 4 bits of the
512K address. As presently constituted 23 bits are available; the scheme could address 8M.
The 74 cartridge port does'nt have paging bits; something else will have to be concocted.
There are multi-page '74 ROM cartridges; it's possible to use <Writes> to ROM to control
paging. For RAM, I think you'd need to decode a specific address and use that for page
control.
Unfortunately this scheme won't work with a TI-74. The CC40 cartridge port has two paging
bits available; as intended by the designers it will support 128K. I use those two bits as an
I2C bus to control a MCP23008 (a so-called 'port expander') to specify the high 4 bits of the
512K address. As presently constituted 23 bits are available; the scheme could address 8M.
The 74 cartridge port does'nt have paging bits; something else will have to be concocted.
There are multi-page '74 ROM cartridges; it's possible to use <Writes> to ROM to control
paging. For RAM, I think you'd need to decode a specific address and use that for page
control.
byates
Experienced Member
JGardner, thanks for the info. Looks like I will have to dig deeper if I want to expand it.
byates -
Perhaps the easiest thing to implement on the '74 would be to use the Dockbus port pins
to set the high address bits of cartridge RAM, using what TI calls "non-standard I/O mode",
aka BAV high & HSK low. Writes to the data port then appear immediately on the port out-
put pins.
Of course this means some wires (4) between the Dockbus port & the cartridge, and you'd
be limited to 512K, but I can't see any reason why it would'nt work fine, & the price would
be pretty hard to beat... Come to think of it, put a crowbar in your wallet & spring for an
extra wire & you could toggle BAV too, for a cool MB.
Think I'll try it - If you don't beat me to it...
Perhaps the easiest thing to implement on the '74 would be to use the Dockbus port pins
to set the high address bits of cartridge RAM, using what TI calls "non-standard I/O mode",
aka BAV high & HSK low. Writes to the data port then appear immediately on the port out-
put pins.
Of course this means some wires (4) between the Dockbus port & the cartridge, and you'd
be limited to 512K, but I can't see any reason why it would'nt work fine, & the price would
be pretty hard to beat... Come to think of it, put a crowbar in your wallet & spring for an
extra wire & you could toggle BAV too, for a cool MB.
Think I'll try it - If you don't beat me to it...
I've attached a wiring list for anyone wishing to try their hand at big CC40 RAM cartridges.
Mine works - YMMV. Readers are welcome to contact me for a current, unhacked version
of the document. I'll make paging software available as well, "soon" - It's a bit, umm,
unpolished, at the moment. Have fun...
Mine works - YMMV. Readers are welcome to contact me for a current, unhacked version
of the document. I'll make paging software available as well, "soon" - It's a bit, umm,
unpolished, at the moment. Have fun...
Paging - This works in an Assembler environment, but if called from BASIC crashes.
At a guess, changing pages boogers up the checksum; hopefully disassembling CTERP
will shed some light on this. We'll see...
Feel free to contact me for an unhacked version.
* Note that attachment has been edited to correct the customary blunders. Sigh...
At a guess, changing pages boogers up the checksum; hopefully disassembling CTERP
will shed some light on this. We'll see...
Feel free to contact me for an unhacked version.
* Note that attachment has been edited to correct the customary blunders. Sigh...
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"AUSE ! 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
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"
AUSE ! demonstrates that routine returns to BASICOnce 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
Last edited:
smp
Veteran Member
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?
I've just acquired my TI-74, and I haven't started experimenting with it yet. I have an 8K RAM module (which most probably has a dead battery) as well as the Statistics and Finance ROM modules. I was figuring on opening the 8K RAM module to see if the battery might be replaced.
smp
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.
Last edited:
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.
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
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.
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
smp
Veteran Member
That is exactly what I was thinking. I have these extra Finance and Statistics modules, as well as the 8K RAM with the dead battery. I also have a Dallas DS1220Y-150+ device. My initial thoughts were to rig that up as a 2Kx8 non-volatile memory, if I cannot get the battery backup to work on my 8K RAM module. Do you have any experience with taking these modules apart?
smp
Last edited: