Apple II DISK Emulator using STM32

Very cool project. Unfortunately, I have a problem with my Apple II EUROPLUS with the smartloader. I noticed that if I choose an image, after a restart, the message "ERR 10 UNABLE TO GET DATA" appears. It seems that the selected image is not mounted. The Refresh Boot and Settings functions also seem to do nothing.

I was doing some testing on the Rev 6 board. Generally it is working for most of the time. 

In my initial testing, i hit a few issues with some DSK games images, some games with multiple disks, on Apple IIe with Disk II controller, rev6 board with v0.80.16 firmware. One example is Magic Candle downloaded from asimov ftp (attached disk images below). The same images when written to disks (all same hw config just change to actual Disk II drive) using ADT Pro are working fine. With the emulator it got stucked on Disk 4. Also problem with Centauri Alliance roster dsk file as if wrong disk (also attached), but the same image written onto real disk is fine. I could not get the woz version to even load, possibly corrupted woz images (attached). Strangely, if i load the game with dsk file and use woz image for roster it worked! 

Nonetheless it works with many other disk images like Apple II writer, Karateka II, ADT Pro, Copy II Plus 6.0, Beagle Basic, Apex Diag 4.7, Prodos 2.4.3.po, etc...

Again, thanks Vincent for this wonderful piece of hardware, especially at a fraction cost of the equivalent drive emulator.

test-images.zip

VIBR wrote:

Hello, 

Yes, It happened to me as well, the best would be to have a good PWR regulator on the PCB to fuel the OLED.

Maybe in rev 7

Vincent 

Hi Vincent,

Just a thought, now you have or will have a stable on screen smartloader.

I have suffered in the past with burnin on OLED screens .

I wonder if it might be useful in the options for the oled screen to be blanked if smartloader is desired choice, or blank OLED after say 60 seconds of no update.

Having a dedicated power reulator for the OLED is a very good idea.

Thanks 

Hi Vincent.

Still testing this brillant piece of hardware.

The DISK II part is working just fine.

However, I'm getting trouble with the smartport configuration.

I have loaded a Smartport file (32Mb) but can't boot from the A2. I'm using a SmartDisk II interface (DISK II and smartport in one card). It works fine with the same mounted image on a fujinet.

The emulator beeps once and that's all, no boot. I tried also on apple 2c with DB19 to IDC converter and it just not boot too.

Also, if the file name is less that 6 chars, the display is corrupted as it show the remainig letter of [SELECT] underneath. I mean, if I load the file PART1.PO , then on the oled, I can see : PART1CT]. Not a big deal

I'm using an old rev2 board but modified to complain with rev6 and 0.80.16 firmware

cheers

Does anyone in the US have a board they want to onsell? I'd like to build one but I'm holding off on a jlcpcb or pcbway order right now.

Peter

In post #410, 'PeterKerr' wrote:

" Does anyone in the US have a board they want to onsell? I'd like to build one but I'm holding off on a jlcpcb or pcbway order right now. "

Uncle Bernie comments:

You did the right thing, refraining from ordering PCBs from overseas ... at the time of this writing, 88 (!) countries have suspended (!) all parcel shipments to the USA, causing utter chaos and economic mayhem worldwide, all because of the end of the "deMinimis" rule for imports into the USA.

Due to this, the best option for us is to order PCBs from domestic sources.

I tried OSHPARK with my 'IWMless TEST CARD' and was happy with the quality. But I had to take three of them. BTW, one went to 'VIBR', in hopes he can use it to make his Floppy Emu work with the 'IWMless' in SmartPort mode (the BMOW Floppy Emu works fine with it, so  no doubt 'VIBR' will be able to achieve the same milestone soon).

If you would organize such an OSHPARK order for the PCB, you can count me in, I'd take one. Assuming you need one for yourself, you need only one taker more.

- Uncle Bernie

UncleBernie wrote:

 

You did the right thing, refraining from ordering PCBs from overseas ... at the time of this writing, 88 (!) countries have suspended.....

Thanks for the link to OSHPARK. I haven't tried them before so this should be a good test. 

The repo readme says rev 4 is prod and rev7 is beta. Is there a concensus on what folk are ordering? Should I wait a couple weeks to see how rev 7 goes? I'm not in any particular hurry.

Pete

Uncle Bernie comments:

You did the right thing, refraining from ordering PCBs from overseas ... at the time of this writing, 88 (!) countries have suspended (!) all parcel shipments to the USA, causing utter chaos and economic mayhem worldwide, all because of the end of the "deMinimis" rule for imports into the USA.

Due to this, the best option for us is to order PCBs from domestic sources.

I tried OSHPARK with my 'IWMless TEST CARD' and was happy with the quality. But I had to take three of them. BTW, one went to 'VIBR', in hopes he can use it to make his Floppy Emu work with the 'IWMless' in SmartPort mode (the BMOW Floppy Emu works fine with it, so  no doubt 'VIBR' will be able to achieve the same milestone soon).

