The Dan ][ SD card disk controller

Yes, the pinout of the Apple /// ROM slightly differs to the 2732. You can either use a TMS2532 EPROM, if you can still get one. Otherwise you need a little adapter to swap pins.

I made this one. It works with 2764/2732 EPROMs (and 28xx EEPROMs). But as described above, I need to revise the PCB, since it still didn't quite fit mechanically.

I was wondering if you ever looked at pin 21 (CS0/ROMSEL2  on the schematic) with an oscilloscope or logic analyzer? Is it always high? The data sheet for the TMS2532 is pretty vague about what happens if that pin (Vpp in the datasheet) is low. It looks like only pin 20 is used to enable/tri-state the outputs.

I've looked at the schematic for your eprom adapter and pin 21 is connected to A12 on the eprom. If ROMSEL2 is always high, then only the upper half of the 8K eprom is used? If ROMSEL2 goes low, the eprom outputs are still enabled.

Sadly, my eprom programmer doesn't know about a 2532, so it would be hard/impossible to program. I have a bunch of 2732's from ages ago, so I guess I'll wait for an improved adapter card.

Yes, ROMSEL2 is always high in the Apple /// - in normal operation. It has a pull-up resistor and is otherwise controlled by the 6522 in B6. The normal ROM and system software will always keep ROMSEL2 "high".

Apple designed the ROM to accept an 8K ROM, split into two banks of 4K. But they only needed 4K, so never made use of the optional second bank. All machines were shipped with a 4K ROM only (which has CS0 instead of A12).

You can use an 8K device though. As you noticed, you will then have to program the stock ROM into the upper 4K bank of the 8K device, so the Apple /// can still boot. Then you have an additional 4K in the lower range available for something else. You can switch ROM banks through bit 1 in the "environment register" ($FFDF). It's the same register where you enable/disable the ROM access (bit 0), or switch between 2MHz and 1MHz operation (bit 7).

But the 8K ROM option is not very useful so far. System software always keeps ROMSEL2 set to 1. And a RESET also resets the 6522, so you cannot use it to select an alternate boot ROM.

But it would work for some custom extensions. Maybe someone will make use of it some day. A better system monitor would be nice, for example. With a builtin assembly/disassembly feature like on the Apple II. That could probably be done...

This card is now also officially freakin' awesome! :)

https://www.youtube.com/watch?v=De5ufcDueRU&t=3554s

That is super cool.  It will be even better when he has a chance to check it out! 

Looks like I need some troubleshooting help. I have all the latest (Arduino) updates installed on my Dan][ card, I’ve created a new boot rom for my Apple 3 from A3ROM_DANII_4KB.bin in the latest Dan2On3 repository and put VOLA3_APPLEIII_BOOT_MENU.po on my first SD card.

It *almost* works. With the alpha lock key up, at power-on I see the usual memory test grid of 8x7 dots on the screen but an ominous ROM message shows up below the grid and I get dropped into the monitor with a beep and “->_” cursor. Press RESET (or CTL-RESET) and I get a blank screen. Press CTL-RESET again and I see “DAN2ON3: Press return” on the lower left. Press RETURN and it goes to the Volume Selector screen. Select what should be a bootable volume (system utilities) for Drive 1, press RETURN twice and I see “OK!” on the screen. Then it just goes to the “Insert boot disk – Press reset” screen. RESET goes back to the Volume Selector screen.

With the alpha lock key down, it boots from the internal drive and works normally.

Seems like something is wrong with the ROM. I used a 2732A EPROM that I’ve verified has the new boot rom code twice. I’ve hacked things so pin 18 (/CE) connects to pin 20 (/OE on the part, /CS1 on the socket). A11 on the EPROM (pin 21) connects to socket pin 18. Nothing connects to socket pin 21 (ROMSEL). Since this is a 24 pin part like the original rom, I just needed to do a little delicate lead bending and solder a couple of jumper wires.

One idea I had was to burn another 2732 EPROM with the original boot code, modify it as outlined above, and see if that works correctly. What else could I try?

There are two separate issues:

• You have some kind of reliability issue with the EPROM. The Apple /// should not show the diagnostic screen with the ROM error when booting. It's shown because the ROM checksum test failed. My patched ROM still has all the diagnostic tests in there - just like the original (with adapted matching checksum, of course). Maybe you have some kind of mechanical issue with the EPROM not making reliable connections. Otherwise likely an issue with the EPROM itself. Which speed grade did you use? I used an 150ns EEPROM (AT28C64B-15PU) and have no issues with this at all.
• The other "issue" is that you are simply quicker in testing the new features than I am in documenting how it works :). The new boot menu detects whether the selected image is directly bootable from the DAN][ controller in the Apple ///. Unfortunately normal SOS images with the stock bootloader and stock SOS.KERNEL cannot be bootstrapped from a hard drive (Profile or DAN][ controller). Apple never supported anything else but booting SOS from floppy disk #1. Everything was hardcoded for floppy #1. So, with normal volumes you still have to use a boot floppy (containing SOS.KERNEL + SOS.DRIVER). Just like it was done originally with Apple's Profile harddisk...In order to directly bootstrap an Apple /// volume from the DAN][ controller you need to use a volume with a patched bootloader and a patched SOS.KERNEL instead. Robert's SOSHDBOOT github contains images with a patched bootloader + SOS.KERNEL, which can be bootstrapped from a ProDOS interface card (like the DAN][ controller) - instead of floppy drive #1. The new DAN][ boot menu detects images based on Robert's bootloader and will happily bootstrap those. Otherwise, if the menu detects a "normal" volume with the stock bootloader, then it just displays the reminder to bootstrap from a floppy.I send you a link with a bunch of bootable volumes that you can use for testing. I made a few for a demonstration at a recent retro festival.

Success! It works like the demo on Youtube with a patched sos.kernel.

The eprom I used is marked Intel 2732A-3 with a 1979 datecode (and a "program at 21V" note - the earlier 2732 parts needed to be programmed at 25V.)  This part probably fell into my hands in the mid to late 198o's. I can't find a datasheet on-line that mentions the "-3" speed grade, my guess would be 300 or 350ns. So, despite failing the power-on diagnostic, everything else seems to work.

2732 eprom top.jpg

Yes, -3 is almost certainly something with a > 300ns response time. And in the Apple /// its being pushed to its limits.

The Apple /// mostly runs at 2 MHz. That's a cycle time of 500ns. However, the active phase of PHI0 is about half of this. So, from "address is available and CS goes low", to the moment where the ROM must have responded with valid data, is about 250ns.

So, a 250ns (better: 200ns) device would be required, to be really safe - if I understand the 6502 timing correctly.

But it's a nice original Intel EPROM. Haven't come across any of these...

I finally found an old enough Intel data book. The 2732a-3 and -30 are both rated for a max address to output delay of 300ns; so yes, probably right on the edge of reliablity at 2MHz. I'll try to source a faster part, but they are not easy to find.

I noticed on the bootable volumes that the sos.driver files don't have a .profile or a dan2On3 driver. Somehow the system utilites can list files on ".profile" - but how does one access the second drive (from the volume selector menu?) I assume .profile must be hard-coded as the boot volume in the modified sos.kernel?

2732 aren't hard to find at all.  You can get them from eBay, etc.  Many of them will be used or pulls, but usually they erase and reprogram w/o any problems.

retro-tinker wrote:

I finally found an old enough Intel data book. The 2732a-3 and -30 are both rated for a max address to output delay of 300ns; so yes, probably right on the edge of reliablity at 2MHz. I'll try to source a faster part, but they are not easy to find.

Jameco has 200ns Intel 2732A in stock.

Also Unicorn Electronics has an good selection.

You could also gamble on the abundance of ST 2732 chips from eBay and AliExpress, but not if you need reliable parts.  They're plentiful but mislabeled.  I've found functional parts among them, but the capacities and chip-selects differ from the specs.

IMG_1213.JPG

S.Elliott wrote:

    You could also gamble on the abundance of ST 2732 chips from eBay and AliExpress, but not if you need reliable parts.  They're plentiful but mislabeled. 

That's exactly why I don't buy this kind of stuff from ebay or AliExpress.

Thanks for pointing out the Jameco one however. I'll add that to my next order.

retro-tinker wrote:

That's exactly why I don't buy this kind of stuff from ebay or AliExpress.

Thanks for pointing out the Jameco one however. I'll add that to my next order

In the meantime, I will keep tinkering with my fake 2732's.  I judged them to be 2316's because pins 20 and 21 are behaving as chip-selects as documented for 2316, but I didn't test pin 18.  If pin 18 functions as A11 then these could work as drop-in replacements for SY2332 chips.

That would be a novel discovery...and it's worth experimenting to find out.

retro-tinker wrote:

I noticed on the bootable volumes that the sos.driver files don't have a .profile or a dan2On3 driver. Somehow the system utilites can list files on ".profile" - but how does one access the second drive (from the volume selector menu?) I assume .profile must be hard-coded as the boot volume in the modified sos.kernel?

Yes, the bootstrappable volumes are based on Robert's patched SOS kernel, which contains his "problock" driver for ProDOS cards. The first volume is hard coded to ".profile", the optional second volume is ".PB2". The "Selector III" utility was also originally hardcoded to require a ".profile" volume. Since Profile was the most frequent (if not only) harddrive for Apple III at a time, there indeed is software which simply assumed that the primary harddrive had to be called ".profile".

S.Elliott wrote:

retro-tinker wrote:

That's exactly why I don't buy this kind of stuff from ebay or AliExpress.

Thanks for pointing out the Jameco one however. I'll add that to my next order

In the meantime, I will keep tinkering with my fake 2732's.  I judged them to be 2316's because pins 20 and 21 are behaving as chip-selects as documen

I've bought dozens of ST labeled 2716/2732 type parts off AliExpress.  I've only found about 4 of them that wouldn't program as they were labeled.  Given the price I paid I'm not unhappy and would buy more.

Wow, you guys have been very busy, great to see the /// getting some nice support with the DanII card!

That picture with the Lan port on the back is fantastic to see.

@Macfly re your rom adapter, I had some similiar thougts of making one but had some height issues as well. A question for the one in the picture you showed, what are you using underneath, is is some sort of header pins with some plastic in there? One other way I have done is to use the Arduino stacking pins and solder them in, then cut off the excess. That way the board can sit almost flush on the socket reducing the height.

You can sort of see what that would look like here:

https://jcm-1.com/product/jcm-universal-keyboard-encoder/

ahh, i see yours needs to be able to clear U135, so my comment above is probably not going to work.

I found these things on Tindie:

https://www.tindie.com/products/oshchip/30-pieces-of-flip-pins-08/

Makes for a very low profile and fits IC sockets much better than arduino header square pins.

I've been buying them from evilmadscientist.com for a while now.

Fliptronics Flip-Pin breadboard compatible IC pins.

I had used these pin headers. These have round pins - and are really thin and delicate. Thinner than normal headers.

rjustice wrote:

ahh, i see yours needs to be able to clear U135, ...

Exactly. The PCB still needs to clear the adjacent IC. The pin headers above would have worked - almost. One thing that really bit me was that the mold has a production date imprint located *exactly* at the tightest edge of my EPROM. The imprint is raised about 2mm from the chassis. (I mean, come on! What are the chances...)

AppleIII_Chassis_Imprint.jpg

So I made it work. I removed the plastic bits from the pin headers, to save a bit of space. But then the PCB wouldn't clear the IC. So I soldered the pins with slightly different lengths. The front pins are the shortest. Pins get taller towards the rear. So the adapter is sitting at an angle. The EPROM now needed less clearance at the front, but the PCB still clears the adjacent IC.

The whole thing sits directly below the keyboard. And the adapter now has the same slope as the keyboard and chassis. Still, each individual pin is making full contact with the socket (due to the different lengths), so it sits rock solid after all.

AppleIII_ROM_Adapter1.jpg

It worked. But I'm not proud of it. And I wouldn't recommend it. I'm going to make an updated version of the PCB, which rotates the EPROM by 90° - so it sits right next to the memory sandwich PCB. That should really work. Without cheating...

Hello to all. I have to say I love this product. Nice build and so far, all that I have made has worked great. The only issue I have is trying to use the external reader card to work with it. Maybe I am not suppose to use the external ISA card version of the SD card reader with the Apple2 DAIN card version? Now, I have not verified my build of the external card but I do not feel it has an issue. Any suggestion? I am also going to try the +44 model and I also want to get these to work on my Apple /// units. Waiting for the modified ROM adapter card.

Thanks again for an AMAZING and great product. Amazing work!

You can still use this board if you simply put another IC socket underneath it, thus rasising it up a bit.

No, it cannot be raised, or otherwise the mainboard will no longer fit in the chassis. Everything is super tight in an Apple ///.

But the controller card works in an Apple /// even without changing the ROM, using a boot floppy instead. It just needs to read two blocks from the first track, which only takes a second. The custom ROM is only needed to eliminate this brief initial floppy access. So, the custom ROM is nice, but not essential.

MacFly wrote:

It worked. But I'm not proud of it. And I wouldn't recommend it. I'm going to make an updated version of the PCB, which rotates the EPROM by 90° - so it sits right next to the memory sandwich PCB. That should really work. Without cheating...

After reading here, i did go back and look again and wondered if the 90 degree rotate might fit. I'll wait for you to see if you can make that work, its all just very tight in there. I'm hopeful.

And a comment on the Arduino header pins, they are .64mm wide and 0.4mm thick. So not to bad as a cheap option thats not to wide for sockets.

I got another 2732 eprom from a reputable vendor that is supposed to have a 200ns max address to output delay. I decided to cobble together a sturdier adapter to fit the apple 3 boot rom socket. It does fit, although the eprom needs to be soldered down because a socket is too tall. Unfortunately, I get the same behavior I reported earlier - ROM checksum failure on boot but everything else seems to work fine after Cntl-Reset. Here are a few pictures of the adapter.

img_001s.jpg

img_002s.jpg

img_004s.jpg

Frustrated that I can't figure out why the modified boot rom doesn't work, I decided to build a 2nd Dan][ card. This one has the uSD sockets and associated components on board. Going to try swapping the 16MHz arduino crystal for a 20MHz one and see what happens :-)

