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

ppuskari

Tinkerer
Dec 25, 2021
22
26
13
Was able to flash them all and see how things worked with System 7.1.1pro running on my Zip 100scsi carts like always...

SlowSCC - Doesn't work for me. It will time out the domain search and then display the control panel and no items in the appletalk list.

FastSCC - works well - and it may just be my viewing but it seems almost a skoche faster but maybe it's just me or some directory lists on my main drive got cached.

0.7d - works well - No noticeable issues now.

What I have NOT tested is hooking Macs back to back via a serial cable direct. I'm using regular LocalTalk serial to 3pin adaptors to my Cayman Gatorbox buss that it then exposes to the Ethernet side to my raspberry pi and virtual box instances on the PC.
 

ppuskari

Tinkerer
Dec 25, 2021
22
26
13
Because my internal 800K drive in this SE is all rusted up and impossible to use, I have no ribbon cable attached. But I connected an external 800K drive and tried to share, but only my hard disk volumes appear. So it would seem that early Mac System Software did not support the LocalTalk Sharing of floppies.

I tried to trick the Mac into doing it anyway by making an Alias of the floppy, then copying that to on my my drive volumes on the SE. But while I could then see the alias on the SE/30, double-clicking the alias resulted in the SE/30 asking me for the disk. I ejected and reinserted the disk into the external drive attached to the SE/30, but that didn't work. Seems as if the SE/30 wants the disk inserted into one of its floppy drives.

I then made an alias of a file on the floppy, and I copied that alias to my hard disk volume. That alias too is visible on my SE/30 via sharing. But trying to open it results in the SE/30 asking me to insert the floppy disk again. But I assure you, it is inserted into the drive attached to the SE.

This means Apple really doesn't want to support floppy driving sharing, and it's too bad too because I think that would be pretty neat.

I will return home from the office now. I can test your version "e" tomorrow, if available by then.
Correct sharing of floppy drives is NOT supported. Neither was floppy images mounted to the desktop via disk copy. Yeah it would have been a neat option!
 

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,655
1,416
113
53
Japan
youtube.com
@ppuskari
Can you run the SCSI Director Pro 4.0 disk test with firmware 0.7d-fastscc flashed to WarpSE?

The reason I ask is because I am getting the error shown below after all the Seek tests finish, just as the Graph tests are beginning. And boosting the Preferred size for the app in the Get Info box doesn't resolve it. This happens only in System 7.1, and it never happened for me in the past.

1729138163880.png


I had old firmware on my BlueSCSI v1. It was December 2022. Last night, I updated to the latest BSv1 firmware, and all seems well. But I didn't run the above test BEFORE I flashed firmware, so I don't know if it is resulting from the WarpSE firmware or new BSv1 firmware.

Even more interesting is the fact I don't get that error if I boot into System 6.0.8! I can run the test just fine, and for some reason, the scores are noticeably higher than my scores tested in the past...

1729138414867.png


For example, in the past, with older WarpSE firmware and my old BSv1 firmware, I was getting very low performance numbers as shown below:

1729138506419.png


I didn't have time on my lunch break to reflash WarpSE, so I am curious what numbers you get @ppuskari , and please test in System 7.1 and System 6. I'm curious if you get the out of memory error like I am seeing in System 7.1. Again, that error is new. I've never seen it before.
 

ppuskari

Tinkerer
Dec 25, 2021
22
26
13
I have fast-scc loaded and booting from a Scsi Director 3.1 driver on the Zip 100 cartridge running 7.1.1 Pro pretty much base install.

Using Scsi Director Pro 4.0 application for tests it passed.

The Epson Iomega zip 100 Scsi with Fuji Zip 100meg cart gave the following:

Sequential 6.27
Butterfly 34.56
Pattern 13.03
Outer to Inner 75.25

Average seek 32.28

max Read 800KB/sec
max Write 804KB/sec
Avg access 4.40 ms

Not too shabby really for a ZIP 100!

It's late here now so I'll try the 6.0.8 variant of this test tomorrow.
 

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,655
1,416
113
53
Japan
youtube.com
@JDW I would keep the 74LS245s since that's the same as the original. The 74F-series parts however should not be replaced with 74ACT and instead 74FCT or 74AHCT would be better.
@Zane Kaminski
So as to update my SE Reloaded BOM, I was searching today for your recommended 74FCT & 74AHCT parts. I cannot find 74AHCT in a DIP package, so that poses a problem for use on an SE motherboard. I was, however, able to find part number IDT74FCT257TP on DigiKey (not on Mouser). Please confirm if this is your top pick IC and if so, I'll update my BOM (and eventually order some for myself).

