S/23 machine update card
Guy Sotomayor Jr
ggs at shiresoft.com
Mon Aug 19 11:57:41 CDT 2019
> On Aug 19, 2019, at 9:35 AM, Dennis Boone <drb at msu.edu> 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
> 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
More information about the cctalk