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

[JDW]

James - would you like me to send you a Windows 10 capable laptop for this sort of thing? We have plenty of basic 6/7/8/9/10th gen Intel stuff that gets chucked out for 'being old' at work.

Kai, you are an incredibly kind and generous person. If you were my next door neighbor, I'd give you a call saying, "I'll be right over!" But I suspect there would be some post office gripes about the battery.

The upside is that, despite the lack of Boot Camp Drivers, I was able to flash WarpSE this evening at home using my 2015 15" MacBook Pro, booted into Windows 10. It's not a true PC and the trackpad isn't as usable as it would be with Boot Camp Drivers, but I think it will suffice for now. Thanks again for your kindness though. And by the way, where do all those throw-away PCs end up going? Recycle centers?

---

@Zane Kaminski
With firmware 0.7b, Audio sounds really good to me.
Here's my D100's 48kHz 24-bit recording via the headphone jack ( made with caution by cranking down the Control Panel volume to level 2), while booted into System 6.0.8:

WarpSE_0.7b_HeadphoneJack.WAV.zip

drive.google.com

SCSI Performance is noticeably faster and it's very nice indeed!

0.7b compared to 0.6h:

My paintbrush drawing test in MacPaint went without issue. My rapid left-right movement of the mouse didn't show any problems either. Honestly, @iPhil64 gave me the magic cure — just put the SE Reloaded motherboard inside the chassis. That's all I did, and the double bong problem and the mouse freezing and jumping problem are now a thing of the past. (As I said before though, they never impacted my stock SE motherboard, even when used outside the chassis, so I guess SE Reloaded just doesn't like to be "away from home." )

While I've not done the Snooper serial port tests yet, I suspect those will go fine and my MacTest SE will freeze again. So tomorrow, I think I'll wire up my TechStep and see what that tells me about the serial ports. That issue only affected my SE Reloaded board. Serial Ports pass MacTest SE just fine when using my stock SE motherboard.

---

...page 429 from Apple's "Guide to Macintosh Family Hardware, 2nd Edition".

Please accept my humble apologies for having forgotten you posted that several thread pages ago. (I went through each thread page one by one until I tracked down your earlier post!) Because you said that back on 9/26, it really did slip my mind. On top of that, I had Boot Camp on the brain all day today, and I must say my brain is nearly fried as a result.

It is interesting that Apple never did put such a Warning in the Owner's Guides for the 128K through SE (which every Mac owner would have likely read, as opposed to Guide to Macintosh Family Hardware), but I guess not enough people complained about fried stereos for Apple to have improved Mac documentation with the additional of that warning.

Even so, you provided all the evidence needed to show what you are supposed to do. And I wish to thank you for that.

I consider this matter not too dissimilar from discharging the CRT. Most people don't seem to be aware of it, but Apple recommends only discharging at the Ground Lug, in the upper left corner of the CRT when viewing it from behind. Apple goes on to say that while you can attach your CRT discharge tool's ground clip to the metal chassis, it strongly recommends you disconnect the motherboard before doing so. If the ground lug is used, the motherboard can be left connected. This is why I always tell people to use the Ground Lug when discharging, because you don't need to worry about zapping your motherboard by accident that way. In other words, it's similar to what you just showed me. It's official and from Apple, but a lot of folks just don't know about it.

So thank you for being persistent and repetitive.

Sometimes we think people are idiots when we need to tell them the same thing multiple times. And I suppose that idiots do exist. But in my case, it's usually a matter of my mind being on something else, combined with my own "dumb luck?" of never have fried anything connected to a Mac headphone jack since 1984. And yes, I actually did connect my Dad's old Sanyo stereo amp (which he picked up on his return from Vietnam) to my 128K Mac in the 80's, as I recall. And it handled those high voltage levels just fine.

Anyway, I wish to repeat my appreciation your having emphasized this important info for all of us, @phipli . I probably stressed you out a bit, and for that, I am sorry. Please don't let me make you hesitate about speaking out. When you feel the need to say something, please do!

 

[JTRetro]

@JDW -I had a similar problem trying to run Visual Basic on my machine with Windows 10 Professional. Of course, in my case I also installed a program called "Stop Windows 10 Updates" because I got sick and tired of having everything set up the way I want, and then they through and update at you and everything breaks.

AS for security, I simply keep all of my peripheral programs up to date, such as my browser (FireFox) and anti-virus/malware programs such as Spybot and Malwarebytes.

I am actually switching off more of the things I do onto my Linux machines, specifically machines running Linux Mint. The laptop I am using now has been running it for years- I love it!

I will download Spectrum Holobyte Tetris and run some test with it later today.

@phipli -I have a Bose Revolve speaker that I use with my SE, although I was mostly just connecting it directly to the CD-ROM to play back music. I just connected it to the SE itself- So far, so good.....although I had the volume turned up a bit too much initially!

 

[Kai Robinson]

@JDW Mostly they just end up in e-waste, crushed. I try and re-home them when i can but honestly people are getting so careless with their stuff now they resemble skateboards mostly by the time i get them.

 

[ppuskari]

Okay, I have version 0.7b ready now which does not have any variants. I am trying to "solve the puzzle" now on 0.7b. Hope it works!

The slowdown policy in 0.7b is as follows:

• Slowdown is triggered for 196-210 microseconds after an interrupt occurs or when the sound buffer is written to.
• When the VIA, IWM, or SCC are accessed and slowdown is not already occurring, slowdown is triggered for the next 14-28 microseconds.
• When the VIA, IWM, or SCC are accessed and slowdown is already occurring, slowdown is prolonged by up to 28 microseconds. The exact amount of additional slowdown is idiosyncratic and depends on the current value of the slowdown timer but the total slowdown time after a VIA, IWM, or SCC access will be at least 14 microseconds.
• Clock gating to 7.8336 MHz is enabled when a sound buffer write triggers slowdown but is disabled immediately after an access to the VIA, IWM, SCSI, SCC, or when an interrupt occurs.
• SCSI accesses never trigger slowdown but do disable clock gating. SCSI accesses are like RAM/ROM accesses in that they do not end slowdown either. After a SCSI access, the slowdown timer continues to count down, and slowdown ends at the same time as it would if there were no SCSI access.

Also the slowdown register is disabled in this version since its semantics need redone slightly to reflect the behavior that clock gating is enabled during slowdown and after a RAM access but is immediately disabled after and I/O chip access or interrupt.

Is this gonna work? Admittedly I don't understand the problems Petar was having with LocalTalk, so I'm just kinda guessing here at the combination of slowdown rules that will fix everything. Unfortunately my little Mac network setup is stalled since my personal lab bench has been reoccupied by some RAM2GS II cards of ours that need tested and added into inventory. So it will be a bit before I can get my three other SEs set up and verify LocalTalk functionality myself. Fingers crossed!

ACK!

0.7b Works, but it takes a LONG time for the shares to populate and it times out on any login attempt. Getting closer but still no cigar. yet.

Sound works great though!

800k format and copy of 700k file works properly!

Petar Puskarich

 

[JDW]

ACK!

0.7b Works, but it takes a LONG time for the shares to populate and it times out on any login attempt. Getting closer but still no cigar. yet.

Sound works great though!

800k format and copy of 700k file works properly!

Petar Puskarich

So when you power off, press Interrupt, power on, then release Interrupt, it boots using the stock 8MHz processor and all is well with LocalTalk networking, including login?

 

[JTRetro]

James - would you like me to send you a Windows 10 capable laptop for this sort of thing? We have plenty of basic 6/7/8/9/10th gen Intel stuff that gets chucked out for 'being old' at work.

Sounds like my old job at a local college here in Northampton. They would throw out so much perfectly good equipment; the desktop machine that I use for work that runs Windows 10 Professional came from this place. And despite the fact that it is from 2011, it works just fine, albeit with an SSD drive upgrade.

@JDW @Zane Kaminski : here is a quick test I just did running Tetris. The video quality is poor, but the sound is good:

 

[ppuskari]

So when you power off, press Interrupt, power on, then release Interrupt, it boots using the stock 8MHz processor and all is well with LocalTalk networking, including login?

That is correct. When back in no acceleration mode everything works just fine again.

I don’t know why the gating is kicking in during LocalTalk access though. Maybe it is because the SCC IS NOT in standard serial port mode but they are put into the special LocalTalk mode and speed setup. Timing apparently is critical at the top end of the chips access speed?

 

[iPhil64]

@JDW Coming back to the improvement seen with the board inside. Would you mind testing voltages with the Mach-o-meter when inside or outside ? I'm still pretty convinced that the quality of the supply at the board plays a role, as you had yourself pointed out in one of your videos. It is certain that adding an accelerator board changes the draw on the PSU.

And of course it could be a lot of other factors (EMI).

 

[Zane Kaminski]

We have been investigating various possible issues impacting LocalTalk. We thought we had the cause figured out but maybe not... Basically, when the 68k CPU receives an interrupt, it executes an "interrupt acknowledge cycle" on the bus. Long story short, due to the interrupt acknowledge cycle using the /VPA cycle termination method, a long and variable amount of time is required to execute the interrupt acknowledge cycle. What was happening on the WarpSE was that the controller logic in the CPLD was waiting for the interrupt acknowledge cycle to finish on the PDS before then repeating the same interrupt acknowledge cycle on the fast bus. This was increasing the interrupt latency over the stock setup. Now in the latest version, 0.7c, interrupt acknowledge cycles are posted to the PDS bus and execute on both buses concurrently, so the interrupt latency on WarpSE should be the same or better.

However... it would be nice if this solved the LocalTalk problem but I am afraid that it won't. I read the serial port section in Guide to the Macintosh Family Hardware and it says that AppleTalk is actually not interrupt-driven and instead uses polling. Hmm. On the other hand, I guess an AppleTalk operation has to start by being triggered by an interrupt, right? Otherwise how would the Mac know it's happening? Checking once during vblank sounds too infrequent. So maybe the interrupt latency thing was part of the problem? But maybe not.

Anyway, now I have version 0.7c, which fixes the interrupt latency issue and also has a slightly revised slowdown policy. Now slowdown is not triggered by an SCC write or SCC interrupt, although either of those conditions occurring doesn't cancel slowdown. It just doesn't prolong it. Clock gating is only enabled after a sound buffer write or VIA interrupt, but is disabled right when an SCC interrupt or any other I/O access occurs. 0.7c comes in three variants, default, fast, and slow. Default has slowdown triggered as I described, fast never slows down (so it will crash in the sound control panel, for example), and slow is always in slowdown (with clock gating to 7.8336 MHz).

@ppuskari Can you try 0.7c and see if this fixes LocalTalk? If not, does 0.7c-fast work? What about 0.7c-slow? Also if you've had no errors while flashing in the past, it's probably safe to power-cycle the Mac after the firmware update gets to 55% to speed things up. After 53.something percent it's just verifying what was written, which takes like 4x longer than the first part where data is being written. Oh, one more thing, what Mac OS version are you using for your testing? If 0.7c still doesn't fix it, can you try the Network Software Installer to update your AppleTalk version to 58.1.4? There are some notes about the Brainstorm accelerator suggesting that version 56+ is required or something to that effect. I think 56 is included with System 7 though so I dunno if this will help if you're not using System 6.

We're super close but this issue is very hard to pin down! If 0.7c doesn't work then I have one more change in mind after studying the old "fastscsi." But if that doesn't work and if there are no obvious next steps then we will have to pause work on the WarpSE for a bit while I do some other GW-related tasks and free up space on my workbench for a little network of accelerated Mac SEs.

0.7c is attached! @JDW @JTRetro you guys can try it if you want (version 0.7c is recommended, not the fast/slow variants) but I say don't bother since it's really just aimed at fixing the LocalTalk issues.

 

[JDW]

@JDW Would you mind testing voltages with the Mach-o-meter when inside or outside ?

Certainly. Here's the Mac-O-Meter voltage test while booted from my internal BlueSCSI v1 and with a Mouse and Keyboard attached.



And you can see it draws 33.7W of power (with WarpSE installed):

Note that my SE Reloaded Motherboard is still installed, and so is WarpSE running firmware 0.7b.

In the past, just after I completed the SE Reloaded build, I did a complete set of TechStep tests on the motherboard and it showed no problems.

I did those same full batch of TechStep tests again this evening, but this time with WarpSE installed. All tests passed.



The only odd result was that the TechStep thinks I have a SWIM chip installed. But in fact it is an IWM 344-0043-A:

Anyway, if either of the serial ports had issues, TechStep either would not have been able to do the tests at all (because that's how the TechStep communicates with the Mac SE), or some of the tests would have resulted in errors. So the fact that every test passed shows no issues with the serial ports. And of course, as I've said, Snooper 2.0 also gives them a clean bill of health. Only MacTest SE dislikes this SE Reloaded motherboard for reasons unknown.

With that said, I've not attached PhoneNET adapters between this SE and another Mac to see if LocalTalk network functions. @ppuskari has been struggling with that.

0.7c is attached! @JDW @JTRetro you guys can try it if you want (version 0.7c is recommended, not the fast/slow variants) but I say don't bother since it's really just aimed at fixing the LocalTalk issues.

I'll wait and see what Petar says before proceeding. So far, I've not done LocalTalk testing, but as I wrote above, everything else with 0.7b is working great!

 

[Kai Robinson]

@Zane Kaminski just an FYI the SCC requires a 4.25x divider from the master 15.6672MHz clock in order to run the serial ports properly. Although this quote references the TSG or Timing State Generator from the original Macintosh & Plus, the SE is just integrating all this identical logic into an ASIC:

The master oscillator frequency in the Macintosh is 15.667 MHz. This is divided by 2 in the TSG to get the 7.834 MHz processor clock. In order for the SCC to be able to operate at a baud rate of 230.4 KBaud, which is what AppleTalk requires, it needs an input clock frequency of 3.686 MHz.

If you pull down your calculator desk accessory, you'll find that 15.667 / 3.686 = 4.25. This means that the TSG needs to divide the 15.667 MHz master oscillator by 4.25 in order to get a 3.686 MHz clock. How is this done, since 4.25 is not even an integer, let alone a binary number?

Let's call the 15.667 MHz clock the MO_clk and the 3.686 MHz clock the SCC_clk. For every 17 MO_clk periods there are 4 SCC_clk periods (17 / 4 = 4.25). The way the TSG generates the SCC_clk is count to 4 three times and then count to 5 once (4 + 4 + 4 + 5 = 17).

Could this have some bearing on the timing being generated? Ie, it's fine for margin of error in terms of serial comms, but localtalk requires something a bit more strict?

 

[JDW]

I decided to try a Farallon PhoneNET networking test with my WarpSE Mac SE and my SE/30.
Names show up in the Chooser, but I can only connect only when WarpSE is disabled, as shown in the video below.
NOTE: I only tested 0.7b because I didn't have time to flash 0.7c yet.

(At 5:21 I said say "It's 8MHz..." but actually WarpSE was active at that point, so just ignore that one incorrect remark.)

So this test seems to be showing what @ppuskari is seeing.

 

[Zane Kaminski]

@Kai Robinson As long as Petar's 15.6672 MHz clock is accurate, it should work. The 4-4-4-5 thing to get the 4.25x average divide rate does reduce the baud rate tolerance a bit, but it should be fine. Baud rates can be slightly off because the serial chip does 16x oversampling and can still count the pulses even if there's a small speed mismatch between the machines. The 4-4-4-5 thing basically just eats away a bit of that margin by sampling a bit later every once in a while. No big deal though and it shouldn't have anything to do with the WarpSE's clock or anything. The LocalTalk issue is probably just that something is happening too fast or too slow for some assumptions made when writing the software. Hopefully we can just analyze the situation more and refine the slowdown rules to fix the issue.


@JDW thanks for trying the TechStep! I think the reason it says you have a SWIM is because the WarpSE uses the SWIM (edit: FDHD) ROM. No big deal, I have been the WarpSE exclusively in a machine with an IWM and the IWM/ROM mismatch is no big deal.

The TechStep is mostly to check for board-level connectivity issues. So it does a lot of tests on the hardware but the goal is just to exercise every board-level circuit path. Its purpose is not really design validation. For example, it wouldn't necessarily find a subtle bug in the CPU or one of the I/O chips. So software which expects certain timing to hold is not necessarily gonna be compatible with an accelerator, but it's not like the TechStep is gonna check for every specific timing-dependent circumstance. If it did then it would fail on any accelerator. So the TechStep is good to check basic functions but it's not a great design validation tool and it's more for board-level diagnostic testing.

And thanks for trying AppleTalk! Too bad it didn't work lol though I guess then that means we would have to track down some obscure issue with Petar's machine hahah. In the future once it's working better you can try some simple file transfers (and maybe take the checksum using md5fl).


@JDW @ppuskari If AppleTalk works better in 0.7c, then either it's because of the VMA/VPA-related interrupt latency fix, because slowdown is no longer triggered on SCC accesses, or because slowdown is no longer triggered on /IPL1 interrupts (which are from the SCC). So if it's better in 0.7c and the reason is not related to the interrupt latency fix, then we still need more changes to robustly solve the problem. Serial communications on an AppleTalk network can happen at any time, so a packet could come in right as a previously triggered slowdown is still pending. In that case the remaining slowdown time could screw things up.

I have been studying the differences between "fastscsi" where AppleTalk worked and subsequent versions. What stands out the most is that the slowdown time interval is really brief on fastscsi. It's not enough to fix sound all the way. That in combination with the fact that there's one less thing (SCSI) triggering slowdown again makes me think that slowdown and AppleTalk don't like each other. So if LocalTalk works on 0.7c-fast, then we know that we need to apply slowdown more cautiously. I wonder what happens on 0.7c-slow? It's supposed to be very close to the original speed. Maybe some serial-related routine measures the machine speed and compiles itself at boot?

Anyway, my current understanding is, we need a bit of slowdown after accessing the VIA, otherwise there's the crash in the sound control panel. We also need a little bit of slowdown after accessing the IWM, otherwise 800k floppies don't work. But we need a lot of slowdown after accessing the sound buffer and after receiving a VIA interrupt (because that ultimately triggers sound generation), otherwise sound is corrupted. But slowdown must be disabled once any SCC-related stuff happens.

So my new idea which will be implemented in 0.7d is... When the CPU gets get an SCC interrupt on the /IPL1 line or accesses the SCC chip, slowdown will be disabled for a little bit. But if this amounted to forcing the slowdown counter to 0, then if the Mac received a byte on the serial port right after the VIA's vertical blanking interrupt, the slowdown counter would be cleared and sound generation for that frame would proceed at full speed. That would corrupt the sound buffer. So instead, an SCC interrupt should set a separate "speedup" timer to inhibit slowdown for a little while. So for the next ~21 microseconds after an SCC interrupt is received or the SCC is accessed, the CPU should speed up to ensure the processing occurs in time, but then slowdown should resume if it was already ongoing. And then of course because we need slowdown for the VIA and IWM, accessing those should clear the speedup timer. If the VIA/IWM and SCC are accessed alternatingly, then slowdown will alternate from on after a VIA/IWM access to off after an SCC access. Should be fine though.

 

[ppuskari]

flashing 0.7c now... will see shortly what is what. Here's hoping.

Initial boot after flash with 0.7c - Appletalk WORKS!
The sound seems good in the control panel too!
800k floppy format and file copy of 700+ k works fine.

will update this as I do other tests.

----------------------------------------------------

0.7c-fastscsi - The sound control panel crashes after a couple sounds with an address error. First time I have seen that. BUT expected I think.
Localtalk works fine as before.

-------------------------------------------------------------

Tried 0.7c-slow

Sound is fine
Localtalk is still working!
BUT overall responsiveness is indeed noticeably slower too! yuck.

----------------------------------------------------------------

Went back and tested with stock SE no acceleration enabled for Scsi Director 4.1 - 4.1 crashes on shutdown and restart still. So it's an issue with SD 4.1 in general.... No need to troubleshoot unless you really want to.

 

[Zane Kaminski]

Thanks!!

 

[Zane Kaminski]

@ppuskari Great news!! I think the WarpSE is almost ready for release. Soon I am gonna prepare version 0.7d which will come in two variants. I want to see, what in 0.7c fixed LocalTalk? Was it the interrupt latency or was it that we don't trigger slowdown on SCC accesses? So I will have 0.7d, which will be as I described in my post above, and then 0.7d-slowscc, where slowdown will be imposed on SCC accesses as was the case in previous versions. Then if 0.7d continues to work but 0.7d-slowscc doesn't, that means LocalTalk doesn't like slowdown. Otherwise if both 0.7d variants work then we know it was the interrupt latency.

Once we get this information, I think I can make the final slowdown policy! Then I will order the final board revision and we will go for version 1.0. Current testers are also gonna get at least one more WarpSE prototype too since the final board will be at 25.946 MHz, I think, and we will need to test that a bit. Maybe a few new testers will be needed to complete the testing too.