Making A Bootable ROM Drive For The Classic II

[Paralel]

Ok, assuming the silicon is good, and it should be, the only thing preventing a Classic II ROM drive from being a reality is that one doesn't exist, at the moment.

I'm determined to rectify that by creating one, but the only things I know about ROMs is how to make a copy of them from a Mac, and how to load them into an emulator...

From what I've gathered, based on the work for the DougG3 ROM project:

An image that fits in the ROM should be created with dd

It should be filled with whatever one wants to put in it

It should be combined with the base ROM for the Classic II using cat

The header for image should be altered so the EDisk Driver in the Classic II's ROM will load the ROM Drive

It has to be determined if there is a set of keystrokes in the Classic II ROM to mount the ROM drive (such as in the Mac Classic) or to add that to the ROM so it can be booted.

(Alternatively, for the last two steps, if the EDisk Driver can't be used, I will need to switch to using BBraun's ROM Disk Driver)

Anyone that want to provide any assistance or feedback during this project is welcome as it will surely speed-up how things progress.

 

[Paralel]

The base ROM configuration in the Classic II is the main ROM spread over 4 128k chips (in version 1). Can that all be put on a single 512k ROM in the 1st ROM slot and the other chips filled with other stuff, or is that not how ROM is read from the logic board?

 

[Paralel]

If I can put the base ROM entirely in the first slot, I won't need to cat anything. I can just load the ROM Drive into the rest of the slots without messing with the base ROM at all.

 

[Paralel]

Ok, looks like EDisk Driver is a non-starter, it only allow 24-bit addressing. That's no good for what I had in mind.

I'll have to talk to BBraun about adapting his ROM Driver into the Classic II's ROM in order to run the system in 32-bit addressing mode.

 

[Schmoburger]

I have nothing useful to contribute to this thread at this point, however it interests me sufficiently to follow it.

 

[gsteemso]

