You are not logged in.

#1 2015-09-10 22:52:03

apm
Member
Registered: 2015-09-10
Posts: 19

SE PDS card ROMs

Question for the compact Mac gurus here: does anyone know how a PDS expansion card (Mac SE in this instance) makes itself known to the system on boot?

I picked up an SE with a Radius TPD card, mostly interested in the card itself. Unfortunately, with the card inserted, the machine hangs when the cursor first appears in the corner of the screen. Without the card (but still with the Radius Magicbus adapter), it boots fine.

The card has a pair of socketed EPROMs, marked "MPD/SE V4.4, 256K". Just out of curiosity, I removed the ROMs and the machine once again boots, though obviously I wouldn't expect any operation from the card.

My assumption is that these ROMs must be mapped somewhere in the unused SE address space, but I don't know where, nor how the system is made aware of their presence. "Designing Cards and Drivers for the Macintosh Family" seems to partially confirm this but leaves the details vague. I'm wondering whether the pattern I'm seeing is the Mac ROM completing its memory check, jumping to the Radius ROM code and never coming back.

I suppose it could be just about anything wrong with the card. I don't suppose anyone has ROM images of one of these boards somewhere?

Offline

#2 2015-09-11 00:05:23

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

That's an interesting question.  AFAIK, the SE doesn't have the Slot Manager, and its address space is not laid out in a normal pseudo-slot oriented manner, so I don't think a normal declaration ROM would be picked up, parsed, and executed that way.
I don't think I've encountered an SE card that worked without drivers, all the ones I've seen have just put the hardware into the address space, and then you needed to boot and run software to be able to use it.  But it is Radius, so all bets are off.

My first suspicion is there could be something wrong with the ROMs themselves, causing errors on the bus.  The fact that the cursor is drawn would kind of indicate at least some basic functioning though.

The Mac ROMs would also look for and execute if present, diagnostic code at certain addresses.  This was never intended for use by 3rd parties, but Radius was always one to use little tricks like that for market advantage.  It's possible they are mapping themselves to one of those addresses and the code is being run that way.

Do you have a way to read the EPROMs off the card?  Maybe a ROM programmer of some type?  If the EPROMs could be read successfully, that'd at least indicate they should be OK.  And the ROM contents might provide some insight into what it is doing.

Offline

#3 2015-09-11 22:26:54

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

Yep, I have access to an EPROM programmer. Despite being 27C256 chips, the ROMs turn out to be quite short, just 560 bytes when they are interleaved together. They do read correctly: in there we find things like "(C)1991 Radius" and "Radius Multi-Page Display"

The ROMs begin with 0x55AAAA55. A bit of Googling brings up a very useful post from Arbee on mac68k.info about these cards. I'll take the liberty of quoting a large part of it here:

"The SE ROM checks for 0x55AAAA55 at 0xF80000 very early in boot (before the memory test or low memory globals are set up). If present, it JMPs through the vector at 0xF80004. You return by jumping to 0x401C04. The Radius ROM uses this primarily for what a NuBus video card would do during PrimaryInit (programming their CRTC to something valid and clearing the VRAM).

Later on, around when NuBus systems call SecondaryInit in video cards (just before DrawBeepScreen, for you experienced ROM spelunkers), it does the same thing through a signature word at 0xF80080 (also 0x55AAAA55) and a jump address at 0xF80084. It still does a JMP to this routine, but this time it's more polite and passes the return address in A1. The Radius card uses this hook to actually patch out QuickDraw to use their display and stuff. Disassembly of their ROM (which normally maps and runs at 0xC00000, with a mirror up in the 0xF800xx range) would likely be enlightening by someone a bit more familiar with the OS internals than myself."

This squares with what I see in the ROM. There is indeed another 0x55AAAA55 signature at 0x80 (and also at 0x88). I will see if I can disassemble them and learn anything. Happy also to send the binaries to anyone who's interested.

Based on the fact that I get to a cursor, I would expect the first ROM jump is successful, but the second one dies somewhere. It may be that it's not the ROM but something else on the card (their custom IC?) that is at fault. Too bad, but further testing needed before I give up on it.

Offline

#4 2015-09-11 22:52:39

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

I'd be interested in a copy of the images.  Maybe I can figure out what it's doing.  Shoot me an email.

Offline

#5 2015-09-11 23:29:58

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

Email sent. And some disassembly done. It looks like there are three distinct blocks of code, the first starting 0x84 into the image. Among other things, it appears to have a loop that I would guess is initialising VRAM:

