You likely have WIRELESS INTERNET ability in your LISA right now!

[bmwcyclist]

Yeah, I'd go with the magic block approach for sure. It's got the downside of requiring that you write a driver of course, but that shouldn't be all that difficult when you have Claude to help. We already agreed via email that I'm not responsible for any issues with this fork of the code, so that should be taken care of!

Thank you!!!

I wanted to make sure.

.

[wottle]

Very cool.  I'll be looking at your progress and try to pull it into my ESP32 firmware for the external add-on scenario with the LisaFPGA.  As far as I could tell, the ESP32 modules on the LisaFPGA don't support Wifi, so your upgrades won't work on the stock LisaFPGA, but I'm hoping to make it support this functionality with a simple addition of a $20 ESP32 and some wiring.  Unfortunately, I don't know that you'll be able to support my ESFloppy / ESProfile SD card management I added to mine.   It takes advantage of the fact you can power the LisaFPGA without booting the Lisa.  So the ESProfile / ESFloppy are powered on while the Lisa hasn't booted.  So I can manipulate the SD cards while they aren't serving as actual emulated drives.  In a real Lisa, you don't have this mode where the ESProfile would have power, but not be working as a hard drive.  I suppose you might be able to do it with safeguards (e.g. you can never manipulate the profile.image itself).  But with Selector as your profile, you could maybe still offer the ability to upload or remove disk images on the SD card?  More so on the ESFloppy, but the ability to add floppy images over Wifi has been a great usability improvement for me. 

I actually am going to try to work on building an ESFloppy standalone for my actual Lisa.  I don't use the floppy drive, and think with an ESFloppy with wifi management, I'd be able to much more easily load new software onto it.  And with the active software development on the Lisa going on right now, I finally have a need to do it.  Great job!

[bmwcyclist]

Very cool.  I'll be looking at your progress and try to pull it into my ESP32 firmware for the external add-on scenario with the LisaFPGA.  As far as I could tell, the ESP32 modules on the LisaFPGA don't support Wifi, so your upgrades won't work on the stock LisaFPGA, but I'm hoping to make it support this functionality with a simple addition of a $20 ESP32 and some wiring.  Unfortunately, I don't know that you'll be able to support my ESFloppy / ESProfile SD card management I added to mine.   It takes advantage of the fact you can power the LisaFPGA without booting the Lisa.  So the ESProfile / ESFloppy are powered on while the Lisa hasn't booted.  So I can manipulate the SD cards while they aren't serving as actual emulated drives.  In a real Lisa, you don't have this mode where the ESProfile would have power, but not be working as a hard drive.  I suppose you might be able to do it with safeguards (e.g. you can never manipulate the profile.image itself).  But with Selector as your profile, you could maybe still offer the ability to upload or remove disk images on the SD card?  More so on the ESFloppy, but the ability to add floppy images over Wifi has been a great usability improvement for me. 

I actually am going to try to work on building an ESFloppy standalone for my actual Lisa.  I don't use the floppy drive, and think with an ESFloppy with wifi management, I'd be able to much more easily load new software onto it.  And with the active software development on the Lisa going on right now, I finally have a need to do it.  Great job!

Wow nice! Yes, wifi software loading would be great. I was doing it tonight but with MacWorks on my AppleTalk network. Publish to my Pi running netatalk then copy to the MacXL. It would be great to do it on the lisa side. The closest I have so far is LISACom.

[AlexTheCat123]

I actually am going to try to work on building an ESFloppy standalone for my actual Lisa.  I don't use the floppy drive, and think with an ESFloppy with wifi management, I'd be able to much more easily load new software onto it.  And with the active software development on the Lisa going on right now, I finally have a need to do it.  Great job!

I'm almost done with the standalone version, which I've been working on for nearly 4 months now, so I'd appreciate it if you'd let me finish that up instead of making your own. That way we don't end up with a bunch of confusion over two devices that do the same thing.

[wottle]

I'm almost done with the standalone version, which I've been working on for nearly 4 months now, so I'd appreciate it if you'd let me finish that up instead of making your own. That way we don't end up with a bunch of confusion over two devices that do the same thing.

Sorry, I actually thought you were done with your standalone version.  I certainly wasn't planning on trying to jump in front of you with a custom version.  No rush on finishing - for some reason I thought I had seen the standalone version already published on GitHub.

[AlexTheCat123]

Sorry, I actually thought you were done with your standalone version.  I certainly wasn't planning on trying to jump in front of you with a custom version.  No rush on finishing - for some reason I thought I had seen the standalone version already published on GitHub.

It's pretty much fully tested and working at this point; I just need to get everything together and write the readme to release it. The reason it's taking so long is because I had to add Disk II, Disk ///, SmartPort hard and floppy disk, and Hard Disk 20 emulation on top of what it already had, along with some other cool features, and those took quite a while to implement and debug since I'm doing it by hand without AI! The version that's on GitHub right now is still just the base LisaFPGA-integrated version that only emulates Sony 400K/800K and Twiggy.

[bmwcyclist]

Sorry, I actually thought you were done with your standalone version.  I certainly wasn't planning on trying to jump in front of you with a custom version.  No rush on finishing - for some reason I thought I had seen the standalone version already published on GitHub.

It's pretty much fully tested and working at this point; I just need to get everything together and write the readme to release it. The reason it's taking so long is because I had to add Disk II, Disk ///, SmartPort hard and floppy disk, and Hard Disk 20 emulation on top of what it already had, along with some other cool features, and those took quite a while to implement and debug since I'm doing it by hand without AI! The version that's on GitHub right now is still just the base LisaFPGA-integrated version that only emulates Sony 400K/800K and Twiggy.

I think you may have already answered this somewhere else... Other than building my own, where will they be available?

[AlexTheCat123]

You'll be able to get them through MacEffects as well!

[bmwcyclist]

My Intern/Tutor has this question for you:

Subject: ESProFile emulator: block range check

"Alex,

While working on ESPFuji I found a small bug in the emulator range check. It is in your main branch too, so I wanted to pass it on.

In sw/ESProFile/ESProFile_Emulator.ino the ordinary read and write paths test

    else if(blockNum < disk.fileSize()){

(line 577 in readDrive and line 932 in writeDrive on main). That compares a block number with a size in bytes, so every block number below the byte count of the image passes, not just the blocks that exist. A 10 MB image has 19,456 blocks but 10,350,592 bytes, so block 20,000 is accepted.

What happens next, from reading the SdFat source: seekSet(blockNum * 532) fails because the position is past the end of the file, and the file position stays where the previous command left it. A read then returns the block after the last one accessed. A write overwrites that block.

A Lisa never asks for those blocks in normal use, so I do not think anyone has been bitten. The case that worried me is an image larger than about 16.7 MB (my Macintosh XL image is 35 MB). There the byte count is above $FFFE00, so a special block number the firmware does not know also passes the check, and a write to it would land on a real block. I have not reproduced this on hardware; it is from the code.

The fix is one division in each place:

    else if(blockNum < disk.fileSize() / 532){

I have made that change in my ESPFuji work for the next version. Happy to send a pull request if that is easier.

"