UPDATE #1: Bad news. Those chips on DigiKey require a stupid 325pc minimum order! So those chips are not possible to use, sadly.

UPDATE #2: Rochester Electronics sells them in single piece quantities, but they have a ridiculous $250 minimum order!

:rolleyes:
 
Last edited:
  • Wow
Reactions: iPhil64

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,655
1,416
113
53
Japan
youtube.com
I retested with the SCSI Director Pro 4.0 disk test using firmware 0.7d-fastscc flashed to WarpSE and using the newest v1.1-20231116 firmware flashed to my BlueSCSI v1. However, this time I disabled WarpSE via INTERRUPT switch and then booted into System 7.1 and tested. No problems...

1729155870860.png


I then powered OFF and ON to retest with WarpSE active, and for some reason, it passed the test without error this time:

1729155854632.png


Why I got the "memory error" as reported in my previous post is a mystery. The other interesting thing is that the "dip" in the graph for Writes, shown in my previous post, is now gone. Strange these two problems magically vanished, but oh well. Such is life, I guess.

One thing this testing shows is that SCSI speed has improved in WarpSE firmware 0.7d-fastscc, as compared to earlier firmware versions where I was getting about the same performance from my BlueSCSIv1 as I got with using the stock 8MHz SE. In other words, that speed bump has nothing to do with the firmware on my BlueSCSI, and I know that because I flashed the old Dec. 2022 BSv1 firmware and tested and got the same graphs you see above.
 

Zane Kaminski

Administrator
Staff member
Founder
Sep 5, 2021
372
612
93
Columbus, Ohio, USA
@ppuskari Thanks for your help testing!! Glad we can now put put "fastscsi" back into the mainline release.

@JDW thanks for investigating this! As I said to Petar, we have put back the "fastscsi" into the 0.7d-series releases, so SCSI will be significantly faster. Are you using the SCSI Director 4.0 drivers? I guess there may be two parts, an init/extension/control panel with drivers and also the drivers that go on the SCSI drive which the Mac loads and then executes. So if the tests work better using the SCSI Director 3.x or other drivers, I think it's probably because of some timing-dependent code in SCSI Director 4.0, maybe there are some blind reads/writes or something. I will investigate SCSI Director 4.0 soon.

As for the chips, thinking further about this, since the RAM row/column address bus is only level-sensitive, it shouldn't really matter if ACT chips are used. The edge rate will be much faster than 74F so the signal may ring in the RAM sockets, but the RAM address bus is not edge-sensitive. Therefore it shouldn't matter if there's an oscillation between 1 and 0 after the transition since it will resolve itself before the RAS/CAS signals become active. Plus this couldn't cause an issue with the WarpSE since it only writes to motherboard RAM and never reads from it. So with the WarpSE, the only possibility from the ACT-series chips being too fast would be oscillations on the address bus that shouldn't matter.

One thing left to try is streaming audio over LocalTalk. This test will really stress the WarpSE especially the slowdown stuff. @ppuskari you mentioned this earlier. What program did you have in mind for this?

In the meantime, I'm finishing up the final board revision. It seems like we have some new competition from the new 68030-based accelerator from MacEffects. It's a clone of the old MicroMac Performer and for the most part not as fast as the WarpSE but we should try to fire back anyway! So I am consolidating the clock input pins into an "overclocking header" that will replace the old debug header. In conjunction with this, we will be making a little "overclocking kit" board that goes on the header with 30, 32, and 36 MHz oscillators selectable via DIP switch. You'll also be able to select different wait state options. With our 800nm 68HC000s, 30 MHz operation with one extra RAM wait state is almost certainly possible, and 36 MHz operation (also with a RAM and ROM wait state) should achievable on most if not all units. Will post pictures soon once I finalize the overclocking header pinout!

In the meantime, for testers, 0.d-fastscc is the version to keep testing! SCSI Director 4.x issues seem mostly benign since there were also issues on Petar's other accelerator. So hopefully there are no more "showstopper" bugs!
 
Last edited:
  • Like
Reactions: iPhil64

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,655
1,416
113
53
Japan
youtube.com
@JDW Are you using the SCSI Director 4.0 drivers?
No. On my BlueSCSI v1, I am using the Eric Helgeson recommended Apple HD SC Setup 7.3.5 driver.

