Jump to content

Making A Bootable ROM Drive For The Classic II


Recommended Posts

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.

Link to post
Share on other sites

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?

Edited by Paralel
Link to post
Share on other sites

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.

Edited by Paralel
Link to post
Share on other sites

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.

Edited by gsteemso
Link to post
Share on other sites

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.

Edited by Paralel
Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Edited by Paralel
Link to post
Share on other sites

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.

Link to post
Share on other sites

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!

Link to post
Share on other sites

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.

Link to post
Share on other sites

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)

Edited by Paralel
Link to post
Share on other sites

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.

Link to post
Share on other sites

The way I would actually do it is just to write a quick little program or script or something. All it needs to do is take the input file, set up an array of four output files, and then loop with three simple operations until you hit the end of the input file, as follows:

 

set the output file counter to the first one

REPEAT

read one byte from input

write it to the current output file

bump the counter to the next output file (wrap to the first if necessary)

UNTIL end of input file is reached

 

See? Not a complicated problem. If you are certain of your system’s byte order, you can improve this by reading a 32-bit word at a time from the input file and writing the appropriate 8-bit piece of it to each of the four output files. Don’t need the output file counter that way.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...