Anonymous
User login
Please support the defense of Ukraine.
Direct or via Unclutter App
Active forum topics
Recent content
Navigation
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
You have two 82C55s which are not working and behaving the same way - both the same brand?
Does it work when you slightly reduce the 10k pull-down resistor(s)? Try using 4k7 resistors instead of 10k.
The 8255 has a weird property: a "bus hold logic" for its input pins. I checked the data sheet and indeed the pull-downs in the current design are a bit marginal/weak:
82c55.png
The chip actively drives its input (!) port pins with 3V and up to 400µA.
A 10k pull-down resistor at 3V only provides a load of 300µA - which indeed may not be enough to overcome the bus hold logic. It usually works - since the data sheet mentions a very wide range (50 - 400µA). But a chip at the upper limit (400µA) would still be "in spec" but not work with 10k pull-downs. Reducing the pull-downs to 4k7 increases the load to over 600µA (at 3V), so this always has to be enough to overcome the chip's bus hold current (otherwise the chip is bad/out of spec).
I don't think the 8255 chips have that. I've only seen it on 82C55 chips and not all of them. For example the ones I have (OKI M82C55A) don't seem to have it. It would be useful to measure the voltage between the closed JP2 and ground on a card with one of those Harris chips and the 10k resistors still in place.
Here are all the chips that I have tested successfully on my two Dan ][ Controller cards. All the CMOS ones are on the left side:
IMG_5788.JPG
The votage between the closed JP2 and ground is 0.001 V for the CMOS ones and 0.015 V for the other ones. However if all 82C55 chips with this "BUS hold" feature don't work with 10k resistors, I totally agree that the design should be changed to 4.7k.
Also I think the official design should change R9 and R15 to 80 and 160 ohms in order to support the microSD extenders as described in this post. I've been running my modified Dan ][ Controller for several weeks now without any adverse effects.
Btw, amazing work on the software side!
Hi all,
Using my old Fluke 83 multimeter I made the following volatge meaurements.
Chip Harris CP82C55A
Card voltage from ground and +5 volts measured at connector j4 has a stable 4.91 volts powered from my Apple 2e bus
PC0 with a 10k pull down resistor shows a voltage of 1.801 volts.
PC0 with a 5K pull down resistor shows a mV reading of 0.1 mV.
For this chip 10k ohms would seem to high.
Not going to unsolder resistors at the moment until new different make of chip arrives about 10 days.
Hope this helps the discussion .
I changed it from 4k7 to 10k, maybe I shouldn't have.
These ICs have a certain amount of "following" voltage on their input/output pins to latch to the output of a bus. The purpose is to allow a quick transition of the bus state with a high current during a transition but not have the quiescent power be too high in a static state. It appears the current here required in the static state is a little higher than I thought, maybe I should change the pull-down back to 4k7.
The best so far are
Mitsubushi M55L8255AP-5 with only 17 mV to ground this is a very old chip lurking at the bottom of my parts bin.
Just arrive from China.
WINGSHING W582C55A-5P 1st chip dead second working chip with 0.1 mV.
Considering the range that I am seeing I think 4k7 pull downs would be best used.
I customized the Arduino bootloader for the DAN][ card. This enables the Apple II to directly update the firmware of the controller. Hassle-free, no cables required - just run an update utility on the Apple II. This should make future updates and custom extensions much easier, since updates can be offered as a simple Apple II utility/disk.
I find it quite convenient - even for developing. The update through the Apple II is really fast. It would also make a lot of sense if this was installed on cards, which are being given away/sold. I see some being offered on ebay. People buying these cards may have no idea about how to update an Arduino, much less know about ICSP programmers or matching RS232 adapter cables. If this bootloader was installed, anyone can simply update the firmware of their devices to get new features. Should also be a "plus" for such ebay offers, since people will usually prefer cards which can be updated.
The custom bootloader is a simple fork of the Arduino bootloader. I only replaced the UART send/receive functions with the respective code to read/write from the DAN][ card's internal port to the Apple II. It's just as safe as the original: the bootloader itself is protected and always keeps working. Even if you "bricked" a card with bad firmware (you could even flash random data if you wanted) - just re-run the update utility to recover and program working firmware.
The update utility is a simple ProDOS application for the Apple II, containing the Arduino firmware as data. Fortunately the Apple II is still superior in terms of memory: the complete 32KB Arduino flash image fits into a single Apple II ProDOS executable. The update utility is loaded to Apple II RAM, then asks the user to press "Ctrl-Reset". This resets the Arduino on the DAN][ card - so it restarts and executes its bootloader. At the same time this triggers a warmstart on the Apple II. The warmstart is caught by the update utility, and it immediately starts "talking" to the Arduino bootloader and sends the flash commands. The protocol is identical to what Arduino normally uses ("STK500"). The only difference is that those commands are now being sent from the Apple II, rather than via the Arduino's RS232 port.
The "ftp" branch of my github project contains a matching update utility (and a copy of the bootloader's hex file). I've also uploaded a ZIP file containing disk images (for the update utility) and hex files (for the Arduino bootloader):
https://github.com/ThorstenBr/Apple2Card/releases/tag/v2.0.3
Of course, this firmware update utility only works once the new bootloader was installed on the Arduino. But I guess anyone able to build a DAN][ card from scratch and program an ATMEGA, is also able to program its bootloader. (All you really need is another Arduino board, or a second DAN][ card, so one is used as the ICSP programmer and the other as the device to be programmed. There are lots of guides on the net, explaining how to update the Arduino bootloader - so I probably don't need to explain details here).
Here's a brief video showing how quick and easy a firmware update is, once the new bootloader is installed:
https://www.youtube.com/watch?v=ViGnc-YHbAo
I made another firmware update for the DAN][ controller - making it even more flexible. It kind of completes the work that Daniel started by internally switching volume access on the fly. This was necessary to work around the resource limitations on the ATMEGA controller, which are just enough to handle a single FAT-formatted volume only. The resources on the controller are limited - but just as we already learned from programming a 6502: you can still squeeze out a little more - you just have to optimize harder...
Here's the most important changes:
bootmenu.jpg
You can find these changes in my github. There is also a ZIP file with disks and binaries under "releases":
https://github.com/ThorstenBr/Apple2Card
Finally, if you want a demonstration of the latest features and some of the other improvements (and hear me rambling along :) ), there's a video here:
https://www.youtube.com/watch?v=25VKtxJNyME
Thanks Dan for the great project! I've been working on a derivative of the card, mostly because:
1) having the board part assembled is super cheap at JLPCB
2) I can't find the old thru hole 328*s easily in the UK
3) I got a box of atmega644's!
4) I would have to BUY thry hole resistors and stuff, while I have tons of 0603's and 0402's of many kinds!
So I mostly converted all passives to SMT (still hand solderable, reasonable 0603's with the 'hand soldering' pads).
+ Added a LDO for the 3.3V for the SD cards
+ Added capacitance to the card rail as some cards are REALLY hungry
+ Changed 328p* to a mega644p*
+ Moved all the connectors to the top of the card
+ Moved all the LEDs to one corner
There's tons more pins available on the m644, twice the flash, and more SRAM that can't hurt! I haven't pushed my fork to github just yet, I hoped to have something that at least compile on the 644 but I'm in arduino-library-hell on linux here so I need so that out...
2023-08-03-193108_1200x698_scrot.png
I 'finished' the routing, and I made a BOM containing the JLCPLB parts, so one can order the whole board (minus the 644 as it's out of stock there at the minute!) Even the 82C55 is in stock so its soldered on. Even the EEPROM socket is there. I've got 5 of them on order (~£90 shipped). I'm not too worried as it is pretty much *exactly* the same as the original, more or less.
I've submited a PR to Thorsten, who seems to have taken over the project (?) ...
https://github.com/buserror/Apple2Card/tree/main/Apple2Card_x44
You should annotate at least all SMD elements with the JLCPCB part numbers, so that anyone can order the cards with all the SMD elements already soldered:
JLCPCB.png
You can do the through-hole elements too, but it's a bit more expensive as it requires wave soldering as well. SMD only is really cheap and the soldering looks absolutely perfect. Cannot say the same about their through-hole soldering though. There are many videos on YouTube how to do it: https://youtu.be/VejO8rDdhzo
Btw, amazing job! Same goes for MacFly on the software side!
Yes the branch I pushed has the LCSC reference number, however, I also added the placement file generated by the plugin, it is essential has it has rotation for some of the parts. But overall, you can just upload what's in the Apple2Card_x44/jlcpcb/production_files/ duirectory and you are good to go!
I've since also update the PR with a first port of the software to m644p. I need to review it, but the Makefile now can build both firmwares, and a quick check of the pinouts *appear* to show it "should work" -- but I need to go over it with a comb, as I've noticed some place where it hard coded the CS pins.
I wouldn't want to put it this way ("taken over"). It's still Daniel's original idea. I'm just pushing ahead with several SW features, since the card continues to be a very useful tool for a lot of projects and stuff I'm playing with on my Apple IIs and III. And I'm still not done - see below. That's the nice thing about open source/CC projects: everyone can add & extend.
Concerning the pin definitions: indeed the CS/CS2/CS3/... defines in the pindefs.h header are barely used (if at all). You also need to adapt the macros in pindefs.h and those in mmc_avr_spi.c. The pin defines use the Arduino I/O pin numbering scheme, while the macros directly access the processor registers of the respective I/O ports. The obvious/probable reason to bypass the Arduino library and directly access the hardware registers was to improve performance. I'll have a look at your SW changes for the new atmega. Might be good to wait until you received the PCBs and had a chance to test it though?
Long file name support for DAN ][ cards
Since we're talking about new features and community contributions: here's another feature for the DAN ][ card. In fact, this was suggested by another AppleFritter member (teki1970), who asked me about it. I quite liked the idea. It should be handy for all those who use individual files on the SD cards (DOS/FAT format), rather than the RAW block format:
DANII_FatVolumeNamingScheme.png
New firmware is in my github:
https://github.com/ThorstenBr/Apple2Card/releases/tag/v3.1.0
The downside of the new naming scheme is that we cannot change the DOS filenames through the FTP access. So the long file names no longer make sense, when you upload new content via FTP. But I guess those using FTP don't care about DOS/FAT filenames anyway, since the long filenames are not visible via the controller's tiny FTP server anyway. (In fact, using the plain "RAW block" format is also a good choice when using FTP access, since the DOS/FAT filesystem just adds overhead - and has no real benefit when the SD cards are just managed remotely anyway.)
I only added a case for Mega644 to the software (and changed the Makefile), it's pretty safe -- and I think it should work, in fact the software NOT using Arduino pin number helps, as I've mapped the 'functions' not the 'pins' -- so I checked SPI and it's OK, the CS lines were the only one that are GPIOs and theres only CS3 (for ethernet) that use the arduino number...
I also purposefuly used a 16M crystal (the m644 COULD go up to 20MHz) so it should also be cycle accurate..
TBH it's looking quite good, crossing fingers ;-) :-)
Nice new changes to the software!
OH! One thing that I couldn't find, is the source of the tweaked bootloader; it'd be nice if I could make an equivalent for the m644 but I could only find the .hex...
The bootloader is built in a separate repository. That's a fork of the "MiniCore" bootloader project - adapted for the DANII controller. You can see the two simple changes (commits) I made. I simply copied the macros to communicate with the Apple II from the DANII project - and replaced the UART in/out functions of the bootloader accordingly. And I added a small change so the bootloader immediately bails out when it sees the first sync byte of a DAN II command ("0xAC").
The MiniCore project supports the entire atmega series. So it might just be a matter of rebuilding the project and then copying the atmega644 "optiboot" binary over to the DANII project. But if there were any necessary changes to the pin mapping/macros, then these would also need to be done in the MiniCore sources.
https://github.com/ThorstenBr/MiniCoreDAN2Controller
I added a make variable to enable building for the DANII controller (instead of stock Arduino), e.g:
(Obviously you will need to replace "atmega328p" with your controller type in the command-line...)
hi all and a big thanks to everyone thats contributed to the card in particular big thanks to macfly helped put some of my thoughts to life with the card absolutely love it!
New smd board looks nice i was thinking of building a second for a IIgs but wondering if possible to make a second version (if space permits)with the atmega328 in dip format like Daniel’s original design instead of the 644. My soldering skills are non existent but soldering sockets is fine ;-)
great work guys!
@MacFly, thanks for the instructions; I've updated my PR branch with the bootloader added. So now I'm actually 'ready' :-)
So @MacFly, if you don't mind a couple of question?
1) I see a fuse.cfg file in the repo -- is it still used? Is it some sort of default filename loaded by arduino-cli, and therefore, should I also make a derivative? I don't mind setting the fuses via AVRdude and adding a line to the Makefile to do it...
2) What's your 'work cycle' with the board? Can you TTFP a new AVR firmware to the card via ethernet, and reflahs the AVR from the apple II tools? Just trying to get my head around how I'm going to set myself up to hack around with the card...
I'm currently busy pressing F5/Reload on the JLPCB progress page, boards are curently being assembled, it's quite addictive to watch :-)
It is used by the "minipro" CLI utility, commonly used to program AVRs with the cheap Minipro programmer under Linux/MacOS.
It is referred to by Apple2Arduino/Makefile.
I've never used the "fuse.cfg" file. Someone added it to Dan's repo a while ago. The commit says it's a config file for "minipro". That's a very popular programmer (which I do not have). Some will certainly find that very useful. I personally run "avrdude" from the command line. I added a description to the README. Some may find this useful. It's an "open" project: always good to support different personal preferences and having variety.
Concerning "workflow": I normally just run
in the project's root directory. Builds everything - including the disk image with the firmware update. Then downloads the image via ftp to the SD card. The Apple just needs a reboot, loads the new disk image, runs the firmware update. Just takes a few seconds and is actually quicker than using the ICSP connection (which at least for me is very slow - using another "Arduino as ICSP"). And when I "brick" the card, I have another disk (real or FloppyEmu) with a known good firmware to recover. The IP address and volume number for the FTP target are configured in the Makefile. You can edit that locally if you wanted to use this approach.
But in your case, with the new ATmega device, you may still need a serial connection for the bring up. Unless you're really lucky and it basically all just works out of the box... You can hook an USB-RS232 converter to the RX/TX pins on J5. The serial debug output isn't enabled by default. But there are compiler switches in the Arduino sources. But be careful: the Arduino "Serial" class needs quite a bit of memory. Also, too many debug "Serial.prints" may consume too much memory (each string is stored in flash and also loaded to RAM...). And when the system runs low on RAM, then the stack just grows into the RAM data area. There are no blue-screens or exceptions: low RAM just causes very strange and "inexplicable" things to happen... :)
And speaking about variety and personal preferences: I see the advantage of the SMD boards. But I personally really like the "retro look" of the through-hole PCBs and all-DIP-ICs. Just fits the Apple II (and III) boards so well. Here's something I recently did, when I ordered a few more PCBs: a minor update, same schematics, just minor realignment of components. I ordered "gold fingers" (ENIG surface) and "chamfered connector edge" (which required a slight realignment of the slot fingers, to provide the necessary edge clearance of the copper layer). I really like the result: the gold finish looks great. And they are a little easier to plug, with the chamfered edge. But as I said: nothing wrong with different preferences.
PCB_GoldFingers2.jpg
I also got some NOS "82C55s". These are from Harris. I can confirm they also require the 4K7 pull-down resistors (as was discussed here a while ago). 10k was also too weak for my batch.
And concerning the ATmega328: it was indeed hard to obtain for a while - at least at reasonable prices. It was affected by the chip shortage. That seems to have cleared up though. The 328 was recently relisted by several distributors and online shops (at least here in Germany), which hadn't been able to provide any at all for the last two years. Prices have also dropped fast. My favourite shop now offers it for 2,65€. I had ordered a few for my new PCBs. They have a date codes "2306" (June 2023). Clearly Microchip is finally distributing fresh supplies...
THe fuse.cfg file is indeed used by the Minipro TL866 programmer. That's what I use.
I see what you mean about the 'classic' looks, however the original routing isn't very 'old school' and the micro-sd card slots are SMD anyway, that was my reason to just bite the bullet and convert it. Also, the prime advantage is that I get them completely assembled, as well as with a considerably bigger MCU (twice the flash, twice the SRAM, tons of spare pins!)
I told myself i'd make that one work, then perhaps I'd hack the firmware seriously to get rid of the arduino dependency. There is zero reason that the UART should take more than a few bytes to run. the SPI is also a good candidate for simplification, and as far as ethernet goes, well I have a enc28j60 driver for AVR kicking around the disk somewhere for years, so that could be a good option too...
FYI I know my way around an avr quite a bit, I'm the author of simavr https://github.com/buserror/simavr
Note that ENIG is not the traditional gold plating used on edge connectors. It is an immersion coating meant to protect the solderability of circuit boards that may be stored for some time. It is not particularly hard or durable and will not withstand repeated insertions.
Edge connectors are traditionally electroplated with "hard gold", a surface treatment that won't scratch or wear off. This is applied by hand to each connector and increases costs substantially. ENIG is typically free or close to free.
They are also always chamfered because it is required to prevent damage to the mating connector.
One of the two original Dan ][ Controllers that I made shortly after it was released must have been inserted into various slots a thousand times by now. It has not sustained any damage, neither has caused damage to any of the slots of the 3 Apple II machines that I own. Actually the way the slots are made, it’s impossible for it to cause damage.
So looks and possibly slightly easier to insert is the only advantage that chamfering and gold plating provides.
I like chamfering, but yeah, on an Apple II the slot will be fine. I did notice the main difference when I had a non chamfered vs chamfered card of the same design is that the fingers near the edge of the non chamfered board looked to be taking a fair amount more wear.
I understand the disadvantage of ENIG vs true hard gold edge connector, but is HASL really any better than ENIG at that point if you're not doing hard gold?
The tin coating from a HASL step is a lot thicker and won't wear through, so in that sense it is better. The problem is that tin in contact with gold plated contacts in the mating connector can produce intermetallic corrosion. It's best to always have the same metal plating on both sides of an electrical contact, so there is no electrochemical cell created when moisture is present.
The same applies to SIMM memory sockets and DIP sockets. In a low-moisture environment it doesn't matter, but matching the plating metal will prevent corrosion even in a humid storage environment.
On my machines only the Apple II+ slots appear to be gold plated. The slots of my Apple IIe are certainly not.
Arrived! Well a bit early in fact; so early I haven't received my eeproms, and I'm out of them -- might program a 27c64 to get going! Boards look good, wave soldering is impecable. I had report that thru hole at jlpcb could be a bit off, but I have to say, it looks perfect to me..
Sorry for the crap photo. The phone makes huge megapixel pile of dross, I'll post a better one later, once I've tried to program the thing :-)
IMG_20230814_103226-EDIT.jpg
So a bit of a painful board bringup here. Managed to program the m644p, that worked (second time... first time verify failed, odd!) -- I then programed the fuses (which I calculated have in fact the exact same value as the 328p!) and... stuck AVR. The card 'boot' to the ROM prompt then just hangs, as expected.
Turns out, idiot me, I used the wrong footprint for the 16Mhz crystal. Doh; so I removed the SMT one and bodged in a pin one on the same pads -- I expected it to unstuck itself and... nope! Still stuck, can't talk to it via avrdude anymore. I'm *sure* I haven't disabled the ISP fuse, and the fuse programing was 'sucess'. Next I'll have to hook up a signal generator on X1 and see of any sort of clock might bring it out of sleep.
Also, I was not able to even talk the the AVR with the board outside the A2, seems the reset line is pulled low by 'something' that prevents it booting/programming... My next revision will definitely have an extra jumper to isolate reset!
Anyway, unfortunately didn't have a lot of time to play with it today, perhaps tomorrow afternoon!
Damn. Sorry to hear of the issues... but hopeful that you will be able to resolve them!
So a bit more progress, and at least part of an explanation!
Turns out the reason you can't have a SD card in when programing the AVR is that... the CS lines are pulled *down* but, CS is *also* active low, so both cards will be trying to interpret commands when programming the AVR (and jiggling MISO!). So these pulled down should be pull *up*. Also, why is there pulldown on MISO/MOSI I can't figure out either, I'm going to remove these as well.
And of course you don't need pull down on MOSI/MISO/SCK if the CS line is not pulled "Active" unless it's in use, so all of these are going to the bin.
Also, what's R20? Seems to pull down on VCC for no particular reasons?
Also, we're missing a pullup on the RESET line of the AVR * at least * when programming via ISP.
These problems migth be related to the programmers I'm using (USBASP) but really, /theorically/ you could program that AVR with just the ISP/PWR jumper on with the board on the table, and that shoudl work even at VCC=3.3V!
The pull-down resistors on the CS and MISO/MOSI lines you noticed are not "pull-downs". They are each part of a voltage divider. The ATMEGA outputs 5V level signals. The SD card expects 3.3V inputs. The 470/1000 Ohm and 4k7/10k resistor pairs each form a voltage divider, which reduces the signal level for the SD cards. If the ATMEGA is in reset and outputs nothing, then indeed the voltage dividers turn into pull-downs. But you cannot use a pull-up resistor to form a voltage divider. And SD cards could be damaged if you just removed the voltage dividers and connected the 5V signals to the SD cards directly.
You could use proper level shifters to convert the signals for the SD cards - and then use a pull-up on the ATMEGA side (level-shifter input). But the resistor dividers are a "poor man's voltage shifter". Indeed the downside of the cheap solution is that no SD cards must be plugged when using the ICSP connection to program the device. Dan actually mentioned that in his description. But it's not really a major limitation.
R20 was probably meant to slightly load D7 and cause a slight voltage drop. But Dan would need to comment on this. I wasn't completely sure about the intention of the JP5 jumper - and in which cases it should be open or closed (to bypass D7).
Your PCB otherwise looks good. Did you solder the through-hole components manually, or were these also done by the PCB manufacturer?
Oh I understand the voltage divider idea, however you can easily use the AVR open drain output and pull them up to 3.3V externaly if there is a worry. Seems everyone has been doing that OR driving 5V SPI into them without any trouble whatsover for the last 10+ years.
Yes thru hole were wave soldered, and really, I'm pretty sure I wouldn't do anything better than that my hand! the board finish is impecable. So far the only mistake is mine, the crystal footprint!
More tomorrow, I don't have a hell of a lot of time to play during the week, unfortunately :-)
Thanks for all y'all's work on this! Good things just keep getting better. It will be awesome to be able to order a nearly assembled card. And all the software work that has been done on this recently including the Apple /// drivers make it even more of an awesome card.
Yeah R20 is intended to present a minimum load on D7 so that the voltage drop is not too small. Same with R11,R12.
I would mention that D7 is there so that if it is not jumpered over, it adjusts the high/low logic levels of the AVR to be intermediate between the SD card and the 82C55A and so acts as a "level shifter."
Because the Apple II power supply is not that powerful and many will have other cards present that can consume quite a bit of current, I tried to keep the current consumption minimized but have enough load so that transitions would happen fast enough. That's why there's 4k7/10k on the chip select lines which generally don't need to change quickly and 470/1k on the MOSI/SCK which are clocked quickly.
Another goal was to keep the BOM as simple as possible so that it would be possible to assemble say, 10 years from now. When Apple ][s are over 50 years old.
I've been crushed by getting my other project the RFBitBanger delivered, for those interested, here's a link to it at the Open Research Institute:
https://www.openresearch.institute/2023/08/08/rfbitbanger-kit-defcon31-show-special/
It's a ham radio designed to be built out of basic junkbox components and communicate hundreds to thousands of km.
Ok, thanks. I wasn't sure if the diode was inteded as a voltage dropper, or just as a precaution to prevent power from "reversing" to the 82C55 side, when power was supplied during programming through the ICSP connector. So the idea was to keep J5 always open in normal operation - not just during programming? In which cases would you suggest to close J5 (= what is the purpose of J5)?
I leave J5 closed, but I added the diode just in case there were issues with voltage levels communicating with the SD card, and to isolate the power from the rest of the computer, so if there is a problem communicating with the SD card you can open J5. Happily, I have never encountered any problems.
Well it's getting somewhere! I wanted to be able to at least reliably program the AVR, so I removed a few bits; R20, R4, D2, D7, and I added a 10K between VCC and reset, so it is 'up' even if the board +5V isn't there (board on the table). What that does is effectively decouple the AVR from the rest of the card when the PWR jumper is not there, so I can program it on the table with just the ISP PWR jumper on, then I can put that jumper back on the +5V of the card.
That programmed, but I got stuck after programming the fuse. Turns out my bodged 16mhz crystal doesn't need the 20pf caps, took me a while to figure this out but poof at least I could see the bootloader and firmware probing the CS with blinking LEDs ...
Still, it didn't go further and hung, so I went again over the pin mapping with a fine comb, and yes, turns out I needed some extra changes, as I had moved 2 pins to free the i2c pins. Also, loads of hard coded access to the SPI pins, while they are on different PORTX on the 644..
So now the card starts, which is excellent, and it loads the boot program, which is excellenter! *however* it locks up if there's a card in the slot, which sucks. I *suspect* still the SPI divider resistor network, which I kept.
So I just have to debug that SPI and we're on!
I made some further changes/cleanups to the software, mostly to define constants for pin numbers and such. Nothing 'functional' so far...
So not a lot of progress in terms of getting it working, but I've reduced the scope of the problem. I've assembled another board, with with the proper crystal it behaves the same as the other one -- ie boots to the menu if there's no card, but fails if there's one.
That validate the firmware running, the bridge talks to the AVR as it displays the menu. I've triple checked the board, triple checked the footprint of the SD card, and checks out. I've validated that the CS line comes to ~3.4V too. I think I'm now down to soldering a few little wires and attach the logic analyzer as the 'deducing' phase is done :-) -- I also triple checked (with a comb) the code for pin mapping this time (I've got a few changes to push related to that)...
Oh I also managed to program the AVR via the DANIITOOL! Of course *this* version programs the wrong firmware (328p) so fails, however, it DID program, which is another checkbox ticked...
I'm using 2*4GB class 4 cards, formated DOS partition map + 1 partition FAT32 (using gparted)
As I said, next is the logic trace, I wonder what's going on with that SPI interface...
You may want to shrink the firmware to the bare minimum for the initial tests - and disable Ethernet+FTP+FAT support:
Dan2Config.png
This removes some complexity and shrinks the firmware to mere 5KB. And if something wasn't working right with the SPI bus, the AVR might indeed get stuck somewhere deep inside the Ethernet drivers, or somewhere inside the jungle of the FAT file system driver. The raw block access is pretty straight forward. Much easier for debugging if your fighting with basic hardware issues.
Class 4 cards work fine. Class 10 cards are not much more expensive though - but they provide significantly better performance in the DAN][ card. I recently noticed my class 10 cards were about 3x faster than the cheap class 4 cards I had. And the performance difference was very noticable (like "A2Desktop" booting in 10 seconds vs 30 seconds). So saving a buck on the cheapest SD cards may not be worth it.
Are you sure it's the class of the card and not just a very large file allocation table due to lots of deleted files? Have you tried reformatting the class 4 card that takes 30 seconds and putting only a few files on it?
Yes. Initially I incorrectly thought the speed difference was due to FAT vs RAW mode (since I had a volume on a class 4 as a FAT disk, which was slow - and another class 10 card used in RAW mode, which was fast). But eventually I narrowed it down to the card itself. So my class 4 cards were just as slow in RAW mode - without any file system at all. There is also a slight performance advantage for RAW vs FAT mode, but this didn't matter much.
"class 4" means at least 4MB/s - and apparently the cheapest ones just barely meet this spec. "class 10" means at least 10MB/s - so the performance gain probably isn't that surprising. 4MB/s may already sound great for a 6502 system. But the ATmega doesn't do any DMA or use parallel threads. It just reads everything on demand - waits for complete blocks to be received, then forwards these to the 6502. So cards with really slow read/response times still have a significant effect.
Thanks @MacFly for the suggestion for a 'lean' firmware I'll try that next! I've took out some class 10 from the SD card drawer and it behaves the same, so at least that's ruled out.
BTW any of you guys hang out on IRC/Discord?
So a bit of progress here -- I ruled out any electrical problems now; I have the logic analyzer on the SPI/CS lines, and it shows the card being talked to; it shows the basic ID going fine, the speed being set to 'fast' and blocks being read (I see the partition map). I'm continuing to trace the transfer to see where it get stuck at!
I'm on a couple of different Discord channels :
Chesh
Small update -- my (clone) Salae probes packed up somehow (cause unknown) so I ordered another thing (Hantek 6022BL), however I since picked a foot injury so I I've had to play a bit of catchup on other things!
Last traces I saw were interesting, as it was definitely reading blocks. I could see the partition map being read etc -- not too much as it's already a lot of traces -- however it seems to have been going thru the motions..
I've re-purposed CS3 LED as a 'watchdog' LED, and it seems to be locking up during the filesystem probing. However I can't confirm that without a probe...
Did you try to isolate on the firmware side where it gets stuck? Does it get stuck during the SD card initialization? In the MMC low-level driver, or in the FAT FS code? Or does the SD card access work, but it gets stuck during the block transfer, when communicating with the 6502? The protocol between the ATmega and the 6502 (via the 8255) is absolutely strict: there are no timeouts etc. Each transfer has to work, and both sides have to strictly follow the protocol (sending vs receiving commands & data bytes). If there was any (software or hardware) issue, e.g. a lost trigger to the 8255, then both sides will get stuck forever.
So, unless you have already done that, it might be worth first narrowing it down from the software side, by adding some instrumentation to the code (debug output via RS232, LED signals etc). So then you know where in the code it actually does get stuck. And then you know whether it's worth probing the SPI bus at all. Or whether you need to look at the parallel CPU-to-CPU interface (8255), for example.
(And speedy recovery to your foot! :) )
Another thing I'll mention is that the ATMEGA can be too fast for the 82C55 and you might have to add some software waits. What happens is that the 82C55 will not change the IBFA/OBFA bits fast enough and you will get an answer that makes it look like the transfer has already completed. If you look at the macros I made
/* Needed to slow down data send for 82C55 */
#define ACK_LOW() do { ACK_LOW_SINGLE(); ACK_LOW_SINGLE(); ACK_LOW_SINGLE(); ACK_LOW_SINGLE(); ACK_LOW_SINGLE(); } while (0)
#define ACK_HIGH() do { ACK_HIGH_SINGLE(); } while (0)
#define STB_LOW() do { STB_LOW_SINGLE(); STB_LOW_SINGLE(); STB_LOW_SINGLE(); STB_LOW_SINGLE(); STB_LOW_SINGLE(); } while (0)
#define STB_HIGH() do { STB_HIGH_SINGLE(); } while (0)
You'll see that I had to add some waits. These waits have to be volatile reads or writes or the compiler will optimize them away.
You could try to add a bunch more ACK_LOW_SINGLE() to ACK_LOW() and STB_LOW_SINGLE() to STB_LOW() to see if that helps.
You may be on to something for the different ATMEGA chip used in this new design. I think it is signifiantly faster than the old one. It may need increased delays in order to work right.
Thanks for all the suggestions guys, it *appears* to be an hardware problem after all... Took me a while to figure this one out but...
So if I *power cycle* the IIe, without any cards, I see the CS LED blink (as intended) and the IIe boot to the menu -- I can type return twice and it 'sets' and return OK! -- also, I can tell the AVR has booted successfuly as I toggle CS3 in the main loop() and it's blinking happily when getting commands from the 'menu'...
However, if I control-apple-reset, it blinks CS/CS1 together a couple of times, then nothing... it never initializes, and the menu never appears...
So there seems to be a reset condition problem. I used the scope to have a look at the reset line for the AVR, and it's behaving more or less as I'd expect...
This is odd, because I would expect to have problem *the other way around* as the rail might not be ready on a power-cycle, while for a warm reset, all is already ready....
I tried adding cycles to the STB toggle BTW, but it doesn't make a difference (apart from making the 'menu' slower to load non-existing filenames)...
This is quite bizare. I have also disabled the brownout detector, just in case there was a dip in power on reset, even if the scope doesn't show anything really...
Is it possible the Apple boot rom is probing the bus for a disk controller faster after a warm start than after a cold start? Maybe the AVR isn't ready to respond by the time the computer has discovered the e/eprom code and is trying to execute there.
Pages