It seems like we have some new competition from the new 68030-based accelerator from MacEffects. It's a clone of the old MicroMac Performer and for the most part not as fast as the WarpSE...
I spotted that being talked about on FaceBook today. My opinion is that it doesn't really compete because an 030 is a very different beast than a 68000. It probably requires some kind of extension or CP to enable all the caches, right? But even if it doesn't, I don't believe an 030 processor can boot into the earliest versions of MacOS like System 0.95 and Finder 1.0. I know WarpSE can do that because I've tested and proven it! And I think that makes the Mac SE really special. Because with WarpSE, you get your same SE software compatibility experience ONLY FASTER! With the 020 and 030 chips, there are more restrictions in place about what software you can run. That's why I think 020 and 030 accelerators for the SE are a different category of accelerator.

Of course, the flip side of the coin is that some software requires an 020 or higher to run. But typically those apps require more than 4MB of RAM too, so you can't run them anyway. And I don't think the MacEffects accelerator breaks the 4MB RAM ceiling.

I don't wish to undermine MacEffects at all by saying all this. I'm a big fan of Mark and his products. But when you are talking about an 030 or faster in a compact Mac, it raises the question as to whether you are best served by a Mac SE, or if you should go with an SE/30 instead.

I therefore think there's a lot of merit to WarpSE, and 030 accelerators really don't steal its thunder in my eyes at all. Which means, all this work being done on WarpSE is certainly not in vain. It just needs to be marketed with "backward software compatibility" at the forefront. It does have that advantage over 030 accelerators.

Speaking of "compatibility"...

I made a NEW DISCOVERY!

Since my 800K drive is all rusted up (so badly that I am not inclined to even try to fix it), I decided to install the 1.44MB Superdrive from one of my SE/30 machines into my SE. Keep in mind I have the old ROMs & old IWM chip on my SE Reloaded motherboard. Zane, I believe you said that WarpSE has the new SE ROMs built-in. But the fact remains I do NOT have a SWIM chip. And so, with WarpSE enabled, it gives me the new ROMs with the old IWM.

I started my tests by booting from my BlueSCSI into System 7.1, with WarpSE enabled:
  1. Inserted a Mac formatted 1.44MB floppy. It reads the disk and recognizes it as 1.44MB! I wasn't expecting that!
  2. I formatted the disk as a 1.44MB floppy. It formatted and verified fine!
  3. I used a 1.44MB disk image on my BlueSCSI to write its content to my real 1.44MB disk. The copy finished without issue! Software launched from my 1.44MB floppy just fine!
  4. I erased the disk and then copied my System & Finder files from my BlueSCSI's System 6.0.8 system folder to the 1.44MB floppy, but when I rebooted the SE refused to boot from the floppy and ejected it. So even though Reading/Writing/Formatting works on 1.44MB floppies, booting isn't supported.
I then powered OFF & ON while pressing INTERRUPT to boot from my BlueSCSI into System 7.1 using the stock 8MHz processor (WarpSE disabled):
  1. When I inserted the 1.44MB floppy, it asks if I want to initialize it as 400K or 800K, which means 1.44MB disks are not understood. That is expected behavior because I have old ROMs and the IWM chip on my motherboard. If you proceed to Initialize without tape, it will fail, but with tape covering the hole, it will succeed.
  2. I used System Picker to set the boot OS to be System 6.0.8, and then I restarted and inserted a 1.44MB floppy formatted as a 400K MFS boot disk with System 3.2 & Finder 5.3. It booted of that floppy disk just fine, although the sound of the drive is a low pitched tone, somewhat resembling a grinding sound.
  3. I then ejected the disk and put a piece of tape over the hole which only 1.44MB disks have, then rebooted from that same disk. This time, the sound of the drive was normal. No more grinding sound.
  4. I took a fresh 1.44MB disk and put tape over the hole and inserted it into the drive, and I formatted it in System 6 as a 400K MFS floppy (yes, I know you shouldn't do that, but I'm testing here!). I then copied my System 3.2 / Finder 5.3 disk content to that newly formatted 400K disk. That worked just fine.
  5. When I booted from the newly created disk without tape covering the hole, it made a grinding sound but it booted. I then put tape on and rebooted from it, and the drive head sound returned to normal.
