LisaList2

Advanced search  

News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

Pages: 1 2 [3] 4 5 ... 10
 21 
 on: October 26, 2022, 08:09:42 am 
Started by rayarachelian - Last post by rayarachelian
Idea: use an RPI Zero W (should have multiple cores, doesn't need much RAM) to collect the VSYNC, HSYNC, and video Data lines that are output to the Lisa's video analog board, and render output off the HDMI port. You'll need level converters since these are 5V on the Lisa, but the RPi wants 3.3V. You might be able to go cheap and use 3 resistors, but that might be noisy, etc.

Can be done with something other than an RPI, but the board must have multiple cores, be relatively fast, and have video output and GPIO.
Preferably all 3 lines coming from the Lisa should be readable by the SBC (Single Board Computer) in one read and not multiple. i.e. a single read byte or word.
To make it easier to detect, perhaps VSYNC should be put on a high bit so that you can test the "N" flag (negative) with a simple branch. Or perhaps it might be better to put the HSYNC line there instead as that will be tested more often.

The board should launch two processes at high priority (assuming we're using Linux) and leave any remaining cores for the OS running on it.
One process will collect data from the input lines, the second will render them onto the display (frame buffer). No other connectivity, such as ethernet, or USB is needed for this project.
The first phase of the first project will count the number of lines on a frame (or more) to figure out if we're running on a 3A system ROM, or standard (D-H) ROM.


Code: [Select]

  while (read_gpio_bits && count<3) {
    if (gpio & HSYNC) linecount++;
    if (gpio & VSYNC) count++;
 }
 lines= linecount/count;   // do some averaging here and decide which system type we're on.

To do this count the number of HSYNC pulses between each pair of VSYNC pulses. You'll also need to carefully clock the rate of the data bits coming in.
Once we know how many lines to render, we'll start collecting and plotting the Data bit onto a shared memory 32KB area that's also accessible by the second process.It may be advantageous to use multiple 32KB areas as well.

VSYNC is used to signal the end of a frame, and HSYNC is used to end a line.

Code: [Select]

while (read_gpio_bits) {
    if (gpio & VSYNC) {x=0; y=0;}
    if (gpio & HSYNC) {x=0; y++;}
    plot(x,y,gpio & DATA); }
The second process could then use one of many algorithms to render video on the frame buffer (we don't want X11 here), perhaps using SDL or some other library.You could steal the HQ3X, or AA, or AA with Gray Replacement algos from LisaEm for this.
This board could also be hooked up to the VSROM and some other point on the CPU board where the video Data bit could be read from in order to display output on an HDMI or VGA/etc LCD monitor.
It could also be used to replace a dead video system by removing the analog board and CRT with a properly sized 12" monitor that accepts HDMI signals.
(You could then use a USB HDMI capture card to capture the output of the Lisa and put it on a video projector, or for use with a video podcast, etc.)

Edit: forgot to mention, for this project you should either compile in the RTOS Linux patches, and/or pin these two processes to a specific core and set it to the realtime class.

 22 
 on: October 26, 2022, 07:52:15 am 
Started by rayarachelian - Last post by rayarachelian
I'm in a really very bad place right now, the cancer has spread to every major organ, not sure, short of a miracle, that I'll ever be able to make these projects see the light of day.
I'm therefore sharing my (possibly useless) ideas for various things on this board, as well as how they'd be implemented.
If you also have project ideas, feel free to post them, but I ask that:
  • Has to be feasible.
  • You include information on how to implement your project.

 23 
 on: October 17, 2022, 10:30:58 am 
Started by rayarachelian - Last post by rayarachelian
Recently my Apple collection got an over 20 years younger addition - a Mac Mini A1283 with Intel Core Duo CPU. This is my first macOS 10 machine, until now my favorite was macOS 6.0.8. Now it took me two days to get macOS 10.11 El Capitain running on this machine. Skip the next paragraph for the LisaEM bug report.

Apple sees no reason to create macOS installation media from Windows or Linux. There is no ISO file available, instead you have to run a program on a second Mac from the appropriate era to create a bootable USB drive. And it will boot. But macOS will not install because the "installation files cannot be verified". Yes, they use certificates for the EFI secure boot. And those certificates expired in 2019. So first I had to get Snow Leopard 10.6, which doesn't use Secure Boot yet, install it on the Mac Mini, and apply all available updates. Then I set the date to October 24, 2019, downloaded the El Capitain installer from Apple's support site, unplugged the LAN cable, and finally started the installation. The combination of download date, machine time, and signatures in the installer file is critical and must match.  >:(

Yes, it's a mess what they did in terms of older machines and operating systems, this is why I want to continue supporting these machines anyway. I don't agree that older machines are useless or should be abandoned.


But now I have one good use for this modern machine in my museum: running LisaEM! Installation worked fine, configuration worked fine, but every time I want to boot anything, I get the fatal error "cpu68k_makeipclist: But! ipc is null! Stopped at cpu68k.c:cpu68k_makeipclist:1064 with code:501"

This is 1.2.7-RC4_2022.04.01 running on MacOS 10.11.6 (Core 2 Duo 2 GHz 8 GB). First I tried the dedicated installer for 10.11, then the fat one. Both installations behave the same.

---
Update: same applies to RC3a, but line 1085 instead of 1064.

I'm very sorry, but yes, RC4 is very much broken.

I didn't realize RC3a is broken in this way as well. Thank you, if that's confirmed as a bug I'd have to back much earlier.

You could try the binary for an earlier MacOS as well, maybe 10.8 or 10.7 and see if it does anything different, that would indicate a compiler/optimization issue, I suppose.


 24 
 on: October 17, 2022, 09:41:54 am 
Started by rayarachelian - Last post by patrick
Recently my Apple collection got an over 20 years younger addition - a Mac Mini A1283 with Intel Core Duo CPU. This is my first macOS 10 machine, until now my favorite was macOS 6.0.8. Now it took me two days to get macOS 10.11 El Capitain running on this machine. Skip the next paragraph for the LisaEM bug report.

Apple sees no reason to create macOS installation media from Windows or Linux. There is no ISO file available, instead you have to run a program on a second Mac from the appropriate era to create a bootable USB drive. And it will boot. But macOS will not install because the "installation files cannot be verified". Yes, they use certificates for the EFI secure boot. And those certificates expired in 2019. So first I had to get Snow Leopard 10.6, which doesn't use Secure Boot yet, install it on the Mac Mini, and apply all available updates. Then I set the date to October 24, 2019, downloaded the El Capitain installer from Apple's support site, unplugged the LAN cable, and finally started the installation. The combination of download date, machine time, and signatures in the installer file is critical and must match.  >:(


But now I have one good use for this modern machine in my museum: running LisaEM! Installation worked fine, configuration worked fine, but every time I want to boot anything, I get the fatal error "cpu68k_makeipclist: But! ipc is null! Stopped at cpu68k.c:cpu68k_makeipclist:1064 with code:501"

This is 1.2.7-RC4_2022.04.01 running on MacOS 10.11.6 (Core 2 Duo 2 GHz 8 GB). First I tried the dedicated installer for 10.11, then the fat one. Both installations behave the same.


---
Update: same applies to RC3a, but line 1085 instead of 1064.

 25 
 on: October 14, 2022, 05:02:07 pm 
Started by rayarachelian - Last post by rayarachelian
fixes for LOS2.0 installer fail pushed to livedev, but needs regression testing for all OSs to ensure something else didn't break.

 26 
 on: October 14, 2022, 10:20:16 am 
Started by rayarachelian - Last post by rayarachelian
Just recently noticed that the VCFMW session was posted here: https://youtu.be/H8SDASP2kQk (or via piped to avoid google tracking: https://yewtu.be/H8SDASP2kQk ) a while ago. There's other sessions in that channel that are worth a watch, though not Lisa related.

 27 
 on: October 14, 2022, 10:17:26 am 
Started by Al Kossow - Last post by rayarachelian
Does this maybe require a twiggy drive? If so it would be nice if they provide a schematic of the interface.

 28 
 on: October 14, 2022, 07:10:43 am 
Started by Al Kossow - Last post by Al Kossow
the next version will  optionally unserialize all versions of the os
https://twitter.com/DiskBlitz/status/1580787719910744064

 29 
 on: October 13, 2022, 12:21:21 pm 
Started by AlexTheCat123 - Last post by AlexTheCat123
After a whole lot of work, my open-source I/O board replica is finally done! I'm pretty happy with how it turned out; it should be pretty much identical to the original other than the routing of traces. It's by far the most expensive board that I've designed, but it's still only around $250 for the board and all of the required parts, so not too bad. If you want to reuse some chips from your old board, the total cost is closer to $150, which is pretty awesome! You can find the Gerbers and more information about the board in this GitHub repository as well as the other Lisa boards that I've made. This took a really long time to design, so hopefully it's helpful to a lot of people who have corroded I/O boards!

 30 
 on: October 11, 2022, 07:45:36 pm 
Started by Al Kossow - Last post by stepleton
I don't know very much about how Applesauce works, but I had thought that getting flux images of Twiggy diskettes was difficult owing to their unusual track pitch --- a lot of more conventional floppy drives couldn't be expected to handle it. Was this wrong, or was it necessary to do something special to collect the flux image mentioned in the tweet?

Pages: 1 2 [3] 4 5 ... 10