The Dan ][ SD card disk controller

Thanks for this clarity. @profdc9: You may want to update your documentation on GitHub then, as I quote from your readme.md:

"There is a program called FLASH.SYSTEM which can flash the ATMEGA328P on the board."

This is what threw me for a loop. 

So, my first "winter project" is finished... well yes, a little early (it's not even cold yet!). :-)

Here's my "DanII Controller" card (with my personal preferences for the silk screen):

DanIICard.jpg

It basically did work "out of the box". The parts are indeed all easy to source. The build is fairly easy. The only thing which might be a slight challenge, unless one was used to working with SMD components, is soldering the two microSD slots. A magnifying glass, a little patience, and lots of flux do help. :) Other than that, it's a really simple build.

I did use an 8K EEPROM (28C64) instead of the 32K (E)EPROM - which is more than big enough (and cheaper and compatible).

Powering and testing the card on the bench (outside the Apple II) made me wonder if the ATMEGA was already alive. Here's a hint what the expected behaviour is: the two drive LEDs for slot1+2 (D9+D1) will faintly glow as soon as the ATMEGA section of the board is powered (these LEDs are connected to resistors of a voltage divider, which makes the LEDs slightly glow, before the ATMEGA is up and actively driving its outputs). Once the ATMEGA boots (runs the project's Arduino code), it will actively drive the outputs and switch off the slot LEDs. So, all is fine when you see the LEDs briefly glow, then switching off soon after powering the card. When these LEDs keep glowing, then the ATMEGA isn't (correctly) programmed yet - or the ATMEAGA is not booting for other reasons.

Eventually I inserted the card into the machine's slot #7 - with an SD card containing "Total Replay" disk (renamed to BLKDEV01.PO). And it did boot straight away. Nice! :)

So, here's a question I have. Might be a dumb question and I may be missing something obvious. When the card is placed in slot #7, so it is bootable and shows the SD card menu, is there a way to tell it to *not* boot from the card - so I could still boot from the "normal" disk drives instead? The card's ROM doesn't seem to have this option, since it will eventually always try to boot from an image on one of the SD cards.

So, what I have done for now is to move the card to another slot (slot #4 in my case). Now the machine still boots as before from a disk drive (or FloppyEmu) by default. But I can boot from the Dan Controller card using the monitor:

CALL -151

*C40DG

(or Cx0DG when the card is in slot x instead).

Of course I could also do it the other way round: normally boot from the card in slot 7, then use the monitor to manually jump to the disk II card's ROM whenever I wanted to boot from a disk drive instead. Depends on what one uses more often. But somehow I had been expecting an option to skip to the next boot ROM. Of course, as we all know, the disk II controller behaves the same - since its boot ROM never gives up waiting for a valid disk in drive 1, no matter what...

Anyway, it's a nice little addition to the Apple II.

Thanks, Dan, for designing this!

No socket for the 8255? You got lucky that it worked out of the box! The first 8255 I tried turned out to be damaged or fake.

Regarding boot skipping or even boot slot selection – I am sure Firmware.asm can be modified to do that.

There is a workaround for Drive ][ though: have the Dan ][ controller in Slot 6 configured to boot from ProDOS and keep the floppy disk controller in Slot 4. If you want to boot from it just run FASTDSK.SYSTEM, which will boot from whatever is in Slot 4. Actually I thought BITSY.BOOT was supposed to let you boot from any slot, but I can never get it to work. It shows me which slots have bootable devices correctly, but when I press a number it just beeps.

Btw, here is the compiled version of the latest Instant Replay (need to hook up a joystick to see all games, otherwise only 15 appear):

Instant Replay.zip

CVT wrote:

No socket for the 8255?

Hahaha, very good! I was wondering if anyone would notice. You caught me cheating with your eagle eyes... If you look even closer at the photo above, you can actually tell there isn't even solder in the througholes around the 8255. It was just sitting there for the photo. When I built the board two weeks ago, I was sure I had everything - and eventually noticed I had run out of 40pin sockets... *sigh* So, I could only test the ATMEGA and the ROM connection separately and had to wait (but I did take the photo...).

Finally completed the board yesterday, when the sockets arrived. Of course, the 8255 is installed properly now... :)

8255.jpg

