Ohhh, this looks promising. I had looked at openWRT as an option. Good idea to look through their website.
And yeah, my Netgear ProSafe switch will automatically connect to the MacCon without a hitch. It will even automatically go to 10Mbps
-
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.
Wifi Extension Development Thread
- Thread starter ants
- Start date
Ohhh, this looks promising. I had looked at openWRT as an option. Good idea to look through their website.
And yeah, my Netgear ProSafe switch will automatically connect to the MacCon without a hitch. It will even automatically go to 10Mbps
Hmmm. This already has OpenWRT.. https://www.newegg.com/Product/Product.aspx?Item=9SIAFN26TX8230
Edit: And has some great documentation..
https://gl-inet.com/docs/mini/ar300m/
Edit: And has some great documentation..
https://gl-inet.com/docs/mini/ar300m/
Last edited by a moderator:
techknight
Well-known member
I like OpenWRT because you can write your own scripting to run on it to catch commands from the Mac extension your writing, or use a built-in API.
That way the extension could periodically scan for non-associated APs and its signal strength and list them in the dropdown. Just like modern macs.
As far as hooking up a Pi to the bus without the ethernet, this has been an idea I have been logging around for a very very long time. I want to do this so I can use it as a co-pro for accelerating Javascript, etc so you can browse the modern internet on an older mac with some "decent" speed.
But unlike you guys, I am only adept in one type of programming language and that was VB6, which luckily there were newer dev environments I have migrated to that kept a similar syntax.
C, etc over my head. :-(
As far as hardware engineering thats the easy part. The programming that links the two, Not so much...
For bus access, there were a couple different ideas that I had. One is just using simple hardware decoding and memory mapped I/O, sharing memory space on the address bus that the Pi can see, and vice/versa, with a program running on the Pi to catch read/writes to that address block.
The other idea which is more slick is the Pi itself attached to the bus as a Co processor in such that you can send F Line instructions and the Pi would catch and execute these.
In this case you could have a program running on the Pi that has a plethora of custom F-Line instructions that the ARM could execute when the 68K issues them to the CoPro address space. I think I recall when reading the 68K manual you can have more than 1 co processor. So you could map the Pi as a 2nd co processor in a machine that doesnt have one.
Otherwise, you could emulate the regular 68K copro on the Pi, as well as having an additional instruction set to make things more powerful.
That way the extension could periodically scan for non-associated APs and its signal strength and list them in the dropdown. Just like modern macs.
As far as hooking up a Pi to the bus without the ethernet, this has been an idea I have been logging around for a very very long time. I want to do this so I can use it as a co-pro for accelerating Javascript, etc so you can browse the modern internet on an older mac with some "decent" speed.
But unlike you guys, I am only adept in one type of programming language and that was VB6, which luckily there were newer dev environments I have migrated to that kept a similar syntax.
C, etc over my head. :-(
As far as hardware engineering thats the easy part. The programming that links the two, Not so much...
For bus access, there were a couple different ideas that I had. One is just using simple hardware decoding and memory mapped I/O, sharing memory space on the address bus that the Pi can see, and vice/versa, with a program running on the Pi to catch read/writes to that address block.
The other idea which is more slick is the Pi itself attached to the bus as a Co processor in such that you can send F Line instructions and the Pi would catch and execute these.
In this case you could have a program running on the Pi that has a plethora of custom F-Line instructions that the ARM could execute when the 68K issues them to the CoPro address space. I think I recall when reading the 68K manual you can have more than 1 co processor. So you could map the Pi as a 2nd co processor in a machine that doesnt have one.
Otherwise, you could emulate the regular 68K copro on the Pi, as well as having an additional instruction set to make things more powerful.
Last edited by a moderator:
Trash80toHP_Mini
NIGHT STALKER
Dunno if it's any help, but the 68030 MMU is a less powerful subset of the discrete MMU used in the Mac II. ISTR reading something along the lines of implementing the full blown MMU for use with the 68030. Could that be a wedge point for Pi?
Last edited by a moderator:
ants
Well-known member
@hfrazier I figured out my 404 issue - turns out a GET request should not include the host in the path unless it's through a proxy, i.e:
Wrong:
GET http://vonets.cfg/a.asp HTTP/1.1
Host: vonets.cfg
Right:
GET /a.asp HTTP/1.1
Host: vonets.cfg
The reason I didn't pick it up is because Fiddler was lying to me! Fiddler actually manipulates the GET request and appends the host to the path - even in Raw view. I just happened to pick it up in Wireshark when comparing the raw TCP data between my Mac and my PC. I've never had a server deny the first request before, but it seems the Vonets module is particularly fussy.
Anyways, good news is that I have actual communication between a native Mac app and the Vonets module - so the rest should be a walk in the park hahaha...
As for OpenWRT I'm happy to give it a go - the good thing is that if we adopt that standard, then maybe any compatible device will work with our extension. That'd be cool.
Wrong:
GET http://vonets.cfg/a.asp HTTP/1.1
Host: vonets.cfg
Right:
GET /a.asp HTTP/1.1
Host: vonets.cfg
The reason I didn't pick it up is because Fiddler was lying to me! Fiddler actually manipulates the GET request and appends the host to the path - even in Raw view. I just happened to pick it up in Wireshark when comparing the raw TCP data between my Mac and my PC. I've never had a server deny the first request before, but it seems the Vonets module is particularly fussy.
Anyways, good news is that I have actual communication between a native Mac app and the Vonets module - so the rest should be a walk in the park hahaha...
As for OpenWRT I'm happy to give it a go - the good thing is that if we adopt that standard, then maybe any compatible device will work with our extension. That'd be cool.
ants
Well-known member
@techknight and @Trash80toHP_Mini, what you are suggesting is exciting and scary - perhaps we need a new thread for Raspberry Pi acceleration! What's most exciting in my opinion is that it would allow many people to speed up their old macs, as cards like Daystar Turbo's are near impossible to find these days.
But i'm going to take baby steps and try and get a working Wifi connection first.
But i'm going to take baby steps and try and get a working Wifi connection first.
@ants Good catch! I need to fire up my 'Mystic' Color Classic and see if the Farallon NIC has better success comunicating with the Vonets. (It looks like that's what you've got so I'm sure it will.)
Random question - does anyone know where to get a DB25 to IDC adapter so that I can externally connect a SCSI2SD?? My CC still ha a mechanical drive that I would like to mirror over to an SD card...
I actually went ahead and ordered the one on Newegg, so I'll follow up with my results!
Random question - does anyone know where to get a DB25 to IDC adapter so that I can externally connect a SCSI2SD?? My CC still ha a mechanical drive that I would like to mirror over to an SD card...
ants
Well-known member
Cool. I've done a bit more groundwork on the extension, I've linked it up to the HTTP library and I've created a base class that should allow us to add other wifi cards such as the one you've ordered. Updates are on GitHub.
I've hit a new issue where DNS resolution is failing when making HTTP requests via the Wifi menu. I'm currently at a loss on how to fix this, but again I'll sleep on it for a while and hopefully it'll come to me.
I've hit a new issue where DNS resolution is failing when making HTTP requests via the Wifi menu. I'm currently at a loss on how to fix this, but again I'll sleep on it for a while and hopefully it'll come to me.
ants
Well-known member
Using the proven software development technique of "trying random sh*t until something works", I now have a functioning network list, reading from the VM300:
Still lots of problems to solve, the main one being that the whole system locks up for 10 seconds when clicking the menu (while waiting for the VM300 to provide a response).
I'm gonna take a break on this for a little while.
Still lots of problems to solve, the main one being that the whole system locks up for 10 seconds when clicking the menu (while waiting for the VM300 to provide a response).
I'm gonna take a break on this for a little while.
techknight
Well-known member
thats what the old school "DoEvents" was supposed to solve in the VB world. I dont know the C equivalent if there is one.
In the early days of me programming, that was what I used to do. I would have a subroutine that did something, and then stuck around and waited for the response.
When I switched to B4X/Java I learned programming another way. Make everything event-driven. So you would setup the request from the VM300 and then return from subroutine. so your not holding up the OS. Then if and when the data arrives, it fires an event which grabs the data, and pulls down the menu.
In the early days of me programming, that was what I used to do. I would have a subroutine that did something, and then stuck around and waited for the response.
When I switched to B4X/Java I learned programming another way. Make everything event-driven. So you would setup the request from the VM300 and then return from subroutine. so your not holding up the OS. Then if and when the data arrives, it fires an event which grabs the data, and pulls down the menu.
Last edited by a moderator:
joethezombie
Well-known member
Just chiming in to say not just how neat this entire project is, but also for the help in getting Retro68 compiled. I've been meaning to delve into programming 68k, but didn't really know where to begin.
My VM300 arrived today, so I hope to get it working on my compacts soon. This extension is just sooo cool, and to top off your amazing wifi hack with it is awesome.
My VM300 arrived today, so I hope to get it working on my compacts soon. This extension is just sooo cool, and to top off your amazing wifi hack with it is awesome.
. Real background tasks on the mac seems to be an art few developers mastered.@ants Awesome!
Still waiting on the new module.. And yeah, @K55 beat me to it, I think the ThreadManager extension can be installed on as old as 7.0??
I'll try to delve into OpenWRT as much as I can, as I've gotten quite proficient in *nix OS'es. I think I have an old WRT54G around here somewhere that I can install it on...
Still waiting on the new module.. And yeah, @K55 beat me to it, I think the ThreadManager extension can be installed on as old as 7.0??
I'll try to delve into OpenWRT as much as I can, as I've gotten quite proficient in *nix OS'es. I think I have an old WRT54G around here somewhere that I can install it on...
ants
Well-known member
OK I've implemented the Thread Manager into the networking stack, which now allows the HTTP requests to frequently yield time to other tasks. But there were still limitations to the Thread Manager, so I had to move all of the long processing into a background application. Long story short, the net result is that the menu is now smooth as butter.
Next task is to try and get switching between wifi networks working, and add a heap of error handling...
Next task is to try and get switching between wifi networks working, and add a heap of error handling...
Last edited by a moderator:
CC_333
Well-known member
This is a really neat project!
This is for way down the road, but you might consider also implementing this as a control panel (or maybe implement the menu and extra stuff as an extension and have it read a preference file created and modified by the control panel, or maybe just a simple application even), so users can change some more advanced settings and stuff, like the Airport software in OS 9 does, and also maybe do stuff like punch in passwords (this will be used with a modern WiFi adapter, so why not? It ought to support WPA2 and such).
With some work, this could be a complete re-implementation of (and an extension to, that could be implemented in later SSWs) the UI in OS 9 and early OS X.
So, this will run on any version of System 7, pretty much? Have you tried it in 8.0/8.1?
c
This is for way down the road, but you might consider also implementing this as a control panel (or maybe implement the menu and extra stuff as an extension and have it read a preference file created and modified by the control panel, or maybe just a simple application even), so users can change some more advanced settings and stuff, like the Airport software in OS 9 does, and also maybe do stuff like punch in passwords (this will be used with a modern WiFi adapter, so why not? It ought to support WPA2 and such).
With some work, this could be a complete re-implementation of (and an extension to, that could be implemented in later SSWs) the UI in OS 9 and early OS X.
So, this will run on any version of System 7, pretty much? Have you tried it in 8.0/8.1?
c
Last edited by a moderator:
ants
Well-known member
@CC_333 a password dialog will be coming soon. I've already got a preferences file set up for caching the networks, so I hope to store credentials in there too.
I haven't done any testing outside of 7.5 yet. The code relies on Thread Manager and MacTCP (or Open Transport) - so I guess it should work on any machine that has these installed.
Once things are stable I'll provide a release for people to test on different machines. The Retro68 compiler supports 68k, PPC and Carbon - so there's opportunity to expand this to other OS versions.
I haven't done any testing outside of 7.5 yet. The code relies on Thread Manager and MacTCP (or Open Transport) - so I guess it should work on any machine that has these installed.
Once things are stable I'll provide a release for people to test on different machines. The Retro68 compiler supports 68k, PPC and Carbon - so there's opportunity to expand this to other OS versions.
joethezombie
Well-known member
Since there was some uncertainty earlier on if the VM300 was working with the Asante MacCon for IIsi or SE/30, I thought I'd chime in and report a resounding success. I now have a wifi connected SE/30! Woot! Now I'm even more excited for this extension!
ants
Well-known member
@joethezombie glad to hear you got it working. Did you hit any issues along the way? I was thinking of writing a wiki article on the setup process.
