A new pseudo-disk for Apple 2.

[Alex Freed]

I have finished a prototype of a new mass storage device for Apple 2 that
uses MultyMedia Cards.
So what, you'll ask. There is already a CF interface.

Yes and no. My toy has a small AVR microcontroller on board and 2 modes of
operation.
The trivial mode simply interfaces the MMC to Apple as yet another ProDOS
storage device.
The fun starts with the "smart" operating mode. The device looks to Apple as
a Disk ][ controller.
So Apple happily reads nibble images as if they were real 5 1/4" floppies.
This allows using
images of DOS 3.3 disks or any other .nib images. For example a couple of
games that do not
use DOS work fine.

The software is not quite finished: I need to add an application that will
run on Apple
and select one of many .nib images to use. My prototype just uses a single
image, but that is
not very difficult.

The firmware can use a lot of improvements too. Currently I feed Apple a new
byte every time
it asks for one instead of changing it every 32 msec. Seems to work for
quite a few images, but
won't work with many protection schemes.

The big question is is there any interest in this device? If there is, I can
make a small production
run and offer for say $100. If not, I'll be the only owner of the only
prototype.

The board has an AVR micro and a CPLD for fast interfacing. Originaly I
though that an AVR
running at 16 MHz is fast enough to do everything in software, but it is
not. In addition the
CPLD acts as a perfect 5v to 3.3v converter - MMC uses 3.3 V. I can add an
EPROM
to make this card bootable. Currently I boot from a real disk and DOS can
see the other
"disk" in another slot.

The MMC card can have up to 4 partitions. Some partitions up to 32 MB can be
seen
as ProDOS volumes and one can have any number of .NIB images.
Future driver will be able to see 2 images at once as drives 1 and 2.

[BLuRry]

Post by Alex Freed
The software is not quite finished: I need to add an application that will
run on Apple
and select one of many .nib images to use. My prototype just uses a single
image, but that is
not very difficult.

The only limitation of this is that games^H^H^H^H^H programs that
require flipping the disk over will not give you much oppertunity to
drop down to this apple application to select a new image. Could it be
possible to have the application set up a queue queue of, say, 16
images that you can toggle between with a physical button? (I say 16
because it is a multiple of two higher than ten, and Ultima 5 is on 5
2-sided floppies hence 10 floppy images) For fun (and for cheap) throw
on a numeric LED or just a series of 4 leds to state which image # is
active.

-B

[Alex Freed]

Post by BLuRry
Could it be
possible to have the application set up a queue queue of, say, 16
images that you can toggle between with a physical button? (I say 16
because it is a multiple of two higher than ten, and Ultima 5 is on 5
2-sided floppies hence 10 floppy images) For fun (and for cheap) throw
on a numeric LED or just a series of 4 leds to state which image # is
active.

Good point. The only problem is the physical construction - where to locate
the buttons and
the display?
If right on the board then a trivial solution will be to put a DIP switch
that can select one of
256 images.

-Alex.

[johnsonlam]

Hi Alex,

Post by Alex Freed
The big question is is there any interest in this device? If there is, I can
make a small production run and offer for say $100. If not, I'll be the only owner of the only prototype.

Yes, I'm interested!
Any photos?

Thanks for the news!


Rgds,
Johnson.

[BluPhoenyx]

This sounds like a very interesting project and I am interested in the
finished model.

Cheers,
Mike T.

[SbM]

Post by Alex Freed
The big question is is there any interest in this device? If there is, I can
make a small production
run and offer for say $100. If not, I'll be the only owner of the only
prototype.

I don't know much about electronics, and the only question I have about
this kind of device, is : how come your device and Rick's CFFA cost
about $100, when the MMC64 for Commodore 64 is readily available for
EUR49 (incl. shipping) and the 1541-III is scheduled for released in
september at an announced EUR50.

Could you please explain why Apple II devices cost twice as much as
Commodore devices ? Are they more complicated to design ?

(Please note this is no troll, only a candid question from a
technically-challenged Applemaniac ;-)

[BLuRry]

Post by SbM

Post by Alex Freed
The big question is is there any interest in this device? If there is, I can
make a small production
run and offer for say $100. If not, I'll be the only owner of the only
prototype.

I don't know much about electronics, and the only question I have about
this kind of device, is : how come your device and Rick's CFFA cost
about $100, when the MMC64 for Commodore 64 is readily available for
EUR49 (incl. shipping) and the 1541-III is scheduled for released in
september at an announced EUR50.

I'm not much of an expert in electronics, but these sorts of prices
aren't too unusual. This is very specialty hardware and in relatively
low demand and rare. Look up "catweasel mk4" on eBay, for example.
(it's a apple/c64/amiga disk drive controller + sid chip soundcard for
a pc -- CRAZY custom hardware in that thing)

You can only lower cost if you go into full mass-production. I'd
imagine that you'd have to order the parts by more than a few hundred
to get significantly reduced prices (even if the lower prices are not
listed, you can negotiate for lower if you're placing a huge order.)
Convert some of those crazy C64 users to be rapid apple // lunatics and
maybe we'll get cheaper parts. :-D Plus, using a FPGA increases the
cost but is upgradable, which is very nice.

-B

[a***@netscape.net]

Post by BLuRry

Post by SbM

Post by Alex Freed
The big question is is there any interest in this device? If there is, I can
make a small production
run and offer for say $100. If not, I'll be the only owner of the only
prototype.

I don't know much about electronics, and the only question I have about
this kind of device, is : how come your device and Rick's CFFA cost
about $100, when the MMC64 for Commodore 64 is readily available for
EUR49 (incl. shipping) and the 1541-III is scheduled for released in
september at an announced EUR50.

I'm not much of an expert in electronics, but these sorts of prices
aren't too unusual. This is very specialty hardware and in relatively
low demand and rare. Look up "catweasel mk4" on eBay, for example.
(it's a apple/c64/amiga disk drive controller + sid chip soundcard for
a pc -- CRAZY custom hardware in that thing)
You can only lower cost if you go into full mass-production. I'd
imagine that you'd have to order the parts by more than a few hundred
to get significantly reduced prices (even if the lower prices are not
listed, you can negotiate for lower if you're placing a huge order.)
Convert some of those crazy C64 users to be rapid apple // lunatics and
maybe we'll get cheaper parts. :-D Plus, using a FPGA increases the
cost but is upgradable, which is very nice.

We have a compact flash in the TI community, that the developer made
_without_ input from us (secretly) then started offering on eBay for
$40 for both the adapter board and the ide to flash adapter, with a
32mb compact flash. Now it comes with a parallel port as well for the
same price...

And we are a smaller community...

[h***@freenet.de]

Post by a***@netscape.net
We have a compact flash in the TI community, that the developer made
_without_ input from us (secretly) then started offering on eBay for
$40 for both the adapter board and the ide to flash adapter, with a
32mb compact flash. Now it comes with a parallel port as well for the
same price...
And we are a smaller community...

Maybe he's strong willed on not making money from it or maybe he
miscalculated. Maybe both, who knows?

And who says all hardware developers should work entirely for free and
on own risk?
Just because the platform is ancient?

bye
Marcus

[Alex Freed]

Post by h***@freenet.de
And who says all hardware developers should work entirely for free and
on own risk?

And one other though. AFAIK all the documentation on CFFA is available
on-line.
If someone feels he can make one cheaper than the asking price, there
doesn't seem to be
anything to stop him/her.

-Alex.

[h***@freenet.de]

Post by Alex Freed
And one other though. AFAIK all the documentation on CFFA is available
on-line.

It is. Right down to the ASIC programming stuff and the documented
firmware. IIRC Rich hasn't posted the newest revision, but he says (and
I don't doubt) that he will.

Post by Alex Freed
If someone feels he can make one cheaper than the asking price,
there doesn't seem to be anything to stop him/her.

In which case, Rich & company actually would've worked for free ;-)

bye
Marcus

[SbM]

Post by h***@freenet.de
And who says all hardware developers should work entirely for free and
on own risk?

Not me for sure. Please don't get too mad about this : I just asked a
naive question to try and understand the price difference. Alex needs to
gain something from his work, for sure. Sorry if some of you took it as
an insult : this was definitely not intended.

Now if only we could find a way to lower the price in such a way that
Alex could /still/ get the same amount of money from each board sold,
that would be great.

Maybe Alex could get in touch which the people who created the MMC64 and
the 1541-III for the Commodore 64, just so that he could ask them how
they manage to offer such a low price ?

[h***@freenet.de]

Post by SbM

Post by h***@freenet.de
And who says all hardware developers should work entirely for free and
on own risk?

Not me for sure. Please don't get too mad about this : I just asked a
naive question to try and understand the price difference. Alex needs to
gain something from his work, for sure. Sorry if some of you took it as
an insult : this was definitely not intended.

Hey, I'm not mad! Damnit!!! ;-)

No, please don't be too touchy - I wasn't meaning to flame.

Post by SbM
Now if only we could find a way to lower the price in such a way that
Alex could /still/ get the same amount of money from each board sold,
that would be great.

Nothing to say against that.

Post by SbM
Maybe Alex could get in touch which the people who created the MMC64 and
the 1541-III for the Commodore 64, just so that he could ask them how
they manage to offer such a low price ?

I hope they get enough revenue out of their projects to keep supporting
and producing them at this price. To name an example, Rich 'CFFA'
Dreher does this for years - and he is in his fourth(?) production run.
I don't know if you have a CFFA-card, but IMHO its very well worth its
price. And as Alex said, Rich documents everything - you can see how
complicated it was to create and how refined the design is. He tracks
and documents every single card he sells and I can personally confirm
his willingness to assist his customer.

And to give it yet another spin:
Yes, I am willing to spend some Euros/Dollars more - for a product that
I know is tested and supported to a certain degree. My time is too
precious and my money to valuable to spend on questionable or even
unreliable articles (note: I'm not saying that the C64-addons are!).

bye
Marcus

[SbM]

Post by h***@freenet.de
No, please don't be too touchy - I wasn't meaning to flame.

Everything fine then ;)

Post by h***@freenet.de

Post by SbM
Maybe Alex could get in touch which the people who created the MMC64 and
the 1541-III for the Commodore 64, just so that he could ask them how
they manage to offer such a low price ?

I hope they get enough revenue out of their projects to keep supporting
and producing them at this price.

The MMC64 is on its second run right now, so I guess the 1st run
produced enough revenue to support a second one.

[a***@gmail.com]

Having designed a board for the Apple II back in 1998, I seem to recall
that the price of getting boards manufactured had a high initial setup
fee.

you could use me... I've made some high quality PCBS using my
apple II and my milling machine.

cost to you: parts (plus maybe a populated tested board :-)

double sided, tin plated (no gold), via's need to be inserted and
soldered manually



Rich

[Alex Freed]

Post by SbM
Could you please explain why Apple II devices cost twice as much as
Commodore devices ? Are they more complicated to design ?

You already got one answer. Here is more specifics.

I work for free just because I like Apple stuff. But I still need to
manufacture the boards.
If I knew that I could cell 100 units, the price per board would be much
lower. If I only
assume 10 units will be sold, each PCB will cost about $25. Blank PCB.
The parts are not very expensive, but again more expensive in small
quantities.
Also I don't know that ALL the units I make will be sold so I can't cell at
cost.

As I said before my design work is free because it is fun. Assembling the
boards is NOT fun.
Nobody will do it for cheap if only a few units are made.

The number $100 is not an exact calculation of the cost. It is just a
convenient figure. If
CF boards are being bought, this is a similar device with more
functionality, so probably
the price is right.

Oh, and if you order 100 units, do I have a deal for you!

-Alex.

[SbM]

Post by Alex Freed
Also I don't know that ALL the units I make will be sold so I can't cell at
cost.

Maybe you could try a subscription thing (where people pay in advance
and you only build the boards when you get, like, 100 orders) ?

Just an idea...

Thanks for the info about your manufacturing process, though. And don't
get me wrong : I'm very grateful that people like you still create new
things for our beloved Apple IIs ! ;-)

[t***@boldt.ca]

Post by SbM
Could you please explain why Apple II devices cost twice as much as
Commodore devices ? Are they more complicated to design ?

Having designed a board for the Apple II back in 1998, I seem to recall
that the price of getting boards manufactured had a high initial setup
fee. So making 1 printed circuit board cost $250 but making 10 was
$300 (i.e. $30 per board) and larger quantities could have pushed that
down to $10 per board or less. Parts for the boards were not quite as
bad in small quantities but I did get a significant discount if I
ordered many of the same part at once. Perhaps the C64 community is
larger and can support better production quantities.

Terence
http://apple2.boldt.ca/

[Scott Alfter]

Post by SbM
Could you please explain why Apple II devices cost twice as much as
Commodore devices ? Are they more complicated to design ?

Having designed a board for the Apple II back in 1998, I seem to recall
that the price of getting boards manufactured had a high initial setup
fee. So making 1 printed circuit board cost $250 but making 10 was
$300 (i.e. $30 per board) and larger quantities could have pushed that
down to $10 per board or less.

Those prices have come way down. A couple of years ago, I had boards made
for a 1-Wire interface that plugs into the joystick port. It's only about
1"x1.5", but I had a dozen of them made for about $35, shipped.

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?

[Michael J. Mahon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by SbM
Could you please explain why Apple II devices cost twice as much as
Commodore devices ? Are they more complicated to design ?

Having designed a board for the Apple II back in 1998, I seem to recall
that the price of getting boards manufactured had a high initial setup
fee. So making 1 printed circuit board cost $250 but making 10 was
$300 (i.e. $30 per board) and larger quantities could have pushed that
down to $10 per board or less.

Those prices have come way down. A couple of years ago, I had boards made
for a 1-Wire interface that plugs into the joystick port. It's only about
1"x1.5", but I had a dozen of them made for about $35, shipped.

Scott, I'm interested in a similar-sized mini-board for NadaNet
adapters. Did you have to saw them apart yourself? Do you have
a URL for the service you used?

Thanks!

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[a***@gmail.com]

Post by Michael J. Mahon
Scott, I'm interested in a similar-sized mini-board for NadaNet
adapters. Did you have to saw them apart yourself? Do you have
a URL for the service you used?

send me the schematic as a DWG or other BOBCAD compatible
format, and I can make them for you.

RIch

[Michael J. Mahon]

Post by a***@gmail.com

Post by Michael J. Mahon
Scott, I'm interested in a similar-sized mini-board for NadaNet
adapters. Did you have to saw them apart yourself? Do you have
a URL for the service you used?

send me the schematic as a DWG or other BOBCAD compatible
format, and I can make them for you.

Thanks for the offer. ;-)

I'll have to look seriously at my options for doing the artwork...

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[Bill Garber]

"Michael J. Mahon" <***@aol.com> wrote in message news:cNudndsLooS6FlvZnZ2dnUVZ_r-***@comcast.com...
: ***@gmail.com wrote:
: > Michael J. Mahon wrote:
: >
: >>Scott, I'm interested in a similar-sized mini-board for NadaNet
: >>adapters. Did you have to saw them apart yourself? Do you have
: >>a URL for the service you used?
: >
: >
: > send me the schematic as a DWG or other BOBCAD compatible
: > format, and I can make them for you.
:
: Thanks for the offer. ;-)
:
: I'll have to look seriously at my options for doing the artwork...

I still have my artwork under ExpressPCB, and I can get quite
a few made for $59. Just need to make sure they're correct.

Bill Garber

[Michael J. Mahon]

Post by Bill Garber
: >
: >>Scott, I'm interested in a similar-sized mini-board for NadaNet
: >>adapters. Did you have to saw them apart yourself? Do you have
: >>a URL for the service you used?
: >
: >
: > send me the schematic as a DWG or other BOBCAD compatible
: > format, and I can make them for you.
: Thanks for the offer. ;-)
: I'll have to look seriously at my options for doing the artwork...
I still have my artwork under ExpressPCB, and I can get quite
a few made for $59. Just need to make sure they're correct.