I knew my 8255 was working though. I bought it more than 30 years ago, when they were still available from trustworthy sources (and long before crooks even invented the concept of sanding and faking such ICs). This 8255 has been sitting unused in my cupboard ever since (I don't think it had any hope left, it would ever be put to good use - much less to be retrofitted in a 6502-based system :) ).

Concerning switching between the boot ROMs: ok, I had a look into patching my card's boot ROM. Obviously Apple/Woz never expected anyone to have more than one card with a boot ROM. The scanner in the F8 ROM is pretty simple: it checks each slot, and if a valid ROM is found, it jumps (yes, it's a "JMP", not a "JSR"). So a boot ROM was never expected to return...

But of course, we can patch something up. Here's what I have done:

bootpatch.png

So, I can now press the ESCAPE key, and it simply uses a fixed jump to return to the autostart ROM, where it continues with checking the next slot. The return address in the F8 ROM ("SLOOP" in the "PWRUP" routine) is valid for the original autostart ROM and AFAICS all later versions (unenhanced, enhanced...). Yes, not pretty to just jump back to the ROM, but it works. So, yay...

I now have my DAN ][ card in slot 7, where it boots by default. But if I press ESC, then the scan continues, finds the disk II boot ROM - and normal disk boot continues.

If anyone else wanted this ESC-key option: I have packed the modified Firmware.asm + Firmware.bin into this ZIP:

FirmwarePatch.zip

MacFly wrote: 

"I now have my DAN ][ card in slot 7, where it boots by default. But if I press ESC, then the scan continues, finds the disk II boot ROM - and normal disk boot continues."

This is the recommended/default behavior with the MicroDrive Turbo, and it's really convenient to be able to skip slot 7 with the escape key. 

I might have to look at getting or making one of these I suppose. Why I feel like I have to own so many disk emulators is beyond me.

MacFly wrote:

So, I can now press the ESCAPE key...

Wow, great job! I already flashed one of my Dan ][ controllers and I can confirm that it works perfectly on Apple ][+. I tested it with the patched Dan ][ controller in slot 6 and:

1.    Disk ][ controller in slot 3.

2.    Second Dan ][ controller in slot 5.

3.    Terence Boldt's ProDOS card in slot 4.

4.    MultiROM card in slot 1 configured to boot in Integer Basic.

5.    CFFA 3000 in slot 2 configured as two SmartPort volumes from its own microSD card and emulating two Disk ][ volumes from its USB port on slot 7.

The last configuration is very interesting, since your patch allows it to sort of sit in the middle the CFFA3000 card. If there is nothing plugged in the USB port of the CFFA3000 card it will go to the Dan ][ Controller, where you can either boot from it or press Escape and boot from the microSD card on the CFFA3000. If however a USB is plugged it will just boot from the USB right away:

20221021_122150.jpg

MacFly wrote:

I knew my 8255 was working though. I bought it more than 30 years ago, when they were still available from trustworthy sources (and long before crooks even invented the concept of sanding and faking such ICs). This 8255 has been sitting unused in my cupboard ever since...

That is hilarious! I usually get them for $1.60 with the delivery from the e-scrapers on AliExpress. Of course you never know what you’ll get until they arrive, but at least they give you a refund right away for all chips that don’t work. The other day though I bought a brand new old stock NEC D8255AC from a Bulgarian electronics store for $3, where it has been sitting for God knows how long! The saleslady told me that their other location has more in stock, but I wasn’t sure is it will work since it’s not the CMOS version. Turned out it works flawlessly, so I combined it with one soviet and one bulgarian 74LS equivalent from the 80s (bottom card):

IMG_5390.JPG

profdc9 wrote:

I like the patch.  Does the jump point $FABA work with all ROM monitors (Autostart ][+, unenhanced ][e, enhanced ][e, and ][gs)?

It does. I tested it with enhanced+unenhanced ROMs. And CVT tested it with the II+.

I don't have a IIgs, but looking at a disassembly of IIgs ROM shows the $FABA entry point is also present and identical to the enhanced IIe ROM.

The enhanced IIe ROM (and the IIgs) actually have a slight modification to this routine. They are only checking the first 4 bytes of the slot ROMs, whereas the original autostart and unenhanced ROMs checked the first 6 bytes. But the slot-loop (SLOOP) location is the same for all of them.

For everyone who lives in Europe, there is a much cheaper alternative for the 8255: https://www.ebay.com/itm/284902793052

This is the soviet KR580VV55A (КР580ВВ55 in cyrillic) - a 1:1 equivalent of the Intel 8255A and there seems to be a very large supply of new old stock for some reason. I got one for 75 cents in Bulgaria and it works perfectly on the Dan ][ Controller. There is also a ukranian version that looks like this, but it’s very rare:

KR580VV55A.jpg

Interesting. Never used a Soviet chip before - they even have "CCCP" on them... The offer of one of the Bulgarian sellers says:

“NOS, Comes Straight from the State Military Surplus”

If these were indeed used in Soviet military equipment, then this explains why eastern European sellers have them on offer.

Current prices for the ATMEGA328p are crazy though. And I guess there's no Soviet alternative for this one... ;-) My preferred online distributor still has them on offer for the normal price, but with an estimated delivery date of October 2023 (yes, 2023)...

MacFly wrote:

Interesting. Never used a Soviet chip before - they even have "CCCP" on them... The offer of one of the Bulgarian sellers says:

“NOS, Comes Straight from the State Militar

Atmega chips are affected by the supply chain issues out of China and Taiwan.  I've had similar issues getting 328P.  Either stupidly long wait times or supidly high prices or both.

No Soviet version of those Atmega because they came out way after the fall of the Iron Curtain and the disollution of the USSR into the mess it is now.  The Soviets and their puppet states cloned a lot of western chips...  the 8255 is not surprising since it was so ubiquitous in both CP/M machines as well as the early PC clones.

I really like the look of the ukrainian version with the two holes and even found one for sale, but unfortunately the seller seems to live in the currently occupied part of Ukraine and cannot ship it internationally: https://www.olx.ua/d/uk/obyavlenie/kr580ik55-kr580vv55a-kr580vi53-IDM990V.html

Otherwise I got my 2 Atmegas without bootstrap from this seller on AliExpress and they arrived in 2 weeks: https://www.aliexpress.com/item/32833490234.html

I didn't have a proper programmer at the time, so I also ended up getting an Arduino Uno with a 328P chip on it: https://www.aliexpress.com/item/1005003120151924.html

They all looked brand new and worked perfectly. I can also get them locally at double the AliExpress price, but I know for sure that's where the local sellers buy them from.

CVT wrote:

I didn't have a proper programmer at the time, so I also ended up getting an Arduino Uno with a 328P chip on it: https://www.aliexpress.com/item/1005003120151924.htm

You have a programmer as soon as you have any working Arduino board. They can all use their ISP connectors as an output. So you just download the programmer sketch ("Arduino as ISP") on to the Arduino , connect its ISP connector to the ISP connector of the target board - and then you can already program the target's bootloader, fuses etc. You can actually also use the DAN card as a programmer - just download the Arduino ISP programmer sketch to the card. But of course, you need one working Arduino board (or ATMEGA with bootloader for the DAN card) first.

The AliExpress sellers do not take care of tax/customs, I guess? I used to order a lot of components from Chinese ebay sellers, until the tax exemption for low-value merchandise was dropped by the EU. Even if the tax is only a few cents for a package, the German post now charges a fixed handling fee of 10€ for each package they have to clear through customs, when that wasn't done by the sender. So now, unfortunately, it's usually cheaper to find local (EU) sellers (who in turn often import the stuff from China in bulk).

MacFly wrote:

You have a programmer as soon as you have any working Arduino board. They can all use their ISP...

I know, I described how to program it using this exact approach in post #100 in the previous page. However when you are first trying to get the card working, the easiest way is to program the Atmega 328P chip that comes with the Arduino board and then move it to the card.

MacFly wrote:

The AliExpress sellers do not take care of tax/customs, I guess?...

Starting last year they made buying from chinese sellers on eBay and AliExpress really simple for EU customers. If the price is under 150 euros you simply pay the 20% VAT to eBay or AliExpress and then it doesn't go through customs, just comes through the mail as if you ordered it from inside the EU and there is no fee.

What you are describing actually happened for a short period right after they dropped the small value tax exemption, before all the sellers got their paperwork together, so that it can go directly through eBay and AliExpress.

After my recent upgrade of my Apple /// with a FloppyEmu, it's become much easier to do experiments and development with the machine. I really hadn't used it much before since reviving it two or three years ago. And here's the next upgrade for my machine: I added a DAN II controller to my Apple ///.

The Apple /// shares the same I/O slot concept as the Apple II. Apple /// only has 4 slots and allows physically bigger cards. Apple II cards do fit nicely (while the other way mostly doesn't work, since Apple /// cards are usually to tall to fit in the slim Apple II).

DAN2vsPROFILE.jpg

The Apple /// does not support boot ROMs on the I/O cards though. So the onboard boot menu of the DAN II controller does not work. It can be invoked manually using the Apple II emulation mode, which requires loading the Apple II emulation disk. But even then it wouldn't work automatically. I had to invoke it manually (enter the monitor in Apple II emulation mode, then call the address of the ROM routine).

Also, a separate driver is required for Apple /// SOS. It didn't yet provide the standard Prodos interface. Robert's Problock3 driver for SOS could work - it's a generic SOS driver for controller cards with Prodos compatible firmware. It didn't work with my DAN II controller though.

I eventually ended up doing two things:

• Since a separate disk was required anyway to configure the DAN II controller on an Apple ///, I converted Dan's configuration menu into a little Apple /// program, which automatically boots from a disk. The disk does allow for a slightly improved interface, since memory isn't issue with a disk. The DAN II only maps 2x256byte of ROM on the Apple II, so everything had to be squeezed in there. Any byte mattered when Dan made its firmware (which is why the card posts "PRESS RTN" at boot time - to save a few bytes :) ). Here's how the config menu now looks on the Apple ///:

DAN2on3_ConfigMenu.jpg

• Finally, I created a native driver for Apple /// SOS to support the DAN II Controller: the DAN2on3.driver. It borrows heavily of other people's work: like from Dan's controller firmware, from David's CFFA3k driver. I also came to admire the Apple III documentation for SOS. The level of detail they provided - down to every bit of their data structures is just insane.

The driver makes the two SD cards available as normal SOS volumes on the Apple /// - as volumes ".DAN1" and ".DAN2"... :)

DAN2on3_SlotConfig2.jpg

The controller works at Apple ///'s full 2MHz clock speed. There was no need to throttle the 6502 down to 1MHz when accessing the controller I/O (it's sometimes required for other hardware). Not surprising, since the 8255 is made for even higher clock speeds anyway. So, Apple /// does keep it's slight performance edge over the Apple IIs even when using this card.

The driver is working with the controller's stock ROM and Arduino firmware - so no changes are required there. I would like to have one or two extensions though - like an option to ask the controller for the actual volume size (16MB volume images are popular for the Apple III, not 32MB as for Apple II/Prodos). This would also be required to make format support work (which currently isn't). One or two other extensions would also be nice. I'll have to talk with Dan about these...

