WarpSE: 25 MHz 68HC000-based accelerator for Mac SE

[JDW]

Lunch break testing now...

My first attempt at flashing "WarpSE.GW4410A.0.6d.exe" was a failure. Flashing worked fine as usual, but after that was done, I switched off power, removed the USB cable, then powered-on (what I always do), and I got the thick bar code bars. I switched off power and waited more than 10 seconds, then powered on again, but still get bars. Switched off power for 30 seconds and then powered ON, but still get bars.

I then reflashed "WarpSE.GW4410A.0.6d.exe" to make absolutely sure it's not a flashing issue. At power-on, I got a normal flashing disk icon screen. I'm pleased to see that, but that still doesn't explain why my first SUCCESSFUL flashing of "d" firmware resulted in bars every time I switched on Power. Strange.

UPDATE: after posting the above, I went back to my powered-OFF SE and switched ON power. I got the bars. So it's 100% clear that the "d" firmware not only doesn't solve the bars problem, but the bars appear to be worse than 0.5robust firmware.

I flashed "a" firmware to see what would happen. At first power-on, I got the normal gray screen and then flashing ? disk icon, which is good. I then powered off and waited 60 seconds, then powered ON again. That too gave me the gray screen and flashing " disk icon, showing all is well. So I have now disconnected everything and will do the multi-hour-disconnect test this evening after work.

Despite my having re-confirmed the problem with "d" firmware, I nevertheless wish to implore my fellow WarpSE beta testers to PLEASE test "d". The reason why is that the only person to date who has described the vertical bar problem is me. That doesn't mean the problem doesn't exist, but it does still mean that other people should see if they get the same thing. I think there's lot of meaning in doing that.

Lunch break over.

---

QUICK QUESTION:
I put all the firmware files on a USB flash drive (8GB) and launch them from there, but today, I put the "d" firmware into the root of that drive, and put the "a,b,c" firmware files into a folder named "WarpSE-0.6" (only to keep them separated from past firmware files). But when I double-click a, b & c firmware, the following error resulted:



I then put the "d" firmware inside that folder and double-clicked it, only to find that it too yielded the same error. I then moved all 4 firmware files to the root, and then they launched without the error. Is this normal?

 

[Zane Kaminski]

Damn, I was hoping for a more positive result. One thing I was thinking about is that I have the update program using the ASCII versions of all the Win32 APIs whereas you're on a Japanese-language machine. The error relating to the directory (and certainly the messed up text) may have to do with that. The "failed to open GWUpdate executable as data file" message is printed when the program can't open itself, so it's likely that the Japanese path separator characters have something to do with it.

Have you been running the update program all the way through? I've said it can be stopped after around 55% since it's just verifying after that point, but maybe there are some errors that are occurring. I will look into this further. Maybe I can also make a Mac version of the program. I will look into this soon.

As for waiting multiple hours, that's probably not necessary. 15 minutes oughta be plenty for any stored charge to bleed off. Hmmm..... The strange/difficult thing is that I can't replicate this behavior at all. Maybe I will have to do a Mac version of the program. Tomorrow I'll get started on a port to x64 macOS but unfortunately at the moment I have only my Apple Silicon MacBook Pro so I have to figure out how to cross-compile a macOS x64 console app.

 

[JDW]

... it's likely that the Japanese path separator characters have something to do with it.

Yes. Another reason I'm not a Windoze fan. Japanese Windows "/" chars (in a path) appear as "¥" characters in many cases. It's not a glitch. It's the way it's always been.

Have you been running the update program all the way through?

Yes. I always wait for the full 6 minutes until it says 100%. It's really slow, but that's the only way I can be 100% sure it flashed correctly. Even so, as I said in my earlier post, I flashed "d" firmware twice, all the way to 100%. Still got the bars.

As for waiting multiple hours, that's probably not necessary. 15 minutes oughta be plenty for any stored charge to bleed off.

Good to know, but since my lunch break is over, the next opportunity I will have to do my next power-on test will be 4.5 hours from now.

The strange/difficult thing is that I can't replicate this behavior at all.

Another reason I'm on my hands and knees begging my fellow WarpSE beta testers to please test 0.5robust and the new "d" firmware to see what they get. And they need to do multiple power-on tests to be sure of what they get. Because if I alone am getting this, we need to find out why. But if everyone else (except you, I guess, Zane) is getting it too, then such gives more evidence that the bars are indeed a real problem.

 

