Recent content by mmjs

You are completely right, no intervention is necessary. Working great with the code as shipped. Thank you!

Happy to report that once I changed destination_network to port.network in the latest code the 512K is happy! Additionally, I found a pin issue on my PhoneNet adapter, which fixed the discrepancy with zones not showing up. Ultimately it looks like it was the combo of the timeout, which did get...

Interesting! In this particular case it seems like a direct connection actually worked *better* since I could at least see and browse other zones, but I need to actually properly test now

Thank you for the quick turnaround! This now works with all my regular LT and LToUDP machines, with both configurations (ie. both with and without tashrouter serving as a seed router). However, the 512K is still struggling. When tashrouter is NOT set as a seed router, then it still doesn't see...

Yup, here's my config without seed: import logging import time import tashrouter.netlog from tashrouter.port.ethertalk.tap import TapPort from tashrouter.port.localtalk.ltoudp import LtoudpPort from tashrouter.port.localtalk.tashtalk import TashTalkPort from tashrouter.router.router import...

FYI, when using @finkmac's tap solution changing to destination_network=port.network in sending.py breaks functionality. This is with a newly pulled version from repo and a config file that works (other than a timeout on a Mac 512K) when destination_network=0x0000. This is on a network where...

Hey folks, I've been seeing something similar with a 512K. Effectively it times out after about 85 seconds after connecting, and during this time it works fine. I haven't done any proper testing yet, but figured I would share since it seems quite similar to the issue described here. I posted...

Definitely sounds like you will have to start to check additional lines across the board to troubleshoot this. One note -- the GLUE is absolutely necessary for any kind of operation (as you've probably noticed with the screen). Without it, the 16Mhz clock will not even get to the video logic, so...

I finally closed the loop on this and wrote a lengthy blog post about what it took to get two working SE/30 boards out of this mess :) https://blog.vladovince.com/i-get-knocked-down-but-i-get-up-again-the-sisyphean-macintosh-se-30-struggles/

Feel free to share your pattern if you've got a pic, might provide some insight! Also, are you using the oscilloscope to check out your data and address lines? It might provide a lot of insight while you identify whether you have a ROM, RAM, memory mux or another bus related problem. This...

Not necessary to get to question mark! I think the original ROM may fail to boot a system without an FPU, and custom ROMs like the Rominator II may boot but applications that require an FPU will fail with Error Type 90 (ie. no FPU). But you should still be able to get to floppy icon.

Hi, I've gone through a pretty difficult rebuild recently (some details here: https://68kmla.org/bb/index.php?threads/se-30-32mhz-clock-and-uh7.46062/ and on Mastodon if you want to read a *very* long thread: https://mastodon.vladovince.com/@mejs/111008723163117281) Here's what I found was...

Thank you both @obsolete and @Melkhior ! In the end this was definitely caused by bad contacts in sockets. Thanks for pointing towards the GLU -- eventually, I found socket issues with SCSI, GLU and FPU. I directly soldered SCSI and GLU, and got a new socket for the FPU. I would have directly...

Hey everyone, This is a follow up to this thread which seemed to end in success, but after a couple of weeks using my newly rebuilt SE/30 Bolle board, I started to experience strange issues that resulted in non-functional FPU. For context, my board is fully socketed and uses a Rominator II. I...

This worked great, thanks again @croissantking ! I'm still waiting for 4 more 512K modules, so keeping the expansion at 8MB for now.