Apple II DISK Emulator using STM32

New question

I have the emulator in the Disk 1 position on the interface card and a real floppy drive in the Disk 2 position.

Trying PR#6,D2  or PR6,S6,D2   does not boot into the second drive

What am I missing?

Aurbo wrote:

New question

 

I have the emulator in the Disk 1 position on the interface card and a real floppy drive in the Disk 2 position.

 

Trying PR#6,D2  or PR6,S6,D2   does not boot into the second drive

 

What am I missing?

That's normal, even with no SmartDiskII or with two floppy disks installed on the same card.

You can only boot from the first drive (Controller port 1/Drive 1) of any given slot.

Two controllers is a better set up with Floppies on 1 card and SmartDiskII on another. Note Smartloader will not work on a lower slot number than floppy disks, but will still boot in disk][ emulation mode with an image mounted (or last known if set to do so in settings).

My setup:

Slot 7 Re Epromed Grappler +

Slot 6 SmartdiskII -> drive 1

Slot 5 Floppies -> drive 1 and 2

etc........

Thanks again

I will give a second Interface card with Floppies a try and see how it goes

With SmartdiskII in slot 6, can a second SmartdiskII be added to the the mix?

Slot5 Floppies -> drive 1 and 2

Slot6 SmartDiskII -> drive 1  and a second SmartDiskII -> drive 2?

Quick reply

Your suggestion to add a second DiskII interface card with the physical Floppy drives attached to it in Slot 5  works.

Slot 6 still boots it's last run file on power up as configured and a PR#5,D1  or PR#5,D2 behaves correctly.

Thanks

Aurbo wrote:

 

With SmartdiskII in slot 6, can a second SmartdiskII be added to the the mix?

 

Probably, as it is addressed like a normal drive.

i have not physically tried it but do have enough emulators to do so just never seen the point.

Addendum: Just tried it and it works as per your expectation.

ATB Steve

New question:

I can create a disk on the emulator (empty file named CHUGGA)  trying to save the typed in code with  SAVE CHUGGA,  I get a WRITE PROTECTED response.

What am I not doing correctly?

Aurbo wrote:

New question:

 

I can create a disk on the emulator (empty file named CHUGGA)  trying to save the typed in code with  SAVE CHUGGA,  I get a WRITE PROTECTED response.

 

What am I not doing correctly?

 

I am fairly sure (but not 100%) that creating a disk in the emulator just creates a file with the correct extension. You still need to format it with DOS 3.x loaded (init hello) or with ProDOS filer for ProDos 8. IIRC not doing so causes a  WP error (locked)

Also in ProDOS.. it's not good practice to name your files the same as the Diskette prefix.

You can also make the disk bootable by coping ProDos.system, basic.system and a startup file (called startup) but make sure they are copied in the correct order (see online ProDOS users guide for full details.)

All the Best

Steve

Finally have some time to get back to this,

Slot 5 with 2 physical floppy drive units connected to S5,D1 and S5,D2 work fine.

Slot 6 with an Apple II DISK Emulator using STM32 connected to S6,D1 works fine, however it does NOT respond with a second Emulator in S6,D2 

Could someone take a moment to explain how to use the 6pin header in the lower right corner of the Rev8 pcb please. (https://github.com/vibr77/AppleIIDiskIIStm32F411)RDD,WRQ,DE,WRP,WRD,GND

I believe they might help solve my "write protected" and "disk full" errors when I try to save programs to the emulator.

I am currently using the required only components on the pcb.

I had trouble recording. It turned out my flat ribbon cable was too long. I checked all the connections, and only shortening it solved the problem.

VIBR wrote:

Just a quick note on the U2 footprint, 

I use this part for LCSC #C381084 I hope it will help 

Vincent 

Vincent, 

Pin 14 (device enable) controls the original Disk II interface card to enable Drive 1 or Drive 2 depending on the signal. 

Does your optional resistor D5 perform the same function depending on if R5 is installed or not, or are you using Device Enable on pin 14 for a different purpose?

Here is my spin on your project;

Panel mounted, installed into an empty Disk II drive case, (a new 3d printed faceplate for the Disk II case is completed but not shown)

.96 oled changed to a 1.54"

4 buttons changed to a 5way navigation button

1000014058a.jpg

1000014057a.gif

VIBR wrote:

Hello, 

Very nice work, I am always impressed by remix of the SmartdiskII, 

The D5 is a pull up resistor (R1K5) on Device_enable, you need this to avoid floating the signal. 

The Drive selection is made on the card but it is always PIN 14 on the IDC connector.

Hope it helps

Vincent 

 

Thank you for the clarification Vincent.

R5 is NOT listed as a mandatory part on the BOM so I did not install it, correcting that now.

Could you take a moment to review the BOM and update any additional mandatory parts please.

Cheers!

VIBR wrote:

V0.80.45

What stuff is new and needs to be tested in the latest few revisions?

Hello,

It's good job,

My 4-pin SPI SD card module only 4 pin cs,clk,miso,mosi, how can I connect it ?

I see it in your previous versions .    

Hi,

First of all, thank you for creating the SmartDisk project and for making it open source. It's a very interesting project, and I really appreciate the time and effort you've put into it. It's great to see new hardware being developed for the Apple II community.

I have a question before I connect a SmartDisk to my Apple II+.

I've been using an SDisk II for quite some time without any problems. However, I wasn't as fortunate with a FloppyEmu. When I connected it to my Apple II+, it ended up damaging (burning) the CPLD. 

After discussing the issue with other Apple II users, I was advised to use a small "surge protector" board that looks like it adds series resistors to each signal line between the disk controller and the emulator. (I've attached a picture of the board I'm referring to.)

Before I connect the SmartDisk to the same machine, do you think this kind of protection is necessary?

I noticed that the FloppyEmu connects the Disk II interface signals directly to the CPLD, while the SmartDisk is based on an STM32 microcontroller. Does the STM32's I/O circuitry make it inherently more robust against voltage spikes or signal transients, or would you still recommend using the external protection board?

If you believe this protection is recommended, do you think it would make sense to integrate these series resistors directly into future revisions of the SmartDisk PCB, instead of requiring an external protection board? It seems like it could improve compatibility with older Apple II machines and provide some extra protection for the MCU.

I'd really appreciate your opinion before I connect my SmartDisk.

Thanks again for sharing this excellent project!

SurgeProtector_FloppyEmus-l500.jpg

In post #521, 'senhordd' asked:

" Before I connect the SmartDisk to the same machine, do you think this kind of protection is necessary ? "

Uncle Bernie comments:

Over the past 40 years or so, I've  had my fair share of CMOS ICs blowing up and needing replacement. It's called "latch up" and was the bane of CMOS since its invention, and still is, despite all efforts to mitigate the problem. The CMOS ICs just got more robust and don't "latch up" that often anymore. But despite of hilarious (or even fraudulent ?) claims such as "will not latch up under any conditions" or "latch up proof" found in some databooks, app notes, or ads from some IC manufacturers, all CMOS ICs can and will "latch up" under certain conditions, with one exception: those using the SOI technology (Silicon-On-Insulator), but this technology  is far too expensive for mass produced consumer ICs and typically has only been used on military and aerospace applications. It also has some severe complications with circuit design, as SOI does not allow for good body connections of the MOSFETs. In standard CMOS, the MOSFETs sit in "tubs" or "wells" which allow for good body connections (the "bulk" node in SPICE). SOI has no "tubs" nor "wells", the transistors are just a thin film of lightly doped silicon on an insulator (hence, the name of the technology) and although you can draw structures which mimic a body connection, these have poor electrical properties. The complications with this technology are so bad that it only is used in said special applications where the advantages like robustness against radiation (and no "latch up", ever) outweigh the disadvantages, and where a Ministry of War is willing to pay the outrageous prices for these SOI ICs.

Understanding "latch up"

"Latch up" is enabled by the above mentioned "tub" or "well" structures found in standard, "bulk" CMOS. They form a PNPN sequence which also is known (and is sold) as a discrete device called a "Thyristor" or "SCR" - "Silicon Controlled Rectifier": it has three electrodes, an anode, a cathode, and a "gate" which should not be confused with a MOSFET gate.

When the "gate" receives a trigger pulse of current, the "Thyristor" turns on and conducts current fom its anode to its cathode, even if the trigger current ceases or if the "gate" gets disconnected after the turn-on event. There is no useful current limit within the structure. And for bulk CMOS ICs, this parasitic (unwanted) "Thyristor" has anode = VCC and cathode = GND, which is the supply voltage, so once it is triggered, it will draw all the current it can get from the power supply, and will get hot enough to destroy itself (or even burn a hole into the PCB).

Now, one you have a basic understanding what the destructive mechanism is, it should be clear that unless you have a current limiter on the VCC of the CMOS IC, if the parasitic Thyistor is triggered, the IC will self destruct.

And it should be clear that by adding series resistors in I/O lines, as the "protection" PCB does, no suffiient current limit in the power supply itself could be achieved. And if you add a series resistor there, the IC will "choke" itself when it switches. Some CMOS circuits use passive filters in the power supply for individual ICs to prevent them from "talking" to each other via the power supply lines but sizing of these filter components is very tricky. Don't try that as an an ill-equipped hobbyist. It requires the lab and know-how of a professional and even then can't be done for all ICs in all applications. When clocked fast, CMOS can draw huge amounts of current.

How the "protection" PCB works

What the  "protection" PCB can do is to limit the trigger current for the parasitic Thyristor. And this is working hand-in-hand with the "latch up" mitigation measures the semiconductor manufacturers have implemented and improved over the decades, which tweak the process and the layout design rules such that the trigger current threshold needed to turn the parasitic Thyristor on (causing self-destruction)  moved higher and higher. If the series resistors in I/O lines can limit the current to a level below that threshold, "latch up" is prevented. The downside is that if the resistor value is too high, the driving capability of the outputs will be impaired and signal edges may get too sloppy, if the outputs must drive larger capacitive loads, such as longer flat band cables.

But there is more going on whenever longer cables are involved: CMOS is able to produce very fast signal edges and the cable, if exceeding a certain length, related to the rise and fall times of the edges, will produce reflections unless the whole thing was correctly terminated using transmission line theory.  If not terminated, the electromagnetic "shock wave" representing the signal edge caused by the output driver will "hit a wall" at the receiving circuit and bounce back, much like an ocean wave hitting a concete wall on shore, and travel back to the output stage, but it may be of negative polarity. And if the output driver of a p-substrate based CMOS IC ever "sees" a negative voltage that is 0.6V (or so) more negative than its negative supply voltage (typically, "GND"), the always present n+/p- substrate diode will open and inject minority carriers (here, electrons) into the p-substrate, which can travel to places all over the IC and trigger parasitic thyristors whereever they are lurking. IC designers add guard rings to catch these vagabonding minority carriers before they can leave the vicinity of the output driver, but there is a limit as to their efficiency. The output driver itself and be made "latch up" robust by using all NMOS output stages. Many PLDs / CPLDs (like the Lattice GALs) did that. When a PMOS is used as the high side switch, trouble is invited, as this output structure by itself has a built-in parasitic Thyristor. Some PLDs / CPLDs also use internal charge pumps which, once powered up, will pump the substrate down to a negative voltage far beyond GND, and then this substrate voltage increases the negative voltage the output pin must be hit with to trigger "latch up". It should be obvious that no charge pump can protect an IC that is "hot plugged". Which would happen if you insert a Floppy Emu cable into an Apple II that is turned on - or has residual voltages on its power supply rails, not enough to power the machine, but enough to feed a "latch up" event.

Last but not least, even a weak ESD event typically involves negative voltages which also can trigger latch up.

Conclusions

It has been shown that the whole topic of why CMOS ICs die is more involved than most people think. While series resistors in "protection" interposers can help to mitigate the "latch up" risk, they also degrade signal edges, which seen in the light of transmission line theory is beneficial as it weakens reflections and allows for longer cables without proper termination, but seen in the light of digital signal integrity, may impair the signals to a point where the system operation becomes unreliable (Schmitt Trigger inputs can mitigate the ill effects of sloppy edges).

But none of these measures provides protection against ESD or "hot plugging" triggering "latch-up".

Recommendations

1. Never hot plug a peripheral or slot card

2. Allow a minute (or so) after power down before plugging a peripheral or slot card in or out

3. Avoid ESD, as this can trigger "latch up", too.

4. Keep your cables as short as possible

5. If longer cables are needed, add proper termination networks matched to the cable

6. Series resistors may help but also degrade signal fidelity

7. Schottky clamping diodes between I/O pins and GND which clamp negative voltages  to < 0.6V provide much better "latch up" protection without any ill effects on signal fidelity. BAT 85 type is popular and cheap.

Final thoughts

Good luck ! Keep in mind that "latch up" risk can only be mitigated, but never fully avoided as long as bulk CMOS (rather than SOI) is used. Personally, I prefer the Schottky diode solution over the series resistors, but for longer cables, termination resistors sized using transmission line theory are inevitable. You can use RC networks to achieve proper RF termination without degrading static logic levels at inputs of logic families which draw static input currents. This is not trivial, though, and needs lab equipment and experience going beyond most hobbyist capabilities.

- Uncle Bernie

The 4-pin SPI SD card module only 4 pin cs,clk,miso,mosi, how can I connect it ?

 it always say "ERROR : SD EJECTED"

Thanks for taking the time to explain all of this. I really appreciate it.

I'll follow your recommendations and shorten the cable I'm using. Thanks again for sharing your knowledge!

I would like to point out you need to have the metal portion of the microSD card holder U2 attached to GND.  (see the first image in post #512,  my U2 was not grounded)

Aurbo wrote:

I would like to point out you need to have the metal portion of the microSD card holder U2 attached to GND.  (see the first image in post #512,  my U2 was not grounded)

thank you,

I also pull up PB13 add a resistor.

VIBR wrote:

You can not as the SmartDisk does not use SPI (to slow for Apple II track move), it uses SDIO (4 Data Line, 1 Clk)

Ah, I see! Thanks for clarifying that SPI is too slow and SmartDisk requires SDIO for proper Apple II track speed. I will switch to an SD card module that supports full SDIO (4-bit Data + CMD + CLK).

Does the test-firmware require to flash the bootloader first or will it also work with old bootloader v0.16?

Gandalf derGraue wrote:

Does the test-firmware require to flash the bootloader first or will it also work with old bootloader v0.16?

Works with the original bootloader. New one among other things stops the error when uploading due to the device restarting after uploading the uf2 file

hello, is it possible to remove /add option (or use the existing settings) to boot directly to file list in smartloader and disable the" Auto-boot of the last disk after the 3 / 2 / 1 countdown" ?

Thanks for a great device !

Tested new fw/smartloader with new settings can now boot directly , very nice, so much faster now its amazing.

I use mainly smartloader with smartport images and noticed it only shows the 1 image when booting from smartloader (the slots 2-4 show empty). When in smartport mode all 4 images are there?

Also notice new setting in smartloader "SP resync 2 edges" couldnt find any info would this setting be related to this? 

hi vincent, thanks for quick update, looks good..Forgot to mention the latest smartloader has smartport coded to slot 5 , i use a softsp v6a card in slot5 and it auto boots on our apple IIe Plat which is actually good as it frees up slot 7.

However naturally it now wont auto boot if softsp is in slot7 just crashes. It would be good to be able to change the slot number for smartport card /floppy controller especially for II/IIe machines via a settings option, perhaps include an "auto" setting for other machines? 

In smartport hd mode it goes back to normal, wont autoboot slot 5 , only boots when softsp is in slot7, not sure if this can also be set in smartdisk fw option? 

In relation to smartport/liron have you looked at imbedding the smartport/softsp rom into the fw especially in smartloader? I was going to try investigate but noticed the smartloader source no longer on github will it be available in future?

thanks again for a great device

Hi, tested on IIe platinum, sp card installed slot 5 - in smartloader emu mode working but not in smartport HD mode, but I can now change to slot 7 in settings and it autoboots in both emu modes. I assume cant override the apple rom autoboot outside the smartloader?

The only setting that SP Start setting works is on "0". If I set SP Start 1/2/3 it ignores the emu mode and just boots smartloader. What does the SP Start setting control?