I then powered OFF & ON and left WarpSE enabled and booted into System 6 from my BlueSCSI:
  1. Inserting my 1.44MB 400K-formatted disk without the tape covering causes the OS to ask me to initialize the disk.
  2. Inserting my 1.44MB 400K-formatted disk with the tape covering allows the disk to be read and mounted just fine.
CONCLUSION
The newer ROMs onboard the WarpSE enable use of 1.44MB floppies when you have a 1.44MB floppy drive installed, and you can do anything you like with those disks, with WarpSE enabled, except for booting. So it would seem that to boot from a 1.44MB disk requires the SWIM chip. And while you shouldn't format 1.44MB disks as 400K or 800K, if you do decide to do that, you just need to remember to put tape over the hole.

I really wish I had a SWIM chip to test things further. For example, I want to see if I can boot from a 1.44MB floppy into System 0.95 and Finder 1.0.
 

JTRetro

Tinkerer
Nov 3, 2021
44
49
18
No. On my BlueSCSI v1, I am using the Eric Helgeson recommended Apple HD SC Setup 7.3.5 driver.


I spotted that being talked about on FaceBook today. My opinion is that it doesn't really compete because an 030 is a very different beast than a 68000. It probably requires some kind of extension or CP to enable all the caches, right? But even if it doesn't, I don't believe an 030 processor can boot into the earliest versions of MacOS like System 0.95 and Finder 1.0. I know WarpSE can do that because I've tested and proven it! And I think that makes the Mac SE really special. Because with WarpSE, you get your same SE software compatibility experience ONLY FASTER! With the 020 and 030 chips, there are more restrictions in place about what software you can run. That's why I think 020 and 030 accelerators for the SE are a different category of accelerator.

Of course, the flip side of the coin is that some software requires an 020 or higher to run. But typically those apps require more than 4MB of RAM too, so you can't run them anyway. And I don't think the MacEffects accelerator breaks the 4MB RAM ceiling.

I don't wish to undermine MacEffects at all by saying all this. I'm a big fan of Mark and his products. But when you are talking about an 030 or faster in a compact Mac, it raises the question as to whether you are best served by a Mac SE, or if you should go with an SE/30 instead.

I therefore think there's a lot of merit to WarpSE, and 030 accelerators really don't steal its thunder in my eyes at all. Which means, all this work being done on WarpSE is certainly not in vain. It just needs to be marketed with "backward software compatibility" at the forefront. It does have that advantage over 030 accelerators.

Speaking of "compatibility"...

I made a NEW DISCOVERY!

Since my 800K drive is all rusted up (so badly that I am not inclined to even try to fix it), I decided to install the 1.44MB Superdrive from one of my SE/30 machines into my SE. Keep in mind I have the old ROMs & old IWM chip on my SE Reloaded motherboard. Zane, I believe you said that WarpSE has the new SE ROMs built-in. But the fact remains I do NOT have a SWIM chip. And so, with WarpSE enabled, it gives me the new ROMs with the old IWM.

I started my tests by booting from my BlueSCSI into System 7.1, with WarpSE enabled:
  1. Inserted a Mac formatted 1.44MB floppy. It reads the disk and recognizes it as 1.44MB! I wasn't expecting that!
  2. I formatted the disk as a 1.44MB floppy. It formatted and verified fine!
  3. I used a 1.44MB disk image on my BlueSCSI to write its content to my real 1.44MB disk. The copy finished without issue! Software launched from my 1.44MB floppy just fine!
  4. I erased the disk and then copied my System & Finder files from my BlueSCSI's System 6.0.8 system folder to the 1.44MB floppy, but when I rebooted the SE refused to boot from the floppy and ejected it. So even though Reading/Writing/Formatting works on 1.44MB floppies, booting isn't supported.
I then powered OFF & ON while pressing INTERRUPT to boot from my BlueSCSI into System 7.1 using the stock 8MHz processor (WarpSE disabled):
  1. When I inserted the 1.44MB floppy, it asks if I want to initialize it as 400K or 800K, which means 1.44MB disks are not understood. That is expected behavior because I have old ROMs and the IWM chip on my motherboard. If you proceed to Initialize without tape, it will fail, but with tape covering the hole, it will succeed.
  2. I used System Picker to set the boot OS to be System 6.0.8, and then I restarted and inserted a 1.44MB floppy formatted as a 400K MFS boot disk with System 3.2 & Finder 5.3. It booted of that floppy disk just fine, although the sound of the drive is a low pitched tone, somewhat resembling a grinding sound.
  3. I then ejected the disk and put a piece of tape over the hole which only 1.44MB disks have, then rebooted from that same disk. This time, the sound of the drive was normal. No more grinding sound.
  4. I took a fresh 1.44MB disk and put tape over the hole and inserted it into the drive, and I formatted it in System 6 as a 400K MFS floppy (yes, I know you shouldn't do that, but I'm testing here!). I then copied my System 3.2 / Finder 5.3 disk content to that newly formatted 400K disk. That worked just fine.
  5. When I booted from the newly created disk without tape covering the hole, it made a grinding sound but it booted. I then put tape on and rebooted from it, and the drive head sound returned to normal.
