• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Lisa Error 45

RolandJuno

Active member
Hey all! A little over a month ago, I embarked on a project to build a new Lisa! For years, I've had a Lisa CPU card given to me by a friend (no idea of its status). Now with the availability of new reproduction motherboard and I/O cards, I've build up the missing cards (and sourced a new bare SunRem 2MB RAM card). I sourced all the parts and assembled it. (DosFox was already successful and has a working Lisa 2/5 from scratch.)

Much to my surprise, it eventually booted and gave an error during the startup test phase (along with two beeps, lo/hi). Error 45 is a "bus error" but I'm not certain how to begin to troubleshoot it. The error happens shortly after it begins the memory test so I'm assuming it's a RAM problem? [Link to video of startup]

Lisa Error 45.jpg

Anyone have ideas of how to proceed?

BTW, I'm using W27C512 in place of the 6309 for both the video and floppy PROMs (which seem to be working, given the picture I'm getting). I'm also using the COP421 EMU board.

BTW, you can see my progress on this Mastodon thread:
https://mastodon.social/@paulrickards/110895001422227651
 

stepleton

Well-known member
I've been monitoring your thread for a while :)
Any Lisa cloner I discover on Mastodon gets automatically followed. I liked the idea of the kb/power switch/etc. PCB you made.

The method you're undertaking of working backwards from the boot ROM source is the approach I would pursue, but I can offer no specific advice at the moment. Per your recent post, a memory error on a 128k boundary would lead me to be suspicious of the circuitry that handles addressing in addition to the RAM itself. Of course in the Lisa there's an entire MMU to debug...

I guess there's one other thing I would do, too. If you are handy with 68000 assembly, you can use Service Mode to key machine code into RAM and then execute it. This may help you troubleshoot with greater precision than you might be able to achieve by interpreting boot ROM complaints. If you're not handy with 68000 assembly, it might be easier than you think. http://www.easy68k.com/ is a great way to start experimenting with it --- it's a Windows program but it works fine under Wine if that helps.

To investigate whether memory at a particular address is working at all, you could also simply use Service Mode to put values into that location and then attempt to read them back.
 

RolandJuno

Active member
The method you're undertaking of working backwards from the boot ROM source is the approach I would pursue, but I can offer no specific advice at the moment. Per your recent post, a memory error on a 128k boundary would lead me to be suspicious of the circuitry that handles addressing in addition to the RAM itself. Of course in the Lisa there's an entire MMU to debug...
I'm able to access the service menu and using the display memory command 01FF00 with a length of 100 fine. As soon as I cross the boundary into 020000 (say, with display memory 01FF80 length 100), the machine abruptly reboots and beeps twice (lo/hi).

So this makes me wonder. Is there an issue with the RAM card or is the MMU pointing to memory out of bounds? Is there a way to dump the MMU table?
I guess there's one other thing I would do, too. If you are handy with 68000 assembly, you can use Service Mode to key machine code into RAM and then execute it. This may help you troubleshoot with greater precision than you might be able to achieve by interpreting boot ROM complaints. If you're not handy with 68000 assembly, it might be easier than you think. http://www.easy68k.com/ is a great way to start experimenting with it --- it's a Windows program but it works fine under Wine if that helps.
I'm afraid my 68k assembly isn't that great, but I'll take a look into it.

Thanks!
 

stepleton

Well-known member
Is there a way to dump the MMU table?
I think you will need to brush up on your 68000 assembly for that.

I can tell from your posts that you've already got your hands on the hardware reference manual (my favourite copy is this one, which may be newer than the one on Bitsavers; all my section and page citations will refer to this document). You will need to access the MMU in "Special I/O space", which is discussed in sections 1.4, 2.3-5, 4.3.4, and 4.4 among other places.

Special I/O space is one of the Lisa's three separate address spaces (the other two are RAM and regular I/O), and you get to it in one of two weird ways: you either disable the MMU and use the special "SETUP" addressing scheme that then applies, or you use the MMU to map a virtual memory address into a location into special I/O space where the MMU register you're interested in lives. In both settings, those MMU registers are spaced widely about special I/O space --- 128 kilobytes apart from each other, if I'm not mistaken.

This makes the second, mapping-based way a hassle because you'd need to (re)configure a virtual memory address for every MMU register you want to access, since an MMU segment can be no bigger than 128k (again if I'm not mistaken).

I was about to describe how to do either thing wholly "from scratch", but then I remembered that you can call a routine in the boot ROM to get data out of the MMU, one register pair at a time. See PDF page 35 of the boot ROM manual. This routine is probably only slightly less tricky than the fully DIY way :) . You will want to write an assembly language program that:
  • Puts $00020000 (128k) into 68000 register A5
  • Loops over MMU contexts c := 0 to 3:
    • Puts the special I/O address of the 0th MMU base register in A2 and the corresponding limit register in A3.
    • Puts c into D2
    • Loops over MMU register pairs p := 0 to 127:
      • Puts the address of the next bullet into A4 and jumps to $FE00A4 (the boot ROM routine)
      • Stores the value in D0 in a memory location you've set aside for the p'th MMU base register value of context c
      • Stores the value in D1 in a memory location you've set aside for the p'th MMU limit register value of context c
