Another IIci ROM hack

[dougg3]

Thanks ojfd!

Now I'm busy separating the traces from each other a bit. I just realized my design rule check was set at 6 mils for clearance. Seeed Studio claims they can do it, but I don't trust that they will be able to do it reliably. I'm trying to get 8 mils of clearance at minimum...

 

[Trash80toHP_Mini]

I worked a few tricks I've learned over the years doing analog photography.

Basically, I hoodwinked my very first digital camera into taking some halfway decent pictures of the Jolly Roger in action! :approve:

IIsiHackKluge:

Close-up of the Rev.1 Jolly Roger in action:

p.s. Tweaking in GraphicConverter helps a lot, but there's NOTHING like dodgin'-n-burnin' print effects in an analog darkroom! }

 

[dougg3]

Very nice jt! It's awesome to see the Jolly Roger happy inside a Mac! Cool pics!

Latest update: I have a headache now, but 400+ DRC errors fixed later, I now have a board that passes the test with 8 mil spacing...



I think I'm going to pass on the ferrite beads on this board, but I'll definitely keep them in mind in the future (or if I start having hardware problems...)

 

[Trash80toHP_Mini]

Thanks, doug! Although, at this point, I think I'd describe it more as the Jolly Roger resigned to being in the middle of a Mess! :lol:

BTW, I discovered something quite by accident while I was taking those shots. When there's no monitor attached to the MoBo and no Monitor attached to the Liberty Adapter for the Radius Color Pivot II/IIsi Card, I get a five note death chime a few seconds after the boot chime every time! Plug in the 16" Sony Trinitron to power up the sense lines on the IIsi's MoBo and it boots up like a champ.

The results are repeatable, therefore I just have to test it out with the MoBo ROM and both the IIsi ROM SIMM configurations to see what's up. :?:

Simply maaaaaahvelous! :

Though it normally ROCKS, serendipity apparently gots its compliment of Yang to balance the Yin . . . like everything else!

__________________________________________________________

I just had a thought about the placement of your header rows . . . for clearance . . .

. . . how complicated would it be to move them another 10-15 mills farther from the SIMM Socket?

 

[dougg3]

Interesting! I don't think that would matter as far as the SIMM is concerned, but I guess it depends on which ROM image you're booting from.

It is definitely possible to move the headers for some clearance. Good idea--there's plenty of board space available, even more if I move the RS-232 chip up. I'll do that! Shouldn't be a difficult change.

 

[dougg3]

Moved it back as far as I could with the size of the board being what it is...sorry if these PCB design updates are getting annoying, I'm almost done!

 

[ojfd]

I have a headache now, but 400+ DRC errors fixed later, I now have a board that passes the test with 8 mil spacing...

Congratulations, dougg3, very nice job! Fixing 400+ errors manually indeed takes some time.

I think I'm going to pass on the ferrite beads on this board, but I'll definitely keep them in mind in the future (or if I start having hardware problems...)

Yes, skip them. I am 100% sure that your board will work as it stands now.

...sorry if these PCB design updates are getting annoying, I'm almost done!

I thin'k it's very good and very educational to that you're publishing progress of your design, especially for casual reader. Next time people, who thought that it's all automatic, 5 minutes, auto-router does it all, will (hopefully) aprreciate the amount of work needed to create a finished product and (hopefully) will stop whining when asked to pay fair price for it.

Go dougg3!

 

[Trash80toHP_Mini]

I'll second that motion, I think it's great that you're documenting the process of creating, not just grounbreaking 68k firmware hacking, but the actual hardware to make it practical for others to try, and now, the tools required to get involved for others to play around with old Macs at an affordable price.

I'm continually amazed at your three level hacking thread, bbraun's incredible ROM Expansion achievements and all the technical expertise you've brought out of the woodwork from so many comrades. The tangential projects under development, like BMOWs unprecedented work and his involvement here in this thread, have been a boon to all.

Your introductory thread has become a treasure trove of content and demolished windmills, DQ!

Go, doug, go!**

jt