I then powered OFF & ON and left WarpSE enabled and booted into System 6 from my BlueSCSI:
  1. Inserting my 1.44MB 400K-formatted disk without the tape covering causes the OS to ask me to initialize the disk.
  2. Inserting my 1.44MB 400K-formatted disk with the tape covering allows the disk to be read and mounted just fine.
CONCLUSION
The newer ROMs onboard the WarpSE enable use of 1.44MB floppies when you have a 1.44MB floppy drive installed, and you can do anything you like with those disks, with WarpSE enabled, except for booting. So it would seem that to boot from a 1.44MB disk requires the SWIM chip. And while you shouldn't format 1.44MB disks as 400K or 800K, if you do decide to do that, you just need to remember to put tape over the hole.

I really wish I had a SWIM chip to test things further. For example, I want to see if I can boot from a 1.44MB floppy into System 0.95 and Finder 1.0.
This is pretty amazing! I will re-install my 800k SE board in my test machine later today when I get home from work and duplicate this test.
 

eric

Administrator
Staff member
Sep 2, 2021
961
1,569
93
MN
scsi.blue
No. On my BlueSCSI v1, I am using the Eric Helgeson recommended Apple HD SC Setup 7.3.5 driver.
Just to clarify the recommendation is not for the "best" or "fastest" it's for "the most compatible" - if you're not moving this image between a Plus and a G3 then you should defiantly give another driver a shot. FWB is amazingly fast on PPC, and I'm sure you can eek out a few kb/sec with a different driver on some 68k's too - just take a backup before trying.
 
  • Like
Reactions: Zane Kaminski

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,655
1,416
113
53
Japan
youtube.com
Just to clarify the recommendation is not for the "best" or "fastest" it's for "the most compatible" - if you're not moving this image between a Plus and a G3 then you should defiantly give another driver a shot. FWB is amazingly fast on PPC, and I'm sure you can eke out a few kb/sec with a different driver on some 68k's too - just take a backup before trying.
In the context of this WarpSE thread, I was merely saying that 7.3.5 is the best BluseSCSIv1 driver for the Mac SE, especially when when booting very old operating systems like System 6 and below.

It’s critically important to bear in mind that I’ve said that WarpSE can be fully enabled in your Mac SE with BluseSCSI and the 7.3.5 driver even when booting a floppy using System file version 0.95 and Finder version 1.0.

I know about this driver compatibility also from past testing with my SE/30, where the OS 8 driver I tested back at that time didn’t work with very old pre-System7 system software. I spent many hours of testing that, and I ultimately found that your original recommended 7.3.5 driver was the best for that particular use case.

So in my overall testing of BlueSCSIv1 on the earliest Macs running very old System Software, the 7.3.5 driver is rock solid.
 
  • Like
Reactions: Zane Kaminski

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,655
1,416
113
53
Japan
youtube.com

Check this out...

1729247527990.png


What you're looking at is my Mac SE with WarpSE enabled, booted from my BlueSCSI v1 (7.3.5 driver) into System 1.1 & Finder 1.1g. That's pretty exciting. But here's the kicker. It's a 20MB "MFS" drive image. :cool: No HFS here!

It's incredible that WarpSE can be enabled and still allow all this to work. And keep in mind that WarpSE has the new SE ROMs onboard, yet it all still works! True, I still have an IWM chip and don't yet know how a SWIM chip will behave, but I spoke to @Kay K.M.Mods today about ordering one of his Super Wh-IWM Swapper products. Having a SWIM will let me do more testing Kay's SWIM device is a really neat product because its low profile and Kay will include an SMD SWIM chip too if you choose that option. (His PCB is an adapter that lets you socket an SMD SWIM, giving you a DIP SWIM chip you can insert into your SE.)