If you would organize such an OSHPARK order for the PCB, you can count me in, I'd take one. Assuming you need one for yourself, you need only one taker more.

- Uncle Bernie

 ===

been using pcbway with no issues to the u.s.a.  just the damned tariffs are the main issue of doing overseas business.

//kneehighspy

Hi,

No, that didn't change.

It display a symbol of a disk in the top right corner and RD on the line 1 where the partition is loaded but still no boot (even PR#5). I tried the double reset with no more luck. My fujinet is working fine at the same end so no issue with the smartport card nor cable.

That's not a big deal as my plans is to use mainly with floppy emulation.

Also the display is still incorrect (superposed chars of the name of the file and [SELECT] ) .

cheers

IMG_20250922_201335.jpg

The filename is PART1.PO but displays as PART1CT] 

Also, not booting from smartport mode

VIBR wrote:

Ok I will investigate and revert back, 

is the booting issue on every PO image ? 

Yes, on every PO image. 

Hi,

Yes, no matter what I load, (.PO, .HDV...). It doesn't boot. Tried also on an Apple 2C still same issue.

thanks 

VIBR wrote:

Which version are you using ? 

Is it working on IIGS ? 

   version:  Firmware_SmartDiskII_v0.80.20.UF2_.zip  

   PCB: 4 and 6 

   Yes, it is working on IIGS.

  and yes, it is booting from another smartport emulators (Apple IIc (version 4))

Hi,

Yes used 80.20 beta version. I tested on a 2c (rom4x) and a 2e with softSP card.

I will test on my 2GS asap.

I used multiple images (.PO or .HDV)

thanks

VIBR wrote:

so not working (booting) on IIE & II+ with Liron / SP card right ?

Thanks

vincent 

    does not booting on IIE + Liron 

In post #425, 'jonnixx' wrote:

"... not booting on IIE + Liron "

Uncle Bernie comments:

Make sure that your Apple IIe has firmware-in-ROM that actually "boots" from a Liron card.

The "EF" ROM should have the number "-0303" at the end

The "DE" ROM should have the number "-0304" at the end

The ROMs can be replaced by 2764 or 27C64 EPROMs of any speed grade and the ROM images can be found on the web.

When I experimented with my 'Liron' substitute cards (having the 'IWMless' instead of the original IWM) in Apple II and Apple IIe I saw a lot of wonky and unpredictable behavior even when using the BMOW Floppy Emu which runs TOTAL REPLAY  perfectly fine on an Apple IIc equipped with the 'IWMless'.  So the latter combination proves that it should work, but if it doesn't work in the IIe or the II+ then something is different with these machines, and I suspected the firmware ROMs. After changing the ROMs in my Apple IIe, it did boot TOTAL REPLAY  from an emulated "Smartport" HDD but crashed after a while. After I replaced all the DRAM in the 80 column / memory expansion card, it didn't crash again, except for the "Serpentine" game demo mode hanging at exactly the same point as usual.

I also observed that TOTAL REPLAY on the Apple IIe, booted from a 'Liron' substitute card, is very finicky with the slot number and the drive number, I got it working when the floppy emu was plugged into drive #2 (my 'Liron' substitute card has two normal 20 pin connectors as this makes more sense than the elusive DB-19 seen on the original 'Liron' card).

I do have an original 'Liron' card but I never could boot anything with it even on the upgraded Apple IIe. I first suspected the original 'IWM' in it to be defective, and desoldered it, just to find out it's good, as it works in my other cards. Had no time yet to desolder the EPROM, too (EPROMs sometimes have bit rot, but a software checksum did not show an issue).

So it is yet unknown to me why my original 'Liron' card failed to boot.

So far the findings on Apple IIe. For Apple II, it's even more hopeless. But this could be due to some wonkyness of the motherboard - I saw DISK II cards failing to boot and after a lot of investigations into the DISK II card seeking bad ICs I found none. And then the "bad" DISK II card worked again ... for a while. It turned out that wiggling the card on the slot connector made it work again, but only for a while, before it failed again.

This said, we are dealing with a multitude of problems here:

1. 40+ year old wonky hardware (including the notorious uT4264-15 DRAMs which often fail)

2. bug ridden early firmware ROMs which Apple fixed later

3. bad contacts in slot connectors

4. undocumented quirks in the 'Smartport' system (hardware quirks and software quirks)

I suspect that 'VIBR' fights with point #4 above because I saw so much unexpected and weird behaviour with 'Smartport' when debugging my 'IWMless' design that I came to the conclusion that most likely, the 'Smartport', if it works, does not work 'by design' but by some evil software hacks which were just tried out (pretending to make a botched design "work") but nobody understood root cause (me included). They never updated the sparse documentation on how 'Smartport' is supposed to work. And once it appeared to "work", after the hacks were found by trial-and-error, it looks as if they never dared to touch any of their code anymore, lest it would explode into their faces.

