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

[JDW]

Reflashing fixed it only while on the same table that is near the PC. But that's not my workbench, so I need to move everything to do real testing. And that means disconnect the motherboard from the chassis extension harness, disconnect the speaker's extension harness, disconnect power cord to the SE chassis, etc.

After reflashing 0.5robust to WarpSE using my Apple stock motherboard and then moving everything to my workbench, I reconnected everything (with ESD strap affixed to my wrist and properly earth grounded) and was pleased to hear the bong and see the flashing disk icon (no drive was attached). I powered off, installed my BlueSCSI v1, booted into System 6.0.8, launched Tetris, made the 48KHz 24-bit recording via headphone hack, then powered off.

I then carefully disconnected Warp SE (checking its pins to ensure none were bent), and then swapped in my SE Reloaded motherboard, then secured WarpSE. At power-on... Nope! Same bars! :-(

I then swapped my stock SE board back, installed WarpSE and powered on. I got the bong and everything was normal. I wasn't expecting that. But that was good. I then swapped motherboards again, using my SE Reloaded, and this time it bong'd and everything was normal. What?!!

My lunch break was over at that point and I could do no further testing.

All I can say is that it is really weird.

Would capacitors still having a stored charge (on SE motherboard and/or WarpSE) cause memory corruption that would explain the oddball garbage on screen at power on? Because like I said, the display on the CRT is 100% the same as when I have the USB cable attached to the PC and power ON. But of course, on my bench, I have no USB cable attached. And no, the USB connector is fine. (After reading the experience of @techknight I now take extreme care to ensure mine is as babied as can be!)

Anyway, here are the stock SE (recorded previously) and 0.5robust recordings (WAV files):

WarpSE_TetrisMusic_StockVs0.5Robust.zip

drive.google.com

 

[JDW]

Just changed Google Drive sharing so anyone clicking the link in my previous post can access. Sorry about that.

 

[Zane Kaminski]

Hmm, I think I am going to re-base all of my changes onto the "old robust" since that build was quite stable. I will do this in the next few days and I will hopefully produce a series of firmware updates that will incrementally add my changes so we can see where things are breaking.

In particular, I am going to apply these changes sequentially to the "old robust":

• New reset and disable behavior
• PDS bridge refactor
• Longer slowdown period
• Possible additional sound slowdown
• New RAM controller
• Possibly increase SCSI speed

We can try these in series and find the one where issues start to occur.

 

[JDW]

@Zane Kaminski

I did a lot of testing tonight after work. On first power-up, I got the bars on the CRT (same as when a USB cable is attached), but I spent almost two hours testing after that, and it never came back. Maybe it was my cable insertion? Because after that first power-up showed CRT bars, I took great care after that to insert the main wiring harness, making absolutely sure it was all the way down. Of course, during my testing tonight, I didn't leave it totally disconnected for several hours on end like I did after my lunch break, or all last night. So tomorrow will be the definitive test. I will leave everything disconnected and on my lunch break tomorrow I will connect everything carefully and do a power-on. If I don't get the bar code bars, I will consider that evidence the root cause was merely me being stupid with my earlier main harness connections. That very well could have been the reason because I've been connecting and disconnecting like mad lately, and that makes you get a little lax.

Of course, it would be nice if I weren't the only one testing WarpSE and the newest 0.5robust firmware. So I'd like to encourage my fellow WarpSE Beta testers to:
1. Download and flash the 0.5robust firmware, and then
2. Test (checking mouse movement and Tetris music, and doing a Speedometer 3.23 benchmark in System 6 or 7.1), and then
3. Report back in this thread to confirm what you tested.

---

Separately from that, I think the speaker inside my SE is on its last legs because it just doesn't sound right compared to the speakers inside my SE/30's. And from the looks of this SE (which @Kai Robinson kindly sent to me a couple years ago), the SE probably was stored outside and even slightly water damaged. That's why I moved components from the old damaged motherboard to an SE Reloaded board, in fact.

I know the MacEffects 8Ω speaker will work because I have one. It's just much lower volume than the stock speaker due to the MacEffects speaker being 8Ω vs. the stock 63Ω. Sure wish there were 63Ω replacements! But if I have time tomorrow, I think I'll remove it from my MacEffects clear case and install it in this SE, so I can get decent sound (albeit soft sound).

---

Lastly, I did more benchmarking tonight, as follows:

IBM DGHS spinning platter drive in HD20 enclosure (Disk: 1.568):


MacSD (Disk: 1.581):


BlueSCSIv2 (Disk: 1.655):


It should be noted that MacSD is normally the speed king on the stock 8MHz SE, so BlueSCSIv2 speed is clearly being influenced in a positive way by the WarpSE.

BSv1 score (Disk: 1.408):


But before we get too excited about the Disk numbers, I must say that when I flashed Zane's "Oops firmware" (which had showstopper problems), the Disk score with BSv1 was getting 2.091:

More testing tomorrow.

Goodnight!

 

[phipli]

I did a lot of testing tonight after work. On first power-up, I got the bars on the CRT (same as when a USB cable is attached), but I spent almost two hours testing after that, and it never came back. Maybe it was my cable insertion? Because after that first power-up showed CRT bars, I took great care after that to insert the main wiring harness, making absolutely sure it was all the way down.

Hey JDW, I'd suggest double checking the 5V rail while the accelerator is running. Perhaps it was lower end, and the extra load is making it marginal. 68000s are picky about the quality of the 5V.

Easiest way to measure it is from the external floppy port. The memory aid is that the fifth pin in from the top left is 5V. 5 for 5.

A quick search of datasheets, I weirdly can't find the recommended voltages, it states the absolute limits (i.e. the limits for damage), not the operational voltages. But 4.75v is probably a pretty poor PSU and I'd be aiming for perhaps 5 to 5.1v without the upgrade card installed? I wouldn't want to go higher than 5.2v as an absolute maximum. Then make sure it doesn't drop horrifically when you add the card.

I usually set mine a little high of 5v with no card fitted so that they're at the high end of safe without a card, and as high as possible after the voltage sag from a hefty upgrade. The WarpSE probably drinks less power than some of my cards TBH because mine are much older designs with a higher chip count, and four RAM SIMMs.

 

[JDW]

Bad news. I still get the bars even after carefully connecting everything, and the voltages are fine. Have a look at all of the details in my video below:

 

[Zane Kaminski]

Hmm, like I said I will be rebasing my changes incrementally onto the "old robust" that seemed to work for everyone and developing versions 0.6a, 0.6b, 0.6c, 0.6d... which will add back the features incrementally to find what's wrong. I suspect the issue here relates to the new reset code but I'm not sure.

 

[JDW]

I suspect the issue here relates to the new reset code but I'm not sure.

That's really why I tried to encourage my fellow WarpSE beta testers to test in the same way I did to confirm they too have the same problem when using 0.5robust firmware. I want to make sure it's not only me who has the same issue. Then we would have definitive proof.

Even so, I will wait your next firmware update to do further testing.

Thanks for your tireless efforts to perfect the product, Zane!

 

[phipli]

Bad news. I still get the bars even after carefully connecting everything, and the voltages are fine. Have a look at all of the details in my video below:

Yeah, not voltage then - was just a thought given you were seeing inconsistent behavior.

Nice meter for the floppy port. I was meaning to make something when I was recapping a load of PSUs, but I never got around to it. The great thing about making one of those PSU extension cabless is that they also work on the IIcx, IIci, IIsi, IIvi, IIvx, P600, Q650, Q700, Q800, and PM7100. Useful for bench testing without having to balance the PSU on top of the logic board. I think you do need to snip the latch off though, because some of the board connectors don't have a place for it.

 

[JDW]

Nice meter for the floppy port...
The great thing about making one of those PSU extension cables is...

I like the Mac-O-Meter because it's about as accurate as my EEVBlog 121GW. I show that in my video here. I recommend Mac-O-Meter a lot to people who either don't have a meter or don't want to accidental short their meter wires together at the external floppy drive connector.

And the Extension Cable I've been using to test WarpSE is the one I show how to make in this video.

If my fellow WarpSE beta testers lack either of those items, I can't speak highly enough about them. Being able to move the motherboard outside the chassis really does allow you to get some real testing work done.

 

[JTRetro]

I don't have a MAc-O-Meter, but I do have an excellent fluke meter that came out of use from a place called Practical engineering. It is my go-to piece of electrical testing equipment!

 

[JDW]

I don't have a MAc-O-Meter, but I do have an excellent fluke meter that came out of use from a place called Practical engineering. It is my go-to piece of electrical testing equipment!

Please be sure to test 0.5robust firmware to see if you find the same issue I did.

 

[JTRetro]

Please be sure to test 0.5robust firmware to see if you find the same issue I did.

I'll try to do that tonight. I applied the first upgrade patch that Zane sent me (I can't remember the revision off of the top of my head) and that patch works terrific.

 

