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

[Zane Kaminski]

@techknight Can you flash the attached firmware and let me know if the sound crash still happens? Just run the program in the zip file and follow the directions. Be forewarned though, it takes about 6-7 minutes to flash the firmware and you will have to snake a microUSB cable out of your Mac SE and connect it to your PC.

 

[techknight]

It must need a driver... I need to figure out what driver.

 

[techknight]

Damn, the USB device isnt being seen by the system at all to even install a driver. Somethings up with that. I only have one micro USB cable, it may be a charge-only cable.

MicroUSB isnt something i keep around, i have a ton of miniUSB cables, and a few USB-C cables but coming up short on Micro.

 

[techknight]

I think its a bad connection on the USB port of the accelerator, I have to bend the cable up quite a bit and itll detect.

Edit: I got it flashed, but the connector is broken loose on the WarpSE, I can wiggle it and see the pins moving up and down. I need to figure that out, and that was the problem with MicroUSB...

Time to move to through-hole hybrid USB-C

 

[techknight]

Yeah i just knocked myself out of the running on ever updating this card again. the USB jack just broke off. Gonna have to look at the schematic and rig up some other jack on here, epoxy or whatnot.

 

[techknight]

@techknight Can you flash the attached firmware and let me know if the sound crash still happens? Just run the program in the zip file and follow the directions. Be forewarned though, it takes about 6-7 minutes to flash the firmware and you will have to snake a microUSB cable out of your Mac SE and connect it to your PC.

Crashes with Address Error. This time around the sound was garbly instead of clean just before the address error

(The Radius card does the same garbly sound but no errors).

I wont be able to do any more firmware updates/testing until I can figure out this USB situation.

Edit: After a crash reboot, I ran the sound control panel again and it had the same crash as before on the first time around. garbled screen and reboot.

 

[techknight]

Time to make a rig from hell, its the only thing I have handy:

 

[Zane Kaminski]

No big deal! We can just make another run of prototypes and send you one. Don’t waste your time with a jank solution unless it’s really easy for you to do.

And thanks for your help so far! I’m thinking that the crash in the sound control panel may be related to SCSI or something, not sound per se. Like, it has to read the samples from disk, right? Removing sound slowdown made the sound garbled (as expected) but how could writing sound samples in a buffer make the machine crash? So it must be that we are running too fast for SCSI. I will try reapplying slowdown to sound and also SCSI (which it wasn’t applied to before) and let’s see if that solves anything.

 

[techknight]

No big deal! We can just make another run of prototypes and send you one. Don’t waste your time with a jank solution unless it’s really easy for you to do.

And thanks for your help so far! I’m thinking that the crash in the sound control panel may be related to SCSI or something, not sound per se. Like, it has to read the samples from disk, right? Removing sound slowdown made the sound garbled (as expected) but how could writing sound samples in a buffer make the machine crash? So it must be that we are running too fast for SCSI. I will try reapplying slowdown to sound and also SCSI (which it wasn’t applied to before) and let’s see if that solves anything.

Yeah let me know if you have newer firmware to try, once I get the USB hacked into place, i will have the machine sitting right here for testing stuff.

The problem with the USB that I can see, its in a bad spot on the card. there is a hole punched into the chassis right where the USB connector is, and the parameter of the chassis is beveled downward from the punch. it puts downward pressure on the USB cable plugged into it which is why it popped off the board I think.

 

[techknight]

Problem solved. I can detect the card again!

 

[Zane Kaminski]

@techknight Ahh great work! A new prototype should be on its way to you early next week anyway. And maybe I should try to recess the USB port before we release the WarpSE. I'd like to use a through-hole part but the one problem through-hole microUSB connectors have is a tendency to wick up solder via the through-hole pins as they're being soldered. For example, we bought a batch of little JTAG-to-USB adapter boards for our GR8RAM and TimeDisk cards from JLCPCB. Unfortunately they were ruined when solder wicked up the through-hole legs of the microUSB and into the connector shell. The solder sort of spread out on the shell and made it impossible to plug the cable in unless you manually picked it out with tweezers. So if we switch, we will have to find a connector that doesn't tend to wick up solder along the through-hole pins

 

[Zane Kaminski]