Thanks, Bill--I'm closing the loop with you off-group...

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[Scott Alfter]

Post by Michael J. Mahon

Post by Scott Alfter
Those prices have come way down. A couple of years ago, I had boards made
for a 1-Wire interface that plugs into the joystick port. It's only about
1"x1.5", but I had a dozen of them made for about $35, shipped.

Scott, I'm interested in a similar-sized mini-board for NadaNet
adapters. Did you have to saw them apart yourself? Do you have
a URL for the service you used?

http://www.olimex.com/pcb/

They do free panelization of small layouts, including cutting the boards
apart. Other than a minor error on my part (some silkscreen over a couple
of pads), the boards arrived ready to stuff.

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?

[a***@gmail.com]

I have finished a prototype of a new mass storage device for Apple 2 >
The device looks to Apple as
a Disk ][ controller.

very cool... have you talked to the guy that made the SVD (semi virtual
disk)

I would be interested in one, but it's low priority...

I like Blurry's idea of selectable dsk images, so you can work with
multiple
disk programs..

Rich

[Alex Freed]

Post by a***@gmail.com
very cool... have you talked to the guy that made the SVD (semi virtual
disk)

No, I didn't talk to him but I did look at the design. I have a completely
different thing.

SVD
1. Uses RAM loaded from a PC
2. Connects to the disk controller
3. Emulates raw disk bits for a number of systems.

My MMCdisk
1. Uses MMC
2. Plugs directly into a slot.
3. Emulates either a Disk ][ or a pretty fast ProDOS volume.


My firmware is orders of magnitute simpler but (IMHO) provides a device
more useful for massive ammonts of data.

Post by a***@gmail.com
I would be interested in one, but it's low priority...

If your offer to make PCBs is good, we can start with making say 10 units.

Post by a***@gmail.com
I like Blurry's idea of selectable dsk images, so you can work with
multiple
disk programs..

Yes, I like it too. My original plan was to have the boot program ask the
user
which image to use and then select it. But I see how this is not good for
swapping
floppies during a game. So as a minimum I can add a DIP switch to select an
image
or maybe some external buttons.

Maybe one button that generates an interrupt and a handler that asks which
image to
use next? I mean Apple has a great keyboard so it's a shame not to use it.
:))