[Zane Kaminski]

@JDW now just to confirm, 0.6d never worked, but 0.6a does? Can you try 0.5b? That has the changes to the startup sequence, where the problem is likely occurring. If I can pinpoint the issue to be between 0.6a and 0.6b then I can look more carefully at what was changed and try to isolate the problem further.

 

[JDW]

@JDW now just to confirm, 0.6d never worked, but 0.6a does?

In my limited testing on my lunch break moments ago, I got the thick vertical bars at every single power-on with the 0.6d firmware flashed to WarpSE, which is bad. I then flashed 0.6a firmware, and at every power on I got a normal screen, which is good! But to make 100% sure "a" is really OK, I need to wait and do further testing. You said wait 15 minutes, but I can't test for another 4+ hours because I'm back to work now at my day job. But I will do that "a" test tonight after work and report back with the result at that point in time.

Now if @JTRetro , @techknight and the rest of our WarpSE beta team could also test 0.6d to see if they too see the vertical bars at cold boot (after multiple power-on tests), that would be EXTREMELY HELPFUL to confirm my findings. I think it's best we have some testing overlap here, and not merely avoid testing particular firmware only because one (and one alone) among us reported a problem. I may sound excessively pushy on this point, but I feel very strongly that would be important and helpful testing.

@JDW Can you try 0.5b? That has the changes to the startup sequence, where the problem is likely occurring. If I can pinpoint the issue to be between 0.6a and 0.6b...

I'm a bit confused. The only "0.5" firmware I've tested is the older 0.5robust (which has the vertical bar problem). I am guessing you made a typo there and were actually asking me this: "Can you try 0.6b?" And my answer to that corrected question is YES, but tonight after work, after I've finished doing my 0.6a power-on testing.

 

[Zane Kaminski]

@JDW Yeah, that's what I meant. Let me know if 0.6b has the issue and then I can start investigating each of the 0.6b changes in turn

 

[JDW]

Only have a short amount of time to test right now (after work).

"WarpSE.GW4410A.0.6a.exe" FIRMWARE:

1. No problem with the power-on test after leaving it disconnected for more than 4 hours. I've never had the bars appear once with this firmware!

2. I see 25MHz in Norton System Info, which is nice. A good number of the earlier firmware versions showed 22MHz.



3. Speedometer 3.23 shows these scores:



4. Tetris music recorded in the same was as before (48KHz, 24-bit), but I can tell you right now the sound isn't great:

WarpSE_0.6a_Tetris.zip

drive.google.com

---

"WarpSE.GW4410A.0.6b.exe" FIRMWARE:

1. No problem with the power-on testing. No vertical bars. No time to do even the 15-minute disconnect test, however.

2. CPU clock speed is back down to 22MHz in Norton System Info:



3. Speedometer 3.23 shows these scores:



4. Tetris music recorded in the same was as before (48KHz, 24-bit), and it sounds great:

WarpSE_0.6b_Tetris.zip

drive.google.com

 

[phipli]

Don't forget to test serial.

Voltage shouldn't matter too much. If the Mac works at 4.75 volts, the card probably will too. It's basically all CMOS.

Your card likely doesn't use anything near as much power, but my old cards drag the 5v rail down, so if you have a PSU outputting 4.75v stock, you add the card and it drops lower and the computer crashes. But JDW has fully confirmed that he already has everything set up perfectly. He's got his PSU set like I have mine. All the rambling in my post was just me being cautious because I didn't want someone to set the voltage to the top end of the safe range with a larger load on the PSU, then remove that load and be putting too higher voltage through their stock machine.

But anyway - not applicable, JDW's got the volts

 

[phipli]

. I see 25MHz in Norton System Info, which is nice. A good number of the earlier firmware versions showed 22MHz.

Norton's estimate of Processor speed is wrong as often as it is right. It is even sometimes wrong on stock, unmodified macs. Some of the 2.5x bus multiplier PPC Performas used to just say the wrong speed.

Long and short - don't pay any attention to that, it is out of anybody's control.

 

[JDW]

"WarpSE.GW4410A.0.6c.exe" FIRMWARE:

