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.
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
> 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.
Cheers,
Mike T.
> 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 ;-)
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
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
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/
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...
> 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
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
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.
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.
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.
>
> 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.
>
> 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
http://www.mirrow.com/FPGApple/MMCdisk_proto.jpg
The unpopulated sockets are for EPROM and associated logic.
Not used during development.
-Alex.
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
> 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 ! ;-)
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
> 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.
> 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.
> 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
> 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,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
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.
Thanks,
-Chris
On Thu, 20 Jul 2006 03:03:35 -0700, "Alex Freed" <al...@mirrow.com>
wrote:
> 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?
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.
>
> 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.
"mr. brad" <mrbrad...@ll.net> wrote in message
news:Ao-dnU672LxuwF3Z...@ll.net...
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
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.
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.
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.
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.
> 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...
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
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.
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
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.
> 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
In article <1153428425.4...@75g2000cwc.googlegroups.com>,
<ter...@boldt.ca> wrote:
>> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEwSp5VgTKos01OwkRAkDoAKDzIwubcEMI7sAt+qwfrf/CzpxiIQCfal0D
4kr93RWkSKifvdzHrhfCn+M=
=bryx
-----END PGP SIGNATURE-----
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
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
wouldn't be difficult to drill them wet...
the fumes from the etching solution and
tinning solution are horrible chemicals too...
Rich
> 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.
--
Linards Ticmanis
> 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.
[...]
> (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.
--
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.
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.
>> 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?
--
Linards Ticmanis
--
Posted via a free Usenet account from http://www.teranews.com
Alex posted this link:
http://www.mirrow.com/FPGApple/MMCdisk_proto.jpg
Cheers,
Nick.
> 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
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.
> 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 ?
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
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."
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.
send me the schematic as a DWG or other BOBCAD compatible
format, and I can make them for you.
RIch
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?
Unfortunately, that (and other) state is not machine readable prior to
the //e.
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.
Thanks for the offer. ;-)
I'll have to look seriously at my options for doing the artwork...
Thanks--good to know!
Put me down for a board, too.
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
Hey, I'm not mad! Damnit!!! ;-)
No, please don't be too touchy - I wasn't meaning to flame.
> 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.
> 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
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.
> 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
> No, please don't be too touchy - I wasn't meaning to flame.
Everything fine then ;)
> > 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.
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.
How about this?
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.
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.
> How about this?
> http://www.8bitbaby.de/
Ah, cool! Thanks for the link!
Regards,
--
| Mark McDougall | "Electrical Engineers do it
| <http://members.iinet.net.au/~msmcdoug> | with less resistance!"
> 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
> 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".
--
Linards Ticmanis
>> 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. ;-)
--
Linards Ticmanis
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
Thanks, Bill--I'm closing the loop with you off-group...
(I knew what you meant, and never for a milisecond worried that
the "disk bit" might get accidentally set. ;-)
> 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.
> 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,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
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.
> 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...
This sounds just like the FingerPrint GS card (and possibly like the
other FingerPrint cards).
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
In article <3dednStZ0qtA8FvZ...@comcast.com>,
Michael J. Mahon <mjm...@aol.com> wrote:
>Scott Alfter wrote:
>> 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?
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEyVxFVgTKos01OwkRAuY3AJ9on02xeDIgX2AXtQadhY4KbEWbWgCbBJim
Qu+aZA93SlHkp9jcXwzHupo=
=rZhO
-----END PGP SIGNATURE-----
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.
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.