The consequence of this is that anyone who wants to implement 'Smartport' functionality has to go the same "trail of tears" with lots of trial and error until it "works".

I can't rule out that Apple (the corporation) had some internal documentation which specified the 'Smartport' system in a way that was up to industry standards, but if so, this documentation never was leaked and can't be found on the internet. The 'ASCII Art' drawings in the "Protocol Converter" source code are not fit to design a robust communication system from them. A real communcation system with asynchronous events needs much, much more elaborate specifications of the timing, the data transfer protocol, the error detection and correction methods, which include rules for timeouts and their handling with retries. Even relatively simple real communcation systems I've encountered in my career had documentation / specifications spanning several hundred pages. And these did work reliably, if correctly implemented according to these elaborate specs.

It seems to me that the 'Smartport' is a sort of botched design with a poor implementation and side effects from the asynchronous nature lurking everywhere. And this requires a lot of testing, and "hacking" to eventually find a solution that works sufficiently well to be useful (at least to run the TOTAL REPLAY demo, I would not trust it with storing real work).

So don't give up, but be aware of the nature of this "beast".

Good Luck !

- Uncle Bernie

UncleBernie wrote:

In post #425, 'jonnixx' wrote:

 

"... not booting on IIE + Liron "

    Okay.

    I have tested again: (and so sorry my mistake )

    - Apple IIe + Yellowstone card : booting automatically (smartport mode)

    - Apple IIe + Liron : does not boot automatically, BUT booting with: PR#5  (smartport mode)

    - Apple II GS: booting (smartport mode)

    - Apple IIc (ROM 4x): does not boot, BUT BMOW in smartport mode and other smartport emulator are booting correctly and automatically 

Hi,

Here's my contributions :

Apple 2C with ROM 4X : no boot on Smartport (Fujinet boots fine)

Apple 2E with SoftSP (Disk II card) : buzzer beeps once but no boot on smartport (Fujinet boots fine). PR#5 gives I/O ERROR 

Apple 2GS : no boot device (Fujinet boots fine)

As said, it is not big deal as I use it mostly for floppy emulation and not smartport emulation.

cheers

VIBR wrote:

Hello Guys, 

Could you please test this firmware, 

It should work on IIe with SP, IIc and IIGS 

    Hi,

    It is works fine on Apple IIc ROM 4X with PCB rev4 and rev6.

   and  still works on IIGS.

   and still works for IIe.

    Regards,

    Arpad

VIBR wrote:

Hello Guys, 

Could you please test this firmware, 

It should work on IIe with SP, IIc and IIGS 

Thanks 

Vincent 

I will test it with a LiRON card and with Uncle Bernie's IWMless test card.

VIBR wrote:

Hello, 

I was finally able to assemble Uncle Bernie IMLESS test card,

SmartDisk is just working fine with Smartport emulation when issuing PR #5

However, when doing PR #6 with regular disk II emulation, I have an error no device connected. 

Same as the SmartDisk II card from BTB, is this normal ? 

Thanks

Vincent 

The current firmware for the IWMless Test Card is I believe that of the LiRON card, which doesn't have 5.25" boot code in it.  I know that integrating support for both 5.25 and SmartPort is something that Uncle Bernie wants to do but it is not a trivial problem to solve.

So yes, I think it is working as it should at this time.

In post #434, 'VIBR' wrote:

" I was finally able to assemble Uncle Bernie IWMLESS test card,

SmartDisk is just working fine with Smartport emulation when issuing PR #5

However, when doing PR #6 with regular disk II emulation, I have an error no device connected."

Uncle Bernie comments:

First, congrats that you finally got your 'IWMless Test Card' to work. It will help you to make your 'SmartPort'  emulation perfect (read: 100% 'IWMless' compatible). I think this is very important. Because more and more Apple IIc will be repaired with the 'IWMless' in the near future (I have a prospective manufacturer who wants to produce and sell it).