I don't know what good is a picture of a prototype, but somebody asked

Loading Image...


The unpopulated sockets are for EPROM and associated logic.
Not used during development.

-Alex.

[a***@gmail.com]

Post by Alex Freed
If your offer to make PCBs is good, we can start with making say 10 units.

send me a DWG file, and I'll see what I can do...
it would be nice to design a program that will convert
from DWG directly to my format, and do all the design
on an apple II using my CAD program....

but, it isn't required... all that is required is a format
that BOBCAD can handle, and I can start setting it
up...

if we're gonna do this, I need to create a brake for
the mills spindle, and a tool holder to hold a dremel...
using the spindle motor for high speed, low torque
fiberglass drilling doesn't make sense.. it would take
an hour or so to set it up with the dremel.



Rich

[[e-mail]]

Post by a***@gmail.com
if we're gonna do this, I need to create a brake for
the mills spindle, and a tool holder to hold a dremel...
using the spindle motor for high speed, low torque
fiberglass drilling doesn't make sense.. it would take
an hour or so to set it up with the dremel.

I assume you are aware of the high hazards of fiberglass dust --
similar to asbestos -- which is why these boards are normally made in
carefully controlled enviroments? Unless you have a way to make these
boards wet, it would be a foolish thing to do for you and your family,
healthwise.

