Re: How do I add firmware to a card?

[Tristan Mumford <xtristan.xmumford@xgmail.xcom>]

RedskullDC wrote:

> Hi Tristan,
> 
> "Tristan Mumford" <xtristan.xmumford@xgmail.xcom> wrote in message
> news:459ced79$0$38159$c30e37c6@lon-reader.news.telstra.net...
> 
>> Can I ask a bit more about the 256 byte memory area?
>> It's been mentioned that banking it is an option. What's the best method?
>> Because I will need more than this.
> 
> As Michael mentioned in another post, if you use the "banked" (or shared)
> $C800-$CFFF area, you need some extra componentry.
> The circuitry required to support the banked area is fairly well covered
> in the //e reference manual : http://www.apple-iigs.info/doc/docii.htm
> (Mon Dieu! C'est en Francais!)
> The "Understanding the Apple2" book covers the topic to death aswell
> (IIRC).
> 
> The 256 byte area $CN00-$CNFF, where N is your slot number on the other
> hand belongs solely to your card.
> 
> This small area is not necessarily a barrier, you could have a very large
> driver if you are happy to switch parts of it in 256bytes at a time.
> 
> Imagine that you had built the Flash card in my project and you had it in
> slot#2. If you had Bank00 of the Flash chip switched in to the $C200
> space, and executed the following code:
> 
> C200: A9 01           LDA #$01
> C202: 8D A0 C0     STA $C0A0; set high order address lines to 01 plus set
> /OE low for read. C205:......
> 
> The STA instruction has switched in Bank01 of the Flash chip.
> The next instruction at $C205 will come from $000105 in the Flash chip.
> 
> You would jump back to Bank00 in a similar way by writing $00 to $C0A0.
> Small overhead really, for an extra 250 bytes of driver code space.

That seems easy enough. The driver could be done in 256 bytes if I were
determined but it'd lose most of its features along the way. For example,
to add more than one device to the controller I'd need the code to
enumerate the USB device tree rather than just directly talking to a single
device.
I don't mind too much if the drivers for different types of device are
stored in RAM though.

It might be fun though to give it enough code to look at 'track 0' of a USB
drive, and load an OS PC style with 6502 code.



> 
> The Apple 2C uses a very similar method to switch its Banks of ROM in and
> out: Writes to $C028 switch between banks. There are some routines around
> $C780 (which exist in both banks of the ROM) to allow easy jumping back
> and forth between ROM banks.
> Fire up a 2c emulator and check it out if you don't have a real one.
> 
>> 
>> I don't see why it would be much harder to load raw data ( no fs) from a
>> USB mass storage device than the loading dos image example you so
>> courteously made.
>> Just as a first test. Know what I mean? Anyway it's not hard to write raw
>> data to USB mass storage in linux to shove into the apple.
> 
> The Apple is not fast enough to act as a USB host (I don't think so at
> least), you will need an extra uController on an interface card.

The apple is fast enough depending on how it's done.
If one were to bit-bang the interface it would be far too slow. However the
USB controller IC that I am using (and many others) are the rough
equivalent of an USB UART. A frame of USB data (should be) smaller than the
size of the onchip buffer. So it can be raided for information at the
computer's leisure. Then the computer tells the peripheral via the
controller that its ready for the next frame. So overall data transfer is
slow but it shouldn't drop anything. That is unless it's a HID device. They
pretty much just blindly vomit data once initialised correctly.

> Here is a firmware only version for the AVR:
> http://www.obdev.at/products/avrusb/index.html
> Even USB 1.1 requires an AVR running at 12MHz to implement in firmware.

The 12MHz is the clocking frequency for USB 1.n devices. Or a multiple
anyway. I got the original 12MHz xtal from a dead webcam.

> 
> Compact flash is probably easiest, though that has already been done....
> 
> SD cards look interesting, cheap, easy to interface.
> You may have noticed the SD interface mini board on futurlec for $6.90 ?

SD card interface should be really easy. As long as the SD card is accessed
via SPI. To use the proper fullspeed SD interface it requires a mystical
indoctrination from the licenseholders of the SD standard. Not easy or
cheap.

Adding a uC was my original idea which I got as far as prototyping.
Unfortunately some unknown force drifted in and eventually stopped
effective communication between the USB IC and the uC.

My fantasy v2 of the uC based one was going to use an 8051 based uC. It
would utilise the uC's ability to have an externally mapped  (and
multiplexed) address/databus for user-loadable drivers (loaded via a
bootloader in the uC).
If I were a real sadist I could share the memorymap of the 8051 with the ][
and use it for other things too like emulating DMA etc.

But for a first attempt I'm going to use a simple-ish uC-less design. But
with the flash or one of the NVRAMs I have. I'll probably do the testing on
the ][ clone so it'll need some kind of persistent storage.

I ordered the parts last night too. $12 including postage ($4) from Futurlec
last night. Making progress!

One final thing. If it works well I'll probably put it in my platinum. It
has an externally connected ATX PS so there's plenty of space for a hard
drive. Has anyone seen the USB -> IDE hard drive cables on eBay? Not the
ones with shells. There are ones that just plug into the data connector of
the IDE drive and have a kind of plugpack adaptor for power. Perfect :)
-- 
-----> http://members.dodo.com.au/~izabellion1/tristan/index.html <-----
=====       It's not pretty, it's not great, but it is mine.       =====