p.s. you moved the headers much farther back, great job. I've got pictures of triangular adapter cards dancing around in my head! :approve:

** silly literary reference for anybody who's read to kids )

 

[dougg3]

Congratulations, dougg3, very nice job! Fixing 400+ errors manually indeed takes some time.

Thanks!!! It took a ridiculous amount of time Although sometimes fixing one error would make 10 of the DRC errors go away, but still...it was ridiculous. I think if I had set the auto router correctly for 8 mil spacing I would have been better off. I agree totally with what you said. The auto router is nice but you really have to do a lot of cleanup by hand, and it ain't easy!

I thin'k it's very good and very educational to that you're publishing progress of your design, especially for casual reader....

Go dougg3!

I'll second that motion

Thanks guys! I appreciate all the help and suggestions and everything. This has been a cool way for me to learn a lot about hardware Not to mention I'm incredibly impressed by all the other cool stuff that has happened in here, like olePigeon's graphics and bbraun's ROM disk!

I've got pictures of triangular adapter cards dancing around in my head! :approve:
** silly literary reference for anybody who's read to kids )

LOL...or for anyone who has ever been a kid

OK, so here's the deal. I think I'm pretty much done with the board. I added a few labels for the pin numbers and stuff. I'll still go over the layout and schematic with a fine-toothed comb a few more times, but it's pretty much done. In celebration, I used a cool script for EAGLE to render an (almost assembled) PCB in 3D! (Sadly, I don't think it has a 3D model of the SIMM socket)

 

[Trash80toHP_Mini]

Go, Dawg, GO! VERY, VERY

That rendering is beeeaaaaauuuuutifuuuuul! :approve:

Now that I've seen the connectors and header pins, I've got a couple of packaging considerations for you. :

If there's any way to move the USB connector over so that it hangs over the edge just about the thickness of a piece of thin plexi (actual thickness to be determined) and the DB-9 out to just about the same amount, I can see your board enclosed in a clear box with a clear plexi hinged lid or a rabbeted pop-top!

I know the crystal can positioning may be problematic, doug, but it might be worth a bit of rework. Some metal screening material inside the plexi for RFI reduction purposes and ESD event prevention might push the packaging parameters out a little farther than I first thought.

ojfd, what do you think? :?:

edit: a bent or mitered aluminum angle exoskeleton with a rabbeted clear plexi pop top and clear fixed base plate/chassis might be better!

 

[ojfd]

If there's any way to move the USB connector over so that it hangs over the edge just about the thickness of a piece of thin plexi (actual thickness to be determined) and the DB-9 out to just about the same amount, I can see your board enclosed in a clear box with a clear plexi hinged lid or a rabbeted pop-top!

ojfd, what do you think?

I can't speak for dougg3, but for me that would mean total re-design. Time=$, you know.

Besides, you can make your plexi box just a tad larger than PCB, so that USB and DB-9 will line up with the outer surface of the walls nicely and it will look just fine. Others might want to put the PCB in different box and they might have different opinions about preferred look of the final product.

Just let the dougg3 do his job and finish his PCB.

Otherwise, you know what they say about the camel? It is a horse designed by the committee. [] ]'>

 

[dougg3]

That's kind of what I'm worried about too. At this point moving the microcontroller out of the way to make more space for the USB connector would require many changes...

I agree with ojfd, I think it would be easier just to make an enclosure bigger on that side so the USB connector would be flush. I knew the USB connector would overhang over the side of the board--I did it on purpose to give myself more board space. I have a microcontroller dev board that does it, too.

The other option would be to make the board a bit bigger, but unfortunately the board height is already at the limit for EAGLE light edition

Anyway thanks for the idea jt, but I think I'm going to have to leave that alone at this point. I'd be happy to do it if it was as simple as moving the DB-9 would be, but it's not

 

[Trash80toHP_Mini]

I meant to the right and up, no moving of the microcontroller, just the crystal can a smidge.

I know I'm nit-picking after the fact, but it pays to ask, the only stupid question . . .

It's still as all getout, DQ! :approve:

