Amiga Development as a Hobby

[RichardP]

Hi all,

A quick intro to myself... I am a software engineer by trade and a hardware engineer for fun. As a young kid, I always have fond memories of the machines - This is where I am today. Keen to re-kindle my hardware desire abd 'Build Stuff' for the Amiga and other retro computers I found myself buying machines for a project. (I love collecting them too)

Thats where the nightmare starts.. a basic machine as it was released in the day is not up to snuff for a development machine. An Amiga 500 is not even an option; but I found that out after the fact I bought it. I was donated a Amiga 600 which is much better (as it had a 1/2 a meg memory expansion fitted). I ripped out the HDD and put in a SD card instead.

My first project was to build a PLIP-Box to get a simple network running - Thats the part things went awry.. I have far bigger Ambitions but this is where its at..

You still have to license AmiTCP ? Really? Same with Miami.. Are people still trying to make a living from 30 year old machines? (This is not unique to the Amiga scene!)

As a hobbyist, I find it difficult to shell out cash to make a device that eventually will get open sourced. The costs are not large for individual components, but when you add them all they become crazy .. then you still need to buy software. This changes the original preposition that its for fun - and the result is that newcomers and old scool coders are not encouraged to develop anything on the platform.

Excuse my ramblings.. trying to make sense of the Amiga software development world.

Richard

[ajk]

Welcome!

There is a free version of AmiTCP which should cover ordinary usage: http://aminet.net/package/comm/net/AmiTCP-bin-30b2

The Amiga scene is a mix of all kinds of projects really, there is a lot of open source stuff but also commercial software. There is nothing inherent in the platform preventing open source alternatives from being developed, someone just has to actually do it

[hth313]

Is it the Amiga hardware you are after, or just some old school programming, back to basics, or close to metal programming? Retro computers, Raspberry Pi and other small development boards can be used.

Either way, you can perhaps cross compile your creations? That way your target retro machine does not need to be so powerful.

Usually people that pay for this and that, spread it out over time. That way you do not notice the total cost so much (unless you count).

[arcanist]

I do nearly all my development in an emulator. From there you can use native tools or cross-compile C/assembly from the host.

I have a real Amiga and enjoy playing games on it but the development experience just isn't convenient. At least, not without a high-end dev system and a slave Amiga to run the program. I love the Amiga for its hardware architecture and limitations and all of that shines through just fine in WinUAE.

[RichardP]

Originally Posted by hth313

Is it the Amiga hardware you are after, or just some old school programming, back to basics, or close to metal programming? Retro computers, Raspberry Pi and other small development boards can be used.

I am more into making interfaces for hardware and have a Amiga500 and 600 for the playpen. On the metal is where it has to be. My initial thought was to make a network adapter for the A500 for the trapdoor slot. starting simple. (so I thought)

