Apple II DISK Emulator using STM32

VIBR wrote:

I am making good progress on emulating Disk3.5 (Non Smartport) with 2MG file

Initially I thought that DiskII was hard, it is nothing compared to Disk 3.5 !!!!

WTF ;)

 

Cool.  3.5 emulation will be nice to have.  What are the plans for more write support for formats other than .woz?  .dsk and .po.  I imagine those won't be easy either compared to .woz or even .nib, but they'll be important for a lot of people.

Sorry about the dumm question, I have download the github site tried to compile the BIN file to install on the BlackPill, but I am getting a header file not found.

Core/Inc/main.h:30:10: fatal error: stm32f4xx_hal.h: No such file or directory   30 | #include "stm32f4xx_hal.h"      |          ^~~~~~~~~~~~~~~~~compilation terminated.

It's almost certainly me being a dimbo! Do you have instructions any place or a howto for compilation and installation.

Thanks

Derek

Hi Vincent,

I tried to implement the rotary encoder support in the HAL_GPIO_EXTI_Callback function. This was not a good idea as the EXTI interrupts are shared with other pins with the same number. If I reprogram the two debug timer outputs B1 and B10 as input for the encoder, the emulation no longer works properly. I will now try the ISP connections A13 and A14 and query them classically in the emul_diskii.c main loop. This will probably not work with the Smartport emulation, but this is not important to me at the moment.

Every idea is welcome :)

https://github.com/joergschne/AppleIIDiskIIStm32F411

Today I tested the green OLED display. Unfortunately it is only available with a FFC connector with 0.5 mm pitch - something for soldering experts only.

https://www.digikey.de/de/products/detail/amphenol-cs-fci/F32R-1A7H1-11031/11564719

But if you make it, you will be rewarded:

IMG_20250220_191018.jpg

Here is a YT short about it: 

https://youtube.com/shorts/aexNvQDcABk

KR

Joerg

Hi Vincent,

Thank you very much for this wonderful experience, now everything works as it should.

https://github.com/joergschne/AppleIIDiskIIStm32F411

https://youtube.com/shorts/TgZ5UqMbQsM

Bildschirmfoto 2025-02-22 um 20.39.46.png

KR

Joerg

I just pulled the latest version and built it and I will give it a test today.  Looking forward to seeing progress on the .dsk and .nib write.  Are you going to handle .po also?  Should be almost the same as .dsk except for the sector block/ordering so it shouldn't be too hard once .dsk is working.

I had no luck getting SmartPort mode to work.  I tried it with SmartDiskII cards and my real LiRON card.  I need to find one of my Yellowstone cards and try that.  Also I should make sure my LiRON and SmartDiskII cards work with one of my FloppyEmu to make sure I'm just not doing something stupid.

Perhaps there is just something I don't know about SmartPort, because it seems like it shouldn't be difficult.

The IWM's cell period is set by bit #3 of the mode register. The mode register is written with $0F to configure the IWM for the Apple 3.5" drive.

Not just the cell period, but all of the other settings (sync vs. async, latched vs. unlatched, motor delay) are different between the 3.5" and the 5.25" disk drives. This manifests as a mode register set to $00 for 5.25" and $0F for 3.5".

See Neil Parker's "Controlling the 3.5 Drive Hardware on the Apple IIGS"

In post #310, 'softwarejanitor' wrote:

" I had no luck getting SmartPort mode to work.  I tried it with SmartDiskII cards and my real LiRON card."

Uncle Bernie comments:

SmartPort seems to be a quite finicky system, and so far I did not succeed to make it work with 'IWMless', but I more and more get the impression that the SmartPort firmware may - intentionally or not - might exploit some weirder 'features' (which may be called 'borderline' bugs) in the original IWM to make SmartPort work.