Otherwise, you know what they say about the camel? It is a horse designed by the committee. [] ]'>

:lol: I've heard that one, but I prefer R.A.Heinleins quip: An elephant is just a mouse built to government spec! :approve:

 

[dougg3]

Thanks jt

It's hard to see in the 3D model, but I have the crystal positioned in such a way that both wires to it are the same length, and moving it around would be problematic. Also I have other wires routed where the USB connector would go. I think I'm going to have to leave it as is...like you said, definitely doesn't hurt to ask though

 

[techknight]

Whats the Microchip IC for? I understand what the AVR is for, but the microchip IC? just curious. it was probably explained several pages back, but going through a several page thread is not easy.

 

[dougg3]

It's a 16-bit SPI GPIO expander chip that I used because the AVR does not have enough IO pins to handle all the data and address lines on the SIMM. I wanted to make sure I used something that has both input and output capabilities as well as pull-ups so that I can also use the board to run some basic tests on newly-assembled SIMM PCBs to find any shorts

All the lines attached to the SIMM (on both the microcontroller and the GPIO expander) have optional pull-up resistors, so I should be able to check if they are shorted to ground by setting them all as inputs, turning on the pull-ups, and making sure none of them read a 0. I should also be able to test for any shorts between pins by setting one pin as an output outputting a 0, and everything else as an input with the pull-up activated. If anything reads back as a 0, it would mean it's shorted to the same line I set as an output. As far as I can tell the only short I won't be able to detect will be a short to VCC, since I don't have pull-down resistors available. Anyway, I wouldn't have thought to do this crazy stuff, but after assembling the SIMMs and fighting shorts, I'm thinking it will be a useful tool to have.

Status update: The OCD in me just finished fixing all traces that were not exactly a multiple of 45 degrees. I'm thinking I'm going to send the first batch off to Seeed Studio tonight...

Status update 2: The gerber files have been sent to Seeed Studio. I went for UPS shipping again Can't wait!

 

[Trash80toHP_Mini]

Status update: The OCD in me just finished fixing all traces that were not exactly a multiple of 45 degrees. I'm thinking I'm going to send the first batch off to Seeed Studio tonight...
Status update 2: The gerber files have been sent to Seeed Studio. I went for UPS shipping again Can't wait!

Mazel Tov! [] ]'>

I really have to do some work on the index . . . or . . . any volunteers here want to hunt down and post a batch of links to the important sub-threads? :?:

If you do it in PM to me, it won't ever be seen as tooting your own horn, all you folks have been awesome and I'd like to document your content creation and achievements!

Links to tangential threads would be much appreciated as well, BMOW's "showed up to get involved there" thread posted by Bunsen comes to mind: Plus Too: a DIY Mac clone project (128k -> Plus) That's one I've dug up myself, IIRC he's been posting in here about his incredible project since the last posts in there on Oct. 11th!

I've been home sick . . . not up to a whole lot . . . and a bit (creatively) lazy to boot . . .

. . . besides, procrastination ofttimes pays! }

edit: that was appropriate, this post just rolled us over to p.24! :O Somebody help out with the indexing . . . please!

edit 2: had to quote for context, this is a watershead moment in Mac Hackin' History!

A tool to program the the Jolly Roger SIMMs that's built to test them in production as well.

I think you're up to four layers of hacking here, DQ!

. . . yet another windmill grudgingly crumples to the ground! )

 

[techknight]

ah ok. so its basically like a SPI based shift-register. Well, sorta. hehe.

With this programmer, at least youll be able to keep the PLCC ICs soldered down onto the SIMM without needing the sockets.

 

[bbraun]

It has been a couple days since there has been a a ROMDisk update, so... What I've learned so far from the ROMDisk driver in ROM experiment:

System 6 boots in 24bit addressing mode, at least initially. In 24bit addressing mode, ROM is located at 0x00800000, so pointing the ROM disk driver at 0x40880000 could result in garbage reads. Even though the ROM boots and refers to its self at 0x40800000, 0x00800000 is apparently always mapped, so just changing where the ROM disk driver points fixes that particular issue, and seems to reliably boot to Finder.