(Just for those who now would start to worry why I wrote  'IWMless' compatibility and not 'IWM' compatibility: the original IWM has a fatal hardware bug well documented by Apple, which never was corrected in the silicon, and this forced them to advise Apple IIe users who bought a 'LiRON' card to change their NMOS 6502 against a CMOS 65C02. IMHO Apple's reasoning behind this band-aid is  v e r y  dubious. Because just having regenerative latches on the data bus (the 65C02 has them, the NMOS 6502 does not have them) will NOT reliably fix the data bus setup time issue caused by the IWM bug. But it may bring error rate down enough to make the 'LiRON' card usable. As I have fixed that bug for the 'IWMless', no such CPU substitution is necessary. But the fix also introduces a slight timing difference between the 'IWMless' and the original IWM, and this is not only the now bug free data bus timing: the bug fix may cause a read data byte to become visible to a polling loop one round trip through the loop earlier or later ... actually it's just one 6502 CPU cycle earlier or later. So, there may be a 1 CPU cycle difference which may throw marginal "SmartPort" routines off track. And I do fear that the whole "SmartPort" software written by Apple may be littered with marginal code which just barely works, very likely due to "hacking" it until it "worked", and not due to proper procedure. And one clue for that conjecture of mine is that Apple did not dare to fix the hardware bug in the IWM silicon. It would have been a trivial fix. And they had the chance to do this when they made the Rev. B silicon of the IWM, which was a full mask redesign. But for some reason, they did not dare to fix that nasty bug, and continued to recommend the CPU swap. A bad sign. This is why we must be prepared to "massage" any SmartPort emulation such that it works despite of all these issues. From my level of insight, this may hinge on +/- one 6502 CPU cycle in timing difference which may make or break the 'SmartPort' . . . be aware of this).

The PR#6 not working is normal, same behaviour seen with the original 'LiRON' card, it's a matter of the firmware on the card. But I have designed the 'IWMless Test Card' such that it can take larger EPROMs like the 2764 or 27128 and there is one uncommitted address line with a pullup (or pulldown ?) resistor which could be wired to a switch to select one of two banks of firmware. I added this feature exactly for the problem with not having the standard DISK II bootstrap code in the 'LiRON' firmware. Send me a PM to learn more, I can look the details up.

For testing 'SmartPort' on the Apple IIe, I used TOTAL REPLAY booted from slot #5. Alas, the "Serpentine" game demo always hangs at the same point (one of the "worms" going around the first corner) and this does not allow to run the test forever and ever. However, I did confirm that this bug is due to "Serpentine" itself, and not due to the 'IWMless': I plugged an original and known good IWM into the 'IWMless Test Card' . . . but to make an original IWM work in it, you must open a trace which shorts the last of the 390 Ohm resistors. This short must be put back (solder in a wire) to use the 'IWMless' again. This is just a RC delay to defuse a critical race between the 7M and the Q3 clocks, which has been lurking in the Apple II since the beginning, but did not manifest itself until slot cards used both clocks at the same time (the 'LiRON' was the first one I know of).  'IWMless' has the RC (and a Schmitt Trigger) on its PCB so it does not need an additional resistor.

One weird thing I saw with TOTAL REPLAY running on the Apple IIe is that it sometimes tries to access drive #1 and drive #2 alternately. I also got the impression it prefers to run with the 'SmartPort' being drive #2 of slot #5 and a real DISK II card being present in slot #6. But I'm not sure if this requirement I see with my old PAL Apple IIe is not due to the 40+ year old computer being too wonky / unreliable. The permanent problems with unreliability in my own Apple II specimen was one of the reasons why 'softwarejanitor' also got a 'IWMless Test Card', since he does have more Apple IIe specimen which do work better than the mine, and he also has a 'VIBR' Floppy Emu ;-)

In post #435, 'softwarejanitor' wrote:

" The current firmware for the IWMless Test Card is I believe that of the LiRON card, which doesn't have 5.25" boot code in it.  I know that integrating support for both 5.25 and SmartPort is something that Uncle Bernie wants to do but it is not a trivial problem to solve."

Uncle Bernie comments:

Correct. The 'IWMless Test Card' (of which only three exist in the world ;-) uses a 1:1 copy of the original Apple 'LiRON' card firmware. And although I do not plan to further develop the the 'IWMless Test Card' (it was only meant for testing the 'IWMless' in a LiRON environment, without need to desolder a good IWM from an original LiRON card) I have some long term plans to make a LiRON substitute card but without an 'IWMless' on it ... instead, I will use ispLSI1016 in PLCC-44 which are easier to solder, or may use a socket. The RTL inside may be the same or slightly altered. I don't know yet how to implement the data bus clash protection in the most efficient way. I could add one input to the ispLSI1016 (the R/!W from the slot) and add one factor to the output enable term, and it's done. But I don't know whether the fitter can do that ... so far any attempt to modify the current RTL blew up in my face, as the design does not fit anymore, even after such a trivial addition. But if might be possible to get a fit if I allow the fitter to shuffle pins around. But if this fails, the data bus clash protection will be done in a GAL which replaces all the TTLs of the LiRON. In this case I can't ditch the 74LS245.

One of the "not trivial" problems to solve is how to fully support the 5.25" drive on that planned card. It looks to me as if Apple never meant the 'LiRON'  to substitute the DISK II card.  But having absolutely no documentation by Apple, this is just a conjecture: in a typical Apple IIe, you would keep the DISK II card in slot #6 and put the 'LiRON' in slot #5. Attach the 3.5" disk drive unit to the LiRON and enter PR#5 and it would boot from the 3.5" disk. So far my conjecture.