[Zane Kaminski]

Yeah, not voltage then - was just a thought given you were seeing inconsistent behavior.

Nice meter for the floppy port. I was meaning to make something when I was recapping a load of PSUs, but I never got around to it. The great thing about making one of those PSU extension cabless is that they also work on the IIcx, IIci, IIsi, IIvi, IIvx, P600, Q650, Q700, Q800, and PM7100. Useful for bench testing without having to balance the PSU on top of the logic board. I think you do need to snip the latch off though, because some of the board connectors don't have a place for it.

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

Anyway I've got this new board revision just about done:

It has the ability to be powered from the USB port as I mentioned earlier. Also, I frequently worry about issues like @JDW mentioned where the system might be retaining some power and not fully turning off. So now there are some 680 ohm resistor that will discharge the +5V and +3.3V rails. I will evaluate whether these need to be placed on production boards but it's good to have the option.

I'm also now sourcing the PDS read/write signal from the CPLD. Previously the R/W signal went into the posted write buffers along with the address bus and out to the PDS. However, on the original 68000 (unlike the 68020+), the R/W signal timing does not exactly follow the address. So the R/W timing has been a bit off, although it should hardly matter.

Another thing-- now the hardware has the ability to remap the top four address bits as a transaction goes from the fast bus to the PDS bus, so we can rearrange the memory map in interesting ways. This won't be enabled for production units though.