Okay @techknight can you try this firmware? I think the issue with the sound control panel is with reading the sounds from disk. Unfortunately I can't duplicate it. You were using BlueSCSI, right? What version of the hardware and firmware?

Anyway, since I suspect it's a SCSI issue, I've slowed SCSI way down using the same hamfisted technique as I previously used for sound slowdown. Now after any access to the 53C80 SCSI chip, 16 wait states are inserted into each subsequent access for the next 100 microseconds or so. This was fine for sound since the CPU only spends a maximum of 50% CPU time working on the sound buffer. So 50% of the time the machine would be a bit slower than unaccelerated but then the rest of the time it'd be 4x faster. However with SCSI, speed matters, so unfortunately the disk speed has been reduced significantly by this change:

Notice the disk score of 0.376, although this SCSI2SD 4.2 I'm using only gets 0.48ish normally on the Mac SE. I should upgrade this test rig to a BlueSCSIv2 for more impressive (and CPU-bound) results. Anyway if the SCSI problem is speed-related, this oughta solve it. I also restored sound slowdown so the sampled audio glitches should be fixed too. Nothing done to address the floppy issues yet though. I'm trying to take things one at a time. Once we confirm this solves the issues Petar was having with old SCSI disks and Techknight was having with the sound control panel, I will start developing a more accurate slowdown technique and also apply it to floppies.

 

[lilliputian]

This all reminds of SCSI Accelerator for the Plus which comes with multiple versions of the extension, which adds different numbers of pause commands and such, based on the capabilities of the hard drive that was being used:

https://macintoshgarden.org/apps/scsi-accelerator

 

[techknight]

Okay @techknight can you try this firmware? I think the issue with the sound control panel is with reading the sounds from disk. Unfortunately I can't duplicate it. You were using BlueSCSI, right? What version of the hardware and firmware?

Anyway, since I suspect it's a SCSI issue, I've slowed SCSI way down using the same hamfisted technique as I previously used for sound slowdown. Now after any access to the 53C80 SCSI chip, 16 wait states are inserted into each subsequent access for the next 100 microseconds or so. This was fine for sound since the CPU only spends a maximum of 50% CPU time working on the sound buffer. So 50% of the time the machine would be a bit slower than unaccelerated but then the rest of the time it'd be 4x faster. However with SCSI, speed matters, so unfortunately the disk speed has been reduced significantly by this change:
View attachment 17850
Notice the disk score of 0.376, although this SCSI2SD 4.2 I'm using only gets 0.48ish normally on the Mac SE. I should upgrade this test rig to a BlueSCSIv2 for more impressive (and CPU-bound) results. Anyway if the SCSI problem is speed-related, this oughta solve it. I also restored sound slowdown so the sampled audio glitches should be fixed too. Nothing done to address the floppy issues yet though. I'm trying to take things one at a time. Once we confirm this solves the issues Petar was having with old SCSI disks and Techknight was having with the sound control panel, I will start developing a more accurate slowdown technique and also apply it to floppies.

This time, windows defender is balking at me

 

[techknight]

Okay @techknight can you try this firmware? I think the issue with the sound control panel is with reading the sounds from disk. Unfortunately I can't duplicate it. You were using BlueSCSI, right? What version of the hardware and firmware?

Anyway, since I suspect it's a SCSI issue, I've slowed SCSI way down using the same hamfisted technique as I previously used for sound slowdown. Now after any access to the 53C80 SCSI chip, 16 wait states are inserted into each subsequent access for the next 100 microseconds or so. This was fine for sound since the CPU only spends a maximum of 50% CPU time working on the sound buffer. So 50% of the time the machine would be a bit slower than unaccelerated but then the rest of the time it'd be 4x faster. However with SCSI, speed matters, so unfortunately the disk speed has been reduced significantly by this change:
View attachment 17850
Notice the disk score of 0.376, although this SCSI2SD 4.2 I'm using only gets 0.48ish normally on the Mac SE. I should upgrade this test rig to a BlueSCSIv2 for more impressive (and CPU-bound) results. Anyway if the SCSI problem is speed-related, this oughta solve it. I also restored sound slowdown so the sampled audio glitches should be fixed too. Nothing done to address the floppy issues yet though. I'm trying to take things one at a time. Once we confirm this solves the issues Petar was having with old SCSI disks and Techknight was having with the sound control panel, I will start developing a more accurate slowdown technique and also apply it to floppies.