The complication is how to put two slot cards into one. Each Apple slot has a specific slot # with its individual control signals to activate the card only in slot  specific address ranges. So to have a traditional DISK II substitute function in slot #5 and a LiRON substitute in slot #6 means that the card must make substitutes for the control signals it does not have on the slot it is plugged into. And the scenario changes depending on which slot that card actually is plugged into. And the firmware of the non-bank-switched 256 Byte page must adapt to the particular slot, too. I've seen some third party floppy disk cards for the Apple II which had seven different such pages in their EPROMs. But this was for only one function, the 5/25" disk drives. Add the 'LiRON' start page and it gets tricky ... how can the card know which kind of peripheral it needs to support ?

I think this can be solved with a lot of head scratching and careful planning, but at the moment I'm too busy with other projects to work on that topic. Still, I'm glad that 'VIBR' finally has his own 'IWMless Test Card' and this will enable him to make his Floppy Emu's 'SmartPort' functions 100% compatible with the 'IWMless' - which the BMOW Floppy Emu already is.

Keep up the good work !

- Uncle Bernie

UncleBernie wrote:

In post #434, 'VIBR' wrote:

 

I never remember to have experienced any problems with Apple Liron card and NMOS 6502 CPU. I set up the following configuration to do two tests at once:

An Apple //e Platinum motherboard with a SY6502 and a "PAL" 50Hz framerate CM632 IOU, and an original 344-0010-C MMU , a 512K RAMWORKS  (a Pravetz RAMWORKS clone), an original Apple Liron card with an original 344-0041-B IWM, and a Liron 3.5" 800K A2M2053 drive with a real physical diskette with the following on it: "serpentine 18k file PRODOS (san inc crack).po". The diskette image is available for downlaod from "mirrors" web resourse. I am using a SMARTPORT floppy drive beacause my place is free from any SMARTPORT  floppy/hdd emulators, e.g. the A2M2053s are the only SMARTPORT type of  drives I have.  For Total Replay I am using my Apple2 SCSI card clones and physical HDDs, with which Serpentine demo is stable for days  (I already checked that in the past when the problem was mentioned here). With the present  configuration I am NOT experiencing any freeze or abnormalities with Serpentine game demo left for hours. Will keep you updated if the freezing problem occurs on this computer which I am planning to leave like this for days.  Let me know if  you want me to put back the 65C02 and restart the test. 

UncleBernie wrote:

In post #434, 'VIBR' wrote:

 

" I was finally able to assemble Uncle Bernie IWMLESS test card,

SmartDisk is just working fine with Smartport emulation when issuing PR #5

However, when doing PR #6 with regular disk II emulation, I have an error no device connected."

 

Uncle Bernie comments:

 

First, congrat

