Any1 developed device drivers using the Retro68 toolchain?

[Thom Cherryhomes]

Has anyone managed to make a usable DRVR using Retro68?

I need to prototype not only a desk accessory (for the FujiNet Configuration UI), but also a device driver that will talk to the FujiNet via the floppy port.

-Thom

 

[halkyardo]

Has anyone managed to make a usable DRVR using Retro68?

I need to prototype not only a desk accessory (for the FujiNet Configuration UI), but also a device driver that will talk to the FujiNet via the floppy port.

-Thom

I've been working on new ethernet hardware and an accompanying driver - the hardware is still in early-prototype stage, but the driver is more or less complete and functional: https://github.com/rhalkyard/SEthernet/

Ethernet drivers are slightly weird in terms of their driver interface (they only support the Control entrypoint, and don't implement the Prime entrypoint that most drivers use for I/O), but for all intents and purposes they're still a DRVR resource, so that should give you something to go on. There are a couple of gotchas in using Retro68 for drivers, which I've tried my best to explain in the comments, but it's still very much possible. If there's anything in there that doesn't make sense to you, feel free to pick my brain about it.

Specifically, you'll probably be interested in the DRVR header and glue code in software/driver/header.S, the entrypoints in software/driver/driver.c, and probably software/driver/CMakeLists.txt too, for how the sausage actually gets made

 

[marciot]

Has anyone managed to make a usable DRVR using Retro68?

I need to prototype not only a desk accessory (for the FujiNet Configuration UI), but also a device driver that will talk to the FujiNet via the floppy port.

-Thom

Hi, I am jumping in from the thread on Facebook. I wanted to confirm what @halkyardo said. Device drivers need a special entry point and are not just plain code resources. If you use a compiler such as Symantec C++, it will provide that glue code for you so you simply write the "main()" routine. If you are using Retro68, you will need to write that glue code yourself. I think @halkyardo has you covered on that.

Once you get that figured out, you can write the guts of the desk accessory. Yesterday I published the code to my Eyeballer DA on Macintosh Garden, but that code is fairly atrocious. Feel free to use it as a reference, but since it was written by my 15-year-old self 30-odd years ago, it's pretty bad.

I do have a much better DA code you can use as a reference though. It was written about two years ago, when I was working on my MiniVNC server and trying to reimplement the mythical event journaling desk accessory which Apple used in the Guided Tour disk. I can't exactly get that code to work again, because I patched the glue code on the fly for some reason and it only works with a specific version of the THINK compiler I cannot seem to find. Nonetheless, the important bit about that code is that it shows you the basic structure of a DA (aside from the startup glue code) and vitally how to load a dialog box and menus from a resource file, so you can implement a UI very quickly.



Between that and what @halkyardo provided, hopefully, you can cobble something together that works in Retro68!

 

[Thom Cherryhomes]

Yup, it sure looks like it. Thanks guys.
The reason I am using Retro68 here, is literally because this program needs to become part of our whole stack, and be able to be built e.g. from a pipeline.

But this is doable, if a wee...bit....awkward.

-Thom

 

[obsolete]

Not to veer this thread too far off topic hopefully, but I took a look at FujiNet--very cool! I'm curious, though; why the floppy port, not the serial port?

 

[marciot]

@Thom Cherryhomes I might be interested in what you come up with. I've been meaning to try out Retro68 someday. The biggest problem with the legacy tools is that they are no longer being actively maintained (obviously) and they have bugs. So it's a game of whack-a-mole getting around the limitations of a particular tool.

 

[Thom Cherryhomes]

Because it natively supports booting disks directly, and we can extend DCD to provide access to the other subdevices with new device drivers (even the virtual printer).

 

[marciot]

@Thom Cherryhomes I did not know the Macintosh floppy disk interface was capable of having sub-devices. That is certainly a thing with the SCSI interface, but I've never seen it done on the floppy interface. Quite intriguing! May I ask why not use SCSI? Are you targeting pre-SCSI Macs?

 

[Thom Cherryhomes]

Yes, intent is for additional commands to be added to support it, and a device driver on the Mac side to expose it.

And yes, this is explicitly meant to support even the 128K Mac, so we have to go floppy.

-Thom

 

[obsolete]

Because it natively supports booting disks directly, and we can extend DCD to provide access to the other subdevices with new device drivers (even the virtual printer).

Very cool, thanks!

 

[marciot]

And yes, this is explicitly meant to support even the 128K Mac, so we have to go floppy.

Fascinating! I'll be following your work!

 

[cheesestraws]

Be warned: I believe there are quirks with DCD + extra devices on later ROMs: @tashtari is the expert here

 

[marciot]

Be warned: I believe there are quirks with DCD + extra devices on later ROMs: @tashtari is the expert here

I was about to ask what DCD meant, but @cheesestraws mention of @tashtari led me to the info I needed. For anyone else joining the party, it looks like the general idea is explained here and I believe is the limitations table you are referring to

 

[Thom Cherryhomes]

Still sculpting on it, but here's a pic.

Here's the corresponding FujiNet on Superbenk's desk:

 

[marciot]

Still sculpting on it, but here's a pic.

Wow, that was super fast! Great job!

Can you explain what is meant by host slots vs. drive slots? Or possibly refer me to some documentation that explains it? I'm still trying to wrap my head around how this is similar or different from the RaSCSI I am familiar with, aside from using an entirely different port. Would this eventually be able to work with CD images, for example? Or could it offer Ethernet, sort of like the DynaPort emulation in RaSCSI?

 

[Thom Cherryhomes]

Host slots, are TNFS hosts where you can mount disk images into drive slots.

So, e.g. in that picture, there's a copy of System 6.0.8.img being mounted from host slot 2 (which is fujinet.online). There is a special host name, 'SD' that you can assign to a host slot, to read/write stuff off the local card storage.

The networking sub-device works _VERY_ differently from anything that has existed on the Mac, ever. It does not emulate a hardware ethernet interface, at all. What is done instead is to send commands to the networking device to do things like open a channel, read from it, write to it, get status, etc. There are a series of protocol adapters for various networking protocols, TCP, UDP, HTTP/S, SSH, FTP, TNFS, SMB, etc. which run on the ESP32, and do all the complex protocol interactions needed, while exposing a clean interface to the Mac. Since the ESP32 is much faster than the Mac, it can handle the bits that haven't been possible to handle (modern SSL, Web APIs etc). It's an entirely different (and, from a programming standpoint, much simpler!) way to handle networking. Oh, and there are built in JSON and XML parsers that can parse incoming data, and quickly pass off relevant data to the Mac...

Our wiki is here:

Home

8-bit systems to ESP32 WiFi Multifunction Firmware - FujiNetWIFI/fujinet-platformio

github.com

-Thom

 

[marciot]

It's an entirely different (and, from a programming standpoint, much simpler!) way to handle networking.

Ooooooo. This interests me. For the last two years, I have been working on a VNC server for classic Macs, but MacTCP is right now one of the major obstacles, as not only is it the slowest component, but it also appears to be unstable on the Mac Plus and causes occasional crashes. If I can get MacTCP out of the equation, I might have a usable remote desktop solution that works on all Macs. That would be very cool.

 

[cheesestraws]

Protocol offload is probably the way to go, yes: I've been thinking this for a while, although less in the context of an external dongle and more in the context of a potential NIC that I'll never design because I'm bad at hardware. TLS offload is, after all, a thing in big machines: why not in small ones as well?

The problem you'll find if you're introducing a totally new API, though, is you'll have to get buy-in from people to use your API rather than the traditional ones, which will of course lock them into your hardware, rather than all the Ethernet cards that are already out there. And if it's IP-specific, you'll be also preventing people from using things like AppleShare. So you might want to consider providing a backwards-compatible TCP and DDP interface also.

 

[Thom Cherryhomes]

Completely understandable, my only counter is that everything we do is open source, and freely available, now and forever. We want people to use our stuff; without reservation.

Firmware: https://github.com/FujiNetWIFI/fujinet-platformio
Hardware: https://github.com/FujiNetWIFI/fujinet-hardware (mac stuff will be here soon)
Software: https://github.com/FujiNetWIFI/fujinet-apps

We are on multiple platforms, and we're continuing to get onto every single computer and game console we can (we've started work on the Atari 2600 version, a few weeks ago)

-Thom

 

[marciot]

So you might want to consider providing a backwards-compatible TCP and DDP interface also.

It might be interesting to have it emulate the MacTCP API. There's not that much to it. MacTCP is just a device driver and it implements routines for opening a connection, closing a connection, reading and writing data, etc. But it does *everything* on the 68000, so no wonder it is slow. If it could simply hand it off to another device for processing, you would essentially have an accelerated MacTCP.