I am using both BlueSCSI and an HDD. BlueSCSI has the bootstrap image and the Wifi Dayna setup.

But, the system is still running on the internal Conner HDD.

The BlueSCSI itself is the latest V2 WiFi setup, it just does not contain the boot image.

 

[techknight]

Ok, just tried it.

Mixed results. On one hand, it lasted longer! I could click the sound more times but it still locked up/crashed.

I could jump between sounds or play the sounds at least 10 times before it crashes, whereas before i could only do it 2 or 3 times.

 

[Zane Kaminski]

Hmm well I was finally able to duplicate @techknight 's sound control panel crash (not sure what changed) but yeah, unfortunately it still happens even with the SCSI slowed way down. Maybe we're accessing the VIA or something too fast? I'm shotgunning at this point.

Sorry about the virus warning. It's just a false positive probably on account of the fact that the updater exe is like the base exe concatenated with the driver and the update SVF file "script." Maybe I should look into getting these update files signed. That would fix any false positives.

Anyway, I got a new idea. Let's look at another accelerator and see how it addresses these issues. The famous @Bolle has reverse-engineered the MicroMac Performer which supports the Mac SE although it has a 68030 CPU. Source is here: https://github.com/TheRealBolle/Performer-SE-PL-CL

So here's the GALs in the MicroMac Performer:

Now I've got the .jed files from the git repos and run them through JED2EQN to get the logic equations. I added in some of the pin annotations but then I got a bit lazy:

Spoiler: MicroMac Performer GAL Equations

U3:

; JED2EQN -- JEDEC file to Boolean Equations disassembler (Version V063)
; Copyright (c) National Semiconductor Corporation 1990-1993
; Disassembled from C:\MMPGAL\U3.jed. Date: 9-21-124
;$GALMODE MEDIUM

chip U3 GAL16V8

A23=1 A22=2 A21=3 A20=4 A19=5 FC0=6 FC1=7 FC2=8 /DTACK=9 GND=10 /PU=11 /SCC_RW_DEC=12
/EXT_DTK=13 f14=14 /DTACK_SYS_EX=15 /CIIN=16 AVEC=17 /FPUCS=18 NOFC=19 VCC=20

@ues 0000000000000000
@ptd unused

equations

/NOFC = /FC0 * /f14
    + /FC1 * /f14
    + /f14 * /FC2
NOFC.oe = vcc
//FPUCS = /A22 * /A23 * /A21 * /A20 * /A19 * FC0 * FC1 * FC2
/FPUCS.oe = vcc
/AVEC = A22 * A23 * A21 * A20 * A19 * FC0 * FC1 * FC2
AVEC.oe = vcc
//CIIN = A22 * A20
    + A22 * A21
    + A23
/CIIN.oe = vcc
//DTACK_SYS_EX = //DTACK * PU
    + /EXT_DTK * //DTACK
/DTACK_SYS_EX.oe = vcc
/f14 = PU
    + /DTACK
    + /EXT_DTK
f14.oe = vcc
//EXT_DTK = gnd
/EXT_DTK.oe = gnd
//SCC_RW_DEC = /A22 * A23 * A20
/SCC_RW_DEC.oe = vcc

U4:

; JED2EQN -- JEDEC file to Boolean Equations disassembler (Version V063)
; Copyright (c) National Semiconductor Corporation 1990-1993
; Disassembled from C:\MMPGAL\U4.jed. Date: 9-21-124
;$GALMODE REGISTERED

chip U4 GAL16V8

CLK=1 NOFC=2 C8M_PDS=3 /AS_30=4 /DTACK_SYS_EX=5 /VPA=6 E=7 R/W=8 /RESET_30=9 GND=10 /OE=11 o12=12
f13=13 rf14=14 rf15=15 /VMA=16 rf17=17 /AS_00=18 f19=19 VCC=20

@ues 0000000000000000
@ptd unused

equations