💡 USEFUL TIP: You can always know if your drive is MFS or HFS by looking between the two horizontal lines in any window, at the left side of the window, where the black arrow pointer in the screenshots below is pointing. If there is not a single pixel in there, it's MFS. If you have the single pixel, its HFS.

MFS disk:
1729247910398.png


HFS disk:
1729247947697.png




Now you might be wondering how in the world I was able to create an MFS hard disk image for my BlueSCSI. Here's how...

CREATING AN MFS BOOT VOLUME FOR BLUESCSI:

1. Launch Disk Jockey (by @OneGeekArmy )

2. Create a 20MB image (the maximum size MFS officially supports) for BlueSCSI that is "Blank HFS", as shown in the screenshot below. (Disk Jockey doesn't allow you to make a "Blank MFS", but I'll soon show you how to fix that.)

1729248128532.png


3. Download the special version of Mini vMac by @eric which let's you mount BlueSCSI images. Get the Mac Plus version:

1729248992437.png


3. Download System 2 and use the one with Finder 4.1:

1729249089473.png


4. Boot Mini vMac from System 2.0 (Finder 4.1).dsk. Then drag your image, created by Disk Jockey, into the Mini vMac window, and it will ask you to Initialize. Click Initialize. Then name it. You're done at this point, but you still should verify its MFS, which is Step-5.

1729248888919.png


5. Shutdown and then boot from a more recent System Software *.dsk that is HFS aware, such as System 3.2 and Finder 5.3. Then mount your newly formatted 20MB volume. Then open some windows and check for the single pixel I told you about. It won't be there on your 20MB volume because it's MFS!

You can now copy files over to your 20MB volume, but be aware that if you use System 1.1 & Finder 1.1g, there is no New Folder menu command. The OS is too old. But if you do all your new folder creation on your 20MB volume while booted from a different disk into System 3.2 and Finder 5.3, those folders will be MFS because your 20MB volume is MFS, and if you later boot from your 20MB volume into a non-HFS aware System and Finder, all your folders will still be there.

Keep in mind that folders are a fake illusion on MFS disks. They are real on HFS disks.

The reason that creating a 20MB MFS drive volume is useful is because if you were to just create a standard HFS volume in Disk Jockey and then copy files and folders to it, but then you put a very old OS on it that is not HFS aware, all the content inside folders will be missing.

I mention all this to illustrate how incredible WarpSE is.

You can really have some serious fun with your Mac SE, running the oldest OS's with full 25MHz acceleration too! It's a blast!
 

JTRetro

Tinkerer
Nov 3, 2021
44
49
18
So I tried to duplicate the test results the @JDW had where he was able to read 1.44Mb floppies off of an SE board with only 800k capabilities and.......nothing, womp womp. Maybe there is another fundamental difference between the re-loaded board and a stock one? There shouldn't be, but there seems to be, judging from all of the test results that i have seen posted here.

In this test, I was once again using a stock SE 800k board with 4Mb of RAM, O.S. 7.1 running off of an original 20Mb drive, and PC Exchange is loaded and running. Oh yes, forgot to mention that this is firmware version .7d-fastscc:

DSCN8876.JPG

No problems reading 400k or 800k disks at least!

I also did a quick test with Speedometer 3.23, and I returned the fastest results yet in terms of CPU and disk access speed. For this test, i used an Iomega 100Mb drive for the disk drive:

DSCN8877.JPG
 
  • Like
Reactions: Zane Kaminski

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,655
1,416
113
53
Japan
youtube.com
@JTRetro
You said you cannot read 1.44MB disks, but it's important to keep in mind that I cannot read them either in the Stock 8MHz state (WarpSE disabled). I must enable WarpSE (firmware 0.7d-fastscc), and then 1.44MB floppy access worked (a really 1.44MB floppy drive mounted internally and connected to the "LOWER" marked ribbon cable connector on the motherboard. But take note that I still had an IWM chip on the motherboard. Remember, WarpSE has the new SE ROMs onboard, but it doesn't have an onboard IWM or SWIM. Yes, I did all my testing on my SE Reloaded board, but I'm not sure if that makes a difference. I left my stock motherboard at the office, so I can't test that until Monday.

And so, the combination of WarpSE and my old IWM chip (on my SE Reloaded board) allowed me to READ from 1.44MB disks. I could also write, format, copy files and all that, but the one thing I could NOT do was BOOT from 1.44MB disks. I assume that means I need a SWIM, and that is why I contacted @Kay K.M.Mods yesterday to inquire about ordering one of his recreations. He said he won't be able to process that order until next week, so I am just waiting for now.