Anothing thing I had in mind was controlling a Gotek using the clockport (Set ADF image from Workbench or something cheezy like that.



Richard

[Niklas]

Originally Posted by RichardP

My initial thought was to make a network adapter for the A500 for the trapdoor slot. starting simple. (so I thought)

Hi Richard,

I have also considered making a network adapter for the A500 trapdoor slot, and accompanying software. Our solution is a bit more general, as it involves a Raspberry Pi acting as a kind of co-processor to the Amiga. The hardware is working, but I haven't gotten around to writing the the network driver for it yet. You can see a couple of images of what is working in this post: http://eab.abime.net/showpost.php?p=...8&postcount=13

As far as I have been able to figure out so far, there are two ways to implement network support: either as a SANA-II driver that is used by a network protocol stack such as AmiTCP, or by implementing the bsdsocket.library interface (as described here: https://wiki.amigaos.net/amiga/autod...socket.doc.txt). It seems to me that implementing bsdsocket.library is more direct and should be simpler, especially as I'm forwarding network calls to the Raspberry Pi and therefore I don't have to re-implement the semantics of the BSD socket calls.

However I'm not sure if going the bsdsocket.library route limits the amount of software that can use this solution. I don't think so, but it would be nice to get some confirmation on this.

[RichardP]

Originally Posted by Niklas

Hi Richard,

I have also considered making a network adapter for the A500 trapdoor slot, and accompanying software. Our solution is a bit more general, as it involves a Raspberry Pi acting as a kind of co-processor to the Amiga. The hardware is working, but I haven't gotten around to writing the the network driver for it yet. You can see a couple of images of what is working in this post: http://eab.abime.net/showpost.php?p=...8&postcount=13

As far as I have been able to figure out so far, there are two ways to implement network support: either as a SANA-II driver that is used by a network protocol stack such as AmiTCP, or by implementing the bsdsocket.library interface (as described here: https://wiki.amigaos.net/amiga/autod...socket.doc.txt). It seems to me that implementing bsdsocket.library is more direct and should be simpler, especially as I'm forwarding network calls to the Raspberry Pi and therefore I don't have to re-implement the semantics of the BSD socket calls.

However I'm not sure if going the bsdsocket.library route limits the amount of software that can use this solution. I don't think so, but it would be nice to get some confirmation on this.

I was going to use an ESP32-Wroom32 device as a network MAC/Phy. Allowing the ESP32 to manage Wifi+Bluetooth, all frames would be passed to the Amiga... This would require an TCPIP stack. That was my first thought as I want the same device to run on an Acorn Archimides.

If the TCPIP stack was a problem on the Amiga, then my plan B would be to use the IP stack on the ESP32 and just pass the FileDescriptor pointers to/from the ESP co-processor.

Speaking from little knowledge, The BSDSocket library is on-top of the IP stack.. which in turn is on top of the SANA-Driver.

I think you are correct in your implementation for an offloaded IP stack *Although* the SANA driver requires less changes.. it should have an INIT,CLOSE, READ, WRITE, INTERRUPT and STATUS type API.. which is easier to work with.

Richard

[Niklas]

Originally Posted by RichardP

I was going to use an ESP32-Wroom32 device as a network MAC/Phy.

I had a look at the datasheet for ESP32-Wroom32 and it looks like a nice little device. One thing that I noticed is that there are 24 available GPIO pins on the ESP32-Wroom32, which might be a bit on the low side if you want to avoid glue logic.

The Amiga custom chips expects there to be a 256k x 16bit DRAM chip on the other side of the trapdoor expansion. The DRAM bus has 16 data pins, 9 address pins, CASL, CASU, RAS, and WE, so that adds up to 29 pins. Then the trapdoor expansion also has pins to connect a real time clock (RTC), which uses 4 address pins, 4 data pins, CLKRD and CLKWR, so that's another 10 pins; but those you may not be interested in using.

What we do is that we have an Intel MAX 10 FPGA that is connected to the pins on the trapdoor expansion (via 5V to 3.3V voltage level translators) and then the FPGA is connected to the Raspberry Pi via SPI.

Originally Posted by RichardP

I think you are correct in your implementation for an offloaded IP stack

I think it should fit well with the design we went with.

The design we have is fairly flexible, since both the Amiga custom chips and the Raspberry Pi can read from and write to a shared memory. The video player that can be seen in one of the images I linked to works by the Raspberry writing bitplane data directly into the shared memory that the Amiga chipsets access directly, so playing video is done without any involvement of the Amiga CPU. Other things I have implemented are: RemoteWB (the Amiga Workbench writes its bitplanes to the shared memory, and are then read by the Raspberry, which are converted to a normal image file made available through a WebSocket to be read from a web browser, and any mouse or keyboard events in the web browser are forwarded in the other direction, so that Workbench can be controlled from that web browser somewhere on the Internet; again without any extra load on the Amiga CPU), a filesystem driver that reads and writes files to the sdcard on the Raspberry, and a utility called 'pi' such that from the AmigaDOS command line you can type "pi gcc prg.c -o prg" to run gcc on the Raspberry, and then the resulting binary is immediately available on the Amiga through the filesystem driver.

Originally Posted by RichardP

*Although* the SANA driver requires less changes.. it should have an INIT,CLOSE, READ, WRITE, INTERRUPT and STATUS type API.. which is easier to work with.

It seems that implementing the SANA-II interface instead could be better suited to your design.

[RichardP]

Originally Posted by Niklas

I had a look at the datasheet for ESP32-Wroom32 and it looks like a nice little device. One thing that I noticed is that there are 24 available GPIO pins on the ESP32-Wroom32, which might be a bit on the low side if you want to avoid glue logic.

That is true on the pin count (its a major downer!) , I was thinking of using shift registers for data latching.. or even a SPI based bus expander. May go for dual port RAM .. but that is all new to me :P

[Olaf Barthel]

Originally Posted by Niklas

As far as I have been able to figure out so far, there are two ways to implement network support: either as a SANA-II driver that is used by a network protocol stack such as AmiTCP, or by implementing the bsdsocket.library interface (as described here: https://wiki.amigaos.net/amiga/autod...socket.doc.txt). It seems to me that implementing bsdsocket.library is more direct and should be simpler, especially as I'm forwarding network calls to the Raspberry Pi and therefore I don't have to re-implement the semantics of the BSD socket calls.

However I'm not sure if going the bsdsocket.library route limits the amount of software that can use this solution. I don't think so, but it would be nice to get some confirmation on this.

Some thoughts...

The bsdsocket.library API gives the appearance of being the simpler route because it is an abstraction of the underlying data exchange operations, such as the buffers which fill and drain as data is exchanged, and how the clients which call these functions interact with the operating system through the library.

For example, one of the most complex API functions in bsdsocket.library is the humble WaitSelect(), which deep down shares with all other library functions a common kernel infrastructure which allows a client to wait for data to become available. This may sound petty, but this is an essential building block which cannot be easily delegated to a TCP/IP stack sitting on the other side of the bus.

It does not say so, but the bsdsocket.library API is not only an API, it also implies a session, if you will. Every client which opens the library gets its own library base which contains state information unique to the client. You cannot delegate this state information, as otherwise you would wind up with a bsdsocket.library variant which only a single client could use at a time.

My advice would be to ponder the SANA-II driver route and trust the TCP/IP stack to do what it's supposed to. For example, you could hook up a PPP session between the Amiga and the Raspberry Pi side of the system through a shared channel (e.g. shared memory). It is going to be easier to implement than to roll your own TCP/IP stack.

[Niklas]

Originally Posted by Olaf Barthel

Some thoughts...

Thank you Olaf for your comments. I noticed in the SANA-II specification revision 4 that you are quite the expert in this area :-)

I think there were two main reasons why I was considering the bsdsocket.library option initially:

1. I'm not exactly a Linux expert, and setting up the necessary routing on the Raspberry Pi to route datagrams to and from the Amiga felt like it would take a bit of learning for me. With the bsdsocket.library approach I would write a normal user-mode Linux application that communicated with the Amiga and then made the corresponding socket API calls.

2. I read somewhere that running the TCP/IP stack on an A500 takes quite a bit of memory (not sure if this is actually true), and therefore I thought I'd do as much off-loading to the Raspberry Pi as possible.

However, after reading your comments I'm motivated to investigate the SANA-II route more carefully. Learning how to set up the routing on the Raspberry Pi (I suppose I may have to create a pseudo Ethernet device, or a PPP link) should be interesting in and of itself.

[RichardP]

Originally Posted by Niklas

Thank you Olaf for your comments. I noticed in the SANA-II specification revision 4 that you are quite the expert in this area :-)

I think there were two main reasons why I was considering the bsdsocket.library option initially:

1. I'm not exactly a Linux expert, and setting up the necessary routing on the Raspberry Pi to route datagrams to and from the Amiga felt like it would take a bit of learning for me. With the bsdsocket.library approach I would write a normal user-mode Linux application that communicated with the Amiga and then made the corresponding socket API calls.

2. I read somewhere that running the TCP/IP stack on an A500 takes quite a bit of memory (not sure if this is actually true), and therefore I thought I'd do as much off-loading to the Raspberry Pi as possible.

However, after reading your comments I'm motivated to investigate the SANA-II route more carefully. Learning how to set up the routing on the Raspberry Pi (I suppose I may have to create a pseudo Ethernet device, or a PPP link) should be interesting in and of itself.

2. I have not managed to get the IP stack to run properly on a 1MB Amiga 500.. it barely runs on a 1.5MB A600

On the Linux box, you can create a basic Ethernet device - that has just memory IO's .. and then add it to a linux Bridge.
https://www.xml.com/ldd/chapter/book/ch14.html

Linux Device Drivers book is the gospel

Some sample skeleton..
https://kernel.googlesource.com/pub/...net/skeleton.c

In the end, there will be three interfaces on the Raspberry... eth0, fakeAmiga0 and Bridge0. Bridge0 will have eth0 and fakeAmiga0 devices enslaved and will behave like a network switch. ( bridge-utils linux package)

[Niklas]

Originally Posted by RichardP

Linux Device Drivers book is the gospel

Thanks for the links! I downloaded the Linux Device Drivers book as a PDF.