LisaList2

sorry this is just about connecting the ESProfile to the drive, Apple ][ not even in the mix.

I have this drive that had to be connected to a LISA I want to dump it, but its wonky

I connect the ESP profile to the drive and turn on the drive in the green LED comes on on the ES profile. As soon as I power up the ESP profile the green light goes off, and the ESP profile won't boot if I unplug the cable from the profile drive, whether it's on, or off of the ESP profile will boot.

Hey there - don't give up so quick!

Alex has been great in offering support and tips on why this isn't working with the apple2. Using a logic probe we have determined that the apple2 card is much more worried about parity than the Lisa is - despite both the apple2 profile card and the Lisa having a 74LS280.

got power supply back today, hooked iit up, Ready light on, can't access with my ESProfile.

Asked Alexand others for help.
Waiting

Got my power supply back for my 5meg profile.
Spins up, ready light stays on,
I power my ESProfile boots up fine
connect to drive, it locks up
Power down profile, power down ESprofile,
Reconnect it to profile, wont boot.
I remove power from from ESP32 and Green light comes on.
Cant get them talking

I finally got the idea to try a real ProFile (not sure why I didn't think of that before), and Xenix fails in the same way on there too, so it's looking like a LisaFPGA issue at this point. I wonder what's going on? Maybe another case of a ProFile control pin getting set to an input on the VIA and me making a bad assumption about it, just like on CRES? We'll have to find out!

QuoteI would have expected the file to be called LRAMBO instead?

That seems reasonable/likely.

IIRC, the upload contained three documents (Two pages of reverse engineered schematics of the 512K Memory Board, and one page for the modifications), so it was probably a .sit stuffit archive.

The documents were created on and uploaded from a Lisa running MacWorks XL, so the original files had long (guessing System 3.0, so up to 31 characters) mixed case names. I don't recall if the CompuServe upload process required pre-naming the upload or providing a (possibly different) name upon upload, but I don't see any uppercase "LRAMBO" file/folder/archive names here.

A brief look suggests the filenames in the archive were "MD2 Lisa RamBo Part 1", 2, 3, implying MacDraw 2 documents. The misaligned text in the pdf is a consequence of hastily converting the files to MacDraw II and then (I don't recall what steps) to create a pdf. Sometimes WYSInWYG.

IIRC, MacDraw 2 knew that it was running on a Lisa, and (assumed) that meant rectangular pixels, so would adjust the aspect ratio when drawing to the screen to compensate. However, it corrected in the wrong direction, so if one drew a circle for example, the circle would be about twice as tall as wide on the screen (but would print as a circle).

Quote from: sigma7 on April 10, 2026, 07:31:57 PMWhen I uploaded his design to CompuServe ca. 1986 (the days of 8.3 filenames), the filename was LRamBo.

I love details like this. "Compuserve" is also an important clue, as at least at a certain point it only allowed 6.3 filenames (see PDF page 30 here) owing to running TOPS-10 behind the scenes (see also PDF page 243 here). This would explain why it's LRamBo (six letters) and not LisaRamB or LRamBrd or something longer.

The only inconsistency is that the SIXBIT character encoding used for TOPS-10 filenames didn't have lower case characters, so I would have expected the file to be called LRAMBO instead?

QuoteI've never heard of a LisaRambo card and Google and DuckDuckGo both just turn up a reality show contestant. What's a LisaRambo card?

Paul Capes devised a modification for the 512K Apple Lisa Memory Board using larger DRAM chips, making it a 2MB board. When I uploaded his design to CompuServe ca. 1986 (the days of 8.3 filenames), the filename was LRamBo.

The relevant part of the upload is shown here:

https://lisalist2.com/index.php/topic,392.msg2916.html#msg2916

The 4MB Modification referenced in the other replies came later. The initial implementation was using two LRamBo boards (hence the overlap in terminology), with a modification to support the AST RamStak boards coming shortly after.

The Sun Remarketing 2MB SIMM memory board was designed after that, and included the undocumented jumper to support the 4MB Modification.

The 4MB Modification does require modifications to the CPU Board, but not the motherboard. The LRamBo modification to make a 512K board into a 2M board doesn't require modifying any other boards.

QuoteXenix fails to boot with a bunch of ProFile handshake errors

Reminder that Xenix's ProFile support is known to be problematic and needs patching to work with faster parallel port drives, see:

http://sigmasevensystems.com/xpf_xenix.html

I don't doubt you've just encountered additional bugs .

Sorry for the slower pace of updates lately! School has really picked up as we near the end of the semester, and I've had a lot less time to work on things than I did before. There's not a whole lot left to do at this point though; the main problems that come to mind are hard disk issues, and they might be ESProFile's fault.

I fixed one hard disk issue, where UniPlus would assert CRES midway through the boot process, which would obviously completely break communications with the ProFile. I had temporarily gotten around this by telling ESProFile to just ignore CRES, but I went in and fixed it for real a few days ago. It turns out that I was operating under the faulty assumption that the CRES pin from the VIA would always be set to an output, so I was ignoring the state of DDRB and just blindly piping the pin out to the CRES logic. But this doesn't work if the VIA sets CRES to an input and then puts a 0 in its output register; this will pull my CRES low even though it should actually be floating (which defaults to the desired state of high). So all I had to do was check the proper bit in DDRB. If the VIA's CRES pin is set to an output, then pass CRES on through, but if it's set to an input, then just force our CRES VIA output high.

This is really interesting because it means that UniPlus is setting the CRES output to an input for some reason. I wonder why?

The other two somewhat-major issues left to solve are also both ProFile-related.

One is that Xenix fails to boot with a bunch of ProFile handshake errors. On very, very rare occasions, it makes it to the login screen, but it's quite uncommon, and you're completely out of luck if you try it at anything higher than a 20MHz DOTCK. I'm thinking that this is an ESProFile issue more than it is a LisaFPGA issue though. Xenix works fine on the regular ESProFile, so perhaps it's some sort of subtle timing thing with porting it from a standard ESP32 to a slightly-faster ESP32-S3?

The second is that your very first attempt to boot from the onboard ESProFile at the 75MHz DOTCK will always result in an error 84, but then all subsequent attempts (until you hit ESProFile's reset button) will work fine. It's just that first attempt that's the problem, and only at the 75MHz DOTCK; all three lower speeds work fine. Looking at it with the logic analyzer, it seems that the problem is that ESProFile is sending its data bytes to the Lisa with a 1-byte delay, so it sends the Lisa status byte 3 when it expects data byte 0, data byte 0 when it expects data byte 1, and so on. I have no idea why this only happens on the first attempt and then never again, but it's clearly some kind of ESProFile issue!