E6     72FF                      MoveQ.L   #-$1, D1
E8     41F9 00C4 0000            Lea.L     ($C40000), A0
EE     303C 7C07                 Move      #$7C07, D0
F2     20C1           L2:        Move.L    D1, (A0)+
F4     51C8 FFFC                 DBF       D0, L2

That part terminates by jumping to either A1 or 0x401C04. I wonder what the significance of the magic number "276" in ROM is?

104    0C79 0276 0040            CmpI      #$276, ($400008)
       0008
10C    6702                      BEQ.B     L4
10E    4ED1           L3:        Jmp       (A1)
110    4EF9 0040 1C04 L4:        Jmp       ($401C04)

I have to spend some more time figuring out what the second and third blocks do, but the last one appears to be full of JSR calls to places in system ROM (0x400262, 0x400396, 0x4006DA, ..., at least a dozen in total). What's the best way to look up what lives at these addresses?

The other unresolved question is where in the boot sequence each of these bits runs. Could bad VRAM lock the system?

Offline

#6 2015-09-11 23:57:06

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

Got it, thanks!  I'll try to dive into this a little later this evening.  The minivmac folk have some commented ROM disassembly that might be interesting.
The ROM starts at 0x400000, so all the ROM addresses will be relative to that.
0x400008 should be some information about the ROM, like machine type and ROM version number, so it's probably doing some sanity checking to make sure it's on the machine it expects.

Offline

#7 2015-09-11 23:58:21

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

The other interesting thing might be to try to step through this in MESS, since arbee seems to know about it, it's probably emulated.  I can try doing that, since MESS is a bit involved to get setup and working, and I've already got it going.

Offline

#8 2015-09-12 02:59:57

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

Out of curiosity, do you have a display connected to the radius card?  It looks like the ROM is disabling (well, just abandoning) the internal video in favor of the radius card.

Offline

#9 2015-09-12 03:55:24

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

The SE ROM looks at $F80000, if it's $55AAAA55, it loads the value at $F80004 into A0 and jumps to it.  At $F80004 is $C00094.  The TPD card maps its ROM to $F80000 and $C00000.  So the first jump is to offset $94 of the ROM, which is:

6000 0006 bra.w *+$8
6000 007C bra.w *+$7E   ; skipped (for now)
4A79 00C6 tst ($C60000) ; bra to here, $C60000 is 0

So that's the entry point.  It looks like it does some initialization, and the loop at your label L2 offset $f2 initializes the screen to black (all 1's).

After initialization, it looks at $400008, which contains $0276 on my ROM, indicating machine type 2, rom version $76.  Interestingly, machine type 2 here matches the machine type reported in the *APPLE* message of the diagnostic mode that I just played with earlier today.
Because $400008 contains $0276, the jmp (a1) is skipped, and it moves on to jmp ($401c04), which looks like the return point.

The next time it gets called, it jumps to $C00098, which is the bra.w *+$7E that got skipped above.  When it jumps here, the return point is left in A1.
So it jumps to $C00116, which is right after the return point of the earlier initialization.  It again does a $400008 compare to $276.

The code around offset $128 into the pds card's ROM is setting a bunch of low memory global variables related to sound configuration.  Then in the big series of jmps, it jumps to:
InitGlobalVars
InitXVectTables
InitDispatcher
GetPRAM
InitMemMgr
SetUpSysAppZone
InitSwitcherTable
InitRsrcMgr
InitTimerMgr
InitADBvars
reenables interrupts
InitADB
InitVidGlobals
sets up to overwrite the screen h and v rows low memory global variable
checks if we're doing a warm start at $cfc low memory global (we're not)
executes the ram test
Then calls CompBootStack to compute where the boot stack should be based on available memory, puts that into the stack pointer, subtracts $2000, and sets up the system heap.  Calls more ROM initialization routines:
InitQueue
InitSCSIMgr
InitIOMgr
InitCrsrMgr
Then it's loading $4000144 into A1, which is basically the place in ROM that would continue off the boot sequence after all the initialization that we just did, and then pushing that on the stack.
Then eventually RTS'.

So it looks like it abandons the internal display, and never really "returns" to the ROM, instead it just jumps into a later part of the boot sequence.

Offline

#10 2015-09-12 04:04:18

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

I'm not too familiar with the card, but it looks like it supports the mac plus as well.  That's why the $276 checks earlier.  At the very end, before it decides whether to rts or jmp ($40063E), it compares $400008 to $75, which would match a mac plus.