What is all this "in the first ROM slot" talk? The four chips on the C2 motherboard are each 8 bits wide, and the CPU reads 32 bits at a time. The four chips collectively act as one wider blob of memory in the system. Put another way, under 24-bit addressing (…for example, and simply because I don't quite recall the actual address values from 32-bit mode), the bytes at addresses $400000 and $400004 occupy the first two locations in the first physical ROM chip, those at $400001 and $400005 occupy the first two locations in the second ROM chip, and so on. It was done this way because a single 128K x 32 ROM chip in that time period would have had to be a DIP IC and would have required at least 51 pins (15 address, 32 data, power, ground, clock, enable). As far as I know, the only standard IC package of the day that could have met those requirements would have been a 64-pinner, as otherwise used only for very expensive applications such as CPUs. (If memory serves, the original 68000 was available in a DIP-64.) Such a ROM part would have required about 4 times as much board space per chip and would have also been way more expensive just for the parts themselves—probably by at least an order of magnitude, considering that it would have had to be a custom part.

 

[Paralel]

I want to swap out all the motherboard chips for 512k X 8, to make 2MB total, for the 2/2 config that the logic board supports. Given that the entire ROM would fit in a single 512k x 8 chips. I was thinking of just putting the 512k base ROM that exists in the system in the first 512k x 8 chip and using the other 3 512kx8 as part of the ROM drive.

That's why I was wondering above if in the 2/2 config it would read the contents of the ROM chips sequentially  Chip 1 first, Chip 2 next, etc.... as its loading the ROMS or if it stripes them in order to fill up the 32-bits the CPU wants to reads, thus reading a section of each chip during each cycle. If that's the case, it will make things much, much more complicated because that means the base ROM and the ROM drive will have to be appropriately striped across the logic board ROMS to be read correctly.

 

[Paralel]

The only way multiple access to the chips will work without striping is that if it takes 8 bits from each chip but puts them in a designated spot for that ROM, like filling up a container. If it does that, we're still fine putting the entire content of the base ROM in the first slot, because its just a faster way of reading the ROMs instead of doing it sequentially.

 

[gsteemso]

So, basically, you didn’t bother to read my post. I shall be sure to use shorter paragraphs in future.

Access to the motherboard ROMs is, as you put it, “striped.” There is no “first slot.” For details, see my previous post.

 

[Elfen]

How is this for a test? The Classic/Classic II has an Interrupt switch that goes into a machine language monitor. In theory you can type "G [ROM Address in Hexidecimal]" and it should run what program is there. So in theory, you can get the Classic II to a flashing Disk icon, press the interrupt and have it "G [Expanded ROM Address]" and see if it boot loader runs from there.

 

[techknight]

umm. no. press NMI without an OS loaded, you get a sadmac. 

Thats macintosh 101. 

Your posts worry me sometimes... 

 

[Elfen]

Your posts worry me sometimes... 

Good to know that I'm doing something right!

Sometimes to get an answer, one has to ask the stupidest questions or make the craziest of comments.

 

[Paralel]

So, basically, you didn’t bother to read my post. I shall be sure to use shorter paragraphs in future...

I did read your post, I just missed what you were trying to convey. Why don't you try being a little less condescending. If not, please don't bother to contribute in this thread further, as this type of attitude is unwelcome and unproductive, to say the least. You of course, may continue to do so, I cannot stop you, but I can guarantee my next response won't be quite as measured.

 

[gsteemso]

Parallel, you are quite correct, my reply was unwarrantedly snide and completely unconstructive. I am very sorry.

When I read your post to which that was a reply, my immediate reaction was pretty much “WTF, I just answered that, why did I go to all that effort?”, followed by “I did kind of get sidetracked in the second half of my post, I should have put it in its own paragraph to avoid obfuscating the important part.” (In reality, now that I reread that initial post of mine, I should have left the second part out entirely; it wastes a great deal of verbiage arguing against something no one was advocating in the first place.)

Now, you would think that after 20 years online I should know better than to post in haste, and you would be right—I should have known better. You have never been anything but helpful and polite on this forum, and my firing off a reply while still grumpy was pretty much guaranteed to produce a counterproductively rude message. Again, I am very sorry. I have no excuse.

 

[gsteemso]

Getting back to the technical questions, while the individual chips can’t really be edited as self-contained packages because any sequential set of at least four ROM locations will be located across all four chips in round-robin fashion, in practice that’s at least a little bit less inconvenient than it sounds. While any change to more than one sequential location requires re-burning at least two of the chips, people have been putting up with that issue for as long as they have been building computers with wider main busses than memories. There are simple tools that will automatically split your desired final ROM image into its four component streams to feed one at a time to a chip burner, and as long as you label the physical chips with 0 1 2 3 or the like to keep them straight, it’s not as much of a nuisance as you might expect.

All of this IS a very strong argument against employing single-use PROMs in your design, of course, at least until you finish making changes to the custom ROM image. Having to buy entire new chips four at a time instead of individually would cost a fortune. Thank goodness those things are verging on obsolete, and thus are impractically uneconomical in the first place!

 

[Elfen]

umm. no. press NMI without an OS loaded, you get a sadmac. 

Hmmmm.... What about a modified boot strap where a tiny program from the floppy or hard drive is booted and then the loaded program jumps to the ROM and the ROM takes over from there?

I've seen some system do this somewhere but forget where I seen this at. If anything it should(/could?) be for at least a testing phase of the ROMs.

 

[Paralel]

Gsteemso, no harm, no foul. Your technical insights regarding this topic are very helpful and your contributions are appreciated.

With the base ROM being spread across all 4 chips will make this more difficult than I thought. This is either going to take me much longer to figure out, or I'm going to need much more help in figuring it out.

I have a set of 4 4-Mbit EPROMs sitting right next to me, I'm just waiting for my EPROM programmer to show up.

Can you suggest any of those utilities that will be able to make the split ROM component streams like you mentioned? I only know how to dump the ROM from the Classic II as one big 512 KB ROM file.

The first trick is just going to be getting the base ROM spread across the 4 4-MBit ROMs correctly, then work on the actual ROM drive proper can start.

I guess some insight can be gleaned from the REV2 Classic II LB design, since it uses 2 16-bit wide ROMs rather than 4 8-bit ROMs.

Until the base ROM can be installed and working with the 4-MBit ROMs, it won't even be possible to test the proto-silicon of the hardware design regarding the add-in ROM. This will allow for the utilities I have to test the entire 16-Mbit space and ensure that the hardware has no errata that are necessary (I have total faith in the design, and its been reviewed by more than one person multiple times to ensure it is correct, but as we've seen, it is possible for small issues to sneak through unnoticed even in big companies)

 

[gsteemso]

I have to admit, while I can say with 100% certainty that such utilities are commonplace in certain circles, I have never actually needed to use one and do not know what to recommend. On top of that, as far as I know most of the sort of developers who would need such a thing use Wintel machines or some flavour of UNIX to do it on, so I do not know whether such a utility that would run on the Classic II itself is still to be had. Happily, OS X includes such a utility out of the box as part of the standard UNIX environment; I just can’t remember what it was called. If you flip through a few likely man pages you should be able to find one. I would start with the pages for dd and tar. Pay special attention to the SEE ALSO section if neither of those is it—I’m pretty sure I ran across it by following a chain of “see also”s.

 

[Paralel]

Sounds good. Fortunately, I have a 10.8 machine just sitting around collecting dust.