Asking you to do a small experiment (needs: Liron card or clone)

In post #2, "Wayne" wrote:

" The Floppy Emus don’t have the currant firmware though I can update it if need be. "

Uncle Bernie advises:

Best approach is to NOT update your floppy emu before running the experiment. I had updated the mine to the latest revision released by BMOW and TOTAL REPLAY did freeze. Although I think that it's probably not the fault of the floppy emu, if you run the experiment with the previous floppy emu firmware, and there is no freeze, then we would have proof it's either the floppy emu firmware revision or my particular specimen of Apple IIe which causes the "freezes".

- Uncle Bernie

But before the praise, here is a hint for those struggling with setting the BMOW Floppy Emu to HDD mode:

In post #11, 'softwarejanitor' wrote:

" I'm not sure what I've been doing wrong, but perhaps my LiRON is bad or I have the wrong firmware version on my FloppyEmus because I can't see anything in the menus to put them into SmartPort mode."

Uncle Bernie comments:

The BMOW Floppy Emu can be put into HDD mode by a few button presses (on it) with no interaction from the Apple II except for providing power. How that works I don't remember - it's written somewhere in the BMOW manual how to do this, it's essentially setting the SmartPortHDD emulation mode and then navigating to the folder in which TOTAL REPLAY is.

No DOS needed to launch TOTAL REPLAY !

I've put my Liron clone into slot #5 of my own Apple IIe (a PAL Euro-Apple, ouch !) after I took the MMU out from softwarejanitor's loaner (NTSC Apple IIe) and put it into my machine. BMOW Floppy Emu connected, system powered up, RESET to get into BASIC, and then PR#5 to run the firmware in slot #5. Which in my case booted TOTAL REPLAY 5.2 just fine and it ran for maybe 4-5 hours, cycling through all the games (automatic demo mode, being lazy, it's the best way to exercise the SmartPort functionality). But it "froze" in the game "SERPENTINE" at this state, just after the start, when the left hand side "worm" began turning around the corner:

Serpentine_Freeze.jpg

How to kill a "Liron" clone, a BMOW floppy emu, and an 'IWMless' (don't try this stunt yourself):

I then replaced the 'IWMless' in the Liron clone with a real IWM and repeated the experiment, and got exactly the same "freeze". After that, I wanted to launch a new experiment (the Liron clone with an 'IWMless' in a Taiwanese Apple II clone with a 40 year old switchmode power supply), but, alas, when I turned on the power there was a flash in the vicinity of the Liron card and a "zap" sound. That was at 2 AM in the morning, and I was too tired (and too frustrated) to investigate what went wrong. Went to bed and got some good sleep. Next morning revealed no obvious hookup fault, but both the Liron clone and the BMOW floppy emu were found dead as a doornail. The takeaway from this is to be careful when plugging together a new hardware configuration. And never plug in your floppy emu before you have confirmed the Liron card does not blow up in that machine --- the idea behind this is that if something goes wrong and blows up the Liron card, at least the Floppy Emu is safe and sound).

How to recover from catastrophy and how to proceed !

I proceeded to order a new BMOW Floppy Emu, repaired the Liron card (the 'IWMless' was dead, too) and put the dubious Apple II clone back into the basement, with a warning sticker on its 40 year old power supply, which never has been opened before. Now I had nothing to do anymore . . . no test platform which could give me more insights. At this point I was not sure if I could repair the IIe motherboard 'softwarejanitor' had loaned to me as "defective, but MMU good". I started this thread. And then proceeded to do surgery on softwarejanitor's IIe motherboard, which was successful, and it came back to life.

Now I have a functional NTSC motherboard and a new BMOW Floppy Emu will arrive this Tuesday. Then I will repeat all the experiments for which the various contributors to this thread found out that TOTAL REPLAY works without "freezing". The difference: it will be an 'IWMless' in the Liron clone (no worries here, I have built a dozen 'IWMless', plenty of "lab rats" and of course the ones designated for the beta testers).

Thank you very much !