Anyway, if anyone was interested: everything is in this github project - including prebuilt disk images: https://github.com/ThorstenBr/DAN2on3.

So far, it all seems to be working nicely on my machine. But it's only running for two days now - so expect a few updates.

In any case: Dan, you can add another Apple to your list. The DAN II controller is also supported on the /// ! :)

Sweet!

I've got an Apple ///...  The Dan ][ card looks like it would be great for use with it.

profdc9 wrote:

Here's a hack for you...

The Apple /// driver doesn't use the firmware in the ROM (except for scanning the slots). It talks to the Arduino directly. Of course, I can already make the driver report any volume size to SOS which I want. I can just enter the value in the Apple /// driver sources.

The idea was to make a proper solution, which obtains the actual image size from the Arduino - so it supports any image size.

So, here's the ideas I had:

1. Add a status command to the Arduino firmware, which also reports the actual image size (number of blocks or bytes of the FAT file). It should be a new status command, so the existing status command continues to work with current EPROMs.
2. Add another command to the Arduino to obtain the current volume configuration (basically the reverse of the "do_set_volume" operation: a "do_get_volume" operation). It would be nice for the configuration utility to be able to obtain and show the current selection.

When these functions existed on the Arduino side, I could immediately use them with the Apple /// driver/configuration utility - even when the card's ROM with the Prodos interface didn't (yet).

