E474

Hi @dmy, Actually, @x=usr(1536) might have a simpler solution, you just need to use a Mac program that lets you access "sftp" files. I did a quick Google and found this list, though the webpage is a bit old (I don't know anything about Macs though): https://apple.stackexchange.com/questions/25661/whats-a-good-graphical-sftp-utility-for-os-x The problems with username/passwords is probably down to the smbpasswd command. You need to: cd /etc/apache2 sudo smbpasswd -a pi But actually use the user that owns the tnfs directory, not the pi user (the user you want to log in to via terminal).

Probably the easiest way is to setup Samba on the Raspberry Pi. See (one of many tutorials on the net) : https://pimylifeup.com/raspberry-pi-samba/

I think the cable cost about a Pound Sterling to make, which was the cost of the logic level shifter from eBay.co.uk (probably the best value Pound I ever spent on my retro journey!). I built it by following this blog post: https://blog.lmorchard.com/2018/03/01/sio2pi/

If you have something like a Raspberry Pi, you can make an SIO cable with a 5V <-> 3.3V Logic level shifter board, and 3D print the SIO molex connector (you just need to figure out how to do the crimp connectors, though you can salvage them from old ATX style PC PSUs). Then just use FujiNet-PC or atariserver on the Pi to serve ATR/ATX images.

Hi @TZJB, Thanks for the feedback on DUMP1050! Good to hear that it did dump the Lazer ROM when set up as a boot floppy, single drive - this might be the easiest way around the data corruption issue, though I think DUMP1050 still needs updating with error handling, etc. I think I need to make it a bit clearer that it only dumps the Happy/Lazer ROM so I'll also add this to the documentation/description (when I get time to update it). Btw, I saw in the new thread you had started that you had used the Happy Utilities sector copier, have you tried the Lazer utilities disk - I posted a copy of it a while back, see:

Hi @TZJB, IIRC, the Fujinet uses high speed I/O when loading its config program, so the drive may already have been set to ignore commands, etc. Simplest path is to get to the "Cannot read command table" bit, and then power cycle just the Lazer drive and try to dump the drive again (so don't reboot the 800XL, just hit #4 again). You can also try making a physical Dos 2.5 boot disk, and copy the utility on to that - it should be OK if you use the same drive to boot and dump the data to (you'll need to change the drive number from #4 to #1 in the above example). This cuts the Fujinet out of the loop, which makes things simpler to trouble shoot (I would unplug it from the SIO chain, and only have the Lazer drive you want to dump the ROM of on the SIO bus). Also, maybe verify that the Lazer utilities disk recognises the drive as a Lazer drive (maybe check in the same "only the Lazer on the SIO bus" configuration?). Hope this helps!

Hi @TZJB, I haven't had time to fix it, the bug can happen with high speed I/O (it's the Happy corruption bug). If you have a stock 8-bit computer (one that doesn't have high speed I/O added in to the OS in as custom firmware), and just use the Atari DOS 2.5 on the ATR you should be fine, but I would boot the ATR, dump the drive ROM, then reboot everything and power cycle the drive as code is uploaded to it as part of the ROM dump routine. Also, don't use a high speed DOS like SpartaDOS, etc., with DUMP1050. The ATR can be downloaded from the DUMP 1050 github repo. DUMP1050 is very "rough and ready", as it's not much more than a wrapper to save memory read from the drive using the routines from the German publication "Atari Magazin". Hopefully I will have time to revisit my various Atari projects later in the year, but I know am going to be very busy for the next few months with more pressing matters. Any feedback would, of course, be appreciated though.

It was more trying to illustrate the idea of there's lots, and then there's really *LOTS*. Bizarrely, when I did a quick YouTube search for "Lots", I stumbled across this clip, which includes possibly the same actor, though in a different role:

Hi @TZJB, Yes, I'll try and dump the ROM at some point going forward (I wrote a utility called DUMP1050 for this, but I need to add a workaround to the Happy corruption bug fix for high speed code, which is still on my to-do list). The PCB looks very similar to a Happy "clone" I picked up from The Netherlands (see below), which actually failed the Happy memory test (IIRC), but I think it was more to do with a hacked ROM than anything else (but I haven't checked so am not 100% sure). I think I will leave the wiring "as is", even though it looks a bit iffy, it will probably actually last a few more years (at least). Thanks again for the help!

Meanwhile, over at Best Electronics:

Good news everyone! I soldered the white wire to the middle pin of the switch, and everything works! With the light off I can't write to a write protected disk, with the light on, I can write to a write protected disk. To be honest, I'm a bit skeptical that I actually want to have a drive that can ignore a write protect sticker, but I'm pleased that the drive works OK, and the switch is fixed. It actually looks like it is a Happy clone - I tried it with a QuickOS disk (see above), and it reported an Unknown U.S. Doubler (which it obviously isn't), but could also get the Happy Command Table, so I think that's what it is. I will try out the Happy and Lazer utility disks to see what they report, but the drive was quite willing to format a single density disk and write Dos files to it, so I'm counting it all as a win. I re-soldered the connectors to the header pins (thanks for the info on the pin numbering on the board - I saw 1s next to each block apart from J11 - but I figure it never hurts to ask), but is it worth putting something like hot glue on the wires to keep them apart, or , could I have wired up the middle switch pin from any ground, or did it have to be the ground next to the black wire (I'm assuming any ground would do)? Thanks again to @_The Doctor__ and @TZJB and everyone else who commented.

Hi @_The Doctor__, Thanks very much for the help, I'll take it as read that it's correct, but any chance of a simpleish explanation? I had a look for Single Pole Double Throw Switches (for example: https://www.elprocus.com/spdt-switch/), and it looks like the middle pin on the switch is the Common pin - and that's what the white wire should be soldered back on to. Is it one (electrical) path through the switch means the reading from the write protect sensor is always obeyed, and the other path through the switch means the sensor is ignored (either the disk is always writeable, or never). Looking at the second schematic in @TZJB's post above, J11 pin 1 is either GND at header position #4, or goes off to JP6/5 at header position #1 (I'm not clear how schematic connectors 1-4 on JP11 map to the headers on the PCB)? I'll try and solder up the wire this weekend (e.g. tomorrow), but I'd like to learn a bit about why the white wire goes to the middle pin on the switch too. I appreciate the help regardless!

Hi, Thanks for tagging me @mnemo! I'm not sure what the exact status of ATRMaker is, but I remember it was mostly there, but I ended up making a newer version which was quite heavily re-factored, but also not quite finishing that. It's been a project that I've actually wanted to get done, but life always seems to get in the way, or I get distracted with another "interesting" project. Unfortunately at the moment I'm getting crushed in real life, since about the same time the PicoCart design got published, which is something I have all the parts for, and no time to do anything with (and why I've pretty much stopped posting recently). Anyway, I made a new repo for the latest version of ATRMaker ages ago, it's still private, though I will try and make it public with a note saying it's a work in progress, and post the link here. It did actually get 5th prize in the ABBUC software competition (and it was very exciting getting it uploaded in time), but apart from wanting to get it finished, I did actually receive some prize money, and feel a bit of a moral obligations to (eventually) ship a working version. Unfortunately I know the next few months will also be very busy, so there isn't a quick fix. I have a vague memory that MyCopyR might have a retry on bad sector option, but I'm really not certain as I haven't used that in years either.

The minute hand on this watch is minute.

I tested the mystery mod drive (2nd drive above) with @Zolaerla's QuickOS disk detect routines - see: and it came up as an Unknown US Doubler, or an Unkown 180/1050, depending on the right side switch position. @xrbrevin - the Lazer mod is a bit bigger than the mystery mod as the Lazer includes a 6502. My first post on AA was actually about my Lazer drive which had developed read/write problems, and also ended up with a loose wire problem. See: I think for the first drive with the loose wire, I will just un-solder the switch assembly as I think it will take me ages to figure out where it should be connected, and I would rather test the drive first. Thanks again everyone for the help!