Another IIci ROM hack

[Trash80toHP_Mini]

Thanks, tt, I can use that graphic! :approve:

From my perspective the Ultra ATA cable header rows will have to be moved up and away from the SIMM Mounting Tab Holes for clearance there, it looks like you've allowed for connector clearance already. I'll do a cardboard fit prototype to see if the clearances will out work with all the connectors in place. Did you confirm that the outboard ends of the IDE cables will not interfere with snapping in/keeping the SIMM in place?

As I said, I can easily be persuaded to do a Seed project if the price is right, but my way has several advantages.

I don't mind taking the time to do the grunt work of assembly from my normal manual process for layout/fab. Being a blast from the 1989 past, it'll be fun, relaxing and theraputic. The IDC ribbon cable mod and use makes for far less expensive multiple/differential length testing process, start long re-munch for successively shorter lengths. I'll probably start off with the nastiest connection first, three feet of standard, crosstalk inducing, non-alternating ground line ribbon cable, one in four odds on that one.

I give that a 50% chance of working reliably with a cable that places my IIsi SIMM in the space under the FDD. [] ]'>

I "know" the project is feasible, down, dirty, fugly, cheap as can be proof, with a side of DeclROM adapter board is almost impossible to resist, from my hacks development program perspective.

p.s. If someone else in the gang wants to adopt this line of research, sans the ROM adapter portion, to Seed the way for the rest of us, it IS a community project! [] ]'>

Besides, I can spend the extra money to replace my storage room whirlpooled Drill Press before I move in with my girlfriend. }

 

[trag]

Rob, that is so cool. Way to go. This is better entertainment than, well most things which are sold as entertainment. Although my son's 10 - 10 ball game last night was quite suspenseful. Some of the most entertaining baseball I've ever seen.

 

[bbraun]

I've written a declrom validator that finds the byte lanes, checks the signature, pulls the length and crc, then computes the CRC. The CRC computation for my card was failing because out of the 66 bytes of my declrom, 2 bytes were being read back differently from what is stored on the 29F040. It helped me track down a mixup of A6 and A8, and once that was figured out, it worked.

I've found I can use either /STERM or /DSACK to acknowledge the read operation. /STERM is supposedly for synchronous operations and /DSACK is for asynchronous, and the 2 /DSACK signals allow for dynamic bus sizing vs. /STERM which is for 32bit bus. My application is a 32bit bus so the bus sizing isn't relevant, and I don't really understand the synchronous vs. asynchronous operation aspect, or if there's even a difference on the mac.

Right now, I'm using /DSACK{0,1}.

To recap:

A2-A20 from the PDS go straight to the 29F040's A0-A18D24-D31 from the PDS go to the 29F040's DQ0-DQ7.The 29F040's /CE is connected to GND, and /WE is connected to VCC.

The address decoding for access to 0xFAXXXXXX is done with:

A24 and A26 from the PDS get inverted by a 7404

/A24, /A26, A25, A27, A28-A31 all get ANDed by a 7408, and the result gets inverted by the 7404, and sent to /OEI know Dennis Nedry pointed out a way to do this with fewer gates, but this is what I did initially and it seems to work, so unless I need to rewire all that logic, I'd rather not.

The /OE line (in addition to being connected to the 29F040) is being sent to the C input of two 74125's, with the A input of each being connected to GND. The output of these two 74125's are being sent to /DSACK0 and /DSACK1.

I've also tried the same config with one 74125 gate and just using /STERM instead of /DSACK, and the results seem the same.

Now that it mostly works, I'll see if I can put this into Osmond PCB and experiment with that.

I guess I've made an 030 PDS card complete with firmware for use on a Mac. Neat. Too bad it doesn't actually do anything.

 

[techknight]

who cares if it doesnt do anything, its the point that the card is "seen" and can be "used" by the mac. So, next step is add a microcontroller to it or something so you can do stuffs with it.

 

[dougg3]

Very nifty, that's awesome that you have it working! Nice work!

I'm wondering if there's any kind of timing requirement for the DSACK or STERM pins -- for example, is it only supposed to go low x nanoseconds after valid data has been placed onto the bus? I started looking in the 68030 manual but quickly lost interest, it's quite a monster. I'm just wondering if the scheme where /OE is going through the tristate buffers into the ack pins might technically be breaking timing requirements that could cause weird problems given the right set of circumstances, and if so, how to correct for that.

 

[bbraun]

Yeah, this seems like quite a hack. I've looked at the timing diagram and can pretty much guarantee it's not doing the right thing. I can't say I really understand the process. This is also about the limit of my ability to work with all these wires on the protoboard though. I was going to see if I can put it onto a PCB as is, just to simplify any further hacking.

 

[tt]

From my perspective the Ultra ATA cable header rows will have to be moved up and away from the SIMM Mounting Tab Holes for clearance there, it looks like you've allowed for connector clearance already. I'll do a cardboard fit prototype to see if the clearances will out work with all the connectors in place. Did you confirm that the outboard ends of the IDE cables will not interfere with snapping in/keeping the SIMM in place?
As I said, I can easily be persuaded to do a Seed project if the price is right, but my way has several advantages.

