Re: S/23 machine update card
> On Aug 19, 2019, at 9:35 AM, Dennis Boone wrote: > >> The uCode in the S/23 is 8085 assembly code that is contained within >> the ROMs. The ROMs have the ability to be patched and the card >> you’re referencing is used to hold those updates. So without that >> card you’re not able to apply any ROM updates (which are loaded each >> boot). > > Ah, ok, that makes sense. It's only 16k of RAM. > >> It’s been long enough that I don’t recall what (if any) updates there >> are and when (and from what) they’re loaded. > > When the machine powers up, it pre-enters a command (PROC START? PROC > INIT? Brane faid.) which could presumably load firmware from diskette. > There aren't a lot of other options. They could be loaded from fixed > disk if you had one, but they'd have to get there somehow. Yea, that’s part of setting up the fixed disk. I was working on other projects (mainly the PC) at that point. > >> The system architecture allows for *much* more than the 64KB normally >> accessible by the 8085 CPU. The memory is bank switched. There is a >> fixed ROM and fix RAM portion of the address space and a bank >> switched ROM and RAM portion of the address space. 16KB of fixed >> (for ROM/RAM) sticks in my head for some reason. I don’t recall the >> granularity of the bank switched areas. > > Right, the memory map for all of that is in the service manuals. The > pageable sections each have 16 possible pages, and footnotes indicate > that two ROM and one RAM (think I have that right way round) pages are > not used. A total of 32k of address space for each of ROM and RAM, so > it would make sense that the pages are 16k, and that the fixed portions > are 16k also. > > What's not there is how the RAM on the card is paged in. The base RAM > card and the feature RAM card are mentioned, but I don't believe the > details of their mapping is described. I never actually used a version with actual ROMs (except for the one I have sitting here in my shop). All development was done with special RAM cards in place of the ROM. Made development *much* easier. However, development was not without its pain. When I started, a full build of the base software (e.g. full ROM image) took a week (yep, 7 days). So we would carry around “patches”. Both “blessed” patches and our own individual test patches. Getting those into the “official” build cleanly usually resulted in 2 or 3 attempts because how you needed to develop a patch was different than actually putting in the change in built source. So when a new build came out, tests would be run and additional patches applied. It was a real pain. We were jumping up and down for joy when the build was moved to the mainframe and we would get builds back in ~24 hours! > >> The patching was accomplished by having each major or critical >> function in the ROM be dispatched through a call table (that is >> placed in RAM at boot and can be “patched” to point to a different >> function). It was *more* than just the ROM address as it also >> contained the bank # of the ROM as well since (with few exceptions) >> all calls were “long calls”. > > Thanks for the enlightenment! Were you involved in the development of > these machines? Yes, it was my first job out of college. I wrote about 20% of the ROM code: floating point code…which because it was a “business” machine was all done in BCD formatting code (anything that is done via print and print using). I don’t recall if I did anything on the “input” side. unwinding expressions when you do a “list”. The source is always thrown away and just the bytecode is retained so the source needs to be “recreated”. a bunch of other stuff that I can’t recall now. > > Presumably there's an I/O to be done to the mapping hardware as part of > a "long call”? That is correct. TTFN - Guy
Re: S/23 machine update card
> The uCode in the S/23 is 8085 assembly code that is contained within > the ROMs. The ROMs have the ability to be patched and the card > you’re referencing is used to hold those updates. So without that > card you’re not able to apply any ROM updates (which are loaded each > boot). Ah, ok, that makes sense. It's only 16k of RAM. > It’s been long enough that I don’t recall what (if any) updates there > are and when (and from what) they’re loaded. When the machine powers up, it pre-enters a command (PROC START? PROC INIT? Brane faid.) which could presumably load firmware from diskette. There aren't a lot of other options. They could be loaded from fixed disk if you had one, but they'd have to get there somehow. > The system architecture allows for *much* more than the 64KB normally > accessible by the 8085 CPU. The memory is bank switched. There is a > fixed ROM and fix RAM portion of the address space and a bank > switched ROM and RAM portion of the address space. 16KB of fixed > (for ROM/RAM) sticks in my head for some reason. I don’t recall the > granularity of the bank switched areas. Right, the memory map for all of that is in the service manuals. The pageable sections each have 16 possible pages, and footnotes indicate that two ROM and one RAM (think I have that right way round) pages are not used. A total of 32k of address space for each of ROM and RAM, so it would make sense that the pages are 16k, and that the fixed portions are 16k also. What's not there is how the RAM on the card is paged in. The base RAM card and the feature RAM card are mentioned, but I don't believe the details of their mapping is described. > The patching was accomplished by having each major or critical > function in the ROM be dispatched through a call table (that is > placed in RAM at boot and can be “patched” to point to a different > function). It was *more* than just the ROM address as it also > contained the bank # of the ROM as well since (with few exceptions) > all calls were “long calls”. Thanks for the enlightenment! Were you involved in the development of these machines? Presumably there's an I/O to be done to the mapping hardware as part of a "long call"? Look at me calling it RAM instead of R/W storage, haha. :) De
Re: S/23 machine update card
The uCode in the S/23 is 8085 assembly code that is contained within the ROMs. The ROMs have the ability to be patched and the card you’re referencing is used to hold those updates. So without that card you’re not able to apply any ROM updates (which are loaded each boot). It’s been long enough that I don’t recall what (if any) updates there are and when (and from what) they’re loaded. The system architecture allows for *much* more than the 64KB normally accessible by the 8085 CPU. The memory is bank switched. There is a fixed ROM and fix RAM portion of the address space and a bank switched ROM and RAM portion of the address space. 16KB of fixed (for ROM/RAM) sticks in my head for some reason. I don’t recall the granularity of the bank switched areas. There was a lot of confusion when the S/23 came out about what the ROM/RAM specifications (192KB of ROM, 128KB of RAM) because an 8085 could only address 64KB. ;-) The patching was accomplished by having each major or critical function in the ROM be dispatched through a call table (that is placed in RAM at boot and can be “patched” to point to a different function). It was *more* than just the ROM address as it also contained the bank # of the ROM as well since (with few exceptions) all calls were “long calls”. TTFN - Guy > On Aug 18, 2019, at 6:11 PM, Jon Elson via cctalk > wrote: > > > On 08/18/2019 06:38 PM, Dennis Boone via cctalk wrote: >> Folks, >> >> I've determined that the piece of my S/23 that's causing the power >> supply to blow its 12V fuse is the machine update card. The manual says >> this provides additional R/W storage for microprogram updates. That >> sounds like something that wouldn't be necessary for normal operation. >> >> > Not knowing anything about this system, but you might check the card for a > bad Tantalum capacitor. > > Jon
Re: S/23 machine update card
On 08/18/2019 06:38 PM, Dennis Boone via cctalk wrote: Folks, I've determined that the piece of my S/23 that's causing the power supply to blow its 12V fuse is the machine update card. The manual says this provides additional R/W storage for microprogram updates. That sounds like something that wouldn't be necessary for normal operation. Not knowing anything about this system, but you might check the card for a bad Tantalum capacitor. Jon
S/23 machine update card
Folks, I've determined that the piece of my S/23 that's causing the power supply to blow its 12V fuse is the machine update card. The manual says this provides additional R/W storage for microprogram updates. That sounds like something that wouldn't be necessary for normal operation. Questions: 1. Can anyone confirm that I'm not losing anything by just pulling this? 2. Anyone have a cross ref for the IBM house numbers on these chips? 3. Anyone have a spare card they'd part with? 4. As long as I'm dreaming, anyone have a set of BRADS floppies or images? Machine update card photo: https://sysovl.info/pages/galleries/ibm/s23guts/s23guts13.jpg Interestingly, the underlying PCB for this seems exactly the same as the one for the word processing feature card. Many thanks, De