[a***@gmail.com]

Post by ***@cimmeri.com

Post by ***@cimmeri.com
Unless you have a way to make these

boards wet, it would be a foolish thing to do for you and your family,
healthwise.

wouldn't be difficult to drill them wet...

the fumes from the etching solution and
tinning solution are horrible chemicals too...

Rich

[PZ]

Post by Alex Freed

Post by a***@gmail.com
very cool... have you talked to the guy that made the SVD (semi virtual
disk)

No, I didn't talk to him but I did look at the design. I have a completely
different thing.
SVD
1. Uses RAM loaded from a PC
2. Connects to the disk controller
3. Emulates raw disk bits for a number of systems.
My MMCdisk
1. Uses MMC
2. Plugs directly into a slot.
3. Emulates either a Disk ][ or a pretty fast ProDOS volume.

I think what they're trying to achieve is very similar, but implemented
very differently.

The SVD uses an external computer to load the images. It would be very
nice to have only one device (a card in a slot ideally) which you could
copy or unpack images from the host Apple II and then play them. Once
again, the limitation is how to "flip" the floppies. On a GS, perhaps
this can be done through the Control Panel, however on a IIe a physical
switch would be required. As it was mentioned before, for multi sided
games you'd have to be able to preload all of the sides. (I think the
latest Kings Quest was the largest with something like 12+ sides)

YES, I would be very interested in something like this!

- Paul

[Alex Freed]

Post by PZ
The SVD uses an external computer to load the images. It would be very
nice to have only one device (a card in a slot ideally) which you could
copy or unpack images from the host Apple II and then play them.

I didn't try it, but it should be possible to use any normal copying program
to read a real floppy and write to an image on an MMC.

In theory my floppy emulation can be near perfect in a sense that
half-tracks and even
quarter tracks can be emulated. But more involved firmware is needed and a
new
format for nibbles that indicates half-tracks, 36 an 40 uS sync bytes etc.

I have deliberately used an oversized AVR chip in terms of memory space so
that a lot of firmware
can be added.
It also has 2 UARTS so it is easy to add a nice fast and buffered serial
port.

Post by PZ
Once
again, the limitation is how to "flip" the floppies. On a GS, perhaps
this can be done through the Control Panel, however on a IIe a physical
switch would be required. As it was mentioned before, for multi sided
games you'd have to be able to preload all of the sides. (I think the
latest Kings Quest was the largest with something like 12+ sides)

The only thing that bothers me is the physical construction with a switch
accessable
from the outside.

-Alex.

[PZ]

Post by Alex Freed
The only thing that bothers me is the physical construction with a switch
accessable
from the outside.
-Alex.

That does pose a bit of a hassle, however only for //e, //+ users if
you use the Control Panel implementation on the GS. The Fingerprint
card had a slick implementation for an external switch, however that
was for a single push button, this would probably require a little more
complexity. FYI, the fingerprint card used a flat laminated cable
which easily bypassed the lids of the //e and GS.

Thinking WAY out of the box..........
Bluetooth might be an option in a year or two, given the mass market
acceptance of the technology. There's probably a turnkey chipset out
there that could make the implementation somewhat easier. You'd have
to develop a seperate "remote" however. It would be easier to
physically wire up a small switch, but not as badass as saying "Yeah,
let me get my bluetooth remote so we can play Karateka."

- Paul

[mdj]

Post by PZ

Post by Alex Freed
The only thing that bothers me is the physical construction with a switch
accessable
from the outside.
-Alex.

That does pose a bit of a hassle, however only for //e, //+ users if
you use the Control Panel implementation on the GS. The Fingerprint
card had a slick implementation for an external switch, however that
was for a single push button, this would probably require a little more
complexity. FYI, the fingerprint card used a flat laminated cable
which easily bypassed the lids of the //e and GS.

Perhaps it's worth considering an NMI detect upgrade for the IIe ?
Something that would detect an unusual keystroke and fire the NMI. You
need to patch into the keyboard connector and patch the ROM (perhaps
remove the essentially useless self-test routine)

Or perhaps it's just too much work. Would certainly be the most
seemless way to do it though.

Matt

[Alex Freed]

Post by mdj
Perhaps it's worth considering an NMI detect upgrade for the IIe ?
Something that would detect an unusual keystroke and fire the NMI. You
need to patch into the keyboard connector and patch the ROM (perhaps
remove the essentially useless self-test routine)
Or perhaps it's just too much work. Would certainly be the most
seemless way to do it though.

There may be a middle ground: a single button connected to the board that
will generate an NMI.
No need to mess with the keyboard connector. The problem is the need to
patch the ROMs.
I believe ProDOS doesn't like that, right?

There must be a way around it but I don't know enogh at this time.

-Alex.

[mdj]

Post by Alex Freed
There may be a middle ground: a single button connected to the board that
will generate an NMI.
No need to mess with the keyboard connector. The problem is the need to
patch the ROMs.
I believe ProDOS doesn't like that, right?

Hmm, The ROM upgrade is probably the trickiest bit - a simple piece of
hardware plugged into the keyboard to detect for example,
apple-shift-esc would be pretty easy to design.

The button idea is ok too, as all you need is debounce circuitry, so
it's a nice simple way. If the idea gets off the ground I'll consider
contributing a design for the keyboard edition.

As far as I know, there's no ProDOS issues. NMI is not officially used
in the Apple II, except of course for the IIgs

Matt

[Michael J. Mahon]

Post by mdj

Post by Alex Freed
There may be a middle ground: a single button connected to the board that
will generate an NMI.
No need to mess with the keyboard connector. The problem is the need to
patch the ROMs.
I believe ProDOS doesn't like that, right?

Hmm, The ROM upgrade is probably the trickiest bit - a simple piece of
hardware plugged into the keyboard to detect for example,
apple-shift-esc would be pretty easy to design.
The button idea is ok too, as all you need is debounce circuitry, so
it's a nice simple way. If the idea gets off the ground I'll consider
contributing a design for the keyboard edition.
As far as I know, there's no ProDOS issues. NMI is not officially used
in the Apple II, except of course for the IIgs

And NMI is not a fully "recoverable" interrupt, either, not to mention
its ability to kill real disks if writing...

There's a reason that IRQ can be disabled.

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[Linards Ticmanis]