So if you have a SWIM chip and not an IWM, that would be a key difference between your testing and mine. And that would theoretically mean that if I installed the Kay Koba SWIM chip in my board, I may get the same results as you. But again, I won't know until I do the actual testing.
 
  • Like
Reactions: Zane Kaminski

Zane Kaminski

Administrator
Staff member
Founder
Sep 5, 2021
372
612
93
Columbus, Ohio, USA
@JDW This business about the IWM and HD floppies is very interesting!! What exactly are the markings on your IWM? I do see a an interview with Steve Wozniak from 1984, before the SWIM but after the IWM, where he says the IWM can do "IBM format, double density recording": https://downloads.reactivemicro.com/Users/Grant_Stockley/Apple2WozInterviewBYTE1984.pdf

Have we discovered this? Maybe it didn't quite work right and the PC/HD compatibility was not used until the SWIM? Or maybe James has a SWIM labeled as an IWM or something like that?


Anyway, I've got the new overclocking/debug connector on the side of the WarpSE:
Screenshot 2024-10-19 at 6.51.53 AM.png
There used to be some overclocking headers spread around the board but this new version consolidates everything.

This little overclocking board goes in the overclocking connector:
PNG image.png

You can select 30 MHz, 32 MHz, or 36 MHz, plus there are settings for RAM, ROM, and I/O wait states. My recommended settings:
SpeedI/O Wait StateROM Wait StateRAM Wait State
30 MHzOnOffTry off, then on
32 MHzOnOffTry off, then on
36 MHzOnTry off, then onOn

I hear the Amiga folks run their 'MC68HC000s at 50 MHz so with 800nm parts these speeds oughta work fairly well but it's not guaranteed.

A little explanation on the overclocking options:

I/O wait state is recommended at all speeds 28.4 MHz or above. It doesn't really affect performance, but if not enabled the WarpSE's CPU could latch data from the PDS too early. So when overclocking above 28.4 MHz always turn it on.

On the other hand, adding a RAM or ROM wait state will decrease performance by about 20% but it might be necessary to achieve a particular speed. All WarpSE units are gonna have 60 ns DRAM and 70 ns flash ROM, but if we're lucky, the RAM could perform closer to 50 ns and the ROM closer to 55 ns (or even faster), since those are the next faster speed grades for the RAM and ROM respectively.

You have to know a bit about the WarpSE's timing budget to figure out how tight the timing is and whether you can get away without adding a RAM or ROM wait state.

For RAM accesses without a wait state, the WarpSE has basically 2.5 clock cycles to access it. The budget calculation is basically subtracting all the other delays in accessing the RAM from this 2.5 clock cycle amount of time. So to access the RAM, a series of things has to happen: the MC68k can take 20 nanoseconds to assert /AS, then the CPLD sees /AS and can take another 10 nanoseconds to assert the /RAS signal to the RAM, then the RAM takes up to 60 nanoseconds, then the MC68k requires the data to be ready 5 nanoseconds before the clock. You have to subtract these figures from the 2.5 clocks and the result oughta be positive to ensure it'll work. So for example, at 25 MHz, 2.5 clocks is 100 nanoseconds. Then you subtract those delays--20 ns, 10 ns, 60 ns, 5 ns--and there's 5 ns left in the budget. At 30 MHz, however, 2.5 clocks is only 83.3 nanoseconds. So if everything performs worst case, that blows the worst timing budget by 11.7 nanoseconds. So at 30 MHz, the RAM wait state may be necessary.

However, you could imagine that since we're using 800 nm MC68HC000s, and since the /AS signal is a really short wire just between the 68k and CPLD, that it won't take the whole worst-case 20 nanoseconds for the 68k to assert /AS. It might take only 16 ns for it to assert /AS. Then maybe we make up 1 ns in the CPLD (9 ns instead of 10), and maybe RAM is performing at 55 ns. And then the 800nm 68k probably doesn't need the whole 5 ns setup time so shave another 2 ns off... Well if everything is a bit faster like that, then we have spare time and conceivably 30 MHz will work without the RAM wait state. But maybe not if everything performs to worst-case specs.