Offline

#11 2015-09-12 17:15:34

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

Interesting info, thanks. I don't have a display (I'm sure it's long gone) but I had been hoping to extract the sync and adapt the signal for a modern multi-sync monitor. It does look like the machine is locked though: no response to a floppy in the drive, nor any sign of life on a bootable image via Floppy Emu.

So the only info I have to go on is that it gets past the system memory test (which I think is the first pattern displayed on the screen for several seconds) and to the point it puts the cursor in the upper left corner, but never to the point that I can move the mouse. The question is which of those Radius ROM routines will have run by then. Also, I suppose, where in the system ROM the cursor first gets displayed.

By coincidence I also have a Plus with a Radius FPD (and 020 upgrade). That one boots with no external display attached-- in fact it puts a little Radius image in the lower left of the internal monitor on startup. On the other hand, the full page display has a 9-pin connector which probably includes a sense pin for whether the monitor is attached, whereas the two-page display uses a single BNC connector. I may see if I can dump the ROMs on that adapter card and learn anything useful.

Offline

#12 2015-09-12 18:52:27

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

If you have a sync on green vga display, you can probably hook up that bnc to it.  The picture will be green & black rather than white and black, but hey.  Although it does sound like a hang.  I think the internal display is supposed to be black once the other display takes over (that's the last loop of writing -1's), and no floppy activity.
The cursor is updated by the 60hz vertical blanking interrupt, so it kind of sounds like interrupts are disabled.  That 60hz is generated by a VIA input causing the interrupt.

Offline

#13 2015-09-12 23:07:49

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

Another interesting data point. When I hit the interrupt switch, I get the usual Sad Mac, but it still draws the cursor (plus a little bit of checkerboard pattern remaining in the upper left). Turns out that if move the mouse and then hit the interrupt switch, the cursor on the Sad Mac screen will have moved from the upper left corner.

That would seem to support the vertical blanking interrupt theory. ADB must be alive even when nothing changes on screen. On the other hand, it's not just a screen issue since the boot sequence doesn't continue.

I checked the voltages-- +5V is normal (5.05V), -12V is a little low (-11.7V), +12V is a bit high (12.7V) but I doubt any of those have anything to do with this.

Offline

#14 2015-09-13 00:42:34

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

I'm starting to find my way around these ROMs. The Radius ROM all seems to work as you say, though I'm not sure about this:

InitVidGlobals
sets up to overwrite the screen h and v rows low memory global variable

The relevant part in my disassembly listing reads like this:

1A6    4EB9 0040 05CA            Jsr       ($4005CA)
1AC    204F                      MoveA.L   A7, A0
1AE    2278 010C                 MoveA.L   ($10C), A1
1B2    2C78 0108                 MoveA.L   ($108), A6

The first line is InitVidGlobals. $10C and $108 are BufPtr and MemTop, respectively, but it's only reading these values. In fact, this whole block of code is identical in function to the SE ROM (e.g. compare these lines to SE ROM at 0x106). So far as I can tell, the only things that are different about this whole block is that it writes a few values around 0x770000 at the beginning (control registers for the board perhaps?) and clears the VRAM again at the end before returning.

Since the grey screen and cursor come up, it must have made it through DrawBeepScreen. At that point it writes a magic number for warm start and then goes to BootMe, inside of which it must be getting stuck. But none of the above seems to explain the lack of cursor movement....

Offline

#15 2015-09-13 01:25:28

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

Yeah, sorry, I got $108 and $10C confused with screen v and h rows, and the looping at the end, I was thinking was writing to the internal video buffer, but it's writing to theirs.  Although, I'm wondering if that's a failure condition.  I'm not sure why it would be blanking the card's buffer if it was just initialized and theoretically in use.
The other thing I noticed is several moves to the status register.
move #$2000 should put it into supervisor mode, but all interrupts disabled, including the VIA interrupt.
move #$2300 should enable interrupt levels 3 and lower.  The VBL interrupt is at level 1 and NMI (programmer's switch) is at level 7.  So VBL should be running but NMI should be disabled when that code gets hit.  That's not a whole lot of help, because the move #$2300 is right towards the end.
Out of curiosity, how much RAM is in this machine, and is it an 800k or FDHD system ROM?

Offline

#16 2015-09-13 17:24:01

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