Post by Michael J. Mahon
And NMI is not a fully "recoverable" interrupt, either, not to mention
its ability to kill real disks if writing...

The disk bit is clear - interrupt in the middle of writing a sector, and
at worst the whole track will go to never-never land.

But how exactly is a NMI "non recoverable" on the Apple? On the
Commodore that is not the case AFAIK, so I don't think it's a property
of the 6502. (Never refrain from refusing to have more than three
negatives in a sentence ;-)

[Linards Ticmanis]

Post by Linards Ticmanis
The disk bit is clear

^^^^^^^^^^^^^^^^^^^^^

This sounds confusing I fear. What I mean is, "the stuff Michael said
about the disk being possibly destroyed is obvious".

[Michael J. Mahon]

Post by Linards Ticmanis

Post by Michael J. Mahon
And NMI is not a fully "recoverable" interrupt, either, not to mention
its ability to kill real disks if writing...

The disk bit is clear - interrupt in the middle of writing a sector, and
at worst the whole track will go to never-never land.

(I knew what you meant, and never for a milisecond worried that
the "disk bit" might get accidentally set. ;-)

Post by Linards Ticmanis
But how exactly is a NMI "non recoverable" on the Apple? On the
Commodore that is not the case AFAIK, so I don't think it's a property
of the 6502. (Never refrain from refusing to have more than three
negatives in a sentence ;-)

In my mind, there has always been a "red flag" associated with the NMI,
possibly because of exceptional conditions related to its occurrence
during a BRK instruction.

Upon review, it seems that the only issue with NMI on an Apple II is
potential disruption of critical timing (as in the case of 5.25" disk
access) and the usual problem with not being able to discover the state
of softswitches on machines prior to the //e, so that memory and display
use potentially cause loss of state.

Of course, the "blind softswitch" problem applies equally to IRQ.

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[h***@freenet.de]

Post by PZ
Thinking WAY out of the box..........
Bluetooth might be an option in a year or two, given the mass market
acceptance of the technology. There's probably a turnkey chipset out
there that could make the implementation somewhat easier. You'd have
to develop a seperate "remote" however. It would be easier to
physically wire up a small switch, but not as badass as saying "Yeah,
let me get my bluetooth remote so we can play Karateka."

Why not use a cell phone with bluetooth functionality?
Sony Ericcson marketed an RC car which could be steered by its
BT-enabled phones.

bye
Marcus

[Linards Ticmanis]

Post by Alex Freed
In theory my floppy emulation can be near perfect in a sense that
half-tracks and even
quarter tracks can be emulated. But more involved firmware is needed and a
new
format for nibbles that indicates half-tracks, 36 an 40 uS sync bytes etc.

As a "nibble format" I'd suggest simply storing a 36 µS sync in 9 bits
and a 40 µS sync in 10 bits (i.e. just ignore byte boundaries and store
a raw bitstream), this is the most universal approach I think. Then just
duplicate the Woz Machine logic (not all that difficult if you have a
schematic of the old Disk II controller). Add a per-track bit count and
you should be fairly universal.

As for the disk selector: A NMI generating pin is an almost universal
approach - but not quite since a NMI writes three bytes to the stack,
which might contain useful data, though it's not all that likely that
they do. You'd really need to freeze the host CPU, DMA out the stack
page, and probably the zero page too, and then cause an NMI, forcing the
system to read *your* NMI vector instead of the one in ROM or RAM (can
you do that on the Apple?)

Problem with this: On a II/II+ you can't reliably freeze the CPU for
more than about 5 cycles, else it'll lose state.

[Alex Freed]

Post by Linards Ticmanis
Problem with this: On a II/II+ you can't reliably freeze the CPU for
more than about 5 cycles, else it'll lose state.

Sure you can. Softcard does. The trick is that the clock is only removed for
a few microseconds but then
is allowed for one cycle while READY is not asserted. So you can do DMA for
say 80% of all the cycles
and allow the 6502 to fetch a byte now and again.

The problem is that any such solution will increase the complexity of the
board very significantly.

-Alex.

[Linards Ticmanis]

Post by Alex Freed

Post by Linards Ticmanis
Problem with this: On a II/II+ you can't reliably freeze the CPU for
more than about 5 cycles, else it'll lose state.

Sure you can. Softcard does. The trick is that the clock is only removed for
a few microseconds but then
is allowed for one cycle while READY is not asserted. So you can do DMA for
say 80% of all the cycles
and allow the 6502 to fetch a byte now and again.

I don't have the data sheet for NMOS 6502 around.. what exactly is the
effect when you don't assert READY? The processor will fetch a byte but
will still stay stuck at the instruction it's at?

[Alex Freed]

Post by Linards Ticmanis
I don't have the data sheet for NMOS 6502 around.. what exactly is the
effect when you don't assert READY? The processor will fetch a byte but
will still stay stuck at the instruction it's at?

Yes, that's pretty much it.

6502 is/was not static so you could not disable the clock for a long time.
The idea od a READY signal is that if the
data is not ready, the CPU should waste a cycle and try again. This was the
mechanism used by the z80 SoftCard.
z80 does a memory refresh cycle on every insruction fetch. So z80 had "DMA"
access to the bus all the time except
during these memory refresh intervals when the 6502 was given a clock cycle
but RDY was not asserted. So the
1 uS cycle was "wasted" but the 6502 registers were preserved.

-Alex.

[Michael J. Mahon]

Post by Alex Freed

Post by Linards Ticmanis
Problem with this: On a II/II+ you can't reliably freeze the CPU for
more than about 5 cycles, else it'll lose state.

Sure you can. Softcard does. The trick is that the clock is only removed for
a few microseconds but then
is allowed for one cycle while READY is not asserted. So you can do DMA for
say 80% of all the cycles
and allow the 6502 to fetch a byte now and again.
The problem is that any such solution will increase the complexity of the
board very significantly.

I agree. Using a cannon to shoot a mouse violates one of "Robot's Rules
of Order". ;-)

For heaven's sake, it's a 2-pin pushbutton switch header, and there are
plenty of holes to bring out 2 wires! (I'm assuming that an IRQ/NMI
approach is taken, with an on-screen menu.)

BTW, any reason for choosing the MultiMedia Card over the more common
(and almost interchangeable) SD card?

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[Alex Freed]

Post by Michael J. Mahon
BTW, any reason for choosing the MultiMedia Card over the more common
(and almost interchangeable) SD card?

Either one will work because I use the SPI mode that must be always
supported.
In fact one of the 2 cards I use happens to be SD.

-Alex.