1. No problem with the power-on testing on the first try, but when I moved my SE setup to my workbench, on the second power-on I got the bars. I heard a strange sound from the speaker twice, and was hoping to capture that audio, but then it stopped. Because of this, I will do no further testing on "c" firmware.

---

I re-flashed "WarpSE.GW4410A.0.6b.exe" FIRMWARE. Again, no bars at power-on so far. I will take the SE home and test "b" more over the weekend. No Windoze Pee See at home, so I can't refresh until Monday (It's Friday night here in Japan.)

Goodnight!

 

[JTRetro]

So I just got up.....and after making my morning coffee, I powered up me SE with the CD-ROM and Iomega drive attached.....and this time it fired right up! Only thing I noticed odd is that this time when the AfterDark screen saver kicked in it was running slow. Of course not a big deal, but weird. However at this point, I don't think that has anything to do with the accelerator:

 

[JTRetro]

Next test, I grabbed my external SCSI2SD drive and plugged it in with a copy of O.S. 6.0.8 installed. And again, it fired right up from the external drive, no problems:

 

[JTRetro]

I also was finally able to get the Iomega drive up and running, running it in conjunction with the CD-ROM. No problems accessing the Iomega drive either:

 

[phipli]

For the moment, my CD-ROM is working well. I forgot to install the drivers for the Iomega, so I will do that in a bit. They are around here somewhere in this mess!

<off topic>
If you don't know - cool trick :