IMG-2171s.jpg

Short follow-up... Accessing the SD cards works fine at 20Mhz, but my casual testing shows that program load times are no faster (suggesting it's not the speed of the arduino that limits anything.) Unfortunately, FTP through the wiznet board doesn't seem to work at this speed. I get the "connected" message, but then it errors out with "service not available" even for a simple "ls" at the root level.

Did you just swap the crystal - or also adapt the bootloader accordingly? The ATMEGA cannot determine what crystal is actually connected. The frequency of the crystal is configured by the bootloader. That's a good concept, since the actual application remains independent of the frequency, and the bootloader is fixed to a board anyway (not updated when a new application was flashed).

The Arduino environment relies on whatever frequency value the bootloader announced. If this value did not match the real crystal, then all frequencies and delays would be off. This would also affect the SPI communication.

I extended the DAN][ firmware and boot menu to support up to 256 volumes. Here's a little fun blog post with the details...

profdc9 wrote:

I'm not sure there's even 8.59 GB of Apple ][ software (even including GS software) to access that way.

Still great you can do it though.

 

Indeed the true practical advantage of the latest update is the higher number of supported volumes - since you can also use 140K disk images with the controller. Normal DOS disk images can't be used, but ProDOS floppy images (Apple //) and SOS floppy images (Apple ///) work fine. So another question is: were there even 256 ProDOS based application disks released for Apple II (or 256 SOS-based disks for Apple ///)? But whatever the answer: the limitation is probably beyond what any individual user would want to use in practice... :)

Successfully updated the (arduino) firmware and SOS boot menu to the latest version without touching a floppy :) Nice work, I can't wait to start filling up the flash cards.

