Search the Community
Showing results for tags 'CF7'.
Found 2 results
I have a question for people running CF7’s or Nano-PEB’s… Do any of you have a REAL-TIME CLOCK installed in your systems? Does one even exist? If not… one of those “clocks-on-a-chip” could be mounted on a small PCB with a chip containing the DSR software and support circuitry, it could then be easily be soldered onto the speech synthesizer circuit board and reside within the same case! Since the speech synthesizer has that little door, it would also give easy access to a battery holder mounted right underneath. This is an option I WOULD BUY! For some Uber programmers, this code would be childs play. If it could be compatible with say, the old CorComp Clock, people would be able to have full functionality in old very useful programs like “Remind-Me!”, use the “Super Clock Support utilities” or even new stuff that could be released in the future. Does this type of thing interest any of you NANO-PEB or CF7 users? P.S. -- One question added later... It's been 24 years now, so my memory is foggy, but didn't the BOOT MENU program also make use of the Real-Time Clock feature of the CorComp card?
Here is the problem and solution I posted to the Yahoo Forums a few years ago. Be aware that the CF7/nanoPEB and other devices (ie, disk controllers) use VDP RAM which might not be reserved in emulation/simulation. I didn't specify a FWEB version in my original post, but I am fairly certain I based this on v4.40. IIRC, the v5.0 release is limited to editor and other non-loader files. FWEB PROBLEM OVERVIEW: 1. The CF7+ device stores 8 bytes of volume control data starting at VDP address 0x3ff8. 2. The CF7+ mimics the TI Disk controller, and uses VDP RAM for its IO operations. 3. A TI Disk Controller reserves VDP memory 0x37d8 to 0x3fff. 4. A CF7+ device reserves VDP memory 0x37d1* to 0x3fff. 5. TI and CF7+ both contain a 5 byte header at the beginning of this VDP RAM. When FWEB launches it reads the first available VDP address from location 0x8370. It then re-creates the header in RAM, writes it to VDP, and clears the controller-reserved VDP memory with the exception of the header. In the case of the CF7+, this is 0x37d7 to 0x3fff. Because the CF7+ device uses 8 bytes to keep track of its volume info but does not "hide" them from other programs, FWEB is able to unwittingly create a condition where the CF7+ can no longer find ivolume information. Essentially, the device gets lost and can no longer access disks, creating lockup and "file not found" conditions. FWEB PROBLEM FIX: We need to help FWEB to "properly" set the VDP pointers and inhibit its clearing the CF7+ volume info. To do this, use your favorite file editor to locate the following three HEX strings and modify as directed: 1. Find "1afb 0220 0010" and replace with "1afb 0220 0018" 2. Find "fa94 0220 fdea" and replace with "fa94 0220 fde2" 3. Find "0580 8800 fa94" and replace with "0580 0280 3ff8" All three changes should be located within the same sector. Note: There are THREE files requiring the changes. IIRC they are: FW, UTIL1 (or UT), and LOAD. DSKU 4.2 return to FW problem: After loading FW, DSKU clears PAD Ram from 0x8300 to 0x83C6. Doing so destroys 0x8370, the VDP Disk Buffer Area pointer, which creates a nasty situation for FWEB and the CF7. During powerup the TI sets this value to 0x37d7 (or 0x37cf for compact flash). DSKU 4.2 FIX: Within the file DU (first file) replace "0281 83C6" with "0281 8348". DSKU inhibits interrupts so any in-place ISR should not wreak havoc between loading the file and re-starting FW. (*Edit: 0x73d1 probably should read 0x73d0 to reflect the 8 byte difference)