[Michael J. Mahon]

Post by Alex Freed

Post by Michael J. Mahon
BTW, any reason for choosing the MultiMedia Card over the more common
(and almost interchangeable) SD card?

Either one will work because I use the SPI mode that must be always
supported.
In fact one of the 2 cards I use happens to be SD.

Thanks--good to know!

Put me down for a board, too.

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[sicklittlemonkey]

Post by Alex Freed
In fact one of the 2 cards I use happens to be SD.

Yes, that is good to know.

I don't suppose one of the 2 machines you've tested this in happens to
be a //c? ;-) If only the //c had a slot. Just one slot (mem exp
aside). Your card would be what I would like to put in it. :-(

Cheers,
Nick.

[Alex Freed]

Post by sicklittlemonkey
If only the //c had a slot. Just one slot (mem exp
aside). Your card would be what I would like to put in it. :-(

The semi-virtual disk is probably your best bet. It doesn't need a slot but
pretends to be a disk drive.
However it requires a PC to load the disk image over the serial connection.

-Alex.

[sicklittlemonkey]

Post by Alex Freed
The semi-virtual disk is probably your best bet. It doesn't need a slot but
pretends to be a disk drive.
However it requires a PC to load the disk image over the serial connection.

The SVD sounds pretty cool, but as I expected, the site documents
problems trying to boot most software in a //c's external drive (in
slot 7 etc). The software often reverts back to accessing the slot 6
drive.

Hmm, I'm trying to get hold of a //c+, and that might actually have
more luck, since the internal 3.5 is mapped to slot 5, and the first
external 5.25 is mapped to slot 6.

Anyway, the coolness of your hack, like the CFFA is mass storage, and
thus a potentially diskless system. In fact I suppose your pseudo-disk
would have less trouble with the //c+ as well ... except for lack of a
slot, of course. ;-)

Cheers,
Nick.

[Alex Freed]

