Similarity to TFTP

[petemoore]

Hey Simon,

It occurs to me that trinload shares a lot of design goals and philosophy with "trivial FTP" (TFTP - i.e., a very simple file transfer protocol based on UDP). I wonder if it is worth exploring the idea of adapting trinload to be TFTP-compliant (e.g. to make it possible to perform regular PXE booting of the SAM, with something like dnsmasq). There is also arguably not necessarily a lot of benefit to it either, since it is trivial to run trinload.py on any modern system. Perhaps it is just an interesting academic exercise. Anyways, just wanted to share the discovery that TFTP and trinload aren't so different, in case you are interested in adapting it. No worries if you aren't, I think I might have a stab at it anyway, perhaps both the client and server side, so you can potentially serve boot images from one SAM to another! Or from a SAM to a raspberry pi, or equally from a raspberry pi to a SAM. The endless possibilities! 🤣

[simonowen]

I hadn't really thought about the similarity with TFTP, but you're right that it's doing pretty much the same thing for the same reasons! It ended up how it is by cutting as many corners as possible, using UDP for simplicity, zero (optional) checksums, and acknowledging each packet to limit buffering requirements.

I also like the idea of it also supporting TFTP reception, with behaviour to matching the current executable code sending. I guess it could work the other way to send files back, though it might require some manual poking of address/length somewhere to set it up as there's currently no need for an interface. You're welcome to have a stab at TFTP as I've no immediate plans to do it.

The simple command mechanism was always expected to be extended. I have made a start on other commands, including support for record-level sector reading/writing. That'd allow more SAMdisk functionality such as record directory listings and record reading/writing. SAMdisk knows the used parts of the disk to reduce data transfers but it's still going to be slow for a full disk. I was undecided on whether to try and improve the protocol efficiency slightly or add some compression, and before that happened I'd already moved on to something else, as is often the way!

[petemoore]

I also like the idea of it also supporting TFTP reception, with behaviour to matching the current executable code sending. I guess it could work the other way to send files back, though it might require some manual poking of address/length somewhere to set it up as there's currently no need for an interface. You're welcome to have a stab at TFTP as I've no immediate plans to do it.

I'll definitely have a play with this, and let you know how I get on! A primary motivation for this is that raspberry pi firmware supports TFTP bootloading, and for github.com/spectrum4/spectrum4 I'd like to move development to the SAM, and it would be so nice to develop locally on the SAM, and then boot the rpi directly from the SAM. I was going to take a look at the Comet Assembler (which seems very popular) and since the source code is available, see if I could adapt it to be an aarch64 cross assembler, at least for the subset of instructions that I've adopted for the spectrum4 project.

The simple command mechanism was always expected to be extended. I have made a start on other commands, including support for record-level sector reading/writing. That'd allow more SAMdisk functionality such as record directory listings and record reading/writing. SAMdisk knows the used parts of the disk to reduce data transfers but it's still going to be slow for a full disk. I was undecided on whether to try and improve the protocol efficiency slightly or add some compression, and before that happened I'd already moved on to something else, as is often the way!

This sounds like a great idea too, I love the idea of being able to remotely access the disk on the SAM over the network, and pull/push data to it. I would also be very interested to see the additional work you've done so far. I know totally what you mean about getting side tracked with numerous other projects!

I've also taken a look at TurboMon - amazing! I am hoping to use this to help me troubleshoot some trinity interfacing code I am writing. It is early days of experimenting, but I think when I run chk_trinity to check the trinity is present under TurboMon, the zero flag is not set (i.e. reports trinity board as not present). Is that a known issue? I've only just seen it and haven't dived deeper, I can get more information if you like (e.g. work out which IN or OUT might be returning different results under emulation, etc). TurboMon looks fantastic, and will be an enormous help, especially for developing networking code! 👍

[simonowen]

Comet is definitely the best bet if you're developing on SAM. Though I'd struggle to go back to developing that way now, having got used to modern text editors and pyz80. TrinLoad was created to address the need to run on real hardware, which is good for anything not available under emulation.

I've had a look at the TurboMON source and it should pass unknown I/O requests through to real hardware. It's only disk and ASIC ports that it seems to filter for some extra behaviour. I can't remember how timing-critical the Trinity detection process is though, so maybe that's an issue?

There are a lot of things in TurboMON I would have done differently now, which would have helped it run quite a bit faster. It will be 30 years old next year so I guess that's to be expected! I did start a bit of a rework on the code, mostly to speed up the inefficient screen drawing by replacing the notepad with a text cache buffer. I'll probably roll it all together into a single source file too, rather than the separate code banks forced on me by the Lerm Assembler I used at the time.

Another reason for the re-work was to add support for "real" breakpoints. I've got a small tm_break program that is designed to work with the updated TurboMON. You'd be able to include the stub code in your own program and jumping to it would page in TurboMON with the registers reflecting the break point location, so you could continue stepping. It allows running natively up until an interesting point, and step the rest in TurboMON. Another one still on the not-yet-finished pile.

[petemoore]

Heh, so I'm torn between two projects at the moment, and maybe I'll park the SAM pxe boot and aarch64 cross assembler for now, as in reality, I would be losing a lot to move development to the SAM. I agree It is super convenient to have all the modern tooling such as qemu, debuggers, IDEs and lightning fast processors to run swaths of unit tests and push directly to github etc, so maybe developing on the SAM, although kind of cool, could just be suicide for the project.

The other thing I am working on right now is the USB library to interface with the Raspberry Pi 400 keyboard, and writing this in bare metal assembly feels like it might be biting off more than I can chew. I seem to be stuck in a never-ending trail of specifications and data sheets, and in the end all I want to do is interpret which keys have been pressed. If I ever complete joining up all the dots, I'll have to write it all up, before I forget it all!