I don't mind taking the time to do the grunt work of assembly from my normal manual process for layout/fab. B

I just did it as a quick demo, showing much of the work is already completed with the libraries available in the program. No mechanical study or anything was done. I guess I tend to favor speed when working on projects since I feel the longer they go the less likely I will finish them. But if you don't mind soldering the connection points, then I say go for it with an etched board fabbed at home. Only thing I'm wondering is if the connectors would somehow make a difference with signal integrity. I think the SeedStudio price would be about $35 to make 10 4"x4" boards. The SIMM connector would have to hang off the edges of the board since it would go over 4" with the layout I posted earlier.

I guess I've made an 030 PDS card complete with firmware for use on a Mac. Neat. Too bad it doesn't actually do anything.

Yes!!! That is an awesome accomplishment, great work. :b&w:

 

[Trash80toHP_Mini]

I guess I've made an 030 PDS card complete with firmware for use on a Mac. Neat. Too bad it doesn't actually do anything.

8-o My friend . . . saying that is akin to saying that dougg3 just managed to change the startup sound on his IIci . . . :lol:

< . . . manages to hold his . . . tongue? . . . wanders to the fridge to make a root beer toast to this fabulous accomplishment . . . >

< . . . muttering: wire wrap . . . wire wrap . . . wire wrap under his breath the whole time . . . ;D >

 

[dougg3]

I did some more googling and came upon this interesting document about interfacing through the SE/30 PDS to a National Semiconductor SONIC ethernet controller...

http://bitsavers.informatik.uni-stuttgart.de/pdf/national/_appNotes/AN-0691.pdf

Toward the end it provides a few basic boolean equations for some of the glue logic that handles activating the PROM and replying with the DSACK stuff. Looks like some of it is related to being a bus master, but I think there's enough in those equations to describe how the PROM should reply as a slave as well. It might be useful...looks pretty much the same as what you're doing except it also takes the address strobe pin into account.

< . . . manages to hold his . . . tongue? . . . wanders to the fridge to make a root beer toast to this fabulous accomplishment . . . >

Ditto! P.S. the blank SIMMs and sockets are finally on the way to you...

 

[bbraun]

Thanks! Yeah, /AS will be dropped before the address bits are, so it'll get /DSACK dropped earlier in the process like the timing diagrams. That's a good idea, thanks.

As I think about the possibility of adding more than just a flash chip to this, more address decoding becomes necessary. I'm enabling output for the 29F040 if anything in the slot is addressed, when it really should just be enabling if it's at the top of the address space. This seems easy enough with more 7408's, but it seems like it quickly gets out of hand. I'll play around with this in Osmond PCB, but like we were talking about, this is where an FPGA would be nice. An FPGA dev kit might be in my future.

 

[dougg3]

Yeah, an FPGA would greatly simplify making some of the logic stuff. You may only need a CPLD, depending on how complex the logic gets. CPLDs are nice because they typically have internal flash so they don't have to be externally loaded when they're powered up--many (most?) FPGAs need another flash chip attached. I do have a Lattice FPGA that doesn't need flash, but most others do from my understanding.

Also keep in mind you'll have to find 5V parts or do level shifting. Just like my RAM struggles, hopefully it isn't too hard to find 5V FPGAs or CPLDs or whatever...edit: looks like 5V CPLDs are still plentiful.

 

[olePigeon]

Since I'm dreaming, would it be possible to eventually make a cost-effective USB card with this? (>$50)

 

[dougg3]

I honestly think the answer to that is "yes". Take an FPGA/CPLD, create some registers inside it that the Mac talks to over the PDS, then hook the CPLD/FPGA to a microcontroller with USB host capability. The microcontroller would talk to the CPLD/FPGA, do the USB work, and return data. Then get bbraun to write software for it. it would probably be slow, but it could be done that way (I think). Might take bus mastering capability to get faster speeds...

With the approach I'm thinking of, you'd have to target specific functionality--like storage or mouse or keyboard--rather than a generic USB stack on the Mac. I think the USB stack could be done too, but it would take a lot more effort...

Just my 2 cents!

 

[bbraun]

I don't know anything about pricing, but as for functionality, anything is possible with sufficient time and resources right?

The steps I'm thinking of go something like this:

1) get what I have onto a PCB. I've not done any of this before, and figuring out PCB software is turning into a more challenging task than getting this working in the first place!

2) refine the bus interaction. I'd like to address the /STERM & /DSACK timing concerns, and I'd like to get the address decoding a little more refined. Specifically, only enabling the ROMs when addressing the end of the address space, and a bonus would be making the super slot space work too. This could be done with more discrete logic, CPLD, FPGA, etc.

3) investigate adding something more complex, like USB controller or similar. My thought process on this seems similar to dougg3's. At least initially, I'd plan on a general approach of the peripheral being "smart" and providing a "dumb" interface to the host processor. For instance, if we had a microprocessor with USB host or OTG support, have the microprocessor handle all the USB details, and for a USB disk just present a simple linear array of bytes to the Mac. Then the driver software is simple, and potentially much faster than having the host CPU execute a complex software stack.

