Re: RS2030 MIPS workstation
On Tue, 2 Jul 2019, Patrick Mackinlay via cctalk wrote: > For the MIPS Rx3230 systems, which use an M48T02, the mac address should > be in the first 6 bytes of NVRAM. You can read/write the NVRAM through > the boot monitor using the “g” (get) and “p” (put) commands. You also > need to provide the “-b” argument to specify byte width, and the > relevant address. The NVRAM is mapped at 0x1d00-0x1d001fff in the > physical address space, but must also set the high bit to access it > through kseg0. Each 32-bit word in that range corresponds to a single > byte in the NVRAM, so the resulting commands will be something like: > > > * g -b 0x9d03 (read first byte of NVRAM) > * g -b 0x9d07 (read second byte of NVRAM) > * ... > > Or conversely: > > > * p -b 0x9d03 0xff (write 0xff to first byte of NVRAM) You probably want to use KSEG1 instead to access an MMIO resource, such as an NVRAM chip, especially with actual hardware and given that the chip is not linearly mapped in the address space in particular, or otherwise rubbish will be transferred through unused byte lanes as cache lines are read or written. With MAME it will of course depend on how accurate it is in reproducing the cache, although as a good measure I think correct access addresses ought to be always used. So: * g -b 0xbd03 (read first byte of NVRAM) * g -b 0xbd07 (read second byte of NVRAM) and: * p -b 0xbd03 0xff (write 0xff to first byte of NVRAM) respectively. Maciej
Re: Current MANX location
This? http://manx-docs.org/ On Mon, Aug 19, 2019, 12:05 PM Noel Chiappa via cctalk < cctalk@classiccmp.org> wrote: > Wasn't MANX supposed to be coming back up after moving? Did that never > happen? > >Noel >
Re: Tape History - Freeman Reports
> On Aug 19, 2019, at 12:11 PM, Tom Gardner via cctalk > wrote: > > I'm sure some of us all remember Freeman Reports as the chronical of the > tape industry well into this century. Ray Freeman and his partner and > successor Bob Abraham published these reports from at least 1983 until 2007 > but with Bob's death in 2007 the reports and backup files apparently wound > up in a dumpster. But Ray, Bob and Jim Porter did exchange copies of their > reports so thanks to Jim the Computer History Museum has almost all of the > Freeman Reports in their permanent collection. I’ve been working with tapes since around ’88, and this is the first I’ve heard of these. Are any of these available online? Zane
Tape History - Freeman Reports
Hi I'm sure some of us all remember Freeman Reports as the chronical of the tape industry well into this century. Ray Freeman and his partner and successor Bob Abraham published these reports from at least 1983 until 2007 but with Bob's death in 2007 the reports and backup files apparently wound up in a dumpster. But Ray, Bob and Jim Porter did exchange copies of their reports so thanks to Jim the Computer History Museum has almost all of the Freeman Reports in their permanent collection. There appear to be a few copies missing from the collection. A complete list of what the museum has and what maybe missing is posted at http://mrxhist.org/tom94022/FreemanRpt.pdf. In summary what may be missing are: Computer tape outlook - . half-inch products: 1994, 1985, 1990 & 1992 Computer tape outlook - . cassette/cartridge: 1984 & 1985 Computer tape outlook - all tape: 1997-2000 (as the market consolidated towards LTO so did the reports J Optical data storage outlook: 1985, 1988 & 1998 Mass storage/Library storage outlook: 1992, 1993, 1997 & 2000 So before they all get trashed please look and see if you happen to have any of the possibly missing editions in your garage, attic or any other repository. Contact me off line if you can help. Tom
Current MANX location
Wasn't MANX supposed to be coming back up after moving? Did that never happen? Noel
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
