Mac plus ROM in a 512k question

[techknight]

I have a question. and i am probably confusing myself by thinking this.

the mac plus ROM is 128K correct?

Well i am looking at early mac schematics posted elseware, its only addressed up to A16 then skips to A20 so its in the 400000 address space.

Problem is, A16 can only address up to 64K. so how can you drop 128K roms in there without needing A17?

another point to ponder, if you dumped the 64K ROM out of a macintosh, how is it not 128kbytes?

because i noticed both ROMs are in parallel. only difference being, its each ROM serves 1 byte of a full word. so it would be 64K Words, and 128K bytes on an early 512k mac, right? or am i confusing myself here.

 

[H3NRY]

To start with, A0 selects the low or high byte ROM for 8-bit read, then A1 - A16 select the individual byte in each ROM out of 65536 possibilities or 64K, so 2 x 64K = 128K bytes of address space. The original ROMs hold 32K bytes each, and they occupy half the address space. If you dump the whole 128K ROM space with "64K ROM", you get 2 images of the ROM, one in the lower half, one in the upper half of the address range. The 68000 normally reads 16 bits at a time, reading a byte from each chip simultaneously. For this reason you want to be sure your code & data sits on even byte boundaries.

Is that any clearer? Original "64K" ROM = 2 x 32K byte (AKA 256K bit) chips = 32K words of 16 bits. Plus ROM = 2 x 64K byte (512K bit) chips.

 

[techknight]

Yea i was making it harder than what it really was. the ROM is 64kilobytes total, 32K in each chip. but each chip is on a 64K addressing system, so in theory it can address up to 128K or 64kilowords.

P.S. on the PDF schematics of the early mac i found elsewhere in this forum, i dont see an A0 anywhere.

 

[H3NRY]

A0 is called UDS (Upper Data Select) and LDS (Lower Data Select) at the 68000 chip. That way, it can read either byte singly or both together. You're right, A0 as such doesn't usually appear naked on CPUs beyond 8-bits. By extension, 32-bit 68020s read 4 bytes at a time, so A0 and A1 are somewhat hidden.

 

[techknight]

yea. well the reason i am asking questions like this, because in my spare time, i have a 512k system here, i was going to start modding it. keep it strictly for a mod machine.

my goal is to make a SCSI system like they did back then with 128K ROM. but i am going to code an Atmega128 to emulate the 5380 SCSI controller and the SCSI drive interface, so i could use a USB flash drive, or SD memory, or for simpler reasons, ATA CF card. or basically like a SCSI --> USB mass storage

Heck i could even do an ATmega256 and put the ROM in the flash with everything else to minimize chip count down to a mere 1. so everything is all on 1 chip. problem with that though is the number of pins to address full ROM to the 68K CPU. but i doubt it'll be an issue. Also need to figure out the timing diagram to the original apple ROMs so i can emulate that, basically figure out when a valid address is given when it should return valid data and upon what state the CS/OE is in. and probably put the CS/MAD logic in the CPU code itself as a state machine, so it knows when its talking with ROM area or SCSI area. run the controller at a full 16mhz should be plenty fast enough for everything to happen. nice thing with the 5XXXXX area being open, i can do lots more than just SCSI, but my issue is drivers. not a very good driver writer, still need to learn the architecture of MacOS and how its drivers are implemented, etc etc. probably have to read the inside macintosh manuals from the time.

 

[H3NRY]

so i could use a USB flash drive, or SD memory

Now you're talkin! I've been thinking the same thing. Just don't have time to take on a project like that.

 

[techknight]

yea my time is limited as well, but its something im going to work on a little bit at a time. i was reading that alot of older software wasnt compatible with 128K roms, so i might end up learning how to make drivers and use the 64K rom with a system enabler or a DRVR entry into the resource on the system suitcase to load up the hardware. Everything is covered in this "inside macintosh" PDF that i am reading.

 

[Gorgonops]

i was reading that alot of older software wasnt compatible with 128K roms

Out of curiosity, do you have a reference for that? There seems to be a lot of confusion regarding that "incompatibility". The Macintosh Plus is generally considered "completely" compatible with the original Macintosh to the extent that it's capable of running all the original applications and operating system versions when booted from the appropriate disks. There *is* a small body of software that's incompatible with the System software versions introduced with the HD-20 and Macintosh Plus (IE, the ones with hard disk and HFS support), but that's not the same thing as being incompatible with the 128K /ROMS/. If you pretended you just had a floppies and booted from a disk said software *would* work with a Plus. Does anyone know a true counterexample? (There may be something that chokes on the slightly different way the Plus indicates how much free RAM it has, but I haven't heard of it.)