I have a weird issue I've noticed with the Dan][.

I have a ProDOS 2.4 image that I've installed GSOS 6.01 on, and it boots into Bitsy.bye normally (I modified the startup to this instead of GSOS/ProDOS). The ProDOS file is renamed to GSOS. 

This works fine on my old CF card controller, and on emulators. It boots into Bitsy.Bye and I can choose to boot GSOS or BASIC, or whatever.  However, on the Dan][, it gets an error $002F when you try to boot GSOS. 

The weird thing is, if you have a floppy with GSOS in the 3.5 drive, it will boot when you choose the GSOS file on the hard drive.  So, it seems something is pointing the system at the floppy drive instead of the Dan][ partition?

Card is in slot 7.

According to an GS/OS error list on the net, error 002F refers to:

002F GS/OS: device offline or no disk in drive

which sounds consistent with your observation that it loads from a disk instead.

I know almost nothing about GS/OS. But it sounds like either the GS/OS image is configured (or hardcoded) to load from the floppy drive. Or it somehow does not support the DAN][ controller (which is a device according to the ProDOS interface standard), then looks for an alternate drive and finds the supported floppy instead.

Once GS/OS is loaded (from a floppy drive), is it able to access the volumes on the DAN][ controller then (just like ProDOS)? Or does GS/OS require the installation of drivers for each drive (like "Apple /// SOS" did)?

MacFly wrote:

According to an GS/OS error list on the net, error 002F refers to:

002F GS/OS: device offline or no disk in drive

which sounds consistent with your observation that it loads from a disk instead.

I know almost nothing about GS/OS. But it sounds like either the GS/OS image is configured (or hardcoded) to load from the floppy drive. Or it somehow does not support the DAN][ controller (which is a device according to the ProDOS interface standard), then looks for an alternate drive and finds the supported floppy instead.

Once GS/OS is loaded (from a floppy drive), is it able to access the volumes on the DAN][ controller then (just like ProDOS)? Or does GS/OS require the installation of drivers for each drive (like "Apple /// SOS" did)?

Yes, you can access the hard drive after it boots. No special driver is required for the Dan][.

Some peculiary with the Dan][ firmware leaves the floppy drive as the default device. I've run into this with other disk images as well. They boot fine in emulation or the Apple II core in the MiSTer, etc. but Dan][ looks in the wrong place for files. I'm sure it's an easy fix for someone...

The games hard drive image assembled by Vince Briel (usually this is called Apple II Games (DOSMASTER)) has a similar problem when booting. It boots for a little bit then gets a Check Disk in Drive error.

Trying to duplicate this bracket for the apple ///. In the stl file, one of the walls in the larger piece looks like it's only .2mm thick? (The part below the wiznet circuit board.) How small of a nozzle did you use?

I used a very basic Ender3v2 printer with a 0.4mm nozzle. But you are right, in the final iteration one of the walls became so thin that one of them only prints partially. But it's fine. Allows the part to slightly flex. And still has enough clearance so the pins don't make contact. I did snip off the pins of the Ethernet socket though, to be on the safe side. They were really long, so I cut them above the soldering points.

I ended up not even using the screw holes to lock the PCB into the bracket. Its such a snug fit, the PCB isn't going anywhere.

A3Wiznet.jpg

rittwage wrote:

The games hard drive image assembled by Vince Briel (usually this is called Apple II Games (DOSMASTER)) has a similar problem when booting. It boots for a little bit then gets a Check Disk in Drive error.

 

I looked into this game collection. An interesting rabbit hole... Here's the reason for the issues:

Background

• Devices like CFFA or DAN][ Controller are implemented according to the "ProDOS interface standard". It allows ProDOS to work with completely different hardware of block devices. The devices just have to provide a ROM, with a matching driver routine to read and write blocks. (Pretty cool!)
• ProDOS detects such devices by checking several signature bytes in the device's ROM. It also reads the last byte from the device's ROM, which contains the offset of the read/write routine. And then ProDOS knows which routine to call whenever it needs to access the drive.
• As the name suggests, Apple introduced this standard with ProDOS. It wasn't supported with DOS 3.3...

The "Apple II Games (DOSMASTER)" game collection

• This is a collection of DOS-based games - not ProDOS-games. Normally, these couldn't be loaded from a ProDOS drive. However, the game collection installs a patched DOS environment. It replaces the original DOS floppy routines with code accessing floppy images stored on the harddrive instead.
• The game collection initially boots ProDOS, but then loads the patched DOS 3.3 environment, which is used to load and execute the DOS games. This environment isn't using ProDOS any longer. It provides its own routines to access the block device.
• Unfortunately these were implemented using fixed addresses matching the CFFA ROM. So this implementation isn't fully compliant with the ProDOS interface standard. It does use the routine from the device's ROM, but it requires the same entry addresses as the CFFA ROM implementation.
• It works with the "AppleWin" emulator though. AppleWin uses a ROM for its harddisk emulation with the routine located at the same offset as in the CFFA ROM (not sure, AppleWin may actually use a copy of the CFFA ROM and emulate a CFFA device, since it is also implementing a DMA block device, just like the CFFA - but I haven't compared this in detail).

Other ProDOS devices

• I checked a few other ProDOS devices, like the tjbold ProDOS ROM drive. Of course, these also have ROMs which are ProDOS compliant, but their entry routines all differ (do not match the CFFA, nor the DAN][ etc). So none of those could work with this game collection.
• Bottom line is: the image with the "APPLE II DOS GAME" collection will only work with the CFFA - but not with other ProDOS interface cards in general (unless they accidentally happened to use the same ROM entry offset like the CFFA).

Fixing the issue

• For the original author it would be rather simple to fix the game collection and make it compatible with any ProDOS interface card. Just needs a few extra bytes. Patching this into the existing image isn't quite so easy. And multiple locations in the image are affected.
• It's possible that the author of the collection never noticed the issue, since he only had a CFFA for testing. Or, since he is also involved in maintaining the CFFA, he may never have intended this to work with any other device than a CFFA.
• A simple, dirty hack is possible though. I attached a patched image which simply replaces the hardcoded offsets matching the CFFA with those matching the DAN][ ROM... Well, the lastet version of "my" DAN][ ROM (this one). However, there were already various versions of the ROM, both in Dan's and in my repo. The entry address has changed several times, since it normally shouldn't even matter at all.
• Maybe if someone (or me) got bored: a better hack would be possible, of course. One would need to squeeze a routine into the game collection's startup, which patched the hardcoded addresses with the correct entry offsets as announced by the device's ROM. This would make the game collection compatible with any ProDOS interface card.

Here's my quick and dirty hack for the DAN][:

APPLE_II_GAMES_DOSMASTER_DANII.zip

It's a really nice collection - and has several games which are not part of other collections (like TotalReplay). But I haven't tested all the games. There are 102 of them in this collection. Neither do I even know how to play most of the games. With the hack all games I had tested appeared to start fine with the DAN][. But no guarantees...

DANII_DOS_GAMES.jpg

That is great sleuthing- thanks for that!

I wonder is that offset in a "standard" place and the Dan][ firmware could always statically locate the routine in the same place as the CFFA, or is that not possible?

Printed the bracket and did a trial assembly. Still need to find some really tiny screws to make the clamp work on the Apple ///. (I did have to file down some casting seams on the chassis to get the bracket to fit in the slot.)

PartsAssy.jpg

It would be pretty cool for the "correct" fix to be done so this DOS games collection worked on any ProDOS block device like the Booti, Fujinet, Apple-IO-RPi and others in addition to the Dan ][.  Maybe the original author will see this or someone can contact them.  But in any case...  baby steps.  The quick hack is still pretty cool in and of itself.

I have created a separate thread for the DOS.GAMES / DOS.MASTER discussion here. It's not DAN][-specific and worth a separate topic.

Hi Dan,

I've grabbed the Gerbers and uploaded them to JLPCB but it complains about null values when I try and view the PCB online. So I can't save to my cart and purchase. 

Which of the various 'Gerber' files do I need to zip up and upload?

Thanks and cheers, Martin

mnc1959 wrote:

Which of the various 'Gerber' files do I need to zip up and upload?

You need all Gerber files. You have to ZIP the entire Gerber directory. Or you can download this prebuilt ZIP file from my repo:

https://github.com/ThorstenBr/Apple2Card/blob/main/Apple2Card/Gerber/Apple2Card-v1.1.1.zip

Hello, 

I have an old Apple II+, and I spent some time to change TTL to bring it back to life.

I have as well ordered this SDCARD PCB and built 2 card.

The firmware is on the EEPROM, the arduino is compiled and upload (with the fuse),

Booting the Apple II, I am asked to push enter, and then to choose between 0-9 for the 2 Slots, and then nothing..........;

I have add a serial to the ATMEGA328 to check the debug message. 

the ATMEGA328 is receiving cmd but it is like it is stucked....

What can I do ? 

Below the screenshot of the serial debug, it seems that the arduino is rebooting

Btw: I struggle to add the serial on the PCB TX/RX are inversed with SDA/SCL...

Screenshot 2023-12-22 at 23.33.08.png

Thanks for your help Vincent

Yes, the default serial RX/TX pins on the Arduino must not be used with this PCB. The entire PD0-PD7 port is used for communication with the Apple II. So PD0/PD1 are not available for serial communication, like they normally are. If you enabled the Arduino's default Serial module, then the card will no longer work. The firmware uses alterate pins and a software-emulated serial connection for debugging instead.

But it probably doesn't make much sense to start debugging anyway. If the card is unable to read volumes from the SD cards, then you most likely have a hardware issue with the connection to the MicroSD slots. Usually pins at the SMD slots are short-circuited or not properly soldered.

You could also use my variant of the firmware. It has a self-test mode at startup. When no SD card is plugged, but the ATMEGA is ok, then the two slot LEDs will alternately blink slowly multiple times after powering the card. You can also test this on the bench, outside the Apple II. Then when you power the card with an SD card plugged, there should be no more slow blinking - just a very brief flash (barely visible) of the LED for the slot where the SD card is plugged. Otherwise, if it was still slow blinking, then you have a hardware issue with the connection between the ATMEGA and the tested SD slot:

https://github.com/ThorstenBr/Apple2Card

Thanks MacFly for your answer, 

I am almost there, my Apple II is a 48k, I can not run anything, waiting for a language card...

I have checked the PCB, and I had a short on the SCARD with GND, 

After that, I was still not able to mount the SDCARD, and I have tried to understand why with serial debug. I discovered that windows / MacOS SD formatting are adding a MBR partition to the SD card. Thus it can not be read...

So for those who are like me (on a journey to make it work ;)) format your SD with a linux and check the partition.

I will continue to post once I have something to RUN (missing 16k of RAM)

Vincent