/f19 = gnd
f19.oe = gnd
//AS_00 := /C8M_PDS * //AS_00 * //VMA * rf14 * /RESET_30
    + //AS_00 * //VMA * rf15 * E * rf14 * /RESET_30
    + C8M_PDS * //AS_00 * /VMA * rf15 * rf14 * /RESET_30
    + //AS_00 * rf17 * /RESET_30
    + /NOFC * /f19 * C8M_PDS * //AS_30 * rf17 * /DTACK_SYS_EX * /VMA * rf15 * rf14 * f13 * /RESET_30
/AS_00.oe = OE
/rf17 := /C8M_PDS * //AS_00 * /rf17 * rf15 * rf14 * /RESET_30
    + //AS_00 * /rf17 * rf15 * E * rf14 * /RESET_30
    + //AS_00 * //VMA * /rf15 * rf14 * /RESET_30
    + C8M_PDS * //AS_00 * rf17 * //VMA * /rf15 * R/W * /RESET_30
    + //AS_00 * rf17 * //DTACK_SYS_EX * //VMA * rf15 * /rf14 * /RESET_30
    + //AS_00 * /rf17 * /VMA * rf15 * rf14 * /RESET_30
rf17.oe = OE
//VMA := /C8M_PDS * //AS_00 * //VMA * rf14 * /RESET_30
    + //AS_00 * //VMA * rf15 * E * rf14 * /RESET_30
    + //AS_00 * rf17 * //VMA * /rf15 * /RESET_30
    + //AS_00 * rf17 * /DTACK_SYS_EX * //VMA * /RESET_30
    + /NOFC * C8M_PDS * //AS_00 * rf17 * //VPA * rf15 * /E * rf14 * /RESET_30
    + C8M_PDS * //AS_00 * rf17 * //DTACK_SYS_EX * rf15 * rf14 * /RESET_30
/VMA.oe = OE
/rf15 := //AS_00 * /rf17 * //VMA * /rf15 * rf14 * /RESET_30
    + C8M_PDS * //AS_00 * rf17 * /DTACK_SYS_EX * /rf14 * /RESET_30
    + /C8M_PDS * //AS_00 * rf17 * /VMA * /rf15 * /RESET_30
    + //AS_00 * rf17 * /rf15 * /rf14 * /RESET_30
    + C8M_PDS * //AS_00 * rf17 * /VMA * /rf14 * /RESET_30
    + /AS_00 * rf17 * /VMA * /rf15 * E * rf14 * /RESET_30
    + /f19 * /AS_00 * rf17 * /VMA * rf15 * /rf14 * /RESET_30
rf15.oe = OE
/rf14 := /C8M_PDS * //AS_00 * rf17 * /rf15 * /rf14 * /RESET_30
    + //AS_00 * rf17 * /DTACK_SYS_EX * rf15 * /rf14 * /RESET_30
    + C8M_PDS * //AS_00 * rf17 * //VMA * rf15 * E * rf14 * /RESET_30
    + //AS_00 * rf17 * /VMA * rf15 * /rf14 * /RESET_30
    + NOFC * C8M_PDS * //AS_00 * rf17 * /VMA * rf15 * /RESET_30
    + C8M_PDS * //AS_00 * rf17 * //DTACK_SYS_EX * /VMA * rf15 * /RESET_30
    + f19 * /AS_00 * rf17 * /VMA * rf15 * /RESET_30
rf14.oe = OE
/f13 = gnd
f13.oe = gnd
/o12 = //AS_30 * /rf17
o12.oe = /NOFC * f13 * /RESET_30

U6:

; JED2EQN -- JEDEC file to Boolean Equations disassembler (Version V063)
; Copyright (c) National Semiconductor Corporation 1990-1993
; Disassembled from C:\MMPGAL\U6.jed. Date: 9-21-124
;$GALMODE REGISTERED

chip U6 GAL16V8

CLK=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /OE=11 rf12=12
o13=13 rf14=14 rf15=15 rf16=16 o17=17 o18=18 o19=19 VCC=20

@ues 0000000000000000
@ptd unused

equations

o19 = i2
o19.oe = vcc
/o18 = i2
o18.oe = vcc
o17 = i2
o17.oe = vcc
/rf16 := i3 * /rf16
    + /i3 * /rf15
    + /i8
    + /rf12