Note that my project is on the 'host' side of the SmartPort system while 'VIBR' is on the peripheral side (because it's a Floppy Emu) so there are different possible pitfalls, but here is my experience with SmartPort:

I wrote my own stripped down versions of these routines to test various functions of the 'IWMless' on different platforms and my simpler routines, despite having been carefully written, do work with the 'IWMless', but don't work with the original IWM.  They do not yet try to implement the full protocol, but exercise data send and receive in SLOW ASYNC LATCHED mode, and all the handshaking etc. appears to work fine as long as the 'IWMless' is used. They do NOT yet work with the original IWM. I'm still investigating why. There must be a subtle difference which matters.

Possible root cause: critical timing !

My routines are not yet complete enough to use them to access my BMOW Floppy Emu, whose SmartPort HDD emulation works fine on the Apple IIc, but there is a lesson to be learned from this, and this is the possibility of some timing critical sections being present despite of the SLOW M7 ASYNC LATCHED configuration of the IWM being used, which should greatly relax the CPU cycle counting ordeal that was needed to make the earlier DISK II system work.

And if the SmartPort timing is indeed so critical, at least in some parts of this firmware, then 'VIBR' must exercise great care to exactly replicate the timing of these original SmartPort devices to keep Apple's SmartPort routines happy.

Yet another wild conjecture about Apple's SMartPort devices:

I found some clues in the original SmartPort source code which seem to hint that at least some 'SmartPort' peripherals may employ yet another IWM in that peripheral. If it is so, then the SmartPort routines in the Apple IIc uses the IWM of the Apple IIc to talk to yet another IWM in the peripheral, and this IWM<->IWM communication implies some inherent timing requirements based on the IWM architecture being present in any peripheral which seeks to substitute an original SmartPort peripheral.

Note that this is just a conjecture because I did not find any schematics for any Apple SmartPort peripheral on the web ... maybe I'm just too dumb to ask the right question to the alleged "AI" trying to help me with finding them., or the "AI" is corrupt and tries to deceive me.

How to proceed ?

Maybe some of the few people who have successfully implemented SmartPort peripherals can chime in and tell us what were the difficulties and surprising 'gotchas' they encountered during their own development effort.

And if you happen to know where to find schematics of original Apple SmartPort peripherals, please provide links either by posting or by PM.

These inputs could greatly help both 'VIBR's floppy emu project and my 'IWMless' project.

- Uncle Bernie        

In post #313, 'robespierre' wrote:

" The IWM's cell period is set by bit #3 of the mode register. The mode register is written with $0F to configure the IWM for the Apple 3.5" drive. Not just the cell period, but all of the other settings (sync vs. async, latched vs. unlatched, motor delay) are different between the 3.5" and the 5.25" disk drives. This manifests as a mode register set to $00 for 5.25" and $0F for 3.5".

Uncle Bernie comments:

I think that this may only apply to the Apple IIgs, or maybe even the Apple IIc+, which I don't have. But for the regular Apple IIe with Liron card and the regular Apple IIc, according to what the discussion in this thread:

https://www.applefritter.com/content/did-anyone-analyze-iwm-related-apple-iic-firmware

has led to, the SmartPort firmware on the Apple IIe Liron card and those in the Apple IIc ROMs only use IWM configuration $07 (post #9 by 'rjustice' has the links to the SmartPort firmware source code). IWM configuration $00 is basically a DISK II emulation, and this is the default state of the IWM on the IIc unless SmartPort is invoked.

My current postulate is that any Apple II-ish computer running the 6502 at only 1 MHz is simply too slow to handle IWM FAST modes, which pump a byte in or out of the IWM every 16 CPU cycles. So unless the contrary is proven, I'd recommend that 'VIBR' should focus on the IWM configuration $07, which is M7, SLOW, MOTOR TIMER OFF, ASYNC MODE ON, and LATCH ON.

But take this with a grain of salt ... so far I did not succeed in making SmartPort work on my 'IWMless' plugged into an Apple IIc. Which might be because the assumption of IWM configuration $07 being the only one used by SmartPort may even be wrong ! But so far the source code the above link refers to has  n o t  reveiled any other IWM configuration code to be used by the SmartPort functions in this source code. Which, alas, I could not find in this form in my Apple IIc having the latest firmware upgrade ... it seems to be an earlier version. So it's possible that Apple used other IWM modes in later revisions - but even if so, I doubt that FAST modes can be used. They would require either faster 6502 clocks, or extra DMA hardware into a RAM buffer like the MIG chip of the Apple IIc+ seems to do.

There is one bit of proof that the SmartPort routines in the Apple IIc using PRODOS 1.9 do never try to set the IWM to any other mode than $07 or $00: my 'IWMless' only implements one bit of the CONFIG register (ASYNC) and 'swindles' in the STATUS register readback to make it appear as  M7, SLOW, MOTOR TIMER OFF, ASYNC MODE ON, LATCH ON.

It so happens that the 'SetIWMmode' subroutine in the SmartPort routines of the above link (page 192, address $CC1F) is written such that it never returns when the IWM can't be set to the desired mode. So if the firmware ROM I have in my Apple IIc uses the same 'SetIWMmode' subroutine, then the system would 'hang' at times and only be recoverable by RESET. But this does not happen with the current version of 'IWMless'. So modes $00 and $07 is all there is. Or they did improve that 'SetIWMmode' subroutine. I can't look into the ROM of my Apple IIc because the keyboard is partially dysfunctional, so I can only use the PRODOS menu functions (cursor up, down, left, right, and RETURN). This hampers my work but it seems it's the keyboard encoder and not the keyboard itself which is the root cause for the keyboard problems. And these ICs are unobtainium, so I can't repair it.

A few words of encouragement:

But as always ... once the bug(s) are found and have been squashed, and it finally works, it all looks trivial, but hindsight is 20:20.

A foul trick used by the design engineer 'superstars' in the industry is to always pretend how simple and trivial and effortless their own work is. So everyone looking at how complex and challenging it is stands in awe. The 'star' engineer must be a superhuman, they think. The ugly truth is that much work is done unseen, at home, at the weekends, and late in the night, when all the 'normal' engineers are not present in the company.

- Uncle Bernie

The 1.54" available at https://www.aliexpress.us/item/3256806392722675.html worked great with no code changes.  Claims to be SSD1309 based.

PXL_20250301_215327444.jpg

The 1.3" from https://www.aliexpress.us/item/3256803297703282.html has pixel shift issues on the right side of the display and would need some updates for the (likely) SH1106 display driver (e.g. https://forum.arduino.cc/t/oled-shifted/323480/4)

PXL_20250301_215529317.jpg

Also grabbed on the new 128x128 1.5" model, similar price as the 128x64 1.54" but double the pixels in the vertical plane which could allow for deeper menus, etc. https://www.aliexpress.us/item/2255799863676468.html

PXL_20250302_000458888.jpg

Here they are all together. Will do a board variant with the 1.54" and full size SD once I figure out the rotary encoder support.

IMG_0071.jpg

When you say : " The SmartDisk II card expects that to be pulled high to 5V to select Disk II mode." you mean that if not pull up I can not have the Smartport to work or the Disk II ?

thanks 

Vincent

The SmartDisk II switches to Disk II mode when the Select line (Pin 12) is pulled high. From https://github.com/btb/SmartDiskII

5.25 Floppy operation works by having the Disk II boot rom in the 0xxx region of the EPROM, and therefore active while U9 is held in reset. Plugging a floppy drive into the DRV1 connector should automatically activate the correct firmware because of the presence of +5V on pin 12, but because some devices do not have that pin connected, you can also close jumper JP8 to force the card into Disk II boot mode.

I just tested again with the v0.80.1 firmware version and it still required the jumper to force Disk II mode.  Smartport mode is now working great though and I was able to boot and use Total Replay on my IIe with only a SmartDisk II card installed.

Now need to try a Disk II card with the DIY SoftSP ROM on a Grappler card.

hideehoo wrote:

When you say : " The SmartDisk II card expects that to be pulled high to 5V to select Disk II mode." you mean that if not pull up I can not have the Smartport to work or the Disk II ?

thanks 

Vincent

 

The SmartDisk II switches to Disk II mode when the Select line (Pin 12) is pulled high. From WhatWha

What jumper or other settings is required to get SmartPort mode to work?  I've tried it with a real LiRON card and a SmartDiskII card and I haven't been able to get it to work.

What jumper or other settings is required to get SmartPort mode to work?  I've tried it with a real LiRON card and a SmartDiskII card and I haven't been able to get it to work.

No jumper is needed for SmartPort mode.  Just plugged it in to the Drive1 connector, installed the SmartDisk II card in Slot 6, and it works fine.  Using the smartdisk.bin firmare burned to a Winbond W27C257-10 EEPROM.  Does a Fujinet or other Smartport devices work with your card?

IMG_0072.jpg

My current postulate is that any Apple II-ish computer running the 6502 at only 1 MHz is simply too slow to handle IWM FAST modes, which pump a byte in or out of the IWM every 16 CPU cycles. So unless the contrary is proven, I'd recommend that 'VIBR' should focus on the IWM configuration $07, which is M7, SLOW, MOTOR TIMER OFF, ASYNC MODE ON, and LATCH ON.

Yes, the 2 µs FAST mode is only really feasible when the IIgs is running at 2.5 MHz. Reading an 800 KB disk requires each byte to be handled by the host in no greater than 16 cycles when the 6502 is running at 1 MHz. This is very hard to achieve. As written elsewhere, however, the IIc+ can do it (at 1 MHz) using a special hardware assist. 

By the way, in case you haven't yet read Neil Parker's guide, I'll attach it here.

IWM-Controlling the 3.5 Drive Hardware on the Apple IIGS

Hello Vincent,

Q6 and Q7 are "soft switches" inside the IWM†. They aren't part of the disk drive.

The document 343-0041-B calls them L6 and L7.

†and existed at the same addresses on the Disk II Card before it: Q6 is the SHIFT/LOAD switch and Q7 is the READ/WRITE switch of the Disk II. The IWM soft switches work the same way when it is in Disk II mode (bit #6 of DISKREG $C031 set to 0)

Both Disk II and Smartport modes work connected to a Disk II card in slot 6 with a Grappler+ card hosting the SoftSP 6a DIY ROM in slot 7 in my IIe.

hideehoo wrote:

What jumper or other settings is required to get SmartPort mode to work?  I've tried it with a real LiRON card and a SmartDiskII card and I haven't been able to get it to work.

 

No jumper is needed for SmartPort mode.  Just plugged it in to the Drive1 connector, installed the SmartDisk II card in Slot 6, and it works fine.  Using the sma

How do you have the solder pads on the back of the board configured?  I've never been able to find any documentation on how they should be set up and I've asked here multiple times and never gotten an answer or had anyone post a pic of the back side of a known working board.

I built 5 of these cards and I get the same result.  I need to try it with one of my FloppyEmu or if I can find it, the FujiNet I have.  I've never used the FujiNet and I've only ever used the FloppyEmu to emulate a 5.25" drive.

softwarejanitor wrote:

How do you have the solder pads on the back of the board configured?  I've never been able to find any documentation on how they should be set up and I've asked here multiple times and never gotten an answer or had anyone post a pic of the back side of a known working board.

It's kind of hard to tell, but I don't have any of the solder jumpers on the back bridged.

IMG_0073 (1).jpg

JP4 controls A10 on the EPROM, by default it is low.  If you just burn the standard SmartDiskII.bin firmware to a 2732 compatible EPROM/EEPROM, you shouldn't have to mess with that one.

The other jumpers control what happens with the Drive1 slot.

SmartDisk II Jumpers.PNG

JP5 routes ENBL2 to pin 5, which is what the Floppy Emu uses to support dual disk.  By default it's grounded.

JP2 does the same for Pin17, which is what the Fujinet uses for ENBL2.  So those two options are mutually exclusive, and it you route ENBL2 to pin 17 and ever plug in an actual Disk II, it will route +12V into the Apple II IWM which is not good.

JP3 routes WPROT on pin 19, Not sure what uses that.

Same as JP5 routing GND to pin 7, not sure on that one.

I'm assuming Brad added these to try to support various newer disk types, but not sure without doing more research.

But it should be working for you with nothing jumpered provided your EPROM (U8) is burned correctly.

Yeah, the solder jumpers are basically not to be messed with unless you know you need them. If the schematic doesn't tell you what you need to know, you don't need them.

But anyway, here's some justifications:

JP1 - as far as I know, the floppyEmu is the only device that expects the second drive enable on pin 5, and the Yellowstone is the only other device that provides it. There is no standard place on a 20 pin ribbon cable to put it, and BMOW basically felt this one would be safest. So this is basically a very primitive Yellowstone emulation. There was talk about changing the FujiNet to use this pin as well, so possibly this could standard some time in the future.

JP2 and JP3 - If you use a regular ribbon cable, wired up to a DB19 connector exactly like the Liron's pigtail is, pins 17 and 19 will line up with the DB19 pins 9 and 10.I only use these if I'm hard-wiring a DB19 (or DB25, like an Apple ///+) pigtail, using an IDC-to-board connector.

JP4 - Some rare EPROMs need pin 19 high, that's what this is for.

JP5 - This would normally be an extra ground on a Disk II controller, but it isn't really needed, and this pin corresponds to the /EN3.5 signal on the IIgs and maybe some other systems. So really nothing should need this.

VIBR wrote:

Well, 

After tracing further down in the UNIDISK 65C02 CPU, it is quite impossible to replicate the behaviour, 

I will manage 2MG as hardrive on Smartport, and finalize read write for Disk II & Disk 3.5

Vincent

Sounds like a good decision.  Read/write support for 5.25 is top importance for me.  3.5 is nice to have but not as critical. 2MG as hard drive on SmartPort is fine.

VIBR wrote:

Hello Softwarejanitor, 

I promise I will work on the 5.25 write side, 

The good news is I figured out the issue with the Unidisk (with a litlle help from Riccardo that has been working on a Math Coprocessor using the Unidisk).

 

The trick is that the Firmware ref of IIGS is not fully accurate, 

 

To work the Unidisk is issuing Unidisk

Awesome news!  I will definitely look forward to testing write of DSK and NIB files.  Do you think .PO will work with DSK or is that a separate task?  I think really the only difference is in sector/block ordering so it probably just requires a little different algorithm when calculating offsets.  I assume .DO and .DSK are basically just different extensions for the same format but I could be wrong about that because I've never really seen it said one way or the other anywhere now that I think of it.

VIBR wrote:

I have the right signature prologue and epilogue for the data block

but for the address block I have only D5.AA.96 at the begining and at the end  DE.AA. something and not DE.AA.EB

That behavior was widely-known in the 1980s but it's probably been forgotten.  Depending on the version of DOS, it will truncate the last nibble of either the address block or the data block.

As I recall, the RWTS16 routine does transmit the whole sequence DE.AA.EB to the controller.  But it deactivates Q7 (WRITE_REQUEST) too soon, so only the first two bits are actually recorded.  The RWTS13 routine had a similar bug, except that it truncated the data block instead of the address block.

[EDIT]

My memory was a bit fuzzy, so I turned to my favorite resources -- and they don't strictly agree with my memory (or each other) so here's a list of references:

Beneath Apple DOS  by Don Worth suggests that the entire address block is written to the disk, just not verified during formatting.

"Lastly follows the epilogue, which contains the three bytes $DE, $AA and $EB. Oddly, the $EB is always written during initialization but is never verified when an Address Field is read."

Beneath Apple ProDOS by Don Worth suggests that the entire addres block is not written to the disk, and that's why RWTS does not verify the EB

"Lasdy follows the epilogue, which contains the three bytes $DE, $AA, and $EB. The $EB is only pardy written during initialization, and is therefore never verified when an Address Field is read."

Understanding the Apple II by James Sather gives the most detailed analysis

"An interesting point about DOS formats is the DE AA EB series that follows every address field and data field. Apple has always had trouble writing the EB. In RWTS 3.2 they cut off the EB at the end of the data field by neglecting to wait 32 cycles before switching READ/WRITE to READ after storing EB in the data register. They changed that in RWTS 3.3, so the EB is actually written at theend of the data field. However, RWTS 3.3 cuts off the EB at the end of the address field. Those cut off EBs are not really written, so don't bother trying to read them. RWTS doesn't try either."

VIBR wrote:

Ah perfect, thank so much  I was starting to become crazy !

In addition to those books, I forgot to mention a blogpost titled  Some synchronous nibble captures  in my blog last year.  It shows a typical address mark, and specifically calls attention to the missing "EB" at the end.

VIBR wrote:

Ah perfect, thank so much  I was starting to become crazy !

I tried so many times with different disk card as I was feeling my soft was wrong. I even did count manually the bit on the logical analyzer... so a waist of time, but the good news is I am doing the right thing.

What is the best approach, not to search for the epilogue and consider that there is an epilogue at Byte 11 (Address block 3+8) and 347 (Data block 3+342+1) and using the data checksum  or stil checking for an epilogue during the parsing of the data ? 

What do you think ? 

Ooo!  Back in the 80's I cracked and reverse-engineered a lot of software just for the satisfaction of understanding how it worked inside.

After thinking about actual examples, I think the best approach is not to search for an epilogue as you proposed.  Here are some cases that led me to that conclusion:

• Disk II bootstrap ROM does not require an epilogue at all -- it merely requires the checksum to be valid.  Because the bootstrap ROM is used as a temporary RWTS-substitute prior to ProDOS relocation, this means ProDOS does not require sector epilogues during its early loading.  I don't see any benefit to being stricter than ProDOS's boot loader.
• Gradebook Plus was software for teachers to store their students' grades.  To prevent students from snooping, Gradebook Plus used a non-standard epilogue on their data disks so they couldn't be examined by other programs.  Gradebook Plus was capable of formatting data diskettes and making backup copies with that non-standard epilogue.  So software like Gradebook Plus won't work if you require a standard epilogue.  But it will work if your emulator accepts sectors written with a non-standard epilogue, even if your emulator regenerates a standard epilogue during reading.  (During reading, the software accepts sectors with the standard epilogue or its non-standard one.)
• Ultima V replaced RWTS with "DINKEYDOS" which intentionally omitted the whole epilogue from tracks 3~34 on its boot diskette.  Like Gradebook Plus, it was compatible with both kinds of sectors during reading.

VIBR wrote:

Ok I found the issue, It was the Sector Skewing that was wrong, my bad ...

But now DSK writing is working :) 

 

This is great!  Will there be a new version out there on GitHub that can be pulled for testing soon?  Is it just .DSK at this point or .PO too?

VIBR wrote:

Hello Softwarejanitor, 

I need to do a bit of cleanup of packaging, and I will release a new firmware

 

Nice!  I will be anxiously awaiting it!  This is the main functionality that for me will make your project even more compelling.  It really makes it competitive in functionality with the long time best of breed products like FloppyEmu and wDrive.  And at a significantly lower price point.

VIBR wrote:

Pre-release is available on github 

 

I will grab it and give it a spin in the morning!

I am trying the BETA now.

I am unable to enable 3.5 disk mode. On my IIgs, it just locks up on the boot logo when I select that. Some combination of ejecting the SD card and resetting  and it  regains functionality and it will go to the file listing. However the config seems corrupt after this and I can't regain control of it.

Further resets just go to boot logo and lock up. I have to power it with USB instead of the IIgs to set it back to SmartPort mode to regain control.

Do I need to change any pin config from the original Rev1 board? I never hooked up the 3.5EN pin where it was grounded. 

VIBR wrote:

Well yes, I remove the DISK3.5 pointing to nothing for the moment, I will publish a fix soon

Regarding writing DSK any feedback ? 

Vincent

I haven't had time to test yet.  I've had to be up at 4am every day the past several days for work.  I hope to do some testing soon.

softwarejanitor wrote:

VIBR wrote:

Well yes, I remove the DISK3.5 pointing to nothing for the moment, I will publish a fix soon

Regarding writing DSK any feedback ? 

Vincent

 

I haven't had time to test yet.  I've had to be up at 4am every day the past several days for work.  I hope to do some testing soon.

 

 <

Initial testing with writing to .DSK is successful!