It's an FDHD machine. From the look of it, it was originally an 800k two floppy machine, which has had the ROMs and SWIM upgraded, and one of the two floppy drives has been replaced with a 1.4MB drive. When I got it, it had 2.5MB of RAM but I upgraded it to 4MB. Same response before and after.

You're right that the status register code is strange. I think it actually works the other way around: $2300 will mean suppressing interrupts of priority 3 and below. $2000 means all interrupts on, $2700 is all interrupts off. The schematics I can find for the SE are hard to read, but so far as I can tell from other Macs, IPL0 (priority 1) is for the VIA including VBL, IPL1 (priority 2) is for serial and IPL2 (priority 4) is for NMI. I can't tell whether 8 interrupt levels are actually used on the Mac. Anyone able to comment on that?

Given that, it's strange that the Radius code would return with SR set to $2300 (i.e. all interrupts except NMI blocked). I don't spot anywhere else in the SE ROM that they would come back on after that. If they are disabled, it may also explain the boot freeze as it appears the Ticks global is used in some of the boot routines. That appears to be updated by the VBL interrupt.

The older version ROMs you sent me are quite a bit longer than the ones I have, and I don't find similar code involving SR. When I get a chance (it may be a while), I'll see if I can burn those to some chips and test it out.

Offline

#17 2015-09-13 20:26:30

jt
Member
From: Bermuda Triangle, NC USA
Registered: 2014-05-21
Posts: 1,408

Re: SE PDS card ROMs

I've skimmed over this ROM spelunking session and know you're considering horizontal and vertical blanking, but are you also considering left and right porch timings?

Offline

#18 2015-09-13 23:32:41

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

Interesting. I haven't looked into timings specifically, but I think the issue here is whether the VBL interrupt is happening at all (and if not, why not).

Some more spelunking: $396 (mInitXVectTables) confirms that there are only two interrupt levels used in the SE, aside from NMI (interrupt switch). Level 1 is for the VIA, which includes VBL and a one-second interrupt. Level 2 is for serial. Inside Macintosh talks about mouse interrupts on level 2, but I think that's pre-ADB only.