No problemo, eh? I think the special I/O address of the 0th MMU base register is $008008 and the address of the 0th MMU limit register is $008000. I derive this from the boot ROM source code and from PDF page 45 of the hardware manual.

(Confusingly, the diagram on PDF page 41 of the hardware manual would suggest addresses $010008 and $008000 respectively, but I wonder if this may be the special I/O addresses you use for the MMU-based "second way" method, when the MMU is enabled because the SETUP (aka START) bit (see PDF pages 43 and 62) is OFF. The $FE00A4 routine turns the SETUP bit ON, disabling the MMU.)

Anyway, once you run your program, then you can inspect the MMU contents that it saved to RAM.

But for all of that: the boot ROM also does a lot of its own MMU tests, and I think it would generate error 40 (EMMU in the boot ROM source code) if it encountered a problem that you are likely to discover by reading the MMU registers :)

(Spare footnote: the MMU-disabled address space is weird: if I'm (again) not mistaken, it interleaves 16K chunks of RAM and Special I/O space, with Special I/O space chunks alternating between MMU registers and repeated "copies" of the ROM. Would have to experiment or derive from the schematics to be certain...)
 
Last edited:

RolandJuno

Active member
Thanks so much for the guidance on debugging the MMU. I'll need to come up to speed on some 68K assembly. It's been years.

One thing to note: In the service menu, there's a Loop on Test option. On a working Lisa I'm assuming once you start a test, it keeps looping the same test over and over until you reset the machine. If this is true, the only test that fails is the RAM test (with error 45). Which means the MMU (and everything else) seems to pass.

Tomorrow I hope to gain access to working Lisa 2/5 at a museum where I'll try to do some board swaps with my own rig to determine where the problem lies. This should help me narrow my focus a bit.

Another interesting development is I've found two other people who also have a SunRem 2MB card, that started bare and was built up by the owner, that are not functional. One owner was able to get the same error 45 that I did (also showing it detected only 128K of memory too). I'm wondering if there's a commonality here that may help in troubleshooting.

More to come..
 

RolandJuno

Active member
Today I had access to a Lisa 2/10 system. The system has two 512K Apple RAM cards installed in it. I pulled my new SunRem 2MB RAM card and set it aside and installed one of the Apple 512K RAM cards in memory slot one. My system powered on and successfully completed all startup tests! So it would seem that my rig is working well enough when the memory card is good. This also means that the MMU is presumably working, so I shouldn't need to delve into that at the moment.

I then pulled the other 512K RAM card from the Lisa 2/10 system and installed the new SunRem 2MB card in memory slot one. The card has 1.2 MB installed (SIMMs in banks 1, 3, and 4). Bank 2 was empty, memory slot 2 on the motherboard was empty, and jumper 2 on the memory card was empty. The Lisa booted up, beeped twice (lo/hi), and gave an error 45. The same exact result I get with my clone.

At this point, it's fairly clear that there's an issue with the SunRem 2MB card I have. Along with the other two owners of this card, we'd like to proceed with trying to troubleshoot why the SunRem 2MB cards aren't working.

Does anyone have one of these cards that is working? What type of RAM are you using? What's the best configuration you've found that has worked? Have you had any issues like the error 45 when booting?
 

Phipli

Well-known member
Does anyone have one of these cards that is working? What type of RAM are you using? What's the best configuration you've found that has worked? Have you had any issues like the error 45 when booting?
Is your RAM EDO or FPM?
 

RolandJuno

Active member
Good question. I have three types. Of these, the bottom one (with ICs beginning with AAA) gives a startup screen. The other two types the Lisa just beeps with a scrambled screen.

But I'm not certain I know how to tell the difference between EDO/FPM.

49A15EA5-7682-4284-890E-5E18C0F167E5.JPG
 

Phipli

Well-known member
Good question. I have three types. Of these, the bottom one (with ICs beginning with AAA) gives a startup screen. The other two types the Lisa just beeps with a scrambled screen.

But I'm not certain I know how to tell the difference between EDO/FPM.

View attachment 62731
The first thing I'd do is scrub the contacts with a Q Tip and some IPA.

I suspect they're not EDO, looking at them. Not sure if it is FPM even :)

I don't know Lisas at all. What arrangement does this RAM need to be in? Pairs like an SE?
 
Last edited:

Phipli

Well-known member
Does the Lisa only take Parity RAM?

Edit : answering myself, yes. Found an old thread here :

 
Last edited:

Busterswt

Well-known member
I have two Sun Rem RAM boards, and one has RAM errors while the other one seems to work fine. I'll have to pull both out and try them in my 2/5 to see if it's an Error 45 like you've got or something else entirely. Been a few years since I paid attention to it.
 

RolandJuno

Active member
Turns out the SunRem 2MB card I have is missing a ground connection to pin 15 (enable) on U4. Adding a bodge to GND for this pin and the card works fine! It's been confirmed to fix at least one other known defective SunRem card.

I had another issue where I accidentally put 74S373 for the two 74LS373 parts (this caused 70 and 71 memory errors).

The only RAM I can get working in it (so far) is NMBS brand (9 chip variety). I've not been able to get 3 chip types working with it.

Hope this info helps others get their broken SunRem 2MB RAM cards working.
 
Top