It guess it *is* true that the drivers for some of the previous third-party efforts (Hyperdrive, et al) that used MFS and oddball partitioning schemes with older System versions *did* work with some of those troublesome programs to get them to run off mass storage. In principle you could write a similar driver to run the Plus' SCSI subsystem the same way, I guess, but you'd really have to *love* one of those programs.

Coincidentally, here's a rambling thread over on Applefritter where the issue of drivers for third-party mass storage systems was uselessly debated. I made the gruesome suggestion over there that one thing that *might* be worth investigating is hacking the ".sony" driver the same way as is done in the BasiliskII and Vmac emulators. Said driver in these emulators replaces the low-level IWM driver in the Mac's ROM with a driver that transparently handles arbitrarily-sized disk images. (Meaning that you can map a "hard disk-sized" filesystem into the Mac OS without worrying about emulating SCSI controller hardware.) It seems to me that it would be relatively trivial to convert this concept to hardware by putting a piggyback board into the ROM sockets which contained a small block of SRAM to replace the ROMs and a microcontroller to handle a flash storage. On powerup the piggyback board would load the SRAM with a copy of the Mac ROM (64k or 128k, wouldn't matter, you could easily switch between them for that matter) patched with a new .sony driver which pointed at the microcontroller, write protect it, and then allowed the Mac to boot off the disk image of your choice.

(You could write a small Mac application to present an interface for switching between images on the memory card at runtime, with an initial config file written to the card from the host computer used to generate the images. Many microcontrollers have FAT/VFAT filesystem parsers available in their example code libraries so it should be easy to handle the disk images.)

Without some creative noodling you'd lose the floppy drive controller when running a modded ROM, but it seems like a fairly small price to pay. The only software which would get broken by doing something like this is anything that reads a disk by bitbanging directly on the floppy controller... the same sort of software that would be broken by running it in an emulator, but the Apple disk controller was so deviously complicated and software dependent I'd hope that would be a smaller category than software broken by HFS.

 

[H3NRY]

Other than drivers for early hard disks like the HyperDrive or Corvus which used their own schemes for partitioning, like "drawers", there wasn't much that didn't work. I can't remember anything else that broke. I retired my 1-year old $2000 10MB Corvus in favor of a SCSI MICAHDrive which was 20 times as fast. General Computer issued HFS-compatible software, as I recall.

HFS very cleverly kept almost complete compatibility with MFS by making a folder (subdirectory) look exactly like the structure of an MFS disk. Apps like my MacMovies written to "bare metal" in assembler work in the Plus like champs. Toolbox calls were the same, though new ones were added in the 128K ROM. The very earliest demos like Pepsi Caps and the early version of Alice that doesn't support the Finder run on a Plus the same as they do on a 64K ROM. There may be incompatibilities, but I don't know of any. There certainly wasn't "alot".

 

[JDW]

On the topic of software "compatibility," I am curious if it has more to do with copy protection and the differences between floppy drive mechanisms than it does with 64k vs 128k ROMs. For truly, some copy protected floppies would only work properly when used in the internal 400k drive -- they wouldn't work right in an external 400k drive. I think SmoothTalker 1.0 was like that. That implies such copy protected 400k floppies may not work well or at all in an 800k drive.

 

[H3NRY]

Now there you have a point. There was a lot of copy protection on the early Mac, and some of those fiddled around with the disk speed, which you could do on a 400K drive, but NOT on an 800K. It wasn't the ROMs that were incompatible, it was other hardware. Some devices depended on power from the 9-pin serial ports, which was not available from the 8-pin DIN port. There was so much bad copy protection which broke the software with every OS release, every new piece of hardware, etc. that users quit buying anything that smelled of protection. Developers got really sick of all the tech support, too. This applied in spades to games, and I keep forgetting that there are a lot of people on this forum whose only interest is old games.

The really remarkable thing is that most of Microsoft's Mac software retained compatibility, even though MS didn't use the documented APIs. They thought they were so much smarter than Apple's programmers that they wrote their own code to replace most of the toolbox. This did result in such ugly messes as Excel needing to run in the bottom 1 MB of memory, so when Excel launches under MultiFinder, Mac OS quits all other apps, saves their states, opens Excel, then re-launches the other apps and restores their states. Excel was important enough that Steve couldn't just ban it from the system as he's done with Flash on the iPhone.

 

[techknight]

well ive never ran into one instance of software incompatibility except between 68k/powerpc, but thats a big duh on that part. hehe.

it might have been mac128k or bunsen that may have mentioned software compatibility issues between plus and older macs. but dont quote me on that, i just remember reading a couple threads here where that was mentioned. but otherwise, im going to use plus ROM flashed into a custom board of mine for SCSI. of course it isnt "legal" to do this, but what do i care? just a hobby ya know.

 

[Mac128]

There was also the MFS/HFS thing. I know some software would not run under HFS, but could be remedied by running an MFS system, and/or keeping all files at root level. However there were a few apps that would not run even under that configuration on a 128K ROM. Fortran comes to mind. Dollars and Sense, Q&D Filer, 1st Base, MacDraft, MacDraw, Guided Tour, and MacServe also had incompatibilities. I've also read that a number of games required Fedit to change the screen address in order to work properly on a Mac Plus. The bigger problem I have personally run into is software that did not know how to deal with more than 128K or 512K RAM. But that's another issue altogether.

 

[techknight]

And that also brings up another thing. i could make a small little lightweight app you could run that would set the hardware to boot from the 64k rom or 128k rom.

because if i use an ATmega256, i could fit both ROMs in just the flash area. and use a control byte written into its eeprom to decide which one to boot from. simple enough, i would just have to give that control byte its own address space on the macintosh buss. just write a $01 or a $02 into that address space will determine which ROM to boot from.

 

[trag]

my goal is to make a SCSI system like they did back then with 128K ROM. but i am going to code an Atmega128 to emulate the 5380 SCSI controller and the SCSI drive interface, so i could use a USB flash drive, or SD memory, or for simpler reasons, ATA CF card. or basically like a SCSI --> USB mass storage
Heck i could even do an ATmega256 and put the ROM in the flash with everything else to minimize chip count down to a mere 1. so everything is all on 1 chip. problem with that though is the number of pins to address full ROM to the 68K CPU.

That is a very cool idea.

Regarding the pin problem, if you are willing to add one more chip you can mostly eliminate your pin problem, I think. It might require a few more components...

Generally, these interfaces have an address bus and a data bus. If you're going parallel to parallel, as you are when going CPU to SCSI, the data doesn't really change. So, if you're a little creative, you can just tie the address and control lines to your microcontroller and use it to control where the data lines go by changing the state of multiplexers and/or bus switches. You may need to latch the data however, which is another component, unless you can find it combined with the multiplexer or bus switch, which you might, because TI makes a logic chip for just about every function a person could imagine....

So the address/control lines and the microcontroller do all the "thinking" about where the data should go, but the data doesn't pass through the microcontroller, it is routed to the appropriate destination by the microcontroller.

Now, if your plan is to use a microcontroller with a built-in USB bus, for example, this idea does not work so well, since the data probably needs to go into the microcontroller in order to come out of the microcontroller's USB pins. But for many interface translations, this microcontroller as traffic cop idea is applicable.

So in the above (ROM, not mass storage) case, the one chip you would add would be a Flash or EEPROM. Something with 4 Mb or even 8 Mb is cheap these days. Then you just use the microcontroller to translate the address the Mac is supplying to whatever address you want to actually access on the EEPROM.

And that also brings up another thing. i could make a small little lightweight app you could run that would set the hardware to boot from the 64k rom or 128k rom.
because if i use an ATmega256, i could fit both ROMs in just the flash area. and use a control byte written into its eeprom to decide which one to boot from. simple enough, i would just have to give that control byte its own address space on the macintosh buss. just write a $01 or a $02 into that address space will determine which ROM to boot from.

Why not use an address in PRAM? I bet there's an unused one you could hijack. Then you'd just need a way for the ATmega256 to read the PRAM contents at boot up without interference from the 68000. I think there's a pin that will hold the 68000 inactive while the ATmega256 sneaks around behind its back.

Of course, if you follow this road to its conclusion, you'll figure out how to emulate the whole Mac in hardware, and simply build a replacement for all the slow hardware sitting in a microcontroller. But one thing at a time.

You might also want to take a look at the MCF522xx cold fire chips. The demo and development boards cost a bit ($99 & $300 respectively) but individually, the raw chips are cheap and the controllers are very capable.

 

[techknight]

I was working on an infocus projector unit that used coldfire microprocessors. but ill save that for another day another topic another forum. hehe.

As far as the idea i had, i was going to use the internal flash of the ATmega to hold the ROM images instead of an external chip, that way i can use less chips as possible. probably use a simple mainloop subroutine that looks at the address, does some simple address math and fetches the databyte on a read call. then the ports are switched on and outputted on the ports during an OE=true request. and anytime the OE is false, i tri-state the port outputs of the AVR into a high-Z state, probably not necessary but ill do it anyway. if i ran the atmega at 18 or 20mhz, it wouldnt really be a bottleneck for address/data fetches as the macintosh is running a mere 8mhz.