I agree that Apple never intended the LiRON to replace a Disk ][ Controller or Apple 5.25 controller card, it was strictly sold for use with the Unidisk 3.5.  I recall reading that Apple only recommended the LiRON for Enhanced //e but I think it was because I don't think the original ROM could boot automatically from a 3.5" drive, maybe not just because of the 65C02.  Certainly the normal way of installation was the LiRON in slot 5 and the 5.25 drives in slot 6.  That mimicked the way things normally were with the //c and IIgs so a lot of software would make that assumption even if it wasn't really absolutely required to do it that way.  You could certainly put the LiRON in slot 7 to force power up boot from a 3.5 drive (and I would expect tslot 7 to be common if someone used something like a Chinook hard drive with a LiRON back in the day), or even to run w/o 5.25" drives and have the LiRON in slot 6, although I suspect few did that on any regular basis because so much software expected 5.25 in slot 6.

As expected by me the Serpentine still runs after 24 hours in the test announced in my post above. The system is rock stable. I forgot to mention the computer for the test was powered by a generic Asian PSU from an apple2 clone  (with the same form factor as the Apple PSUs have). The PSU was last time serviced by me some 15 years ago, when I was given it, and the problem lied in a medium current rectifier diode on the negative voltages side and only one filter low-voltage electrolyte capacitor had to be replaced. 

In post #437, 'transwarp2' wrote:

" ... an original Apple Liron card with an original 344-0041-B IWM, and a Liron 3.5" 800K A2M2053 drive with a real physical diskette with the following on it: "serpentine 18k file PRODOS (san inc crack).po "

Uncle Bernie comments:

This is not the same test setup as I use where 'Serpentine' freezes. So you don't have the same experiment, and can't expect the same outcome.

I use a PAL Apple IIe, with 128k RAM, a BMOW Floppy Emu in 'SmartPort' emulation mode, with the most recent image of TOTAL REPLAY found on the internet archive, and either a real 'LiRON' card or my 'IWMless Test Card' in slot #5 - slot #6 still has a DISK II card in it. In this configuration, TOTAL REPLAY boots and runs fine and goes through all the automatic demo modes of the games and this goes on for hours until the automatic demo mode of 'Serpentine' starts. Once the first "worm" turns around a corner, the game freezes. And this ends the test session. This happens with either the 'IWMless' or the original IWM Rev.A or the original IWM Rev.B in either the original 'LiRON' card or the 'IWMless Test Card', so it is certainly not an issue with the 'IWMless'. The 'Serpentine' freeze does not occur if the experiment is run on an NTSC Apple IIc with either the original IWMs or the 'IWMless'.

We need to keep in mind that all games on TOTAL REPLAY are "4AM cracks" which enables them to be aggregated into such a humongous piece of software. Some of the cracks may not have been tested with all versions and configurations of Apple II machines. Your "san inc" crack is a different animal.

'SERPENTINE' FREEZE NOT CAUSED BY 'IWMless':

As I came to the conclusion that the 'Serpentine' freeze is not caused by the 'IWMless', I did not spend any further time on investigating it. I'm not interested in playing games or watching their automatic demo modes, I'm only after a test suite for the 'SmartPort' functionality of 'IWMless', which I can start und let run for weeks without any further interaction. TOTAL REPLAY seemed to be a great candidate for this, because it does have sensitivities if 'SmartPort' does not work well enough, and this manifests itself by TOTAL REPLAY hanging / crashing. Which means that the 'SmartPort' routines in TOTAL REPLAY are not 100% robust and they are unable to handle communication errors with the 'SmartPort' device in at least some situations. Which is a welcome "bug" as it helps in my use case: unless the 'SmartPort' functionality of 'IWMless' is clean, there will be random crashes. This is not exactly the "professional" way to check a communications channel, which would involve attaching a "communications channel analyzer" which also can inject errors and imperfections (such as dialing down the "eye opening" of the signals) and after running this instrument on a channel for a while you get a bit error rate. Alas, for the 'SmartPort', due to its proprietary nature, no communications channel analyzer can be bought or borrowed. So everything we can do to check 'SmartPort' devices is empirical and not exactly engineering based on measurements. But I did some experiments with injecting random bit errors in either the read or the write channel to see what happens in case of errors. And I was not impressed by the mediocre robustness of Apple's own 'SmartPort' firmware routines in the Apple IIc. They seem to be able to recover from some corrupted bits in some parts of the 'SmartPort' protocol, but I also saw cases where injected bit errors led to crashed boots or loads of corrupted data without any error message or warning. This is no good ! Any communications protocol should have reliable error detection and correction mechanisms built in, and it should never ever accept corrupted data as being "good". This is why I deem Apple's 'SmartPort' to be botched. And the proof for this is that they abandoned it.

ON THE NMOS 6502 vs. CMOS 65C02 SWAP AFFAIR:

As for the NMOS 6502 vs. CMOS 65C02 substitution, I also ran experiments on how bad the data setup time bug of the original IWM is on the NMOS version. But without a communications channel analyzer, no bit error probability numbers can be attached to it. What I saw is that with older, slow NMOS 6502 (rated for 1 Mhz clock speed) from the 1970s I got the occasional crash of TOTAL REPLAY. With faster NMOS 6502 (rated for 3-4 Mhz clock speed) I saw not a single such crash (other than the 'Serpentine' freeze, which is unrelated to the data setup time bug). The reason for this behaviour is that the read data setup time for the slower 6502 is violated by the original IWM, while the much shorter read data setup time of the faster 6502 is NOT violated. Apple internal documentation available on the internet does not explain this from a data setup time standpoint, but they must have spent considerable time to analyze the problem, as they have found out exactly what happens: in the NMOS 6502, the "N" (for "negative") flag has a different setup time referred to the end of the PHI2 cycle than the data path within the 6502 has. So when the IWM presents a "finished" byte, where the MSB is set, then the bug (which stems from the "port mode" of the IWM) first presents the byte with MSB cleared, and then sets the MSB one 7M clock later - which is the data setup time violation - and so the "N" flag may get set while the MSB of the byte ending up in a CPU register may have the MSB still cleared, which implies that the data path setup time is higher than then "N" flag setup time. The other seven bits of the byte in the CPU register are OK. But the typical de-nibbelizing lookup table assumes MSB is set. And consequently, any such MSB mismatch will turn the byte read into garbage. Apple even suggested a software based remedy in one of their technical briefs: just add "ORA #$80" before the "TAX" and "LDA table,X" in the read loops. Which fixes the problem. But for some reason, Apple still recommended the exchange of the NMOS 6502 with the CMOS 65C02 for 'LiRON' users. In my eyes this indicates that the dimension of the problem (having relased such a botched and bug-ridden peripheral system to the field), in the opinion of Apple, was severe enough to justify spending a lot of time (= money) into analyzing the root cause and to elucidate the exact fault mechanism, and to go for the swap of the CPU, which must have been very embarassing to Apple, as any desperate measure like that never looks good in the eyes of the public and may worry the affected users about the professionalism of the company. As far as I'm concerned, I decided to fix this bug, and so the 'IWMless' does not have it. But consequently, 'IWMless' can't do "port mode" (never was used by Apple in any product, so they shot themselves in the foot for nothing) without adding an extra D-Flipflop, to achieve the same ends.

Here is the link to the TOTAL REPLAY archive page:  

https://archive.org/details/TotalReplay

I would be interested if this version of TOTAL REPLAY does not have the 'Serpentine' freeze on any Apple IIe, and if so, which exact hardware and firmware configuration is used. If such a solution without the 'Serpentine' freeze is found, I could resume long term tests of various Floppy Emus with the 'IWMless' - including the 'VIBR' Floppy Emu of this thread which recently seems to have reached a state of development where 'SmartPort' works well enough to justify that I spend  my  time to test it with my machines.

- Uncle Bernie

UncleBernie wrote:

In post #437, 'transwarp2' wrote:

 

" ... an original Apple Liron card with an original 344-0041-B IWM, and a Liron 3.5" 800K A2M2053 drive with a real physical diskette with the following on it: "serpentine 18k file PRODOS (san inc crack).po "

 

Uncle Bernie comments:

 

Your "san inc" crack is a different animal.

It is not mine, it is san inc's! You underestimate me again,  but I am not estimating you as high as you estimate yourself.  Your selfesteem resembles that of my father (A great engineer of his time which equipment flew for decades in Space, I miss him now for the third year).  Here are the facts:

The san inc cracked Serpentine is bound within Total Replay:

https://github.com/a2-4am/4cade/tree/main/res/dsk

In post #441, "transwarp2" wrote:

" The san inc cracked Serpentine is bound within Total Replay:

https://github.com/a2-4am/4cade/tree/main/res/dsk

"

Uncle Bernie comments:

Oh, I did not know that "4AM" used a third party crack of "Serpentine". If he indeed used  the "san inc" crack then the "Serpentine" freeze in TOTAL REPLAY is not the fault of his own (4AM) crack, but he is still guilty of including a faulty crack in TOTAL REPLAY which does not work on all machines. This "freeze" has been confirmed by others, so I'm not seeing phantoms and it's not due to a possible hardware issue with my own Apple IIe.

Please put any further comments on the "Serpentine" freeze in the appropriate thread, which is this:

https://www.applefritter.com/content/asking-you-do-small-experiment-needs-liron-card-or-clone

... as it's a bit off-topic for VIBR's Floppy Emu thread, but still, the use of TOTAL REPLAY as a test case for "SmartPort" does have its place here in this thread, and the "Serpentine" freeze must be made known so as to avoid false alerts from experimenters who run  TOTAL REPLAY with VIBR's Floppy Emu and see the "freeze".

- Uncle Bernie

UncleBernie wrote:

 

 

Serpentine" freeze in TOTAL REPLAY is not the fault of his own (4AM) crack, but he is still guilty of including a faulty crack in TOTAL REPLAY which does not work on all machines. 

The crack is perfect, the game is NOT freezing when ran "stand-alone" under ProDOS. Please note the san inc crack was "polished" later by 4AM when the game was included in Total replay. The bug is either with the Total Replay loader, or with your IWM emulation hardware. You (or anybody)  could build a short version of your own Total replay from github sources with a game or two only, the Serpentine included, to make faster tests. 

transwarp2 wrote:

UncleBernie wrote:

 

 

Serpentine" freeze in TOTAL REPLAY is not the fault of his own (4AM) crack, but he is still guilty of including a faulty crack in TOTAL REPLAY which does not work on all machines. 

The crack is perfect, the game is NOT freezing when ran "stand-alone" under ProDOS. Please note the san inc crack

The freeze only seems to occur when Serpentine is run from Total Replay, and it doesn't happen on both of the //e that I have been using for testing, only on one.  That one also freezes up occasionally in other places with even a real LiRON card or with a Dan ][, so I'm pretty sure that IWMless is not the issue.  The demo code when Total Replay is running that way is Total Replay specific so running the original San Inc crack from a disk image isn't an exact test.  As you suspect, I believe it is probably something in the Total Replay loader.

softwarejanitor wrote:

The demo code when Total Replay is running that way is Total Replay specific so running the original San Inc crack from a disk image isn't an exact test.

Start a debugger and prove what you are saying with facts. The rest is bla-bla as are your last two messages in this topic. 

transwarp2 wrote:

softwarejanitor wrote:

The demo code when Total Replay is running that way is Total Replay specific so running the original San Inc crack from a disk image isn't an exact test.

 

 

 

 

Start a debugger and prove what

Actually all of your messages in this thread are largely "bla bla" as you have proudly stated that you don't even have one of VIBR's floppy emulator devices or even a FloppyEmu let alone an IWMless Test Card.  So you are just talking about Oranges instead of Apples when you run Serpentine from some other image using some other hardware.  As I've said, I can run Serpentine from a different disk image than Total Replay using IWMless and it does not crash.  I don't need to use a debugger to know that means it has to be something specific to Total Replay.  And anyway, a debugger in an emulator would do no good for testing hardware and even if I had a hardware debugger card, introduction of such into the system would undoubtedly change cycle timing enough that it would possibly make any results dubious anyway.

transwarp2 wrote:

UncleBernie wrote:

 

 

Serpentine" freeze in TOTAL REPLAY is not the fault of his own (4AM) crack, but he is still guilty of including a faulty crack in TOTAL REPLAY which does not work on all machines. 

The crack is perfect, the game is NOT freezing when ran "stand-alone" under ProDOS. Please note the san inc crack was "polished" later by 4AM when the game was included in Total replay. The bug is either with the Total Replay loader, or with your IWM emulation hardware. You (or anybody)  could build a short version of your own Total replay from github sources with a game or two only, the Serpentine included, to make faster tests.

That is not true. The "stand-alone" version under ProDOS that is included in Total Relay starting from v5.0 does crash with the Dan ][ Controller.

As part of this investigation I determined that the crash was introduced in version 5.0 of Total Replay, with the last version not containing the crash being version 5.0-beta.3. If we look at the history of the file res/dsk/serpentine 18k file PRODOS (san inc crack).po, we see two changes after the last good version:

SerpentineHistory.png

I am attaching a ZIP archive containing the standalone ProDOS versions of Serpentine from Total Replay 5.0-beta.3, 5.0 and 5.2 for anyone who wants to test them: Serpentine from Total Replay.zip

When used by themselves on my Apple IIe with a Dan ][ Controller, they exhibit the following behavior:

   Serpentine from 5.0-beta.3 - GOOD.po - works perfectly.

   Serpentine from 5.0 - CRASH.po - crashes with a black screen.

   Serpentine from 5.2 - CRASH.po - crashes with a black screen and a beep.

Nice work CVT.  That pretty much confirms that it is a problem with Total Replay.  I will pull a copy of the older version or build a new one with the older version of Serpentine in it and see if I can reproduce it working correctly.  The weird thing is I have at least one //e where it actually works.  But the other one I have been using for testing is as you describe.

The information provided by 'CVT' in post #447 above provides very valuable insights into the "Serpentine" freeze - so anyone who chooses to use TOTAL REPLAY to test the 'SmartPort' feature of  VIBR's floppy emu  gets confidence it's not the floppy emu who is the culprit.

I think that TOTAL REPLAY is currently the best means to test the robustness of the 'SmartPort' functionality of any floppy emu - just because TOTAL REPLAY loads huge amounts of data via 'SmartPort' and this exercises the hardware and software platform, regardless which one.

Here is "The Way":

Just run TOTAL REPLAY in its automatic demo mode, using your hardware platform, and your choice of floppy emu.

Expect that 'Serpentine' will freeze at exactly the same state of its auto run demo, when the "worm" just starts to go around the corner. You  may take a photo of that state with your digital camera, just as a memory aid. Then restart / reboot TOTAL REPLAY.

It will "freeze" in 'Serpentine" at the same spot, again. We shall call this "normal".

But ... and this is the important part ... if TOTAL REPLAY crashes / freezes  anywhere  else, this is suspicious as it might point to a problem with the reliability of the 'SmartPort' implementation.

If you find this case, take a screen shot, and post it here in this thread, and state which hardware configuration you did use, model of Apple II, firmware ROM revision (the Apple part # on the "CD" and "EF" ROMs) and which slot cards are in which slot.

This will help greatly with making this Floppy Emu the best possible. IMHO,  'SmartPort' is a botched system, so there will be pain, but at the end of the development road, we will have the best solution possible for it.

- Uncle Bernie

Obviously the San inc crack is perfect but when 4AM modified it it became buggy. 

transwarp2 wrote:

Obviously the San inc crack is perfect but when 4AM modified it it became buggy. 

This appears to be correct.  I can run Serpentine from a floppy image with the San Inc crack without problem but when run from Total Replay it crashes on one of my //e every time, even if you go directly to it and not letting the demo run.  And even when run from a Dan ][ card, so it isn't specific to SmartPort. On the other //e I've been using for testing it works from Total Replay using LiRON, IWMless Test Card, etc.  I don't know for sure how the two machines differ since they're both enhanced //e.  I've even swapped CPUs and a few other things.  That inconsistency is probably why ithe introduced bug got past 4AM's testing I guess.  Maybe it works for him on the machines he is using.