Anonymous
User login
Please support the defense of Ukraine.
Direct or via Unclutter App
Active forum topics
Recent content
Navigation
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
Theres something really bizarre going on. I tried a few other things.
+ Added a 100nF to the reset line, just in case it was 'bouncing' and glitching/crashing the AVR. No change.
+ I changed the AVR fuses to re-use the internal 8Mhz oscillator, to rule out a problem with the 16mhz crystal. No change.
It is pretty constant, and it also is constant across 2 boards, so I can rule out the AVR..
1) If I power cycle the IIe, with no SD in slots, I see the CS being probed, then no_cards_blink() is called, the boot menu is loaded, and I can play to my heart content with the menu and all is well. I see my 'watchdog' (CS3 LED) blink. Basically, it's all working...
2) If I power cycle the IIe with a SD card in (out of 2 I have here), the CS LED stays on and never turns off, and of course, the AVR appears hung.
* Even in case #1 (avr working) if I press control-apple-reset, theres zero activity on the CS line, my CS3 (which I turn on as pretty much the first thing in setup() never light up. The AVR just doesn't start....
I have to say, it is extradinarily bizare, as the 5V is there, the clock uses the internal RC now, and the RESET line is high... It's like it's somehow crashed or hung... It still feel like it's being glitched, but, by what?
Is there *anything* the arduino firmware do before calling 'setup'? I *never* use the arduino thing, all my firmwares ever use bare metal...
Note: I have currently disabled the bootloader as well, so the reset vector is straight into the main firmware..
Ok, this is indeed odd. If the CS of the SD card stays on, then something is seriously wrong. And the SPI driver does have timeouts everywhere AFAIK, so it shouldn't get stuck there. Also, the Apple-Reset triggers the ATmega RESET line - this always has to work.
My suggestion would be to remove the card from the Apple II and first test it separately, using a reliable bench power supply. I usually remove the 74HCT00, since it is otherwise continously forcing the ATmega RESET, when its inputs are drifting (HCT's don't have input pull-ups, so when disconnected from the Apple II bus, the logic with the two inverters of the 74HCT00 cause the RESET line to be continously low). You can't easily remove the SMD 74hct00, so you'll need to externally drive the RESET line high (at the unconnected Apple II bus connector). You can also remove the ROM and the 8255 when bench testing - they are not needed then. Then test if the ATmega reliably starts - with and without SD cards plugged. And check if the RESET works reliably (using the RESET button).
A separate test on the bench simplifies tests a lot and excludes a lot of other issues (like a weird Apple II power supply etc).
So bit of progress here!
First I tried a few extra bits just to rule out problems:
+ Tried the card in a different IIe -- different PSU (mind you this one on the bench is freshly recapped, it's great) -- same problem!
+ Entirely bypassed the RES->RESET diode, wired RES to RESET via a 15ohm resistor, just to rule *that* out... same problem. I can reset the IIe from the card button as expected. Didn't teach me a lot BUT helped with the next step
+ Card on the bench, sourced 5V to the +5V rail (not VCC), same problem shows!
The really bizare thing is, RESET is obviosuly working, but the sketch doesn't start!
So flashed my bare metal blinker and... *that works* I can reset all I want...
Which leads me to some sort of Arduino init problem... it seems *something* running before setup() is crashing.... very early, OR a bit later, OR not at all depending on conditions... so I'm going to run it in debug/trace mode in *simavr* and see what the flip is going on in there...
Ok, after many, MANY hours of debug and tests, I figured it out!
Turns out the firmware was locking up waiting for SPI to complete a master transfer... Now, *normally* it cannot be happening, however, turns out the SPI peripheral on the AVR has a 'special feature' that will disable the SPI Master mode if the Slave Select (SS) pin goes low.... It's not even documented in an obvious way! So here on the m644 PB4 is SS, and is 'not configured' as I didn't need it... Turns out that pin is floating, and can trigger a falling edge in some condition, like *almost always* when we start to transfer via SPI (neigboring pins).
So that explain that it worked when powered up (different conditions for that pin!) and not otherwise... One line later to configure that pin, and all is working!
So my 'simplified' card with the reset bypass a a few removed diodes/resistors now work perfectly well all the time, I can configure the meny, boot an image etc, cool!
The card I haven't modded initializes the card but fails to talk to the menu, so there's still something to debug there, but it's a lot easier now as I can just de-mod my card one by one and as soon as it stops working, I'll know what bit is the problem!
At last! It took me *many* hours to get there, I definitely deserved a beer :-)
I spent a lot of the day writing a simavr test hardness with it's own SD card emulator, and ran the firmware thru it until it probed 2 'sd card' images and started to loop for commands, that showed me that *all was well* in the firmware otherwise. That's pretty cool, even if it's not *terribly* useful now :-)
Yes you definitely deserved a beer after all that! Been following this thread since the beginning, going to try doing a different spin on the original. Really interested seeing what issues you faced. I'll post more about my changes when I get some hardware assembled.
Congrats on the progress! It's great news!
Great project and impressive sleuthing. I really enjoy reading this kind of in depth stuff.
So, 4 working boards now. I've also just pushed some changes to the sofware to allow building a separate FWUPDATE644P updater. Well it builds, programs, verify but doesn't run! So I suspect whatever I changed to the assember to make it use bigger page is still buggy. But, getting there :-)
@MacFly, if you check my tree, there's a few changes to the build system you could review? The fwupdate now uses some special magic that passes the .asm file to the proprocessor, as the code is slightly different between 328p and 644p -- not *entirelly sure* it's the way to do things with ca65 at all, I'm not familiar at all with that tool!
If you look and are still happy, I'll pass you a PR (or, just pull my tree and cherry pick the bits you like!)
Currently a bit stuck... I have some changes to the fwupgrade program, but my 644 version hangs. It must be something pretty obvious; I simplified the program: subroutine, and it's calling code sinc ein the 644p case, we're writing 256 bytes at a time, so there's no need to update 'buflo'...
Also, the main change is that instead of writing until we reach the hard coded page number of the bootloader (644p is too big to fit anyway) I added a label to the end of the firmware, and changed hex2bin.py to generate a padded (to 256) file with just the firmware, without bootloader (that file is already generated by arduino-cli)
Anyway I'll sure I'll figure it out, but if anyone care to have a look, most at 'program:' and 'writepage:' -- the 328p version works and write pages (and of course trash the AVR) while my version just hang! Not terribly useful :-)
https://github.com/buserror/Apple2Card/blob/main/utilities/fwupdate/dan2stk500.asm
Only had a moment to look at it. But something seems wrong about the condition to find the end of the programmed/verified address range. Might explain why it get's stuck.
Orignal (for the 328p) was (for 32K of flash):
Your current Git head has that changed to:
That's not looking right. It would keep programming until the memory buffer address wraps. And "ldx #..." has no effect...
You probably wanted to do something along the lines of:
But that would still require the memory buffer to be aligned to 256 bytes - which currently isn't the case. You padded the firmware (size) - but not the start address of the firmware image in Apple // memory (?). So it could still program one more flash page than expected: this probably wouldn't be an issue for the 644 (since we're not using all of it), but it would be for the 328p, since the entire flash is used - and writing an extra block would result in an attempt to overwrite the bootloader area.
Thanks for looking, it's definitely my 6502 being top rusty! I didn't remember one could CMP the content of an address, I've done way too much ARM for my own good :-)
I know, I'm wierd like that, but since I didn't find the bug, I spent some time writing an emulated DanII 'simplified' in linappe, and debugged fwupdate like that!
2023-08-28-145620_1250x881_scrot.png
I've just pushed a Pull Request with all my current changes, seems all good; going to test IP next, i've finaly caved in and moved a IIe to my main office, saves the dozens of trips to the 'museum' with the laptop :-)
First of all, many thanks to Dan for creating this project and making it open source! Also thanks to MacFly for his on-going contributions to the Apple /// adaptations!
I recently had the crazy idea that I could build this on a protoboard and greatly simplify things by using an Arduino Nano (same Mega328P chip) and a couple of SPI based "Micro SD Card Adapter" boards I had laying around. I started down that road, but it is still a lot of wiring that I don't have much patience for anymore. Discovered I could get Dan's already designed PCB from JLCPCB for next to nothing (without the gold finish) and delivered in a week. My revised approach was to include the Mega328 chip and support circuitry on-board, but I didn't load any of the parts associated with the uSD cards. Instead, I put zero-ohm resistors in for R27 and R28 and repurposed the Wiznet socket (J6) to support a little daughter card with my two micro SD adapters. Now I only have to make a dozen connections. The micro SD adapters already have voltage regulators and signal level conversion. Used a home-made (Arduino Mega based) EEPROM burner for the firmware and an old Arduino Uno to program the Mega328 chip. Formatted and loaded up a couple of 16GB flash chips - and it seems to work flawlessly! Yes, the way the daughter card and micro SD adapters stack up I can't put anything in the adjacent slot, but I can live with that for now. It was very easy to wire this way.
PCBassembly1.jpg
PCBassembly2.jpg
All those blocks available!
ConfigAndFiler.jpg
A very interesting idea! It would be interesting if someone created a daughter PCB that could be used in place of your hand wired proto board. That would largely eliminate one of the tougher parts of building this board for a lot of people, that being soldering of the SD card slots onto the PCB.
There are just so many cool options using this basic design in slightly different permutations!
The daughter card was largely a proof-of-concept, although I agree soldering the SD card slots didn't look like fun. It doesn't hurt that it eliminates soldering a lot of other components too. In keeping with Dan's original intent, I tried to just use parts I had laying around. I only had to buy the 82c55 (and the HCT parts, but LS probably would have worked.) The I/O slot configuration is a bit different on my Apple /// - longer (than the current PCB) and taller. If anything, a layout that put one or both of the SD slots at the back end would be better for me and the few other A/// users out there. Sadly, my PCB routing skills are rudimentary at best.
@BusError: Congratulations on getting the x44 variant up and running! The pull request looks good. I have to have a closer look when merging. Not sure if I'm going to find time this weekend. I also need to clean-up my local repo, since I've just been pushing ahead with a number of changes for the Apple ///. There were a few things I wanted to have ready in preparation of an upcomming event. (I planned a smaller addition, then somehow end up in the middle of a bigger project, including two new smaller side projects... Sounds familiar, anyone? :) ).
@retro-tinker: Really nice to see it being used on the Apple ///. And I'm always in favour of any kind of tinkering... Soldering the MicroSD slots isn't really near as difficult though, as it might seem. You probably have a few more PCBs from the batch you ordered. You might still want to try it with one of the other PCBs. The trick really only is to use enough flux when soldering the SD card pins.
And for those living in Germany or close by: I'm going to participate in the Classic Computing 2023 (near Frankfurt, last September weekend). To no one's surprise, I'll be bringing an Apple II, Apple ///, DAN][ controller cards, FloppyEmu Apple III adapters and other stuff. And I've just been improving the support for the /// (sneak peak video below). And for those living abroad or on the other side of the planet: the event is just a 15 minute drive away from Frankfurt airport... :D
So, here's a video with what the Apple /// can now do:
Sneak peak: DAN][ on the /// - No floppy!
This includes a few things, which I haven't yet pushed to github, and also require a bit more documentation for the setup. Also, it's not just my work alone: it's a combination of stuff for the DAN][ controller with the soshdboot project by Robert Justice. But as you can see, it works nicely together now... :)
I guess it wasn't so much that I didn't want to solder down the uSD sockets as 1) I wanted to avoid all the diodes and resistors needed to do what seemed like a clumsy attempt at VR and level shifting and 2) I already had the micro-SD modules in my parts bin. It didn't hurt that the Apple /// has more space for an I/O card so I knew any kludge I threw together would fit. Right now I'm waiting on a 10 pin extension cable so I can try putting the whole daughter card outside the computer and allow for easier SD card swaps. I can also add another header (to my daughter card) for a Wiznet board that can coexist with the SD cards.
I could use some help troubleshooting FTP on the Apple /// - starting with setting the IP address. Everything else seems to work fine on my DAN2 card, but I've added a Wiznet W5500 module and I can't set an IP address. At power-on the CS3 activity LED blinks once. The green indicator on the W5500 ethernet connector is flashing sort of randomly, yellow is on. When I press "I" in the ("Dan2On3") config menu, it lets me enter an IP address, then says "OK" and goes to the "insert bootdisk" screen. If I restart with the config disk again, there is no IP address displayed, and nothing at my selected IP has shown up in the router address table. I have tried building the Arduino code with both FTP and Ethernet enabled, and just with FTP. Behavior is always the same.
If I boot into Apple 2 emulation mode and do PR#1 from the (applesoft) basic prompt, it does basically the same thing. I can type in an IP address, but then it bails out into the monitor with: 0803- A=00 X=10 Y=01 P=36 S=E6If I dump the 0800 space it is just all 00's. (And the IP address still isn't set/recalled when I restart the config menu.) Maybe not too surprising since emulation mode probably doesn't support a boot rom.
Nothing that looks like a MAC address on the Wiznet module (https://www.amazon.com/dp/B0BMPK1C2K?psc=1&ref=ppx_yo2ov_dt_b_product_details) so I don't know how to assign a static IP in the router. I've also tried both Wiznet modules - no difference.
There are no other I/O cards in the Apple /// (at the moment.)
Any ideas? Thanks!
The IP address in the main SD card menu is only shown if
a) the FTP server is enabled (= when an IP address was configured - except for 0.0.0.0, which disables the integrated FTP server)
b) the Wiznet module is plugged and initialized.
So, you already did configure the IP address. The setting is saved permanently. So this leaves some kind of issue with the WIZnet module. The other observations you made are normal: after entering the IP address it will just reboot / try to load the currently selected volume - or show the "insert bootdisk" message, if the volume cannot be bootstrapped on the Apple ///.
The Wiznet module shares the same SPI signals as the SD cards (MISO, MOSI, CLOCK) - except for a separate CS line. Maybe try removing the SD cards - and see if the Wiznet module works without them. Also try unplugging your SD card adapters. I'm not sure how these adapters handle the SPI bus, when the SD cards are not in use. The signals (MISO, MOSI, CLOCK) must be "open"/unused unless the CS1 or CS2 signal for the SD cards are active (low). There is a certain chance that these adapter somehow interfere with the SPI bus (pull-ups, "bus hold logic" or whatever). So testing the WIZnet without the adapters may be a good idea to narrow down the cause.
Also note that the WIZnet module also is a 3.3V device. Its I/O signals are 5V tolerant though, but needs to be powered with 3.3V only. Just mentioning this since you replaced some of the other logic with the SD card adapters.
Once the Wiznet module is found (basic communication between ATmega and Wiznet works), then the currently configured IP address should also be displayed in the main menu.
BTW I have pretty must the same problem on IIe with the 644 card... I set the IP address with "I" and, reboot (no IP displayed) and nothing happens. The module works, as I can use it with ip65 (dhcp, ping etc), but I can't get the FTP to work. I blamed my recent changes but since ip65 works...
Thank you for the tips. The Wiznet module initializes and I see the "FTP/IP:" message in the main config menu IF I remove both of my SD modules (removing just the SD cards had no effect.) Just realized the MAC address for the Wiznet module is in the config.h file.
J6 only provides +5V, and there are no voltage dividers on any of the SPI signals going to J6 that I can see. The Wiznet module I have has a 3.3v regulator and a 5V pin (where J6 expects it to be.)
It is interesting that the 2 SD modules can co-exist without interfering with each other. These modules also have a 3v3 regulator and 74LVC125A buffer/level shifters. It's possible the OE on the MISO pin isn't connected to CS. I'll have to probe this with a 'scope since I (sort of) know what to look for now. I hope I can just get away with some pull-ups on the SPI lines.
WizModule-back.jpg
Found another SD module (on Amazon) that looks identical to the ones I have and has a schematic. Traced it out and the design is the same. The MISO line never tristates because the Output Enable on that buffer is hard wired to ground. Of course it is a very small SOIC and pulling 1 pin to reroute the signal to ChipSelect looks very difficult. Looks like I need to add an external buffer chip.
My experience with a lot of these modules on an Apple II is that you need to use a 74*245 to make them work reliably.
The 74x245 is an octal transceiver with a single OE pin; doesn't really work in this case. I need to tristate the MISO pin on two different modules - so two different enable pins. A 74x125 probably would have been ideal, but I don't have any on-hand. I do have a 74LS367. That has 6 3-state buffers, controlled in 2 groups of 3 so I can use one buffer from each triplet. I did in fact wire this up but (there's always a "but") the config screen only shows SD1 and the Wiznet module. No idea why SD2 doesn't show up, but the chip select LED on SD2 doesn't seem to blink anymore (or if it does, it is very brief.) I'm going to pull the '367 and verify it's working as expected.
I tested the LS367 stand-alone, and the buffer I had randomly chosen for SD2 was dead. Rewired to use a different one in the triplet and now I see both SD cards and the Wiznet in the config program main screen. More testing to do though. System utilities can read all the files/directories but BOS dies with "system failure #1" (or something like that) as soon as it tries to access ".profile" (renamed .dan1) and I can't get filezilla to connect. I did apply the max simultaneous connections = 1 setting mentioned elsewhere.
I noticed the Wiznet LAN status LED's doing the weird alternating blinks thing when one or both SD modules was installed, even with the external tri-state buffers on MISO. Without the SD modules, the link LED (yellow) was on and the activity LED (green) was flashing. Just for fun, I ran a wire from the ATmega328 reset pin to the Wiznet reset pin (the empty pin 5 on connector J6.) Seems much happier now - I don't get the blinky LEDs and the router consistently sees the Wiznet's MAC & IP addresses - with both SD modules connected too.
Filezilla just "fails to load a directory"
From a linux command line I can get this:
ftp screen.jpg
Shouldn't it list some volumes here?
I think you need to issue the PASV command before the LIST command:
pasv.png
My (linux) ftp must be different. It defaults to passive mode and most of the commands in your example are slightly different here.
$ ftp -n 192.168.50.220
Connected to 192.168.50.220.
220 Welcome to DAN][, v3.2.0. Apple ][ Forever!
ftp> pasv
?Invalid command.
ftp> passive
Passive mode: off; fallback to active mode: off.
ftp> passive
Passive mode: on; fallback to active mode: on.
ftp> pwd
Remote directory: /
ftp> cd SD1
250 Ok
ftp> pwd
Remote directory: /SD1
ftp> list
?Invalid command.
ftp> ls
421 Service not available, remote server has closed connection.
This is not Linux, this was just me connecting to ftp.apple.asimov.net with a simple text based FTP client. For passive mode a second connection needs to be established, because the result of the LIST (or LS) command will come though that connection.
Best thing to do is install Wireshark on your Linux machine and see what is happening.
Thanks for helping me understand what's going on! Unfortunately, I'll be away for a week or so; further troubleshooting will have to wait.
The error messages with the closed connection sounds a bit like the Wiznet maybe made a reset.
But first try to list the root directory:
If that also doesn't work, then you have an issue with the "data connection" only (Ethernet).
Otherwise, if that does work. But only the "ls" in the SD1 or 2 directories doesn't work, then you still have a hardware issue with the SPI bus. Accessing the SD card via FTP is the ultimate test if SPI works properly. This will cause the SPI bus to be busy communicating with the SD card and the Wiznet "back to back" and at full speed. As described before, SD cards and Wiznet share the same bus. So if there were still issues with one device not properly releasing the bus, and somehow interfering with the other, then the alternating access to SD cards + Wiznet may not work.
ls at the root (/) level gives the same 421 Service not available message.
Ok, at the root level it doesn't talk to the SD cards. This suggests a general Ethernet issue - not related to SPI access to the SD cards.
The FTP directory listing (just as file uploads/downloads) uses a separate data connection. FTP servers provide a separate port for these operations. The FTP server advertises the port number to be used to the client. The tiny implementation in the Arduino always advertises the same data port. It's using port 20 - but you can change that in the config file. Are you sure your firewall isn't blocking this port (e.g. did you configure your firewall to allow outgoing FTP command requests on port 21, but not allow port 20?).
Otherwise run ftp with debug output enabled (ftp -d ...) - and show what it is actually doing.
The error code 421 isn't set anywhere in the FTP server implementation. So it's an error which is generated by the host (FTP client). The debug log might explain why...
I could have sworn I've done successful ftp I/O in the not too distant past with "regular" websites - but that may have been with a different router. I'll check the settings when I get back to my workshop next week. Thanks for the help!
This sick contraption is... linapple simulating a 82C55 based DanII Card (with ROM) bridged over (unix socket) to my own simavr emulating emulating the 82C55 other side, a SPi SD card (mapped to /dev/sdd) AND arduino firmware. And it works
I did that to *fully* test my 644 firmware, I have precise timing charts on the AVR side via simavr VCD support
2023-09-10-083021_1056x841_scrot.png
That is pretty cool.
I have just tried to install Apple Works 5 onto the SD card in the Dan ][ drive and have hit a problem, which may be me being silly and not seeing the obvious answer.
The Apple Works 5 disk images I downloaded 10 in all, 140k images ,are the original disks and are expected to be loaded via Drive 0 floppy disk. I can put each image onto the sd card VOL00.PO to VOL09.PO no problem and set up the boot option as first drive D2 VOL00.PO which happily boots and then asks for the next disk to be put into the Drive as you would on a floppy.
If I now do a hard reset and change the boot sequence to D2 VOL01.PO I have now lost the memory image of VOL00 that was loaded into the apple memory.
So my question is there a possibility that in future upgrades to software that it would be possible to use a keyboard sequence to change the volume number on the fly so that it would seem like you are just putting the next disk in the primary floppy drive.
Yes I know I could make 10 floppy disks from the images but it would be much more elegant to be able change a volume number in some way.
I am also thinking it would be nice if the users could post their Dan ][ images to help the less gifted of us. I would dearly like an image for booting CPM from a prodos drive on the DRan][ card.
Regards
Crusty
Changing volume images on the fly isn't quite so easy. On the Apple II there are no "resident drivers" which could be installed in the background to listen for some secret key combination. If you wanted to control the card while an application was already running, you would need to attach extra hardware buttons. This would allow you to generate a signal to the card, requesting to swap volume images etc. This is how "FloppyEmu" does it, for example.
However, concerning your specific request, there is a much more elegant solution for AppleWorks (and probably other similar software). I'm also using AppleWorks (an older version though, and also the German edition - so you wouldn't be interested in my specific image). But what you do with AppleWorks is to create one bootable ProDOS volume (of several MB -32MB is the maximum supported). Then you copy the contents of all AppleWorks disks to this single volume. And then you use this single volume image which already contains everything. And it just works: no more disk flipping. AppleWorks will never bother you again with "Please insert disk <xyz>" messages. It will just boot and run.
But I agree: it would be nice if such harddrive images of preinstalled software (like AppleWorks) were conveniently available for download - not just the individual original disks. And such images don't even depend on the DAN][ card. All ProDOS interface cards use the same volume image format (well, the ProDOS format, obviously...). So there is no need for a "DAN][-specific" volume collection.
And not sure, but maybe someone has already created such a ProDOS (harddrive) volume image with AppleWorks installed - and uploaded it to a site like "asimov" or similar...
@MacFly Thanks for the very quick response. I shall have another go with just putting all the files associated with AppleWorks on one Disk Image so far I have had mixed sucess with this approach I think I might try V3.1 instaed of V5.
I need some form of programme using the mouse as I am starting on my first iteration of a usb mouse card and I need to see if I am getting my mouse card interrupts and responses in the form that mainstream programmes need.
Yet again thanks to Dan and yourself I have started to use my apple and not worry about where to get floppy disks. My BBC Master long ago lost its floppy for a sd drive and also in the background a new UK101/Ohio superboard is being built to my own specification with SD drive.
Long live the 6502.
Many thanks for the pointer regarding the images for AppleWorks.
I must have had a senior moment when using Cider Press while copying to my own image, I lost all the subdirectory structure .
Once I had that error sorted then AppleWorks works.
It appears there is some conflict with an ftp server built into my router (to access its USB port.) I am not able to turn that off, so I changed the command port to 2121 and the data port to 2120 in the config.h file. I was able to transfer volumes from the Apple /// at 196.2 KB/s - so slightly less than 1.5 minutes to get 16MB. (And less than a second for 140K.) CiderPress is happy opening the downloaded volumes, and windows FileCompare utility shows no differences between the files on the SD card and the downloaded ones. Haven't tried a file upload yet...
Never thought I'd see a LAN cable sticking out of my Apple ///.
Nice! Glad it's working now. Did you have to change both ports - or would the changed data port have been enough?
The FTP (command) port 21 is still the current standard - just like http port 80. Port 20 is also a standard for FTP data, however this is from back in the day when "active" FTP connections were used for data (basically a TCP connection opened in reverse direction, from the server to the client). This is barely used these days, since "reverse" connections are normally blocked by firewalls. And, looking into some FTP specs, for "passive" FTP it's indeed the standard to pick a higher port number for the data connections. The number doesn't really matter, since the user never needs to manually configure it. Current FTP servers even just pick a random port from the dynamic port range.
The DAN ][ FTP server uses "passive" data connections, of course, hence it probably makes sense if I change the default port for the FTP data connection to a higher number...
I tried changing just the data port, first to 8020 and then to 25 but I didn't have success either way. Wiznet didn't even seem to initialize correctly at 8020, and I got the same "421" error with 25. I suspect one or both of those may have had to do with the (Asus) router firewall. I got the 21xx idea from searching around the 'net a bit and someone else had success with this. I am a little dissapointed that I couldn't disable the router's ftp server or its claim on ports 20/21, even though I don't use its USB port for anything.
I also updated to the latest release of the Apple2Arduino code, which feels even faster than before!
I've only done a 140K (Binary) copy to an SD card volume, it ran at 135.76 KiB/s.
Next task is to build an interposer card to put the boot rom into a 28c64 eeprom.
Yes, there was some progress on the Ethernet support. I customized the stock Arduino Ethernet library. Dropped the support for older, obsolete Wiznet modules (before W5500), which we aren't using with the DAN][ anyway. This removed several delays and workarounds, which were only required for obsolete modules. Ethernet initialization is quick and smooth now. The hickups are gone, which could be noticable when launching the menu while Ethernet was being initialized. And it saved a lot of code: we now again have space for more features...
Concerning the boot ROM for the Apple ///: haha, I also made an adapter recently (see here). One of the side projects for the Apple ///. I wanted an adapter to use "normal" DIP 28c64, so I can play with the Apple ROM. The adapter tries to fit the EEPROM in the tight/sloped space below the keyboard - by offsetting it towards the rear. I made measurements and was absolutely convinced it would fit. But I still had problems. I eventually managed to make it fit with some tricks, but I do *not* recommend this design. It was good enough for my tests. And it will work for next week's retro event, where I will also be showing Apple /// booting with DAN][. But my new plan is to redesign the adapter by rotating the EPROM by 90 degrees (so its rear longer edge sits flush with the memory/sandwich board - and the EPROM sits exactly between the CPU and the PROM - so doesn't hinder cooling).
Another option, of course, would be to use SMD components. But well... I wanted a normal DIP ROM in my Apple ///. :)
On the positive side: I got to relive some of the experience (headaches) which Apple engineers suffered 40 years ago. According to the history books, the Apple /// chassis was finished long before the PCB design. The tight and twisted remaining space for the mainboard was one of the issues which troubled the Apple /// project.
A3ROM_adapter.jpg
Haha, indeed. But it was designed as a "business computer" so a nifty Ethernet port is well deserved. :)
Here's what I did for my setup. The Wiznet module fits exactly in the free slot space above the DAN][ controller card. I made 3D-printed parts to attach the module to the slot - plugged from the outside, secured with a bracket from the inside.
A3_DAN2_3Dprint.jpg
A3_DAN2_inside.jpg
A3_DAN2_rear.jpg
Designing the 3D-parts was surprisingly complex. The Apple /// didn't intend expansion cards to have any kind of mechanical support at the rear - there are no screws, nothing where a slot bracket could be firmly attached. And one would quite naturally expect such slots to have a simple rectangular shape. Oh no! Nothing was easy with the heavy Apple /// aluminium-cast case... :)
The slots have the shape of a trapezoid. They are narrower at the bottom, wider at the top. And the thick walls between the slots not only become slimmer - they also become less deep (so they get narrower in two dimensions). And, of course, the shape of the outer walls of the two outer slots differ to those in the middle...
Anyway. The bracket fits well (in the two inner slots). I'll be adding this to the DAN][ github project, if anyone else needed a bracket for the Apple ///.
Very clever and it looks great!
Is there anything odd about the wiring to the boot rom socket B9? I tried replacing it with a 2732A eprom I got off ebay and I get a screen full of gibberish and (obviously) no boot/disk activity. I verified the eprom contents match the 341-0031.bin file I got off the internet. My eprom programmer will not read the OEM boot rom - it just says "all ones". I put the original back in and all is well.
Can the fuzzy on line schematics be trusted? It looks like Apple uses the 2732's chip enable line (pin 18) as A11 and the eprom's A11 line (pin 21) as CS0/ROMSEL2. If so, I don't see how an e/eeprom would ever work in that socket.
I guess I can answer my own questions after some more digging. It looks like the mask rom (in my computer at least) is a Synertek SY2332. Digging up an old catalog from the early 1980's shows the pinout is the same as the schematic says. Pins 20 and 21 are chip selects (the mask allowed you to specify high or low true) and pin 18 is A11. Thus, not pin compatible with a standard 2732 EPROM.
I verified with an arduino based reader that pin 20 must be low (ok since it maps to Vpp/E\ on the 2732) but pin 21 (the other chip select) must be high and A11 is on pin 18. Ugh.
Pages