4) explore the host processor side possibilities. We'll all have a much better idea on what is/isn't feasible as things take shape.

Anyway, baby steps. A week ago I didn't know what /STERM, /DSACK, or these tristate buffers were.

 

[techknight]

There off the shelf chips/MCUs with the entire USB architecture built in. Stack and all..

You would need a driver that enables the card to talk to the macintosh, and you need a secondary driver that enables USB Mass Storage, so once the USB device is put in, the driver of the card knows how to handle it.

I can handle PCB/CAD software. hehe. Footprints are a royal pain in the ass though.

Babysteps USB wise, would be start simpler. Use Serial, Slow Yes.... BUT...

if you can get an MCU that handles USB/USB Mass Storage and can interface the MCU through the serial port, you can write software/drivers to handle it. That will at least make sure you learned the USB MCU your using, and got all the software working.

Best thing would be to somehow patch the USB Mass Storage into the SCSI manager so formatting software like LIDO would see and format it. Otherwise youll have to write your own utility, and a driver that allows it to mount in finder.

I can/have made a simple app and an AVR that reads an SD card, prints its contents in the app, and gives me 512bytes in which sector/LBA that i request. The problem lies in the ability to take that, and make it into a driver that allows finder to use it. Something that I cannot do.

Which begs the question, How do you write a storage driver for macintosh?

 

[bbraun]

I've got what I think is the connector, the chips and the connections all into Osmond. I'm not sure I've got the orientation of the board correct. As in, the chips on the right side of the board when the card is installed into a machine.

Anyway, my files are all here. The 030Card.osm file is the project file and should be all that's needed. The others define parts, list of parts, and connections. Osmond is a free download, and works on OSX, so if anyone wants to take a look, feedback is appreciated.

U1-U4 are 29F040's

U5 is 7404

U6 and U7 are 7408's

U8 is 74125

I can/have made a simple app and an AVR that reads an SD card, prints its contents in the app, and gives me 512bytes in which sector/LBA that i request. The problem lies in the ability to take that, and make it into a driver that allows finder to use it. Something that I cannot do.

Hook me up! I'll take a stab at it. Or if you'd like to do it yourself, the ROMDisk driver should be a fairly simple C based example using CodeWarrior 10. It's really just a lot of glue that boils down to a memory copy. The complications usually come in when the memory copy becomes something more complicated, like calling another driver, or something along those lines. I'd be glad to help out in any way.

I haven't figured out how (or if it's reasonable) to make something appear to the SCSIMgr. Everything I've done is more along the lines of the floppy & EDisk driver, that just present a "drive" to the OS, which is a linear array of 512byte blocks. When the "drive" structure is given to the OS, your driver is associated with it and the Prime routine will be called whenever a read or write operation is performed. The drive will show up in the Finder when a diskEvt event is posted using PostEvent. If the disk needs formatting, you'll get the "Uninitialized disk has been inserted, do you want to eject or initialize" dialog.

Icon retrieval and information about the size of the disk, whether it can be ejected, is read-only, etc. is handled by the driver's Control call.

 

[tt]

The 030Card.osm file is the project file and should be all that's needed.

I opened it in Osmond, but I just see the components laid-out, how do I get the traces to appear? (I tried importing the netlist.)

 

[bbraun]

Well, that's the part I'm still trying to figure out. I haven't routed anything manually yet. AFAICT, Connect tool (the two arrows pointing at each other), and if you click on a pin, it will show the pin you clicked on in blue (if there's a connection defined), and all the other things it connects to in pink. If you option-click on a pin, it'll show a suggested trace, and then you use the other tools (to the right of the scissors) to move the trace around.

I'm still playing around with that part.

 

[dougg3]

Interfacing to a USB mass storage device in a microcontroller supporting USB is really really simple, especially if you use a library like LUFA. In fact, the same chip I use on the SIMM programmer would be capable of it (except it would need to be the AT90USB647 rather than the 646 though, because the 646 only supports being a device). Another advantage of going the AVR route is the AVR can run at 5V. LUFA comes with tons of sample code demonstrating how to do it. It's the same library I've been using for the SIMM programmer.

Not pushing for any choice in particular, but I'm just saying that I agree with techknight -- it's way easy to do with a microcontroller that has USB built in. Making sample code to return 512-byte blocks from a USB drive would be a cinch.

 

[Trash80toHP_Mini]

p.40 already gang! :approve:

What are the response time differences between an SD Card, your typical Thumb Drive and SDRAM?

If we're going to lay storage out as memory acreage to parcel out for the CPU, why not use a relatively inexpensive SDRAM module as a battery backed Silicon Disk?

Heck, with Compact Virtual and the Killy Klip 68000 PDS hack we could be looking at a LOT of Virtual Memory and a hard disk replacement in an beige box compact Mac.

It'd be way cool in my IIsi and IIfx as well! }