rf16.oe = OE
/rf15 := rf16 * /rf12
    + /rf15 * rf12
    + i3 * rf16
    + i4 * /rf15
    + /rf15 * i9
    + /i8
rf15.oe = OE
/rf14 := i6 * /rf14
    + i5 * /rf14
    + /i8
rf14.oe = OE
/o13 = vcc
o13.oe = /i5 * /i6 * i7 * rf14
/rf12 := rf16 * /rf12
    + i3 * /rf16 * /rf15
    + /i4 * /rf12
    + /i8
    + /rf15 * /rf12
rf12.oe = OE

U5 just acquires the bus and does the LDS/UDS strobes so I didn't bother posting it.

Okay well the only bit of I/O dependent slowdown I can find in here is that the CDIS (cache disable) pin on the '030 gets disabled when the SCC is accessed. Hmm... Maybe the issue is not speed related but instead there's a bug in the logic somewhere? Tbh the WarpSE accelerator logic has become a mess so maybe it's time for a rewrite/refactor. I can add pieces back in slowly to find out where the problem lies. I will get to work on that soon.

 

[Zane Kaminski]

Two more thoughts about this issue...

First of all @techknight if you're flashing a bunch of times in a row, you can basically just pull the plug once the update is something like 55% done. Once you see it slow way down from 1000-2000 bits/sec to under 500, you know it's verifying what was written and you can just pull the plug since errors should be very rare.

Second, maybe I'm approaching slowdown all wrong. Maybe instead of inserting a bunch of wait states to accomplish slowdown, the accelerator controller should sort of emulate the timing of PDS bus transactions. Like, once the fast CPU access SCSI, IWM/SWIM, SCC, VIA, or writes to the sound buffer, instead of inserting a bunch of wait states, the controller should put the subsequent transactions out on the Mac's bus and wait for them to complete there, even if the data is actually just coming from onboard RAM/ROM. This is basically what the MicroMac Performer and all the other '030 accelerators do, right? They don't insert 16 wait states or whatever, they disable the '030's cache. So the equivalent for the WarpSE is to put transactions out on the PDS bus during slowdown and wait for 'em to complete. I will try this and it doesn't require a big refactor like adding cycle-accurate slowdown.

 

[techknight]

Two more thoughts about this issue...

First of all @techknight if you're flashing a bunch of times in a row, you can basically just pull the plug the update is something like 55% done. Once you see it slow way down from 1000-2000 bits/sec to 500ish, you know it's verifying what was written and you can just pull the plug since errors should be very rare.

Second, maybe I'm approaching slowdown all wrong. Maybe instead of inserting a bunch of wait states to accomplish slowdown, the accelerator controller should sort of emulate the timing of PDS bus transactions. Like, once the fast CPU access SCSI, IWM/SWIM, SCC, VIA, or writes to the sound buffer, instead of inserting a bunch of wait states, the controller should put the subsequent transactions out on the Mac's bus and wait for them to complete there, even if the data is actually just coming from onboard RAM/ROM. This is basically what the MicroMac Performer and all the other '030 accelerators do, right? They don't insert 16 wait states or whatever, they disable the '030's cache. So the equivalent for the WarpSE is to put transactions out on the PDS bus during slowdown and wait for 'em to complete. I will try this and it doesn't require a big refactor like adding cycle-accurate slowdown.

So in other words, youre just waiting for /DTACK at that point?

 

[Zane Kaminski]

So in other words, youre just waiting for /DTACK at that point.

Basically yeah although it’s slightly more complicated because of the tuning of the bus bridge. If we just sent DTACK from the PDS to the accelerated CPU, it would not necessarily work. First of all, since DTACK is synchronized through multiple flip-flops in the 68000, but the data input is unsynchronized, DTACK can be asserted one clock cycle in advance of valid data on the data bus. At the accelerated speed one clock period is 3x shorter, so there may be insufficient data-in setup time if we just gated the PDS DTACK onto the fast CPU's DTACK line during PDS bus transactions.

So in the CPLD, we have to retime the DTACK signal. Turns out this is a little difficult. Too early and the CPU latches data before it’s ready. Too late and back-to-back accelerated CPU cycles end up having a gap on the PDS bus, which is undesirable. But more or less yeah, during slowdown we're using the PDS DTACK signal for all bus operations.