My speculation is that the II/IIx/SE30 ROMs were a transition from 24 to 32bit addressing, since the ROMs themselves map to 0x40800000 (the start address for the II ROM is 0x4080002A), but are not consistent in the use of the new 32bit mapping, for example when the ROM loads the DRVR resources, the pointers it returns are in the 0x00800000 range. System 6 boots initially in 24bit addressing mode with reads from 0x40800000 returning garbage, then loads a 'ptch' resource to move into using the newer ROM mappings.

It is not necessary to do a PostEvent(diskEvt, drvNum) for the boot drive, adding it to the Drive Queue is sufficient. When the ROM goes to look for bootable drives, it traverses the Drive Queue, mounts the selected drive, and records the bootdrive number at 0x210. The System picks all this up and runs with it. Only drives that are not the boot drive will then need to post the diskEvt event to get mounted. Subsequent diskEvts for mounted disks are ignored.

Once in Finder, I still have the problem of no cursor movement. As I noted before, the rawmouse low global gets updated, so it looks like interrupts are working, but the CrsrTask isn't getting called. Either it never gets added or something is removing it. I'm leaning towards the removal theory. If I check out the VBL queue once in the Finder, it has 2 entries in it: the Sound driver's VBL task, and another task located in RAM that I'm not too sure about. If I use macsbug and steal an existing VBL queue entry (such as my own), and put the crsrtask address in the VBL queue ptr element, CrsrTask gets run (the cursor is updated), and it works for some short period of time (fractions of a second or so), then that VBL queue element is removed. So, it's possible CrsrTask is removing its own task for some reason.

I'm (somewhat intentionally) not fully emulating the .Sony floppy driver, although at this point I have implemented almost all of the Control and Status entries of the floppy driver. Some of them don't make much sense for the ROM disk (I'm an HD20 with 1024 sectors, because I'm not 400/800/720/etc). The floppy driver installs a VBL task on Open, which seems to poll the floppy for disk insertion, update the SonyVars low global, and fire off a PostEvent(diskEvt) to mount the disk. This isn't particularly relevant for the ROM disk, since it's always attached, but I've tried adding my own VBL task and posting one diskEvt event (subsequent diskEvt events for a mounted disk will be ignored, but no need to do it repeatedly). After boot, I can find my VBL task in the VBL queue, but it makes no difference on the rest of the behavior.

Another thing that's weird about the floppy driver is it has memory at 0x222 which contains pointers to its own Prime/Control/Status and other routines. I'm not touching this space, and it's all initialized to 0xff, except I've noticed some of them are populated with valid looking addresses after boot. Disassembling the code at these addresses, it looks like the System is calling through to the ROM driver's code, then catching the return value and calling off to do something else in specific instances. This should be all harmless, since it appears to require the ROM driver calling these patched routines, which mine doesn't. But, it might be an interesting vector to experiment with bigmessowires' arbitrary sized floppies.

So, I'm trying to figure out the VBL task eater, and what I'm not doing to satisfy it...

 

[dougg3]

I think you're up to four layers of hacking here, DQ!. . . yet another windmill grudgingly crumples to the ground! )

Woohoo!!! I think if any indexing happens, it won't be me doing it for a while. My brain is fried from all the PCB layout work I did this weekend, haha. 8-o xx( |)

Just ordered parts...I got enough of the cheap parts (capacitors, resistors) for 25 boards, but only a few of the expensive parts (the ICs) until I get an idea of how much interest there is in the programmer board. Exciting!

ah ok. so its basically like a SPI based shift-register. Well, sorta. hehe.

Yep, exactly! Just a little more powerful since it's configurable as input/output on a per-pin basis

With this programmer, at least youll be able to keep the PLCC ICs soldered down onto the SIMM without needing the sockets.

Yep! Although some people may still want sockets because it will technically be possible to use the programmer as a burner for any chips with a matching pinout for any purpose...

Edit: And great to see an update bbraun! Hmm...I'd try to help with the VBL task problem but I don't know anything about the system internals.