S/23 machine update card

[Guy Sotomayor Jr]

> 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
>> 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