I also had some ideas how the ROM for the Apple II firmware could be improved - even without hardware modifications to the current 2-page ROM system:

3.  Move the entire configuration utility to a 512byte block, which is stored in the Arduino flash (part of its firmware). 512 instead of 128 bytes would allow nice improvements to the configuration menu.

The Arduino currently uses about 50% of its flash, even with all features (Ethernet, Debugging) enabled. Reserving 512byte for a fixed 6502 image would still leave lots of flash for future extensions.

The ROM already contains a routine to transfer 512byte blocks from the Arduino side into the 6502's RAM: the "read block" routine. That can be reused to load the configuration code from the Arduino side into the 6502 RAM and execute it, when needed. Just needs a new command ID to tell the Arduino to return the fixed block with the configuration code, instead of reading a block from the SD cards.

The configuration code is only required when the user hits RETURN - at boot time. The entire RAM is available at this point anyway.

This would free up the configuration code from the entire second half of the card's current ROM. Another 128bytes available for the implementation of the Prodos interface (like to also extend the Prodos status command to work with different volume sizes).

Anyway, maybe we can also move the discussion to github. Would you be willing to consider contributions to your project on github (merge requests)? Adding the first two new commands would be a start. And indeed a rather small extension...

In post #110, CVT wrote:

"For everyone who lives in Europe, there is a much cheaper alternative for the 8255: https://www.ebay.com/itm/284902793052