Y'all have been tremendously helpful with your contributions, we all know now for sure which hardware setup is supposed to work with TOTAL REPLAY. This is invaluable for my 'IWMless' test program because one "unknown" factor was eliminated. Cross your fingers that the 'IWMless' works with the hardware configurations you have found out.If it does, I will launch the 'IWMless' beta test phase immediately after this experiment succeeded.

- Uncle Bernie

P.S.: Of course, you can go on with your investigations. You may even try to catch "Serpentine" in its attract mode phase (there also are "Serpentine" screenshots but static, no game code running). I spent hours sitting in front of the machine, reading a book, until "Serpentine" came up and "froze", just to be sure that it did "move" at all before the "freeze".

P.P.S.: The PAL / Euro-Apple IIe may be the culprit for the "Serpentine" freeze but I seem to have a dim memory  that somebody, somewhere on the internet, long ago, posted a photo of his Euro-Apple  IIe running TOTAL REPLAY, so I thought it should work. The culprit is not the firmware-in-ROM which is different for the PAL versions . . . after the first "freeze" I put the ROMs from 'softwarejanitor's IIe into my Euro-Apple IIe and got the same "freeze". And a messed up keyboard layout.

In post #17, 'CVT' wrote:

" All you have to do is type "ser" to get to the Serpentine title screen. Then just hit <SPACE> and the Serpentine demo will run. "

Uncle Bernie comments:

Oh, thanks for this hint. It won't save me time (I read the book anyways) but it will speed up my testing process.

In post #18, 'gew' wrote:

" NTSC Apple //e with 128k and joystick with a Liron Reborn and a Smartdisk II from Vibr77 V0.80.10 shows random freezes. "

Uncle Bernie comments:

Thanks for sharing this insight ! It only is another clue that the whole 'SmartPort' stuff is wonky and a hit-and-miss in some hardware / firmware / software combinations. If you find a combination that works satisfactory, fine, but if you get "random freezes" then good luck finding and removing/replacing/fixing the culprit.

It took me two months of systematic experiments to get rid of the "freezes" of TOTAL REPLAY running on my Apple IIc and residing on the BMOW Floppy Emu. I could not point to a culprit - it just so happened that one of my experiments with systematic changes to my RTL for the 'IWMless' made the "freezes" disappear. But this does not mean it will work fine on any other hardware/firmware/software configuration.

What I found out when investigating the "Serpentine" freezes on the Euro-Apple IIe was that after the "freeze", the 'IWMless' (and same for the original IWM) had device select #2 activated, but there was no device #2, as the whole system in this particular experiment was configured to be device #1 of slot #5. In the next experiment I changed the device selects such that the BMOW Floppy Emu was device #2 in slot #6 (where normally the DISK II controller resides) and got the same "freeze" - this choice was made as it is the same slot / device configuration as in my Apple IIc experiments, where there was no "freeze".

How all this comes about is a mystery.

We may be trying to hunt down bugs which were planted 40 years ago by Apple, who knows. I found some of the code in the Apple IIc firmware ROMs appalling, such as the endless loop which happens before the sceen is cleared, if the firmware can't configure the IWM. This is unacceptable software design. There should have been a limited number of retries, and then a return with a diagnostics error code. They did not even fix that in later ROM versions.

They also use the ROL instruction to check the MSB of an IWM register by moving it into the CY, but, alas, the last CPU cycle of any ROL is a write, leading to a bus driver clash. This not sound programming either.

