• Please review our updated Terms and Rules here

SOL-20 Memory Management Dilemma

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
4,648
Location
Australia
I wanted to try out the Compupro Spectrum board in my Sol. After trying the Matrox ALT-512/256 and the Dazzler I found that BASIC was an invaluable tool, to learn the card's registers, before moving to an 8080 assembly language routine.

I run MBASIC in CP/M and it is a big program, using up half the 48k memory.

I have been running the 64k SCP110 static RAM card, it had an address decoder for disabling applications, but its logic its used up to disable the card above BFFFH. This card though can inhibit 4k blocks of memory. I looked at the Compupro RAM17, but that one has the facility to inhibit the memory for 16k blocks, not leaving enough spare RAM.

To run the Spectrum card, MBASIC and CP/M and still have some area left for transient programs I needed to have the SCP110 card inhibit above 48K (as usual) but also over a 8k range, say from 6000H to 7FFFH, because this is the space or a block required for the Spectrum's RAM, which when the spectrum is not activated, just acts as ordinary system RAM.

I have attached a "memory map" of my SOL. The thing is that I didn't want to modify the SCP110 card or the RAM17 card hardware as they are valuable (to me at least), but I noticed that if I unplugged the jumper on the output of the address decoder on the SCP110 card, I could plug it onto a custom pcb which would deal with the required deactivation of the SCP card over an 8k address range and then I could have no modification to the actual SCP110 card.

I think there is also a way to Phantom the memory out using that line in the SOL, but I struggle with the software, say to integrate that into test programs and a hardware solution seemed suitable, but is there another more simple/easy way to do it than at the hardware level ?

(I didn't have a 74LS640 in my parts box, so I had to use the '642 with some pullups because its open collector)
 

Attachments

  • SCP2R.jpg
    SCP2R.jpg
    52.9 KB · Views: 23
  • SCP1R.jpg
    SCP1R.jpg
    95.4 KB · Views: 21
  • SCP3R.jpg
    SCP3R.jpg
    162 KB · Views: 21
Last edited:
What disk controller are you using in the Sol? Maybe you could run the Spectrum card in high RAM address like D000-EFFF depending on your disk controller. The North Star controllers can't be moved. A Micropolis controller is easily moved and CP/M does not even have to be patched.

Mike
 
What disk controller are you using in the Sol? Maybe you could run the Spectrum card in high RAM address like D000-EFFF depending on your disk controller. The North Star controllers can't be moved. A Micropolis controller is easily moved and CP/M does not even have to be patched.

Mike

I have the N* double density controller at E800.

At D000, where there was some space available I made a ROM card (using two Sol personality cards). On that I have a few useful programs where I can test memory, write to blocks of memory. That is also helpful in testing the graphic's cards so I need to keep that running.

I also have a program called MEMMAP, I got from a textbook which shows how much of the memory is used by CP/M. But when I filled the whole memory with all the same byte and ran CP/M, I found that CP/M actually used a little more memory in high memory than the MEMMAP program reported, that is how I figured out how much free memory I would have left over just below CP/M and in the gap to where the Spectrum card will be.
 
I'm not sure, are you trying to use software to activate phantom? I believe it is normally done by a hardware circuit. When the card that you want to control a portion of RAM spare that card pulls pin 67, phantom *, down. If the controlling card has a select signal for that chunk of RAM then that could be fed out to pin 67 with an open collector gate and disable the other board(s). Else, a lot of processing time would be eaten up testing memory addressing to see if the CPU is trying to access that range of RAM.

Perhaps you could make a small circuit on a prototyping S-100 board that could test RAM addressing and issue phantom to the bus if the requested address was within the lower and upper memory range and allow some other board that wasn't looking for phantom (disabled) to still control that RAM range. Would work if there was only one such need for phantom control in the system.
 
If you have a S100 extention card, you can hack a memory remapper to it. It wouldn't work well in the case. If you don't mind tacking wires to your memory board, you can use Kevlar tape to isolate the offending address pins from the bus and put your hack card on there ( not cuts needed ).
Dwight
 
I'm not sure, are you trying to use software to activate phantom? I believe it is normally done by a hardware circuit. When the card that you want to control a portion of RAM spare that card pulls pin 67, phantom *, down. If the controlling card has a select signal for that chunk of RAM then that could be fed out to pin 67 with an open collector gate and disable the other board(s). Else, a lot of processing time would be eaten up testing memory addressing to see if the CPU is trying to access that range of RAM.

Perhaps you could make a small circuit on a prototyping S-100 board that could test RAM addressing and issue phantom to the bus if the requested address was within the lower and upper memory range and allow some other board that wasn't looking for phantom (disabled) to still control that RAM range. Would work if there was only one such need for phantom control in the system.

Thanks, I was not exactly sure how the phantom system was supposed to work.

It is an interesting thing with the Spectrum card, because when its not activated for graphics activities, it is still active in the sense that its video RAM becomes general RAM filling the address range that the card occupies, so in a sense that solves one problem when it is fitted to the computer. The SCP-110 card though didn't have enough hardware on it to simultaneously knock it out over 48k and also create an 8k hole in the rest of its address space.

Still, at least what I made works, without having to cut any tracks etc, but it does require the extra card and in the case of the SOL-20 I always seem to be looking for extra card slots!
 
.... it turned out just by coincidence that this address decoder board I made will be useful when I install the Bytesaver II, to deactivate the SCP-110 memory card over the range when the Bytesaver will operate. (I'm still awaiting the Bytesaver to arrive in the post !)
 
I wanted to try out the Compupro Spectrum board in my Sol. After trying the Matrox ALT-512/256 and the Dazzler I found that BASIC was an invaluable tool, to learn the card's registers, before moving to an 8080 assembly language routine.

I run MBASIC in CP/M and it is a big program, using up half the 48k memory.

I have been running the 64k SCP110 static RAM card, it had an address decoder for disabling applications, but its logic its used up to disable the card above BFFFH. This card though can inhibit 4k blocks of memory. I looked at the Compupro RAM17, but that one has the facility to inhibit the memory for 16k blocks, not leaving enough spare RAM.

To run the Spectrum card, MBASIC and CP/M and still have some area left for transient programs I needed to have the SCP110 card inhibit above 48K (as usual) but also over a 8k range, say from 6000H to 7FFFH, because this is the space or a block required for the Spectrum's RAM, which when the spectrum is not activated, just acts as ordinary system RAM.

I have attached a "memory map" of my SOL. The thing is that I didn't want to modify the SCP110 card or the RAM17 card hardware as they are valuable (to me at least), but I noticed that if I unplugged the jumper on the output of the address decoder on the SCP110 card, I could plug it onto a custom pcb which would deal with the required deactivation of the SCP card over an 8k address range and then I could have no modification to the actual SCP110 card.

I think there is also a way to Phantom the memory out using that line in the SOL, but I struggle with the software, say to integrate that into test programs and a hardware solution seemed suitable, but is there another more simple/easy way to do it than at the hardware level ?

(I didn't have a 74LS640 in my parts box, so I had to use the '642 with some pullups because its open collector)

I was searching through some old threads and found this one of yours. I've been looking for a Sol memory map, and your attachment was perfect. It was very similar to one I'd seen before and it's a welcome addition to my new Sol notebook I've been putting together.
 
Back
Top