Loading ...
Sorry, an error occurred while loading the content.
 

Strange discovery with stop + reset, run and Bytesaver

Expand Messages
  • tkaragiris
    Hi All, First some background, over the last few weeks I ve spent some time on a mini project to reconfiguring my 8k Bytesaver card to run 8k Basic. For a
    Message 1 of 28 , Jul 25, 2014
      Hi All,

      First some background, over the last few weeks I've spent some time on a mini project to reconfiguring my 8k Bytesaver card to run 8k Basic.  For a while now I've been using John Garza's 2k Altair Rom monitor, which I really like, it has some great features.  But I've wanted to cut it down to 1k and re-address it, so I could fit 8k Basic on the other 7 roms in the Bytesaver.  I spent some time with the source code and  managed to remove some features that I don't use and get it to assemble at just under 1k.  I used CP/M running under the SIMH AltairZ80 emulator to re-assemble the monitor and I used mload to create the stand alone binary.  All worked well!  I now have the 1k Altair Rom addressed at E000 and 8k Basic addressed from E400 to FFFF.  And using the block move and run feature of the monitor I can transfer Basic to ram and run it instantly. 

      Now to the strange discovery that I made with my machine.  Since addressing the monitor to E000 which corresponds to the first slot of the 8k Bytesaver, whenever I turn on the Altair and simply hit stop, reset and run (all address switches down), I can run the monitor at address E000.  I only just discovered this, usually I would examine address E000 manually and then hit run. 

      Now, how is it possible that I can simply hit reset and run from a cold boot and the monitor at address 56k will run??  I've never read that the 8k Bytesaver has any feature like this, so I'm pretty sure it's not that.  I've also checked that the Bytesaver is addressed properly and not somehow overlapping ram, and it's addressed properly at E000. 

      Once observation I've made is that my particular Altair has a non standard jumper wire installed on the back of the front panel, the wire is connected to the run switch.  Until now I've never had any idea why that wire was, but I suspect it may be wired to jump to the rom card and run from there.  If so it's an amazing co-incidence.  Can anyone shed any light on how my machine is capable of jumping to the rom card?

      A while back I posted a picture of the back of my front panel on the VCF, you can see the jumper wire here:

      http://www.vintage-computer.com/vcforum/attachment.php?attachmentid=14000&d=1371893584











    • Craig Landrum
      ... It probably depends on your RAM configuration and what kind of card(s) comprise your RAM. Two thoughts occur to me - with all switches down, you would
      Message 2 of 28 , Jul 25, 2014
        > Can anyone shed any light on how my machine is capable
        > of jumping to the rom card?

        It probably depends on your RAM configuration and what kind of card(s)
        comprise your RAM. Two thoughts occur to me - with all switches down,
        you would normally be starting execution at address 0000. If that
        address contained a 0 (which is an 8080/Z80 NOP) instruction, it would
        simply advance the PC + 1 and fetch the next instruction. If all of your
        RAM came up initialized to zero, you would end up executing about 57,344
        NOPs before you hit the first non-zero executable code at E000.

        On the other hand, perhaps your RAM at address 0000 initializes to FFh.
        In that case the processor would execute an RST 7 instruction which
        (if my aging memory serves me) effectively does a CALL 0038H, which means
        the processor begins executing instructions at 0038h. If that address
        were to contain something like C3 00 E0... (i.e. JMP E000 ), that would
        go directly to your EPROM at E000.

        The Z80 (not sure about the 8080) also had an interrupt mode whereby
        an interrupting device could supply a portion of the address to which the
        processor would jump to service the interrupt. The Z80 systems we
        built back in the day depended on this capability which worked quite
        well. Probably not involved in what you are seeing however.

        --
        Craig Landrum
        Chief Technical Officer
        mindwrap, inc.
        Phone: (540) 347-2552 x 229
        Fax: (540) 347-2556
        email: craigl@...
      • B Degnan
        Is the ROM code on the Yahoo site? I d be happy to test my system if you d like/compare contrast to confirm. Bill ... From: Craig Landrum craigl@mindwrap.com
        Message 3 of 28 , Jul 25, 2014
          Is the ROM code on the Yahoo site? I'd be happy to test my system if you'd like/compare contrast to confirm.
          Bill



          -----Original Message-----
          From: Craig Landrum craigl@... [altaircomputerclub] <altaircomputerclub@yahoogroups.com>
          To: altaircomputerclub <altaircomputerclub@yahoogroups.com>
          Sent: Fri, Jul 25, 2014 9:39 am
          Subject: Re: [Altair Computer Club] Strange discovery with stop + reset, run and Bytesaver

          > Can anyone shed any light on how my machine is capable 
          
          > of jumping to the rom card?
          It probably depends on your RAM configuration and what kind of card(s) comprise your RAM. Two thoughts occur to me - with all switches down, you would normally be starting execution at address 0000. If that address contained a 0 (which is an 8080/Z80 NOP) instruction, it would simply advance the PC + 1 and fetch the next instruction. If all of your RAM came up initialized to zero, you would end up executing about 57,344 NOPs before you hit the first non-zero executable code at E000. On the other hand, perhaps your RAM at address 0000 initializes to FFh. In that case the processor would execute an RST 7 instruction which (if my aging memory serves me) effectively does a CALL 0038H, which means the processor begins executing instructions at 0038h. If that address were to contain something like C3 00 E0... (i.e. JMP E000 ), that would go directly to your EPROM at E000. The Z80 (not sure about the 8080) also had an interrupt mode whereby an interrupting device could supply a portion of the address to which the processor would jump to service the interrupt. The Z80 systems we built back in the day depended on this capability which worked quite well. Probably not involved in what you are seeing however. -- Craig Landrum Chief Technical Officer mindwrap, inc. Phone: (540) 347-2552 x 229 Fax: (540) 347-2556 email: craigl@... ------------------------------------ Posted by: Craig Landrum <craigl@...> ------------------------------------ ------------------------------------ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/altaircomputerclub/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/altaircomputerclub/join (Yahoo! ID required) <*> To change settings via email: altaircomputerclub-digest@yahoogroups.com altaircomputerclub-fullfeatured@yahoogroups.com <*> To unsubscribe from this group, send an email to: altaircomputerclub-unsubscribe@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
        • B Degnan
          (with same card installed in my Altair I mean, apples to apples.). Do you have a picture of the added jumper? ... From: B Degnan billdeg@aol.com
          Message 4 of 28 , Jul 25, 2014
            (with same card installed in my Altair I mean, apples to apples.).  Do you have a picture of the added jumper?



            -----Original Message-----
            From: B Degnan billdeg@... [altaircomputerclub] <altaircomputerclub@yahoogroups.com>
            To: altaircomputerclub <altaircomputerclub@yahoogroups.com>
            Sent: Fri, Jul 25, 2014 10:18 am
            Subject: Re: [Altair Computer Club] Strange discovery with stop + reset, run and Bytesaver



            Is the ROM code on the Yahoo site? I'd be happy to test my system if you'd like/compare contrast to confirm.
            Bill



            -----Original Message-----
            From: Craig Landrum craigl@... [altaircomputerclub] <altaircomputerclub@yahoogroups.com>
            To: altaircomputerclub <altaircomputerclub@yahoogroups.com>
            Sent: Fri, Jul 25, 2014 9:39 am
            Subject: Re: [Altair Computer Club] Strange discovery with stop + reset, run and Bytesaver

            > Can anyone shed any light on how my machine is capable 
            
            > of jumping to the rom card?
            It probably depends on your RAM configuration and what kind of card(s) comprise your RAM. Two thoughts occur to me - with all switches down, you would normally be starting execution at address 0000. If that address contained a 0 (which is an 8080/Z80 NOP) instruction, it would simply advance the PC + 1 and fetch the next instruction. If all of your RAM came up initialized to zero, you would end up executing about 57,344 NOPs before you hit the first non-zero executable code at E000. On the other hand, perhaps your RAM at address 0000 initializes to FFh. In that case the processor would execute an RST 7 instruction which (if my aging memory serves me) effectively does a CALL 0038H, which means the processor begins executing instructions at 0038h. If that address were to contain something like C3 00 E0... (i.e. JMP E000 ), that would go directly to your EPROM at E000. The Z80 (not sure about the 8080) also had an interrupt mode whereby an interrupting device could supply a portion of the address to which the processor would jump to service the interrupt. The Z80 systems we built back in the day depended on this capability which worked quite well. Probably not involved in what you are seeing however. -- Craig Landrum Chief Technical Officer mindwrap, inc. Phone: (540) 347-2552 x 229 Fax: (540) 347-2556 email: craigl@... ------------------------------------ Posted by: Craig Landrum <craigl@...> ------------------------------------ ------------------------------------ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/altaircomputerclub/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/altaircomputerclub/join (Yahoo! ID required) <*> To change settings via email: altaircomputerclub-digest@yahoogroups.com altaircomputerclub-fullfeatured@yahoogroups.com <*> To unsubscribe from this group, send an email to: altaircomputerclub-unsubscribe@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/


          • deramp5113
            Most likely your unitialized RAM tends to power up into values that allow code execution starting at zero to eventually reach E000 without hitting a HALT or
            Message 5 of 28 , Jul 25, 2014
              Most likely your unitialized RAM tends to power up into values that allow code execution starting at zero to eventually reach E000 without hitting a HALT or ending up in an endless loop. I've had that happen before, ending up in the Turnkey Monitor ROM (on a non-turnkey Altair) when reseting and running from zero.

              In your picture, the wire on the run switch is actually connected to the "STOP" side of the switch (raising the switch connects the bottom two terminals together), so most likely it was routed to logic elsewhere that allowed a program to stop the machine. Or maybe it went to other logic that needed to "know" the machine was just manually stopped.

              Mike

            • corey986
              I would think the wire has nothing to do with the issue as has been stated here. My guess it that the wire is hooked up to an unused pin on the Altair/S100
              Message 6 of 28 , Jul 25, 2014
                I would think the wire has nothing to do with the issue as has been stated here.  My guess it that the wire is hooked up to an unused pin on the Altair/S100 bus and used to reset a card that was in the machine like a UART card or something.  

                Cheers,
                Corey
              • tkaragiris
                Craig, I think you re right, what s happening is that it s just executing from location zero all the way up to the first rom location. The ram card that I use
                Message 7 of 28 , Jul 26, 2014
                  Craig,

                  I think you're right, what's happening is that it's just executing from location zero all the way up to the first rom location.  The ram card that I use is a Claifornia Computer Systems 64k dynamic ram, it's a fairly late card dated 1981.  In some quick tests that I did, after initial power on and  stop + reset, the ram seems to be consistently initialized with the following pattern:

                  0000 FF00FF00 FF00FF00 FF00FF00 FF00FF00 ................
                  0010 FF00FF00 FF00FF08 FF00FF02 FF00FF02 ................
                  0020 FF00FF00 FF00F700 FF00FF04 FF04FF04 ................
                  0030 FF00FF00 FF00FF08 FF00FF00 FF02FF02 ................

                  Every odd byte is set to FF and every even byte is mostly set to zero and occasionally some other value.
                • tkaragiris
                  Bill, If you d like to try the monitor I ve uploaded it to the files section. I ve created a folder called tkaragiris, it has the source code that I modified
                  Message 8 of 28 , Jul 26, 2014
                    Bill,

                    If you'd like to try the monitor I've uploaded it to the files section.  I've created a folder called tkaragiris, it has the source code that I modified to build the 1k monitor and the bin version which runs at E000.  One thing I noticed that was missing from this monitor was the initialization code for the Motorola 6850.  So I've added that  too, although I haven't tested that yet.

                    A little background is necessary to explain what I mean.  I have two serial cards: SSMIO4 and the MITS 88-2SIO.  The two serial cards work exactly the same in terms of MITS software, but the SSMIO4 doesn't require any software initialization like the 88-2SIO does.   When I first tried the Altair ROM monitor using the SSMIO4 it worked fine.  You'd power the machine up, hit stop and reset, address the rom monitor and run.  All worked.  When I tried it with the 88-2SIO, I found that it didn't work unless I first entered the 8 byte initialization code for the 6850.  Then it worked fine.  And later when I went through the source code of the original monitor I noticed that it didn't contain the 6850 initialization code.  So I've now added it.  So far I've tested the 1k monitor with the SSMIO4 and it seems to work fine.  But I  haven't yet got around to testing it with the 88-2SIO yet, as I don't have that card installed at the moment.
                  • tkaragiris
                    Mike, Yes, good observation about the jumper wire, it s definitely connected to the stop switch so that rules that out.
                    Message 9 of 28 , Jul 26, 2014
                      Mike,

                      Yes, good observation about the jumper wire, it's definitely connected to the stop switch so that rules that out.
                    • deramp5113
                      All you really need to make what you re seeing happen is a 0xFF at zero (you have it), a 0xFF at 0x38 (you have it) and the 8080 SP powering up to 0x38 or less
                      Message 10 of 28 , Jul 26, 2014
                        All you really need to make what you're seeing happen is a 0xFF at zero (you have it), a 0xFF at 0x38 (you have it) and the 8080 SP powering up to 0x38 or less (zero is typical, though not guaranteed).  These three conditions will cause execution from location zero to magically run the first PROM in memory. This is what is happening with your machine. 

                        Mike


                      • Bill Deg.
                        thank you for the details. look forward to trying. Bill ... From: tkaragiris@gmail.com [altairco... Date: Sat, Jul 26, 2014 8:53 PM To:
                        Message 11 of 28 , Jul 26, 2014

                          thank you for the details.  look forward to trying.

                          Bill

                           

                          ............

                           

                           

                          ------ Original message------

                          From: tkaragiris@... [altairco...

                          Date: Sat, Jul 26, 2014 8:53 PM

                          To: altaircomputerclub@yahoogroups.com;

                          Subject:[Altair Computer Club] Re: Strange discovery with stop + reset, run and Bytesaver

                           



                          Bill,

                          If you'd like to try the monitor I've uploaded it to the files section.  I've created a folder called tkaragiris, it has the source code that I modified to build the 1k monitor and the bin version which runs at E000.  One thing I noticed that was missing from this monitor was the initialization code for the Motorola 6850.  So I've added that  too, although I haven't tested that yet.

                          A little background is necessary to explain what I mean.  I have two serial cards: SSMIO4 and the MITS 88-2SIO.  The two serial cards work exactly the same in terms of MITS software, but the SSMIO4 doesn't require any software initialization like the 88-2SIO does.   When I first tried the Altair ROM monitor using the SSMIO4 it worked fine.  You'd power the machine up, hit stop and reset, address the rom monitor and run.  All worked.  When I tried it with the 88-2SIO, I found that it didn't wo rk unless I first entered the 8 byte initialization code for the 6850.  Then it worked fine.  And later when I went through the source code of the original monitor I noticed that it didn't contain the 6850 initialization code.  So I've now added it.  So far I've tested the 1k monitor with the SSMIO4 and it seems to work fine.  But I  haven't yet got around to testing it with the 88-2SIO yet, as I don't have that card installed at the moment.

                        • D. Hugh Redelmeier
                          ... This is a little tricky, so I tried to figure out the details. Let s assume that SP starts at 0x0000. 0xFF at 0 is an RST call to 0x0038 (pushing 0x00 0x01
                          Message 12 of 28 , Jul 27, 2014
                            | From: "deramp5113@... [altaircomputerclub]"

                            | All you really need to make what you're seeing happen is a 0xFF at zero
                            | (you have it), a 0xFF at 0x38 (you have it) and the 8080 SP powering up
                            | to 0x38 or less (zero is typical, though not guaranteed). These three
                            | conditions will cause execution from location zero to magically run the
                            | first PROM in memory. This is what is happening with your machine.

                            This is a little tricky, so I tried to figure out the details.

                            Let's assume that SP starts at 0x0000.

                            0xFF at 0 is an RST call to 0x0038 (pushing 0x00 0x01 on the stack.

                            0xFF at 0x0038 is an RST call to 0x0038 (pushing 0x00 0x39 on the stack)

                            Repeat this until the stack smashes downwards into 0x0038.

                            The processor will then execute the following, starting at 0x0038
                            0x00 NOP
                            0x39 (octal 071) DAD SP
                            0x00 NOP
                            0x39 (octal 071) DAD SP
                            0x00 NOP
                            0x39 (octal 071) DAD SP
                            0x00 NOP
                            0x39 (octal 071) DAD SP
                            etc.

                            Until it gets to the first bit that isn't written over by the stacking
                            of return addresses.

                            If your machine has RAM up until 0xE000, then it will get all the way
                            up to that. Just what you want.
                          • deramp5113
                            Oh yes, good point, RAM must also be contiguous up to the base of the lowest PROM address! Mike
                            Message 13 of 28 , Jul 27, 2014
                              Oh yes, good point, RAM must also be contiguous up to the base of the lowest PROM address!

                              Mike
                            • tkaragiris
                              Yes, it s certainly the case, I have the full 64k enabled and the Bytesaver overrides the top 8k, so 56k ram and then 8k rom with no gaps.
                              Message 14 of 28 , Jul 27, 2014
                                Yes, it's certainly the case, I have the full 64k enabled and the Bytesaver overrides the top 8k, so 56k ram and then 8k rom with no gaps.
                              • D. Hugh Redelmeier
                                ... (I haven t played with my Altair for a long time, so I don t remember the details very well. I could have this all wrong.) How can you have a Bytesaver
                                Message 15 of 28 , Jul 27, 2014
                                  | From: "tkaragiris@... [altaircomputerclub]"

                                  | Yes, it's certainly the case, I have the full 64k enabled and the
                                  | Bytesaver overrides the top 8k, so 56k ram and then 8k rom with no gaps.

                                  (I haven't played with my Altair for a long time, so I don't
                                  remember the details very well. I could have this all wrong.)

                                  How can you have a "Bytesaver override the top 8k"? Is there not a
                                  problem if more than one board responds to an address? (Perhaps the
                                  result would be an AND of the two results since the TTL drive to 0 is
                                  stronger than the drive to 1.)

                                  If I remember correctly, I have a 64K dynamic RAM board with a dip
                                  switch that allows each bank of 16k to be separately enabled. I leave
                                  the top one off so that I can use the 8k Bytesaver. This wastes 8K of
                                  address space.

                                  (In fact, I use a couple of 4K static RAM boards to fill in the hole.)

                                  It would be great to leave all the RAM enabled but have my Bytesaver
                                  grab references to its address range.

                                  P.S. I was given a ARM Cortex-M3 NXP LPC-1768 board this week. Kind
                                  of funny that it has half the RAM compared with my Altair. Its 512K
                                  flash beats my Bytesaver's 8k.
                                  <https://mbed.org/platforms/mbed-LPC1768/>
                                • tkaragiris
                                  Not sure how my system does it but I recall when I got the ram card at first I had the top 16k disabled, but then I just tried it with all ram banks enabled
                                  Message 16 of 28 , Jul 27, 2014
                                    Not sure how my system does it but I recall when I got the ram card at first I had the top 16k disabled, but then I just tried it with all ram banks enabled and the bytesaver address to the top 8k and it just works.  I haven't had any issues with overlapping memory.  If I address the top 8k it just reads the bytesaver.
                                  • Systems Glitch
                                    ... The Bytesaver is probably asserting /PHANTOM and the RAM is probably respecting it. I don t have a Bytesaver but the other Cromemco boards I have (4FDCs,
                                    Message 17 of 28 , Jul 28, 2014
                                      > Not sure how my system does it but I recall when I got the ram card at first I had the top 16k disabled, but then I just tried it with all ram banks enabled and the bytesaver address to the top 8k and it just works. I haven't had any issues with overlapping memory. If I address the top 8k it just reads the bytesaver.

                                      The Bytesaver is probably asserting /PHANTOM and the RAM is probably respecting it. I don't have a Bytesaver but the other Cromemco boards I have (4FDCs, various RAM) expect /PHANTOM to work in their default configuration. Always sort of thought a /PHANTOM indicator would be useful on a front panel, then you'd know where the mystery ROM in a RAM bank is coming from!

                                      Thanks,
                                      Jonathan
                                    • deramp5113
                                      The 8K Bytesaver responds to /PHANTOM in, but it does not generate /PHANTOM out. However, it is not a difficult mod to make the board generate /PHANTOM out
                                      Message 18 of 28 , Jul 28, 2014
                                        The 8K Bytesaver responds to /PHANTOM in, but it does not generate /PHANTOM out. However, it is not a difficult mod to make the board generate /PHANTOM out instead. It may be that such a mod has been done to Theo's card. If so, that would explain how the overlaid RAM and the Bytesaver are not conflicting.

                                        Theo, take a look at bus pin 67 on the Bytesaver board and follow traces from there. Any signs of modification?

                                        Mike

                                      • tkaragiris
                                        Mike, I ve got some high-res pics of my Bytesaver card on my website, see this page, click on the first two pics to get high res versions: tkc8800.com |
                                        Message 19 of 28 , Jul 28, 2014
                                          Mike,

                                          I've got some high-res pics of my Bytesaver card on my website, see this page, click on the first two pics to get high res versions:

                                          tkc8800.com | Cromemco 8k Bytesaver eprom card

                                           

                                          Am I right in saying that pin 67 would be the 17th from the right on the solder side?

                                          If so, it looks blank to me.
                                        • deramp5113
                                          Theo, Nope, I don t see a mod either. If this board overlays your RAM, then you probably have a bus conflict and the Bytesaver is winning - though both boards
                                          Message 20 of 28 , Jul 28, 2014
                                            Theo, 

                                            Nope, I don't see a mod either. If this board overlays your RAM, then you probably have a bus conflict and the Bytesaver is winning - though both boards could be damaged by this, especially if you examine PROM locations on the front panel which leaves the bus divers on each board indefinitely. 


                                          • tkaragiris
                                            Mike, Ok thanks, that doesn t sound good, I don t want to damage anything. What I ll do is disable bank 4 on the ram card, that should fix it. It leaves and
                                            Message 21 of 28 , Jul 28, 2014
                                              Mike,

                                              Ok thanks, that doesn't sound good, I don't want to damage anything.  What I'll do is disable bank 4 on the ram card, that should fix it.  It leaves and 8k gap but I'd rather have that than run the risk of damage.  The ram banks are easy to disable just a jumper shunt on the card.

                                              Thanks,
                                              Theo
                                            • deramp5113
                                              Check and see if your RAM board responds to /PHANTOM in. If so, you could mod the Bytesaver to generate /PHANTOM out when accessed. Then it would be OK if the
                                              Message 22 of 28 , Jul 28, 2014
                                                Check and see if your RAM board responds to /PHANTOM in. If so, you could mod the Bytesaver to generate /PHANTOM out when accessed. Then it would be OK if the Bytesaver overlays the RAM.

                                                Mike
                                                 
                                              • tkaragiris
                                                Yes, the CCS 64k does support phantom in, it s jumper selectable on the card. This is the ram card that I m currently using: S100 Computers - California
                                                Message 23 of 28 , Jul 28, 2014
                                                  Yes, the CCS 64k does support phantom in, it's jumper selectable on the card.  This is the ram card that I'm currently using:

                                                  S100 Computers - California Computer Systems 2065 64K DRAM

                                                   

                                                • Systems Glitch
                                                  You can add /PHANTOM on an external card, if you didn t want to add it to the Bytesaver; however, you d also have to disable /PHANTOM on the Bytesaver (not
                                                  Message 24 of 28 , Jul 29, 2014
                                                    You can add /PHANTOM on an external card, if you didn't want to add it to the Bytesaver; however, you'd also have to disable /PHANTOM on the Bytesaver (not sure if it's a jumper-able option, or if you'd have to cut a trace/insulate edge connector pin 67).

                                                    It looks like the CCS board supports Cromemco bank select, so you should be able to switch out the top 32K of the CCS board when you want to use the Bytesaver, and switch the Bytesaver out when you want a full 64K of RAM.

                                                    Thanks,
                                                    Jonathan

                                                    On 28 Jul 2014 22:02:13 -0700
                                                    "tkaragiris@... [altaircomputerclub]" <altaircomputerclub@yahoogroups.com> wrote:

                                                    > Yes, the CCS 64k does support phantom in, it's jumper selectable on the card. This is the ram card that I'm currently using:
                                                    >
                                                    > S100 Computers - California Computer Systems 2065 64K DRAM http://s100computers.com/Hardware%20Folder/CCS/2065%2064K%20DRAM/2065%2064K%20DRAM.htm
                                                    >
                                                    > http://s100computers.com/Hardware%20Folder/CCS/2065%2064K%20DRAM/2065%2064K%20DRAM.htm
                                                    >
                                                    > S100 Computers - California Computer Systems 2065 6... http://s100computers.com/Hardware%20Folder/CCS/2065%2064K%20DRAM/2065%2064K%20DRAM.htm S100 Computers
                                                    >
                                                    >
                                                    >
                                                    > View on s100computers.com http://s100computers.com/Hardware%20Folder/CCS/2065%2064K%20DRAM/2065%2064K%20DRAM.htm
                                                    > Preview by Yahoo
                                                    >
                                                    >
                                                    >
                                                  • deramp5113
                                                    Until you posted the pictures, I was thinking Bytesaver II this whole time (probably because that s what I have!). The original Bytesaver that you have does
                                                    Message 25 of 28 , Jul 29, 2014
                                                      Until you posted the pictures, I was thinking "Bytesaver II' this whole time (probably because that's what I have!). The original Bytesaver that you have does NOT respond to /PHANTOM in, so adding a /PHANTOM out mod is actually even simpler.

                                                      The Bytesaver "almost" has a /PHANTOM out signal already present, but it's on pin 69 instead of 67. Pin 69 is the Altair Bus /PROTECT STATUS signal (not an official S-100 signal). With early Altair memory boards that supported the front panel Protect/Unprotect switch, a memory board was supposed to assert this signal (drive low via open-collector) whenever the board was accessed in a memory range for which writes were disabled. The Bytesaver board drives this signal low (effectively open-collector using a tri-state buffer), any time the board is addressed AND the program power switch is "off" (meaning you can't write to the board). Look at the PROT LED on the front panel of your Altair when you examine memory locations E000-FFFF. You'll see the light comes on. When you examine locations outside the Bytesaver's range, the PROT LED is off.

                                                      So if you enable /PHANTOM on your memory board, and no memory board in your system drives pin 69 (most likely none of them do), then you can simply jumper from pin 69 to pin 67 on the Bytesaver (I'd connect from the feed-through hooked to pin 69 and then solder-tack to the top of pin 67). This should work as a typical open-collector /PHANTOM output and also let you see the fact it's working on the PROT LED!

                                                      This simple mod will work UNLESS YOU TURN ON THE PROGRAM POWER SWITCH. In other words, with this simple mod, you'll have to disable the upper 16K on your RAM board anytime you want to program EPROMs.

                                                      For a most robust /PHANTOM out mod, also perform these steps:

                                                      1) Remove U16 from its socket, pull pin 10 out just a bit, and put the chip back in the socket. This leaves pin 10 just outside the socket and now disconnected from the program power switch.

                                                      2) Connect a jumper directly from pin 10 on the IC to ground.

                                                      These additional steps let /PHANTOM out work even when programming an EPROM.

                                                      Finally, if the Bytesaver will ever be used in a system where a memory card might drive the /PROTECT STATUS bus line (pin 69), then you'll want to cut the trace on the back of the Bytesaver that feeds pin 69 (i.e., isolate pin 67 from pin 69). Unfortunately, we then lose the PROT LED "feature"!

                                                      Mike



                                                    • Systems Glitch
                                                      ... If there s no response to /PHANTOM, just generate it offboard. I did this to provide Power-on-Jump for a turnkey system in which neither the CPU nor the
                                                      Message 26 of 28 , Jul 29, 2014
                                                        > Until you posted the pictures, I was thinking "Bytesaver II' this whole time (probably because that's what I have!). The original Bytesaver that you have does NOT respond to /PHANTOM in, so adding a /PHANTOM out mod is actually even simpler.

                                                        If there's no response to /PHANTOM, just generate it offboard. I did this to provide Power-on-Jump for a turnkey system in which neither the CPU nor the ROM board provided POJ:

                                                        http://glitchwrks.com/2013/04/17/Power-On-Jump/

                                                        Then you don't have to modify your Bytesaver, and you'll eventually find other functions you'll want to place on the empty space left on the card!

                                                        Thanks,
                                                        Jonathan
                                                      • tkaragiris
                                                        Jonathan, Yes the CCS64k has four jumpers with three settings on each jumper, block enable, block select and if you remove the jumper it disables the block.
                                                        Message 27 of 28 , Jul 29, 2014
                                                          Jonathan,

                                                          Yes the CCS64k has four jumpers with three settings on each jumper, block enable, block select and if you remove the jumper it disables the block.  So I just disabled block 4 for now, it reduces the card to 48k, but that's fine.  I prefer to leave the Bytesaver in the machine as it has 8k Basic and the general purpose rom monitor that I use.
                                                        • tkaragiris
                                                          Mike, Yes, it s the first Bytesaver, I don t recall reading anything about the phantom line in the manual for my version of the card. The PROT led works just
                                                          Message 28 of 28 , Jul 29, 2014
                                                            Mike,

                                                            Yes, it's the first Bytesaver, I don't recall reading anything about the phantom line in the manual for my version of the card.  The PROT led works just like you describe, I've noticed this in the past.  And the power switch is the same whenever it's on the PROT led is off and vice-versa.

                                                            I most likely won't t use the Bytesaver for programming, I've had mixed results with programming 2708's with my card, I've had some success with 1k writes but not 7k.  This is the main reason I created those socket adapters to use the more modern 2716/2816 roms.  It's much easier now to program those roms outside of the Altair and then just use the adapters.

                                                            I removed the CCS64k yesterday and disabled bank 4 (topmost 16k) and I also noticed that the phantom jumper was disabled so I've now enabled the phantom in.  The jumper mod sounds very easy, just the sort of mod I like.  I'll take note of the issue with programming, I may try and use it for programming at some stage in the future but most likely not.  Good to know that all I need to do is disable bank 4 anyway.  The Bytesaver card won't be used in any other machine, so no problems there.

                                                            Appreciate the great info.  I'm glad I've got the memory configured better now without any risk of problems.  8k Basic is working great when transferred from the Bytesaver, I can load it instantly from power-up with a single command from the terminal, you've got to love that!

                                                            Thanks,
                                                            Theo

                                                          Your message has been successfully submitted and would be delivered to recipients shortly.