I have added some info to the FAQ page (http://mirrow.com/FPGApple/FAQ.html)
and a link to the sources.

http://mirrow.com/FPGApple/source

What good is an open source project with no sources published?

The firmware is very much work in progress. If anyone wants to offer
constructive cryticism or help, now is the good time.


-Alex.

[Grant Stockly]

Post by Alex Freed
I have added some info to the FAQ page (http://mirrow.com/FPGApple/FAQ.html)
and a link to the sources.
http://mirrow.com/FPGApple/source
What good is an open source project with no sources published?
The firmware is very much work in progress. If anyone wants to offer
constructive cryticism or help, now is the good time.

Can I see the CPLD code? I am working on something very similar for
the Altair. I'm using the AVR as a MMC to 8bit bus bridge, and like
you said the AVR is way too slow to handle the bus. I am using a CPLD
to handle all of the bus signals. Right now the CPLD asserts a signal
to the AVR when the AVR is needed, and the AVR clears the wait line
when its done. I haven't had the time to see what the times actually
are. I would love to see exactly how you are doing things. A 2MHz
8080 might be close to a 2MHz 6502.

Grant

[Alex Freed]

Post by Grant Stockly
Can I see the CPLD code?

I've mailed you the Verilog source.

-Alex.

[r***@gmail.com]

Hi Alex, great work and thanks for sharing your knowledge!

I was searching for the schematics and code for the pseudo disk but the links to the project are dead now. Can you email me the schematics and CPLD and AVR source code? What license do you use for the sources?

[Mark McDougall]

Post by Alex Freed
I don't know what good is a picture of a prototype, but somebody asked
http://www.mirrow.com/FPGApple/MMCdisk_proto.jpg

Does that proto board plug directly into the Apple II? Where did you get
it????

Regards,

[Alex Freed]

Post by Mark McDougall

Post by Alex Freed
http://www.mirrow.com/FPGApple/MMCdisk_proto.jpg

Does that proto board plug directly into the Apple II? Where did you get
it????

The big board plugs directly into the Apple slot. I got it many years ago in
a surplus store
a few miles from the Apple campus. The board has Apple logo and the sockets
for ROM were
already there. There was plenty of space left so I used it for the project.

-Alex.

[Mark McDougall]

Post by Alex Freed
The big board plugs directly into the Apple slot. I got it many years ago in
a surplus store
a few miles from the Apple campus. The board has Apple logo and the sockets
for ROM were
already there. There was plenty of space left so I used it for the project.

Ah, so there's little chance of being able buy one these days... :(

BTW which CPLD did you use? A MAX3000?

Regards,

[Alex Freed]

Post by Mark McDougall
Ah, so there's little chance of being able buy one these days... :(

I'm affraid so. However I have seen a while ago a proto board to fit Apple 2
slots. In fact it
has several sets of "fingers" to fit a number of computers.
Proto board for ISA bus are available too. Probably not hard to cut the
connector to 50 contacts.

Post by Mark McDougall
BTW which CPLD did you use? A MAX3000?

XC9536XL. More or less the same thing but I prefer Xilinx tools for my
"real" projects.

-Alex.

[Mark McDougall]

Post by Alex Freed
XC9536XL. More or less the same thing but I prefer Xilinx tools for my
"real" projects.

The reason I ask is that recently I've been considering doing a similar
thing for the TRS-80 hard-drive, since there seems to be a market for
that and I grew up with TRS-80s rather than Apples. I was looking at
prototyping the whole thing in an FPGA, only because I've already done
the TRS-80 side and also I've got (most of) the hardware already. Then
the idea would be to re-target to a MAX 3000 CPLD and do a small run of
boards.

I hadn't considered using a micro at all - since I'm emulating the
register interface of a HDD controller rather than raw disk signaling
there's no real need for a micro on my design...

Regards,

[d***@gmail.com]

Post by Mark McDougall

Post by Alex Freed
The big board plugs directly into the Apple slot. I got it many years ago in
a surplus store
a few miles from the Apple campus. The board has Apple logo and the sockets
for ROM were
already there. There was plenty of space left so I used it for the project.

Ah, so there's little chance of being able buy one these days... :(
BTW which CPLD did you use? A MAX3000?

How about this?

http://www.8bitbaby.de/

[Mark McDougall]

Post by d***@gmail.com
How about this?
http://www.8bitbaby.de/

Ah, cool! Thanks for the link!

Regards,

[PZ]

Post by Mark McDougall

Post by d***@gmail.com
How about this?
http://www.8bitbaby.de/

Ah, cool! Thanks for the link!

There's one thing thats kind of dissappointing with the 8bb, no break
out pads for the CPLD. You pretty much have to wire your jumpers
directly to the solder side of the 44 pin socket.

Its a cool multi platform implementation though, and the price is
certainly right. You can also avoid using the voltage regulator if you
can find some MAX 7032's or 7064's rather than the 30xx 3v equivalent.

- Paul

[Mark McDougall]

Post by PZ
There's one thing thats kind of dissappointing with the 8bb, no break
out pads for the CPLD. You pretty much have to wire your jumpers
directly to the solder side of the 44 pin socket.

Huh??? Where is the CPLD I/O wired to???

Regards,

[Michael J. Mahon]

Post by Mark McDougall

Post by PZ
There's one thing thats kind of dissappointing with the 8bb, no break
out pads for the CPLD. You pretty much have to wire your jumpers
directly to the solder side of the 44 pin socket.

Huh??? Where is the CPLD I/O wired to???

It's not wired to anything. That's up to you--and there are no
wiring pads brought out, just a place to solder a socket.

It would be hard to wire it usefully to edge connectors for four
different computers, but it would have been nice to have pads.
As it is, you have to "contact solder" all the wires you need
to the socket pads.

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[Mark McDougall]

Post by Michael J. Mahon
It would be hard to wire it usefully to edge connectors for four
different computers, but it would have been nice to have pads.
As it is, you have to "contact solder" all the wires you need
to the socket pads.

I'm flabbergasted! :O I would've thought the *obvious* thing to do would
be to bring the I/O out into the prototyping area with breakouts...

Hmmm... might think about doing my own version...

Regards,

[PZ]

Post by Mark McDougall

Post by Michael J. Mahon
It would be hard to wire it usefully to edge connectors for four
different computers, but it would have been nice to have pads.
As it is, you have to "contact solder" all the wires you need
to the socket pads.

I'm flabbergasted! :O I would've thought the *obvious* thing to do would
be to bring the I/O out into the prototyping area with breakouts...
Hmmm... might think about doing my own version...

Pretty rediculous, I agree. I was quite shocked when I got my board.
I thought about doing the same after I saw it - I was pretty teed off.
I have too many things going on the front burner right now, so go for
it.

- Paul

[n***@cishollywood.com]

Im interested in this board.

Thanks,
-Chris

Post by Alex Freed
I have finished a prototype of a new mass storage device for Apple 2 that
uses MultyMedia Cards.
So what, you'll ask. There is already a CF interface.
Yes and no. My toy has a small AVR microcontroller on board and 2 modes of
operation.
The trivial mode simply interfaces the MMC to Apple as yet another ProDOS
storage device.
The fun starts with the "smart" operating mode. The device looks to Apple as
a Disk ][ controller.
So Apple happily reads nibble images as if they were real 5 1/4" floppies.
This allows using
images of DOS 3.3 disks or any other .nib images. For example a couple of
games that do not
use DOS work fine.
The software is not quite finished: I need to add an application that will
run on Apple
and select one of many .nib images to use. My prototype just uses a single
image, but that is
not very difficult.
The firmware can use a lot of improvements too. Currently I feed Apple a new
byte every time
it asks for one instead of changing it every 32 msec. Seems to work for
quite a few images, but
won't work with many protection schemes.
The big question is is there any interest in this device? If there is, I can
make a small production
run and offer for say $100. If not, I'll be the only owner of the only
prototype.
The board has an AVR micro and a CPLD for fast interfacing. Originaly I
though that an AVR
running at 16 MHz is fast enough to do everything in software, but it is
not. In addition the
CPLD acts as a perfect 5v to 3.3v converter - MMC uses 3.3 V. I can add an
EPROM
to make this card bootable. Currently I boot from a real disk and DOS can
see the other
"disk" in another slot.
The MMC card can have up to 4 partitions. Some partitions up to 32 MB can be
seen
as ProDOS volumes and one can have any number of .NIB images.
Future driver will be able to see 2 images at once as drives 1 and 2.

[mr. brad]

i'd like such a board due to the fact dos 3.3 is useable with it....nice job
brad

[Alex Freed]

OK. Looks like there is a market for a few boards. I'll start with making 10
or so.

Post by mr. brad
i'd like such a board due to the fact dos 3.3 is useable with it....nice job
brad

[sicklittlemonkey]

Post by Alex Freed
OK. Looks like there is a market for a few boards. I'll start with making 10
or so.

I'm definitely up for one of these too. Great work.

When looking into the CFFA I pored over the documentation wondering if
disk images could be emulated somehow, but was disappointed that it
hadn't been thought of in advance. It's a great product, but this
wouldn't have been too hard to allow for as a future expansion.

About swapping disk images - I'm not a hardware guy, but if you had one
external pushbutton (think Wildcard), could you use DMA to stop the CPU
and read the keyboard for the image number?

Cheers,
Nick.

[Alex Freed]

Post by sicklittlemonkey
About swapping disk images - I'm not a hardware guy, but if you had one
external pushbutton (think Wildcard), could you use DMA to stop the CPU
and read the keyboard for the image number?

Yes, it can be done but requires a lot of logic (and wires on a prototype).
For DMA we have to drive all 16 address lines. Several TTL chips or
one more CPLD.

Thanks for the idea. I already thought of one button, but for NMI rather
than DMA.

-Alex.

[sicklittlemonkey]

Post by Alex Freed
Yes, it can be done but requires a lot of logic (and wires on a prototype).
For DMA we have to drive all 16 address lines. Several TTL chips or
one more CPLD.
Thanks for the idea. I already thought of one button, but for NMI rather
than DMA.

So I guess the other option is making the "remote control" slightly
more complicated but much more useful. Single hex digit led display
(0-F) and a few buttons: next/previous image and write protect toggle
perhaps?

Cheers,
Nick.

[BLuRry]

Post by sicklittlemonkey
About swapping disk images - I'm not a hardware guy, but if you had one
external pushbutton (think Wildcard), could you use DMA to stop the CPU
and read the keyboard for the image number?

That would be neat. Stop the cpu, read the softswitches for the
current video mode (and retain those), backup $400-$7ff to onboard ram
and then take control with a UI menu.

Or am I going way too far with that idea? I've been known to do that.
:-D

(oh, and make sure it works on 6502 machines, that seems to be a
requirement ;-)

-B

[Linards Ticmanis]

Post by BLuRry
That would be neat. Stop the cpu, read the softswitches for the
current video mode (and retain those), backup $400-$7ff to onboard ram
and then take control with a UI menu.

[...]

Post by BLuRry
(oh, and make sure it works on 6502 machines, that seems to be a
requirement ;-)

Difficult. You can't stop a NMOS 6502 long enough to do all these things
at once, I think. It has to run about one cycle out of five or six to
keep its state.

[Michael J. Mahon]

Post by BLuRry

Post by sicklittlemonkey
About swapping disk images - I'm not a hardware guy, but if you had one
external pushbutton (think Wildcard), could you use DMA to stop the CPU
and read the keyboard for the image number?

That would be neat. Stop the cpu, read the softswitches for the
current video mode (and retain those), backup $400-$7ff to onboard ram
and then take control with a UI menu.

Unfortunately, that (and other) state is not machine readable prior to
the //e.

-michael

New, faster SUDOKU v2.0 solver for Apple II's!
Home page: http://members.aol.com/MJMahon/

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

[Linards Ticmanis]

Post by Michael J. Mahon

Post by BLuRry
That would be neat. Stop the cpu, read the softswitches for the
current video mode (and retain those), backup $400-$7ff to onboard ram
and then take control with a UI menu.

Unfortunately, that (and other) state is not machine readable prior to
the //e.

Well, you *could* keep a copy of that info in the card by snooping the
bus all the time...

This deal gets worse all the time. ;-)

[David Wilson]

Post by BLuRry

Post by sicklittlemonkey
About swapping disk images - I'm not a hardware guy, but if you had one
external pushbutton (think Wildcard), could you use DMA to stop the CPU
and read the keyboard for the image number?

That would be neat. Stop the cpu, read the softswitches for the
current video mode (and retain those), backup $400-$7ff to onboard ram
and then take control with a UI menu.

This sounds just like the FingerPrint GS card (and possibly like the
other FingerPrint cards).

[Bryan Parkoff]

Post by Alex Freed
I have finished a prototype of a new mass storage device for Apple 2 that
uses MultyMedia Cards.
So what, you'll ask. There is already a CF interface.
Yes and no. My toy has a small AVR microcontroller on board and 2 modes of
operation.
The trivial mode simply interfaces the MMC to Apple as yet another ProDOS
storage device.
The fun starts with the "smart" operating mode. The device looks to Apple as
a Disk ][ controller.
So Apple happily reads nibble images as if they were real 5 1/4" floppies.
This allows using
images of DOS 3.3 disks or any other .nib images. For example a couple of
games that do not
use DOS work fine.
The software is not quite finished: I need to add an application that will
run on Apple
and select one of many .nib images to use. My prototype just uses a single
image, but that is
not very difficult.
The firmware can use a lot of improvements too. Currently I feed Apple a new
byte every time
it asks for one instead of changing it every 32 msec. Seems to work for
quite a few images, but
won't work with many protection schemes.
The big question is is there any interest in this device? If there is, I can
make a small production
run and offer for say $100. If not, I'll be the only owner of the only
prototype.
The board has an AVR micro and a CPLD for fast interfacing. Originaly I
though that an AVR
running at 16 MHz is fast enough to do everything in software, but it is
not. In addition the
CPLD acts as a perfect 5v to 3.3v converter - MMC uses 3.3 V. I can add an
EPROM
to make this card bootable. Currently I boot from a real disk and DOS can
see the other
"disk" in another slot.
The MMC card can have up to 4 partitions. Some partitions up to 32 MB can be
seen
as ProDOS volumes and one can have any number of .NIB images.
Future driver will be able to see 2 images at once as drives 1 and 2.
--
-Alex.

I wonder -- do you think that some folks are willing to spend their time
by converting all games from DOS 3.3 to ProDOS and eliminate copy-protection
scheme. It is like Sierra games such as King's Quest. It is too much work
to do by decompiling 6502 assembly code. Modifying and updating it to work
with ProDOS. Is it worth?

Bryan Parkoff

[BLuRry]

Post by Bryan Parkoff
I wonder -- do you think that some folks are willing to spend their time
by converting all games from DOS 3.3 to ProDOS and eliminate copy-protection
scheme.

One way to think of it is copy protection. Another way to think of it
is that each game has its own unique OS. Prodos occupies a lot of ram,
and thus might make it next to impossible to fit some games in ram and
play nicely.

Post by Bryan Parkoff
It is like Sierra games such as King's Quest. It is too much work
to do by decompiling 6502 assembly code. Modifying and updating it to work
with ProDOS. Is it worth?

Worth it? Maybe. Possible? Maybe not in some cases. It would be
nice to see the mutated prodos-based origin games play off of a
harddrive for a change. That would probably be doable. (ultima 5,
ultima 1&2 rereleases, wind walker)

-B

[Terry Olsen]

Do you have any pictures?

Post by Alex Freed
I have finished a prototype of a new mass storage device for Apple 2 that
uses MultyMedia Cards.
So what, you'll ask. There is already a CF interface.
Yes and no. My toy has a small AVR microcontroller on board and 2 modes of
operation.
The trivial mode simply interfaces the MMC to Apple as yet another ProDOS
storage device.
The fun starts with the "smart" operating mode. The device looks to Apple as
a Disk ][ controller.
So Apple happily reads nibble images as if they were real 5 1/4" floppies.
This allows using
images of DOS 3.3 disks or any other .nib images. For example a couple of
games that do not
use DOS work fine.
The software is not quite finished: I need to add an application that will
run on Apple
and select one of many .nib images to use. My prototype just uses a single
image, but that is
not very difficult.
The firmware can use a lot of improvements too. Currently I feed Apple a new
byte every time
it asks for one instead of changing it every 32 msec. Seems to work for
quite a few images, but
won't work with many protection schemes.
The big question is is there any interest in this device? If there is, I can
make a small production
run and offer for say $100. If not, I'll be the only owner of the only
prototype.
The board has an AVR micro and a CPLD for fast interfacing. Originaly I
though that an AVR
running at 16 MHz is fast enough to do everything in software, but it is
not. In addition the
CPLD acts as a perfect 5v to 3.3v converter - MMC uses 3.3 V. I can add an
EPROM
to make this card bootable. Currently I boot from a real disk and DOS can
see the other
"disk" in another slot.
The MMC card can have up to 4 partitions. Some partitions up to 32 MB can be
seen
as ProDOS volumes and one can have any number of .NIB images.
Future driver will be able to see 2 images at once as drives 1 and 2.
--
-Alex.

[sicklittlemonkey]

Post by Terry Olsen
Do you have any pictures?

Alex posted this link:
http://www.mirrow.com/FPGApple/MMCdisk_proto.jpg

Cheers,
Nick.