This is the soviet KR580VV55A (КР580ВВ55 in cyrillic) - a 1:1 equivalent of the Intel 8255A"

Uncle Bernie cautions:

Ex-Eastern Bloc IC packages typically are metric (I never encountered an "inch" based one). Which means pin pitch is 2.50mm, not 2.54mm. For smaller pin counts this is not much of a problem. But for 40 pins you need a socket which can tolerate the difference. The "stamped contact" types with a flat contact on the outside and a "snail" contact in the inside work. But precision machined DIL-40 IC sockets won't work with those "metric" ICs.

UncleBernie wrote:

Uncle Bernie cautions: ...

Wow, you are right! The one I bought is metric, but because I used a flat contact socket I never noticed.

Awesome! I tested all kinds of combinations on Pravetz 82 and Apple IIe and they all work perfectly.

The only interesting thing I found is that it won’t boot from slot 3 on the Apple IIe. This is the slot that is in line with the aux slot on the PAL motherboard and none of my cards boot into ProDOS from it, which is why I think it’s not an issue with the Dan ][ Controller. The only cards that can boot from slot 3 are the Apple ][ floppy drive and the CFFA3000 in Disk ][ mode. If this supposed to be normal?

profdc9 wrote:

Ok, so I just pushed a new version to GitHub.  Here's the changes:

1.  It now supports FAT filesystems on both drive 1 and drive 2.  It does so by closing one of the filesystems and opening the other each time they are switched.  It doesn't seem that slow.  But it's a brand new feature, so beware, it may eat your data.

2.  Pressing escape during boot no

I'd love for it to be able to list a text file off the sd card where we could list the images with titles.

I think simply listing the files with a certain extension and being able to select one will be more than enough. FAT32 supports long file names, so there is no need to list files in a separate text file.

The current firmware has fixed filenames, so unless he gets rid of those, a description file would be the easiest.

The current firmware uses the FatFs library. It implements f_opendir(), f_readdir(), f_closedir() and f_stat(), which is enough to perform directory listing just as easily as opening a text file and reading it.

I finally sourced all of the parts and built a unit this afternoon.

Worked perfectly.  This is the first time I've managed to get a mass-storage solution working in the ACE 1000 -- tjboldt's ROM drive is flakey, and ReactiveMicroDrive Turbo always crashes to monitor.

Thank you very much for having designed this and making it available.

cryu wrote:

I finally sourced all of the parts and built a unit this afternoon.

 

Worked perfectly.  This is the first time I've managed to get a mass-storage solution working in the ACE 1000 -- tjboldt's ROM drive is flakey, and ReactiveMicroDrive Turbo always crashes to monitor.

 

Thank you very much for having designed this and making it available.

Glad you have this working! I won't side track too much, but, are you sure your ProDOS rom drive has the latest firmware? There was a patch to its firmware a couple months ago that fixed things on my II+. 

For the microdrive are you sure it has the II and not IIgs firmware chip? And do you have a system to use to change / Disable DMA mode on the Microdrive itself? 

Terence Boldt’s ProDOS card has been getting lots of firmware updates lately, the latest one being just from 2 weeks ago. I also noticed that soon after MacFly provided the ESC boot skip patch for the Dan ][ Controller, an ESC boot skip was added to the ProDOS card too.

I do like the ProDOS card, especially as a pocket-sized diagnostics tool, but I think the Dan ][ Controller at this point is far superior in every way and it has the potential to even rival the CFFA3000 at some point. Considering how cheap and available the ProDOS card is though (brand new card with preloaded 512KB EPROM for $15) it remains the only card I'm willing to insert for the first time into a newly acquired computer.

I actually requested that latest update for the TJBoldt card (I'm alex-kw on github), to help with using the card in slot 7 with a floppy controller present. 

Certainly not suggesting it's superior to this card, I share your sentiment on it being a affordable card to pop into an unknown condition system. 

I would like one of these but I've built a lot of hobby kits lately. I do still think I'll get to this one too though.  

I'm pretty sure the issues are caused by a timing variance introduced by the janky workaround Franklin had to use to "legally" facilitate color video.

I haven't analyzed the system clocks with a logic analyzer yet, but there's definitely something up:

* Steve's FloppyEmu won't work with a regular Disk ][ controller -- read requests time out.  Works fine with a Franklin (which is a rebadged Micro-SCI) controller with identical firmware as the Disk ][ controller

* when I was working through the issue with Steve, I discovered that it would boot from a Disk ][ if I disabled large chunks of the color timing circuit by lifting IC legs.  No video, of course, but it could boot :)

* the VGA scaler from a2heaven loses sync about once every second

* the ROMdrive will boot from slot 7 with the Franklin FDC removed from the system

* the MicroDrive Turbo works fine in my enhanced //e.  ROM is for the ][, and DMA is turned off

This is with two different 1000s (one with the color board, the other with the two-caps-and-a-coil mod).  Both have had their PSUs replaced with ReactiveMicro units, so no power issues, and all slots have been treated with DeOxIt.

As a side note, I dumped and partially disassembled the Franklin/Micro-SCI ROM and put an image builder at https://github.com/christopherkobayashi/franklin_fdc .  It's an interesting board; it implements Woz's state machine in discrete TTL, has both 13 and 16-sector firmware, as well as what appears to be a diagnostic program and a "jumper things like this" splash page.

I somehow managed to break my AVR ISP, and thus had to get creative in order to flash the new AVR microcode via my TL-866 under Linux.

If anyone else runs into the same issue, here's how it's done:

• Compile and export the microcode in the Arduino IDE via "Sketch / export compiled binary"
  
• Execute "minipro -p 'ATMEGA328P@DIP28' -c code -w Apple2Arduino.ino.standard.hex -f ihex -e"
  
• Create fuses.cfg with contents of:
  lfuse = 0xff
  hfuse = 0xde
  efuse = 0xfd
  lock = 0xff
  
• Execute "minipro -p 'ATMEGA328P@DIP28' -c config -w fuses.cfg -e"
  

edit: can also generate the hex file through CLI by executing "arduino-cli compile -b arduino:avr:uno --output-dir . Apple2Arduino.ino" ... the file containing the microcode is "Apple2Arduino.ino.hex"

cryu wrote: I somehow managed to break my AVR ISP, and thus had to get creative in order to flash the new AVR microcode via my TL-866 under Linux. If anyone else runs into the same issue, here's how it's done: [list] [*] Compile and export the microcode in the Arduino IDE via "Sketch / export compiled binary" [*] Execute "minipro -p 'ATMEGA328P@DIP28' -c code -w Apple2Arduino.ino.standard.hex -f ihex

Thanks for sharing that!  A lot of people have the TL-866 programmers since they are very affordable.

I have both the original TL-866CS as well as the newer TL-866 II+.  I keep the old one since it will program some 2716 and other older EPROMs the newer one won't do.  But the newer one will do a few newer chips the older one won't.

I also use the same Open Source tools under Linux for driving the programmer that you do.  They work really well.

cryu wrote:

As a side note, I dumped and partially disassembled the Franklin/Micro-SCI ROM and put an image builder at https://github.com/christopherkobayashi/franklin_fdc .  It's an interesting board; it implements Woz's state machine in discrete TTL, has both 13 and 16-sector firmware, as well as what appears to be a diagnostic program and a "jumper things like this" splash page.

Thanks for creating that!

I own a MicroSci A2 Disk Controller, and I always wanted to disassemble the contents of that  MicroSci A2 Controller  ROM.  You just made it so much more convenient by disassembling it and uploading it to GitHub.  For anyone who's curious, here's a clickable link to the un-commented disaasembly for the controller's somewhat-hidden "diagnostic" firmware, which is accessed by installing both 13-sector and 16-sector jumpers at the same time  https://github.com/christopherkobayashi/franklin_fdc/blob/main/0000.s-wip

From what I've deciphered so far, that firmware is a 256-byte command-line interface with 7 single-letter commands that work like monitor commands: a simple letter command (like 'R' for recalibrate) or a hexadecimal argument followed by a single-letter (like '11S' to seek track $11)

(Zoom in to this picture to see first attempt to add comments and annotations to the disassembly.)

MicroSci ROM annotations.png

But this is off-topic, as the MicroSci A2 Controller  is not the subject of this thread.  Forgive me please!  So I will record that GitHub URL and my observations in a blogpost...and eventually publish my annotations in another thread.  Or check them into GitHub...if I learn how to do that!

softwarejanitor wrote:Thanks for sharing that!  A lot of people have the TL-866 programmers since they are very affordable.

I figured that might be the case.

For what it's worth, a Makefile and fuses.cfg were merged into the main repository earlier today. To build the firmware (and display TL-866 programming instructions), cd into Apple2Arduino/ and execute "make".

161FAD45-3B7F-47E4-AB76-9DA0149B9043.jpeg

E2ACAF3C-7A09-4178-8087-EDC2BCE2D721.jpeg

So, I've now built two cards - and they're both failing with the exact same issue.  I have an SD card formatted FAT16 using the individual 32MB volumes. 

When booting the card, I get the "DAN ][ PRESS RTN" message and if I hit return, I get the card volume prompts as expected.  

However, whenever it tries to boot - on either card, I get the exact same result. Dumps to monitor with:

0803- A=28 X=D8 Y=06 P=35 S=F8.  

I get this behavior identically on both cards, and it does the same thing even with no SD cards in any slots. 

AA0FA9A7-27E4-4D86-B940-9A8D4F862406.jpeg

This makes me think maybe some of my sourced parts are bad. What would be the behavior of a bad 82C55A?

I programmed the ATMega using an Arduino Uno R3 by swapping the chip that comes with it. It seems to program just fine. The ATMEGA328P's I sourced already had the boot loader - so the fuses should be set - I simply programmed over the existing "blink" sketch that came with it.   

Any hints or suggestions?

If you are using a single SD card, it's supposed to be in slot 1, not in slot 2 like you have it.

The easiest way to test is to just format the SD card in Windows as FAT32, download Total Replay, rename it to BLKDEV01.PO and put it in the root of the SD card. Then in the Dan ][ Controller boot screen hit Enter and choose 1 for both slots.

Thanks - I was confused about the slots.   

However, this is weird.  When I take out the ReactiveMicro RamWorks IIII, it boots.  With it in, it dumps to monitor. Seems entirely dependent on the RAM card being present??

CT100 wrote:

Thanks - I was confused about the slots.   

However, this is weird.  When I take out the ReactiveMicro RamWorks IIII, it boots.  With it in, it dumps to monitor. Seems entirely dependent on the RAM card being present??

That's odd. I have a RamWorks IIII but not one of these cards to try to recreate your problem. I'm intrigued though.

Thanks for making this better and better.

profdc9 wrote:

In the past few days I've made a number of changes to the Arduino code.  In particular, I added a simple boot menu you can get to by pressing space.  You have to upgrade the Arduino firmware to access it.

It lists out the names of the ProDOS volume names on the volumes 0-9,A-F and allows you to select the drive for 1 and 2.  It's not the fastest but it works and its conveni

Is it supposed to work on the Apple IIe, because I am just getting Monitor when I hit Space with the latest everything. I am programming the Atmega 328P chip by simply moving it to an Arduino Uno board and using the Arduino IDE v.2.0.2. This is the output I'm getting with the verbose on:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)avrdude: reading input file "C:\Users\xxx\AppData\Local\Temp\arduino-sketch-28FDA0FD3D13A4E42EEBCA170CA3888F/Apple2Arduino.ino.hex"avrdude: writing flash (15980 bytes):

Writing | ################################################## | 100% 2.56s

avrdude: 15980 bytes of flash written

avrdude done.  Thank you.

CT100 wrote:

...

However, this is weird.  When I take out the ReactiveMicro RamWorks IIII, it boots.  With it in, it dumps to monitor. Seems entirely dependent on the RAM card being present??

I don't have this beast, but I can confirm that it works perfectly with this $10 card from eBay:

20221126_101231.jpg

I just reflashed using the latest FLASH.SYSTEM and then read it back with my Willem programmer and made sure it's identical to https://github.com/profdc9/Apple2Card/blob/main/firmware/Firmware.bin

Here is what I get when I do 800L right after I hit Space from the boot screen and it enters Monitor on the Apple IIe:

IMG_0033.JPG

On my Pravetz 82 (Apple II+ clone) I just get a black screen when I hit Space.

CVT wrote:

Here is what I get when I do 800L right after I hit Space from the boot screen and it enters Monitor on the Apple IIe

Ooo, cool...some machine code!

Without knowing where it came from, here's my best-guess at what that machine code might mean...

Those comments are mostly just guesswork, but they provided enough insight to locate the source code in the Apple2Card project at Apple2Card/firmware/bootpg.asm where it's hard-coded with a DEVSEL index for slot 7 only.

So here's the source code from GitHub.  It's well-designed to compute the IO and ROM addresses for any slot, based on the DEVSEL index in the X register.  But line 37 is hard-coded with the DEVSEL index for slot 7.

Dan bootpg.png

From this it's fairly easy to guess why it crashed:

• The Apple //e probably has a device installed in slot 7 whose firmware contains a $00 byte at adddress $C7D0, and a byte at $C7FF that contains $D0 or $CF.
• The Pravetz 82 probably has an empty slot 7, or a device whose firmware lets the 6502 execute garbage until the processor jams at the illegal $F2 instruction at $D01B.

It strikes me as a likely bug -- there's probably code that already calculated the correct slot number, but someone forgot to store the slot-number in a ZP location to pass it into this boot-page routine.  Or, just as likely, the slot-number was correctly calculated and stored in a ZP location, but this boot-page routine forgot to retrieve it.  Same result either way, the boot-page routine attempted to use slot 7.

Short summary (tl;dr)

If you want to boot the BOOTPG firmware to work in another slot, you'll need to edit line 37 and reassemble, or hex-edit the binary image to change #$70 at offset +$02 to a different value for the slot you want.

For instance, to use the Dan ][ in slot 6, change line 37 to "LDX #$60" or hex-edit that $70 byte to $60.

Or better still, if there's already firmware to detect the correct slot number and save it in a memory location, fix line 37 to retrieve it from that memory location.

(PS: I think that is valid, but I admit it's just a best-guess without any experience with this particular device.  It was a pleasant excuse to attempt some reverse-engineering and failure-analysis,  Forgive me if it's not helpful!)

Well spotted, S.Elliot!

That is most likely forgotten debug code from testing. The slot number of the DAN2 card is passed in the upper nibble of the X-register when the DANII card's ROM passes control to the loaded boot program. Daniel has probably been developing his new boot program separately, without using the Arduino download mechanism for every test. So he hardcoded the value of the X register, so the boot program could be tested on its own. And then this line got forgotten and remained in there, when it was ready to be integrated into the Arduino. And when the card indeed is in slot 7, then it just works anyway.

So, the LDX #$70 needs to be removed. You could just remove this line, reassemble and replace the entire copy of the boot program in the Arduino sources. Or, you could simply replace the "LDX #$70" with two NOPs (0xea). I'm not at home, couldn't test it - but am pretty sure it will work with other slots like this:

Bildschirmfoto von 2022-11-26 23-59-45.png

(The change is in line 608 in Apple2Arduino.ino)

Works! The cooperation here is truly inspiring.

From your short description above I didn't even realize right away what this new feature was supposed to do until now. This is amazing and super useful!

Btw, here is an interesting adapter/extender I just ordered from AliExpress that might be very useful for this card: 

https://www.aliexpress.com/item/1005004149375152.html