If you put a removable SCSI disk like a CD or a Zip disk in the drive before powering on, and it has a compatible driver on the disk for the host computer, the computer loads the driver from the disk right at the start of boot. This is a great way to use drives on a computer without the drivers installed. It works with CDs and Zip disks, although with older macs it can be tricky with Zip disks because the later drivers that the formatting tools install (and automatically update if you don't turn it off - stupid software) don't work with old Macs.

I often install CD drivers like this - put a CD with a driver partition on it in the drive, and also the CD driver installer, boot (from it or the hard disk, doesn't matter), install the CD software and you're away, without having to mess with floppy disks or networking.

</off topic>

 

[techknight]

Sorry this thread has gotten way to large to understand what happened since ive last been here. Not sure what i need to test, not test, with what software, or otherwise. TLDR.

Also, I was affected by the hurricane pretty badly and im just now starting to get back into operational status over here.

 

[JDW]

Not sure what i need to test

Zane’s newest firmware consists of 4 files inside this ZIP download:

https://tinkerdifferent.com/attachments/warpse-0-6-zip.18054/

Zane says to flash the “d” firmware file first.

After flashing and after disconnecting your USB cable from WarpSE, if you see vertical bars or artifacts, please report it.

If you see bars or artifacts and power on or otherwise experience is a major problem with “d”, proceed to flash firmware files “a, b and c.”

---

I’m terribly sorry To hear that you were hit by the hurricane, and I truly do hope that you did not sustain any major damage and that you and your loved ones are safe and in good health!

 

[Zane Kaminski]

@techknight Glad to hear from you that everything is fine after the hurricane. Please take your time and don't feel pressured to do anything until you're ready.

@JDW Hmm, too bad 0.6c/d didn't work for you. I'm wondering, is this a hardware issue? I will be getting new boards made soon with the changes I previously described. I will send you another WarpSE card once I have the new boards and assemble them. I have some more prototypes of the current board revision, but I think it'd just be better to move on to the next one. Let me know if 0.6b continues to work for you. My feeling is that you should stay on that revision as long as it's stable. Once we're sure 0.6b is working for you then I can start looking specifically at the changes between 0.6b and 0.6c to pinpoint the issue, assuming it's not some kind of idiosyncratic hardware problem.

 

[JDW]

I spent more than 6 hours testing Firmware 0.6b today. It's for the most part problem free, but I am seeing occasional arrow pointer MOVEMENT strangeness which I show very clearly in the video below. This video is not only for @Zane Kaminski but also for @JTRetro , @techknight and all my other fellow beta testers. Watching this video will help you to know what you should watch out for in your own testing, regardless of firmware version used.

---

BELOW are my benchmark and other test results.
My drive is a BlueSCSIv1 with 16GB Gigastone SD card (fast V30 speed).

==============================================
Test #1: Speedometer 3.23 booted into System 6.0.8:

==============================================
Test #2: Speedometer 3.23 booted into System 7.1:

"Mac SE WarpSE-Robust" shown at right below is the very first version of "Robust" labeled firmware. "This Machine" at left is the "0.6b" firmware.

I did Test #1 & #2 to show that performance numbers are lower when booted into System 7.1 versus System 6.0.8. But please note that all my previous benchmark testing shown in this thread was done while booted into System 7.1. So before anyone starts comparing their numbers to mine, be sure you are booted into System 7.1 to make the comparison fair.


==============================================
Test #3: Norton System Info

Note that "Mac SE WarpSE-Robust S7.1" below are the test results from the version fist "Robust" labeled firmware.
"Current System" below shows firmware 0.6b.

==============================================
Test #4: I launched the Daystar Power Demo and ran "DayStars" constantly for over 3 hours. No lockups or problems.


==============================================
Test #5: Word Processing test shows no problems. (Typing on old Macs is a wonderful, distraction-free experience too!)

==============================================
Test #6: Snooper 2.0 "LOGIC" tests PASSED without problem.

I also ran "Disk Tests" and only "Random Sector" FAILED. But it fails when WarpSE is disabled too, so that must be a BlueSCSIv1 thing. Basically, no problems here either:

=========================================
Lastly, @phipli said not to trust the clock speed shown in Norton due to it not being accurate. I can't speak for WarpSE but it normally nails the stock clock speeds and my overclocked Color Classic Mystic. Even so, I tend to rely more on the Clockometer app than anything else. Sadly, it won't work with WarpSE though:

===================================
That concludes my testing for today. I can continue tomorrow. But overall, except for the occasional arrow pointer movement glitch, the 0.6b firmware is excellent. Fixing the arrow pointer glitch problem would probably make it perfect, if everyone finds the SCSI performance to be acceptable.

 

[Zane Kaminski]

@JDW Thanks for all your hard work testing!!!!! Soon I will produce versions 0.7a,b,c..... where I incrementally apply more changes to further isolate the problem. The reason for the mouse pointer problem is not immediately obvious to me. I will think further about this. Regading the CPU speed, the reason it says 22 MHz in version 0.6b and 25 MHz in version 0.6a is because of the sound fix. In 0.6a, after an I/O chip access, the accelerator is only slowed down for something like 28-42 microseocnds. In 0.6b, the accelerator is slowed down for approximately 200 microseconds. This fixes the sound but because the I/O chips are accessed at least one per frame (during the vertical blanking interrupt), there is overhead of at least 200 microseconds per 16.6 milliseconds during which the WarpSE operates at the PDS bus speed. In reality the I/O chips are accessed more than just once per frame and the slowdown persists for more than 200 microseconds. Hence the lower clock speed reported.

 

[phipli]

Just to clarify, I don't believe that TattleTech or Norton calculate the MHz themselves, I think they use an OS function... which I think might be run during boot.

More guessing, but I think some accelerators modify the stored value to correct it so that things like Norton report correctly. I swear I read this all once... but have no clue where.

Edit - the correct value would also be shown if the accelerator was running from power on, and important settings were not changed during the boot process. I.e. The WarpSE should be accurate (as an average during the mini benchmark) as long as the clock speed doesn't change later.

If you see the following :

I just took this photo. What I did was I booted at 25MHz (at which point all three showed 25MHz), then I changed the clock speed to 33MHz, and re-launched the three programs. Clockometer, which estimates the processor speed based on doing a load of calcs and timing them, plus checking what CPU type is fitted (i.e. the calcs should take specific numbers of clock cycles based on which chip it is) is basically showing the correct speed. The reason it isn't 100% accurate is perhaps because of background processes and interrupts and things and whatnot, or just timings / hardware or calculations aren't perfect, or it can't account for cache / RAM performance.

I think the number System Info uses is rounded slightly (less so than the one in System Profiler on later macs which is heavily rounded), but ultimately based on the same number as TattleTech is using. I think these are little mini benchmarks performed by the ROM during boot, and scaled based on the processor type detected (similar to Clockometer, but run when there aren't other things running in the background?).

Really sorry, there is a lot of guessing here, I checked the OS Utils Inside Macintosh quickly but couldn't see any MHz reporting tool. But ultimately, Norton and TattleTech aren't calculating the speed when you launch them, and get it wrong if it changes after whatever calc is run.

Note the number in brackets in TattleTech? 6187 - I assume that is the raw "speed" value stored by the System.