I'll try to do that tonight. I applied the first upgrade patch that Zane sent me (I can't remember the revision off of the top of my head) and that patch works terrific.

I think this latest build is probably not working right, so you'll likely have to go back to the previous firmware. I'll have more firmwares out in the next 8-24 hours though. These should help isolate the cause of the instability @JDW was having

 

[JTRetro]

I think this latest build is probably not working right, so you'll likely have to go back to the previous firmware. I'll have more firmwares out in the next 8-24 hours though. These should help isolate the cause of the instability @JDW was having

Sounds good. I think that I will wait until you are finished working on the new firmware before installing another patch. Like I said earlier, the current one that you gave me seem to work well. Tonight, I want to test out some functionality via the external SCSI port, like a CD-Rom and an Imoega drive.

 

[JTRetro]

So I did some testing via the external SCI port....and had some interesting results. I attached one of my CD-300 drives, daisy chained with a SCSI Iomega 100Mb Zip Drive. And when I powered it up......I got a checkerboard.

So I disconnected the drives and powered up the machine again, and re-attached the drives after the O.S. had finished booting. Of course, the CD-Rom wouldn't work properly, so I did a soft restart of the machine......and it worked! Here's a quick video of my SE playing "Dreaming" by Blondie.....hope I don't get a copyright strike!

 

[Zane Kaminski]

Okay!! I’ve got some new firmwares ready. There are four versions, 0.6a through 0.6d.

I recommend trying 0.6d! If it works well then there’s no need to try any of the others. Here’s a description of the versions:

• 0.6a - basically the same as “old robust.” Sound isn’t great but everything else seems to work
• 0.6b - has new startup and sound slowdown code. Sound should work well but the system will be about 1% slower than 0.6a.
• 0.6c - has new RAM controller
• 0.6d - has refactored bus bridge

Like I said, only try 0.6d unless you have issues. Then flashing the others can pinpoint the problem.

I think the reason why @JDW was having issues had to do with the startup sequence. Previously, in the firmware shipped on the card and the “old robust” firmware, the function of the startup sequence was to wait a while with the Mac held in reset. During this time, the accelerator controller looks at the interrupt button and deasserts the bus request for the PDS card if it’s pressed. This amounts to disabling the accelerator. However, in the build where James started having issues, I changed the reset sequence so that any reset pulse would trigger a re-entrance into the startup sequence. Previously the startup sequence only occurred once after the power was turned on. This allowed you to enable the accelerator without cycling the power and also served the function of extending a reset pulse generated by the fast processor. (Which is important in some contexts but I don’t think it matters on the WarpSE.) Unfortunately, I think there was some metastability effect or something and the reset kept getting triggered, hence the inability to boot. That code has been removed in 0.6a (well, it was never in there in the first place) and the startup sequence has been rewritten in 0.6b to eliminate the reset pulse extension and the ability to change the WarpSE enablement after each reset. So you'll have to turn on the power with interrupt held down again in order to disable the card.

Also there's a new power-on-reset feature. Since the WarpSE can be powered via USB and the Mac simultaneously, we need to detect when the Mac's power is turning off and disable the outputs onto the PDS bus since it is not good to drive a system which is off. My solution for this is pretty simple. The startup sequence logic samples the Mac's 7.8336 MHz signal continuously at each 25 MHz clock. If the C8M clock is ever high or low for four consecutive 25 MHz clocks then this means the power has dropped low enough that the C8M clock is acting weird. In this case the WarpSE immediately returns to the startup sequence and doesn't leave it until the C8M clock is looking more correct.

Firmwares are attached! Remember to try 0.6d first!

So I did some testing via the external SCI port....and had some interesting results. I attached one of my CD-300 drives, daisy chained with a SCSI Iomega 100Mb Zip Drive. And when I powered it up......I got a checkerboard.

So I disconnected the drives and powered up the machine again, and re-attached the drives after the O.S. had finished booting. Of course, the CD-Rom wouldn't work properly, so I did a soft restart of the machine......and it worked! Here's a quick video of my SE playing "Dreaming" by Blondie.....hope I don't get a copyright strike!

Hmm that's odd. Kinda like the issue James was having. Can you ever get it to boot with the SCSI drive attached or is it consistent? Can you try the new firmware and see if that helps anything?

 

[JTRetro]

The weird thing is that I tried re-creating the conditions of my initial test-booting the machine from a completely powered down state, even going as far as making sure all of the power was disconnected from the machine and holding in the reset button to try to drain all of the capacitors.....and it kept working. I wonder if it will boot up O.K. tomorrow morning?

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!

 

[JTRetro]

@Zane Kaminski - I am curious to see what happens if I let the machine sit all night and then power it up tomorrow. I think I'll see what happens with that first, and then flash the new firmware in the morning!

 

[JTRetro]

@Zane Kaminski -Interesting side note: My Afterdark screen saver just turned on; It is very smooth now. I don't recall it being this smooth before. Maybe that last firmware upgrade had something to do with it? Or maybe something else: