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.
@profdc9,
Regarding: " If you're going to add the Ethernet board like I show in the picture, do not populate R27/R28. This is because I have a special "outboard" I have been working on which places the SD card slots on the outside of the computer "
OK, I get that, or at least part of it. Your photo in this thread above shows your board with these 2 resistors missing with the Ethernet board attached.
But you go on to say: " ... because I have a special "outboard" I have been working on which places the SD card slots on the outside of the computer "
The SD Card slots are already mounted on the inside edge of the Version 1.1 board. What happens to those? I don't see any correlation with those 2 resistors (R27, R28) to the SD Card slots at all, but to J6 where the Ethernet board attaches. (photo below)
Am I missing something?
J6_Dan][.png
I also see you are working on a different version of the board with the SD Slots on top of the board, rather on the forward edge.
Are we talking a different board from Version 1.1?
Looking at the source code for the arduino side, you have the FF_FS_TINY set to one, so shared buffers, with this already being there how much extra ram would be needed to just have 2 files on the slot 1 mounted as the 2 drives, instead of relying on 2 sd cards?
I got my ethernet module in this week, updated the hex in my atmega, and was on the net in no time.
Anyone have a stl to mount these modules somewhere?
Thanks!
Ok, more news...
I just added a program to the github called "allvols.bin" which is a ProDOS System program. What it does is use the unused slots and drives to populate extra 32 MB volumes that are on block devices (0 or ! type devices). There's a selection for slot 1 as the block device, slot 2 as the block device, or both (option 3) when you choose ! for slot 1. This will point all of the extra slots and drives to more extra volumes on the SD card.
If you unzip BlankVols.zip you get a 512 MB volume that you can use a program like Win32DiskWriter to write to a SD card. This writes 16 volumes which are named SxDx. When you boot, only the slot in which the Dan ][ controller is will have volumes associated with it, but after you execute allvols.bin, you will get access to other 32 MB volumes on the SD card. You can have up to 14 32 MB volumes if all of the slots and drivers are dedicate the a single SD card.
Dan
R27/R28 are only used by the external outboard to provide the chip select lines if the SD cards are mounted externally. If the SD cards are mounted internally, R27/R28 should be omitted, because otherwise the CS/CS2 signals may interfere with the operation of the W5500 if the signals from CS/CS2 remain connected.
If you use the outboard to make the slots external, CS/CS2 don't reach the W5500 and don't interfere with it.
I haven't really worked on the outboard a lot yet but it would allow the sd card slots to be mounted externally, but I have already have some of the PCBs built.
I think I would like to write a ftp server for ip65, because it would be very handy to transfer data to/from the Apple. I already wrote one for a microcontroller years ago, so I think it shouldn't be that hard.
Dan
When I first started following this thread, I thought YASDDE (Yet Another SD Disk Emulator) - Yawn. But, now I see this is shaping up nicely with lots of interesting features. Good Work! Keep it up.
What do you think about this:
https://www.mouser.com/ProductDetail/WIZnet/W5500-Ethernet-Shield
Would that work with the A2Shield card similarly to the Dan ][ SD card with the W5500 ?
I get a "can not find web page you are looking for" when accessing the link. But its likely it would not work, at least without modification, because the chip select line used for the W5500 is not the default chip select line for the ATMEGA328P.
There is something I am missing to make raw block mode work. I can copy the files to a FAT-formatted SD card and they boot fine.
If I write Blankvols.po (512m) to the same card with Win32DiskImager, then open the volume with CiderPress and write the same files to the partitions, it won't boot. I just get "Unable to load ProDOS". What step am I missing?
Nevermind... I see where I have made my mistake. CiderPress does not show the volumes in order starting from S7D1.... Whoops.
I do still have a problem where I can't make any other partitions show up in GSOS. I can run allvols.bin, it says it added them, then it appears to reset GSOS, but no new drives appear? Is there some way to run allvols.bin before GSOS starts up, or force a rescan?
Also, could you explain the "!" wide block mode a little better? How do we access those partitions from a PC?
Hello,
I designed a 3D printable holder for the PCB for the Ethernet Jack that allows it to be mounted on the back of an Apple ][+ or //e. It mounts with the hole spacing the same size as a DB-25 connector.
The board slips into the holder and it held in place by a screw and nut. Then screws are inserted through the holes from inside the Apple ][. Washers may need to be used to provide a large enough surface to hold the screw captive on the inside.
You can find the holder STL file here:
https://github.com/profdc9/Apple2Card/tree/main/CAD
Here is a picture of the holder with the board in it:
Ethernet-Mount-Front.jpg
Ethernet-Mount-Back.jpg
The method I use to add the slots and drives may work for ProDOS 8 only, as it directly writes to the table of devices in the ProDOS page at $BF10 to $BF3F. This probably doesn't work for GSOS, and I don't have an Apple ][gs to figure out how to do the same trick for GSOS.
The "!" directs both Prodos Drive 1 and Drive 2 to the SD Card Slot 1, so that you can host up to fourteen 32 MB volumes from a single SD card. I intended it so that if one wanted to host a large amount of storage (like say for a BBS) from ProDOS, 14 X 32 MB of space could be made available. Unfortunately CiderPress doesn't support more than addressing 8 volumes on a SD card (as I don't think CFFA3000 does) so it would have to be modified to work with this mode.
I was able to modify/customize makevols.bat to copy some existing 32M images as the D2 drives for the wide mode. I assume the default boot mode is "!" since S7D2 does show up in GSOS by default. No other partitions do, though. It would be nice to figure out how to make them appear in GSOS.
It should be possible, if the card is in slot 7, to have both slot 7 drive 1 and slot 7 drive 2 function in GSOS the same as it would in ProDOS 8. What is not supported is overriding any of the other slots with additional volumes. It may be also possible to add SmartPort support in the future, however, I need to read up on how to do this. The "allvols.bin" is a hack that works for ProDOS 8.
I don't have an Apple ][gs, but I was curious as to how the performance is of the Dan ][ controller with the Apple ][gs. There are seven 6502 instructions in the main loop that reads bytes from the 82c55A, and I was wondering how fast that executes at 2.8 MHz. It might be possible to reduce that to four (getting rid of the byte read check) but it's a bit risky I think.
Do you have a benchmark you would like to have me run on a ][gs?
Not really, I just wanted to know if it was fast enough to be practically usable on the ][gs without being too slow. Competitive with, for example, using a SCSI hard disk like those that might have been used at the time the ][gs was produced. But if there's any benchmarks if you think would be useful that might be helpful.
I found one called StressProDOSFileSystem_003.zip on Asimov.
I ran it on my ][gs only, (It won't run on my ][e, it says clock not found, I have no clock card for it.)
apple2speed.jpg
I would be happy to benchmark one of these in a IIgs when I get around to building one. It's on my list of projects most likely for when I do a PCB fabrication order next. I have a SCSI card and MicroDrive Turbo, and floppyEMU as well all of which I could compare to this card.
Here are the results using a .po mounted on my CFFA3000.
apple2speed-cffa3000.jpg
I'm guessing that based on your benchmark results that the Dan ][ is pretty slow in GS/OS. I am surprised that fast/slow didn't make that much of a difference. Perhaps the execution of code from the ROM slows it down too much. It might be possible to improve the speed 50% or so, but since the 6502 handles transfering the data a byte at a time, at least three or four instructions are needed to transfer each byte, so we're probably talking 80-100 kb/sec maximum. I'm just afraid to take out readiness checks in the code that could result in corrupted data.
These are the loops that could benefit the most from optimization:
readbytes:
lda $BFFA,x ; wait until there's a byte available
and #$20
beq readbytes
lda $BFF8,x ; get the byte
sta (buflo),y ; store in the buffer
iny
bne readbytes ; get next byte to 256 bytes
writebytes:
lda (buflo),y ; write a byte to the Arduino
sta $BFF8,x
waitwrite:
lda $BFFA,x ; wait until its received
bpl waitwrite
iny
bne writebytes
It might be possible to not worry about the "double read" problem on the 6502, but I would be worried that it would falsely trigger the 82C55A flag so that the AVR would send another byte before the Apple ][ read it, so I have avoided this. The price of avoiding a double read is an extra cycle. The double read issue is why I base the reads from page $BFFx, so that the extra read happens in page $BFxx rather than $C0xx. I could also get rid of the checks completely:
readbytes:
lda $BFF8,x ; get the byte
sta (buflo),y ; store in the buffer
iny
bne readbytes ; get next byte to 256 bytes
writebytes:
lda (buflo),y ; write a byte to the Arduino
sta $BFF8,x
waitwrite:
iny
bne writebytes
which would save almost thalf the cycles in the loop, but would then require the AVR to never miss a byte. It would be painful if there were intermittent failures and data losses, so I've just avoided this and lived with the check for each byte.
I'll probably leave it as it is, but it would be possible to disable interrupts on the AVR and remove the checks in the Apple ][ and see what happens...
Here's my quick and dirty #12 opening 3d bracket for the wiznet module.
rear.jpg
internal.jpg
Good job! Along the same lines of what I plan to do.
Finally got my 2 boards finished and programmed as well.
160MB... The hard way.. :)
IMG_20220821_213027100.jpg
Why did you leave the one card in? You could have had 192 MB :)
I only had 5 cards...
So, if anyone wants one, I have 2 extra, fully built and tested with ethernet module and 3d printed mount $70 + shipping.
I sold one of the cards I built to a Apple ][+ owner. He returned it, with the following reports.;
I got the card back, and it's still working fine in my ][e and ][gs. Has anyone else tried these in a ][+?
I have an Apple ][+ with 64K and was able to use it ok with several other cards in the computer. Did the user try to remove other cards to see if that helped? Which version of ProDOS was used?
Also, jumper JP5 can be closed to provide a full 5 volts to the Arduino. If there's a difference in power supply and the voltage is sagging, this may help.
Did you use 74LS or 74HCT for the two small chips? I've heard some horror stories of new chips marked 74LS actaully being CMOS 74HC, which are not compatible with the TTL levels, unlike the 74HCT series.
I can now confirm that the card works perfectly on Apple II+ with 16K card, Apple IIe and on Pravetz 82 with 16K card, which is a bulgarian Apple II+ clone. Also I want to thank Dan for designing such an amazing card! I didn't realize how awesome it was until I got it to work. A bunch of us from this bulgarian forum assembled the card and tested it on various Pravetz machines - you can find more constructive criticism there and some interesting substitutions with old soviet chips: click, then right-click to translate to English.
Also I would like to suggest adding to the instructions in GitHub that 8 GB (and larger) SD cards can be formatted in Windows using FAT32 and they will also work perfectly. I was initially left with the incorrect impression that only FAT16 is supported.
Here is a picture of my Apple IIe with only the Dan ][ Controller in it:
Apple IIe.JPG
I updated the github with the information about SD and SDHC cards and FAT32 being acceptable. I also added some detail about the new ALLVOLS.SYSTEM program which enables up to 14 32 MB volumes to be used in ProDOS 8.
By the way, the reason I have two SD card slots rather than one is so that the Apple II can be used to copy between two cards. For me it wasn't so important to make the Dan ][ as small as possible or as cheap as possible, but to make something easily reproduced, and the SD slots from lcsc.com are 0.20-0.25 USD a piece or so, so I figured it was a good addition. I tend to err on the side of adding too much rather than too little, which you can see from all of the headers I added. Also being a bit bigger allows me to run most of the traces on the back side of the card, leaving the front side mostly connected ground, which helps with RFI.
Thanks for the update!
Btw, there isn't really a 32 GB limit. You can use much larger SD cards, as long as they are formatted in FAT32. I just tried a 256 GB SD card and it worked perfectly. The problem is that Windows will not give the option to format in FAT32 for cards larger than 32 GB, so you need to use another program like FAT32 Format.
I am curious: what is the limitation that prevents both SD slots to be used in FAT/FAT32 mode? I totally understand the idea behind raw block mode, but I think it's more advanced and way less user friendly to set up. Also in my opinion the killer apps for this card are collections like Total Replay and Instant Replay that can simply be dropped into the root of any FAT32 formatted SD card. This is why it would be nice if both SD slots can work in FAT mode. I tried copying Total Replay from slot 2 in FAT mode to one of the raw volumes in slot 1 on an Apple II+. It took a couple of hours to copy and at the end it failed to run. Instant Replay is much smaller and I was able to copy it and run it, but it still took a while to copy.
InstantReplay.jpg
There is not enough SRAM in the ATMEGA328P to have two FAT filesystems open at the same time. A FAT FS requires about 520 bytes of SRAM. It's possible that by modifying the FAT FS code, I might be able to get rid of a buffer and free enough space to have two FAT FS.
A newer AVR with more SRAM would probably be able to do two FAT FS without modification. The AVR128DB28/I-SP is DIP28 but has an incompatible pinout. A lot of improvements are possible, I chose the ATMEGA328P because it's super common and would be easy for someone to assemble.
A 32 MB volume needs to be copied to the correct place on the card to be seen by the card when it is a certain slot and drive. Maybe I should change this, but the purpose is to allow up to 512 MB of data to be addressable on a single card.
The order the volumes are laid out in a card are for standard block mode is
Slot 0, Slot 1, Slot 2, Slot 3, Slot 4, Slot 5, Slot 6, Slot 7
And for both volumes block mode (!)
Slot 0 Drive 1, Slot 1 Drive 1, Slot 2 Drive 1, Slot 3 Drive 1, Slot 4 Drive 1, Slot 5 Drive 1, Slot 6 Drive 1, Slot 7 Drive 1, Slot 0 Drive 2, Slot 1 Drive 2, Slot 2 Drive 2, Slot 3 Drive 2, Slot 4 Drive 2, Slot 5 Drive 2, Slot 6 Drive 2, Slot 7 Drive 2
Each volume is 65536 blocks long. These are laid out consecutively, so that for Slot 1 Drive 1, the volume start at block 65536.
I use the "cat" command under linux or some simple batch commands under Windows to assemble these volumes by concatenating the files.
Dual FAT system support, but only without USE_ETHERNET will also be a good compromise I think.
Ethernet doesn't really take up much RAM because I wrote it so that the AVR doesn't need to even hold the packet in RAM that it is send/receiving, so there's no real benefit to removing it.
I could have two volumes that are on one FAT FS on the same SD card, but not two separate FAT filesystems on two SD cards as each FAT FS uses about 520 bytes of RAM. It might be possible to do some surgery on the Arduino libraries to squeeze it in, but I have already spent significant time examining the memory map of the sketch.
This is why when copying between two cards, one may can be a FAT FS, but the other one can not be.
Can it be switched to Petit FAT?
There is an Arduino port of Petit FAT: https://github.com/Master811129/PF
It's available in the Arduino library manager, just search for "petit" or "PF".
But no idea about differences and disadvantages.
Winter is coming - time to prepare for new indoor projects. I now also ordered a PCB for this card...
Minor side note: I did adapt the silkscreen for mine a bit. I always prefer to have the component values directly on the PCB. I find this a lot easier when soldering: no separate schematics or component list required, all you need to know is directly printed on the PCB. I place the component values right below the components:
Apple2Card_newSilk2b.png
After soldering, the values get blocked by the components on top - but then it no longer matters (and you can see the values on the components itself).
And I place the component references (R17, C21, etc) next to the components - so these remain visible, even after soldering. This helps with troubleshooting, when you need to work with the schematics and look for a specific component on the PCB (or vice versa).
Apple2Card_newSilk1b.png
Unfortunately, that's not the default setting in KiCad. But of course, it's also a matter a personal taste and aesthetics...
Anyway, that's all the nit-picking I have. Can't wait for my batch to arrive... :-)
This will probably work. The main disadvantage I see looking at the code is that it could be significantly slower, as it rereads sectors constantly (look at the get_fat function). This is to avoid having to buffer a single sector, because the Petit FS works by building up an individual sector from parts. This is really efficient with memory but requires the sector to be reread every time a new FAT entry is loaded. It might be too slow to be usable.
There's usually always a drawback when using a resource-restricted library...
Maybe another option: does the current module allow to switch the mapping of the SPI I/O pins for the SD card at run-time? The question is whether you could get away with using a single instance of the driver for both SD cards. Avoids the need to two instances with two separate buffers in RAM. You would just need one buffer and an extra flag to remember which SD card is currently active. And you would need some smart logic to switch the volume access (flush write buffer, invalidate read buffer, the switch SPI pins when the Apple II requests access to the other volume).
That would not affect the speed when the Apple II was accessing a single drive only. It would probably slow down the case where the Apple II copied data from one SD card to the other - but that's probably not the main use case which mattered. Just thinking out loud here...
Or maybe have both FATFS instances share the same 512 byte buffer?
typedef struct {...BYTE win[FF_MAX_SS]; /* Disk access window for Directory, FAT (and file data at tiny cfg) */} FATFS;This could probably work. I looked at the FATFS code and it seems like it could be modified to use one buffer and keep track of the last filesystem that used the buffer. I might give this a try, but I won't have time for a while. It's a good idea though.
I tried it, but I seem to be missing something. You can see the changes with WinMerge, if you have some time to take a look and give me a hand.
I've started building this card, but don't have the full Arduino experience to decipher Dan's instructions on programming the ATmega.
On the site he indicates that you should flash "the boot loader" onto an ATMega "without a boot loader", and then that the sketch (I'm assuming this is Apple2Arduino.ino?) should be uploaded using a programmer.
He then mentions that the FLASH.SYSTEM can "flash the firmware to the 28c256" on here, but in his docs he says it's used to flash the ATMega, not the 28c256.
I have several EPROM/FLASH programmers and a Pololu AVR programmer, but am naively unclear here on the process. Can anyone clarify?
Does FLASH.SYSTEM look for a file? If so, does it look for the sketch for the ATMega or the FIRMWARE.BIN that goes on the 28c256?
Should I have perhaps gotten the ATMega328P variant with the boot loader already on it, and then simply use my AVR programmer via the ICSP port to flash the Apple2Arduino sketch, and then flash the 28c256 like normal?
Apologies if this is simple stuff - I recently built the RetroChipTester from 8bit.de with no issue and flashed it, but a little confused on the two levels of firmware on this card as I'm just getting to understand Arduino. Appreciate any clarity.
I described how I burned the bootloader on my empty ATMEGA328P using an Arduino Uno as a programmer here: click (To see the images in high resolution use the direct link).
Once I have a bootloader, the easiest way for me to program is just move the ATMEGA328P chip to the Arduino Uno board and then put it back on the card.
I used FLASH.SYSTEM to program an empty 28C256 flash chip with every single jumper closed, but I don't know if it actually programed the ATMEGA328P as well. The instructions on GitHub are unclear on that.
Thanks. I think that's what threw me. The Github instructions seem to imply that FLASH.SYSTEM programs the ATMega, but looking at how he assembles the file by copying the FIRMWARE.BIN to the end of it, I don't see how that would happen, but maybe I'm missing something.
Also unclear on how the ICSP works with the card itself - since programming defaults with the external crystal, I'd imagine the board itself needs to be powered, I.E. inside an Apple2 if using that route for programming?
Not to criticize Dan - this is great work - but he mentioned making this easy for anyone to build. A little help in the docs would go miles as far as this part of things. Only vaguely familiar with the AVR fuses, sketch and boot loader process, and sounds easy to frustratingly screw up.
Also would be great if the BOM/component list was added to the GitHub repo instead of residing here on AF..
You don't really need the BOM in GitHub, it can be generated in KiCAD from the Tools menu.
Otherwise yes, with the card connected to the Arduino board like this with JP1 and JP5 closed and all the other jumpers opened, it gets powered by the Arduino boards itself and it can be programmmed. Both microSD slots must be emprty though.
ArduinoProgrammer.JPG
The FLASH.SYSTEM program does not flash the AVR, only the 28C256 ROM. I use the ATTINYUSB programmer myself, but any programmer including the Arduino ISP will work as well. Remove the card from the Apple ][ when programming the AVR. The easiest way to get the fuses right is to first program the standard Arduino bootloader, and then overwrite this with the firmware without the bootloader. It needs the fuses in the standard configuration for Arduino, which is programmed when the bootloader is programmed, but does not need the bootloader itself in flash, only the firmware, so overwrite the bootloader with the firmware.
I will take a look at the FAT FS to see if I can modify it to reuse the same buffer. However, I am going to be pretty busy for the next few weeks.
Pages