However even if 30 MHz works without a RAM wait state, 32 MHz is less likely to work and 36 MHz even less so. So for 36 MHz in particular, the RAM wait state will almost certainly be required. With the wait state, then you get 3.5 clocks to access the RAM, which even at 36 MHz is plenty. However, adding the wait state reduces performance by 20% or so in RAM-bound workloads. So with the overclocking kit, you can experiment a bit and see what works for you.

ROM timing is better and also easier to calculate. For ROM, you get three clocks to access it, minus 20 ns for the 68k to put out the address, 70 ns to access the ROM, and then 5 ns data setup time at the 68k. So ROM definitely does not require a wait state at 30 MHz, and the worst-case ROM timing budget is only 1.25 nanoseconds short at 32 MHz and no wait state. So that oughta work if all we need is a spare nanosecond. However a wait state might be required at 36 MHz. Maybe not though since I think it's highly likely the 70 ns flash ROM will perform closer to 55 ns speed.

This oughta be good! Should boost the speed a fair amount. And of course I'm going to like 25.946 MHz on the production WarpSEs as well, since that squeezes all but the last nanosecond out of the worst-case timing budget. I think we may include this overclocking kit with the first bunch of units sold to get feedback and better understand the overclockability. Then later it might be an optional add-on. Not sure yet. Also if you're good at soldering it's easy to make your own little protoboard version with a through-hole oscillator and fixed soldered wait state options.
 
Last edited:

phipli

Tinkerer
Sep 23, 2021
141
128
43
In this test, I was once again using a stock SE 800k board with 4Mb of RAM, O.S. 7.1 running off of an original 20Mb drive, and PC Exchange is loaded and running. Oh yes, forgot to mention that this is firmware version .7d-fastscc:
And a superdrive?

And so, the combination of WarpSE and my old IWM chip (on my SE Reloaded board) allowed me to READ from 1.44MB disks.

So... it shouldn't... really be possible.

Short background - The SWIM is a IWM with a second "chip" added, the ISM. These two separate parts of the SWIM are very close to functionally identical to their stand alone predecessors. In a FDHD SE, the IWM part controls the drive for reading apple GCR style disks, and the ISM runs the show for IBM style MFM disks. Later versions they stopped using the IWM bit and the ISM did everything.

Edit...

1729344936678.png

... End Edit

I went through all the documentation I could find on the IWM and the SWIM and nothing mentions anything other than a theoretical possibility. Why would Apple leave it out of their own internal confidential documentation? Why would Apple spend the time writing code designed to use the IWM to control a 1.4MB MFM, when all computers used the ISM (Integrated State Machine) that was combined into the SWIM by adding it to the IWM?

My only thought (complete guess) is, the IWM in the SE is actually a failed SWIM - they contain the IWM and the ISM, but they never usually use the ISM because of a bug - perhaps that bug stops them booting. This wouldn't be the only time Apple did things like this, there were many features that got cancelled because there wasn't time to add them to the OS (hardware audio decompression in the Quadra 700), or it just didn't happen (ADB integrated into the chipset proper in the Wombat).

To check, what we could do is get a 344-0043A equipped machine and poke ISM registers - see if we can confirm that the ISM is present. Perhaps we could write a "My IWM has an ISM" application :LOL:

Or, something has got mixed up and your IWM is actually a SWIM chip.

My SE is away at the moment because I'm meant to be finalising the 475 overclock code and doing testing on the 6200 and 6100... but I might do some digging if I have time.

Perhaps this needs its own thread? It is a nice potential feature for the WarpSE, but perhaps we could get more stuck into research and stuff without getting in the way of the testing here.
 
Last edited:

Zane Kaminski

Administrator
Staff member
Founder
Sep 5, 2021
372
612
93
Columbus, Ohio, USA
Perhaps this needs its own thread? It is a nice potential feature for the WarpSE, but perhaps we could get more stuck into research and stuff without getting in the way of the testing here.
One thing we do need to make sure of is that there are no unforeseen problems from using the SWIM ROM with an IWM chip. Just in case of an issue, I will be putting both the original SE and the FDHD ROMs on the flash chips for the final board.

So if there's any issue in IWM machines we can do a firmware update to change the ROM addressing slightly and use the original SE ROM. I'm also gonna include the Mac Classic ROM as @phipli suggested so we can try its ROM disk. All that adds up to 1 MB (256 kB for each of the SE ROMs and 512 kB for the Classic ROM), which is equal to the ROM capacity of the WarpSE. Great!
 
  • Love
Reactions: JDW