The vertical blanking interrupt code (mVBLInt_VIA, $2BE4) starts by incrementing Ticks, then clearing the interrupt on the VIA itself. Then it reenables interrupts (sets SR to #$2000) and appears to do some sort of re-entry check to see if there is already VBL interrupt code running. If so, it returns. I guess there is a facility to add routines to run at VBL time, so this would prevent multiple copies of those routines from running at the same time. The VBL interrupt also appears to update the cursor (JCrsrTask), though I can't tell if that means update the position of the cursor, or draw it on screen.

Given the observation (stuck screen but cursor will have moved on NMI), the options seem to be: VBL doesn't run because it's left masked by Radius ROM; VBL runs but gets stuck in some custom routine; VBL runs but doesn't update the screen; or some other higher-priority interrupt keeps triggering that preempts VBL. All three interrupt signals on the 68000 do connect to the Radius ASIC so I suppose the last theory is possible if there's something wrong with the hardware. I may check that on a scope in a couple days.

Offline

#19 2015-09-14 15:29:27

jt
Member
From: Bermuda Triangle, NC USA
Registered: 2014-05-21
Posts: 1,408

Re: SE PDS card ROMs

bbraun wrote:

But it is Radius, so all bets are off  .  .  .

.  .  .  Mac ROMs would also look for and execute if present, diagnostic code at certain addresses.  This was never intended for use by 3rd parties, but Radius was always one to use little tricks like that for market advantage.  It's possible they are mapping themselves to one of those addresses and the code is being run that way.

Radius was able to do tricks like that because the founders were the most brilliant stars in the firmament of Macintosh development gone renegade.

I don't do software/firmware archaeology, but I'm an SE era peripherals guy and radius fanatic, so I'm dialing this back to basics of troubleshooting:

IIRC, the BNC interfaced FPD and TPD were first gen B&W DTP Display solutions. If the ROMs bb sent you are for the SE/800, definitely pull that FDHD ROM (SWIM too?) upgraded puppy back to original spec before worrying about anything else. Always wanted the first gen FPD at the time, but never had one then or since (DAMMIT) but I've got a thick folder of FAXback documentation. Unfortunately, I never wanted the TPD, so:

From what I just reviewed, SE ROM trickery for the the B&W FPD/TPD (likely the BNC models) probably expired with the change in ROM and definitely with anything over System 7.1. (according to the recommendations in my docs anyway)

Info from article(?) about TPD released fourth quarter 1987
Refresh Rate: 72 Hz

Aha! Mainly Neat Stuff does have the TPD Q&A I'm missing: http://www.vintagemacworld.com/radius/tpd04360437.html

Last edited by jt (2015-09-14 15:33:58)

Offline

#20 2015-09-14 22:53:38

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

I do have an SE 800k ROM image, but I need to order some chips to burn it onto. Will test this next week. bb's image was actually for an older version of the Radius ROM (4.1 versus my 4.4), which I am also interested to try.

I put the CPU interrupt lines on the scope. No unusual activity on IPL1/ (i.e. priority 2, from the SCC). With the card inserted, IPL0/ (i.e. priority 1, from the VIA) is held low for most of the initial startup phase except for a brief burst at the beginning. Shortly before the cursor first appears, it runs normal vertical blanking interrupts every 60.1Hz for about 310ms. Once the cursor appears, IPL0/ stays low forever (i.e. gets stuck, interrupt service routine not clearing it). This happens exactly on a VBL boundary, so it is likely I'm seeing a VBL interrupt that the system fails to clear, rather than something else being generated by the card.

Without the card, the startup sequence begins the same way (IPL0/ low, VBLs begin shortly before cursor screen) but the VBL pattern continues indefinitely: a brief pulse low at 60.1Hz, otherwise high. The machine goes to the usual question-mark disk.

I also scoped the BNC output, though I don't have a suitable monitor for it yet. The signal looks fine. I measure 65kHz horizontal refresh, 70.9Hz vertical refresh but the latter is hard to pick out amidst the high-frequency stuff, so 72Hz may well be right.

Back to the spelunking, the 300ms of normal VBL interrupts before getting stuck sure seems to match the Radius ROM, where writing #$2000 to SR midway through the initialisation routine enables interrupts, and then writing #$2300 near the end would disable the VBL interrupt. 300ms seems plausible for initialising things like ADB, SCSI etc.

It really seems like the disabling of interrupts at the end of the Radius code is the problem. But I can't figure out why that code would ever have worked. The sequence doesn't really make sense, but at the same time I can't imagine ROM corruption could produce it. I also have to imagine this card worked for the original owner when it was installed. It's a bit of a puzzle.

Offline

#21 2015-09-22 23:05:46

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

Some progress (maybe, possibly). I burned a copy of bb's v4.1 ROMs and put them in the card. The machine boots now. However, that could either mean that the card is now initialising properly, or that it isn't finding the ROM at all.

I need the Radius drivers to test it ("Classic / SE / Plus Display CDEV"). However, the Mac Driver Museum links are long dead, and I don't think the newer versions of RadiusWare are what I want -- at least, they don't come up with anything on 6.0.8. Does anyone have a copy of these old drivers floating around?

Offline

#22 2015-09-23 00:25:06

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

One sanity check on the ROMs would be to enter microbug (hit the programmers switch/NMI button on the side), and peek at some of the ROM's locations in the address space.  In microbug, you can do "DM F80000" and that should display memory at that location, and it should be 55AAAA55.  That should make sure the ROMs are present at the right location, and are installed in the right order.  Otherwise they'd be AA5555AA I guess.

Offline

#23 2015-09-23 00:36:02

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

Good thought. Something's not right there as it just shows BFBF FFFF repeatedly through that whole space. Is it possible these locations get remapped after boot?

I'll try a few other things tomorrow to see what I find. Meanwhile, if anyone has drivers for these boards, send me a PM.

Offline

#24 2015-09-23 00:39:19

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: SE PDS card ROMs

I don't think it gets remapped, since the SE's logic there is pretty limited.

Offline

#25 2015-09-23 17:48:33

apm
Member
Registered: 2015-09-10
Posts: 19

Re: SE PDS card ROMs

Right, fixed that. I was using 28C256 EEPROMs in place of the old 27C256 chips. I lazily assumed that they would have the same pinout since they are the same capacity in the same package, but turns out two of the pins are swapped. After running a couple wires now I get the "Radius Display Systems" badge in the lower-left corner of the screen ("Copyright 1989 Radius Inc / Version 4.1C"). It stays up less than a second before it goes to the floppy icon, but that's the first sign of life I've seen from this card.

No obvious sign of it being aware of the display once the system has booted. I assume I'll need the drivers for that.

Offline

Board footer

About ThinkClassic

ThinkClassic specialises in the maintenance, repair, restoration and modification of Vintage Apple and Macintosh computers. Ask questions and find answers about classic Apple desktops, laptops, accessories and peripherals.