As for Vibr77's floppy emu, we have to cut him some slack, it's a quite new project that started just a year ago (first post in the thread: https://www.applefritter.com/content/apple-ii-disk-emulator-using-stm32 was on 2nd June 2024), and for the one year which transpired until today, he made some amazing progress. Sooner or later, at some point in the future, it may be be a great Floppy Emu. But at the moment, it isn't --- yet. Still, our little experiments here in this thread will sure help and inspire him to improve his code further.

UNCLE BERNIE'S GENERAL TAKE ON THESE EXPERIMENTS

What started as a humble request to get my 'IWMless' project out of the bog and up to some better speed, turned out into a worldwide hunt for 'SmartPort' bugs. Which is good ! All the results reported by various experimenters here on Applefritter will form a database of "go" and "nogo" system configurations which will be very helpful for those in the Apple II user community who want to acquire and / or experiment with various 'SmartPort' peripherals. When you know what to expect, then a lot of frustration and loss of time can be avoided.

Keep up the good work and continue the experiments !

- Uncle Bernie 

In post #22, 'gew' wrote:

" I am very impressed by the work of Vibr and I love the Smartdisk II. This was one reason why I did the test.My comment was just an information and I did not want to blame anybody."

Uncle Bernie comments:

Oh, I did not get the impression you were blaming anybody - we just need to honestly face the fact that 'Vibr77's Floppy Emu is not yet as perfected as, for example, the BMOW Floppy Emu, which has been around for ~13 years (maybe even more, no time to investigate any further) and which had numerous firmware upgrades, the last one was released just 3 months ago.

And Steve of BMOW is really eager to further perfect it, and fixing bugs that may pop up now and then.

I acknowledged in my post #21 that 'Vibr' has "made some amazing progress" in the one year since he started the project, but the undeniable fact is that he has to catch up quite a bit, as BMOW has a lead of more than a decade.

This is not meant in any ways to blame or discourage anyone. If you have a 'Vibr' Floppy Emu and want to beta test my 'IWMless' with it, fine, buy if it doesn't work in that environment, I won't "fix" any of my RTL to change the 'IWMless', but rather would suggest that 'Vibr' analyzes that problem himself and fixes his firmware instead. For me the BMOW Floppy Emu is the "gold standard" and if you followed my work, I've spent 2+ months to tweak my RTL until the random "freezes" running TOTAL REPLAY running on the Apple  IIc disappeared --- anything else would have been unacceptable, as the original IWM does not "freeze" when running TOTAL REPLAY from the BMOW Floppy Emu either. My 'IWMless' cannot be worse than the original IWM.

Here is my take on the "random freeze" topic:

We need to discern truly "random freezes" from "not-so-random freezes": the former strike in a random fashion, the same game demo of TOTAL REPLAY might load and run a few times, but then "freeze" some 10,20,30 hours later, when it comes up again. The latter is the case with "SERPENTINE", it "freezes" all the time shortly after it started its demo mode, at least on all the different hardware configurations I tried. But posts #8, #10, #14 report no such freezes seen.

What we have here is known in the industry as the "onion model": there is not just one bug or flaw in a system, but there are many, in layers, like the layers of an onion, but you can only see the outer layer and fix the bugs you can see and find in this outer layer. Once fixed, another, deeper bug manifests - now you have to "peel" away one layer of the "onion" to be able to "see" the deeper bugs. Rinse and repeat. And in the process, the thing being an "onion", you will "weep" a lot --- metaphorically speaking. Actually, what "weeps" is your wallet as an independent maker / producer, or, if it's done in a larger business, your project budget and the time-to-market plan will "weep".

So, we must ask the question in which layer of the "onion" the culprit hides. For the truly "random freezes" involving SmartPort operation, my money is on the 'SmartPort' functions themselves, and this again is an "onion" all by itself: from bottom to top, the Floppy Emu, then the 'IWM' or 'IWMless', then the firmware in the Liron card (or Liron clone), then the caller of these functions (TOTAL REPLAY). The bug(s) can lurk anywhere in this stack.

For the "SERPENTINE" freezes, after all the different results from all the contributors in this thread, I am now inclined to suspect a problem within "SERPENTINE" itself, and I don't suspect any of the 'SmartPort' components to be the culprit, in this specific case with "SERPENTINE".

The other reports of "random freezes", such as in post #18 by 'gew', to cite:

" NTSC Apple //e with 128k and joystick with a Liron Reborn and a Smartdisk II from Vibr77 V0.80.10 shows random freezes. "

... indicate that there is an issue either with the "Liron Reborn", or Vibr's "Smartdisk II" implementation, or both.

The whole 40+ year old 'SmartPort' design and implementation looks dubious / bug ridden to me:

Again, let me emphasize that I don't blame anyone who made any of the various software, firmware and hardware components involved in this investigative experiments. I think the whole "SmartPort" system crawls with bugs both in the hardware and the firmware. The documentation available on the web is extremely poor, not to say "pathetic" - although there could have been some more professional  'SmartPort' specification within Apple that never got 'leaked' - but if so, how come they (Apple) were obviously unable to weed out the bugs and fix the issues with 'SmartPort' ? IMHO, it's a mess !

So anyone who endavors to make "products" using 'SmartPort' is venturing into dangerous and unpredictable terrain.

As far as I was told by several Applefritter members commenting my work (and my questions to the Apple II user community), the 'SmartPort' was never considered to be a great feature back in the day (40+ years ago) and Apple soon abandoned it, at least this is what I was told. My conjecture is that maybe Apple got so many "phone calls" from frustrated 'SmartPort' device users about functional issues that they (Apple) came to the conclusion that 'SmartPort' is botched and beyond repair / redemption / fixing, and decided to quietly let it die off, and to replace it with other schemes to attach mass storage peripherals to the Apple computer product lines. This would be a typical and sound management decision when facing such a mess.

Why 'SmartPort', despite all of its flaws, is needed nowadays, 40+ years later:

In the past 40 years things have changed quite a bit, and from this thread:

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

... I have learned that 'SmartPort' functionality is really a must-have nowadays, to cite from 'CVT's post #2:

" Maybe it was not that important back in the day, but it has become very important in the last 5 years with all the new devices like wDrive, FujiNet, etc. "

... so I decided to put 'SmartPort' functionality into my 'IWMless', which initially was planned to be just a DISK II substitute (no 'SmartPort') to drop into the 28 pin footprint of the original IWM.

This decision cost me more than three months of frustration trying to weed out the "random freezes".

And I found lots and lots of bugs and flaws in the whole system, beginning with the Apple II slot bus timing, the problem with the Q3/M7 clock critical race (which Apple lamely 'dodged' by adding the suspicious 390 Ohm resistor on the Liron card, quite a band-aid / kludge), the problem with inadvertent IWM configuration changes, the IWM incompatibility with legacy copy protections, the rotten firmware using ROL making bus driver clashes, the infinite loops waiting for somthing that won't happen, and so on and so on, I have a whole pile of paper documenting all these grievances.

Hope it was worth the effort to have 'SmartPort' in the 'IWMless'.

Time will tell !

Comments invited !

(Oh, and keep these experiments running - I also will go on investigating "SERPENTINE")

- Uncle Bernie  

In post #27, 'Wayne' wrote:

" I ran Serpentine for 7 hours with no problems. "

Uncle Bernie comments:

I tried the same hardware platform you described, except for a Liron clone with a real IWM in it, and it still froze. Then I moved the Liron clone to a NTSC Apple IIe and it also froze. I also did try  the "serpentine.woz" file from the Woz-A-Day collection on the internet with a DISK II card and it also froze (but not at the same state of the game compared to the TOTAL REPLAY automatic demo "frozen" state).

As I mentioned in post #26 above, the culprit may be anywhere but based on all evidence collected by the contributors to this thread, I now think that something with "Serpentine" itself causes the issues, and that the 'SmartPort' stack may not be the culprit. So I decided to continue testing the 'IWMless' equipped Liron clone on 'softwarejanitor's NTSC Apple IIe running TOTAL REPLAY II (which has a smaller number of games in it) and so far no freezes:

IWMlessLironTest.JPG

On the lower right side is the new BMOW Floppy Emu which - luckily ! - arrived in my mailbox earlier than expected, so I was able to win 3 days for continued testing of the 'IWMless'/Liron combination.

Wayne - can you please tell me the Apple part# on your Euro-AppleIIe firmware ROMs (CD and EF) I could try what happens if I put those into my Euro-AppleIIe.

- Uncle Bernie

P.S.: Just as a footnote, the wonky nature of 'Serpentine' on certain machines producing "freezes" while it runs on others would be worth an investigation. Maybe somebody with a more recent Apple II emulator can look into it. If it also freezes there, it should be possible to go into the debug console of the emulator (if it has that) to find out where and when this "freeze" happens.

But keep in mind that emulators also have their own issues: when I investigated the "DROL" game  - one of my favorites - on Linapple (running on Linux) and had found an immortality hack, I finally was able to solve all three levels for the first time in decades and got to the intermission scene where the "mom" is reunited with her kids in front of the island surface background, but once the "kids" appeared and should start to move, the game froze ! I traced that "freeze" to an issue with the "vaporlock" programming technique which is used throughout the game, but for some reason did not work in that intermission scene. I had to manipulate the code both in DROL and in Linapple to make it work, and got the "kids" moving towards their "mom", but this hack is DROL specific, so it can't be put into Linapple for general release, sorry. --- This only shows us that when playing with these old machines we are not exactly standing on solid ground. Everything is wonky and treacherous.   -U.B.

In post #29, 'Wayne' wrote:

" I’m using the EF 342-0303-A and CD 342-0304-A ROMs "

Uncle Bernie comments:

I think this is the same version I did try in one of my experiments where I still got a "freeze" of  "Serpentine" (and a real IWM in the Liron card clone !).

The video ROM can't be the culprit anyways.

Now I wonder which slot cards do you have in your Euro-AppleIIe ? --- it is known that the success of the "vaporlock" programming technique also depends on the number and kind of the slot cards plugged in. It depends where the "bit vapors" are lingering and AFAIK this is not the same place (in the circuit) for every generation of Apple II.

At least the smarter kind of Apple II game programmers put some CPU cycle limit on their "vaporlock" routines, and if it failed, fell back to the old way just ignoring the screen scan. You can see this with some games which "flicker" on one Apple II, but don't "flicker" on another Apple II variant. With "flicker" I mean that moving objects seem to "break up" briefly, it's a really weird effect because the human eye is not supposed to be able to "see" that, but it does. This depends on the individual observer - seems to be genetic. When we developed an "intelligent" TV frame rate upscaler which would detect moving objects in a video and put them at the right spot of its "move vector" for the synthetic picture in between two of the original frames sent by the TV station, the ability of certain test persons to "see" a problem with that was uncanny. It seems that the human visual perception system does it own "moving object" detection and "move vector" prediction based on the neural net in your brain, and if there is anything  "unnatural" in the movements caused by our digital trickery then the test person perceives that as "disturbing" or "something wrong" or "jerky movement", but they can't really tell what exactly is wrong.

- Uncle Bernie

In post #31, 'Wayne' wrote:

" ... and the Liron or Yellowstone card I was testing. "

Uncle Bernie asks (just to be sure):

So both the Liron (original or clone ?) and the Yellowstone card worked with TOTAL REPLAY never "freezing" in its automatic demo mode, even with "Serpentine" ?

I'm just asking to make absolutely sure I'm not on a "Wild Goose Chase". Because in the same configuration you describe, with the 80 char / 128k RAM card, and my Liron clone with either the original IWM, and the 'IWMless', I did get those "freezes" on both the PAL Euro-AppleIIe and the NTSC Apple IIe, with the same version of the firmware ROMs as you have.

This is really weird.

I don't think it's a faulty Apple II because the "freeze" state of "Serpentine" shows exactly the same screen picture with both Apple IIe.

What's weirder is that said "freeze" state is different depending on whether it happens in the TOTAL REPLAY automatic demo mode or after the game has been manually selected by typing "SER" and then a RETURN.

Although I'm quite convinced that these particular "freezes" have nothing to do with 'SmartPort', I really would like to get to the bottom of it, find the root cause for the "freezes", because if I can prove it's the game itself, and not 'SmartPort', then the last doubts about my 'IWMless' are gone. Which you can guess is very, very important for me.

- Uncle Bernie

In post #34, 'Wayne' wrote:

" Maybe there's something different with the copy of Total Replay we're  using. "

Uncle Bernie tested your link !

Oh, and 'diff' told me that the two files (the one I used before vs. the one in your link) were indeed different !

They have exactly the same size, however, and AFAIK had no different splash screen.

Hmmm. How can it be that different versions of  Total Replay v5.2.hdv are around ?????

But Wayne's version did not help ... "Serpentine" froze again, at the same screen image as before. I tried it twice, with a NMOS 6502 and a CMOS 6502. Same frozen picture.

So what could the difference be ?

I do have some clues that whoever made this version of Total Replay may have difficulties with "Serpentine" in earlier versions, because in a 5.0 "beta" version of TOTAL REPLAY, it does not even run and shows a blank screen.

Anyways, TOTAL REPLAY II ran fine 24/7 (a week) and I'm satisfied with that. I will stop testing with HDD emulation and do another round of the "real floppy disk" tests and some 80 WOZ files which I have selected as test specimen.

-  Uncle Bernie

P.S. : I still wonder what the difference might be, why Wayne had success with running "Serpentine", but there may be numerous other sources of differences, i.e. a different firmware in the Liron card. I'm just running out of time and I'm too fed up with all these experiments that don't want to investigate this any further, it will just delay the beta test launch of 'IWMless' further. But it may be that others find the root cause later.

I'm now back with testing the 'IWMless' on the Apple IIc and - of course - "Serpentine" runs just fine there, as evidenced by these photos:

Serpentine_1.JPG

And here is another one:

Serpentine_2.JPG

It is still a mystery why "Serpentine" did "freeze" on both of my Apple IIe (an Euro-Apple IIe / PAL, and a NTSC Apple IIe borrowed from 'softwarejanitor') but this freeze has occured in the exacty same way on all these machines, with all four possible CPU choices I have available (NMOS 6502, CMOS 6502: GTEu G65SC02PI-1 DC 8442, Rockwell R65C02P2 DC 9441, WDC W65C02S8P-14), and all three IWM choices in the Liron clone: original IWM Rev. A, original IWM Rev. B, and the 'IWMless' in its most recent version V0.99 (the one destined for the beta test phase). Two choices of Apple II system firmware were tried on both machines: the CD/EF pair 342-0135-B/341-0134B (c) Apple 1982 and 342-304-A/342-0303-A (c) Apple 1984. This was a text matrix of 2 x 4 x 3 x 2 = 48 cases, and since it took on average 6 hours of runtime of TOTAL REPLAY in its automatic demo mode, and only 3 such tests were possible per 24h (I also have to sleep now and then), it took 384 hours of testing, or, 16 days of testing, in which I found no case that did not "freeze". 'Wayne' was more lucky and on his Apple IIe there was no freeze.

(As a side note, when you launch "Serpentine" directly by typing "S" "E" "R" and then RETURN, the "freeze" scenario may not be exactly the same as with the "freeze" in the undisturbed automatic demo mode).

So what could be the cuplrit for the freezes ? Well, until the root cause has been found and corrected (and a successful code mod to fix the "freezes" would be the only acceptable proof it's really the root cause) all we can say is that the 'IWMless' most likely is not the culprit, but root cause may be somewhere in the game itself, or in the Liron firmware ROM, or in TOTAL REPLAY's automatic demo mode routines. My money is on the game itself, as I have a hunch that a botched 'vaporlock' programming technique may be responsible for the "freezes", but this is just a conjecture, and not based on hard evidence - it is just known that "vaporlock" is a very temperamental method to synchronize the screen updates with the vertical frame rate, and it does not always work for every possible Apple II configuration.

But these 16 days of testing did not delay the beta test phase of 'IWMless' - the delay was caused because I first had ordered the wrong SMD resistors to finish the beta test specimen. This story is told in this thread:

https://www.applefritter.com/content/announcing-iwmless-iwm-substitution-call-beta-testers

In the next days I am still busy with testing the final 'product' and if no major disappointments are found, the beta test phase will be launched.

Thanks to every contributor of this thread ! Your experiments and the results you reported were of great help to make a decision on what to do with the "Serpentine" freezes. I decided to ignore them as far as the 'IWMless' is concerned - the fix, if ever found, must be applied elsewhere. But I will put a warning about these "freezes" in the 'IWMless' manual.

- Uncle Bernie

P.S.: if you find out how to fix 'Serpentine' or how to remove it from TOTAL REPLAY, please comment here.