[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ideas for //c (rom 0) mods

BLuRry wrote:

On Aug 7, 4:36 am, "Michael J. Mahon" <mjma...@aol.com> wrote:



I just recently went through security twice (in Seattle and Wichita)
with a 17-board AppleCrate, packed in nested cardboard boxes with
Masonite panels in between.


You're much braver than I.  I would have overnighted it.  I do not
trust baggage handlers or **gasp** other travelers who try to maximize
overhead bin space by smashing everything in their way.


I don't trust *any* freight handlers--I've seen them work!

And it was about 1" too big to fit in an overhead bin--I had to persuade
a flight attendant to let me stow it in the closet on four flights.  ;-)


-Which begs the question, are there any micro-controllers that emulate
floppies like SVD did?  Another totally kooky idea is something that
has the timing to emulate the boot 0 phase to push 256 bytes of loader
code into ram and execute a much cooler program that is less timing-
dependent and reuses the floppy signals to stream data in a way that
doesn't need to mimic physical media in favor of a larger storage
scheme based on IDE-style flash.  I think the only real barrier might
be the //c woz machine part.  Any way to bypass and go straight for
the raw signals?

Sure, you can transfer data just like a smartport device.

And the boot code can be any length that doesn't require a seek--
which is not a problem if you're *emulating* a disk...


But the boot 0 is controlled by the woz machine and hence the //c rom,
right?  So is this possible without reprogramming the onboard rom?


Yes, the ROM boot code will load as many sectors as you wish (with
the obvious limits of RAM size)--it just won't "seek" to another
"track".  ProDOS, for example, loads two sectors at boot time.


-Pie in sky idea: Microdrive with a flash card that mounts in the
floppy drive opening.  Is there any way to tap the //c bus on a rom-0
board to create a virtual "slot"?  I seem to remember that the //c had
its own rom that more or less occupied the bank-switch rom reserved
for physical cards in other ]['s, which leads me to believe that no
bankswitching == no support for card rom == no possibility to hack a
slot.  Which is a bummer, but understandable.

There should be pretty easy workarounds for ROM, since you will be
changing it in any case.  All the signals needed for a slot are there
or can be synthesized, so that should be possible.


Right, so you're saying this is doable if I pop the rom out and
reroute the traces accordingly.  Basically, making my own bankswitch
-- but where is it best to do this?  Hijack the processor or the rom
slot?  I'm certainly not opposed to re-learning what little I knew
about TTL logic! :-)


No trace rerouting, just a new ROM.  And you'll have to add some
logic to decode the "slot" signals that aren't provided by the IOU.

The only thing you need to avoid is hijacking a phantom slot that is
needed for compatibility.

-michael

AppleCrate: An Apple II "blade server"!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."